تعدد قوانین در پرامپت باعث فروپاشی استدلال عامل‌های هوشمند می‌شود

تصور کنید یک فایل پرامپت به ۵۶,۰۰۰ کاراکتر می‌رسد؛ این حجم از جزئیات به‌جای تضمین دقت، می‌تواند باعث فلج شدن عامل (Agent) و تحریک یک فروپاشی کامل در عملکرد آن شود. این شکست سیستمی زمانی رخ می‌دهد که توسعه‌دهندگان با مدل‌های بدون حافظه (Stateless) مانند همکارانی رفتار کنند که اشتباهات دیروز را به یاد دارند. این رویکرد منجر به چرخه‌ای از قوانین افزایشی می‌شود که در نهایت توانایی استدلال مدل را خفه می‌کند. این یک تله رایج در مهندسی زمینه (Context Engineering) است: این باور غلط که جزئیات بیشتر برابر با دقت بیشتر است.

اکثر سازندگان هوش مصنوعی در یک چرخه بازخوردی غریزی عمل می‌کنند: وقتی یک عامل مرحله‌ای را فراموش می‌کند، آن‌ها قانونی اضافه می‌کنند که «این مرحله را فراموش نکن». سپس، اگر عامل رفتار «احمقانه» دیگری داشته باشد، آن‌ها یک قانون دیگر اضافه می‌کنند و باز هم تکرار می‌کنند. این رویکرد فرض می‌کند که تداوم وضعیت (Continuity of State) در مدل‌های بدون حافظه وجود دارد، در حالی که چنین نیست. هر اجرای مدل یک «راه‌اندازی سرد» (Cold Start) است؛ یعنی هوش مصنوعی هیچ حافظه‌ای از شکست‌های قبلی، هیچ یادآوری از اصلاحات دیروز و هیچ وضعیت مشترکی با جلسات پیشین ندارد. در واقع، تلاش برای شبیه‌سازی حافظه در مدل‌های زبانی همواره چالش‌برانگیز بوده و برخی پژوهش‌ها نشان می‌دهند که ابزارهای حافظه‌ی بلندمدت حتی می‌توانند منجر به افزایش چاپلوسی مدل و کاهش دقت شوند. همان‌طور که نویسنده مشاهده کرد، عبارت «دفعه بعد مراقب باش» پیش‌فرض می‌گیرد که یک «دفعه بعد» وجود دارد که وضعیت فعلی را به اشتراک می‌گذارد. در واقعیت، شما با طرف مقابل گفتگو می‌کنید که هیچ خاطره‌ای از مکالمه‌ای که فکر می‌کنید در حال انجامش هستید، ندارد.

پارادوکس اضافه‌بار زمینه

وقتی فایل قوانین به ۵۶,۰۰۰ کاراکتر رسید، توسعه‌دهنده متوجه شد که عامل به‌طور کامل از کار افتاده است. مدل دیگر روی حفاظ‌ها (Guardrails) استدلال نمی‌کرد، بلکه در آن‌ها غرق شده بود. توجه مدل (Attention) بیش از حد پخش شده بود که بتواند روی هر یک از دستورات عمل کند. اما وقتی قوانین تخلیه شدند و به کمتر از ۱,۲۰۰ کاراکتر کاهش یافتند، رفتار عامل در واقع بهبود یافت. این موضوع یک حقیقت بنیادین را آشکار کرد: عامل با قوانین کمتر، بهتر عمل می‌کند.

این مسئله یک تمایز حیاتی در مهندسی زمینه را برجسته می‌کند: تفاوت بین «دانستن یک قانون» و «توقف در برابر یک قانون».

• بازیابی (Knowing): قرار دادن یک قانون در پنجره زمینه به این معناست که مدل از وجود آن قانون آگاه است. این صرفاً تکه‌ای از اطلاعات است که در پنجره ذخیره شده است.
• کنترل جریان (Stopping): این یک عملیات متفاوت است. دانستن یک قانون تضمین نمی‌کند که مدل در میانه یک گردش کار (Workflow) متوقف شود، به‌ویژه زمانی که سه مرحله در فراخوانی ابزارها (Tool-calls) پیش رفته و در حال بهینه‌سازی برای به پایان رساندن وظیفه است.

متن موجود در یک پرامپت صرفاً یک پیشنهاد نرم (Soft Suggestion) است که برای جلب توجه با هر توکن دیگر در پنجره رقابت می‌کند. اگر واقعاً نیاز دارید که یک عامل متوقف شود، نوشتن یک جمله تأکیدی‌تر راهکار نیست.

حفاظ‌های ساختاری در برابر پرامپت‌های نرم

برای حل این مشکل، توسعه‌دهنده محدودیت‌ها را از پرامپت به کد منتقل کرد و «قلاب‌ها» (Hooks)، گیت‌ها و بررسی‌های فیزیکی ایجاد کرد که خارج از اختیار مدل هستند. اسکریپتی که از ادامه مسیر امتناع می‌کند، را نمی‌توان با صحبت کردن یا متقاعد کردن مدل دور زد. این بخشی از مهندسی زمینه است که اغلب در اسلایدهای ارائه‌ها گم می‌شود: نیمی از این شغل تصمیم‌گیری در این مورد است که چه چیزی «نباید» در پنجره زمینه باشد و چگونه آن تضمین‌ها به کد سخت (Hard Code) منتقل شوند.

این تغییر رویکرد، هدف را از تعقیب «دقت نظری» به «طراحی برای شکست ایمن» تغییر می‌دهد. شرط‌بندی روی این موضوع که «فقط آن را دقیق‌تر کن»، شرط‌بندی بسیار ضعیفی است. در حالی که برخی رویکردها بر تزریق خاطرات جعلی از شکست برای کاهش ریسک‌پذیری عامل‌ها تمرکز کرده‌اند، داده‌های سال‌های ۲۰۲۵ و ۲۰۲۶ از این رویکرد ساختاری حمایت می‌کنند:

• نظرسنجی JUAS ۲۰۲۵: تنها ۴٪ از شرکت‌ها گزارش کردند که هوش مصنوعی زاینده (Generative AI) «بسیار فراتر از انتظارات» عمل کرده است.
• گزارش شکاف GenAI مؤسسه MIT (۲۰۲۵): این گزارش سهم پایلوت‌های هوش مصنوعی سازمانی که واقعاً به مرحله تولید (Production) رسیدند را حدود ۵٪ تخمین زد.
• پژوهش Persol (فرواره ۲۰۲۶): داده‌ها نشان داد که تنها ۲۵.۴٪ از کارکنان کاهش ساعات کاری خود را به دلیل AI تجربه کردند. هشداردهنده این است که کاربران پروباز AI، به دلیل بار سنگین اصلاح خروجی‌های ناقص، اغلب اضافه‌کاری بیشتری داشتند، نه کمتر.

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

الگوهای عملی برای طراحی عامل

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

• اختلاف‌نظر را به عنوان سیگنال ببینید: تکنیکی که توسط تیم estie استفاده می‌شود، شامل اجرای یک وظیفه یکسان توسط چندین مدل مختلف (مانند GPT، Claude و Gemini) است. اگر مدل‌ها توافق کنند، نتیجه ارسال می‌شود. اگر اختلاف‌نظر داشته باشند، مورد مذکور به یک انسان ارجاع داده می‌شود. این روش از افزونگی ارزان‌قیمت برای مکان‌مند کردن دقیق نقاطی که نیاز به توجه انسانی دارند استفاده می‌کند.
• معیارهای تصاعد را بنویسید، نه تشویق: درخواست‌های مبهم مانند «مراقب باش» را با شرایط صریح بازگشت در پرامپت سیستم جایگزین کنید:
  • اگر نتوانست در دو دقیقه حل کند $
    ightarrow$ تغییر روش.
  • اگر پانزده دقیقه گیر کرد $
    ightarrow$ بازگشت به انسان.
  • اگر تغییرات، محدوده یا طراحی را تغییر دهد $
    ightarrow$ همیشه بازگشت به انسان.
  • هر مورد دیگر $
    ightarrow$ ادامه به‌صورت خودگردان.
    این موارد به عنوان یک مرز تصمیم‌گیری عمل می‌کنند که عامل می‌تواند آن را ارزیابی کند، نه یک آرزوی مبهم برای «خوب عمل کردن».
• جایگاه محدود (Narrow Seating): به جای دادن مأموریتی مبهم مانند «کمک کن»، به هوش مصنوعی یک جایگاه ثابت در گردش کار بدهید. استقرار‌های موفق (آن‌هایی که بعد از سه ماه هنوز فعال هستند) معمولاً یک صندلی خاص را تخصیص می‌دهند: مثلاً تنظیم صورت‌جلسات، رسیدگی به پشتیبانی خط اول مشتری یا جمع‌آوری یک اسلایدشو. یک صندلی محدود تضمین می‌کند که یک پاسخ غلط، شعاع تخریب کوچک و شناخته‌شده‌ای داشته باشد.

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

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

گام بعدی شما

• قوانین تکراری و «نصیحت‌های» متنی را از پرامپت سیستمی حذف کنید.
• برای هر محدودیت حیاتی، یک چک‌باکس در کد (Python/JS) قرار دهید تا مدل نتواند از آن عبور کند.
• مدل‌های مختلف را برای اعتبارسنجی متقاطع (Cross-validation) به کار بگیرید تا نقاط شکست را شناسایی کنید.

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