پنجره‌های متنی بزرگ‌تر راهکار حل مشکل توقف عامل‌های کدنویسی نیستند

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

به نقل از گزارشی در ۴ سپتامبر ۲۰۲۶ در وب‌سایت dev.to، صنعت هوش مصنوعی در حال خلط کردن «زمینهٔ گفتگو» با «وضعیت پایدارِ شغل» است. این تفاوت حیاتی است؛ زیرا یک عامل کدنویسی ممکن است ۱۲ فایل را ویرایش کند و ۸ ساعت یک سرور توسعه را اجرا نماید، اما در یک لحظه کل جلسه (Session) خود را از دست بدهد. حتی اگر تمام تاریخچهٔ گفتگو در یک پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که جا برای چند ورق دارد، نه برای کل کتابخانه — جای بگیرد، یک پردازش جدید نمی‌داند کدام تست دقیقاً باعث توقف مرحلهٔ قبلی شده یا آیا اجرای مجدد یک مهاجرت پایگاه‌داده ایمن است یا خیر. این چالش با پدیده پوسیدگی زمینه تشدید می‌شود که در آن مدل‌ها با وجود پنجره‌های بزرگ، بخش‌های حیاتی اطلاعات را نادیده می‌گیرند.

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

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

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی حافظهٔ عامل‌های هوش مصنوعی اشاره کردیم، تکیه بر حافظهٔ کوتاه‌مدت برای عملیات‌های طولانی‌مدت همواره با ریسک عدم قطعیت همراه است. این ریسک در مقیاس وسیع‌تر نیز مشاهده شده است؛ چنان‌که مطالعات دانشگاه پن استیت نشان داد بخش بزرگی از دستورات کاربران در فرآیندهای فشرده‌سازی حافظه حذف می‌شوند.

شکاف میان نقطه بازرسی و زمینه

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

این تفاوت در زمان وقفه‌ها بسیار هزینه‌بر می‌شود. اگر جلسه بین فراخوانی یک ابزار و پاسخ نهایی قطع شود، روایت عامل ممکن است با اطمینان باشد، اما وضعیت مخزن نامشخص می‌ماند. یک پردازش جایگزین نمی‌تواند برای تشخیص زنده بودن سرور توسعه یا ایمنی اجرای مجدد یک مهاجرت، به متن گفتگو تکیه کند.

برای حل این مشکل، عامل‌ها به یک سوابق عملیاتی فشرده نیاز دارند که شامل موارد زیر باشد:

• قرارداد اجرا (هدف و شرط توقف).
• آخرین مرحله تکمیل‌شده و نتایج دقیق اعتبارسنجی آن.
• فهرستی از اثرات جانبی خارجی که پیش‌تر اعمال شده‌اند.
• ایمن‌ترین تصمیم بعدی برای پردازش جایگزین.

پیاده‌سازی پروتکل بازگشت

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

یک قرارداد دقیق، مرزها را پیش از شروع اجرا تعریف می‌کند. این شامل یک شناسه اجرا (Run ID)، مخزن مالک و درخت کاری (Worktree) و یک شرط توقف مشخص است؛ مثلاً: «یک پچ قابل بررسی برای کال‌بک ورود آماده کن، پیش از استقرار متوقف شو و نتایج تست‌های نام‌گذاری‌شده را ثبت کن». همچنین محدودیت‌های زمانی، ابزاری و سطح دسترسی، و خروجی مورد انتظار را تعیین می‌کند.

وضعیت باید در مرز هر مرحله ذخیره شود، نه در پایان کل اجرا. انتظار برای پاسخ نهایی بسیار دیر است؛ زیرا ممکن است پردازش پیش از آن از بین رفته باشد. نقاط بازرسی باید پس از مراحل معنادار رخ دهند، مانند:

• نصب وابستگی‌ها
• تولید مهاجرت‌های پایگاه‌داده
• تغییر کد
• اجرای تست‌ها
• اعتبارسنجی مرورگر
• هرگونه تغییر در محیط خارجی

ابزارهایی مانند Mivia این سازوکار را از طریق جریان‌های کاری ایزوله، سوابق اجرای هر مرحله و قلاب‌های چرخه حیات پیاده می‌کنند. هدف، ذخیره «واقعیت‌ها»ست — یعنی دستور دقیق و نتیجه واقعی آن — نه خلاصه‌هایی مثل «تست‌ها خوب به نظر می‌رسند». برای مثال، یک نقطه بازرسی باکیفیت، فایل تغییر یافته (مثلاً db/migrations/0042_add_job_receipts.sql) و کد خروجی دقیق دستور تست (مثلاً exit_code: 1) را ثبت می‌کند، نه یک دفترچه خاطرات صیقل‌خورده از افکار عامل.

مدیریت اثرات جانبی و بازیابی

تغییرات فایل‌ها تنها بخشی از مشکل هستند. عامل‌ها اغلب سرویس‌هایی را اجرا می‌کنند، پایگاه‌داده‌ها را تغییر می‌دهند، درخواست‌های Pull ایجاد می‌کنند یا تنظیمات راه دور را عوض می‌کنند. یک تلاش مجدد کورکورانه (Blind Retry) می‌تواند منجر به مهاجرت‌های تکراری یا استقرارهای متضاد شود و عدم قطعیت را با توالی جدیدی از اقدامات که صرفاً لاگ‌های تمیزتری تولید می‌کنند، جایگزین کند.

یک دفتر کل اثرات جانبی باید تغییرات خارج از متن گفتگو را ردیابی کند و به سه پرسش پاسخ دهد:

• چه چیزی خارج از متن گفتگو تغییر کرد؟
• آیا عملیات را می‌توان به‌طور ایمن بررسی کرد؟
• آیا این اقدام تکرارپذیر است، قابل بازگشت است یا هیچ‌کدام؟

بازیابی با «تلاش مجدد» متفاوت است. تلاش مجدد صرفاً عملیات را تکرار می‌کند، اما بازیابی ابتدا از طریق بازرسی، آنچه رخ داده را تثبیت می‌کند. PI-Desktop با استفاده از جلسات پروژه، تفاوت‌های (Diffs) محدود به پیام، تأییدیه‌ها و بازگشت‌های محافظت‌شده، واحد تغییر را به جای یک جریان کدر از فعالیت‌ها، قابل بازرسی می‌کند.

بازیابی باید از یک درخت تصمیم سخت‌گیرانه پیروی کند:

• ادامه (Resume): وقتی وضعیت ثبت‌شده با محیط مطابقت دارد و اقدام در انتظار هنوز معتبر است.
• بازگشت (Roll back): وقتی یک تغییر بازگشت‌پذیر شناخته‌شده باید پیش از ادامه کار حذف شود.
• ارجاع (Escalate): وقتی شواهد ناقص است، محیط تغییر کرده یا اقدامات بعدی می‌تواند اثرات جانبی ناشناخته را تشدید کند.

نقش رسیدها و آرشیوها

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

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

در نهایت، اجراهای قدیمی باید قراردادهای جدید را بهبود ببخشند. تیم‌ها با آرشیو کردن جلسات می‌توانند نقاط اصطکاک تکراری را شناسایی کنند. اگر چندین اجرا به دلیل ثبت نشدن مالکیت یک پورت (مثلاً پورت ۳۱۰۲) متوقف شدند، این فیلد به قالب قرارداد بعدی اضافه می‌شود. اگر تلاش‌های مجدد باعث تکرار اقدامات خارجی می‌شوند، سیستم می‌تواند کلیدهای Idempotency یا قوانین ارجاع جدیدی را الزامی کند.

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

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

گام بعدی شما

• در طراحی عامل‌های خود، به جای افزایش Context Window، یک ساختار ذخیره‌سازی وضعیت (State Store) برای ثبت نتایج هر مرحله ایجاد کنید.
• برای هر تسک پیچیده، یک «قرارداد اجرا» شامل شرط توقف و خروجی‌های مورد انتظار تعریف کنید تا بازیابی ممکن شود.
• از ابزارهایی استفاده کنید که تغییرات محیطی (مانند تغییرات فایل یا دیتابیس) را در یک دفتر کل (Ledger) مجزا از تاریخچه گفتگو ثبت می‌کنند.

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