درون معماری مسیریاب قطعی؛ روشی برای افزایش دقت و کاهش هزینه‌های عملیاتی

تصور کنید برای هر تکلیفی که به کارمندانتان می‌دهید، ابتدا باید به یک مدیر بگویید تا او تکلیف را تحلیل کند و سپس به کارمند بسپارد؛ و در نهایت، دوباره همان مدیر نتیجه را بررسی کند. اگر این مدیر، بخشی از دستورالعمل‌های اولیه را فراموش کند، کل پروژه با یک اشتباه کوچک به فنا می‌رود.

به گزارش dev.to در ۶ جولای ۲۰۲۶، استقرار عملیاتی یک تیم ۵-عاملی نشان داد که عامل‌های «مدیر» (Manager Agents) اغلب نقطه شکست اصلی در سامانه‌ها هستند. در این آزمایش ۳۰ روزه، تیم مهندسی دریافت که تکیه بر یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برای تفویض وظایف، گلوگاهی بحرانی برای هزینه‌ها و حافظه زمینه ایجاد می‌کند.

بسیاری از آموزش‌های عامل‌های هوش مصنوعی بر دموهای ساده‌ای تمرکز دارند که در آن‌ها یک عامل در یک نوت‌بوک، عامل دیگری را فراخوانی می‌کند و وقتی نتیجه چاپ می‌شود، همه تشویق می‌کنند. اما در محیط واقعی تولید، این ساختارها زیر بار هزینه توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های یک کیک که مدل می‌خورد — و «تأییدهای توهم‌آلود» (Hallucinated Success Signals) فرو می‌ریزند. این چالش‌ها تأیید می‌کند که صرفاً ارتقای مدل‌ها راهکار قطعی نیست و به همین دلیل است که حتی مدل‌های قدرتمندتر هم همیشه نمی‌توانند نقص‌های ساختاری عامل‌های هوش مصنوعی را پوشش دهند. همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، انتقال از طراحی سلسله‌مراتبی و مدیر-محور به معماری تخت و قطعی (Deterministic)، اکنون برای هر تیمی که قصد خروج از مرحله پروتوتایپ را دارد، ضروری است.

شکست عامل مدیر

طراحی اولیه از یک عامل مدیر برای مسیریابی و توزیع تمامی وظایف بین چهار عامل کارگر استفاده می‌کرد. طبق مستندات این تیم، این مدل یک «نقطه شکست واحد» (Single Point of Failure) ایجاد کرد. از آنجا که هر وظیفه دو بار از مسیر مدیر عبور می‌کرد — یک بار برای برنامه‌ریزی و یک بار برای بازبینی — سیستم به‌جای انجام کار واقعی، توکن‌های خود را صرف هزینه‌های اداری و سربارهای مدیریتی می‌کرد.

علاوه بر هزینه، عامل مدیر از مشکل سرریز پنجره زمینه (Context Window) — یعنی میزان متنی که مدل شبیه به یک میز کار کوچک در ذهن نگه می‌دارد — رنج می‌برد. با پیشرفت کارهای طولانی، مدیر شروع به فراموش کردن نیمی از جزئیات اولیه وظیفه می‌کرد. این مسئله منجر به خطاهای زنجیره‌ای شد، به‌طوری که هر چهار عامل کارگر، همان اشتباه اولیه مدیر را به ارث می‌بردند. تیم به این نتیجه رسید که مسیریابی در واقع یک مسئله منطقی است (مانند یک دستور if ساده در کد) و نه یک مسئله استدلالی پیچیده که نیاز به یک مدل LLM گران‌قیمت داشته باشد.

درس کلیدی: یک عامل مدیر برابر است با یک نقطه تمرکز برای هزینه، شکست و سرریز حافظه. این ساختار ریسک را دقیقاً در جایی متمرکز می‌کند که سیستم کمترین توان تحمل آن را دارد.

ساختار تختِ نجات‌بخش

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

خط لوله ۵-عاملی بازمانده از این تغییرات، شامل نقش‌های محدود و تخصصی زیر است:

• Intake (دریافت‌کننده): درخواست‌های ورودی را به یک وظیفه ساختاریافته در قالب JSON تبدیل می‌کند. تمرکز این نقش تنها بر شکل داده است و نه استدلال.
• Planner (برنامه‌ریز): وظیفه را به یک لیست مرتب از گام‌ها تبدیل می‌کند. این نقش فقط برای کارهای چندمرحله‌ای اجرا می‌شود؛ وظایف تک‌مرحله‌ای به‌طور کامل از این گام عبور می‌کنند.
• Executor (مجری): تنها عاملی است که اجازه دسترسی به سیستم‌های خارجی و فراخوانی ابزارها (Tool Calls) را دارد.
• Verifier (تأییدکننده): خروجی مجری را به‌صورت مستقل در برابر وظیفه اولیه بررسی می‌کند. این نقش برای تضمین دقت حیاتی است.
• Scribe (نویسنده): نتیجه نهایی ساختاریافته را به همراه یک خلاصه قابل فهم برای انسان تدوین می‌کند.

حل معمای «پاسخ غلطِ مطمئن»

تیم خطرناک‌ترین نوع شکست را «تیک سبز» (Green Checkmark) نامید؛ وضعیتی که در آن یک عامل با وجود تولید نتیجه‌ای کاملاً غلط، گزارش موفقیت می‌دهد. در هفته اول، دو بار اتفاق افتاد که مجری وظیفه را اشتباه انجام داد اما آن را «تکمیل‌شده» علامت زد. بدون وجود یک سیستم خطا یا استثنا (Exception)، این داده‌های 쓰레غی مستقیم به مراحل پایین‌دست جریان می‌یافتند.

برای مقابله با این موضوع، قانونی سخت‌گیرانه وضع شد: تأییدکننده باید کاملاً مستقل از مجری باشد. این بدان معناست که تأییدکننده باید از پرامپت متفاوتی استفاده کند و در هر کجا که ممکن است، به‌جای تکیه بر نظر دوم یک LLM، از یک بررسی قطعی (Deterministic Check) استفاده نماید.

مکانیزم‌های تأیید شامل این موارد است:

• مقایسه خروجی با داده‌های مرجع (Ground Truth) یا نمونه‌های صحیح.
• اجرای مجدد یک محاسبه خاص با استفاده از کد برنامه‌نویسی ساده.
• اعتبارسنجی خروجی بر اساس یک Schema دقیق و سخت‌گیرانه JSON.

این کار تضمین می‌کند که عامل «برگه امتحانی خودش را تصحیح نکند»، زیرا گزارش اشاره می‌کند که تصحیح توسط خود عامل هیچ خطایی را شکار نمی‌کند. عبارت‌های کلی مثل «به نظر من درست است» (Looks good to me) تأیید محسوب نمی‌شود؛ بلکه تنها خروجی ساختاریافته به همراه بررسی مستقل است که ارزش دارد.

مدیریت هزینه حلقه‌های تکرار

شوک‌های مالی زمانی رخ داد که صورت‌حساب ماه اول تقریباً ۴ برابر تخمین‌های اولیه شد. مقصر اصلی قیمت پایه مدل نبود، بلکه «حلقه‌های تکرار» (Retry Loops) خارج از کنترل بودند. وقتی عاملی با یک خطای گذرا (Transient Failure) مواجه می‌شد، دوباره تلاش می‌کرد، باز هم شکست می‌خورد و این چرخه بدون هیچ سقفی ادامه می‌یافت. یک وظیفه که در حلقه گیر کرده بود، شبانه صدها استنتاج (Inference) گران‌قیمت را به‌طور بی‌صدا اجرا کرد.

برای توقف این روند، دو safeguard یا حفاظ حیاتی پیاده شد:

• عقب‌نشینی نمایی (Exponential Backoff): جلوگیری از تکرارهای سریع و متوالی برای مدیریت بهینه خطاهای گذرا.
• بودجه‌های سخت توکن (Hard Token Budgets): تعیین یک سقف هزینه حداکثری برای هر وظیفه. اگر این سقف لمس شود، وظیفه به‌جای اینکه تا ابد به پردازش ادامه دهد، با یک خطای واضح متوقف (Fail Loudly) می‌شود.

به باور این تیم، یک وظیفه شکست‌خورده ارزان است، اما یک وظیفه در حلقه بی‌نهایت، یک بدهی مالی است. کنترل هزینه باید یک نیازمندی طراحی باشد، نه صرفاً داشبوردی که بعد از رسیدن صورت‌حساب بررسی شود.

اصول نهایی استقرار

تجربه ۳۰ روزه این تیم به مجموعه‌ای از قوانین غیرقابل‌تغییر منجر شد. آن‌ها متن‌های آزاد (Free-form text) بین عامل‌ها را حذف کردند، زیرا هر انتقال داده فرصتی برای برداشت اشتباه بود. به‌جای آن، از JSON Schema برای هر پیام بین‌عاملی استفاده کردند: یا داده ساختاریافته است یا ارسال نمی‌شود.

همچنین ردگیری گام‌به‌گام (Step-level execution traces) اجباری شد. وقتی سیستم می‌شکست، پیام کلی «تیم شکست خورد» هیچ اطلاعاتی نمی‌داد. اما ردگیری‌های دقیق هر گام، جلسات سه ساعته عیب‌یابی را به سه دقیقه کاهش داد؛ ابزاری که برای عیب‌یابی‌های ساعت ۲ صبح یک ضرورت است.

خلاصه ساختار برنده:

• عامل‌های تخصصی و محدود به‌جای یک «عامل خدا» (God-agent).
• مسیریاب کدبنیان قطعی به‌جای مدیر LLM.
• تأیید مستقل برای هر وظیفه.
• سقف‌های هزینه (محدودیت تکرار و بودجه توکن) که از روز اول در سیستم تعبیه شده‌اند.

در نهایت، این تیم اجزای مسیریاب، حلقه تأیید، بودجه‌ها و ردگیری‌ها را در سیستمی به نام one-team بسته‌بندی کردند. نتیجه نهایی این است که مدل سخت‌ترین بخش کار نبود؛ بلکه «چارت سازمانی» (Org Chart) عامل‌ها بود. LLM تنها یک قطعه است و مهندسی واقعی در هارنس (Harness) یا همان چارچوبی است که اطراف آن قرار دارد.

گام بعدی شما

• اگر از عامل‌های مدیر در پروژه‌های خود استفاده می‌کنید، مسیرهای تصمیم‌گیری را به توابع if/else ساده در کد منتقل کنید.
• برای هر عامل مجری، یک عامل تأییدکننده (Verifier) با پرامپت متفاوت تعریف کنید تا از «خود-تصحیح‌گری» جلوگیری شود.
• حتماً برای هر درخواست، یک Max_Token_Budget تعریف کنید تا از شوک‌های مالی ناشی از حلقه‌های تکرار جلوگیری کنید.

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