چرا برای توقف توهمات ساختاری عامل‌های هوش مصنوعی، معماری مهم‌تر از پرامپت است؟

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

در ۱۳ مه ۲۰۲۶، راهنمایی در وب‌سایت dev.to فاش کرد که عامل‌ها اغلب پارامتر‌های ابزاری را اختراع می‌کنند که اصلاً وجود ندارند. این مشکل در مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — بسیار رایج است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن دیدیم، اعتماد کورکورانه به خروجی مدل، نقطه‌ی ضعف سیستم است.

بسیاری از توسعه‌دهندگان با توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — به عنوان یک خطای اطلاعاتی برخورد می‌کنند. اما در گردش‌کارهای عامل‌محور (Agentic)، مدل ممکن است یک فیلد خیالی در یک طرح‌واره JSON بسازد. طبق گزارش این راهنما، این تغییر از «اطلاعات غلط» به «کد خراب»، پایداری سیستم را به یک گلوگاه حیاتی تبدیل کرده است.

برای سخت‌سازی معماری عامل‌ها، این ۷ مورد ضروری است:

• طرح‌واره‌های سخت‌گیرانه: غیرفعال کردن additionalProperties: true برای جلوگیری از اختراع فیلدهای جدید توسط مدل.
• مدیریت خطای ساختاریافته: ابزارها باید به جای نمایش خطاهای خام، یک ساختار JSON ثابت (مثل success: false) برگردانند.
• ثبت وقایع مرزی: ثبت کامل زنجیره «ورودی $\rightarrow$ فراخوانی ابزار $\rightarrow$ پاسخ $\rightarrow$ خروجی».
• پاسخ‌های محدود: محدود کردن دریافت داده‌ها به ۲۵ مورد برای کاهش «تفسیر خلاقانه» مدل از داده‌های حجیم.
• تست‌های مدل‌محور: اجرای مجموعه‌آزمون‌ها روی هر مدل؛ چون مدل‌های ارزان‌تر بیشتر پارامترهای خیالی می‌سازند.

این رویکرد، بار مسئولیت پایداری را از «هوش» مدل به «طراحی» توسعه‌دهنده منتقل می‌کند. برای یک مهندس، این یعنی مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — دیگر اهرم اصلی برای پایداری نیست. در واقع، عامل مانند یک تست استرس برای API شماست؛ اگر مدیریت مقادیر تهی (Null) در کد شما ضعیف باشد، عامل دقیقاً همان شکاف را پیدا کرده و فعال می‌کند.

گام بعدی شما

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

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