مهار هرج‌ومرج ایجنت‌های هوش مصنوعی: چطور جلوی اشتباهات زنجیره‌ای در سیستم‌های چندایجنتی را بگیریم؟

در سیستم‌های چندایجنتی، این امکان وجود دارد که تک‌تک ایجنت‌ها به تنهایی کارشان را درست انجام دهند، اما وقتی کنار هم قرار می‌گیرند خروجی نهایی کاملاً غلط از آب درآید! خروجی یک ایجنت تبدیل به کانتکست و زمینه کاری ایجنت بعدی می‌شود؛ در نتیجه ممکن است اطلاعات در حین دست‌به‌دست شدن گم شوند یا اشتباه تفسیر شوند، وضعیت مشترک دچار انحراف شود و ایجنت‌ها در لوپ‌های تکراری یا بن‌بست‌های بی‌پایان گیر بیفتند. حتی وقتی چند ایجنت به یک مدل پایه مشترک متکی باشند، ممکن است به جای اصلاح خطاهای یکدیگر، همان اشتباه را تأیید و تقویت کنند.

همین موضوع باعث می‌شود سیستم‌های چندایجنتی تفاوت بنیادی با برنامه‌های تک‌ایجنتی داشته باشند. ارزیابی جداگانه هر ایجنت به تنهایی، یا صرفاً نگاه کردن به جواب نهایی، اصلاً به ما نشان نمی‌دهد که آیا روند همکاری بین آنها درست کار کرده است یا نه.

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

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

چرا همکاری بین ایجنت‌ها حتماً به ارزیابی (Evals) نیاز دارد؟

مدل‌های زبانی بزرگ (LLM) ذاتاً غیرقطعی و احتمالاتی هستند. در یک سیستم چندایجنتی، این عدم قطعیت از بین نمی‌رود؛ یک ایجنت داده تولید می‌کند، ایجنت بعدی آن را می‌خواند و تفسیر می‌کند و خروجی آن مجدداً تبدیل به کانتکست ایجنت بعدی می‌شود. هرگونه تولید نادرست یا تفسیر اشتباه محتوا در طول مسیر گردش کار گسترش یافته و چندبرابر می‌شود.

ایجنت‌ها در عمل مدام در حال مصرف کانتکست یکدیگر هستند. ما می‌توانیم این فرآیند را درست مثل یک سیستم تولید مبتنی بر بازیابی اطلاعات (RAG) ارزیابی کنیم. تعاملات بین ایجنت‌ها نیز می‌تواند دقیقاً از همان اصول و متدولوژی پیروی کند.

یک خط لوله معمولی RAG را می‌توان به این شکل تفکیک کرد:

پرسش کاربر ← موتور بازیابی ← کانتکست بازیابی‌شده (ارزیابی) ← تولید پاسخ ← پاسخ نهایی (ارزیابی)

ما در سیستم‌های RAG، بازیابی محتوا و تولید پاسخ را به صورت جداگانه ارزیابی می‌کنیم تا مشخص شود آیا ریشه مشکل در بازیابی داده بوده، یا کیفیت کانتکست ایراد داشته، یا بخش تولید پاسخ خطا کرده است.

یک سیستم چندایجنتی همین ایده را گسترش می‌دهد:

پرسش کاربر ← ایجنت A ← تحویل داده‌ها (Handoff) ← ایجنت B ← وضعیت مشترک (Shared State) ← ایجنت C ← اعتبارسنجی ← خروجی نهایی

بررسی صرفِ پاسخ نهایی — یا حتی ارزیابی مستقل هر ایجنت به تنهایی — به ما نمی‌گوید که آیا فرآیند همکاری واقعاً درست کار کرده است یا نه. ما به شفافیت و دید کامل نسبت به آنچه میان ایجنت‌ها اتفاق می‌افتد نیاز داریم.

ردیابی کامل ردپای اجرای سیستم‌های چندایجنتی (Trace)

پیش از ارزیابی همکاری، ابتدا باید بتوانیم کل جریان گردش کار را به طور کامل مشاهده کنیم. همان‌طور که ابزار‌هایی مانند LangSmith می‌توانند پرامپت‌ها، اسناد بازیابی‌شده، فراخوانی ابزار‌ها و پاسخ‌های مدل را برای یک برنامه RAG ثبت و ضبط کنند، ردیابی سیستم‌های چندایجنتی نیز باید موارد زیر را پوشش دهد:

• کدام ایجنت‌ها و با چه ترتیبی فراخوانی شدند

• ورودی‌ها و خروجی‌های دقیق هر ایجنت

• داده‌های ردوبدل‌شده در زمان تحویل بین ایجنت‌ها (Handoff Payloads)

• تصمیمات مربوط به مسیریابی و ارجاع وظایف

• خواندن و به‌روزرسانی‌های انجام‌شده روی وضعیت مشترک

• فراخوانی ابزار‌ها و نتایج بازگشتی آنها

• تلاش‌های مجدد (Retries)، حلقه‌ها و تصمیمات پایان کار

• میزان تأخیر زمانی، توکن‌های مصرفی و هزینه در هر مرحله

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

ارزیابی بن‌بست‌ها و لوپ‌های بی‌پایان در جریان کار

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

بن‌بست‌ها (Deadlocks) زمانی رخ می‌دهند که ایجنت‌ها دچار وابستگی دایره‌ای شوند. به عنوان مثال، ایجنت هماهنگ‌کننده منتظر بازگشت نتیجه از ایجنت کارگر می‌ماند، در حالی که ایجنت کارگر هم منتظر تأییدیه یا دستورات جدید از سوی هماهنگ‌کننده است. هیچ‌کدام نمی‌توانند جلو بروند و کل سیستم برای همیشه قفل می‌شود.

حلقه‌های بی‌پایان یا قفل‌های زنده (Livelocks) زمانی رخ می‌دهند که ایجنت‌ها مدام با هم تبادل داده دارند اما هیچ پیشرفتی حاصل نمی‌شود. مثلاً یک ایجنت دانش، درخواستی را برای رفع ابهام به ایجنت تراکنش پس می‌فرستد، در حالی که ایجنت تراکنش هم چون هنوز همان ابهام وجود دارد، دوباره آن را برمی‌گرداند. ایجنت‌ها به شدت مشغول فعالیت و مصرف منابع هستند، اما جریان کار هرگز به یک تصمیم، اقدام نهایی یا حالت پایانی نمی‌رسد.

این شکست‌ها ویژگی‌های گراف اجرا هستند و لزوماً به اشکال یک ایجنت منفرد مربوط نمی‌شوند. بنابراین ما ردپای اجرای گردش کار را با معیارهای زیر ارزیابی می‌کنیم:

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

ارزیابی دست‌به‌دست شدن اطلاعات بین ایجنت‌ها (Handoffs)

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

می‌توان هر فرآیند تحویل میان ایجنت‌ها را به چشم یک خط انتقال داده کوچک دید:

خروجی ایجنت A ← کانتکست منتقل‌شده به ایجنت B ← درک و تفسیر ایجنت B

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

ارزیابی انتقال کانتکست

اولین پرسش کلیدی این است: آیا اطلاعات صحیحی که توسط ایجنت بالادستی تولید شده، واقعاً به دست ایجنت پایین‌دستی می‌رسد یا خیر؟

پرسش‌های اساسی در این بخش عبارتند از:

• آیا تمام اطلاعات مرتبط از ایجنت A به ایجنت B منتقل شد؟

• آیا اطلاعات مهمی در طول این جابه‌جایی از بین رفت؟

• آیا اطلاعات اضافه و نامربوط در این انتقال گنجانده شد؟

• آیا کانتکست ارائه‌شده به ایجنت B، نیازهای او برای انجام تسک محوله را تأمین می‌کند؟

همان معیارهای کیفیت کانتکست که در RAG استفاده می‌شوند، در مرز تبادل میان ایجنت‌ها نیز قابل استفاده هستند:

ارزیابی درک و تفسیر ایجنت پایین‌دستی

انتقال کانتکست صحیح فقط نیمی از مسیر تحویل است. ما باید بدانیم آیا ایجنت پایین‌دستی داده‌های دریافتی را به درستی می‌فهمد و از آنها استفاده می‌کند یا خیر.

پرسش‌های رایج در این مرحله:

• آیا خروجی ایجنت B بر پایه اطلاعات دریافتی از ایجنت A استوار است؟

• آیا ایجنت B معنا و منظور اصلی نتیجه بالادستی را حفظ کرده است؟

• آیا ایجنت پایین‌دستی اطلاعاتی سرخود و بدون پشتوانه به موضوع اضافه کرده است؟

• آیا بر اساس داده‌های ارائه‌شده تصمیم درستی اتخاذ کرده است؟

اصول ارزیابی کیفیت تولید متن در RAG را می‌توان در اینجا نیز تطبیق داد:

معمولاً برای این ارزیابی‌های معنایی از سازوکار استفاده از مدل زبانی به عنوان داور (LLM-as-a-judge) بهره گرفته می‌شود که خروجی بالادستی، کانتکست دریافتی و نتیجه نهایی پایین‌دستی را با یکدیگر می‌سنجد.

ارزیابی یکپارچگی رابط‌ها (Interface Integrity)

همکاری ایجنت‌ها لایه ارزیابی دیگری را معرفی می‌کند که در خطوط لوله متداول RAG کم‌تر به آن توجه می‌شد: قرارداد رابط بین ایجنت‌ها.

تا جای ممکن، حتی در مواردی که با متن‌های طولانی سروکار داریم، ایجنت‌ها باید به جای پاسخ‌های متنی آزاد، خروجی‌های ساختاریافته ردوبدل کنند. استفاده از اسکیمای JSON، مدل‌های Pydantic یا قراردادهای داده‌ای مشخص، امکان اعتبارسنجی قطعی بخشی از فرآیند تحویل را پیش از اجرای ایجنت بعدی فراهم می‌کند.

معیارهای کلیدی در این زمینه:

به این ترتیب ما سه لایه مکمل برای ارزیابی انتقال اطلاعات به دست می‌آوریم:

خروجی ایجنت A ← کیفیت کانتکست ← یکپارچگی رابط ← تفسیر ایجنت B

معیارهای کانتکست نشان می‌دهند داده‌های درست منتقل شده‌اند یا نه؛ اعتبارسنجی رابط مشخص می‌کند آیا انتقال با ساختار صحیح انجام شده است؛ و معیارهای تولید تأیید می‌کنند که آیا ایجنت پایین‌دستی پیام را به درستی درک کرده و طبق آن عمل نموده است یا خیر.

ارزیابی وضعیت مشترک (Shared State)

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

به همین دلیل، ارزیابی وضعیت عملکردی شبیه به ایجاد یک ایست بازرسی (Checkpoint) دارد: مقایسه وضعیت قبل و بعد از اجرای هر ایجنت و اطمینان از حفظ دقیق اطلاعات کلیدی.

به عنوان مثال، وضعیت مشترک را در یک جریان پشتیبانی نرم‌افزاری ابری در نظر بگیرید:

{
  "customer_id": "C1024",
  "plan": "Enterprise",
  "issue": "duplicate_charge",
  "identity_verified": true,
  "refund_eligible": true,
  "refund reason": "توضیحات طولانی دلیل استرداد وجه"
}

راهکار اساسی، تعریف تابعی تحت عنوان «مدیر وضعیت» (State Manager) است که وضعیت به‌روزشده را از طریق دو دسته بررسی ارزیابی می‌کند:

بررسی‌های قطعی و قاعده‌محور: اعتبارسنجی مواردی که با قوانین مشخص کانوولوشن و کدهای برنامه‌نویسی قابل تست هستند:

• اعتبارسنجی اسکیما: آیا فیلدهای ضروری وجود دارند و نوع داده آنها درست است؟

• اعتبارسنجی فیلدهای تغییرناپذیر: آیا یک ایجنت به طور ناخواسته شناسه مشتری یا فیلدهای محافظت‌شده دیگر را دستکاری کرده است؟

• بررسی سازگاری: آیا مثلاً شرط refund_eligible = true با فیلدهای دیگر یا قوانین تجاری سیستم تضاد دارد؟

• بررسی تازگی داده‌ها: آیا ایجنت از اطلاعات تاریخ‌گذشته یا باطل‌شده استفاده می‌کند؟

• بررسی حجم کانتکست: آیا حجم گفتگو یا حافظه مشترک از آستانه تعریف‌شده عبور کرده است؟

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

• آیا فکت‌ها یا محدودیت‌های حیاتی از دست رفته‌اند؟

• آیا خلاصه‌سازی باعث دگرگونی معنای اصلی مکالمه شده است؟

• آیا اطلاعات بی‌اساس و اثبات‌نشده وارد وضعیت مشترک شده است؟

• آیا وضعیت جدید همچنان بیانگر درخواست اولیه کاربر است؟

• آیا انباشت داده‌های نامربوط تمرکز ایجنت‌های پایین‌دستی را به هم می‌زند؟

این فاکتورها را می‌توان با شاخص‌های کلیدی عملکرد (KPI) در سطح وضعیت سنجید:

• نرخ اعتبار وضعیت: درصد انتقال‌هایی که استانداردهای اسکیما و قوانین تجاری را رعایت می‌کنند

• نرخ سازگاری وضعیت: درصد انتقال‌های بدون تناقض در داده‌ها

• نرخ حفظ محدودیت‌ها: میزان بقای شروط و الزامات مهم در طول مراحل مختلف

• وفاداری خلاصه‌سازی: آیا نسخه فشرده‌شده، معنا و فکت‌های حیاتی کانتکست اصلی را حفظ کرده است؟

• نرخ وضعیت منسوخ: تناوب مصرف داده‌های قدیمی توسط ایجنت‌های پایین‌دستی

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

به این ترتیب مدیر وضعیت درست شبیه یک چک‌پوینت در خطوط انتقال داده عمل می‌کند:

وضعیت قبلی ← اجرای ایجنت ← وضعیت به‌روزشده ← ارزیابی وضعیت ← ایجنت بعدی

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

ارزیابی استدلال همبسته و خطر «تک‌کشت مدلی» (Model Monoculture)

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

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

• تنوع خروجی: آیا ایجنت‌ها برای یک تسک مشابه پاسخ‌های هم‌شکلی تولید می‌کنند؟ (با شباهت کسینوسی امبدینگ، BERTScore یا مدل زبانی در نقش داور)

• تنوع استدلال: آیا ایجنت‌ها مسیرهای منطقی متفاوتی را طی می‌کنند؟ (شباهت ردپای استدلال و فاصله ویرایش گراف)

• تنوع در استفاده از ابزار‌ها: آیا ایجنت‌ها از ابزار‌ها و فرآیندهای متفاوتی استفاده می‌کنند؟ (آنتروپی و توزیع فراخوانی ابزار‌ها)

• تنوع در بازیابی: آیا ایجنت‌ها به اسناد و شواهد متفاوتی استناد می‌کنند؟ (شباهت جاکارد و همپوشانی مستندات)

• تنوع تصمیم‌گیری: آیا ایجنت‌ها همیشه به تصمیم‌های یکسانی می‌رسند؟

• همبستگی خطاها: آیا ایجنت‌ها روی تسک‌های یکسان با هم شکست می‌خورند؟ (نرخ توافق در خطا و همبستگی جفتی خطاها)

• تنوع زاویه دید: آیا ایجنت‌ها مسئله را از زوایای گوناگون بررسی می‌کنند؟

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

از ارزیابی تا اعمال کنترل‌های مهندسی

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

مهندسی انتقال داده بین ایجنت‌ها: رابط‌های شفاف را با خروجی‌های ساختاریافته مانند اسکیمای JSON یا مدل‌های Pydantic تعریف کنید. فیلدهای الزامی، انواع داده و قوانین تجاری را پیش از تحویل نتیجه به ایجنت بعدی اعتبارسنجی کنید. در صورت رد اعتبارسنجی، سیستم می‌تواند داده را پس بزند، ایجنت بالادستی را برای بازتولید فراخوانی کند یا مسیر را به یک شاخه جایگزین هدایت نماید. این ساختار اجازه می‌دهد استدلال معنایی همچنان انعطاف‌پذیر بماند، اما رابط ارتباطی رفتاری کاملاً قطعی داشته باشد.

مهندسی هماهنگی گردش کار: لایه ارکستراسیون باید فراخوانی‌ها، تصمیمات مسیریابی، دفعات تحویل، تکرارها، زمان اجرا و حالت‌های پایانی را به طور دقیق دنبال کند. اینجاست که ارکستراسیون قطعی اهمیت پیدا می‌کند. فریم‌ورک‌هایی مانند LangGraph اجازه می‌دهند گردش‌های کاری به صورت گراف‌های دارای وضعیت با گره‌ها، یال‌ها، شاخه‌ها و چک‌پوینت‌های مشخص طراحی شوند. کنترل‌های مهندسی از قبیل سقف مجاز تکرار، مهلت زمانی (Timeout) و شروط خروج مشخص، مانع از افتادن سیستم در دام بن‌بست‌ها و لوپ‌های بی‌پایان می‌شوند و دیگر نیاز نیست برای توقف سیستم به تصمیم خود مدل زبانی تکیه کنیم. ردپای اجرا را می‌توان به کمک LangSmith ثبت کرد تا امکان بررسی روند پیشرفت کار و خطایابی فراهم شود.

مهندسی مدیریت وضعیت: وضعیت مشترک نباید به شکل نامحدود بین ایجنت‌ها جابه‌جا شود، بلکه باید توسط یک مدیر وضعیت اداره گردد:

اجرای ایجنت ← مدیر وضعیت ← به‌روزرسانی و هرس داده‌ها ← ایجنت بعدی

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

مهندسی در انتخاب مدل‌ها: اولین و مهم‌ترین اصل این است که برای تمام ایجنت‌ها از یک مدل پایه واحد استفاده نکنید. ایجنت‌های مختلف مسئولیت‌های گوناگونی دارند و نیازمندی‌های آنها از نظر قدرت استدلال، سرعت، هزینه و ضریب اطمینان با یکدیگر تفاوت دارد.

به عنوان مثال، یک سیستم پشتیبانی سازمانی می‌تواند از این ترکیب استفاده کند:

• ایجنت مسیریاب و تریاژ: مدلی سریع و کم‌هزینه برای دسته‌بندی و هدایت تیکت‌ها

• ایجنت دانش و RAG: مدلی با مهارت بالا در فهم متن و تولید پاسخ‌های مستند

• ایجنت تراکنش: مدلی با توان استدلال بالا‌تر برای تفسیر قوانین و تعیین مجاز بودن اقدام

• ایجنت بازبین: مدلی از یک خانواده مجزا برای کاهش نقاط کور فکری مشترک

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

این راهکارهای مهندسی، چارچوب ارزیابی را به یک معماری آماده برای پروداکشن تبدیل می‌کنند. رابط‌های ساختاریافته جریان اطلاعات را مهار می‌کنند، ارکستراسیون روند اجرای کار را هدایت می‌کند، مدیریت وضعیت حافظه مشترک را در دست می‌گیرد و انتخاب مدل‌ها تنوع و توانمندی ایجنت‌ها را تنظیم می‌نماید. در نهایت، سیستم ارزیابی (Evals) بازخورد لازم را ارائه می‌دهد تا مطمئن شویم این کنترل‌ها دقیقاً طبق طراحی کار می‌کنند.

در پایان، ساخت یک سیستم چندایجنتی قابل اتکا صرفاً به معنای اضافه کردن ایجنت‌های باهوش‌تر نیست؛ بلکه اصل ماجرا مهندسی مرزهای میان آنهاست: شفاف کردن این مرزها، سنجش‌پذیر کردن آنها، قطعی‌سازی در نقاط ضروری و ساخت سیستمی تاب‌آور که در صورت اشتباه یک ایجنت، کل ساختار فرو نریزد.