حافظه عامل هوش مصنوعی برای تسک؛ چه چیزی را نگه داریم و چه چیزی را نه؟

نویسنده: WKFGo Editorial · تاریخ انتشار · آخرین ویرایش

حافظه بیشتر الزاماً پاسخ بهتر نمی‌سازد

اگر هر نشست AI با توضیح معماری و تصمیم‌های قبلی شروع شود، زمان تلف می‌شود. اما ذخیرهٔ کل گفتگو نیز امن نیست: دادهٔ قدیمی، نظر تأییدنشده و اطلاعات حساس دوباره وارد پاسخ می‌شوند. حافظهٔ خوب کوتاه، دارای منبع، محدود به دامنه و قابل حذف است.

چرخهٔ طراحی حافظه

1. هدف: حافظه باید کدام سؤال تکراری را حذف کند؟
2. منبع: هر نکته به تسک، تصمیم یا صفحهٔ ویکی برگردد.
3. دامنه: حافظهٔ کاربر، پروژه و سازمان مخلوط نشوند.
4. اعتبار: محدودیت موقت تاریخ بازبینی یا انقضا داشته باشد.
5. کنترل: پیش از اقدام حساس، منبع اصلی دوباره بررسی شود.
6. اصلاح: مالک انسانی بتواند نکتهٔ غلط را پیدا، ویرایش یا حذف کند.

نمونهٔ عملی

عامل روی احراز هویت کار می‌کند. نکتهٔ مناسب این است: «تصمیم معماری: نشست‌ها سمت سرور می‌مانند؛ دلیل و تهدیدها در صفحهٔ X؛ بازبینی در نسخه بعد.» جملهٔ «کاربر گفت OAuth بد است» بدون تاریخ، گوینده و تصمیم نهایی حافظهٔ خطرناکی است.

در WKFGo ابزارهای save_memory و get_memory برای ثبت و بازیابی زمینه و get_context_pack برای گردآوری زمینهٔ مرتبط وجود دارند. وجود ابزار به معنی ذخیرهٔ خودکار همه‌چیز نیست؛ سیاست محتوا و دسترسی با تیم است.

پایلوت سنجش‌پذیر

روی یک پروژه ده سؤال پرتکرار را ثبت و فقط پاسخ‌های تأییدشده را وارد حافظه کنید. طی دو چرخه بسنجید:

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

اگر بازیابی اشتباه زیاد است، افزودن حافظه بیشتر وضعیت را بدتر می‌کند؛ دامنه، برچسب و منبع را اصلاح کنید.

محدودیت‌ها و خرید

پیش از استفاده سازمانی، حذف داده، جداسازی tenant، تاریخچه تغییر و رفتار هنگام لغو دسترسی را در دمو آزمایش کنید. حافظه جای ویکی را نمی‌گیرد: ویکی منبع دانش قابل نگهداری تیم است؛ حافظه سرنخی فشرده برای بازیابی زمینه است.

قدم بعدی

یک نوع حافظه با دامنه، مالک و تاریخ بازبینی تعریف کنید. راهنمای MCP و مرکز دانش پروژه مسیر پیاده‌سازی را تکمیل می‌کنند.