«شبیه به صحنه جرم»؛ رویکردی نوین برای عیب‌یابی سیستم‌های چندعاملی

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

به نقل از راهنمای فنی dev.to که در ۴ اکتبر ۲۰۲۶ منتشر شد، شکافی بحرانی در مدیریت عامل‌های خودمختار وجود دارد: لاگ‌های سنتی فقط می‌گویند یک تابع فراخوانی شده است، اما هرگز توضیح نمی‌دهند که چرا عامل فکر می‌کرد این فراخوانی، تصمیم درستی است. در یک سامانه چندعاملی (Multi-Agent System) — شبیه به تیمی از متخصصان که هر کدام independently تصمیم می‌گیرند و روی هم اثر می‌گذارند — شما با یک برنامه خطی طرف نیستید، بلکه با گروهی از موجودات هوشمند روبرو هستید که می‌توانند در حلقه‌های تکرار گیر کنند یا بر اساس حافظه‌ای آلوده، دچار توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شوند.

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

زنجیره شواهد سه لایه

برای تبدیل یک تصمیم «جعبه سیاه» به یک فرآیند شفاف، این متد استفاده از یک سیستم لاگ‌گذاری ساختاریافته در سه لایه را الزامی می‌کند:

• لایه ادراک (Perception Layer): ثبت تمام ورودی‌هایی که عامل دریافت می‌کند؛ از پیام‌های کاربر و پرامپت‌های سیستمی گرفته تا خروجی‌های سایر عامل‌های گروه.
• لایه استدلال (Reasoning Layer): ثبت زنجیره تفکر (Chain-of-Thought) — مثل وقتی شاگرد ریاضی پای تخته بلند بلند فکر می‌کند تا به جواب برسد. در اینجا ثبت می‌شود که چه راهکارهایی بررسی شدند و منطق انتخاب مسیر نهایی چه بود.
• لایه اقدام (Action Layer): مستندسازی ابزارهای فراخوانی شده، پارامترهای ارسالی، مقادیر بازگشتی و تأخیر در اجرا.

به عنوان مثال، اگر یک عامل داده برای محاسبه رشد سالانه تابعی را فراخوانی کند، لاگ معمولی فقط نام تابع را می‌نویسد. اما لاگ ساختاریافته فاش می‌کند: «نیاز فعلی محاسبه فروش سال گذشته است، بنابراین تابع X فراخوانی می‌شود؛ اما بازیابی حافظه نشان می‌دهد در گزارش سه ماهه قبل، تعریف رشد سالانه با رشد فصلی جابه‌جا شده بود.» این یعنی ریشه مشکل، آلودگی حافظه است، نه خطای کدنویسی.

پیاده‌سازی فنی و تحلیل داده‌ها

اجرای این سیستم نیازمند دسترسی به حلقه استدلال عامل از طریق دکوراتورها یا میان‌افزارها (Middleware) است. سیستم باید قبل از هر گام استدلالی، بستر فعلی — شامل نقش‌ها در پرامپت سیستمی (System Prompt)، قصد کاربر و استدلال‌های تولید شده — را به یک شیء JSON تبدیل کند و پس از هر گام، خروجی مدل یا دستور اقدام را به آن بچسباند.

این لاگ‌ها در قالب یک خط زمانی (Timeline) ذخیره می‌شوند تا توسعه‌دهندگان بتوانند با استفاده از گراف‌های علی (Causal Graphs) ببینند چگونه اشتباه یک عامل، مانند اثر دومینویی، کل سیستم را مختل می‌کند.

بررسی موردی: نقص عامل سفر و خدمات مشتریان

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

در مورد دیگری در بخش خدمات مشتریان، کاربران پس از انتقال به اپراتور انسانی، باز هم پاسخ‌های خودکار دریافت می‌کردند. لاگ‌های رفتاری نشان داد که عامل تشخیص قصد، شکایت از «زمان انتظار طولانی» را به اشتباه به عنوان «پرسش از وضعیت» طبقه‌بندی کرده بود. در نتیجه، عامل تیکت حتی پس از انتقال به انسان، همچنان در صف پاسخ‌های خودکار باقی مانده بود چون ماشین وضعیت داخلی (State Machine) پس از عملیات انتقال، صف پاسخ‌ها را پاک نکرده بود.

تضاد در دانش حقوقی

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

از عیب‌یابی دستی تا تشخیص خودکار

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

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

گام بعدی شما

• اگر از سامانه‌های چندعاملی استفاده می‌کنید، لایه استدلال (Reasoning) را از خروجی نهایی جدا کرده و در یک فایل JSON مجزا ذخیره کنید.
• برای هر ابزاری که عامل فراخوانی می‌کند، یک لاگ از «دلیل فراخوانی» (Why) در کنار «نتیجه فراخوانی» (What) ثبت کنید.
• یک گراف علی ساده برای ردیابی خطاهای زنجیره‌ای در سیستم خود رسم کنید تا نقاط شکست تکراری را بیابید.

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