۵ قانون قراردادی برای جلوگیری از شکست سامانه‌های چندعاملی در مقیاس واقعی

اگر امروز در حال استقرار یک سامانه هوش مصنوعی چند-عاملی هستید، بزرگ‌ترین ریسک شما قدرت استدلال مدل نیست، بلکه شکاف میان عامل‌هاست. طبق یک راهنمای فنی از دکتر سامسون تانیمائو (Dr. Samson Tanimawo)، بنیان‌گذار و مدیرعامل Nova AI Ops، اکثر شکست‌های عملیاتی دقیقاً در نقطه «دست‌به‌دست» رخ می‌دهند؛ یعنی جایی که یک عامل وظیفه‌ای را به عامل دیگر می‌سپارد.

مسئله‌ی «درز»

تصور کنید در یک مسابقه دو امدادی هستید، اما دونده‌ها روی نحوه گرفتن چوب امداد توافق ندارند. در دنیای هوش مصنوعی، این اتفاق زمانی می‌افتد که عامل‌ها به‌جای داده‌های ساختاریافته، از چت‌های متنی آزاد استفاده می‌کنند. وقتی فقط یک عامل دارید، موضوع دست‌به‌دست مطرح نیست. با دو عامل، به یک فرمت نیاز دارید. اما وقتی تعداد عامل‌ها به ۱۰ می‌رسد، خودِ این فرمت تبدیل به محصول اصلی می‌شود.

تانیمائو مشاهده کرده تیم‌ها دموهای خیره‌کننده‌ای می‌سازند که در آن هر عامل به‌تنهایی دقیق و تیز است، اما کل سامانه در محیط عملیاتی شکست می‌خورد. این شکست تقریباً همیشه در «درز» یا همان نقطه اتصال رخ می‌دهد، چون هیچ‌کس مستند نکرده که یک عامل مجاز است چه چیزی را به دیگری تحویل دهد.

در حالی که یک دموی دو-عاملی ممکن است بسیار صیقل‌خورده و عالی به نظر برسد، یک سیستم ۱۰-عاملی بدون رابط‌های سخت‌گیرانه، تبدیل به یک «مزرعه باگِ سیستم‌های توزیع‌شده» می‌شود. برای حل این مشکل، تانیمائو مفهوم «قرارداد دست‌به‌دست» (Handoff Contract) را پیشنهاد می‌کند: یک رابط صریح، تایپ‌شده و مستند. یک قرارداد مقاوم باید شامل ۵ عنصر مشخص باشد:

جزئیات قرارداد دست‌به‌دست

• طرح‌واره (Schema): یک شیء تایپ‌شده با فیلدهای نام‌گذاری شده. این باید یک رکورد ساختاریافته باشد، نه یک پیام چت یا متن آزاد.
• دامنه (Scope): تعریف دقیق از آنچه آرتیفکت (خروجی) نمایندگی می‌کند. برای مثال، خروجی یک عامل بررسی باید علت ریشه پیشنهادی و شواهد را شناسایی کند، اما نباید مشخص کند که در مورد آن چه کاری انجام شود؛ چرا که این وظیفه عامل دیگری است.
• سیگنال‌های اطمینان (Confidence Signals): یک مقدار عددی (مثلاً ۰.۷۴) برای تعیین مسیر؛ اگر اطمینان بالا بود، فرآیند پیشروی خودکار (Auto-progression) فعال می‌شود و اگر اطمینان پایین بود، بررسی انسانی (Human check) لازم است.
• منشأ (Provenance): لاگی از ورودی‌ها، منابع داده و ابزارهایی که فرستنده استفاده کرده است تا هم گیرنده و هم انسان‌ها بتوانند فرآیند را بازرسی و حسابرسی کنند.
• مسیر جایگزین (Fallback Path): یک مقصد تعیین‌شده، مانند یک صف انسانی، مسیر تصاعدی (Escalation) یا یک صف پیام‌های شکست‌خورده (Dead-letter queue)، برای زمانی که گیرنده نمی‌تواند دست‌به‌دست را پردازش کند.

یک مثال عینی

برای مثال، یک عامل همبستگی (Correlation Agent) ممکن است یک شیء JSON را به یک عامل بررسی (Investigation Agent) ارسال کند که شامل موارد زیر باشد:

• incident_id: "inc-2026-04-17-0042"
• signal_types: ["metric", "log", "trace"]
• services: ["checkout-api", "payment-client"]
• time_window: شروع "۲۰۲۶-۰۴-۱۷T۲۳:۰۳:۰۰Z" با مدت ۲۴۰ ثانیه
• alert_count: ۸۴
• primary_hypothesis: "recent_deploy"
• evidence_refs: ["deploy:prod-2026-04-17-2247", "trace:abc123..."]
• confidence: ۰.۷۴
• fallback: "escalate_to_oncall_if_not_progressed_within_300s"

این ساختار به گیرنده اجازه می‌دهد با دست‌به‌دست به عنوان «داده» برخورد کند، نه «گفتگو»، و بدین ترتیب هرگونه ابهام حذف می‌شود.

مقیاس‌بندی شبکه عامل‌ها (Agent Mesh)

مقیاس‌بندی این سیستم‌ها نیازمند چهار قانون عملیاتی است. اول، دست‌به‌دست‌ها باید به‌طور پیش‌فرض یک‌طرفه باشند؛ یعنی عامل B نباید وظیفه را به عامل A برگرداند، مگر اینکه یک قرارداد بازگشت مستند وجود داشته باشد؛ این کار از ایجاد حلقه‌های تکراری (Loops) جلوگیری می‌کند. دوم، این تبادلات باید «تکرارپذیر» (Idempotent) باشند؛ به این معنا که گیرنده بتواند یک دست‌به‌دست یکسان را دوبار پردازش کند، زیرا شبکه‌ها غیرقابل‌اعتمادند و عامل‌ها ممکن است تلاش مجدد (Retry) کنند.

سوم، هر تبادل باید یک رویداد قابل‌مشاهده (Observable Event) تولید کند — در واقع یک API Log برای شبکه عامل‌ها — تا انسان‌ها بتوانند بدون نیاز به خواندن وضعیت‌های داخلی عامل‌ها، کل مسیر را بازرسی کنند. در نهایت، طرح‌واره‌ها باید نسخه‌بندی شوند تا عامل‌هایی که نسخه‌های متفاوتی دارند، بتوانند روی فرمت‌های سازگار توافق کنند یا در صورت ناسازگاری، آن‌ها را رد کنند.

اجتناب از اشتباهات رایج

تیم‌ها اغلب با «بیش‌بار کردن» آرتیفکت شکست می‌خورند؛ یعنی قرار دادن هر فیلد احتمالی در خروجی «فقط برای احتیاط»، که این کار باعث گیج شدن عامل گیرنده می‌شود. برخی دیگر مسیر جایگزین (Fallback) را حذف می‌کنند و همین باعث می‌شود وقتی یک گیرنده شکست می‌خورد، حوادث و درخواست‌ها به‌کل ناپدید شوند. همچنین، بسیاری به اشتباه تصور می‌کنند که یک دموی تمیز دو-عاملی به‌راحتی به یک سیستم بزرگتر تعمیم می‌یابد.

این تغییر رویکرد، تمرکز بنیادین مهندسی عامل‌ها را دگرگون می‌کند. توسعه‌دهندگان باید وسواس روی پرامپت‌های مدل‌های تک‌نفره را کنار بگذارند و روی «درزها» تمرکز کنند. هدف این است که از مجموعه‌ای از عامل‌های تیز و سریع، به یک شبکه صنعتی قابل‌اعتماد و استوار حرکت کنیم.

برای پیاده‌سازی این روش، ابتدا تمام انتقال‌های عامل-به-عامل در گردش‌کار فعلی خود را ترسیم کنید. نقاطی را که در آن‌ها به «امید» این هستید که عامل بعدی خروجی قبلی را بفهمد، شناسایی کنید و این شکاف‌ها را با یک طرح‌واره تایپ‌شده (Typed Schema) جایگزین کنید.