عامل هوش مصنوعی شما به این دلیل شکست نمی‌خورد که داده‌ی کافی ندارد، بلکه به این دلیل می‌لغزد که نمی‌تواند جایگاه خود را در یک سیستم پیچیده در بازه‌های زمانی طولانی حفظ کند. طبق یک تز فنی که در ۱ جولای ۲۰۲۶ در dev.to منتشر شد، اتکای صنعت به تولید بازیابی‌افزا (RAG) — که شبیه دانش‌آموزی است که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — در واقع یک مشکل «هدایت» را به اشتباه به عنوان مشکل «اطلاعات» تلقی می‌کند.
بیشتر توسعه‌دهندگان برای رفع مشکل «پرش» یا Drift عامل‌ها، سعی می‌کنند ایندکس‌گذاری، بردار معنایی (Embedding) — که مثل کارت معرفی عددی برای هر واژه است تا همسایگانش را بشناسد — و نقشه‌های مخزن کد را بهبود ببخشند. آن‌ها تصور می‌کنند عامل گم شده چون اطلاعات کافی از کد یا فرآیند کسب‌وکار ندارد. اما در واقعیت، یک مدل توانمند اگر چارچوب درست داده شود، زنجیره‌های منظم را اجرا می‌کند، اما وقتی مجبور شود به‌طور خودگردان در یک سیستم پیچیده حرکت کند، دچار فروپاشی می‌شود. این چالش‌ها دقیقاً همان نقاط ضعفی هستند که در تحلیل ما درباره‌ی کندی استقرار عامل‌های کدنویس در محیط تولید به آن‌ها پرداختیم.
به گزارش نویسنده‌ی این مقاله، وقتی یک عامل خودش زمینه یا Context را «می‌کشد»، دقیقاً همان کاری را انجام می‌دهد که در اثر «پرش» از دست داده است: یعنی ناوبری و فیلتر کردن موارد مرتبط. این وضعیت یک حلقهٔ شکست ایجاد می‌کند؛ عامل موقعیت خود را دوباره استنتاج می‌کند، رابطه‌هایی را که قبلاً دیده بود از دست می‌دهد و به‌جای ریشه، فقط علائم را وصله می‌زند. این پدیده به شدت با رویکرد «صف اقدامات» برای جلوگیری از هدررفت توکن‌ها در مواجهه با Drift مرتبط است.
همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، مدیریت وضعیت در سیستم‌های توزیع‌شده همیشه چالش‌برانگیز بوده است. در اینجا نیز مشکل، نبود داده نیست، بلکه نبودِ یک «نقشه راه» فعال است.
سازوکار Guided Runtime
جایگزین پیشنهادی، یک «زمان‌بندی هدایت‌شده» (Guided Runtime) بر اساس معماری «هل کردن» (Push) به جای «کشیدن» (Pull) است. در این مدل، به‌جای اینکه عامل تصمیم بگیرد چه زمینه‌ای را جمع‌آوری کند، خودِ زمان‌بندی گام بعدی را محاسبه کرده و پیش از اقدام عامل، آن را به حلقهٔ اجرا تزریق می‌کند. این کار حلقهٔ کنترل را از «بازیابی» به سمت یک «راهنمای ساختاری» می‌برد.
این سامانه از سه لایه مجزا تشکیل شده است:
- حقایق (Facts): یک مدل حقیقتِ زمینی (Ground Truth) قابل پرس‌وجو. برای کد، این لایه شامل گراف نمادها و وابستگی‌های متصل به کامیت‌هاست. نویسنده پیشنهاد می‌کند از Event Sourcing استفاده شود تا وضعیت، تصویری از یک گزارش رویدادِ صرفاً-افزودنی باشد.
- قوانین (Rules): برنامه‌ی دامنه که به قراردادهای قابل بررسی تبدیل شده است. برخلاف برنامه‌های مبهم (مثل «این ویژگی را پیاده کن»)، یک قرارداد، فایل‌های خاصی را به عنوان حصار تعریف می‌کند و اقدامات مجاز یا ممنوعه را مشخص می‌کند.
- راهنما (Guide): حاصل ارزیابی قوانین در برابر حقایق است. این لایه یک سیگنال هدایتی صادر می‌کند که اقدام قانونی بعدی را تعریف کرده یا هرگونه «پرش» عامل را هشدار می‌دهد.
فراتر از کدنویسی: معماری عمومی
اگرچه نویسنده این روش را برای Aming Claw — یک ابزار عامل‌محور برای کدنویسی — توسعه داده است، اما این معماری مستقل از دامنه است. موتور «حقایق + قوانین $ o$ راهنما» در اصل یک موتور قوانین تولیدی یا سیستم «سیاست به مثابه کد» است.
برای به‌کارگیری این روش در گردش‌کارهای پیچیده دیگر، مثل خط لوله‌های claims بیمه یا دفترچه‌های راهنمای عملیاتی (Runbooks)، کاربر تنها به دو چیز نیاز دارد: یک ابزار لایه حقیقت برای استخراج داده‌های مرجع و مجموعه‌ای از قراردادهای قابل بررسی. خودِ موتور در دامنه‌های مختلف کسب‌وکار قابل استفاده مجدد است. با این حال، باید به یاد داشت که هرگونه دسترسی گسترده‌تر به لایه‌ی حقایق می‌تواند سطح حمله (Attack Surface) اتوماسیون‌ها را در برابر اسکریپت‌های غیرفعال افزایش دهد.
پاکت «هل کردن» (Push Envelope)
در این مدل، زمان‌بندی یک «پاکت داده» مشخص را به عامل ارسال می‌کند. این پاکت شامل موارد زیر است:
۱. شناسه‌ی قرارداد فعلی و نقش بازیگر.
۲. لیست اقدامات مجاز و مسدود شده.
۳. اقدام قانونی بعدی و شواهد مورد نیاز.
۴. اسکلت داده‌های ارسالی (Payload) و نشانگر وضعیت (Watermark) مورد استفاده در محاسبات.
۵. دروازه‌ای (Gate) که اقدام حاصل را تأیید می‌کند.
با ارائه این ساختار، عامل دیگر مجبور نیست در هر گام، موقعیت یا قانونیت خود را از صفر استنتاج (Inference) — یعنی همان لحظه تولید جواب، شبیه آشپزی-کردن بعد از یادگیری دستور — کند.
شواهد مشاهده‌ای و گام‌های آتی
نویسنده اشاره می‌کند که اجزای این سیستم (مثل Event Sourcing و تزریق زمینه ماشین-وضعیت) پیش‌تر وجود داشتند. نوآوری در ترکیب آن‌هاست: استفاده از یک قرارداد بر روی مدل حقیقتِ برآمده از رویدادها به عنوان کنترلر اصلی ضد-پرش.
داده‌های اولیه از Aming Claw نشان می‌دهد که حلقه‌های گیر‌کردنِ بیمارگونه (Pathological Loops) زودتر شناسایی می‌شوند و مسیرهای پیچیده چند-کارکنی با دقت بیشتری هم‌گرا می‌شوند. با این حال، نویسنده صراحتاً ذکر می‌کند که این هنوز یک نتیجه‌ی تأییدشده نیست، زیرا معماری و راهنمایی اپراتور به‌طور هم‌زمان تغییر کرده‌اند.
برای اثبات علیت، یک آزمایش کنترل‌شده برنامه‌ریزی شده است. این آزمایش در محیطی بدون اپراتور و با استفاده از حذف متغیرهای مدل (Ablation) انجام می‌شود تا اثرِ «هارنس» یا همان چارچوب هدایت‌کننده، از هوش ذاتی مدل تفکیک شود. معیار کلیدی، دلتای بین «پرش» و «تکمیل» بر اساس طول وظیفه خواهد بود تا این فرضیه تست شود که هزینهٔ یک Guided Runtime با مزایای ضد-پرشی آن در وظایف بلندمدت جبران می‌شود.
گام بعدی شما
- اگر عامل‌های شما در زنجیره‌های طولانی «گم» می‌شوند، به‌جای افزایش پنجره متنی، روی تعریف «قراردادهای سخت» (Hard Contracts) برای گام‌های میانی تمرکز کنید.
- بررسی کنید آیا می‌توانید لایه‌ی «حقایق» سیستم خود را از حالت بازیابیِ لحظه‌ای به حالت Event Sourcing تغییر دهید تا تاریخچه تغییرات را گم نکنید.
- در طراحی پرامپت‌های سیستمی، به‌جای توصیف کلی هدف، لیست اقدامات «مجاز» و «ممنوعه» را در هر مرحله به مدل تزریق کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو