اگر امروز یک عامل هوش مصنوعی را برای مدیریت پروژه‌های بلندمدت به کار گرفته‌اید، احتمالاً با انباشت دستوراتی مواجه شده‌اید که دیگر صادق نیستند اما مدل همچنان از آن‌ها پیروی می‌کند. این پدیده که «انحراف دستوری» (Instruction Drift) نامیده می‌شود، می‌تواند باعث شود مدل در لحظه‌ای حساس، تصمیمی بر اساس یک برنامهٔ منقضی‌شده از ۶ ماه پیش بگیرد. در واقع، فایل‌های حافظهٔ عامل‌ها درست مانند کدهای قدیمی (Legacy Code) دچار پوسیدگی می‌شوند. استثناهای موقت به قوانین دائمی تبدیل شده و برنامه‌های قدیمی در فایل‌های زمینه باقی می‌مانند، حتی زمانی که پروژه تغییر جهت داده است. ممکن است بعداً قانونی قوی‌تر اضافه شود، اما نسخه ضعیف‌تر همچنان در نزدیکی آن باقی می‌ماند. طی چندین ماه، دیگر مشخص نیست کدام خط فرمان‌دهه است و کدام‌یک صرفاً بخشی از تاریخچه است. در چنین شرایطی، هوش مصنوعی ممکن است از قانونی پیروی کند که دیگر درست نیست، چون هیچ‌کس آن را به‌عنوان «منقضی‌شده» علامت‌گذاری نکرده است.
بر اساس گزارش منتشرشده در dev.to، یک توسعه‌دهنده در تاریخ ۱ ژوئیه ۲۰۲۶ ابزاری برای بازرسی حافظه ساخت تا دستوراتی که عامل باید پیروی از آن‌ها را متوقف کند، شناسایی کند. اما نتیجه‌ای طنزآمیز به‌دست آمد: ابزار، شعار تبلیغاتی خودِ پروژه را به‌عنوان یک «دستور منقضی» علامت‌زد، در حالی که یک خطای عملیاتی واقعی در همان فایل را نادیده گرفت. این شکست دقیقاً همان شکافی است که بین تطبیق سطحی الگوها و درک واقعی معنایی قرار دارد و دشواری مدیریت حافظه بلندمدت هوش مصنوعی را برجسته می‌کند. این موضوع یادآور چالش‌های مشابه در سیستم‌های خود-اصلاح‌گر است؛ همان‌طور که در بررسی حفره‌های استدلالی پروژه Kuro مشاهده شد، بسیاری از وعده‌های اصلاحی مدل‌ها در عمل با شکست مواجه می‌شوند.
این مشکل تنها مختص ماشین‌ها نیست؛ انسان‌ها نیز گاه دستورات قدیمی را در ذهن دارند و آن‌ها را بازخوانی نمی کنند تا زمانی که یک اتفاق غیرمنتظره، واکنشی تاریخ‌گذشته را فعال کند. آزمون واقعی حافظه، چه انسانی و چه ماشینی، توانایی تکرار داده‌های ذخیره‌شده نیست. بلکه توانایی تشخیص این است که کدام قانون هنوز پابرجاست و کدام‌یک به‌طور خاموش باطل شده است، و اینکه بتوان در لحظه‌ای که تجربه قبلی با وضعیت فعلی تطبیق ندارد، از قانون مرده عبور کرد. عاملی که فقط قادر به بازپخش پاسخ‌های ذخیره‌شده است، در مواجهه با ریسک‌های دنیای واقعی و وقوع یک خطای پیش‌بینی‌نشده (Oops)، فلج می‌شود.
توسعه‌دهنده این پروژه بر این فرض استوار بود که «مرتبط بودن» (Relevance) با «صلاحیت» (Authority) متفاوت است. در یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — ممکن است یک یادداشت قدیمی، یک سیاست فعلی، یک ترجیح کاربر و یک توصیف ابزار، همگی «مرتبط» باشند و هم‌زمان در پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است با فضای محدود برای چند ورق کاغذ — قرار گیرند. اما تطبیق با یک وظیفه، به معنای داشتن اجازه برای هدایت اقدام بعدی نیست. این تمایز در دسترسی به داده‌های مشتری، جابجایی وجه، پیام‌رسانی خارجی، استقرار کد (Deployments) و سایر ابزارهای حساس حیاتی است؛ جایی که عبارت «مدل یک حافظه مرتبط را دید» توجیه کافی برای یک اقدام اشتباه نیست.
طبق اعلام نویسنده، هدف این ابزار ایجاد یک «نقشه صلاحیت» (Authority Map) است تا انسان بتواند بررسی کند کدام خطوط وزن بیشتری دارند، نه اینکه یک گواهینامه ایمنی دوتایی (Binary Safety Certification) ارائه دهد. هدف این است که گزارشی تهیه شود تا انسان آن را بازبینی کند و این تظاهر که هر خط در فایل حافظه اثر یکسانی دارد، برطرف شود. ارزش فعلی ابزار در این نیست که ماشینی declaring کند هوش مصنوعی «ایمن» است، بلکه در این است که نقشه‌ای ارائه دهد و ریسک‌های شناخته‌شده را برای نظارت انسانی علامت‌گذاری کند.
معماری فنی
این ابزار ادعای تایید ایمنی مطلق ندارد، بلکه عملیات محدودی را برای ترسیم منطق داخلی فایل‌های حافظه انجام می‌دهد:
- تکه‌بندی حافظه: تقسیم فایل‌های دستورالعمل بزرگ به آیتم‌های کوچک و مجزایی که قابلیت بازرسی داشته باشند.
- طبقه‌بندی صلاحیت: دسته‌بندی هر آیتم بر اساس سطح قدرت و اثرگذاری:
- قانون حاکم: دستوراتی با صلاحیت بالا که رفتار کلی عامل را هدایت می‌کنند.
- قانون تایید-اول: دستوراتی که پیش از اجرا حتماً نیاز به تایید انسانی دارند.
- فقط زمینه: اطلاعاتی که برای درک پیش‌زمینه مفیدند اما قدرت حاکمیتی ندارند.
- دستور احتمالا جایگزین‌شده: قوانینی که ممکن است توسط دستورات جدیدتر جایگزین یا منسوخ شده باشند.
- تشخیص ریسک: شناسایی الگوهای خطرناک پوشش‌داده‌شده و تبدیل این ریسک‌ها به «گیت‌های تایید» (Verification Gates). این رویکرد متکی بر گیت‌های فعال، مشابه استراتژی‌هایی است که در جایگزینی نظارت‌های غیرفعال با گیت‌های اعتبارسنجی فعال منجر به بهینه‌سازی قابل‌توجه کدهای عامل‌های هوشمند شد.
- ترسیم رفتاری: بررسی و ترسیم اینکه کدام دستورات در عمل شکل نهایی رفتار عامل را می‌سازند.
آزمایش عملی (Dogfooding)
توسعه‌دهنده برای تست سیستم، ابزار را روی دو فایل اصلی در محیط کاری خود اجرا کرد:
۱. فایل استارت-آپ (Startup File): این اولین فایلی است که عامل‌ها می‌خوانند. این فایل تعریف می‌کند که زمینه چگونه بازیابی شود، چه قوانینی نشست (Session) را محدود می‌کنند، چه چیزهایی نباید فرض شوند و حافظه قدیمی چگونه مدیریت شود.
۲. فایل وضعیت زنده (Live State File): این فایل کارهای جاری، تصمیمات اخیر، مرزهای پروژه و گام‌های بعدی فعال را ردیابی می‌کند.
این دو فایل فراتر از ارائه یادداشت ساده، در واقع رفتار عامل را حاکم می‌کنند. 
فایل استارت-آپ ۵۲ آیتم حافظه تولید کرد. طبقه‌بند ۲۴ مورد را «حاکم» و ۲۸ مورد را «فقط زمینه» شناساند. این موارد را بیشتر تقسیم کرد: ۴۸ مورد «شکل‌دهنده خواندن» و ۴ مورد «شکل‌دهنده اقدام». ابزار گزارش داد که هیچ یافته‌ای وجود ندارد و وضعیت ریسک «پایین» است. با این حال، این یک «منفی کاذب» (False Negative) بود؛ توسعه‌دهنده می‌دانست یک برنامه منقضی از ژوئن ۲۰۲۶ در فایل است که تقریباً باعث نشت خطا در اجرا شده بود. ابزار این مورد را گم کرد چون برنامه با نثر معمولی نوشته شده بود و کلمات کلیدی مثل «منقضی» یا بیانیات صریح درباره جایگزینی یک قانون با قانون دیگر در آن نبود. در واقع، متن همان‌طور نوشته شده بود که آدم‌ها هنگام فکر کردن با صدای بلند می‌نویسند.
فایل وضعیت زنده پیچیده‌تر بود و ۵۳۸ آیتم تولید کرد: ۱۱۷ مورد حاکم، ۱۶ مورد تایید-اول و ۴۰۳ مورد زمینه. ابزار ۲۱ گیت تایید شناسایی کرد، اما ۲ مورد «دستور منقضی» را به‌اشتباه گزارش داد (مثبت کاذب). با این حال، نقشه صلاحیت روحیتی داد که توسعه‌دهنده نمی‌توانست به‌تنهایی در ذهن نگه دارد. این ابزار قوانین هدایتی را از توده‌ای به‌هم‌ریخته از زمینه جدا کرد و به‌عنوان یک ابزار کاربردی برای هر کسی که به تیمی با فایل‌های طولانی مانند CLAUDE.md یا AGENTS.md یا قوانین Cursor می‌پیوندد، عمل کرد.
مکانیزم شکست
شکست اصلی ابزار، اشتباه گرفتن «دسته» با «عضو دسته» بود. ابزار شعار «دستورات قدیمی را پیدا کنید که هوش مصنوعی شما باید پیروی از آن‌ها را متوقف کند» را صرفاً چون کلمات «دستورات قدیمی» و «توقف پیروی» در آن بود، به عنوان یک دستور منقضی شناسایی کرد.
این موضوع شکافی را در منطق تشخیص‌دهنده برجسته کرد: ابزار به جای روابط صلاحیت، بر واژگان سطحی (Lexical Matching) تکیه داشت. مدل شکست به این صورت بود:
- ورودی: عبارت «دستورات قدیمی»
- مشاهده ابزار: واژگان مربوط به منقضی بودن
- استنتاج ابزار: پس این خودِ یک دستور منقضی است
- مدرک مفقود: کدام دستور جدیدتر جایگزین این شده است؟
برای اینکه یک قانون «منقضی» تلقی شود، باید شواهدی از یک «رویداد صلاحیت» وجود داشته باشد؛ یعنی قانون جدیدتری که قانون قدیمی را جایگزین، منسوخ، محدود یا متناقض کرده باشد. ابزار موضوعِ «دستورات قدیمی» را دید و استنتاج کرد که خودِ آن متن یک دستور قدیمی است. این ثابت می‌کند ابزاری می‌تواند تمام تست‌های طراحی‌شده را پاس کند اما وقتی دنیای واقعی مشکلی را به روشی متفاوت توصیف می‌کند، شکست بخورد. توسعه‌دهنده اشاره کرد که این الگوی شکست را قبلاً هم دیده است: گیتی که تست‌های طراحی‌شده را پاس می‌کند اما در یک مورد استثنایی (Hold-out case) شکست می‌خورد، یا امتیازدهنده‌ای (Scorer) که با تغییر داده‌ها فرو می‌پاشد.
اصلاح تدریجی
برای رفع مثبت‌های کاذب، توسعه‌دهنده «قرارداد دستورات منقضی» را سخت‌گیرانه‌تر کرد. او به‌جای حذف دستی آن شعار (که تکرار همان شکست قبلی بود)، شرط اثبات را تغییر داد. استخراج‌کننده دیگر با عبارت‌های ساده فعال نمی‌شود، بلکه به زبان صریح جایگزینی نیاز دارد، مانند:
- «جایگزین شد» (superseded)
- «منسوخ شد» (deprecated)
- «جایگزین شده با» یا «Replace with»
- «دیگر معتبر نیست» (no longer valid)
- «منقضی» (obsolete)
- برچسب‌های صریح مانند «دستور قدیمی:»
با این تغییر، مرز از «آیا متن کلمات منقضی‌مانند دارد؟» به «آیا متن مدرکی بر جایگزینی واقعی یک قانون ارائه می‌دهد؟» تغییر کرد و طبقه‌بند از بررسی‌های متنی شل دست پرداخت. برای اطمینان از اینکه این اصلاح صرفاً ابزار را «ساکت‌تر» نکرده و مشکل را بدتر ننموده است، دو تست رگرسیون اضافه شد:
۱. تست ذکر موضوع: ثابت می‌کند که اشاره‌های شعارگونه به دستورات قدیمی دیگر علامت‌گذاری نمی‌شوند.
۲. تست قانون جایگزین‌شده: ثابت می‌کند که قوانین واقعاً جایگزین‌شده همچنان شناسایی می‌شوند.
مجموعه تست‌ها اکنون ۴ مورد پاس و ۱ مورد شکست مورد انتظار را نشان می‌دهد. پس از این به‌روزرسانی، فایل وضعیت زنده هیچ مثبت کاذبی نداشت و وضعیت آن از «نیاز به بازبینی» به «قابل استفاده با گیت‌ها» تغییر کرد.
شکاف معنایی باقی‌مانده
مسئله عمیق‌تر — تشخیص چارچوب‌های منقضی شده‌ای (Stale Framing) که با نثر طبیعی نوشته شده‌اند — همچنان حل‌نشده است. این همان «شکست مورد انتظار» است که توسعه‌دهنده عمداً آن را sichtbar (مرئی) نگه داشته تا با یک جمله مبهم در نقشه راه، یک باگ را پنهان نکند. برای حل این مورد، لایه‌ای در معماری آینده به نام «مسیر A» پیشنهاد شده است: یک لایه تضاد/جایگزینی معنایی.
این سیستم پیشنهادی صرفاً از یک LLM حدس نمی‌گیرد و به آن اعتماد نمی‌کند، بلکه از یک ساختار منضبط پیروی می‌کند:
- پیشنهاددهنده معنایی: یک LLM تضادها، جایگزینی‌ها یا انحرافات صلاحیت را در نثر شناسایی می‌کند.
- تأیید قطعی (Deterministic): سیستم نیاز به تأیید بر اساس شواهد سخت و مشخصی دارد که در فایل یافت شود.
- گزارش‌دهی مبتنی بر رسید: ادعا، مدرک و سطح عدم قطعیت را به‌طور جداگانه گزارش می‌کند.
این ساختار تضمین می‌کند که لایه معنایی هرگز بدون یک «رسید» قابل تأیید، تبدیل به یک گیت عملیاتی خاموش نشود. تا زمانی که این لایه وجود نداشته باشد، ارزش ابزار در همان نقشه صلاحیت و شناسایی ریسک‌های الگوهای شناخته‌شده باقی می‌ماند.
به‌سوی اعتبارسنجی خارجی
نویسنده معتقد است بازرسی فایل‌های شخصی (Dogfooding) هدف خوبی برای شروع است اما اثبات نهایی نیست، چرا که او خودش نویسنده فایل‌هاست و نقشه ذهنی از آنچه فعلاً معتبر است و آنچه تاریخی است دارد. برای اعتبارسنجی واقعی، ابزار باید روی فایل‌های حافظه‌ای که توسعه‌دهنده ننوشته و سیستم‌هایی که نمی‌شناسد، تست شود.
فایل‌های هدف برای تست‌های آینده شامل موارد زیر است:
- فایل‌های
CLAUDE.md - فایل‌های
AGENTS.md - فایل‌های قوانین Cursor
- فایل‌های دستورالعمل داخلی تیم‌ها
- تنظیمات عامل‌های قدیمی با تصمیمات انباشته‌شده
هدف این است که مشخص شود آیا نقشه صلاحیت به یک غریبه کمک می‌کند چیزهایی را ببیند که قبلاً به‌وضوح نمی‌دید یا خیر. این پروژه در حال حاضر به‌عنوان رکورد یک «حلقه اصلاح عمومی» است: یک نقشه صلاحیت مفید، یک باگ الگویی حل‌شده و یک شکاف معنایی صادقانه و حل‌نشده. توسعه‌دهنده باور دارد که اگر خود-اصلاحی معنایی داشته باشد، باید رسیدهای کافی از شکست‌ها باقی بگذارد تا شکست تبدیل به یک «به‌روزرسانی» شود، نه فقط یک داستان.
کالیبراسیون بازار
در حالی که مرزهای فنی روشن هستند، مرزهای بازار همچنان نامعلوم است. توسعه‌دهنده از تظاهر به قطعیت درباره قیمت‌گذاری برای ابزاری که فقط روی یک سیستم اجرا شده، اجتناب کرده است. او به‌جای گمانه‌زنی، دو درخواست مشخص از جامعه دارد:
۱. بازرسی مستقیم: درخواست دریافت فایل‌های حافظه عامل‌های خارجی (مانند CLAUDE.md یا قوانین Cursor) تا ببیند آیا نقشه صلاحیت چیزی را آشکار می‌کند که سازنده اصلی نتوانسته بود به‌وضوح ببیند. در این مرحله، کاربردی بودن ابزار بر فروش مقدم است.
۲. مدلسازی حکمرانی: مشورت با کسانی که بررسی‌های امنیتی یا گردش‌کارهای حاکمیتی تخصصی را به شغل تبدیل کرده‌اند. به‌طور مشخص، او می‌خواهد بداند چگونه نسخه اول محصول را مدلسازی کند وقتی خروجی کار یک «نقشه ریسک» است (نه یک «تیک سبز جادویی» برای ایمنی) و چگونه آن را بدون بزرگ‌نمایی مرزهای فعلی ابزار، قیمت‌گذاری کند.
با یادگیری در فضای عمومی و به اشتراک گذاشتن مکانیسم‌ها و رسیدهای پروژه، توسعه‌دهنده قصد دارد ابزاری بسازد که به کاربرانی کمک کند که خودِ او نیستند. وضعیت فعلی پروژه: یک حلقه اصلاح عمومی، یک نقشه صلاحیت مفید و یک لایه معنایی حل‌نشده.
گام بعدی شما
- اگر از فایل‌های
.mdبرای مدیریت دستورات عامل‌های خود استفاده می‌کنید، سعی کنید دستورات متناقض را با برچسب‌های صریح مانند[Deprecated]یا[Superseded]علامت‌گذاری کنید. - ساختار فایل‌های حافظه خود را از حالت «یادداشت‌های پراکنده» به «سلسله‌مراتب صلاحیت» (قوانین حاکم در مقابل داده‌های زمینه) تغییر دهید.
- در صورت استفاده از Cursor یا Claude، یک فایل
AGENTS.mdمجزا برای ثبت تصمیمات معماری ایجاد کنید تا از انحراف دستوری در طول زمان جلوگیری شود.
اما چالش واقعی زمانی است که این حافظه‌ها را با پایگاه‌های داده برداری ترکیب می‌کنیم — در گزارش بعدی، اثر RAG بر دقت بازیابی دستورات منقضی را بررسی خواهیم کرد.
گفتگو