اگر امروز در حال استقرار عاملهای هوش مصنوعی هستید، بزرگترین هزینه شما اولین شکست مدل نیست، بلکه حلقه تکرار بیانتهاست که پس از آن میآید. طبق گزارشی که در ۱۷ ژوئن ۲۰۲۶ توسط وبسایت dev.to منتشر شد، این حلقهها یک «مشکل سیستم کنترل» ایجاد میکنند که در آن عاملها یک دستور شکستخورده را بارها اجرا میکنند و بودجه را میبلعند و اعتماد کاربران را نابود میکنند.
مکانیسمهای حلقه
تصور کنید دستیاری دیجیتال یک مرحله حیاتی در یک گردش کار را فراموش میکند. بهجای متوقف شدن، سیستم دوباره همان اقدام را امتحان میکند. چون محیط تغییر نکرده، عامل دوباره همان وضعیت را میبیند و همان خطا را تولید میکند. این چرخه تا زمانی تکرار میشود که هزینه در صورتحساب API یا لاگهای اپراتور ظاهر شود.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، بسیاری از نقاط شکست در لایههای پنهان عملیاتی رخ میدهند. این حالت شکست اغلب «خستهکننده» است و نادیده گرفته میشود. توسعهدهندگان معمولاً روی دموهای موفق تمرکز میکنند و اتفاقاتی که بعد از سومین خطای مشابه میافتد را نادیده میگیرند. در حالی که یک گام اشتباه قابل جبران است، یک حلقه بیانتها هزینهها را در سطح توکنها، فراخوانیهای API و توجه اپراتور چندین برابر میکند.
چرا راهکارهای رایج شکست میخورند؟
واکنشهای رایج به این مشکل اغلب معکوس اثر میکنند. توسعهدهندگان معمولاً سعی میکنند:
- متن پرامپت را طولانیتر کنند
- تکرارهای عمومی اضافه کنند
- زمان انتظار (timeout) را افزایش دهند
- از مدل بخواهند «بیشتر استدلال کند»
- همان دستور را با کلمات کمی متفاوت اجرا کنند
این تغییرات شاید دموی شما را بهتر کند، اما حلقه گیر کرده را باز نمیکند؛ چون محیط ثابت ایجادکننده خطا تغییری نکرده است. اگر محیط تغییر نکند، تکرار فقط کپی دوم همان اشتباه است. برای حل این موضوع، MartinLoop رویکردی مبتنی بر لایه کنترل را پیشنهاد میکند. بهجای زبان هوشمندتر، زمان اجرا (Runtime) — که مثل موتور محرک برنامه است و تصمیم میگیرد چه کدی در چه لحظهای اجرا شود — باید با پاسخ به چهار سؤال سختگیرانه، مرزهای عملیاتی را تعیین کند:
- بودجه چقدر است؟
- چه چیزی «موفقیت» محسوب میشود؟
- تأییدکننده (Verifier) کیست؟
- وقتی یک شکست تکرار میشود چه اتفاقی میافتد؟
جزئیات پیادهسازی
اجرای یک بلوک سیاستگذاری مشخص میتواند جلوی این خونریزی مالی را بگیرد. برای مثال، پیکربندی زیر مانع از آن میشود که سیستم تصور کند اجرای بعدی بهطور جادویی متفاوت خواهد بود:
{ "budget_cap": 250, "max_attempts": 3, "stop_on_same_error": true, "require_verifier": true, "emit_receipt": true }
مکانیزم حیاتی دیگر، «رسید» (Receipt) است. رسید، روایت مبهم عامل را به یک حقیقت قابل بررسی تبدیل میکند و این موارد را مستند میکند:
- عامل چه چیزی را امتحان کرد
- چه چیزی تغییر کرد
- چه چیزی شکست خورد
- چرا اجرا متوقف شد
بدون اینها، حلقهها در دل خلاصههایی که حس اعتماد میدهند پنهان میشوند و نقطه شکست واقعی را میپوشانند. با وجود رسیدها، اپراتورها میتوانند تصمیم بگیرند که گام بعدی باید دخالت انسانی باشد، ابزاری متفاوت باشد یا اصلاً هیچ اقدامی صورت نگیرد.
زمینه و چشمانداز
این چرخش، تمرکز کار را از مهندسی پرامپت (Prompt Engineering) — که مثل هنر سؤال درست پرسیدن از یک مشاور باتجربه است — به سمت عملیات (Operations) میبرد. کنترل سختگیرانهتر یعنی سیستم زودتر متوقف شود. شاید این موضوع وقتی میخواهید عامل «به هر قیمتی» مشکل را حل کند ناامیدکننده باشد، اما توقف زودهنگام بهمراتب ارزانتر از یک توالی تکرار کورکورانه و طولانی است. در نهایت، یک عامل محدودشده، کاربردیتر از یک عامل پرزرقوبرق است که هرگز تسلیم نمیشود. هدف این است که از عاملی که فقط «خودمختار به نظر میرسد» به عاملی برسیم که واقعاً «قابل مدیریت و عملیاتی» باشد.
مرز بعدی در این مسیر، طبقهبندی پیشرفته شکستها است. زمان اجرا (Runtime) باید بتواند بین موارد زیر تفاوت قائل شود:
- نبود دسترسیها (Permissions)
- وضعیتهای قدیمی یا منقضی شده (Stale states)
- عدم تطابق ابزارها (Tool mismatches)
- قطعیهای خارجی
- تکمیل واقعی تسک
تنها در این صورت است که سیستم میتواند بهجای بازیافت همان اشتباه، یک گام اصلاحی درست را انتخاب کند.
گام بعدی شما
- در تنظیمات عاملهای خود، سقف تعداد تلاشها (max_attempts) را برای هر تسک تعریف کنید.
- سیستمی برای تولید «رسید» (Receipt) پیادهسازی کنید تا نقاط شکست دقیقاً شناسایی شوند.
- بهجای طولانی کردن پرامپتها برای رفع خطا، روی لایهی کنترل و Verifier تمرکز کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو