CUGA چگونه پیوند ابزارهای محلی و MCP را در عامل‌ها تسهیل می‌کند؟

تصور کنید هفته‌ها زمان خود را صرف اتصال مدل‌ها به ابزارها، طراحی رابط‌های میانی و مدیریت حافظه کنید، پیش از آنکه عامل شما حتی یک دستور ساده را اجرا کند. IBM با عرضهٔ CUGA (Configurable Generalist Agent) این مرحلهٔ خسته‌کنندهٔ «لوله‌کشی» (Plumbing) را حذف کرده است تا یک اپلیکیشن عامل‌محور (Agentic) تنها در یک فایل پایتون جای بگیرد.

اکثر توسعه‌دهندگان در حال حاضر هفتهٔ اول ساخت یک عامل را صرف زیرساخت می‌کنند، نه منطق برنامه. آن‌ها یک چارچوب انتخاب می‌کنند، کلاینت مدل را متصل می‌کنند، برای ابزارها آداپتور می‌نویسند و راهی برای ارسال وضعیت (State) به رابط کاربری می‌سازند. در این میان، بخش جالب اپلیکیشن — یعنی آنچه عامل قرار است واقعاً انجام دهد — در اولویت آخر قرار می‌گیرد. CUGA این روند را وارونه می‌کند؛ این ابزار یک «هارنس» (Harness) یا پیش‌خوان آماده و متن‌باز از IBM است که برنامه‌ریزی، حلقهٔ اجرا، فراخوانی ابزارها و لوله‌کشی وضعیت را به‌طور خودکار هندل می‌کند. آنچه برای شما باقی می‌ماند، تعیین ابزارهای در دسترس و دستوراتی است که به عامل می‌دهید.

معماری هارنس (The Architecture of the Harness)

CUGA بیشتر شبیه به یک محیط زمان‌اجرا (Runtime) است تا یک چارچوب سنتی. این رویکرد توسعه‌دهندگان را از بازسازی مداوم ارکستراسیون حول یک مدل نجات می‌دهد. به نقل از مستندات فنی این پروژه، سیستم CUGA پیش از اقدام، ابتدا برنامه‌ریزی می‌کند و سپس با ترکیبی از فراخوانی ابزارهای خارجی و تولید کد از طریق مکانیسم CodeAct، دستورات را اجرا می‌کند.

در تکالیف طولانی که بیش از ۲۰ گام دارند، اکثر عامل‌ها شکست می‌خورند چون نتایج میانی را گم کرده و در مراحل بعدی آن‌ها را به‌طور اشتباه بازسازی می‌کنند. CUGA این مشکل را با حفظ دقیق وضعیت و اجرای یک گام «تامل» (Reflection) حل می‌کند. این گام تامل می‌تواند یک فراخوانی نادرست را شناسایی کرده و به‌جای پیشروی کورکورانه و تکرار اشتباه، برنامه را مجدداً بازنگری کند. طبق گزارش‌های منتشر شده، همین سازوکار پیچیده باعث شد CUGA در محک‌های معتبری چون AppWorld (در بازه ژوئیه ۲۰۲۵ تا فوریه ۲۰۲۶) و WebArena (در بازه فوریه ۲۰۲۵ تا سپتامبر ۲۰۲۵) رتبه‌های برتر را کسب کند.

جزئیات پیاده‌سازی هسته

برای اثبات کارایی این رویکرد، IBM مجموعه‌ای از ۲۴ نمونهٔ عملیاتی به نام cuga-apps را ساخت. هر برنامه در این مجموعه تنها یک فایل FastAPI است که یک CugaAgent را در بر می‌گیرد. این طراحی تضمین می‌کند که اگر شما یک مسیر (Route) در FastAPI نوشته باشید، می‌توانید تمام خطوط کد عامل را بدون نیاز به یادگیری یک چارچوب جدید و پیچیده بخوانید.

به عنوان مثال، در اپلیکیشن «مشاور ابری IBM»، عامل تنها با چهار آرگومان اصلی ساخته می‌شود:

• model: مدل مورد نظر که توسط یک کارخانهٔ create_llm تامین می‌شود.
• tools: فهرستی از قابلیت‌ها که از طریق متد _make_tools() تعریف می‌شوند.
• special_instructions: همان پرامپت سیستمی یا دستورالعمل‌های ویژه (_SYSTEM).
• cuga_folder: یک دایرکتوری محلی (به عنوان مثال .cuga) که اپلیکیشن وضعیت و سیاست‌های خود را در آن نگه می‌دارد.

منطق برنامه از طریق مسیرهای FastAPI به‌شدت ساده شده است. مرورگر یک پرسش را به مسیر /ask ارسال می‌کند و پنل زنده برای دریافت وضعیت، نقطه اتصال /session/{thread_id} را مانیتور می‌کند. در این ساختار، هیچ پایگاه‌داده‌ای وجود ندارد؛ وضعیت هر گفتگو (Thread) یک دیکشنری پایتونی است که فقط عامل از طریق ابزارهایش آن را تغییر می‌دهد. رابط کاربری در واقع صرفاً نمایشی از وضعیتی است که عامل تغییر داده است.

ادغام ابزارها و پروتکل MCP

سیستم CUGA برای سبک نگه داشتن برنامه‌ها از یک الگوی ابزار دوگانه استفاده می‌کند که توابع محلی را با قابلیت‌های میزبانی‌شده ترکیب می‌کند:

• ابزارهای MCP: قابلیت‌های عمومی و بدون وضعیت از سرورهای پروتکل زمینهٔ مدل (Model Context Protocol) فراخوانی می‌شوند. ۷ سرور عمومی (شامل ۳۶ ابزار) روی IBM Code Engine میزبانی می‌شوند که نیازی به احراز هویت ندارند. این ابزارها قابلیت‌هایی مانند جست‌وجوی وب، دسترسی به ویکی‌پدیا/arXiv، ژیکودینگ (Geocoding)، هواشناسی و نرخ‌های مالی را فراهم می‌کنند. یک پل ارتباطی کوچک این URLها را به‌طور خودکار حل می‌کند. برای مثال، با فراخوانی load_tools(["web"]) جست‌وجوی وب اضافه می‌شود بدون اینکه توسعه‌دهنده نیاز به میزبانی هیچ چیزی داشته باشد.
• ابزارهای داخلی (Inline Tools): منطق خاص هر برنامه به صورت توابع استاندارد پایتونی تعریف می‌شود. عامل با خواندن Docstring تابع تصمیم می‌گیرد چه زمانی از آن استفاده کند. برای مثال، مشاور معماری IBM از تابع search_ibm_catalog استفاده می‌کند تا پیش از پیشنهاد هر سرویس، وجود واقعی آن را تایید کند و مطمئن شود که عامل هرگز نام سرویس‌های خیالی را ابداع نمی‌کند.

برای جلوگیری از کرش کردن عامل، CUGA یک قرارداد بازگشتی سخت‌گیرانه برای هر ابزار داخلی تحمیل می‌کند. ابزارها باید پاسخی در قالب یک پاکت کوچک برگردانند:

• موفقیت: {"ok": true, "data": {...}}
• شکست: {"ok": false, "code": "...", "error": "..."}

این روش باعث می‌شود Trace-stackهای خام در میانه‌ی برنامه ظاهر نشوند. برنامه‌ریز CUGA یک شکست اعلام شده را به‌صورت منعطف مدیریت می‌کند (مثلاً: «ژیکودینگ چیزی برنگرداند، پس این بخش را نادیده بگیر و ادامه بده»)، در حالی که استثناهای اعلام نشده (Undeclared Exceptions) باعث ریل‌زدگی و توقف کامل اجرا می‌شوند. این قرارداد ساده اما حیاتی، تفاوت بین عاملی است که خود را بازیابی می‌کند و عاملی که با کوچک‌ترین خطا از کار می‌افتد.

استدلال و طراحی مستقل از مدل

CUGA برای حفظ انسجام به مدل‌های غول‌پیکر و پیشرو وابسته نیست. در حالی که اکثر هارنس‌ها برای بازیابی از خطاهای برنامه‌ریزی به مدل‌های Frontier تکیه می‌کنند، CUGA عملیات برنامه‌ریزی، تامل و ردیابی متغیرها را خودش انجام می‌دهد. این سیستم باری را بر دوش می‌کشد که در غیر این صورت بر عهده مدل بود و اجازه می‌دهد مدل‌های کوچک‌تر با وزن‌های باز (Open Weights) در جاهایی که معمولاً شکست می‌خورند، پایداری کنند.

به همین دلیل، اپلیکیشن‌های میزبانی‌شدهٔ CUGA به‌جای APIهای پولی و گران‌قیمت، روی مدل gpt-oss-120b اجرا می‌شوند. این موضوع ثابت می‌کند که مدل‌های باز کوچک‌تر، در صورت جفت شدن با یک هارنس قدرتمند، کفایت می‌کنند. این رویکردی است که در پروژه‌های مشابه نیز دیده می‌شود؛ برای example، سیستم Clioloop نیز با ترکیب مدل‌های ارزان‌قیمت تلاش می‌کند تا کیفیت مدل‌های پیشرو را شبیه‌سازی کند تا بهره‌وری عملیاتی افزایش یابد. توسعه‌دهنده می‌تواند موازنه هزینه و تأخیر را بدون تغییر کد و تنها از طریق پیکربندی در سه حالت تنظیم کند:

• Fast (سریع)
• Balanced (متعادل)
• Accurate (دقیق)

اجرای کد در یک محیط ایزوله (Sandbox) به انتخاب کاربر انجام می‌شود که شامل محیط محلی، Docker/Podman یا ابر E2B است. این هارنس کاملاً مستقل از مدل (Model-agnostic) است؛ کارخانه create_llm اجازه می‌دهد تنها با تغییر یک متغیر محیطی بین OpenAI، Anthropic، watsonx، LiteLLM و Ollama جابه‌جا شوید، بدون اینکه کد اپلیکیشن متوجه شود چه مدلی در پشت صحنه قرار دارد.

حاکمیت داده و نظارت تولیدی

سیستم نظارت در زمان اجرا (Runtime) ادغام شده و نه به صورت یک لایه جداگانه. CUGA شامل یک سیستم سیاست‌گذاری است که سیاست‌ها مستقیماً به شیء عامل متصل می‌شوند. این سیاست‌ها در پوشه .cuga ذخیره می‌شوند تا همگام با کد نسخه‎‌بندی شوند و از تغییرات ناخواسته در تنظیمات جداگانه جلوگیری شود.

شش نوع سیاست مجزا برای ایمن‌سازی پیش از استقرار در محیط تولید وجود دارد:
۱. محافظ قصد (Intent Guard): بررسی درخواست پیش از آنکه عامل ابزاری را انتخاب کند. این لایه می‌تواند با استفاده از تطبیق کلمات کلیدی یا شباهت معنایی (از طریق sqlite-vec store) درخواست را به‌طور کلی رد کند. مثلاً مسدود کردن فلگ‌های تخریبی git مانند --force یا --no-verify با پیام: «مسدود شد: فلگ‌های تخریبی git مجاز نیستند.»
۲. تأیید ابزار (Tool Approval): پس از تولید کد توسط عامل اجرا می‌شود تا پیش از اجرای یک ابزار پرریسک، برای دخالت انسانی توقف کند.
۳. راهنمای ابزار (Tool Guide): نحوه استفاده از یک ابزار خاص را هدایت می‌کند بدون اینکه نیاز به بازنویسی خود ابزار باشد.
۴. کتابچه راهنما (Playbook): یک رویه تایید شده و موفق را برای کارهای تکراری تثبیت می‌کند.
۵. قالب‌ساز خروجی (Output Formatter): تنها زمانی که پیام نهایی آماده شد اجرا می‌شود تا پاسخ را به شکل مورد نیاز اجبار کند.
۶. سیاست سفارشی (CustomPolicy): یک راه خروج برای نیازهای بسیار خاص و تخصصی.

زمان‌بندی این لایه‌ها حیاتی است: ابتدا Intent Guards درخواست را چک می‌کنند، سپس Tool Approval بعد از تولید کد اما پیش از اجرا عمل می‌کند و در نهایت Output Formatters فعال می‌شوند. چون این سیاست‌ها از شباهت معنایی در sqlite-vec استفاده می‌کنند، بر اساس «قصد کاربر» فعال می‌شوند و نه فقط کلمات کلیدی دقیق. اهداف تطبیق می‌توانند شباهت معنایی، وضعیت خاص عامل یا فعال شدن یک ابزار خاص باشند.

این معماری امکان ایجاد Sovereign Core (هسته حاکمیتی) را فراهم می‌کند که استراتژی IBM برای محیط‌های بسیار محدود است. با استفاده از «ایزولاسیون مرزی» (Boundary Isolation)، داده‌ها، صفحه کنترل و موتور اجرا در یک مرز منطقی می‌مانند. عامل‌ها در کانتینرهای گذرا و ایزوله در فضای کاری خودِ مشتری اجرا می‌شوند و مدل (که به‌طور پیش‌فرض gpt-oss-120b است) کاملاً Air-gapped (جدا از شبکه خارجی) در زیرساخت قرار دارد. هر گام استدلالی ردپاهای OpenTelemetry را به یک بک‌اند Grafana Tempo ارسال می‌کند که در محیط مشتری می‌ماند و هیچ تله‌متری به بیرون ارسال نمی‌شود. هیچ چیز از این مرز خارج نمی‌شود.

مقیاس‌پذیری به سامانه‌های چندعاملی

وقتی یک تکلیف بیش از حد پیچیده شود و عامل ریسک غرق شدن در کانتکست (تعداد زیاد ابزارها یا شواهد برای ردیابی) داشته باشد، CUGA از یک CugaSupervisor استفاده می‌کند. ناظر، کار را به عامل‌های متخصص (CugaAgents) تفویض می‌کند که هر کدام پرامپت، مجموعه ابزار و کانتکست ایزوله خود را دارند. ناظر تنها درباره این فکر می‌کند که هر زیر-تسک را به کدام متخصص بسپارد، به این معنی که سطح برنامه‌ریزی آن کوچک باقی می‌ماند. اگر یک ابزار ناپایدار باشد، تنها یک تفویض شکست می‌خورد، نه کل فرآیند.

متخصص‌ها می‌توانند محلی باشند یا عامل‌های خارجی که از طریق تفویض A2A (Agent-to-Agent) در دسترس هستند. یک مثال عینی، سیستم Ouroboros است؛ یک سیستم تولید لید (Lead-generation) با هفت عامل. این سیستم دارای یک ناظر است که هفت متخصص را مدیریت می‌کند:

• Scout (جست‌وجوگر)
• Site Auditor (بازرس سایت)
• Voice-of-Customer (صدای مشتری)
• Person Finder (یافتن شخص)
• Stack Scanner (اسکنر تکنولوژی‌های مورد استفاده)
• Revenue Estimator (تخمین درآمد)
• Pitch-email Writer (نویسنده ایمیل نهایی که خروجی را ترکیب می‌کند)

ناظر این عامل‌ها را از طریق ابزارهای تولید شده خودکار مانند delegate_to_<name> فراخوانی می‌کند. افزودن متخصص هشتم تنها با تغییر یک خط در کارخانه مدل ممکن است و نیاز به بازنویسی هماهنگ‌کننده ندارد. این ساختار چندعاملی در فایل ARCHITECTURE.md برنامه به‌طور مفصل شرح داده شده است.

علاوه بر تفویض، CUGA چارچوب ALTK-Evolve را برای یادگیری حین کار معرفی کرده است. عامل‌ها می‌توانند یک «مهارت عامل» (Agent Skill) — که پوشه‌ای شامل یک Playbook در فایل SKILL.md است — را بر اساس اجراهای قبلی خود اصلاح کنند. عامل این پلی‌بوک را تنها زمانی که تکلیف لازم باشد وارد کانتکست می‌کند تا یاد بگیرد از تجربات امروز برای سریع‌تر و دقیق‌تر کردن اجرای فردا استفاده کند. فایل SKILL.md آموخته‌های عامل را فراتر از دستورالعمل‌های اولیه انسانی ثبت می‌کند و نیاز به پرامپتینگ مجدد برای مشکلاتی که قبلاً حل شده‌اند را از بین می‌برد.

کتابخانه Cuga-Apps و شروع کار

برای کمک به توسعه‌دهندگان، مخزن cuga-apps کاتالوگی از نقاط شروع فراهم می‌کند. چون این برنامه‌ها اسکلت مشترکی دارند، یادگیری یک برنامه (مثل مشاور ابری) به معنای درک تمام آن‌هاست. شما می‌توانید مخزن را کلون کنید، در دایرکتوری cuga-apps/cuga-apps/apps/ برنامه‌ای که نزدیک‌ترین ایده را به هدف شما دارد شناسایی کرده و لیست ابزارها و پرامپت را ویرایش کنید. راهنمای این کار در فایل‌های HOW_TO_BUILD_AN_APP_FAST.md و ADDING_AN_APP.md موجود است.

این برنامه‌ها در دسته‌های زیر طبقه‌بندی شده‌اند:

• پژوهشی (Research): شامل Paper Scout (رتبه‌بندی مقالات arXiv بر اساس تعداد ارجاعات)، Wiki Dive و Web Researcher برای سنتز داده‌های مستند.
• بهره‌وری روزمره (Everyday Productivity): گزارش‌های شهری، سفر، دستور پخت و مسیرهای پیاده‌روی.
• سند/رسانه (Document/Media): اجرای RAG (تولید بازیابی‌افزا) روی PDFها، صوت و ویدیو با استفاده از Docling.
• عملیاتی (Operations): مانیتورینگ لحظه‌ای متریک‌ها از طریق یک گوشه عملیاتی (Ops Corner).
• سازمانی (Enterprise): نمونه‌هایی که از مستندات واقعی محصولات IBM استفاده می‌کنند.
• اتوماسیون (Automation): مانند Meetup Finder که از طریق Playwright یک مرورگر Chromium بدون سر (Headless) را هدایت می‌کند تا رویدادهای ساختاریافته را از Meetup، Luma و Eventbrite استخراج کند، چرا که این پلتفرم‌ها APIهای جست‌وجوی عمومی خود را حذف کرده‌اند. این اتوماسیون مرورگر، قدرت اصلی CUGA در نتایج WebArena بود.

توسعه‌دهندگان می‌توانند از گالری زنده و MCP Tool Explorer استفاده کنند تا پیش از اتصال ابزارها به عامل، آن‌ها را از طریق یک فرم فراخوانی و تست کنند. رابط کاربری برنامه‌ها را به عنوان «آماده برای عرضه» (ship-ready)، «برای بعد» یا «اکتشافی» علامت‌گذاری می‌کند. IBM با استانداردسازی وضعیت و حلقه اجرا، نقش توسعه‌دهنده را از یک «لوله‌کش» به یک «رهبر ارکستر» تغییر داده است و انتقال از یک دموی لپ‌تاپی به یک محیط تولیدی تحت نظارت را به جای بازنویسی کامل، به یک موضوع بازdeployment تبدیل کرده است.

راه اندازی و استقرار

راه‌اندازی محیط نیاز به Docker و چند گام ساده دارد. پس از کلون کردن مخزن cuga-apps کاربر باید .env.example را به .env کپی کرده و ارائه‌دهنده LLM و کلید مربوطه را تنظیم کند. کلیدهای API برای ابزارهای خاص مانند TAVILY، OPENTRIPMAP یا ALPHA_VANTAGE نیز برای برنامه‌هایی که به آن‌ها نیاز دارند اضافه می‌شوند. اجرای دستور docker compose up --build محیط را مقداردهی اولیه می‌کند، شامل بیلد بزرگ برای CUGA، Chromium و وابستگی‌های MCP، و رابط کاربری را در http://localhost:8080 ارائه می‌دهد.

به دلیل کوچک بودن هارنس، متن‌باز بودن و استقلال از مدل، عاملی که روی لپ‌تاپ نوشته شده دقیقاً همان عاملی است که در یک استقرار محدود (Locked-down) اجرا می‌شود. حاکمیت (Sovereignty) در اینجا یک وعده نیست، بلکه یک واقعیت قابل بررسی است چون کد زمان‌اجرا باز است. توسعه‌دهندگان با دستور pip install cuga می‌توانند به زمان‌اجرا و سیستم سیاست‌ها دسترسی پیدا کنند، در حالی که مستندات پروژه در cuga.dev میزبانی می‌شوند. انتقال از یک اپلیکیشن آزمایشی به یک استقرار حاکمیتی در یک VNET با تأیید ابزار-به-ابزار، تنها تغییری در نحوه استقرار است، نه تغییری در تعریف عامل.

گام بعدی شما

• مخزن cuga-apps را کلون کرده و با اجرای docker compose up --build محیط را راه‌اندازی کنید.
• برای کاهش هزینه‌ها، مدل‌های Ollama را در محیط محلی تست کرده و تأثیر سیستم برنامه‌ریزی CUGA را بر مدل‌های کوچک ببینید.
• ابزارهای مورد نیاز خود را از طریق MCP Tool Explorer شناسایی و به عامل خود اضافه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.