اگر امروز قصد دارید یک ارتش از عامل‌های هوش مصنوعی را برای مدیریت کسب‌وکارتان به کار بگیرید، احتمالاً با سقف سخت‌گیرانه‌ای از خطاهای زنجیره‌ای و هزینه‌های نجومی توکن‌ها مواجه شده‌اید. مشکل این است که اکثر شرکت‌ها هنوز با عامل‌ها مثل مدل‌های زبانی تک‌بعدی رفتار می‌کنند و نه یک زیرساخت مهندسی‌شده. این چالش با واقعیت‌های فعلی بازار همسو است، چرا که برخی پژوهش‌ها نشان می‌دهند بخش بزرگی از عامل‌های سازمانی در حال حاضر صرفاً پوششی برای چت‌بات‌های ساده هستند.
طبق گزارشی فنی در تاریخ ۲۱ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، توسعه‌دهندگان پروتکل IRC-A یک تفکیک ساختاری حیاتی را معرفی کرده‌اند: جداسازی هارنس (Harness) — که تعیین می‌کند «چه چیزی و چرا» باید اجرا شود — از IRC-A که مسئول «چگونه» انتقال و اجراست. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، وابستگی شدید مدل به محیط اجرا همیشه یک نقطه ضعف امنیتی بوده است.
در حال حاضر، بسیاری از سازمان‌ها عامل‌ها را صرفاً به عنوان یک مدل زبانی بزرگ (LLM) — شبیه کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — می‌بینند که دورادور آن چند دستور ساده نوشته شده است. این ساختار باعث می‌شود عامل‌ها نتوانند بدون دخالت مداوم انسان، گردش‌های کاری پیچیده را پیش ببرند. راهکار جدید، انتقال به لایه‌های پشتیبانی ماژولار است تا هوش مدل از محیط اجرای آن جدا شود.
هارنس عملیاتی
هارنس در واقع لایه مفهومی سطح بالاست که قوانین تجاری، پایگاه‌های داده و ابزارهای سفارشی را در اختیار مدل قرار می‌دهد. این لایه بر سه رکن متمرکز است:
- مدیریت وضعیت و حافظه: برای حفظ زمینه در تعاملات طولانی و چندمرحله‌ای.
- حفاظ‌ها (Guardrails) و سیاست‌ها: تعریف مرزهای سخت برای جلوگیری از توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد — و تضمین امنیت.
- ارکستراسیون ابزارها و APIها: کنترل دقیق زمان و نحوه اجرای کد یا پرس‌وجوی پایگاه داده توسط مدل.
پروتکل شبکه IRC-A
در حالی که هارنس قوانین را دیکته می‌کند، IRC-A (چت رله اینترنتی برای عامل‌ها) به عنوان لایه مهندسی شبکه عمل می‌کند. این پروتکل نحوه اجرای اتصالات را تعریف می‌کند تا مصرف توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — کاهش یابد و امنیت محیط ارتقا پیدا کند. این رویکرد در راستای رقابت‌های جاری برای تسلط بر لایه کنترلی عامل‌ها و استانداردسازی مدیریت آن‌ها قرار دارد.
به نقل از مستندات این پروتکل، برخلاف روش‌های سنتی که بر گراف‌های اجرای استاتیک و صلب (مثل DAGها) تکیه داشتند، IRC-A از مدلی غیرمتمرکز الهام گرفته است. در این سیستم، میکرو-عامل‌ها و رابط‌هایی مانند FastMCP به عنوان گره‌های مستقل عمل می‌کنند و از طریق درخواست‌های سبک HTTP به‌صورت پویا یکدیگر را پیدا می‌کنند.
مکانیسم‌های امنیت و اجرا
امنیت در این معماری از طریق توکن‌های اجرای تفویض‌شده (DET) مدیریت می‌شود. این توکن‌ها امضاهای رمزنگاری‌شده‌ای موقت هستند (مانند JWTها) که در عرض چند ثانیه منقضی می‌شوند.
به گزارش توسعه‌دهندگان، این مکانیسم‌ها اهداف فنی دقیقی را دنبال می‌کنند:
- اعتبارسنجی آفلاین: گره دریافت‌کننده درخواست را محلی تأیید می‌کند و نیاز به مراجعه به یک گیت‌وی مرکزی را از بین می‌برد تا گلوگاه شبکه حذف شود.
- مهار حلقه‌ها: پنجره کوتاه انقضا باعث می‌شود حلقه‌های بازگشتی و نشت دسترسی در حملات تزریق پرامپت (Prompt Injection) فوراً متوقف شوند.
- مقیاس‌پذیری: حذف گلوگاه مرکزی، امکان اجرای سیستم‌های عظیم با تأخیر بسیار کم را فراهم می‌کند.
این چرخش معماری به معنای گذار از خط‌لوله‌های صلب به «استخر قابلیت‌ها» است. با جداسازی لایه امنیتی از SDK، سیستم‌ها می‌توانند با هزینه توکن کمتر و سرعت بیشتر مقیاس‌بندی شوند. برای توسعه‌دهندگان، اولویت از «چگونه پرامپت بنویسم» به «چگونه شبکه را برای کشف و امنیت ساختاردهی کنم» تغییر می‌کند.
جزئیات پیاده‌سازی فنی و کدهای منبع اکنون در مخزن bfa-sdk در گیت‌هاب (SandroG1977/bfa-sdk) در دسترس است.
گام بعدی شما
- مخزن bfa-sdk را بررسی کنید تا با نحوه پیاده‌سازی توکن‌های DET آشنا شوید.
- اگر از گراف‌های صلب برای مدیریت عامل‌ها استفاده می‌کنید، مدل توزیع‌شده IRC-A را برای کاهش تأخیر تست کنید.
- استراتژی مدیریت حافظه در لایه هارنس را با نیازهای تجاری سازمان خود تطبیق دهید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو