تصور کنید برنامه‌نویسی هستید که دوشنبه با یک عامل کدنویسی توافق کرده است تا یک API عمومی را ثابت نگه دارد، اما همین عامل در روز چهارشنبه پیشنهاد اضافه کردن نقاط اتصال (Endpoints) جدید می‌دهد. این شکست رایج در گردش‌کارهای عامل‌محور، یک مشکل ذخیره‌سازی نیست، بلکه یک شکست در بازیابی اطلاعات است. در واقع، عامل «جلسه دوشنبه» را هرگز نخوانده است.
به نقل از گزارشی در dev.to که در ۶ اکتبر ۲۰۲۶ منتشر شد، راهکار این مشکل افزایش حافظه نیست، بلکه الزام به خواندن تصمیمات فعال پیش از شروع هر وظیفه است. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی حافظهٔ عامل‌ها اشاره کردیم، مشکل اصلی این است که اطلاعات در جایی وجود دارند، اما در لحظهٔ مناسب جلوی چشم مدل قرار نمی‌گیرند.
زمینه و بستر فراموشی
وقتی یک عامل (Agent) — شبیه دستیاری که هر روز حافظه‌اش پاک می‌شود و باید یادداشت‌های روز قبل را بخواند — تصمیم هفته گذشته را نقض می‌کند، اطلاعات معمولاً در تاریخچه چت، یک فایل یادداشت یا یک خلاصه موجود است. شکست اصلی اینجاست که هیچ مکانیزمی وجود ندارد که این اطلاعات را پیش از شروع جلسه جدید، مقابل مدل قرار دهد. این چالش با الگوی «تحویل شیفت» برای حل فراموشی عامل‌ها که پیش‌تر بررسی کردیم، شباهت زیادی دارد و بر اهمیت انتقال وضعیت بین جلسات تأکید می‌کند.
بسیاری از توسعه‌دهندگان به‌طور غریزی سعی می‌کنند با ایجاد فایل‌هایی مثل DECISIONS.md یا استفاده از پایگاه‌داده برداری (Vector Database) — که مثل یک فهرست هوشمند، مطالب مشابه را پیدا می‌کند — یا نوشتن خلاصه‌ای توسط یک جلسه برای جلسه بعدی، این مشکل را حل کنند. این روش‌ها مشکل ذخیره‌سازی را حل می‌کنند، اما ذخیره‌سازی هرگز بخش سخت ماجرا نبوده است. اگر عملیات خواندن به این وابسته باشد که عامل «به یاد آورد» فایلی را باز کند، دقیقاً در روزی که این اطلاعات حیاتی هستند، این مرحله نادیده گرفته خواهد شد.
خطر حافظه کاذب
عاملی که فراموش می‌کند، قابل مدیریت است؛ زیرا یا دوباره سؤال می‌پرسد یا اشتباهی آشکار می‌کند. اما عاملی که تصمیمی را که شما لغو کرده‌اید به یاد می‌آورد، بسیار خطرناک‌تر است. چنین عاملی با اطمینان کامل بر اساس قانون قدیمی عمل می‌کند و در خروجی‌اش هیچ نشانی از خطا دیده نمی‌شود.
ذخیره‌سازهای «فقط-افزودنی» (Append-only) این وضعیت را بدتر می‌کنند. وقتی یک تصمیم قدیمی و یک تصمیم جدید هر دو در تاریخچه وجود داشته باشند، هر دو مرتبط به نظر می‌رسند. در این حالت، مدل به‌طور خاموش یکی را انتخاب می‌کند و اغلب نسخه اشتباه را برمی‌گزیند. این عدم قطعیت در مدیریت وضعیت، دلیل اصلی این است که بسیاری از وظایف تغییر وضعیت در عامل‌های هوش مصنوعی با شکست مواجه می‌شوند.
اکثر توسعه‌دهندگان تلاش می‌کنند با افزودن یک فایل DECISIONS.md و یک خط در پرامپت سیستمی این مشکل را حل کنند. با این حال، این رویکرد شکست می‌خورد زیرا خواندن فایل همچنان اختیاری باقی می‌ماند و فایل‌ها تا زمانی که کوتاه شوند یا نادیده گرفته شوند، رشد می‌کنند. تصور کنید همکاری جدید به پروژه می‌پیوندد؛ او فقط به توده‌ای از یادداشت‌های قدیمی نیاز ندارد، بلکه باید دقیقاً بداند کدام قوانین در حال حاضر اجرایی هستند.
جزئیات راهکار: ADR مخصوص عامل‌ها
برای حل این بحران، نویسنده مقاله یک مدل اصلاح‌شده از «سوابق تصمیمات معماری» (ADR) را پیشنهاد می‌دهد که به‌طور خاص برای عامل‌ها طراحی شده است. این سوابق برخلاف نسخه‌های انسانی، به چهار فیلد اجباری نیاز دارند:
- تصمیم‌گیرنده (Decided by): تفکیک بین دستور انسانی و استنتاج عامل. برای مثال، تصمیمی که توسط «دانا (در جلسه ۲۰۲۶-۱۰-۰۵)» گرفته شده یک قانون است؛ اما حدس عامل در روز سه‌شنبه باید به عنوان یک «پیشنهاد» بازگردانده شود.
- وضعیت (Status): علامت‌گذاری ورودی‌ها به عنوان «فعال» (in force) یا «متضاد» (conflict). این کار مانع از آن می‌شود که مدل به‌طور خودسرانه و خام تناقضات را حل کند.
- زمان پایان (Ends when): تعیین یک شرط انقضا (مثلاً «زمانی که نسخه ۱ خاموش شود») تا رکوردها به یک پرامپت بیش از حد حجیم تبدیل نشوند.
- جایگزین (Replaces): بازنشسته کردن صریح تصمیمات قدیمی (مثلاً جایگزینی تصمیم «حفظ برابری نسخه ۱ و ۲» از تاریخ ۲۰۲۶-۰۸-۱۲) تا اطمینان حاصل شود که عامل هرگز دو قانون متضاد را به یک اندازه معتبر نمی‌بیند.
طبق این متدولوژی، نوشتن این سوابق باید وظیفه عامل در پایان هر جلسه باشد—مرحله‌ای که اغلب نادیده گرفته می‌شود. جملات تأییدشده توسط انسان به عنوان «تصمیم» ثبت می‌شوند و نتایج عامل تا زمان تأیید انسانی، در وضعیت «پیشنهاد» باقی می‌مانند. این کار مانع از آن می‌شود که حدس عامل در روز سه‌شنبه، به یک قانون تغییرناپذیر در روز چهارشنبه تبدیل شود. در واقع، این رویکرد با مدیریت دسترسی بر اساس هزینه بازگشت از خطا همسو است تا ریسک تغییرات نادرست در وضعیت پروژه کاهش یابد.
این تغییر رویکرد، صنعت را از امید به «پنجره متنی نامحدود» (Infinite Context) — که مثل میز کاری است که هرچه بزرگ‌تر شود، پیدا کردن وسایل سخت‌تر می‌شود — به سمت مدیریت وضعیت قطعی (Deterministic State Management) می‌برد. با تبدیل تصمیمات به یک پایگاه‌داده نسخه‌بندی‌شده به جای تاریخچه چت، تیم‌ها می‌توانند بدون از دست دادن همراستاسازی پروژه، بین مدل‌هایی مثل Claude، ChatGPT، Codex یا Cursor جابه‌جا شوند.
برای کسانی که قصد پیاده‌سازی این روش را دارند، پلتفرم Arroway چارچوبی ارائه داده که جلسات را با خواندن پروژه بر اساس اولویت وظیفه آغاز می‌کند. این سیستم تضمین می‌کند که یک عامل نمی‌تواند روی قوانین موجود بازنویسی کند، مگر اینکه ابتدا وضعیت جاری پروژه را خوانده باشد. این سازوکار هم برای کاربران تک‌نفره و هم برای تیم‌ها کاربرد دارد، زیرا خواننده در واقع همان عاملی است که فردا بازمی‌گردد.
توسعه‌دهندگان اکنون می‌توانند این گردش‌کارهای بهینه را از طریق arroway.app/install ادغام کنند تا چرخه بازگشت خطاهای اصلاح‌شده (Regressions) ناشی از هوش مصنوعی را متوقف کنند.
گام بعدی شما
- ساختار ADR پیشنهادی (شامل فیلدهای وضعیت و جایگزین) را در پروژه‌های فعلی خود پیاده کنید.
- در پرامپت سیستمی عامل خود، مرحلهٔ «خواندن سوابق تصمیمات» را به عنوان اولین گام اجباری تعریف کنید.
- از ابزارهایی مثل arroway.app برای اتوماسیون این چرخه استفاده کنید تا از بازگشت خطاهای اصلاح‌شده (Regressions) جلوگیری کنید.
اما داستان سخت‌افزاری این تحول و نحوه مدیریت حافظه در سطح تراشه حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی حافظه‌های HBM در پردازنده‌های جدید مراجعه کنید.
گفتگو