چرا دسترسی به متن جلسات پیشین عملکرد عامل‌های کدنویسی را تخریب می‌کند؟

اگر تصور می‌کنید دسترسی کامل عامل‌های هوش مصنوعی به تاریخچهٔ تمام گفتگوهای پیشین، آن‌ها را هوشمندتر می‌کند، احتمالاً در حال هدر دادن بودجهٔ توکن‌های خود هستید. طبق تحلیل فنی منتشرشده در ۳ جولای ۲۰۲۶ توسط Agentics، فراهم کردن دسترسی جست‌وجو به متن جلسات پیشین برای عامل‌ها، در وظایف مهندسی نرم‌افزار (SWE) هیچ بهبود عملکردی ایجاد نمی‌کند، به‌ویژه زمانی که سایر اشکال زمینه (Context) در دسترس باشند. در واقع، این رویکرد می‌تواند کیفیت خروجی مدل‌ها را کاهش دهد.

توهم «حافظه جلسات»

برای بسیاری از تیم‌های توسعه، این باور شهودی وجود داشت که متن جلسات (Session Transcripts) مانند «نفت جدید» است؛ منبعی که حاوی داده‌های حیاتی درباره قصد کاربر و رویکردهایی است که در نهایت رد شده‌اند. نویسنده این تحلیل می‌گوید که زمانی خود چنان به این ایده باور داشت که شرکتش یک محصول کامل را بر پایه این مفهوم ساخت و استدلال می‌کرد که متن جلسات حتی از خودِ کد هم ارزشمندتر است.

این فرض به ایجاد معماری‌های پیچیده‌ای منجر شد که هدفشان بیرون کشیدن تعاملات پیشین و ارائه آن‌ها به عامل بود. تنظیمات رایج در این مسیر اغلب شامل موارد زیر است:

• ذخیره تمام متن جلسات در سطح سازمان در یک پایگاه داده.
• پیاده‌سازی لایه جست‌وجو با استفاده از جست‌وجوی برداری (Vector Search)، الاستیک‌سرچ (Elastic Search) یا جست‌وجوی SQL (برخی تیم‌های بلندپرواز حتی از هر سه روش به‌طور همزمان استفاده می‌کردند).
• ادغام پایگاه‌داده‌های گراف برای ایجاد ارتباطات عمیق‌تر بین مفاهیم.
• در دسترس قرار دادن این داده‌ها از طریق پروتکل زمینه مدل (MCP) یا یک رابط خط فرمان (CLI) با مهارت‌های خاص.

این ابزارها که مشابه قابلیت‌های موجود در Claude Code هستند، تلاش می‌کنند تا به عامل‌ها یک «حافظه بلندمدت» ببخشند. با این حال، تیم Agentics پس از چندین ماه آزمایش (در دو حالت با دسترسی و بدون دسترسی به جست‌وجوی جلسات) دریافت که این ابزارها اغلب مانند «تخته-سیاه‌هایی بی‌معنی و شبه‌تصادفی» عمل می‌کنند. در برخی موارد، این دسترسی اضافی حتی باعث بدتر شدن عملکرد مدل‌ها شده است.

مکانیسم تقطیر اطلاعات

ریشه مشکل در نحوه ساختار جریان‌های کاری حرفه‌ای کدنویسی در دنیای امروز نهفته است. در محیطی که عامل‌ها بخش اعظم کدها را تولید می‌کنند، این تیم بر سیستمی تاکید دارد که در آن دیگر کدی را به‌صورت دستی نمی‌نویسند. در عوض، آن‌ها اولویت را بر تولید «مصنوعات باکیفیت» (High-quality Artifacts) می‌گذارند تا درخواست‌های ادغام (PR) خوانا و قابل فهم باشند.

اطلاعات ارزشمند یک جلسه پیش از این در موارد زیر تقطیر و خالص شده‌اند:

• مستندات جامع فنی.
• پیام‌های دقیق و تفصیلی کامیت (Commit Messages).
• متادیتای باکیفیت در درخواست‌های ادغام (PR).

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

شکست «باغبانی حافظه»

علاوه بر این، مدل‌ها از یک نقص بنیادی به نام نبود «باغبانی حافظه» (Memory Gardening) رنج می‌برند. عامل‌ها نمی‌توانند به‌طور خودکار زمینه‌های قدیمی، منسوخ یا نادرست را از پنجره ورودی خود حذف کنند. تیم Agentics در بررسی هزاران جلسه مشاهده کرد که عامل‌ها هرگز موفق نشدند زمینه اضافی را حذف کنند؛ شکستی که با مهندسی پرامپت‌های هوشمندانه نیز قابل حل نیست. این چالش با مسئله فراموشی در محیط‌های Stateless گره خورده است که در آن نبود وضعیت پایدار باعث اتلاف زمان و منابع می‌شود.

به دلیل اینکه عامل‌ها فاقد وضعیت (State) هستند، مجبورند فرض کنند هر آنچه در پنجره زمینه ورودی قرار دارد، «حقیقت مطلق» (Ground Truth) است. این وضعیت منجر به پدیده‌ای به نام «انحراف در قصد» (Intent Drift) می‌شود که با ویژگی‌های زیر شناخته می‌شود:

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

تیم Agentics اشاره کرد که در حال حاضر، هیچ‌کدام از بنچ‌مارک‌های کدنویسی فرض نمی‌کنند که داده‌های ورودی فاسد یا اشتباه باشند. در واقع، مدل‌ها اغلب به‌دلیل این‌که فرض کنند زمینه ارائه شده اشتباه است، جریمه می‌شوند. این یک تضاد در تراز (Alignment Conflict) ایجاد می‌کند؛ به‌طوری که عامل نمی‌تواند به راحتی بین دستور «کدبیس را حذف نکن» و «این حافظه جلسه غیرمرتبط را حذف کن» تمایز قائل شود.

اعتبارسنجی انسان در حلقه (Human-in-the-Loop)

برای مبارزه با زوال حافظه خودکار، این تیم از بات‌های داخلی به نام nori استفاده می‌کند تا فعالیت‌های سراسری شرکت در Slack، Drive و PRها را هر هفته بررسی کنند. این بات‌ها به جای به‌روزرسانی خودکار، تغییراتی را برای مهارت‌های داخلی nori پیشنهاد داده و تیم را در Slack تگ می‌کنند. برای بهینه‌سازی این فرآیند، می‌توان ساختار حلقهٔ عامل را بازبینی کرد تا جایگزینی موثرتری برای روش‌های سنتی مهندسی پرامپت باشد.

تمام این پیشنهادات به‌طور پیش‌فرض رد می‌شوند. یک انسان باید تغییرات (Diff) را بررسی کند تا مطمئن شود با قصد واقعی پروژه سازگار است. نتیجه این فرآیند تکان‌دهنده است: کمتر از ۲۰٪ از این به‌روزرسانی‌های خودکار پذیرفته می‌شوند. این بدان معنای آن است که ۸۰٪ از به‌روزرسانی‌های «خودکار» در واقع باعث تخریب فعال عملکرد مدل می‌شدند. نویسنده خاطرنشان می‌کند که در یک سازمان با صدها نفر، ذخیره خودکار این به‌روزرسانی‌ها کاملاً ناپایدار و غیرممکن خواهد بود.

این تغییر دیدگاه نشان می‌دهد که متن جلسات برای نظارت انسانی (Observability) و حسابرسی (Auditing) مفید هستند، اما هنگامی که به عنوان یک لایه حافظه خودکار برای عامل‌های هوش مصنوعی استفاده شوند، تبدیل به یک liabilities یا نقطه ضعف تبدیل می‌شوند.

گام بعدی شما

• بازبینی استراتژی حافظه در عامل‌های خود و جایگزینی جست‌وجوی جلسات با تقویت بازیابی مستندات (RAG).
• پیاده‌سازی یک لایه تایید انسانی برای هرگونه به‌روزرسانی در پایگاه دانش عامل‌های کدنویس.
• کاهش تکیه بر تاریخچهٔ گفتگوها و تمرکز بر تولید متا‌دیتای دقیق برای PRها و کامیت‌ها.

اما تاثیر این انحراف حافظه بر مدل‌های استدلالی جدیدتر حتی پیچیده‌تر است — به تحلیل ما درباره‌ی مدل‌های Reasoning مراجعه کنید.