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

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

به نقل از راهنمای فنی منتشر شده در dev.to در ۱۸ جولای ۲۰۲۶، این شکست‌ها معمولاً به این دلیل رخ می‌دهند که مهندسان به‌جای استفاده از یک «هارنس» ساختاریافته برای حاکمیت بر رفتار، بر هوش مدل تکیه می‌کنند. در نهایت، یک مدل با عملکرد بالا به‌تنهایی برای ساخت یک عامل (Agent) قابل اعتماد کافی نیست. در واقع، تکیه صرف بر هوش مدل برای مدیریت رفتار عامل، یک اشتباه استراتژیک است. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن دیدیم، تکیه بر «حسن نیت» یا توانایی ذاتی مدل‌ها بدون وجود لایه‌های حفاظتی، همیشه به شکست منجر می‌شود. این آسیب‌پذیری‌ها در واقع ریشه در کیفیت ورودی‌ها دارند؛ چنان‌که پیش‌تر بررسی کردیم چگونه داده‌های خام می‌توانند عامل‌های هوش مصنوعی را به شکست بکشانند و هزینه‌های پنهانی برای سیستم ایجاد کنند.

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

مهندسی پرامپت (Prompt Engineering) — که شبیه به هنر سؤال درست پرسیدن از یک مشاور باتجربه است — فقط شکل آنچه مدل «می‌خواهد» انجام دهد را تغییر می‌دهد. اما هارنس تعیین می‌کند مدل «چه کاری می‌تواند» انجام دهد. هارنس به‌عنوان لایه‌ای عمل می‌کند که فراخوانی‌های ابزار (Tool Calls) را اجرا می‌کند، وضعیت گفتگو را دنبال می‌کند و محدودیت‌های سخت را اعمال می‌کند. بدون این سیستم، حتی پیشرفته‌ترین مدل‌ها تمایل دارند در حلقه‌ها گیر کنند، نتایج ابزارها را توهم کنند و از مسیر وظیفه منحرف شوند، زیرا هیچ سیستم خارجی وجود ندارد که امتیازات و پیشرفت‌ها را ثبت کند. در اینجا مدل دچار توهم (Hallucination) — یعنی حالتی که مدل با اطمینان چیزی می‌گوید که وجود ندارد، شبیه به دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شده و از مسیر اصلی خارج می‌شود.

ستون‌های چهارگانه پایداری در هارنس

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

• اجرا و اعتبارسنجی (Execution and Validation): هارنس باید فراخوانی ابزارها را اجرا کرده و پیش از آنکه این فراخوانی‌ها به یک سیستم واقعی برسند، آن‌ها را با یک طرح‌واره (Schema) بسنجد. این شامل رد کردن فراخوانی‌هایی است که به ابزارهایی اشاره می‌کنند که اصلاً وجود ندارند. سیستم باید به‌جای شکست‌های خاموش، خطاهای شفاف و بدون ابهام بازگرداند. یک هارنس سست که اجازه فراخوانی‌های بدشکل (Malformed) را می‌دهد یا پاسخ‌های خالی برمی‌گرداند، همان چیزی است که به یک عامل اجازه می‌دهد به‌جای تشخیص شکست، یک «موفقیت» پذیرفتنی را جعل کند.
• وضعیت و حافظه (State and Memory): مدل‌ها به‌طور طبیعی ردیابی نمی‌کنند که قبلاً چه کارهایی را امتحان کرده‌اند. هارنس باید یک سابقه مستمر از اقدامات قبلی و نتایج آن‌ها نگه دارد تا سیستم بتواند تلاش‌های تکراری را شناسایی کند. بدون این بررسی داخلی که «آیا من این کار را قبلاً انجام داده‌ام؟»، ایجاد حلقه‌های تکرار (Retry Loops) تقریباً اجتناب‌ناپذیر می‌شود، زیرا عامل نمی‌تواند یک تلاش تازه را از پنجمین تلاش کاملاً مشابه تشخیص دهد. این چالش‌ها دقیقاً همان جایی است که ابزارهای تخصصی مانند ai-loopguard برای توقف چرخه‌های مرگبار عامل‌ها به کمک توسعه‌دهندگان می‌آیند تا از توقف کامل سیستم جلوگیری کنند.
• منطق خروج و توقف (Termination and Exit Logic): تصمیم درباره اینکه «چه زمانی متوقف شویم» نباید یک تصمیم نرم در سطح متن (Prose-level) باشد که به قضاوت مدل سپرده شده است. چنین تصمیماتی تحت فشار برای «بهره‌ور به نظر رسیدن»، فرو می‌پاشند. سیستم‌های مقاوم، منطق خروج را به تعریف گردش‌کار (Workflow) منتقل می‌کنند، جایی که هر وضعیت به‌طور صریح اعلام می‌کند که در صورت شکست، مسیر بعدی کجاست. برای مثال، یک مرحله تأیید (Verification) شکست‌خورده باید به «تلاش مجدد برای پیاده‌سازی» هدایت شود، نه اینکه دوباره به خودش بازگردد. اگر گردش‌کار شامل هیچ یالی نباشد که اجازه تکرار بی‌پایان خودبه‌خود را بدهد، آن حالت شکست از نظر ساختاری غیرقابل دسترس می‌شود.
• بودجه و محدودیت‌ها (Budgets and Limits): سقف‌های سخت هزینه، محدودیت تعداد نوبت‌ها (Turn limits) و سقف دفعات تلاش مجدد، به‌عنوان آخرین خط دفاعی عمل می‌کنند. در حالی که این‌ها در مقایسه با منطق خروج ظریف، ابزارهایی خشن هستند، اما ضروری‌اند. هیچ مکانیزم تشخیصی نمی‌تواند تمام موارد خاص (Edge cases) را بگیرد؛ بودجه همان چیزی است که مانع از تبدیل شدن یک مورد خاصِ شناسایی‌نشده به یک فاجعه مالی گران‌قیمت می‌شود.

مسیرهای شکست پذیر و صادقانه

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

این وضعیت دشوارترین نوع شکست برای شناسایی را ایجاد می‌کند: «موفقیت توهمی» (Hallucinated Success). یک هارنس خوش‌ساخت، یک پیام ساختاریافته و صریح مبنی بر اینکه «من آنچه را برای به پایان رساندن این کار نیاز دارم، ندارم»، به‌عنوان یک نتیجه خنثی و درجه اول (First-class outcome) را می‌پذیرد. وقتی شکست صادقانه جریمه نشود، عامل‌ها دیگر برای مفید به نظر رسیدن، دست‌وپا نمی‌زنند. در این مرحله است که متوجه می‌شویم چرا نظارت انسانی به تنهایی نمی‌تواند جلوی این خطاهای پیچیده را بگیرد و نیاز به لایه‌های کنترلی سخت‌افزاری و نرم‌افزاری مبرم است.

تشخیص الگوهای شکست

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

دوم، «نوسان» (Oscillation) است که ظریف‌تر است و تشخیص آن سخت‌تر است. در اینجا هیچ تک‌اقدامی تکرار نمی‌شود؛ در عوض، عامل ممکن است یک فایل را به یک روش ویرایش کند، سپس آن را به حالت قبل برگرداند و سپس مراحل تغییر اولیه را دوباره معرفی کند. چون هیچ تک‌اقدامی کپی نیست، سیستم‌های ساده‌ی حذف تکرار (Deduplication) به‌طور کامل آن را نادیده می‌گیرند.

راهنمای مذکور پیشنهاد می‌کند به‌جای هش کردن کامل وضعیت، یک «خلاصه نتایج» (Outcome Digest) ردیابی شود. با نظارت بر اینکه آیا اثرات چندین اقدام اخیر — مانند فایل‌های تغییر یافته، فراخوانی‌های انجام شده و نتایج بازگشتی — شروع به تکرار می‌کنند بدون اینکه چیز جدیدی اضافه شود، هارنس می‌تواند نوسان را شناسایی کند. اگرچه این یک بررسی تقریبی (Lossy check) است و ممکن است برخی موارد را 놓 دهد، اما وقتی با یک سقف سخت (Hard cap) به‌عنوان پشتیبان جفت شود، سیگنال قدرتمندی است.

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

چرا مدل‌های بزرگ‌تر راه نجات نیستند؟

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

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

گام بعدی شما

• استک عامل‌های خود را بررسی کنید و ببینید آیا «منطق خروج» شما یک پیشنهاد در پرامپت است یا یک قانون کدنویسی شده در گردش‌کار.
• یک لایه اعتبارسنجی برای تمام خروجی‌های Tool Call اضافه کنید تا از ارسال داده‌های نامعتبر به APIها جلوگیری شود.
• مکانیزم رهگیری تاریخچه اقدامات را پیاده‌سازی کنید تا حلقه‌های تکراری در سطح هارنس شناسایی و متوقف شوند.

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