اگر امروز یک قابلیت تخصصی برای عامل هوش مصنوعی شرکتتان میسازید، مجبورید برای هر ابزار و محیطی، یک نسخه جداگانه بنویسید. اما از ۱۲ اوت ۲۰۲۶، این دشواری به پایان رسید و گیتهاب (GitHub) پشتیبانی عمومی از Agent Plugins 1.0 را اعلام کرد. این اقدام، افزونههای عاملهای هوش مصنوعی را از قالبهای ایزوله و تکمنظوره به سمت یک استاندارد بستهبندی مشترک و قابلحمل سوق میدهد.
سالهاست توسعهدهندگان با یک مشکل اساسی در بستهبندی دستوپنجه نرم میکنند. طبق گزارشهای فنی، اگر میخواستید قابلیتی برای استقرار کد (Deployment) بسازید، مجبور بودید برای هر ابزاری که تیم استفاده میکرد، مانیفستها و مراحل نصب متفاوتی ایجاد کنید. این تکرار، سربار عملیاتی عظیمی برای سازمانهایی ایجاد میکرد که دهها عامل داخلی و چندین محیط توسعه (IDE) را مدیریت میکردند. از نظر تاریخی، پشتیبانی از چندین کلاینتِ عامل، نیازمند ساختارهای دایرکتوری متفاوت، مراحل نصب مجزا و پوششهای (Wrappers) خاص هر فروشنده بود.
همانطور که در تحلیلهای قبلی ما دربارهی پروتکلهای ارتباطی مدلها اشاره کردیم، نیاز به یک لایه واسط برای حذف وابستگی به فروشنده احساس میشد. این تلاشها در واقع تکامل ائتلاف آمازون و OpenAI برای استانداردسازی افزونههای عاملها است که هدف آن ایجاد یک زبان مشترک برای ابزارهای هوش مصنوعی بود. به همین دلیل گیتهاب با همکاری AWS، Anysphere، مایکروسافت، OpenAI و Vercel — و با حضور گوگل به عنوان نگهدارنده اصلی — استانداردی را خلق کرد که مهارتها و پیکربندیهای پروتکل زمینهٔ مدل (MCP) — شبیه به یک درگاه مشترک که اجازه میدهد مدل به ابزارهای مختلف دسترسی داشته باشد — را در یک واحد قابلنصب جمع میکند. این بدان معناست که یک توسعهدهنده میتواند قابلیتی را یکبار بسازد و آن را در VS Code، رابط خط فرمان (CLI) کوپایلت، اپلیکیشن کوپایلت و SDK گیتهاب کوپایلت اجرا کند.
معماری سهلایه برای جابهجایی آسان
این استاندارد برای تضمین قابلیت حمل، توانمندیهای عامل را به سه لایه متمایز تقسیم میکند. برای درک بهتر، این مدل ذهنی را در نظر بگیرید: مهارت یعنی «روش کار»، MCP یعنی «دسترسی به ابزار» و پلاگین یعنی «بستهبندی و توزیع».
- مهارتها (Skills): این لایه «چگونگی» انجام کار را تعریف میکند. یک مهارت به عامل میگوید که یک وظیفه چگونه باید اجرا شود. این لایه شامل گردش کار (Workflow)، قوانین حوزه، دستورالعملهای اجرایی (Runbooks)، قالبها، مثالها و بهترین روشها برای یک وظیفه خاص است.
- سرورهای MCP: این لایه «چیستی» را فراهم میکند. پروتکل زمینه مدل (Model Context Protocol) به عامل اجازه میدهد دسترسی کنترلشدهای به ابزارهای خارجی و سیستمها داشته باشد؛ سیستمهایی مانند گیتهاب، جیرا (Jira)، پایگاهدادهها، کوبرنتیز (Kubernetes)، سیستمهای CRM و مرورگرها.
- پلاگینها (Plugins): این لایه توزیع است. پلاگین واحد بستهبندی و توزیعی است که به کلاینتهای سازگار اجازه میدهد قابلیت را شناسایی، بازرسی و مصرف کنند.
تصور کنید یک فرآیند استقرار کد دارید. یک سرور MCP ممکن است ابزارهایی مثل deploy()، rollback() و get_status() را ارائه دهد. اما ابزارها به تنهایی به عامل نمیگویند که چه زمانی استقرار مجاز است، کدام بررسیها اجباری هستند یا کدام محیطها نیاز به تاییدیه دارند. اینجاست که «مهارت» وارد میشود و آن قوانین را کدگذاری میکند. سپس «پلاگین» تضمین میکند که هم ابزار و هم قانون، با هم نصب شوند. در مجموع، مهارت رویه ایمن را تعریف میکند، MCP اقدامات کنترلشده را فراهم میکند و پلاگین آنها را به عنوان یک قابلیت کامل عامل توزیع میکند.
ساختار دقیق بستهها
یک بسته مفهومی حداقلی، مجموعهای از پرامپتها و اسکریپتهای پراکنده را به یک واحد توزیع نرمافزاری تحت حاکمیت تبدیل میکند. ساختار یک بسته ساده به این شکل است:
company-deploy/plugin.json(مانیفست اصلی)skills/deployment/SKILL.md(تعریف بررسیهای پیش از استقرار، تاییدیه، بررسی مهاجرت دیتابیس، تایید سلامت سیستم، بررسی نرخ خطا و شرایط بازگشت/Rollback)
mcp.json(پیکربندی عملیات واقعی استقرار)
حاکمیت سازمانی و امنیت
برای سازمانهای بزرگ، ارزش این استاندارد در کنترل است تا راحتی. وقتی صدها توسعهدهنده، دهها عامل داخلی و چندین پلتفرم عامل وجود دارد، اگر هر ادغام نیاز به مجوز و حسابرسی جداگانه داشته باشد، حاکمیت (Governance) بسیار گران تمام میشود.
اکنون سازمانها میتوانند مخزنی مرکزی از پلاگینهای تاییدشده — مثل company-security یا company-finance یا company-database یا company-support — داشته باشند و آنها را از طریق یک مارکتپلیس داخلی توزیع کنند. این جریان باعث میشود مسیر به این شکل باشد: مارکتپلیس سازمانی $
ightarrow$ پلاگین تاییدشده $
ightarrow$ نصب توسط توسعهدهنده $
ightarrow$ مهارت + MCP $
ightarrow$ نسخه کنترلشده $
ightarrow$ دسترسیهای کنترلشده $
ightarrow$ بهروزرسانی کنترلشده.
گیتهاب برای پشتیبانی از این حاکمیت، تنظیمات مدیریتی جدیدی معرفی کرده است. مدیران میتوانند با استفاده از تنظیماتی مثل enabledPlugins (پلاگینهای فعال)، extraKnownMarketplaces (مارکتپلیسهای شناختهشده اضافی) و strictKnownMarketplaces (مارکتپلیسهای سختگیرانه) دسترسی به پلاگینهای غیرمجاز را مسدود کنند یا نصبها را به منابع تاییدشده محدود کنند. این موضوع حیاتی است چون پلاگینها از طریق پیکربندی MCP، دسترسی واقعی به سیستمها دارند. در همین راستا، گیتهاب پیشتر مکانیزمهای تعیین آستانه اطمینان را برای کنترل دقیقتر اقدامات خودکار عاملها معرفی کرده بود تا ریسک خطاهای سیستمی کاهش یابد.
مدیریت ریسک و خط لوله امنیتی
امنیت همچنان دغدغه اصلی است. یک پلاگین میتواند ترکیبی از دستورالعملها، ابزارها، هوکها (Hooks) و دستورات باشد. بر اساس مستندات امنیتی، یک بسته آلوده میتواند منجر به خروج دادهها، اجرای دستورات مخرب در شل (Shell)، سرقت اعتبارنامهها، تغییر مسیر MCP، تزریق پرامپت (Prompt Injection) یا ایجاد تداوم (Persistence) از طریق هوکها شود. بنابراین پلاگینهای عامل باید مانند وابستگیهای نرمافزاری مدیریت شوند، نه مانند تمهای ظاهری ادیتور.
تایید یک پلاگین نباید به معنای تایید خودکار هر سرور MCP یا فراخوانی زمان اجرا باشد. یک سیاست امنتر این است که پیش از اجرا، چهار شرط برقرار باشد: پلاگین تایید شده باشد AND سرور MCP تایید شده باشد AND کاربر نقش لازم را داشته باشد AND سیاست ابزار در زمان اجرا (Runtime Tool Policy) تایید شود.
برای کاهش ریسک، این استاندارد یک خط لوله امنیتی سختگیرانه را پیشنهاد میدهد:
- توسعه: ساخت پلاگین $
ightarrow$ بازبینی کد $
ightarrow$ اسکن استاتیک. - اعتبارسنجی: اسکن محتوای مهارت $
ightarrow$ بررسی لیست سفید MCP $
ightarrow$ بازبینی دسترسیها. - توزیع: امضا $
ightarrow$ مارکتپلیس داخلی $
ightarrow$ نصب مرحلهای $
ightarrow$ حسابرسی زمان اجرا.
سازمانها باید شناسه پلاگین، نسخه، ناشر، هش (Hash)، سرورهای MCP، مهارتها، دسترسیها، کاربران نصبکننده و تاریخ آخرین بهروزرسانی را ردیابی کنند.
قابلیت حمل در برابر نوآوری
یک نکته کلیدی این است که «قابلحمل» به معنای «یکسان» نیست. این استاندارد اجازه میدهد پوشههای مخصوص هر فروشنده وجود داشته باشد. مثلاً یک بسته میتواند پوشه com.github.copilot/ داشته باشد که شامل ویژگیهایی است که فقط در کوپایلت کار میکنند. سایر کلاینتها این پوشههای نامگذاری شده (Namespaced) را نادیده میگیرند. این معماری به فروشندگان اجازه میدهد بدون شکستن هسته مشترک، در زمینه عاملها، دستورات، قوانین، هوکها یا بومهای (Canvases) خاص خود نوآوری کنند.
این معماری وابستگی به فروشنده (Vendor Lock-in) را کاهش میدهد. در حالی که مدلهای LLM به سرعت تغییر میکنند، داراییهای سازمانی — مانند سیاستهای داخلی، ادغام ابزارها و دانش حوزه — بادوام هستند. با جداسازی این داراییها از کلاینت عامل، شرکتها از بازسازی کل پشته ادغام خود در هر بار تغییر مدل یا پلتفرم اجتناب میکنند.
استراتژی پیادهسازی
سازمانها نیازی به مهاجرت فوری ندارند. گیتهاب تایید کرد پلاگینهای قدیمی که هدفشان Agent Plugins 1.0 نیست، همچنان پشتیبانی میشوند. مسیر پیشنهادی این است که پلاگینهای پایدار فعلی در محیط عملیاتی بدون تغییر بمانند، برای بستههای قابلحمل جدید از Agent Plugins 1.0 استفاده شود و اولویت مهاجرت برای قابلیتهایی باشد که باید در چندین کلاینت اجرا شوند.
برای کسانی که اکنون شروع میکنند، ساختار پیشنهادی مخزن سازمانی به این صورت است:
agent-plugins/deployment/(plugin.json,skills/,mcp.json,com.github.copilot/)database/security/support/
چنین مخازنی باید شامل CODEOWNERS (مالکان کد)، CI، اسکن امنیتی، تگهای نسخه و یادداشتهای انتشار (Release Notes) باشند تا از تبدیل شدن پلاگینها به پیکربندیهای مدیریتنشده روی لپتاپهای شخصی جلوگیری شود.
شناسایی موارد کاربرد
هر فرآیندی نباید به پلاگین تبدیل شود. بهترین کاندیداها، گردشهای کاری تکرارپذیر، مکرر و ابزار-محور هستند. مثالها عبارتند از:
- استقرار و بازگشت (Rollback) در DevOps.
- پرسوجوهای دادهای و تولید گزارشات.
- تحقیقات امنیتی.
- تحلیل تیکتها، جستوجوی سفارشات پشتیبانی و ایجاد تیکت.
در مقابل، گزینههای ضعیف شامل گردشهای کاری نادر، وظایفی که نیاز به قضاوت انسانی قابلتوجه دارند یا سیستمهای ناپایدار بدون APIهای مطمئن هستند. سازمانها باید پیش از باز کردن دسترسی عاملها، سیستم زیربنایی را مدیریت و اصلاح کنند.
آینده پشته هوش مصنوعی
این تحول شبیه به تکامل مرورگرهای وب و IDEهاست. یک پشته مشترک در حال شکلگیری است: کلاینت عامل $
ightarrow$ پلاگین (شامل مهارتها، سرورهای MCP، قوانین، دستورات، هوکها و افزونههای فروشنده). در این ساختار، MCP لایه اتصال ابزار، مهارتها لایه رویهای، پلاگینها لایه بستهبندی و کلاینتها لایه اجرای کد هستند. برای تامین امنیت این لایهها، راهکارهایی مانند ایزولهسازی محیطهای اجرا توسط Agent-Up اهمیت مییابند تا از تداخل یا نشت دادهها در محیطهای اشتراکی جلوگیری شود.
تیمها باید پیش از عرضه، از یک چکلیست استفاده کنند که موارد زیر را پوشش دهد: عملکرد (شناسایی و اتصال)، امنیت (دسترسی به اسرار و دسترسی به محیط عملیاتی)، حاکمیت (مالکیت و لغو دسترسی) و عملیات (قابلیت ردیابی و استراتژی عرضه).
پشتیبانی گیتهاب از Agent Plugins 1.0 به یک تغییر بزرگتر اشاره دارد: قابلیتهای عامل در حال تبدیل شدن به بستههای نرمافزاری قابلحمل هستند. برای افراد، این موضوع تکرار پیکربندی را کاهش میدهد و برای سازمانها، ارزش در مارکتپلیسهای داخلی، نسخههای یکسان و کاهش وابستگی به فروشنده نهفته است.
گام بعدی شما
- اگر از ابزارهای داخلی برای اتوماسیون استفاده میکنید، ابتدا گردشهای کاری تکراری خود را شناسایی و آنها را به قالب «مهارت» و «ابزار» تفکیک کنید.
- برای تیمهای DevOps، بررسی کنید که آیا میتوان دستورالعملهای استقرار را در قالب یک پلاگین استاندارد برای تمام اعضای تیم یکسان کرد یا خیر.
- در صورت استفاده از MCP، یک خط لوله امنیتی برای امضا و تایید پلاگینها پیش از استقرار در محیط عملیاتی طراحی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو