«دفعه بعد بیشتر دقت می‌کنم»؛ برای اکثر عامل‌های هوش مصنوعی، این وعده یک دروغ است. طبق تحلیل فنی Wu Ji که در ۱۷ اوت ۲۰۲۶ منتشر شد، عامل‌های «خودبهبودبخش» تا حد زیادی یک افسانه هستند، زیرا به جای تکامل (تغییر فیزیکی در سیستم)، بر بازتاب (یک خروجی احتمالی) تکیه می‌کنند.
این تمایز در حالی مطرح می‌شود که صنعت به سمت عامل‌های خودمختار حرکت می‌کند. در حالی که دانشگاه استنفورد دوره‌ای اختصاصی (CS329A) برای عامل‌های خودبهبودبخش راه‌اندازی کرده و ICLR ۲۰۲۶ کارگاهی را به این موضوع اختصاص داده است، اما همچنان شکافی عمیق میان تئوری‌های آکادمیک و واقعیت‌های عملیاتی وجود دارد. این چالش‌ها در حالی رخ می‌دهد که برخی معتقدند عامل‌های خودبهبودبخش می‌توانند نیاز به کتابخانه‌های ابزار سنتی را از بین ببرند. همان‌طور که در تحلیل قبلی ما درباره‌ی شکست عامل‌ها در مقیاس واقعی اشاره کردیم، مشکل اصلی این است که بازتاب تنها یک «صحبت» است و هرگز به «رفتار» سیستمی تبدیل نمی‌شود.
برای حل این مشکل، Wu Ji یک حلقه چهارمرحله‌ای پیشنهاد می‌کند که هر اشتباه را به یک دارایی دائمی تبدیل می‌کند. این فرآیند با دفتر ثبت خطا (Error-ledger) آغاز می‌شود؛ سندی ساختاریافته (نشانه ← علت ریشه ← راهکار ← وضعیت) که در فایل‌های فیزیکی مانند error-ledger.md ذخیره می‌شود. این کار مانع از آن می‌شود که پنجرهٔ زمینه (Context Window) — که مثل میز کاری است و فقط جای چند ورق دارد، نه کل کتابخانه — درس‌های آموخته‌شده را پاک کند.
مرحله دوم، تقطیر اصلاحی (Corrective Distillation) است. در این مرحله، سیستم به جای یادداشت ساده‌ی یک اشتباه، دفتر ثبت را برای استخراج یک اصل کلی اسکن می‌کند. برای مثال، اصلاحی درباره‌ی سبک نوشتار، به یک قانون دائمی در فایل SKILL.md تبدیل می‌شود تا عامل در جلسات بعدی نیازی به «آموزش مجدد» نداشته باشد.
سپس دانش به مرحله مادنی‌سازی قوانین (Rule Materialization) می‌رود تا تکرار خطا از نظر فیزیکی غیرممکن شود. این سخت‌گیری در سه سطح رخ می‌دهد:
- مستندات: قوانین در اسناد مهارت نوشته می‌شوند (احتمالی).
- اسکریپت‌های تایید: کدهای خودکار، خروجی را در لحظه بررسی می‌کنند (قطعی).
- گیت‌ها: اگر گیت شکست بخورد، سیستم خروجی را به‌طور کامل مسدود می‌کند (اجباری).
به عنوان مثال، اسکریپتی مانند check_cross_links.py می‌تواند در صورت نبود لینک‌ها، خروجی را رد کند. این یعنی عامل از حالت «تلاش برای نتیجه» به حالت «تضمین نتیجه» می‌رود. این تغییر، تفکر عامل را به یک حلقه قابل مشاهده و کنترل تبدیل می‌کند که به آن مهندسی حلقه (Loop Engineering) می‌گویند. این رویکرد ساختاریافته با پژوهش‌های انویدیا درباره تکامل هم‌زمان ارزیاب و عامل هم‌سو است که نشان داد نظارت دقیق می‌تواند هزینه‌های محاسباتی را کاهش دهد.
این چرخش، فرض بنیادی توسعه‌ی عامل‌ها را تغییر می‌دهد. ما دیگر امیدوار نیستیم که یک پنجره متنی بزرگ‌تر یا یک پرامپت بهتر، رفتار مدل را اصلاح کند. هدف اکنون ایجاد «مصونیت سیستمی» است؛ جایی که محیط عامل در برابر حالت‌های شکست شناخته‌شده، به‌صورت فیزیکی مقاوم شده است. این تحول در معماری سیستم‌ها با سرعت خودکارسازی پژوهش‌های هوش مصنوعی که از پیش‌بینی‌ها پیشی گرفته است، شتاب بیشتری یافته است.
برای متخصصان، این بدان معناست که ارزش شما دیگر در مهندسی پرامپت (Prompt Engineering) — که هنر سؤال درست پرسیدن است، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — نیست، بلکه در مهندسی حلقه است. شما از معلمی که دستورات را تکرار می‌کند، به معماری تبدیل می‌شوید که گیت‌های کنترلی می‌سازد. نتیجه، سیستمی است که با هر خطای جدید، تکامل می‌یابد.
گام بعدی شما
- رایج‌ترین شکست‌های عامل خود را شناسایی و آن‌ها را از تاریخچهٔ چت به یک دفتر ثبت ساختاریافته (Markdown) منتقل کنید.
- برای خطاهای بحرانی، به جای اصلاح پرامپت، یک اسکریپت تایید (Verify Script) ساده بنویسید که خروجی را فیلتر کند.
- قوانین استخراج‌شده از خطاها را در فایل‌های مهارت مجزا ذخیره کنید تا از تکرار آموزش در هر جلسه جلوگیری شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو