---
# System prepended metadata
title: '[AI] Agents / Hermes Agent - 簡介'
tags: [OpenClaw, AI / Tools / Agents / Hermes Agent /, tools, AI, Hermes Agent, Hermes, agents, 愛馬仕, Honcho]
---
[AI] Agents / Hermes Agent - 簡介
===
###### tags: `AI / Tools / Agents / Hermes Agent /`
###### tags: `AI`, `tools`, `agents`, `Hermes Agent`, `Hermes`, `愛馬仕`, `OpenClaw`, `Honcho`
**目錄**
- [\[AI\] Agent / Hermes Agent](#AI-Agent--Hermes-Agent)
- [GitHub](#GitHub)
- [News](#News)
- [2026/04/13 - 讓你產能百倍的 Hermes Agent 工具，把龍蝦 OpenClaw 打回寒武紀](#20260413---讓你產能百倍的-Hermes-Agent-工具，把龍蝦-OpenClaw-打回寒武紀)
- [討論](#討論)
- [Hermes 是如何把用戶體驗變成可以持續迭代改善的技巧](#Hermes-是如何把用戶體驗變成可以持續迭代改善的技巧)
- [Honcho 和 Hermes 的關係為何?](#Honcho-和-Hermes-的關係為何)
- [Honcho 的 prompt 和固化記憶的流程為何？](#Honcho-的-prompt-和固化記憶的流程為何？)
- [畫成一張「Honcho 記憶流 / prompt 流」的文字架構圖](#畫成一張「Honcho-記憶流--prompt-流」的文字架構圖)
- [用小學五年級程度描述 Honcho 的做法](#用小學五年級程度描述-Honcho-的做法)
- [如果只是將紀錄，整理出重點，進一步擷取出關鍵/精華。也就是，可以遞迴找出當前重點，再遞迴找出當前重點（=關鍵/精華）。這樣的簡單做法，為何 Honcho 作法會如此複雜？有什麼不一樣？](#如果只是將紀錄，整理出重點，進一步擷取出關鍵精華。也就是，可以遞迴找出當前重點，再遞迴找出當前重點（關鍵精華）。這樣的簡單做法，為何-Honcho-作法會如此複雜？有什麼不一樣？)
- [都還沒聊天，Honcho 怎麼知道當前有那些記憶是重要的？怎麼知道用戶要做什麼事？](#都還沒聊天，Honcho-怎麼知道當前有那些記憶是重要的？怎麼知道用戶要做什麼事？)
- [peer card 是什麼？](#peer-card-是什麼？)
- [`summary / representation / peer card / conclusion` 四者超簡單對照表](#summary--representation--peer-card--conclusion-四者超簡單對照表)
> Date: 2026-04-27 15:29:56 GMT+8
## GitHub
https://github.com/nousresearch/hermes-agent
## 安裝方式
```
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
```
- 支援 Linux、macOS 和 WSL2，Hermes Agent 會自動完成全部配置，無需手動操作。
### 執行過程
```
...
How would you like to set up Hermes?
↑↓ navigate ENTER/SPACE select ESC cancel
→ (●) Quick setup — provider, model & messaging (recommended)
(○) Full setup — configure everything
Select provider:
↑↓ navigate ENTER/SPACE select ESC cancel
→ (●) Nous Portal (Nous Research subscription)
(○) OpenRouter (100+ models, pay-per-use)
(○) LM Studio (local desktop app with built-in model server)
(○) Vercel AI Gateway (200+ models, $5 free credit, no markup)
(○) Anthropic (Claude models — API key or Claude Code)
(○) OpenAI Codex
(○) Xiaomi MiMo (MiMo-V2.5 and V2 models — pro, omni, flash)
(○) Tencent TokenHub (Hy3 Preview — direct API via tokenhub.tencentmaas.com)
(○) NVIDIA NIM (Nemotron models — build.nvidia.com or local NIM)
(○) Qwen OAuth (reuses local Qwen CLI login)
(○) GitHub Copilot (uses GITHUB_TOKEN or gh auth token)
(○) GitHub Copilot ACP (spawns `copilot --acp --stdio`)
(○) Hugging Face Inference Providers (20+ open models)
(○) Google AI Studio (Gemini models — native Gemini API)
(○) Google Gemini via OAuth + Code Assist (free tier supported; no API key needed)
(○) DeepSeek (DeepSeek-V3, R1, coder — direct API)
(○) xAI (Grok models — direct API)
(○) Z.AI / GLM (Zhipu AI direct API)
(○) Kimi Coding Plan (api.kimi.com) & Moonshot API
(○) Kimi / Moonshot China (Moonshot CN direct API)
(○) StepFun Step Plan (agent/coding models via Step Plan API)
(○) MiniMax (global direct API)
(○) MiniMax China (domestic direct API)
(○) Alibaba Cloud / DashScope Coding (Qwen + multi-provider)
(○) Ollama Cloud (cloud-hosted open models — ollama.com)
(○) Arcee AI (Trinity models — direct API)
(○) GMI Cloud (multi-model direct API)
(○) Kilo Code (Kilo Gateway API)
(○) OpenCode Zen (35+ curated models, pay-as-you-go)
(○) OpenCode Go (open models, $10/month subscription)
(○) AWS Bedrock (Claude, Nova, Llama, DeepSeek — IAM or API key)
(○) Azure Foundry (OpenAI-style or Anthropic-style endpoint — your Azure AI deployment)
(○) Custom endpoint (enter URL manually)
(○) Configure auxiliary models...
(○) Leave unchanged
...
→ Starting setup wizard...
┌─────────────────────────────────────────────────────────┐
│ ⚕ Hermes Agent Setup Wizard │
├─────────────────────────────────────────────────────────┤
│ Let's configure your Hermes Agent installation. │
│ Press Ctrl+C at any time to exit. │
└─────────────────────────────────────────────────────────┘
Skipped (keeping current)
◆ Inference Provider
Choose how to connect to your main chat model.
Guide: https://hermes-agent.nousresearch.com/docs/integrations/providers
Warning: No inference provider configured. Run 'hermes model' to choose a provider and model, or set an API key (OPENROUTER_API_KEY, OPENAI_API_KEY, etc.) in ~/.hermes/.env. Falling back to auto provider detection.
Current model: anthropic/claude-opus-4.6
Active provider: none
Not logged into Nous Portal. Starting login...
Starting Hermes login via Nous Portal...
Portal: https://portal.nousresearch.com
To continue:
1. Open: https://portal.nousresearch.com/manage-subscription?user_code=BTJ9-ABCD
2. If prompted, enter code: BTJ9-ABCD
(Opened browser for verification)
Waiting for approval (polling every 1s)...
gio: https://portal.nousresearch.com/manage-subscription?user_code=BTJ9-ABCD: Operation not supported
```
- https://portal.nousresearch.com/manage-subscription?user_code=BTJ9-ABCD
```
Connect a messaging platform? (Telegram, Discord, etc.)
↑↓ navigate ENTER/SPACE select ESC cancel
→ (●) Set up messaging now (recommended)
(○) Skip — set up later with 'hermes setup gateway
...
┌─────────────────────────────────────────────────────────┐
│ ✓ Setup Complete! │
└─────────────────────────────────────────────────────────┘
📁 All your files are in ~/.hermes/:
Settings: /home/tj_tsai/.hermes/config.yaml
API Keys: /home/tj_tsai/.hermes/.env
Data: /home/tj_tsai/.hermes/cron/, sessions/, logs/
────────────────────────────────────────────────────────────
📝 To edit your configuration:
hermes setup Re-run the full wizard
hermes setup model Change model/provider
hermes setup terminal Change terminal backend
hermes setup gateway Configure messaging
hermes setup tools Configure tool providers
hermes config View current settings
hermes config edit Open config in your editor
hermes config set
Set a specific value
Or edit the files directly:
nano /home/tj_tsai/.hermes/config.yaml
nano /home/tj_tsai/.hermes/.env
────────────────────────────────────────────────────────────
🚀 Ready to go!
hermes Start chatting
hermes gateway Start messaging gateway
hermes doctor Check for issues
Launch hermes chat now? [Y/n]:
```
## News
### 2026/04/13 - [讓你產能百倍的 Hermes Agent 工具，把龍蝦 OpenClaw 打回寒武紀](https://www.blocktempo.com/hermes-agent-nous-research-openclaw-migration-self-evolution-tools/)
- ### 安裝方式
上手極其簡單。一行命令「curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash」即可完成安裝，支援 Linux、macOS 和 WSL2，Hermes Agent 會自動完成全部配置，無需手動操作。
- ### 核心觀點：
1. **Hermes Agent 的核心賣點不是「會用工具」，而是「會越用越強」**：它主打記憶系統 + 技能系統，能把過往經驗、使用者偏好、操作流程累積成可重用資產，形成自我改進閉環。
2. **作者在對比中明顯偏向 Hermes、弱化 OpenClaw**：文中把 OpenClaw 放在安全漏洞與架構侷限的背景下，並強調 Hermes 提供一鍵遷移、自主生成技能、不同的架構哲學，因此更適合長期與實務使用。
3. **作者想傳達 Hermes 不只是玩具，而是可部署的開源生產力平台**：它支援多種工具、排程、自動化、多平台接入與低成本部署，定位成可長時間運作、可自主管理的開源 Agent。
- #### 一句話總結
作者的重點是：**Hermes Agent 之所以值得關注，不只是因為它能取代 OpenClaw，而是因為它試圖把 Agent 做成一個會記憶、會學習、能長期進化的開源自主助手。**
## 討論
### Hermes 是如何把用戶體驗變成可以持續迭代改善的技巧
- ### Question
https://github.com/nousresearch/hermes-agent
拉下來看一下， Hermes 是如何將用戶體驗變成可以持續迭代改善的技巧？
- ### gpt-5.4 (2026/04/18)
我看完 repo、文件和部分原始碼後，覺得 Hermes 最核心的招，不是「把用戶體驗直接拿去線上微調模型權重」，而是先把互動過程沉澱成幾種**可重用資產**：`session`、`memory`、`skill`、`user model`、`insights`。也就是說，它把「一次性的使用經驗」轉成「下次可直接派上用場的結構化知識」。([GitHub][20260418-A-1])
我會把 Hermes 的做法濃縮成 5 個技巧：
1. **先把所有互動完整留痕，不讓 UX 消失**
Hermes 會把每次對話存成 session，放進 SQLite 與 JSONL transcript；SQLite 還有 FTS5 全文檢索，所以不是只有「存檔」，而是之後真的找得回來。它甚至有 `session_search`，會先搜相關 session，再做聚焦摘要。這代表一次成功或失敗的互動，不會只是當下體驗，而會成為後續可回收的知識來源。([GitHub][20260418-A-2])
2. **把穩定偏好與環境事實，提煉成小而精的記憶**
Hermes 不走「無限長記憶」路線，而是把可長期影響體驗的內容，整理到 `MEMORY.md` 與 `USER.md`，而且有嚴格字數上限。文件裡明講：該存的是偏好、慣例、修正、環境事實；不該存的是雜訊、暫時性資訊、可輕易再查到的東西。這其實是一種很重要的 UX 技巧：**不要把所有歷史都丟進 prompt，而是只保留最影響未來互動品質的東西**。([GitHub][20260418-A-3])
3. **把重複成功流程升格成 skill，而不是每次重新 prompt**
Hermes 的 `skill_manage` 讓 agent 可以自己建立、更新、刪除 skill。文件寫得很直接：當它完成複雜任務、踩過錯路找到正解、被使用者糾正、或發現非 trivial workflow 時，就應該把這些經驗保存成 skill；而 skill 更新時又偏好用 `patch` 做局部修補。這就是把 UX 轉成持續改善的關鍵：**不是只記「你喜歡什麼」，還記「這件事怎麼做才會成功」**。([GitHub][20260418-A-4])
4. **把更深層的使用者模式，從明示偏好提升到推論層**
如果有開 Honcho，Hermes 不只記你說過什麼，還會在每回合後用 dialectic reasoning 去推導使用者的習慣、目標、溝通風格，並且分成兩層注入：一層是「這個人是誰」，一層是「現在這個 session 什麼最重要」。這比單純 key-value 記憶更接近真正的個人化。也就是說，Hermes 把 UX 不是只當成 feedback，而是當成**可持續更新的使用者模型**。([GitHub][20260418-A-5])
5. **把使用行為量測化，讓人能看到 agent 到底怎麼被使用**
我也看了 `agent/insights.py`。它會從 SQLite 狀態庫分析 token 消耗、成本估算、工具使用模式、活動趨勢、模型與平台分布、session 指標。這很重要，因為很多 agent 系統只有「會學」，卻沒有「讓你看它學得值不值得」。Hermes 這裡多做了一步：**把 UX 改善變成可觀測、可分析、可調整的營運資料**。([GitHub][20260418-A-6])
再往前看一步，Hermes 還做了兩個很實用的設計。第一，它在 context 壓縮前會先 flush persistent memory，避免上下文快被截掉時學到的東西遺失；第二，session auto-reset 前也會先給 agent 一回合去保存重要 memories 或 skills。這代表它有明確在處理「**知識在邊界點遺失**」這個 agent UX 常見問題。([GitHub][20260418-A-7])
所以你問「Hermes 是如何把用戶體驗變成可以持續迭代改善的技巧」，我會直接回答：
**它的做法是把 UX 分層資產化。**
當次互動先變成 session；高頻穩定事實變成 memory；成功流程變成 skill；長期人格與偏好變成 user model；整體使用型態再變成 insights。下次互動時，Hermes 不是從零開始，而是帶著這些層次化資產回來。([GitHub][20260418-A-1])
這也代表一個很重要的判斷：
**Hermes 的「持續改善」主要是 runtime / prompt / memory / skill 層，不是預設就做線上模型訓練。**
Repo 雖然有 research-ready、trajectory generation、可拿去訓練下一代 tool-calling model 的方向，但產品層面真正落地的改善循環，核心還是在記憶、技能、檢索、使用者建模與觀測分析。([GitHub][20260418-A-1])
如果你要把這套觀念用在你自己的系統，我最推薦直接抄的不是「Honcho」本身，而是這 4 個原則：
**分層記憶、程序升格、邊界保存、使用分析。**
這四個比「讓模型更聰明」更容易做，也更容易真的讓 UX 越用越順。
你要的話，我可以下一步直接幫你把 Hermes 這套方法整理成一份「可套用到你自己 agent / 語言學習系統 / 產品設計」的實作框架。
[20260418-A-1]: https://github.com/nousresearch/hermes-agent?utm_source=chatgpt.com "GitHub - NousResearch/hermes-agent: The agent that grows with you · GitHub"
[20260418-A-2]: https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/sessions.md "hermes-agent/website/docs/user-guide/sessions.md at main · NousResearch/hermes-agent · GitHub"
[20260418-A-3]: https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/memory.md "hermes-agent/website/docs/user-guide/features/memory.md at main · NousResearch/hermes-agent · GitHub"
[20260418-A-4]: https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/skills.md "hermes-agent/website/docs/user-guide/features/skills.md at main · NousResearch/hermes-agent · GitHub"
[20260418-A-5]: https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/honcho.md "hermes-agent/website/docs/user-guide/features/honcho.md at main · NousResearch/hermes-agent · GitHub"
[20260418-A-6]: https://github.com/NousResearch/hermes-agent/blob/main/agent/insights.py "hermes-agent/agent/insights.py at main · NousResearch/hermes-agent · GitHub"
[20260418-A-7]: https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/agent-loop.md "hermes-agent/website/docs/developer-guide/agent-loop.md at main · NousResearch/hermes-agent · GitHub"
---
### Honcho 和 Hermes 的關係為何?
- ### gpt-5.4 (2026/04/18)
Honcho 和 Hermes 的關係，可以直接理解成：
**Hermes = Agent 本體**
**Honcho = Hermes 可接上的長期記憶／使用者建模層**。 ([Hermes Agent][20260418-B-1])
更精準一點說：
* **Hermes Agent** 是 Nous Research 的 agent，負責對話、工具呼叫、skills、session、內建記憶等整體行為。官方把 Honcho 列為 Hermes 的閉環學習能力之一部分，但不是 Hermes 本體的全部。([Hermes Agent][20260418-B-1])
* **Honcho** 是一個獨立的 AI-native memory / user modeling 系統，提供長期記憶、跨 session 延續、以及比一般 RAG 更深的使用者理解。它本身不是 Hermes，而是可被 Hermes 整合使用的記憶基礎設施。([docs.honcho.dev][20260418-B-2])
Hermes 文件寫得很明白：
它有 **兩套記憶系統** 可以一起用或分開用：
1. **Hermes 內建記憶**：`MEMORY.md`、`USER.md`
2. **Honcho Memory**：較深層的 cross-session user modeling
預設的 `hybrid` 模式下，兩者會一起運作；若設成 `honcho`，則可只用 Honcho。([Hermes Agent][20260418-B-3])
所以它們不是「同一個東西」，而是：
* **Hermes 需要記憶能力**
* **Honcho 提供更進階、更持久的記憶與使用者模型**
* **Hermes 透過整合 Honcho，把個人化與跨平台／跨 session 延續做得更強**。([docs.honcho.dev][20260418-B-4])
你也可以把兩者想成這樣：
* **沒有 Honcho 的 Hermes**：有 session、skills、內建記憶，已經能學一些東西。([Hermes Agent][20260418-B-1])
* **接上 Honcho 的 Hermes**：多了使用者偏好、目標、溝通風格、歷史脈絡的持久建模，並能透過 `honcho_profile`、`honcho_search`、`honcho_context`、`honcho_conclude` 這些工具去查與寫。([Hermes Agent][20260418-B-3])
一句話總結：
**Hermes 是會工作的 agent；Honcho 是讓 Hermes 更記得你、理解你、延續你脈絡的記憶與社會認知後端。** ([Hermes Agent][20260418-B-3])
你要的話，我下一則可以再幫你整理成一張表：
**Hermes 內建 memory vs Honcho memory 差異表**。
[20260418-B-1]: https://hermes-agent.nousresearch.com/docs/?utm_source=chatgpt.com "Hermes Agent Documentation | Hermes Agent"
[20260418-B-2]: https://docs.honcho.dev/v2/documentation/introduction/overview?utm_source=chatgpt.com "Honcho - Honcho"
[20260418-B-3]: https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho/?utm_source=chatgpt.com "Honcho Memory | Hermes Agent"
[20260418-B-4]: https://docs.honcho.dev/v3/guides/integrations/hermes?utm_source=chatgpt.com "Hermes Agent + Honcho - Honcho"
---
### Honcho 的 prompt 和固化記憶的流程為何？
- ### gpt-5.4 (2026/04/18)
有，這部分我看了 Hermes 的 Honcho 文件與實作，結論是：
**Honcho 在 Hermes 裡，其實有兩條線同時運作：**
1. **給模型看的 prompt / context 注入線**
2. **把互動固化成長期記憶的寫入線** ([hermes-agent.nousresearch.com][20260418-C-1])
---
### 1) Honcho 的 prompt 大致長什麼樣？
#### A. 先有一個「靜態模式提示」
Hermes 不會把整包 Honcho 記憶都硬塞進 system prompt。
目前 repo 的實作是：
* **system prompt 只放一個靜態 header**
* **動態記憶內容另外注入**
* 這樣做是為了保留 prompt caching 效益。 ([GitHub][20260418-C-2])
依 `recallMode` 不同，這個靜態 header 會變：
* `context`：只說明「相關使用者背景會自動注入，沒有 memory tools」
* `tools`：只說明「你可以用 honcho_profile / honcho_search / honcho_context / honcho_reasoning / honcho_conclude」
* `hybrid`：兩者都有，自動注入 + tools 可用。 ([hermes-agent.nousresearch.com][20260418-C-1])
---
#### B. 動態注入的記憶內容分兩層
Honcho 會組一個兩層的 memory context：
**第一層：Base context**
1. Session summary
2. User representation
3. User peer card
4. AI self-representation
5. AI identity card
**第二層：Dialectic supplement**
* 也就是 Honcho 額外跑的推理摘要結果。
最後兩層會合併，再依 `contextTokens` 截斷。 ([GitHub][20260418-C-2])
---
#### C. 真正最關鍵的是 dialectic prompt
這一段才是 Honcho「怎麼思考這個使用者」的核心。
##### Pass 0：冷啟動 prompt
當還沒有 base context cache 時，會問：
> Who is this person? What are their preferences, goals, and working style? Focus on facts that would help an AI assistant be immediately useful. ([GitHub][20260418-C-2])
也就是：
**這個人是誰？他的偏好、目標、工作風格是什麼？先抓能讓 AI 立刻更有用的資訊。**
##### Pass 0：暖啟動 prompt
如果已經有 session context，則改問：
> Given what's been discussed in this session so far, what context about this user is most relevant to the current conversation? Prioritize active context over biographical facts. ([GitHub][20260418-C-2])
也就是：
**基於本 session 到目前為止的內容，這個 user 現在最 relevant 的背景是什麼？優先考慮當前活躍情境，不要只講生平。**
##### Pass 1：補洞 / 再綜合
第二輪會拿第一輪結果再追問：
> Given this initial assessment ... What gaps remain in your understanding ... grounded in evidence from recent sessions. ([GitHub][20260418-C-3])
意思是：
**剛剛那份判斷還缺什麼？請用最近 session 的證據補齊，整理出這個 user 目前狀態與立即需求。**
##### Pass 2：矛盾整合 / 收斂
第三輪則會問：
> Prior passes produced ... Do these assessments cohere? Reconcile any contradictions and produce a final, concise synthesis of what matters most for the current conversation. ([GitHub][20260418-C-3])
也就是：
**前兩輪如果有衝突，就把它們 reconcile，最後給一份精簡、適合當前對話的總結。**
這套 multi-pass 由 `dialecticDepth` 控制，並且如果前一輪訊號已經夠強，後面可以提早停止。 ([hermes-agent.nousresearch.com][20260418-C-1])
---
#### D. 初始化時還會先問一句預熱問題
在 context / hybrid mode 初始化 session 時，Hermes 會先背景預熱：
* `prefetch_context(...)`
* `prefetch_dialectic(..., "What should I know about this user?")`
也就是先跑一個很實用的總問題：
**我應該知道這個 user 的什麼事？** ([GitHub][20260418-C-3])
---
### 2) Honcho 的「固化記憶」流程是什麼？
這裡要分兩種：
#### 第一種：原始互動先被寫進 session
每回合 user / assistant 的訊息，會透過 `sync_turn()` 寫入 Honcho session。
如果訊息太長，還會切 chunk，再送 `add_messages()`。 ([GitHub][20260418-C-3])
真正寫入頻率由 `writeFrequency` 控制：
* `async`：背景寫入
* `turn`：每回合同步寫
* `session`：等 session 結束一起 flush
* `N`：每 N 回合寫一次。 ([hermes-agent.nousresearch.com][20260418-C-1])
這一層比較像是：
**先把原料存起來。**
---
#### 第二種：被提煉過的穩定事實，會固化成 conclusion
Honcho 有一個專門工具 `honcho_conclude`。
它不是存整段對話，而是存一個**持久化結論 / 事實**。文件明講，這些 conclusion 會成為 peer profile 的一部分。 ([hermes-agent.nousresearch.com][20260418-C-1])
例如可能會存成這種東西：
* 這個使用者偏好簡潔回答
* 他常問 Kubernetes / Slurm
* 他希望技術翻譯用臺灣繁體中文
* 他正在做某個專案
這種 conclusion 才是「固化記憶」真正最接近的部分。
而且刪除不是拿來修一般錯誤，而是主要用於 **PII removal**；文件甚至寫了，錯誤結論通常會隨著後續互動自行修正。 ([GitHub][20260418-C-3])
---
#### 第三種：Hermes 內建 memory 寫入，也會鏡像到 Honcho
Hermes 在 `on_memory_write()` 裡，會把內建 user memory 的新增內容，同步 mirror 成 Honcho conclusion。 ([GitHub][20260418-C-3])
也就是：
**本地 memory 有新增 user facts**
→ **Honcho 也會收到一份 conclusion**
這很重要，因為它表示 Hermes 的本地長期記憶與 Honcho 的 cross-session user model 不是完全分離的。 ([GitHub][20260418-C-3])
---
#### 第四種：session 結束時做 flush
當 session 結束時，Hermes 會呼叫 `flush_all()`，把還沒送完的訊息都補寫進去。 ([GitHub][20260418-C-3])
所以它的固化流程不是只有「對話中即時寫」，也有「結束時收尾補寫」。 ([GitHub][20260418-C-3])
---
### 3) 舊記憶怎麼搬進 Honcho？
這也是你問的「固化流程」裡很重要的一段。
#### A. 首次新 session 時，會搬 MEMORY.md / USER.md / SOUL.md
如果是一個新 session，且不是 `per-session` 策略，Hermes 會做一次 memory file migration，把本地的：
* `MEMORY.md`
* `USER.md`
* `SOUL.md`
上傳到 Honcho。 ([GitHub][20260418-C-3])
上傳時會包成 ``，而且文字明講：
* 這些內容是在 Honcho 啟用前，從本地互動整理出的記憶
* 請把它當成 foundational context。 ([GitHub][20260418-C-4])
---
#### B. 如果是中途啟用 Honcho，舊對話也可以整段搬進去
`migrate_local_history()` 會把本地既有對話包成 `prior_history.txt` 上傳，外面再包一層 ``。
同樣也會明示：這是 Honcho 啟用前就存在的對話歷史，應當視為後續互動的基礎背景。 ([GitHub][20260418-C-4])
---
### 4) 把整個流程濃縮成一句話
Honcho 在 Hermes 裡的流程其實是：
**原始對話先寫進 session → Honcho 生成 summary / representation / card → dialectic prompt 再做多輪歸納 → 穩定事實用 conclusion 固化 → 下次再把這些結果注入回 prompt。** ([hermes-agent.nousresearch.com][20260418-C-1])
---
### 5) 你如果只想抓最核心的差別
可以把它想成兩個層次：
#### 不是固化記憶本身的
* `session messages`
* `summary`
* `representation`
* `peer card`
這些比較像是**模型化後的動態記憶層**。 ([hermes-agent.nousresearch.com][20260418-C-1])
#### 最接近真正「固化」的
* `honcho_conclude`
* `on_memory_write()` mirror 到 conclusion
* 初次 migration 的 `MEMORY.md / USER.md / SOUL.md`
* 中途啟用時搬進去的 prior conversation history。 ([GitHub][20260418-C-3])
---
補一個小提醒：
**文件與目前實作在「context 注入到哪裡」的描述有一點差異。**
文件頁面有些描述會寫像是注入到 system prompt，但目前 plugin README 與實作更接近的是：**system prompt 只放靜態 header，動態 memory context 另外處理**。我會以 repo 目前的程式實作為準。 ([hermes-agent.nousresearch.com][20260418-C-1])
你要的話，我下一則可以直接幫你把這套流程畫成一張「Honcho 記憶流 / prompt 流」的文字架構圖。
[20260418-C-1]: https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho/ "Honcho Memory | Hermes Agent"
[20260418-C-2]: https://github.com/NousResearch/hermes-agent/blob/main/plugins/memory/honcho/README.md "hermes-agent/plugins/memory/honcho/README.md at main · NousResearch/hermes-agent · GitHub"
[20260418-C-3]: https://github.com/NousResearch/hermes-agent/blob/main/plugins/memory/honcho/__init__.py "hermes-agent/plugins/memory/honcho/__init__.py at main · NousResearch/hermes-agent · GitHub"
[20260418-C-4]: https://github.com/NousResearch/hermes-agent/blob/main/plugins/memory/honcho/session.py "hermes-agent/plugins/memory/honcho/session.py at main · NousResearch/hermes-agent · GitHub"
---
### 畫成一張「Honcho 記憶流 / prompt 流」的文字架構圖
- ### gpt-5.4 (2026/04/18)
可以，下面我把它整理成一張**Honcho 在 Hermes 裡的 prompt 流 + 記憶流**文字架構圖。
```text
┌─────────────────────────────┐
│ 1. 使用者送出新訊息 │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 2. Hermes 判斷 recallMode │
│ - context │
│ - tools │
│ - hybrid │
└─────────────┬───────────────┘
│
├──────────────────────────────┐
│ │
▼ ▼
┌─────────────────────────────┐ ┌─────────────────────────────┐
│ 3A. 靜態 system prompt header│ │ 3B. 動態 memory context │
│ 只放模式說明 │ │ 依 cadence 決定是否刷新 │
│ 不放大量動態記憶 │ │ 並依 token budget 截斷 │
└─────────────┬───────────────┘ └─────────────┬───────────────┘
│ │
│ ▼
│ ┌─────────────────────────────┐
│ │ Layer 1: Base Context │
│ │ - Session Summary │
│ │ - User Representation │
│ │ - User Peer Card │
│ │ - AI Self-Representation │
│ │ - AI Identity Card │
│ └─────────────┬───────────────┘
│ │
│ ▼
│ ┌─────────────────────────────┐
│ │ Layer 2: Dialectic │
│ │ - Cold prompt / Warm prompt │
│ │ - 可做 1~3 pass │
│ │ - 補洞 / reconcile │
│ └─────────────┬───────────────┘
│ │
└──────────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 4. 組成最終送給 LLM 的上下文 │
│ = static header │
│ + injected memory context │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 5. LLM 生成本回合回答 │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 6. 回合結束後寫回 Honcho │
└─────────────────────────────┘
```
---
### A. Prompt 流的核心
你可以把它想成：
```text
system prompt
= 很短的模式說明
user turn 前的動態注入
= Honcho 抓出的 relevant context
+ dialectic 推理後的補充摘要
```
也就是：
**Hermes 不把 Honcho 當成一大包永久貼在 system prompt 的記憶。**
而是每回合前，依 cadence 與 budget，動態挑出適合當前對話的背景。
---
### B. Dialectic prompt 流
#### 1. Cold start
```text
Who is this person?
What are their preferences, goals, and working style?
Focus on facts that would help an AI assistant be immediately useful.
```
用途：
* 第一次認識這個 user
* 還沒有 base context cache
* 重點是「先快速建立可用的人物模型」
---
#### 2. Warm session
```text
Given what's been discussed in this session so far,
what context about this user is most relevant to the current conversation?
Prioritize active context over biographical facts.
```
用途：
* 已經有 session context
* 重點不是生平，而是**現在這輪對話最 relevant 的東西**
---
#### 3. Pass 2 補洞
```text
根據前一輪初步判斷，
還缺哪些理解？
請根據最近 session 的證據，
補出使用者目前狀態與立即需求。
```
---
#### 4. Pass 3 收斂
```text
前面幾輪若有矛盾，
請 reconcile，
產出對當前對話最有用的最終精簡綜合。
```
---
### C. 固化記憶流
下面這張比較重要，因為你問的是「固化記憶的流程」。
```text
使用者訊息 / 助手回覆
│
▼
┌─────────────────────────────┐
│ 1. sync_turn() │
│ 原始訊息先寫入 Honcho session│
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 2. Honcho 從 session 中整理出 │
│ - summary │
│ - representation │
│ - peer card │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 3. dialectic 再做高階推理 │
│ 把零散互動變成較穩定理解 │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 4. 若需要長期保留 │
│ -> honcho_conclude() │
│ 寫成 persistent conclusion │
└─────────────┬───────────────┘
│
▼
┌─────────────────────────────┐
│ 5. conclusion 回饋到 │
│ peer card / representation │
│ 變成未來可再注入的記憶 │
└─────────────────────────────┘
```
---
### D. 哪些算「真的固化」？哪些只是中間層？
#### 只是中間整理層
```text
- session messages
- session summary
- representation
- peer card
```
這些比較像：
**從互動中即時整理出來的可讀模型**
---
#### 比較接近真正固化
```text
- honcho_conclude 寫入的 conclusion
- Hermes built-in memory 寫入後 mirror 到 Honcho conclusion
- 初次啟用時上傳的 MEMORY.md / USER.md / SOUL.md
- 中途啟用時上傳的 prior conversation history
```
所以如果你要一句話判斷：
> **Honcho 真正的固化點，不是 summary，而是 conclusion。**
---
### E. 實際時序版
```text
[回合開始]
-> Hermes 取 Honcho base context
-> Hermes 跑 dialectic（視 cadence）
-> 注入本回合 prompt
-> LLM 回答
[回合結束]
-> user / assistant message 寫入 Honcho session
-> 之後 Honcho 更新 summary / representation / card
[需要長期保留時]
-> honcho_conclude()
-> 寫入 persistent fact
-> 下次再被 representation / card 吸收
```
---
### F. 你可以直接怎麼理解它
把 Honcho 想成 4 層：
```text
第 1 層：原始對話倉庫
第 2 層：自動整理層（summary / representation / card）
第 3 層：推理層（dialectic）
第 4 層：固化層（conclusion）
```
其中最有價值的是這個轉換：
```text
一次互動
-> 被整理
-> 被理解
-> 被濃縮成可持久保留的 conclusion
-> 反過來改善下一次互動
```
---
如果你要，我下一則可以直接幫你做一版：
**「Hermes + Honcho 的最小可抄架構」**
也就是把這整套拆成：
* 資料表 / 儲存層
* prompt 組裝層
* 記憶提煉層
* conclusion 寫入規則
讓你可以直接套到自己的 agent 系統。
---
### 用小學五年級程度描述 Honcho 的做法
- ### gpt-5.4 (2026/04/18)
可以，把它想成一個**很會做筆記的助理小幫手**。
### 最簡單版本
你每次跟 Hermes 聊天時，Honcho 會做 3 件事：
#### 1. 先把對話記下來
像老師把你上課說過的話，先寫進筆記本。
這時候只是「先記錄」，還沒有變成重要重點。
#### 2. 再整理成重點
它會想一想：
* 這個人喜歡什麼回答方式？
* 他最近在忙什麼？
* 他常問哪一類問題？
* 現在這一輪聊天，什麼最重要？
然後整理成一小段「背景說明」，讓下次回答更貼近你。
#### 3. 特別重要的，才變成長期記憶
如果某件事很重要，例如：
* 你喜歡簡短回答
* 你偏好臺灣繁體中文
* 你常做某個專案
那它就會把這件事寫成**固定重點**。
這就像把「很重要、以後也會用到」的事情，寫到長期筆記裡。這個在 Honcho 裡叫做 **conclusion**。
---
### 「prompt」是什麼？用小學生版本講
你可以把 prompt 想成：
**AI 在回答前，眼前看到的提示紙條。**
Honcho 會在 AI 回答前，偷偷把一張小紙條放到旁邊，上面寫：
* 這個使用者最近在聊什麼
* 他可能喜歡什麼方式
* 現在最該注意什麼
這樣 AI 比較不會每次都像第一次認識你。
---
### Honcho 怎麼決定紙條上要寫什麼？
它會先問自己一些問題。
#### 第一次比較不熟時
它會像這樣想：
> 這個人是誰？
> 他喜歡什麼？
> 他的目標是什麼？
> 我要怎樣才能立刻幫上忙？
#### 已經聊過很多時
它會改成想：
> 在這次聊天裡，現在最重要的是什麼？
> 哪些背景最值得提醒 AI？
所以它不是每次都把全部舊資料搬出來，
而是挑「現在最有用的」給 AI 看。
---
### 「固化記憶」到底是什麼？
你可以把它想成兩種筆記：
#### 普通筆記
就是把聊天內容先記下來。
像課堂上的隨堂筆記。
#### 固化記憶
就是把真的很重要的事情，寫進「重點整理本」。
下次就更容易拿來用。
所以：
**聊天記錄 ≠ 固化記憶**
**重要重點 = 固化記憶**
---
### 一句話總結
Honcho 的做法就是：
**先把對話記下來 → 再整理出重點 → 把最重要的事變成長期記憶 → 下次回答時先偷看這些重點。**
---
### 再用一個生活比喻
你可以把它想成：
* **聊天內容** = 上課全部內容
* **整理摘要** = 課後重點整理
* **conclusion** = 考前一定要背的重點
* **prompt 注入** = 考試前先偷看重點卡
所以 Honcho 不只是「記住」，而是會做：
**記錄 → 整理 → 挑重點 → 下次先提醒 AI**。
你要的話，我可以下一則直接畫成 **超簡單 4 格圖**。
---
### 如果只是將紀錄，整理出重點，進一步擷取出關鍵/精華。也就是，可以遞迴找出當前重點，再遞迴找出當前重點（=關鍵/精華）。這樣的簡單做法，為何 Honcho 作法會如此複雜？有什麼不一樣？
- ### gpt-5.4 (2026/04/18)
你這個想法**沒有錯**。
而且我會直接說：
**如果目標只有「把長對話壓縮成重點」，
你說的遞迴摘要法，通常比較簡單、便宜、也夠用。**
Honcho 之所以看起來複雜，是因為它解決的問題**不只是一個「摘要問題」**，而是一個「**可長期使用的記憶系統**」問題。
---
### 先講最核心差別
#### 你的方法在做的事
```text
原始紀錄
-> 摘要
-> 再摘要
-> 再摘要
-> 得到精華
```
這是在做：
**「壓縮資訊」**
---
#### Honcho 在做的事
```text
原始紀錄
-> 存成 session
-> 分辨哪些是這次聊天重要
-> 分辨哪些是長期偏好
-> 分辨哪些只是暫時狀態
-> 必要時寫成長期結論
-> 下次依情境取回不同層級的記憶
```
這是在做：
**「管理記憶」**
不是只壓縮。
而是要回答：
* 現在這次聊天最重要的是什麼？
* 這個人長期的習慣是什麼？
* 哪些該短期保留，哪些該長期保留？
* 哪些該自動注入，哪些等需要時再查？
* 哪些是事實，哪些只是這一輪暫時狀態？
---
### 為什麼單純遞迴摘要不夠？
#### 1. 遞迴摘要很會「變短」，但不一定很會「分類」
例如一大串聊天裡面同時有：
* 你今天心情不好
* 你最近在做 Kubernetes
* 你長期偏好臺灣繁體中文
* 你這一輪只是臨時想看簡短版
這四種東西其實不一樣：
* 有的是**今天的暫時狀態**
* 有的是**長期偏好**
* 有的是**工作背景**
* 有的是**這一輪任務需求**
如果全部一直摘要、再摘要，最後可能變成一小段「看似精華」，但其實**不同種類的資訊混在一起**。
Honcho 會把它拆成不同層：session summary、representation、peer card、conclusion。
---
#### 2. 遞迴摘要通常只回答「整體重點」，不擅長回答「現在最 relevant 的是什麼」
你說的方法，比較像做一本愈來愈薄的筆記。
但實際對話常常需要的不是「全書最精華」，而是：
> **現在這題最該拿哪一張卡出來？**
所以 Honcho 才會分：
* **Cold start prompt**：第一次認識這個人，要先知道他是誰、偏好什麼、目標是什麼
* **Warm session prompt**：已經聊到一半了，現在最 relevant 的背景是什麼，而不是重新背這個人的人生簡介。
這就是它比單純摘要更複雜的原因之一。
---
#### 3. 遞迴摘要容易把「重要但低頻」的事壓掉
有些事情不常出現，但非常重要，例如：
* 不要保存某類隱私
* 這個人很在意某種用詞
* 某個專案名稱很重要
* 某個偏好雖然少提，但之後常影響回答方式
如果只一直摘要，低頻但重要的資訊，可能會被後面大量新資訊沖掉。
Honcho 另外做了 `honcho_conclude`，把這些值得長期保留的事，寫成 persistent conclusion。這不是普通摘要，而是**明確固化**。
---
#### 4. 遞迴摘要通常是「一條線」，Honcho 是「多種取用方式」
Honcho 不是只有一種 memory 讀法，它有：
* `honcho_profile`：快速看人物重點
* `honcho_search`：找相關片段
* `honcho_context`：看整個 session context
* `honcho_reasoning`：讓 Honcho 幫你推理
* `honcho_conclude`：寫入長期結論。
所以它不是只做「一份摘要」，而是做成像工具箱。
你要查人、查片段、查上下文、查推理答案，都有不同入口。
---
#### 5. 遞迴摘要不一定會處理「矛盾」與「自我修正」
Honcho 有 dialectic depth：
* 第一輪先看
* 第二輪補漏洞
* 第三輪檢查前面有沒有矛盾，再做 reconcile。
這表示它不是單純濃縮，而是想做：
**先判斷 → 再補洞 → 再整合衝突**
如果只是一路摘要，很多時候只是把前一份摘要再縮短，不一定真的有做「審核」這一步。
---
### Honcho 真正多做的是哪幾件事？
我用最白話方式講：
#### 不是只有「寫筆記」
而是還做了這些：
**第一，分層。**
它把記憶分成「這次聊天的重點」和「長期人物模型」。
**第二，分用途。**
有些記憶拿來直接注入 prompt；有些只在需要時用工具查。這也是為什麼它有 `context / tools / hybrid` 三種模式。
**第三，分讀寫時機。**
它不是每次都全部重算，而是用 `contextCadence`、`dialecticCadence`、`writeFrequency` 控制成本和時機。
**第四，分短期與長期。**
短期先存 session；長期才寫 conclusion。
**第五，分 user 跟 AI。**
它不只建 user model，也建 AI 自己的 representation / card，甚至有 AI peer。這不是單純摘要會做的事。
---
### 所以 Honcho 跟你的方法，真正不一樣在哪？
一句話：
**你的方法是在做「內容壓縮」；Honcho 在做「記憶編排系統」。**
---
### 什麼情況其實不用 Honcho？
如果你的需求只有這些：
* 把長對話縮短
* 留一份目前重點
* 偶爾再濃縮一次
* 不太需要跨 session 的個人化
* 不需要很細的讀寫控制
那你說的遞迴摘要法，真的很可能比較適合。
---
### 什麼情況 Honcho 才有價值？
當你需要的是：
* **跨 session** 還記得人
* 分得出**短期狀態**和**長期偏好**
* 能在不同時機，用不同方式取回記憶
* 能把特別重要的事**固化**
* 不想每次都把整包記憶塞進 prompt
* 想控制成本、注入頻率、推理深度
這時 Honcho 這種複雜度才開始有意義。
---
### 最後我直接幫你下判斷
**如果你只是想做「重點愈濃愈精」：Honcho 大多數功能都太重。**
**如果你想做「可長期運作的個人化記憶系統」：單純遞迴摘要又太薄。**
也就是：
* **摘要法**：像做一本愈來愈薄的筆記
* **Honcho**：像蓋一個小型記憶圖書館
你現在其實不是在問「誰比較強」，而是在問：
> **我要的是壓縮器，還是記憶系統？**
這才是關鍵。
如果你要，我下一則可以直接幫你畫成：
**「遞迴摘要法 vs Honcho」超簡單對照圖**
只用 6 行講完。
---
### 都還沒聊天，Honcho 怎麼知道當前有那些記憶是重要的？怎麼知道用戶要做什麼事？
- ### gpt-5.4 (2026/04/18)
對，**這就是關鍵點**：
**如果都還沒聊天，Honcho 其實不知道「現在什麼重要」、也不知道「你現在要做什麼事」。**
它不是通靈。
它只能用 **已經存在的資料** 先做「初步猜測」，如果連舊資料都沒有，那就只能**從空白開始**。
---
### 最直接的答案
#### 情況 1：真的完全沒有任何舊資料
例如：
* 沒有以前的 session
* 沒有 USER.md / MEMORY.md
* 沒有匯入舊聊天
* 沒有任何 profile
這時候 Honcho 能做的其實很少：
* session summary 可能是空的
* user representation 可能是空的
* peer card 可能是空的
程式裡也有明講：**新 session 可能拿到 null summary，這是正常的，要優雅處理。**
也就是說：
> **如果沒資料，它就不知道。**
---
#### 情況 2：還沒開始這一輪聊天，但以前聊過
這時候它不是知道「你現在要做什麼」，而是知道：
* 你是怎樣的人
* 你長期偏好什麼
* 你過去常做什麼
* 你最近可能在忙什麼
所以它能做的是：
> **先帶著「舊印象」來迎接這一輪對話。**
這不是知道當前任務，
而是知道「這個 user 大概是誰」。
---
### 為什麼它還能講「當前重要」？
這裡要分兩種「當前」。
#### A. 你說的「當前」：還沒聊之前
這時 Honcho 其實不知道真正當前重點。
它最多只能用 cold start 的方式先問：
* 這個人是誰？
* 有哪些偏好？
* 有哪些目標？
* 哪些背景可能先知道會有幫助？
注意，是 **可能有幫助**，不是 **已經知道你現在要幹嘛**。
---
#### B. Honcho 說的「當前」：已經看到這輪對話一些內容之後
例如你一開口說：
* 幫我看 Hermes
* 幫我比較 Honcho
* 幫我翻譯這段話
這時它就可以把：
* 你的長期偏好
* 你剛剛這一輪講的內容
* 最近幾次對話脈絡
合在一起，去判斷：
> **對這一輪最重要的是什麼。**
所以「當前重要」通常不是在**完全零訊息**下產生的，
而是在**至少有一些當前線索**後，才比較準。
---
### 那 cold start 到底是在做什麼？
你可以把 cold start 想成：
> **先用舊資料，做一份「入場前備忘錄」**
不是說它知道你這一刻要做什麼，
而是先整理出：
* 這個人可能喜歡怎樣的回答
* 這個人以前常處理哪些主題
* 這個人有哪些固定習慣
這樣至少第一句回答不會完全像陌生人。
---
### 那如果連舊資料都沒有，Honcho 不就沒用了？
在第一輪，對，**幾乎沒什麼可用的個人化內容**。
但一旦你開始講第一句話後，它就開始累積：
1. 先記錄這輪對話
2. 再整理成 session summary / representation / card
3. 覺得真的重要的，再寫成 conclusion
4. 下次就不再是空白了。
所以 Honcho 的強項不是：
> **第一次就神準知道你要什麼**
而是：
> **第二次、第三次、第四次開始，愈來愈懂你。**
---
### 你可以把它想成兩種資訊
#### 1. 先天沒有的
它一開始不知道：
* 你這一輪任務是什麼
* 你今天心情如何
* 你現在最想做哪件事
* 這次聊天真正目標是什麼
這些一定要靠你這一輪講出來。
---
#### 2. 可以先帶進來的
如果以前有資料，它可以先知道：
* 你偏好繁體中文
* 你偏好簡潔還是詳細
* 你過去常問哪些領域
* 你有沒有固定專案脈絡
這些能幫它比較快進入狀況。
---
### 最準確的一句話
**Honcho 不是先知道「你現在要做什麼」，而是先知道「你大概是怎樣的人」；等你一開口，它才把這一輪需求和舊記憶合起來。**
---
### 你前面那句流程，修正成更準的版本會是這樣
```text
如果有舊資料：
舊資料
-> 先整理出可能有用的背景
-> 等使用者這一輪開口
-> 再判斷這一輪什麼最重要
-> 必要時寫成長期結論
如果沒有舊資料：
從空白開始
-> 先聽這一輪在說什麼
-> 再慢慢建立記憶
-> 下次才有背景可用
```
---
### 最後一句，最白話
**沒聊天前，它不知道你現在要幹嘛。**
**它最多只知道你「平常像什麼樣的人」。**
**真正的「當前重點」，要等你這一輪開始說話後，才會慢慢浮現。**
你要的話，我可以下一則直接幫你畫成：
**「第一次聊天」vs「聊過很多次」的超簡單對照圖**
---
### peer card 是什麼？
- ### gpt-5.4 (2026/04/18)
`peer card` 可以把它想成：
> **某個對話參與者的「人物小卡 / 重點卡」**
這個參與者就是 `peer`。
在 Honcho 裡，`peer` 可以是：
* 使用者
* AI
* 其他被記錄的對象
所以 `peer card` 就是：
> **「這個人是誰、有哪些重要特徵」的精簡卡片**
Hermes repo 裡對它的描述很接近：
它是 **curated list of key facts**，也就是「整理過的重要事實清單」，內容可能包含：
* 名字
* 角色
* 偏好
* 溝通風格
* 常見模式
---
### 用很白話的方式講
如果 session summary 像是：
> 「這次上課老師講了什麼」
那 peer card 比較像：
> 「這位同學平常是怎樣的人」
例如可能長這樣：
* 喜歡簡短回答
* 常問技術問題
* 偏好臺灣繁體中文
* 做事很重視結構
* 常處理 Kubernetes / Slurm
這不是「這一輪聊了什麼」，
而是「這個人有哪些值得先知道的特徵」。
---
### 它的用途是什麼？
用途就是讓 AI 很快知道：
> **我現在是在跟怎樣的人互動？**
這樣 AI 不用每次都重讀全部歷史，
只要先看這張小卡，就能比較快進入狀況。
在 Honcho 的 context 裡，`peer card` 也是 base context 的一部分，會跟 summary、representation 一起提供給 agent。
---
### 它和其他幾個東西差在哪？
#### 1. `session summary`
是：
> **這次聊天的重點**
它偏向事件、任務、當前脈絡。
---
#### 2. `peer card`
是：
> **這個人的重點特徵卡**
它偏向人物、習慣、偏好。
---
#### 3. `representation`
是：
> **用一段比較完整的描述，來說明這個人**
通常比 peer card 更像一小段文字說明。
---
#### 4. `conclusion`
是：
> **某條被固化保存的重要事實**
而這些 conclusion 之後可能會回饋進 peer card 或 representation。
也就是說，conclusion 比較像「原料」，peer card 比較像「整理後的小卡」。
---
### 最短版一句話
**peer card = 某個人的重點資料卡。**
不是完整歷史，
不是整段摘要，
而是：
> **讓 AI 快速知道「這個人有什麼值得記住的特徵」的精簡卡片。**
如果你要，我下一則可以直接幫你做一個
**`summary / representation / peer card / conclusion` 四者超簡單對照表**。
---
### `summary / representation / peer card / conclusion` 四者超簡單對照表
- ### gpt-5.4 (2026/04/18)
可以，這是超簡單對照表：
| 名稱 | 最白話意思 | 記的是什麼 | 比較像什麼 |
| ---- | -------- | --------- | ------- |
| `summary` | 這次聊天重點 | 這一輪 / 這個 session 在做什麼 | 上課重點整理 |
| `representation` | 對這個人的整體描述 | 這個人是怎樣的人、常做什麼、風格如何 | 人物介紹短文 |
| `peer card` | 人物重點卡 | 精簡版的重要特徵、偏好、習慣 | 人物小卡 / 重點條列 |
| `conclusion` | 被固定保存的一條重要事實 | 某個值得長期記住的事 | 單條永久筆記 |
---
### 再用一句一句講
#### 1. `summary`
是在說：
> **這次聊天主要在講什麼**
例如：
* 這次在討論 Hermes 與 Honcho
* 這次在看記憶系統設計
* 這次在比較摘要法與 Honcho
所以它偏向「**這一輪發生什麼事**」。
---
#### 2. `representation`
是在說：
> **這個人大致上是怎樣的人**
例如：
* 他偏好結構化說明
* 他常問技術架構問題
* 他喜歡從原理比較差異
* 他會追問流程與設計原因
所以它偏向「**整體人物描述**」。
---
#### 3. `peer card`
是在說：
> **這個人的重點條列卡**
例如：
* 偏好臺灣繁體中文
* 喜歡簡潔但有重點
* 常討論 agent / memory / LLM
* 重視實作流程與差異比較
所以它偏向「**重點條列版人物資訊**」。
比 `representation` 更短、更像卡片。
---
#### 4. `conclusion`
是在說：
> **某一條應該長期保存的重要事實**
例如：
* 使用者偏好臺灣繁體中文
* 使用者常問 Kubernetes / Slurm
* 使用者喜歡用對照方式理解概念
這種是一條一條存的。
之後可能會被整理進 `peer card` 或 `representation`。
---
### 最好記的版本
你可以這樣背：
```text
summary = 這次聊了什麼
representation = 這個人大致是誰
peer card = 這個人的重點小卡
conclusion = 一條被固定保存的重要事實
```
---
### 再用學校比喻一次
* `summary`：這節課老師教了什麼
* `representation`：這位同學整體是怎樣的人
* `peer card`：這位同學的重點小卡
* `conclusion`：老師特別寫下來、以後要記得的一條重點
---
### 關係圖
```text
聊天內容
-> 整理成 summary
-> 慢慢形成 representation
-> 再濃縮成 peer card
-> 特別重要的單條事實可寫成 conclusion
-> conclusion 又可能反過來影響 representation / peer card
```
如果你要，我下一則可以直接用**一組實際例子**示範：
同一段對話，分別會長成 `summary / representation / peer card / conclusion` 什麼樣子。
{%hackmd vaaMgNRPS4KGJDSFG0ZE0w %}