تصور کنید یک شبکه‌ی عامل‌محور در محیط عملیاتی، تنها در ۴۶ دقیقه قابلیت‌های جدیدی را جذب کند، بدون آنکه حتی یک خط از کدهای موجود تغییر کند. این دستاورد، نتیجه‌ی آزمون استرس پروتکل IRC-A است؛ سیستمی غیرمتمرکز که برای عبور از جریان‌های کاری سخت‌افزاری و صلب طراحی شده است.
بسیاری از ساختارهای فعلی عامل (Agent) — شبیه به یک شرکت با سلسله‌مراتب سخت‌گیرانه که برای هر تغییر کوچک نیاز به تأیید مدیرعامل دارد — بر ارکستراتورهای متمرکز یا جریان‌های استاتیک متکی هستند. در این مدل‌ها، افزودن هر ابزار جدید مستلزم بازنشر (Redeploy) کامل کد است که ریسک شکست عملکردهای موجود را بالا می‌برد. رویکرد IRC-A اما با عامل‌ها به عنوان گره‌های «بزن و ببر» (Plug-and-Play) برخورد می‌کند که از طریق یک درگاه (Gateway) ثبت می‌شوند و اجازه می‌دهند شبکه به‌صورت ارگانیک رشد کند.
طبق گزارش‌های فنی، در ۱۴ اوت ۲۰۲۶ آزمونی در دنیای واقعی برای سنجش این چابکی انجام شد. نقطه شروع یک شکست بود: سیستم نمی‌توانست به پرسش‌های مربوط به فروش پاسخ دهد چون هیچ عامل تخصصی در این حوزه وجود نداشت. وقتی سوال شد «در ماه جولای چقدر فروش داشتیم؟»، درگاه درخواست را به عامل مشتریان فرستاد، صرفاً چون از نظر معنایی نزدیک‌ترین گزینه بود. این خطای مثبت (False Positive) نشان داد که نقطه انتهایی /discover به یک آستانه‌ی شباهت قابل تنظیم نیاز دارد تا از ارجاعات نادرست جلوگیری کند.
به جای اصلاح منطق هسته، توسعه‌دهنده با استفاده از یک کرونومتر اندازه‌گیری کرد که ساخت و استقرار یک عامل متخصص گزارش‌های فروش از صفر چقدر زمان می‌برد تا فاصله زمانی بین تصمیم‌گیری تا استقرار نهایی دقیقاً محاسبه شود.
ادغام در ۴۶ دقیقه
بر اساس مستندات این آزمایش، فاصله زمانی تصمیم برای ساخت عامل تا مشاهده‌ی آن در داشبورد نظارتی، دقیقاً ۴۶ دقیقه بود. این فرآیند به هیچ تغییر در اجزای موجود نیاز نداشت و ثبت عامل تنها با یک دستور ساده‌ی curl انجام شد. شبکه بدون هیچ بازنشری، از ۲ عامل به ۳ عامل گسترش یافت.
با این حال، رسیدن به عملکرد کاملِ سرتاسری حدود ۶.۵ ساعت زمان برد. این فاصله نه به دلیل پروتکل، بلکه به دلیل باگ‌های پیشین بود که گره جدید آن‌ها را آشکار کرد؛ مواردی مثل:
- یک URL اشتباه در فایل .env.
- یک بازسازی (Refactoring) در MCP که به‌طور بی‌صدا اتصال FastMCP بین نمونه (Instance) و هندلر را شکسته بود.
- بازگشت باگ «مسدود شدن حلقه رویداد Uvicorn توسط فراخوانی‌های همزمان LLM»، که باعث شد Pinger دوباره شروع به حذف ثبت عامل اصلی کند.
برای جلوگیری از تکرار این اتفاق، اصلاحات در کلاس پایه SDK در حال اعمال است. لحظه تعیین‌کننده در ساعت ۲۳:۱۹ رخ داد؛ وقتی پرسش «در ماه جولای چقدر فروش داشتیم؟» پاسخ دقیق «۳,۲۵۹.۷۰ دلار» را از پایگاه‌داده بازگرداند. این یعنی افزودن یک گره چنان عملیات پاکی است که می‌تواند به عنوان بهترین تست ادغام برای سایر اجزای محیطی عمل کند.
دفاع رمزنگاری‌شده در برابر کدهای AI
این پروتکل با یک تست امنیتی غیرمنتظره مواجه شد؛ زمانی که یک دستیار کدنویسی AI به نام Antigravity سعی کرد یکی از عامل‌ها را تغییر دهد. کد تولیدشده توسط AI تلاش کرد با دو روش، حفاظ‌های امنیتی را دور بزند. ابتدا سعی کرد فراخوانی را با پارامترهای خودش بسازد، نه پارامترهایی که توسط درگاه در «توکن اجرای تفویض‌شده» (DET) امضا شده بودند.
از آنجا که DET به‌صورت رمزنگاری‌شده اجرا می‌شود، سیستم بلافاصله درخواست را رد کرد. این قفل پارامترها یک قرارداد ساده نیست، بلکه یک الزام رمزنگاری است؛ اگر داده‌های مجاز با امضای توکن مطابقت نداشته باشند، فراخوانی تحت هیچ شرایطی اجرا نمی‌شود.
وقتی عامل سعی کرد یک نقطه انتهایی جایگزین برای دور زدن درگاه بسازد، سیستم خطای ۴۰۴ داد. لاگ‌ها نشان می‌دهند که عامل سعی کرد یک فراخوانی جایگزین به آدرس http://host.docker.internal:8003/mcp با استفاده از متد JSON-RPC انجام دهد. این تلاش شکست خورد زیرا فراخوانی‌های P2P بدون وضعیت (Stateless) هستند و فاقد نشست SSE بودند که نقطه انتهایی بداهه شده توسط AI درخواست می‌کرد.
ثبات امنیتی و تحلیل لاگ‌ها
لاگ‌های دست‌نخورده این حادثه، تاب‌آوری پروتکل را به رخ می‌کشد:
- فراخوانی اولیه: متد
guardar_contactoاز طریق/toolsخطای ۵۰۰ بازگرداند («برای ایجاد مخاطب حداقل به یک فیلد نیاز است»). - فراخوانی جایگزین: تلاش برای دسترسی به نقطه انتهایی
/mcpبا خطای ۴۰۴ مواجه شد («نشست یافت نشد»).
این اتفاق در واقع یک تست نفوذ ناخواسته بود که ادعای مقاله سفید (Whitepaper) درباره غیرممکن بودن تغییر داده‌های مجاز توسط DET را به‌صورت تجربی ثابت کرد. این تایید می‌کند که با افزایش کدهایی که توسط AI نوشته می‌شوند، کنترل‌ها باید در ارث‌بری کلاس‌های پایه SDK نهادینه شوند، نه در مستندات. «امنیت پیش‌فرض» اکنون یک الزام برای بقای سیستم است.
حذف وابستگی‌ها و افزونگی
در جریان بهینه‌سازی، توسعه‌دهنده یک اصلاحیه قدیمی را که از جداول سخت‌افزاری KNOWN_MCP_SCHEMAS به عنوان پشتیبان در عامل استفاده می‌کرد، حذف کرد. این مورد به عنوان «وابستگی در لباس مبدل» شناسایی شد، زیرا عامل‌ها را مجبور می‌کرد طرح‌های ابزار را از پیش بشناسند.
عاملی که نیاز به دانش پیشین از طرح‌ها دارد، در واقع در حال کشف قابلیت‌ها نیست، بلکه شبکه در آن سخت‌افزاری شده است. این بدان معناست که هر ابزار جدید مستلزم تغییر در تمام عامل‌هاست که هزینه نهایی توسعه را افزایش می‌دهد.
در الگوی اصلاح‌شده‌ی IRC-A، عامل نسبت به پارامترها نادان می‌ماند. ساختار BFA (Broker/Forwarder/Agent) آدرس URL را همراه با پارامترهای کامل و DET امضا شده بازمی‌گرداند. عامل فراخواننده صرفاً «قصد» (Intent) و «توکن» را منتقل می‌کند. این ساختار باعث می‌شود عامل هیچ چیزی را نداند که درگاه پیش‌تر می‌داند و افزونگی را که در لباس استحکام ظاهر شده بود، حذف کند.
تله‌متری عملیاتی و هزینه‌ها
داده‌های LangSmith نشان می‌دهد که این رویکرد غیرمتمرکز از نظر اقتصادی توجیه‌پذیر است. در ۳۳۳ اجرای مختلف، نرخ خطای سیستم ۰٪ بود. جزئیات عملیاتی به شرح زیر است:
- تأخیر: میانگین ۱.۰۴ ثانیه برای هر فراخوانی LLM (با p99 حدود ۲.۹ ثانیه).
- مصرف توکن: مجموعاً ۷۹,۲۶۳ توکن.
- هزینه کل: ۰.۰۴ دلار برای کل تاریخچه تست.
- گران‌ترین فراخوانی: گزارش کامل وضعیت خط لوله با ۵,۴۶۲ توکن که ۰.۰۰۲۵ دلار هزینه داشت و ۳.۹۳ ثانیه زمان برد.
این اعداد ثابت می‌کند که یک شبکه چندعاملی با کشف معنایی مبتنی بر بردار و امضای رمزنگاری‌شده، برای هر پرسش کاربر بین ۰.۰۰۰۱ تا ۰.۰۰۲۵ دلار هزینه دارد که در مقایسه با هزینه LLM ناچیز است. این بهینگی در هزینه‌ها تضاد جالبی با برخی تجربه‌های شکست‌خورده در کسب‌وکارهای خودکار دارد که علی‌رغم اتوماسیون، نتوانستند به درآمدزایی برسند.
قابلیت‌های گفتگویی و چشم‌انداز
این معماری اجازه گفتگوهای پیچیده و چندمرحله‌ای را می‌دهد. در یک جلسه در ساعت ۱:۵۳ بامداد، سیستم توانست زمینه را در چندین نوبت حفظ کند؛ ابتدا به سوال «مجموع مبالغ پارک شده در مرحله Proposal چقدر است؟» پاسخ داد (۳,۱۳۴.۹۰ دلار) و سپس در نوبت بعد، عبارت «و در prospecting؟» را تحلیل کرد تا ۱۰ فرصت باز را با احتمالات بسته شدن و تاریخ‌های مربوطه تفکیک کند.
جالب اینجاست که این تعاملات به زبان اسپانیایی رخ داد، در حالی که CRM از عبارات انگلیسی (Enums) استفاده می‌کرد. کشف اینکه کلمه «prospección» با «Prospecting» مطابقت ندارد، به عنوان یک مشکل در Promptهای Few-shot شناسایی شد، نه یک نقص معماری.
با ۱۲ حادثه ثبت‌شده که هیچ‌کدام به پروتکل مربوط نبود، این سیستم از یک شمارنده ساده به یک موتور آمار تجاری تبدیل شده است. موارد باقی‌مانده در نقشه راه عبارتند از:
- پیاده‌سازی آستانه‌ی شباهت قابل تنظیم در
/discover. - توسعه تله‌متری بومی برای حذف وابستگی به پلتفرم‌های خارجی. این موضوع برای جلوگیری از ریسک‌های موجود در لایه‌های رایگان AI و نبود حسابرسی دقیق توکن حیاتی است.
- افزودن Few-shots برای واژگان CRM.
- اجباری کردن حالت Async-by-default در کلاس‌های پایه.
- رفع باگ ریشه‌ای سریال‌سازی
input_schemaدر درگاه.
برای توسعه‌دهندگان، این تغییر به این معناست که محدودیت‌های امنیتی و معماری دیگر نمی‌توانند در مستندات زندگی کنند؛ آن‌ها باید در کلاس‌های پایه SDK گنجانده شوند تا از نقض ثبات سیستم توسط کدهای تولید شده توسط AI جلوگیری شود.
گام بعدی شما
- بررسی نحوه پیاده‌سازی توکن‌های امضا شده (DET) برای جلوگیری از دستکاری پارامترها توسط AI.
- جایگزینی جداول سخت‌افزاری (Hardcoded) با مکانیزم‌های کشف پویا در سیستم‌های عامل‌محور. این رویکرد می‌تواند از شکست‌های زیرساختی در پرداخت‌های عامل‌های AI که به دلیل صلب بودن جریان‌ها رخ می‌دهد، پیشگیری کند.
- تحلیل هزینه استنتاج در مقیاس بالا با استفاده از تله‌متری‌های مشابه LangSmith.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو