Copilot SDK؛ وقتی اجرای عامل به یک قابلیت برنامه تبدیل می‌شود

GitHub در ۱۰ مارس ۲۰۲۶ از Copilot SDK به‌عنوان لایه‌ای برای قراردادن اجرای عامل درون برنامه‌ها گفت. ایده ساده اما معماری‌محور است: به‌جای اینکه کاربر همیشه در IDE یا CLI با Copilot کار کند، یک محصول می‌تواند intent و محدودیت را به موتور برنامه‌ریزی و اجرا بدهد و نتیجه را در همان workflow خود دریافت کند.

#از پاسخ متنی تا execution loop

بسیاری از برنامه‌های LLM هنوز با الگوی سؤال و جواب ساخته می‌شوند. اپلیکیشن متن می‌فرستد، پاسخ می‌گیرد و منطق مرحله بعد را خودش تعیین می‌کند. این الگو برای خلاصه‌سازی مناسب است، اما در کاری که به context، ابزار، تغییر فایل و بازیابی خطا نیاز دارد، glue code زیاد می‌شود. هر edge case یک شرط تازه می‌خواهد و orchestration به‌تدریج شکننده می‌شود.

Copilot SDK قصد دارد این حلقه را به قابلیت قابل برنامه‌ریزی تبدیل کند. برنامه می‌تواند وظیفه‌ای مانند آماده‌سازی repository برای release را به عامل بسپارد؛ عامل مخزن را بررسی کند، مراحل را طرح‌ریزی کند، فایل تغییر دهد، فرمان اجرا کند و در صورت شکست مسیر را اصلاح کند. این آزادی بدون constraint خطرناک است، بنابراین runtime باید tool، permission و محیط اجرا را از ابتدا مشخص کند.

#context ساختاریافته

GitHub در این مطلب هشدار می‌دهد که prompt نباید جای اتصال واقعی سیستم‌ها را بگیرد. مالکیت سرویس، schema API، وابستگی و تصمیم‌های تاریخی بهتر است از طریق ابزار یا MCP در اختیار عامل قرار گیرند، نه با متن بلند و ثابت. context ساختاریافته هم قابل آزمون‌تر است و هم می‌تواند با تغییر سیستم منبع به‌روزرسانی شود.

این رویکرد برای برنامه‌هایی مناسب است که باید در یک event پاسخ دهند: تغییر فایل، trigger استقرار، درخواست کاربر یا پیام صف. اجرای عامل درون application اتفاق می‌افتد، نه در پنجره جداگانه توسعه‌دهنده. در نتیجه telemetry، retry، timeout و هزینه بخشی از مسئولیت همان محصول می‌شود.

#چه چیزی باید کنترل شود؟

تیم نباید SDK را به مخزن یا شبکه بدون محدودیت وصل کند. اجرای کد در sandbox، محدودیت مسیر فایل، ثبت فرمان‌ها و approval برای اقدام برگشت‌ناپذیر حداقل کنترل‌ها هستند. همچنین باید مشخص باشد اگر مدل نسخه‌اش تغییر کرد، خروجی متفاوت یا اشتباه چگونه rollback می‌شود.

یک الگوی استقرار قابل دفاع، قرار دادن SDK پشت صف کار و worker محدود است. صف می‌تواند timeout و retry را کنترل کند و worker فقط ابزارهایی را ببیند که برای همان وظیفه لازم‌اند. این طراحی از آن جلوگیری می‌کند که یک درخواست کاربر به‌طور مستقیم به زنجیره‌ای از عملیات نامحدود تبدیل شود.

Copilot SDK قرار نیست جای معماری برنامه را بگیرد. ارزشش در حذف بخشی از orchestration تکراری است و شرط موفقیتش، تعریف دقیق مرزهاست. وقتی execution به یک interface برنامه تبدیل می‌شود، همان‌قدر که قابلیت محصول بیشتر می‌شود، نیاز به تست و مشاهده‌پذیری هم بالا می‌رود.