Hermes-Agent-Speichersystem

Die zentrale Differenzierungsfähigkeit von Hermes ist nicht das Aufrufen von Tools, sondern vielmehr, dass es sichwirklich an dich erinnert。

Die meisten KI-Tools beginnen jede Konversation bei null – du verbringst heute eine Stunde damit, ihm deine Projektstruktur, Namenskonventionen und deinen Deployment-Prozess beizubringen, und morgen, wenn du eine neue Sitzung startest, ist alles zurückgesetzt.

Dieses Kapitel analysiert eingehend, wie Hermes dieses Problem durch eine dreistufige Speicherstruktur löst und wie der Agent Speicher autonom verwaltet, wodurch sitzungsübergreifende Suche und Abruf ermöglicht werden.

Dreistufige Speicherarchitektur

Hermes verwendet eine dreischichtige Speicherarchitektur aus voneinander unabhängigen, funktional komplementären Schichten, um Informationen zu speichern und abzurufen.

Kern-Designphilosophie der dreistufigen Architektur:Häufig genutzte wichtige Informationen bleiben im Kontext, selten genutzte historische Informationen werden bei Bedarf abgerufen, und tiefe Muster werden automatisch von der KI abgeleitet.—wodurch ein Gleichgewicht zwischen Speicherfähigkeit und Token-Kosten entsteht.

┌─────────────────────────────────────────────────┐
│       第一层：持久记忆（Persistent Memory）        │
│  MEMORY.md（环境事实）+ USER.md（用户画像）          │
│  → 每次会话启动时自动注入系统提示词，始终可见          │
├─────────────────────────────────────────────────┤
│       第二层：情节日志（Session History）            │
│  SQLite + FTS5 全文检索，存储所有历史对话             │
│  → Agent 主动搜索时按需加载，不占用固定 Token         │
├─────────────────────────────────────────────────┤
│       第三层：用户建模（Honcho，可选）               │
│  辩证推理引擎，提取跨会话模式、偏好与目标              │
│  → 比你亲口说出来的更深层地理解你                     │
└─────────────────────────────────────────────────┘

Die drei Ebenen sind keine Ersatzlösungen, sondern Ergänzungen. Persistenter Speicher beantwortet "Ich muss diese immer wissen," der Sitzungsverlauf beantwortet "Haben wir das letzte Woche besprochen," und Honcho beantwortet "Was willst du wirklich."

Persistente Speicherdatei

Persistenter Speicher ist die erste und grundlegendste Ebene des Hermes-Speichersystems.

Er wird in zwei gespeichert~/.hermes/memories/Besteht aus Markdown-Dateien unter, die bei jedem Sitzungsstart automatisch in den System-Prompt eingefügt werden.

Zwei Kerndateien

Die beiden Dateien haben jeweils ihre eigene Rolle und überschneiden sich nicht.

Das Zeichenlimit ist beabsichtigt – es stellt sicher, dass der Speicherinhalt prägnant und fokussiert bleibt. Wenn ein neuer Eintrag das Limit überschreitet, gibt das Speicher-Tool einen Fehler zurück, der den Agenten dazu auffordert, vor dem Schreiben Speicherplatz freizugeben, anstatt alte Einträge stillschweigend zu verwerfen.

Wie der Speicher in den System-Prompt injiziert wird

Beim Start jeder Sitzung werden die Inhalte beider Dateien in einem festen Format in den System-Prompt injiziert, wie folgt:

══════════════════════════════════════════════
MEMORY（Agent 个人笔记）[67% — 1,474/2,200 字符]
══════════════════════════════════════════════
用户的项目是位于 ~/code/myapi 的 Rust Web 服务，使用 Axum + SQLx
§
本机运行 Ubuntu 22.04，已安装 Docker 和 Podman
§
用户偏好简洁回复，不喜欢冗长解释

Hier sind einige wichtige Design-Details:

Freeze Snapshot Mode: Der Speicherinhalt im System-Prompt wird einmal zu Beginn der Sitzung erfasst und während der Sitzung nicht aktualisiert.

Dies ist eine bewusste Design-Entscheidung – um den Prefix-Cache (Prompt-Cache) des LLM gültig zu halten und die Token-Kosten zu reduzieren.

Wenn der Agent den Speicher während einer Sitzung ändert, werden Änderungen sofort auf die Festplatte geschrieben, müssen aber aufStart in der nächsten Sitzungwarten. Erst dann erscheinen sie im Kontext.

Nutzungsprozentsatz sichtbar：[67% — 1,474/2,200]Hält den Agenten jederzeit über die verbleibende Kapazität informiert, sodass er proaktiv umorganisieren kann, wenn er sich dem Limit nähert.

§ als Elementtrenner: Jeder Speichereintrag wird durch § getrennt, und die Einträge selbst können mehrzeiliger Text sein.

Wie der Agent den Speicher verwaltet

Der Agent verwendet integriertememoryTools zur Speicherverwaltung, die drei Operationen unterstützen.

Hinweis:Kein Lesevorgang—der Speicherinhalt wird bereits beim Sitzungsstart in den System-Prompt injiziert, sodass der Agent ihn direkt im Kontext sieht, ohne zusätzliche Lesevorgänge zu benötigen.

replaceundremoveVerwendungTeilstring-AbgleichUm einen Eintrag zu finden, musst du nicht den vollständigen Eintragstext angeben:

Wenn der Teilstring auf mehrere Einträge passt, gibt das Tool einen Fehler zurück und verlangt eine genauere Übereinstimmungszeichenfolge.

Was man sich merken sollte, was nicht

Der Agent ermittelt und speichert wertvolle Informationen automatisch — normalerweise musst du nicht explizit danach fragen.

Aber das Verständnis der Kriterien hilft Ihnen, das Verhalten des Agenten zu verstehen und es bei Bedarf manuell zu steuern.

Sollte proaktiv im Speicher gespeichert werden (Umgebung & Arbeit)

Die folgenden Informationsarten veranlassen den Agenten, in MEMORY.md zu schreiben:

Sollte proaktiv beim Benutzer gespeichert werden (über dich)

Die folgenden Arten von Informationen veranlassen den Agenten, in USER.md zu schreiben:

Inhalte, die nicht gespeichert werden sollten

Der folgende Inhalt verdient keinen wertvollen Speicherplatz:

Gutes Gedächtnis vs. schlechtes Gedächtnis

Dieselbe Information, gut geschrieben, kann zehn Einträge wert sein; schlecht geschrieben ist sie wertlos.

Verwaltung der Speicherkapazität

Speicherdateien haben ein striktes Zeichenlimit; der Agent muss proaktiv organisieren, wenn er sich dem Limit nähert.

Was passiert, wenn man sich dem Limit nähert

Wenn ein neuer Eintrag dazu führen würde, dass das Zeichenlimit überschritten wird, gibt das Tool einen Fehler zurück, anstatt stillschweigend abzuschneiden:

{
  "success": false,
  "error": "Memory 已用 2,100/2,200 字符。新条目（250 字符）会超出上限。
            请先整理：用 replace 合并重叠条目，或 remove 过时条目，
            再重试——在同一轮对话中完成。",
  "current_entries": [
    "用户的 macOS 14 Sonoma，Homebrew，Docker Desktop",
    "项目 ~/code/api 使用 Go 1.22，sqlc 做 DB 查询"
  ],
  "usage": "2,100/2,200"
}

Beim Empfang dieses Fehlers ist das korrekte Vorgehen des Agenten:

1. Alle aktuellen Einträge lesen (bereits in der Fehlerantwort enthalten)
2. Einträge finden, die gelöscht oder zusammengeführt werden können
3. Verwenden SiereplaceMehrere zusammengehörige Einträge zu einer verfeinerten Version zusammenführen
4. Versuchen Sie dann erneut, den neuen Eintrag hinzuzufügen.

Best Practice: Wenn der System-Prompt eine Speichernutzung von über 80% anzeigt, organisieren Sie proaktiv – warten Sie nicht auf einen Fehler. Vorbeugung spart immer mehr Tokens als Behebung.

Kapazitätsreferenz

Schreibberechtigungen für den Speicher steuern

Standardmäßig kann der Agent frei in den Speicher schreiben – einschließlichIm Hintergrund automatisch ausgelöste Selbstverbesserungs-Überprüfung(Läuft im Hintergrund nach dem Ende einer Gesprächsrunde ab und destilliert Speicher und Fähigkeiten.)

Wenn Sie Inhalte überprüfen möchten, bevor etwas in den Speicher geschrieben wird, können Sie die Schreibgenehmigung aktivieren.

Schreibgenehmigung aktivieren

Legen Sie es einfach in der Konfigurationsdatei fest:

Verhaltensänderungen nach der Aktivierung:

Befehle zur Genehmigungsverwaltung

Verwenden Sie die folgenden Slash-Befehle, um ausstehende Speicherschreibvorgänge zu verwalten:

Anwendungsfälle: Wenn der Agent eine falsche Annahme über dich gespeichert hat oder du die volle Kontrolle über den Speicherinhalt möchtest, ist das Aktivieren von write_approval der direkteste Ansatz.

Über die Selbstverbesserungsprüfung im Hintergrund

Nach jeder Gesprächsrunde führt Hermes im Hintergrund eine Selbstverbesserungsprüfung (Hintergrundprüfung) durch, analysiert das Gespräch und destilliert Erinnerungen oder Fähigkeiten, die es wert sind, behalten zu werden.

Standardmäßig wird eine Benachrichtigungszeile im Chat angezeigtMemory updated。

Sie können den Detailgrad der Benachrichtigungen anpassen:

Wenn Ihr Hauptmodell teuer ist, können Sie Hintergrundüberprüfungen mit einem günstigeren Modell ausführen:

Episodenverzeichnis und sitzungsübergreifende Suche

Die zweite Speicherschicht – Sitzungsverlauf – speichert vollständige Aufzeichnungen aller historischen Konversationen und unterstützt Volltextsuche sowie Abruf auf Anfrage.

Alle Konversationen werden automatisch gespeichert

Jede Sitzung – ob von CLI, Telegram, Discord oder einer anderen Plattform – wird automatisch an zwei Orten gespeichert:

session_search-Tool

Integrierter Agentsession_searchEin Tool, das eine Volltextsuche über alle historischen Konversationen durchführen kann.

Der gesamte Prozess erfordert keine Beteiligung eines LLM in der Suchphase; sie wird direkt von der SQLite-FTS5-Engine durchgeführt:

Workflow:

1. FTS5 ruft übereinstimmende Nachrichten ab, sortiert nach Relevanz
2. Nach Sitzung gruppiert, wobei die relevantesten Sitzungen genommen werden (standardmäßig 3)
3. Lädt die Konversation jeder Sitzung und erfasst ungefähr 100.000 Zeichen rund um den Trefferpunkt
4. Ein leichtgewichtiges Zusammenfassungsmodell erzeugt fokussierte Zusammenfassungen
5. Gibt die Zusammenfassung und den Kontext jeder Sitzung an den Agenten zurück

Unterstützte Suchsyntax (FTS5-Standard):

Auslösezeitpunkt: Der Agent ruft session_search automatisch auf, wenn Sie "was wir letztes Mal besprochen haben ..." oder "der vorherige Vorschlag ..." erwähnen, statt dass Sie die Erklärung wiederholen müssen.

session_search vs. persistentes Gedächtnis

Die beiden ergänzen sich, sie stehen nicht in einem Ersatzverhältnis:

GedächtnisVerwendet für "Das muss ich immer wissen"—Umgebungsfakten, Benutzereinstellungen, Projektkonventionen.

Story-ProtokollVerwendet für "Haben wir letzte Woche darüber gesprochen?"—Finden bestimmter historischer Diskussionen.

Sitzungsverwaltung

Jede Sitzung im Sitzungsverlauf kann benannt, fortgesetzt, exportiert und bereinigt werden.

Benennung und Wiederherstellung

Hermes generiert automatisch einen kurzen Sitzungstitel (3–7 Wörter) nach der ersten Gesprächsrunde, der asynchron im Hintergrund läuft, ohne die Antwortgeschwindigkeit zu beeinträchtigen.

Sie können sie auch manuell benennen:

Nach der Benennung können Sitzungen direkt über den Titel fortgesetzt werden:

Auto-Lineage: Wenn eine Session eine Kontextkomprimierung durchläuft, erstellt und nummeriert Hermes automatisch Fortsetzungs-Sessions:

"我的项目" → "我的项目 #2" → "我的项目 #3"

Beim Fortsetzen anhand des Titels wird automatisch die neueste Fortsetzungs-Session ausgewählt.

Übliche Befehle zur Session-Verwaltung

hermes sessions listBeispielausgabe:

标题                 预览                               最近活跃    ID
────────────────────────────────────────────────────────────────────
重构认证模块          帮我重构认证模块的代码                2 小时前   20260305_09...
我的项目 #3          检查一下测试失败的原因                昨天        20260304_14...
—                   Python 装饰器怎么用                  3 天前      20260303_10...

Automatische Sitzungsbereinigung (optional)

Standardmäßig wird der Sitzungsverlauf dauerhaft aufbewahrt (da er Daten für session_search bereitstellt).

Wenn eine automatische Bereinigung erforderlich ist, aktivieren Sie sie in der Konfiguration:

Honcho-Benutzermodellierung

Honcho ist ein KI-natives Memory-Backend, entwickelt von Plastic Labs und als Plugin in Hermes integriert.

Es ersetzt MEMORY.md und USER.md nicht, sondern baut auf ihnen aufDialektische Argumentationsschicht hinzufügen—durch die Analyse Ihrer Gesprächsmuster leitet es automatisch Präferenzen, Ziele und Gewohnheiten ab, die Sie nicht explizit ausgedrückt haben.

Im Gegensatz zur manuellen Pflege von MEMORY.md ist Honcho vollautomatisch: Nach jeder Gesprächsrunde (Frequenz konfigurierbar) denkt es im Hintergrund nach und entwickelt dabei ein tieferes Verständnis von Ihnen.

Honcho vs. integriertes Gedächtnis

Zweischichtige Kontextinjektion

Bei jedem Konversationsschritt stellt Honcho zwei Ebenen von Kontext zusammen, die in den System-Prompt injiziert werden:

Basisschicht (Basiskontext): Sitzungszusammenfassung + Nutzercharakterisierung + Nutzer-Peer-Card + KI-Selbstcharakterisierung. Aktualisiert gemäß contextCadence (alle N Schritte). Dies ist die Schicht „Wer ist dieser Nutzer?“.

Dialektische Schicht (Dialektische Ergänzung): In Echtzeit von Honchos LLM-Engine generiert, mit Fokus darauf, „was gerade am relevantesten ist“. Aktualisiert gemäß dialecticCadence.

Zwei Startmodi für dialektisches Reasoning:

Drei unabhängige Einstellregler

Die drei Regler sind völlig unabhängig — du kannst die Basisschicht mit hoher Frequenz aktualisieren und die dialektische Schicht mit niedriger Frequenz laufen lassen, oder umgekehrt:

Die obige Konfiguration bedeutet: die Basisschicht jede Runde zu aktualisieren und alle 5 Runden ein tiefes dialektisches Reasoning mit 2 Durchgängen durchzuführen.

Dialektisches Reasoning mit mehreren Durchgängen

Wenn dialecticDepth auf größer als 1 gesetzt ist, führt jeder Durchlauf des dialektischen Reasonings mehrere Runden von LLM-Aufrufen aus:

Tiefe 3 bedeutet nicht unbedingt 3 LLM-Aufrufe – wenn der vorherige Durchgang bereits eine hochwertige Ausgabe erzeugt hat, wird der nächste Durchgang frühzeitig beendet, um Tokens zu sparen.

Schnellstart mit Honcho

Oder manuelle Konfiguration:

API-Schlüssel auf honcho.dev abrufen.

Von Honcho bereitgestellte Tools

Nach der Aktivierung von Honcho kann der Agent fünf exklusive Tools verwenden:

Honcho-CLI-Befehle

Referenz zur Konfiguration des Speichersystems

Das Folgende ist die vollständige Referenz für alle speicherbezogenen Konfigurationen, die direkt in Ihre Konfigurationsdatei kopiert werden kann.

Kurzreferenz für häufige Speicheroperationen

Speicher direkt in der Konversation bearbeiten

Sie können Hermes anweisen, den Speicher mit natürlicher Sprache zu bearbeiten, ohne sich Befehle merken zu müssen:

Slash-Befehle

Speicherdateien direkt bearbeiten

Speicherdateien sind reines Markdown und können direkt mit einem Editor geöffnet und bearbeitet werden:

Hinweis: Nach direkter Bearbeitung von Dateien werden Änderungen beim nächsten Sitzungsstart wirksam und erscheinen nicht sofort im Kontext der aktuellen Sitzung.

Speichersicherheit und Datenschutz

Sicherheitsscan

Speicherinhalte werden vor dem Schreiben einem Sicherheitsscan unterzogen, der Injection-Angriffe und Muster von Datendiebstahl erkennt.

Das System erkennt die folgenden Bedrohungsmuster:

Inhalte, die Bedrohungsmustern entsprechen, werdenSchreiben verweigern。

Sensible Informationen in Logs werden maskiert

Vertrauliche Informationen wie API-Schlüssel und Tokens werden in allen Protokolldateien automatisch geschwärzt—selbst wenn sie in Tool-Ausgaben erscheinen, werden sie niemals im Klartext aufgezeichnet:

Lokale Datenspeicherung

Alle Speicherdaten (MEMORY.md, USER.md, state.db) werden standardmäßig lokal gespeichert~/.hermes/Verzeichnis, wird nicht in die Cloud hochgeladen

Wenn Sie sich für die Nutzung von Honcho entscheiden, werden Gesprächsdaten zur Verarbeitung an Honchos Server gesendet—dies ist ein bewusster Kompromiss: Datenuploads gegen tiefergehende Reasoning-Fähigkeiten einzutauschen.