بررسی‌های فنی: دسترسی به حافظهٔ بدون خطای عامل‌ها غیرممکن است

تصور کنید سیستمی بسازید که هر دستور شما را مانند یک قانون سخت‌گیرانه در کدنویسی اجرا کند و هرگز آن را فراموش نکند؛ در دنیای فعلی عامل‌های هوش مصنوعی، چنین چیزی وجود ندارد. طبق گزارشی که در ۱۴ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، تلاش‌های نه‌ماهه یک توسعه‌دهنده ثابت کرد که «سیستم حافظه‌ای که قادر باشد رفتار مدل را به‌طور کامل تغییر دهد، یک تک‌شاخ است»؛ یعنی محصولی که نمی‌تواند وجود داشته باشد. این گزارش با جزئیات توضیح می‌دهد که چرا صرفاً ذخیره و بازیابی داده‌ها نمی‌تواند کیفیت خروجی‌های خاص را تضمین کند.

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

زمینه‌ی حافظه در عامل‌ها

نویسنده برای رسیدن به این نتیجه، ابتدا بر بهینه‌سازی سیستم تمرکز کرد. او سیستم عامل‌محور خود را به یک «رژیم سخت» برد: حجم زیرساخت (Harness) را کاهش داد، تعداد زیر-عامل‌ها را کم کرد و مسئولیت‌های پراکنده را در هم ادغام نمود. هدف این بود که زیرساخت را حول یک هدف اصلی بازسازی کند: اجازه دادن به مدل برای استفاده حداکثری از توانایی‌های ذاتی و درونی خود.

این مسیر به یک پرسش بنیادی درباره هدف از حافظه رسید. فرض رایج این است که ذخیره و بازیابی اطلاعات، تمام وظیفه حافظه است. اما نویسنده متوجه شد که مشکل واقعی، بازیابی (Retrieval) نیست، بلکه این است که اطلاعات بازیابی‌شده چگونه برای ارضای خواسته‌های خاص و شخصی یک کاربر به کار گرفته می‌شوند. این چالش با تلاش‌هایی مانند پیاده‌سازی ۸ لایه حافظه در EdosAI برای تثبیت هویت عامل‌ها همسو است که سعی دارد از فراموشی شناختی مدل‌ها جلوگیری کند.

شکست «پرامپت کامل»

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

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

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

به همین دلیل، تمرکز از یک پرامپت واحد به «مداخله در فرآیند» تغییر کرده است. این کار شامل استفاده از فایل‌هایی مانند CLAUDE.md یا AGENTS.md است تا تعریف شود که معماری، کدنویسی و تست‌ها دقیقاً چگونه باید مدیریت شوند.

معماری تزریق دستورات

برای حل مشکل حافظه، نویسنده سیستمی متشکل از «اصول» و «مراحل» طراحی کرد تا ترجیحات تیم بدون ایجاد بار اضافی مدیریت شوند:

• اصول (Principles): این‌ها قوانینی هستند که باید در هر لحظه و در هر شرایطی اعمال شوند. تنها این دسته از قوانین شایستگی حضور در فایل CLAUDE.md را داشتند. نویسنده اشاره می‌کند که فایل CLAUDE.md اغلب به مکانی تبدیل می‌شود که محدودیت‌ها در آن رانده شده و انباشته می‌شوند، زیرا جای دیگری برای آن‌ها وجود ندارد.
• مراحل (Stages): این‌ها قوانینی هستند که عامل در ابتدای یک جلسه (Session) متوجه وجودشان می‌شود. وقتی یک مرحله خاص فرا می‌رسد، عامل قوانین مربوط به آن را می‌خواند و بر وضعیت فعلی اعمال می‌کند.

این سیستم تلاشی بود برای فاصله گرفتن از رویکرد «پرامپت‌های سنگین» — مشابه آنچه به «پرامپت سنگین استیگ» (Stig's heavy prompt) معروف است — که در آن حجم عظیمی از اطلاعات در پنجره زمینه (Context Window) رانده می‌شود. هدف این بود که دستور درست، دقیقاً در لحظه‌ای که عامل در حال بررسی یک تصمیم معماری خاص است، تزریق شود؛ زیرا نویسنده معتقد است اگر اطلاعات در آن لحظه دقیق حضور نداشته باشد، پاسخ واقعی حاصل نخواهد شد. در همین راستا، برخی ابزارها مانند Cortex سعی کرده‌اند با استفاده از SQLite حافظه محلی عامل‌های کدنویسی را بازسازی کنند تا دسترسی به داده‌های ساختاریافته را بهبود ببخشند.

کشف «تک‌شاخ»

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

برای اطمینان از اجرای این روند، نویسنده حتی یک اسکریپت نظارتی مستقر کرد تا اجرای بازبینی Codex را رصد کند. با این حال، برای هفته‌ها، حتی یک جلسه (Session) هم این رویه را به‌طور صحیح از ابتدا اجرا نکرد. با وجود اینکه قوانین تزریق شده بودند، ارسال شده بودند و توسط مدل خوانده شده بودند، هیچ اتفاقی نیفتاد. این شکست منجر به کاهش اعتماد به عامل شد؛ روندی که نویسنده پیش‌بینی می‌کند با هوشمندتر شدن مدل‌ها، حتی تقویت شود.

واقعیت آموزش مدل‌ها

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

امروزه حافظه پایه — یعنی ذخیره و یادآوری حقایق — به یک استاندارد تبدیل شده و در ChatGPT و Claude تعبیه شده است. برای اینکه حافظه ارزش افزوده ایجاد کند، باید هدفی شفاف و محدود داشته باشد، نه اینکه بخواهد رفتار بنیادی مدل را به‌طور کلی بازنویسی کند. در واقع، حافظه در عامل‌ها بیش از آنکه یک قابلیت دیتابیسی باشد، باید به عنوان یک پروتکل اعتماد بررسی شود تا از مسموم‌سازی داده‌ها و رفتارهای پیش‌بینی‌نشده جلوگیری شود.

به همین دلیل است که نویسنده این حافظه ایده‌آل را «تک‌شاخ» می‌نامد: حیوانی که وجود ندارد، اما هر شرکتی که واقعاً بتواند آن را بسازد، یک‌شبه به یک شرکت تک‌شاخ (Unicorn) تبدیل می‌شود.

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

گام بعدی شما

• به جای تلاش برای «اصلاح» مدل با حافظه، شروع به اندازه‌گیری کنید که کدام قانون در چه لحظه‌ای اجرا شد و جلوی چه خطایی را گرفت.
• از فایل‌های پیکربندی محیطی (مانند .md) برای تعریف استانداردهای سخت‌گیرانه استفاده کنید، اما انتظار اجرای ۱۰۰ درصدی نداشته باشید.
• روی تزریق دستورات در مراحل (Stages) تمرکز کنید تا پنجره متنی مدل را با اطلاعات غیرضروری پر نکنید.

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