اگر برای مدیریت پروژه‌های خود به عامل‌های هوش مصنوعی تکیه می‌کنید، باید بدانید که این ابزارها می‌توانند با اطمینانی کامل، بر اساس مستنداتی کاملاً منقضی‌شده تصمیم بگیرند. خطر اصلی زمانی رخ می‌دهد که حافظهٔ عامل با کد واقعی فاصله می‌گیرد، اما سیستم‌های نظارتی هیچ خطایی گزارش نمی‌کنند. در ۲۱ اوت ۲۰۲۶، تلاش یک توسعه‌دهنده برای شناسایی حافظه‌های کهنه در هوش مصنوعی ثابت کرد که روش‌های پیچیده و هوشمند (Heuristics) اغلب در جایی شکست می‌خورند که روش‌های ساده و خسته‌کننده موفق می‌شوند. هدف این بود که از تبدیل شدن عامل‌های هوش مصنوعی به موجوداتی «مطمئن اما اشتباه» جلوگیری شود؛ وضعیتی که در آن عامل بر اساس مستنداتی قدیمی عمل می‌کند که دیگر بازتاب‌دهنده وضعیت واقعی کد منبع نیستند.
در دنیای گردش‌کارهای عامل‌محور (Agentic)، عامل (Agent) — شبیه دستیاری که قبل از هر اقدام، ابتدا یادداشت‌های روی میز را می‌خواند تا راه را پیدا کند — پیش از هر عملیاتی، حافظهٔ متنی خود را بررسی می‌کند. این یادداشت‌ها شامل نحوه عملکرد یک اسکریپت، استدلال پشت یک تصمیم فنی، یا این موضوع است که کدام فایل مالک منطق خاصی است. طبق گزارش منتشرشده در dev.to، نبودِ یک یادداشت تنها یک مزاحمت کوچک است چون عامل را مجبور می‌کند خودش پاسخ را جست‌وجو کند؛ اما یک یادداشت «کهنه» یا منقضی‌شده، یک شکست بحرانی است. این وضعیت باعث ایجاد توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌شود و منجر به اجرای نادرست کدها بر اساس منطق قدیمی می‌گردد. این چالش‌های عملیاتی در مدیریت حافظه، در کنار ریسک‌های امنیتی دسترسی به فایل‌ها، اهمیت نظارت دقیق بر رفتار عامل‌ها را دوچندان می‌کند؛ موضوعی که در بررسی استفاده از فایل‌های تله برای سنجش امنیت سیستم‌فایل در محیط‌های ایزوله به تفصیل به آن پرداختیم.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی مدیریت وضعیت در مدل‌های زبانی اشاره کردیم، تکیه بر تحلیل‌های معنایی برای نگهداری سیستم‌های پیچیده همیشه پاسخگو نیست. برای حل این مشکل، توسعه‌دهنده مذکور سه روش خاص را روی ۵۰ جفتِ «یادداشت-منبع» واقعی آزمایش کرد. اولین روش، یک بررسی قطعی (Deterministic) و منطقی بود: اگر یادداشت به نام یک تابع خاص، یک فلگ (مانند --flag) یا یک عبارت functionName() اشاره داشت، سیستم بررسی می‌کرد که آیا آن رشته متنی دقیق هنوز در فایل وجود دارد یا خیر. نتیجه این بررسی صفر بود؛ نه به این دلیل که یادداشت‌ها به‌روز بودند، بلکه چون خطرناک‌ترین نوع کهنگی، از نوع «افزایشی» است.
کهنگی افزایشی زمانی رخ می‌دهد که یک فایل قابلیت‌های جدیدی پیدا کند — مثلاً یک زیردستور (Subcommand) جدید یا یک فلگ مالکیت — اما یادداشت قدیمی هرگز به آن اشاره نکند. در یک مورد خاص، اسکریپتی در سکوت یک زیردستور جدید و یک فلگ مالکیت جدید دریافت کرد. یادداشت توصیفی آن اسکریپت هیچ چیز غلطی نمی‌گفت؛ هر کلمه‌ای که در آن بود همچنان درست بود. تفاوت در این بود که یادداشت ۴ دستور را لیست می‌کرد در حالی که حالا ۶ دستور وجود داشت. چون متن موجود در یادداشت همچنان صادق بود، هیچ تضادی برای یک اسکریپت قطعی وجود نداشت تا آن را پیدا کند. در نتیجه، عامل از ویژگی‌های جدید بی‌خبر ماند و عملاً بر اساس یک «حقیقت ناقص» فعالیت کرد.
دو روش جایگزین دیگر نیز بر اساس معیارهای جایگزین (Proxy Metrics) آزمایش شدند تا زوال حافظه شناسایی شود، اما هر دو در اندازه‌گیری دقیق کهنگی شکست خوردند:
- تعداد ارجاعات (Mention Count): در این روش، فایل‌ها بر اساس تعداد یادداشت‌هایی که به آن‌ها ارجاع داده بودند رتبه‌بندی شدند، با این فرض که فایل‌های پرتردد احتمال کهنگی بیشتری دارند. اما این روش شکست خورد زیرا فایل‌هایی که بیشترین ارجاع را دارند، معمولاً همان‌هایی هستند که افراد مدام آن‌ها را به‌روز می‌کنند و در نتیجه تازه‌ترین بخش‌های سیستم هستند. این متد حتی یک مورد «مثبت کاذب» را بالاتر از یک مورد «مثبت واقعی» رتبه‌بندی کرد.
- Fan-in: در این رویکرد، یادداشت‌ها بر اساس تعداد یادداشت‌های دیگری که به آن‌ها اشاره می‌کردند رتبه‌بندی شدند. این روش حتی «رجیستری مرکزی» — که تک‌فایلی با بیشترین بار عملیاتی در کل سیستم بود — را پایین‌تر از نویزهای سیستمی رتبه‌بندی کرد. چون این فایل مدام مورد ارجاع قرار می‌گرفت و مدام تغییر می‌کرد، این معیار نتوانست هیچ‌کدام از این دو عامل را به‌درستی تشخیص دهد.
در نهایت، تنها سیستمی که جواب داد، یک مهر تاریخ دستی بود. انسان تاریخی را روی یادداشت می‌زند و می‌گوید «من این را تأیید کردم» و ماشین این تاریخ را با آخرین زمان تغییر فایل مقایسه می‌کند. این مقایسه ساده، یک پرسش معنایی پیچیده درباره «قصد و نیت» را به یک مقایسه عددی و ساده تبدیل کرد. این سیستم در یک روز ۴۸ مورد نیازمند بررسی را شناسایی کرد که نویسنده آن‌ها را به صفر رساند. این موارد شامل دو مورد کهنگی افزایشی بود که متدهای هوشمند به‌طور کامل از آن‌ها غافل شده بودند.
در طول این مسیر، ابزار شناسایی سه بار دچار نقص فنی شد. هر یک از این خرابی‌ها باعث شد ابزار کمتر از حقیقت را گزارش کند:
۱. یک فیلتر تاریخ که به‌طور بی‌صدا جست‌وجو را زودتر از موعد متوقف می‌کرد.
۲. مهری که سیستم نمی‌توانست آن را دوباره بخواند و در نتیجه برای ۱۵ فایل بدون مهر، گزارش «موفقیت» صادر کرد.
۳. یک لنگر زمانی به نیمه‌شب که گزارش‌های مربوط به فایل‌هایی که در همان روز روی آن‌ها کار می‌شد را ساکت می‌کرد.
چون «صفر بودن یافته‌ها» و «خراب بودن ابزار» از بیرون کاملاً یکسان به نظر می‌رسند، اکنون این ابزار تا زمانی که ثابت نکند واقعاً جست‌وجو کرده است، گزارش صفر نمی‌دهد.
این یافته‌ها این فرض را که نگهداری هوش مصنوعی می‌تواند به‌طور کامل از طریق تحلیل‌های معنایی خودکار شود، تغییر می‌دهد. این موضوع نشان می‌دهد که برای حافظه‌های حساس در سیستم‌های عامل‌محور، حضور انسان در چرخه (Human-in-the-loop) نه یک گلوگاه، بلکه یک ضرورت برای تأیید نیت و صحت است. برای توسعه‌دهندگانی که سیستم‌های عامل‌محور می‌سازند، این به معنای سرمایه‌گذاری روی متادیتای «خسته‌کننده» به‌جای روش‌های پیچیده است. ریسک اینکه ابزاری در حالی که خراب است گزارش «صفر» بدهد، بسیار بیشتر از هزینه یک بررسی دستی تاریخ است.
باید منتظر الگوهای نوظهور در «بهداشت حافظه» برای مدل‌های زبانی بزرگ (LLMs) بود، زیرا صنعت در حال حرکت از RAG ساده به سمت مدیریت وضعیت بلندمدت در سیستم‌های عامل‌محور است.
گام بعدی شما
- در سیستم‌های عامل‌محور خود، به‌جای تکیه بر تحلیل‌های معنایی برای به‌روزرسانی حافظه، از متادیتای ساده مثل مهر تاریخ (Timestamp) استفاده کنید.
- فرآیند تأیید انسانی (Human-in-the-loop) را برای مستندات حساس حافظه اجباری کنید تا از کهنگی افزایشی جلوگیری شود.
- ابزارهای نظارتی خود را طوری طراحی کنید که در صورت عدم یافتن خطا، «اثباتِ جست‌وجو» ارائه دهند تا نقص فنی ابزار با نبودِ خطا اشتباه نشود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو