- ویژگیها
- هسته
- حافظه پایدار
حافظه پایدار
Hermes Agent دارای حافظه محدود و گزینش شدهای است که در جلسات پایدار میماند. این به آن اجازه میدهد ترجیحات، پروژهها، محیط و چیزهایی را که یاد گرفته به یاد بیاورد.
نحوه کار
دو فایل حافظه عامل را تشکیل میدهند:
| فایل | هدف | محدودیت کاراکتر |
|---|---|---|
| MEMORY.md | یادداشتهای شخصی عامل — واقعیات محیط، قراردادها، چیزهای آموخته شده | 2,200 کاراکتر (~800 توکن) |
| USER.md | پروفایل کاربر — ترجیحات، سبک ارتباطی، انتظارات | 1,375 کاراکتر (~500 توکن) |
هر دو در ~/.hermes/memories/ ذخیره میشوند و در ابتدای جلسه به عنوان یک اسنپشات یخ زده در پرامپت سیستم تزریق میشوند. عامل حافظه خود را از طریق ابزار memory مدیریت میکند — میتواند مدخلها را اضافه، جایگزین یا حذف کند.
~/.hermes/memories/
memory
محدودیتهای کاراکتر حافظه را متمرکز نگه میدهند. حافظه به طور خودکار فشرده نمیشود: وقتی یک نوشته از محدودیت فراتر رود، ابزار memory به جای حذف بیصدا مدخلها خطا برمیگرداند. سپس عامل خودش جا ایجاد میکند — مدخلها را در همان دور ادغام یا حذف میکند و دوباره تلاش میکند (به چه اتفاقی میافتد وقتی حافظه پر است مراجعه کنید). توجه کنید که replace نیز توسط محدودیت بسته شده است: تعویض یک مدخل با یکی طولانیتر همچنان میتواند سرریز کند، بنابراین محتوای جدید باید کوتاه شود (یا مدخل دیگری حذف شود) تا جا شود.
memory
replace
نحوه نمایش حافظه در پرامپت سیستم
در ابتدای هر جلسه، مدخلهای حافظه از دیسک بارگذاری شده و به عنوان یک بلوک یخ زده در پرامپت سیستم رندر میشوند:
══════════════════════════════════════════════MEMORY (your personal notes) [67% — 1,474/2,200 chars]══════════════════════════════════════════════User's project is a Rust web service at ~/code/myapi using Axum + SQLx§This machine runs Ubuntu 22.04, has Docker and Podman installed§User prefers concise responses, dislikes verbose explanations
قالب شامل موارد زیر است:
- یک سرصفحه که نشان میدهد کدام فروشگاه (MEMORY یا USER PROFILE)
- درصد استفاده و تعداد کاراکترها تا عامل از ظرفیت آگاه باشد
- مدخلهای جداگانه با جداکنندههای § (نشان بخش)
- مدخلها میتوانند چند خطی باشند
§
الگوی اسنپشات یخ زده: تزریق پرامپت سیستم یک بار در ابتدای جلسه ضبط میشود و هرگز در اواسط جلسه تغییر نمیکند. این عمدی است — کش پیشوند LLM را برای عملکرد حفظ میکند. وقتی عامل در طول جلسه مدخلهای حافظه اضافه/حذف میکند، تغییرات بلافاصله در دیسک پایدار میشوند اما تا شروع جلسه بعدی در پرامپت سیستم ظاهر نمیشوند. پاسخهای ابزار همیشه وضعیت زنده را نشان میدهند.
اعمال ابزار حافظه
عامل از ابزار memory با این اعمال استفاده میکند:
memory
- add — اضافه کردن یک مدخل حافظه جدید
- replace — جایگزینی یک مدخل موجود با محتوای بهروز شده (از تطابق زیررشتهای از طریق old_text استفاده میکند)
- remove — حذف یک مدخل که دیگر مرتبط نیست (از تطابق زیررشتهای از طریق old_text استفاده میکند)
old_text
old_text
هیچ عمل read وجود ندارد — محتوای حافظه به طور خودکار در ابتدای جلسه در پرامپت سیستم تزریق میشود. عامل حافظههای خود را به عنوان بخشی از زمینه مکالمه خود میبیند.
read
تطابق زیررشتهای
عملیات replace و remove از تطابق زیررشتهای کوتاه و یکتا استفاده میکنند — نیازی به متن کامل مدخل نیست. پارامتر old_text فقط باید یک زیررشته یکتا باشد که دقیقاً یک مدخل را شناسایی کند:
replace
remove
old_text
# اگر حافظه حاوی "User prefers dark mode in all editors" باشدmemory(action="replace", target="memory", old_text="dark mode", content="User prefers light mode in VS Code, dark mode in terminal")
اگر زیررشته با چندین مدخل مطابقت داشته باشد، خطایی برگردانده میشود که درخواست تطابق دقیقتر میکند.
توضیح دو هدف
memory — یادداشتهای شخصی عامل
memory
برای اطلاعاتی که عامل باید درباره محیط، جریانهای کاری و درسهای آموخته شده به یاد بیاورد:
- واقعیات محیط (سیستم عامل، ابزارها، ساختار پروژه)
- قراردادها و پیکربندی پروژه
- مشکلات و راهحلهای کشف شده ابزار
- مدخلهای روزانه کارهای تکمیل شده
- مهارتها و تکنیکهایی که کار کردهاند
user — پروفایل کاربر
user
برای اطلاعات درباره هویت، ترجیحات و سبک ارتباطی کاربر:
- نام، نقش، منطقه زمانی
- ترجیحات ارتباطی (مختصر در مقابل مفصل، ترجیحات قالب)
- مسائل آزاردهنده و چیزهایی که باید از آنها اجتناب کرد
- عادات جریان کاری
- سطح مهارت فنی
چه چیزی ذخیره کنیم در مقابل رد کردن
اینها را ذخیره کنید (به صورت پیشگیرانه)
عامل به طور خودکار ذخیره میکند — نیازی نیست بخواهید. وقتی یاد میگیرد ذخیره میکند:
- ترجیحات کاربر: «I prefer TypeScript over JavaScript» → ذخیره در user
- واقعیات محیط: «This server runs Debian 12 with PostgreSQL 16» → ذخیره در memory
- اصلاحیهها: «Don’t use sudo for Docker commands, user is in docker group» → ذخیره در memory
- قراردادها: «Project uses tabs, 120-char line width, Google-style docstrings» → ذخیره در memory
- کارهای تکمیل شده: «Migrated database from MySQL to PostgreSQL on 2026-01-15» → ذخیره در memory
- درخواستهای صریح: «Remember that my API key rotation happens monthly» → ذخیره در memory
user
memory
sudo
memory
memory
memory
memory
اینها را رد کنید
- اطلاعات پیشپاافتاده/بدیهی: «User asked about Python» — بیش از حد مبهم برای مفید بودن
- واقعیاتی که به راحتی دوباره کشف میشوند: «Python 3.12 supports f-string nesting» — میتوان این را در وب جستجو کرد
- ارسالهای داده خام: بلوکهای کد بزرگ، فایلهای گزارش، جداول داده — بزرگ برای حافظه
- موارد موقت مختص جلسه: مسیرهای فایل موقت، زمینه اشکالزدایی یکبار مصرف
- اطلاعاتی که از قبل در فایلهای زمینه وجود دارد: محتوای SOUL.md و AGENTS.md
مدیریت ظرفیت
حافظه محدودیتهای سخت کاراکتری برای نگه داشتن پرامپتهای سیستم در محدوده دارد:
| فروشگاه | محدودیت | مدخلهای معمول |
|---|---|---|
| memory | 2,200 کاراکتر | 8-15 مدخل |
| user | 1,375 کاراکتر | 5-10 مدخل |
چه اتفاقی میافتد وقتی حافظه پر است
وقتی سعی میکنید مدخلی اضافه کنید که از محدودیت فراتر رود، ابزار خطا برمیگرداند:
{ "success": false, "error": "Memory at 2,100/2,200 chars. Adding this entry (250 chars) would exceed the limit. Consolidate now: use 'replace' to merge overlapping entries into shorter ones or 'remove' stale or less important entries (see current_entries below), then retry this add — all in this turn.", "current_entries": ["..."], "usage": "2,100/2,200"}
عامل باید:
- مدخلهای فعلی را بخواند (در پاسخ خطا نشان داده شده)
- مدخلهایی را که میتوان حذف یا ادغام کرد شناسایی کند
- از replace برای ادغام مدخلهای مرتبط به نسخههای کوتاهتر استفاده کند
- سپس مدخل جدید را اضافه کند
replace
add
بهترین شیوه: وقتی حافظه بالای 80٪ ظرفیت است (در سرصفحه پرامپت سیستم قابل مشاهده)، مدخلها را قبل از اضافه کردن جدید ادغام کنید.
مثالهای عملی مدخلهای خوب حافظه
مدخلهای فشرده و متراکم از اطلاعات بهترین عملکرد را دارند:
# خوب: چندین واقعیت مرتبط را بستهبندی میکندUser runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop and Podman. Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.# خوب: قرارداد مشخص و عملیProject ~/code/api uses Go 1.22, sqlc for DB queries, chi router. Run tests with 'make test'. CI via GitHub Actions.# خوب: درس آموخته شده با زمینهThe staging server (10.0.1.50) needs SSH port 2222, not 22. Key is at ~/.ssh/staging_ed25519.# بد: بیش از حد مبهمUser has a project.# بد: بیش از حد طولانیOn January 5th, 2026, the user asked me to look at their project which islocated at ~/code/api. I discovered it uses Go version 1.22 and...
جلوگیری از تکرار
سیستم حافظه به طور خودکار مدخلهای دقیقاً تکراری را رد میکند. اگر سعی کنید محتوایی اضافه کنید که از قبل وجود دارد، موفقیت با پیام «no duplicate added» برمیگرداند.
اسکن امنیتی
مدخلهای حافظه قبل از پذیرش برای الگوهای تزریق و نشت اسکن میشوند، زیرا در پرامپت سیستم تزریق میشوند. محتوایی که با الگوهای تهدید مطابقت دارد (تزریق پرامپت، نشت اعتبارنامه، درهای پشتی SSH) یا حاوی کاراکترهای Unicode نامرئی است مسدود میشود.
جستجوی جلسه
علاوه بر MEMORY.md و USER.md، عامل میتواند مکالمات گذشته خود را با ابزار session_search جستجو کند:
session_search
- همه جلسات CLI و پیامرسانی در SQLite (~/.hermes/state.db) با جستجوی تمام متن FTS5 ذخیره میشوند
- پرسوجوهای جستجو پیامهای واقعی از پایگاه داده برمیگردانند — بدون خلاصهسازی LLM، بدون کوتاهسازی
- عامل میتواند چیزهایی را که هفتهها پیش بحث کرده پیدا کند، حتی اگر در حافظه فعالش نباشند
- عامل همچنین میتواند در داخل هر جلسهای که پیدا میکند به جلو/عقب اسکرول کند
~/.hermes/state.db
hermes sessions list # مرور جلسات گذشته
Session Search Tool را برای سه شکل فراخوان (کشف / اسکرول / مرور) و قالب پاسخ مشاهده کنید.
session_search در مقابل memory
| ویژگی | حافظه پایدار | جستجوی جلسه |
|---|---|---|
| ظرفیت | ~1,300 توکن در مجموع | نامحدود (همه جلسات) |
| سرعت | فوری (در پرامپت سیستم) | ~20ms پرسوجوی FTS5، ~1ms اسکرول |
| هزینه | هزینه توکن در هر پرامپت | رایگان — بدون فراخوان LLM |
| مورد استفاده | واقعیات کلیدی همیشه در دسترس | پیدا کردن مکالمات خاص گذشته |
| مدیریت | توسط عامل به صورت دستی گزینش شده | خودکار — همه جلسات ذخیره شده |
| هزینه توکن | ثابت در هر جلسه (~1,300 توکن) | درخواستی (وقتی نیاز باشد جستجو میشود) |
حافظه برای واقعیات حیاتی است که باید همیشه در زمینه باشند. جستجوی جلسه برای پرسوجوهایی مانند «آیا هفته گذشته درباره X بحث کردیم؟» است که عامل به یادآوری جزئیات از مکالمات گذشته نیاز دارد.
پیکربندی
# در ~/.hermes/config.yamlmemory: memory_enabled: true user_profile_enabled: true memory_char_limit: 2200 # ~800 توکن user_char_limit: 1375 # ~500 توکن write_approval: false # false = آزادانه بنویس (پیشفرض) | true = نیاز به تأیید
کنترل نوشتههای حافظه (write_approval)
write_approval
به طور پیشفرض عامل حافظه را آزادانه ذخیره میکند — از جمله از مرور بهبود خود پسزمینهای که پس از یک دور اجرا میشود. اگر ترجیح میدهید ابتدا ذخیرهها را تأیید کنید، memory.write_approval: true را تنظیم کنید. این یک دروازه ساده روشن/خاموش است که هم برای دورهای پیشزمینه و هم برای مرور پسزمینه اعمال میشود:
memory.write_approval: true
| write_approval | رفتار |
|---|---|
| false (پیشفرض) | آزادانه بنویس — دروازه خاموش است (رفتار قبل از دروازه). |
| true | قبل از ذخیره هر چیزی تأیید لازم است. در CLI تعاملی، نوشتههای پیشزمینه به صورت درونخطی از شما پرامپت میکنند. هر جای دیگر — پلتفرمهای پیامرسانی، اسکریپتها و مرور بهبود پسزمینهای — نوشتهها برای بررسی با /memory pending مرحلهبندی میشوند. |
write_approval
false
true
/memory pending
برای غیرفعال کردن کامل حافظه (نه فقط دروازه کردن)، memory_enabled: false را تنظیم کنید.
برای غیرفعال کردن کامل حافظه (نه فقط دروازه کردن)، memory_enabled: false را تنظیم کنید.
memory_enabled: false
بررسی نوشتههای مرحلهبندی شده از CLI یا هر پلتفرم پیامرسانی:
/memory pending # لیست نوشتههای حافظه مرحلهبندی شده/memory approve <id> # اعمال یکی (یا 'all')/memory reject <id> # رد یکی (یا 'all')/memory approval on # دروازه را روشن (یا 'off') کنید و ذخیره کنید
این پاسخ به «عامل یک فرض اشتباه درباره من ذخیره کرد» است: write_approval: true را تنظیم کنید.
write_approval: true
اعلانهای مرور پسزمینه (display.memory_notifications)
display.memory_notifications
پس از یک دور، مرور بهبود خود پسزمینهای ممکن است بیصدا حافظهای ذخیره کند یا مهارتی را بهروز کند. این حلقه یادگیری آگاه از رضایت Hermes است. به طور پیشفرض یک خط 💾 Memory updated کوتاه در چت نشان میدهد:
write_approval
💾 Memory updated
display: memory_notifications: on # off | on (پیشفرض) | verbose
| مقدار | رفتار |
|---|---|
| off | بدون اعلان چت. مرور همچنان اجرا میشود. |
| on (پیشفرض) | خط عمومی، مثلاً 💾 Memory updated. |
| verbose | شامل پیشنمایش فشردهای از تغییرات. |
اجرای مرور روی یک مدل ارزانتر (auxiliary.background_review)
auxiliary.background_review
مرور به طور پیشفرض روی مدل اصلی چت شما اجرا میشود. روی یک مدل اصلی گرانقیمت میتوانید مرور را روی یک مدل ارزانتر اجرا کنید:
auxiliary: background_review: provider: openrouter model: google/gemini-3-flash-preview # auto (پیشفرض) = مدل اصلی چت
کنترل نوشتههای مهارت (skills.write_approval)
skills.write_approval
skills: write_approval: false # false = آزادانه بنویس (پیشفرض) | true = نیاز به تأیید
وقتی write_approval: true باشد، هر نوشته skill_manage مرحلهبندی میشود:
write_approval: true
skill_manage
~/.hermes/pending/skills/
/skills pending # لیست نوشتههای مهارت مرحلهبندی شده/skills diff <id> # diff کامل unified/skills approve <id> # اعمال آن (یا 'all')/skills reject <id> # رد آن (یا 'all')/skills approval on # دروازه را روشن کنید
ارائهدهندگان حافظه خارجی
برای حافظه عمیقتر و پایدارتر که فراتر از MEMORY.md و USER.md است، Hermes با 8 پلاگین ارائهدهنده حافظه خارجی ارائه میشود — از جمله Honcho، OpenViking، Mem0، Hindsight، Holographic، RetainDB، ByteRover، و Supermemory.
ارائهدهندگان خارجی در کنار حافظه داخلی اجرا میشوند (هرگز جایگزین نمیکنند) و قابلیتهایی مانند نمودارهای دانش، جستجوی معنایی، استخراج خودکار واقعیات و مدلسازی کاربر بین جلسهای اضافه میکنند.
hermes memory setup # یک ارائهدهنده انتخاب و پیکربندی کنیدhermes memory status # بررسی کنید چه چیزی فعال است
Memory Providers را برای جزئیات کامل درباره هر ارائهدهنده، دستورالعملهای راهاندازی و مقایسه ببینید.