1. 为什么我要把 Hermes Agent 和 OpenClaw 的记忆系统放在一起测Hermes Agent 和 OpenClaw 这两个名字最近在 Agent 圈子里被反复提起但真正让我想动手对比的是它们对「记忆」这件事的底层态度完全不同。OpenClaw 的记忆系统走的是广度优先路线Skills 是人工编写的静态文件记忆主要靠 Markdown 文件做基础存储结构简单、上手快但跨会话的持久化和检索能力偏弱。Hermes Agent 则是深度优先的自学习体记忆被拆成声明式、程序式、情景式和身份四个 store每个 store 有独立的存储格式、检索路径和失败模式越用越「聪明」。我关心的问题很具体在同一个 TaoToken 统一 Key 和 API 通道下我能不能用一套配置骨架分别接入两个 Agent 的记忆模块然后通过日志和调用记录直观地看到记忆读写到底有没有生效这篇文章就是围绕这个目标展开的。你会看到settings.json和config.toml的可复制骨架、同一 Key 分别接入两个 Agent 的具体步骤、验证请求的完整命令以及我在实测中踩过的坑。适合正在选型 Agent 框架、或者想搞清楚「记忆持久化到底差在哪」的开发者。TaoToken 在这里的角色是统一入口官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址 https://taotoken.net/api 。一个 Key 同时喂给两个 Agent省去分别管理凭证的麻烦也让对比实验的变量更干净。2. TaoToken 前置准备统一 Key 与通道配置在动两个 Agent 的配置文件之前先把 TaoToken 这边的准备工作做完。这一步不复杂但顺序错了后面会反复报 401。2.1 获取统一 Key登录 TaoToken 控制台进入 API Keys 页面创建一个新 Key。建议按用途命名比如agent-memory-test方便后面在日志里区分调用来源。创建后立刻复制保存页面刷新后就不再完整显示。控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content2.2 确认 Base URL 与模型名TaoToken 的 API 基地址是https://taotoken.net/api兼容 OpenAI 风格的/v1/chat/completions路径。模型名按你实际要用的填比如claude-sonnet-4-20250514或gpt-4o具体以文档里的模型列表为准。接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content2.3 用 curl 先验证 Key 可用在配置任何 Agent 之前先用一条最小请求确认 Key 和通道是通的curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: ping}], max_tokens: 16 }返回里能看到choices[0].message.content就说明通道正常。这一步过了后面两个 Agent 的报错就基本可以排除是 Key 的问题。注意把 Key 写进环境变量TAOTOKEN_API_KEY不要硬编码进配置文件提交到仓库。两个 Agent 都读同一个环境变量这也是「统一 Key」的关键。3. 可复制配置骨架settings.json 与 config.toml两个 Agent 的配置格式不同Hermes Agent 用settings.jsonOpenClaw 用config.toml。下面给出的是记忆模块相关的最小骨架你可以直接复制后改路径。3.1 Hermes Agent 的 settings.json 骨架Hermes 的记忆系统围绕四个 store 组织配置里需要显式声明各 store 的落盘位置和预算。声明式记忆存在MEMORY.md2200 字符和USER.md1375 字符程序式记忆存在SKILL.md情景式记忆进 SQLite 并带 FTS5 全文搜索。{ agent: { name: hermes-memory-test, api_base: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, model: claude-sonnet-4-20250514 }, memory: { declarative: { memory_file: ~/.hermes/MEMORY.md, user_file: ~/.hermes/USER.md, memory_budget: 2200, user_budget: 1375, frozen_snapshot: true }, procedural: { skills_dir: ~/.hermes/skills, auto_create: true, min_tool_calls: 5 }, episodic: { db_path: ~/.hermes/sessions.db, fts5: true, auto_record: true }, nudge: { interval: 10, flush_min_turns: 6 } } }几个参数值得单独说。frozen_snapshot: true是 Hermes 的关键设计记忆在 session 开始时从磁盘加载一次作为冻结快照注入系统提示词session 中途的写入进磁盘但不更新提示词目的是保住前缀缓存的稳定性。nudge.interval: 10表示每 10 轮插入一次提醒让 agent 评估最近有没有值得持久化的内容。min_tool_calls: 5是程序式记忆的触发门槛任务超过 5 次工具调用才会提议保存成 skill。3.2 OpenClaw 的 config.toml 骨架OpenClaw 的记忆结构简单得多主要是 Markdown 文件存储加静态 Skills。配置骨架如下[agent] name openclaw-memory-test api_base https://taotoken.net/api api_key_env TAOTOKEN_API_KEY model claude-sonnet-4-20250514 [memory] type markdown store_path ~/.openclaw/memory.md max_chars 4000 auto_save true [skills] dir ~/.openclaw/skills mode static auto_create false [session] persist true db_path ~/.openclaw/sessions.db对比很明显OpenClaw 没有声明式/程序式/情景式的拆分记忆就是一个memory.mdSkills 是static模式、不自动创建。auto_save: true会在会话结束时把内容写回文件但没有 Hermes 那种 nudge 节奏和冻结快照机制。3.3 两个配置的对照表维度Hermes AgentOpenClaw配置文件settings.jsonconfig.toml记忆存储四 store 分离单一 Markdown声明式预算2200 1375 字符4000 字符情景式检索SQLite FTS5无全文索引Skills 生成Agent 自动创建人工静态编写快照策略冻结快照无写入触发nudge 轮次计数会话结束这张表是后面验证环节的判断依据如果 Hermes 的日志里出现了 nudge 触发的写入而 OpenClaw 只在会话结束才写盘那就说明两者的记忆节奏确实不同。4. 同一 Key 分别接入两个 Agent 的记忆模块配置骨架有了接下来把同一个 TaoToken Key 分别喂给两个 Agent并让它们的记忆模块跑起来。4.1 接入 Hermes Agent先导出环境变量两个 Agent 共用export TAOTOKEN_API_KEY你的Key然后启动 Hermes指定配置文件hermes run --config ~/.hermes/settings.json --session memory-test-01启动后Hermes 会执行_build_system_prompt()按 12 层顺序组装系统提示词。其中第 5 到第 6 层来自MemoryStore.load_from_disk()的冻结快照第 7 层是 skills 索引。你可以在启动日志里看到类似输出[memory] loaded MEMORY.md (0 chars), USER.md (0 chars) [memory] frozen snapshot injected at layer 5-6 [skills] index built, 0 skills registered第一次跑的时候两个文件都是空的这是正常的。接下来做几轮对话触发记忆写入。4.2 接入 OpenClawOpenClaw 的启动方式类似openclaw start --config ~/.openclaw/config.toml --session memory-test-01它的启动日志更简单[memory] markdown store initialized at ~/.openclaw/memory.md [skills] static mode, loaded 0 skills [session] persistence enabled注意 OpenClaw 没有「冻结快照」这一步记忆文件在会话期间是直接读写的所以它的日志里不会出现快照注入的记录。这是两者在记忆持久化上的第一个可观测差异。4.3 触发记忆写入的对话设计为了让对比有意义我给两个 Agent 喂了同一组对话覆盖三类知识第一轮用户说「我用的是深色主题讨厌浅色」。这是用户偏好Hermes 应该路由到USER.mdOpenClaw 应该写进memory.md。第二轮到第八轮让 Agent 完成一个多步骤任务比如「帮我写一个批量重命名文件的脚本要求支持正则」。这是可复用流程Hermes 在超过 5 次工具调用后应该提议创建 skillOpenClaw 因为是 static 模式不会自动创建。第九轮用户问「我之前说过我讨厌什么主题」。这是情景式检索Hermes 应该从 SQLite 的 FTS5 里搜出历史消息OpenClaw 则依赖memory.md里的记录。5. 验证请求与成功结果日志与调用记录怎么看配置跑通只是第一步真正要确认的是「记忆读写有没有生效」。我用三个信号来判断。5.1 信号一记忆文件的字符数变化Hermes 的声明式记忆有预算限制写入后可以直接看文件大小wc -c ~/.hermes/USER.md ~/.hermes/MEMORY.md如果第一轮对话后USER.md从 0 变成了几十个字符说明用户偏好被正确路由到了声明式 store。OpenClaw 这边wc -c ~/.openclaw/memory.md同样应该看到增长。但区别在于Hermes 的写入受nudge.interval控制可能要到第 10 轮才落盘OpenClaw 的auto_save在会话结束时才写。所以如果你在第 3 轮就去查文件可能两个都还没写——这不是 bug是节奏差异。5.2 信号二SQLite 里的情景式记录Hermes 的情景式记忆每条消息都进 SQLite带 FTS5 全文搜索。可以直接查sqlite3 ~/.hermes/sessions.db \ SELECT COUNT(*) FROM messages WHERE session_idmemory-test-01;再用 FTS5 搜关键词sqlite3 ~/.hermes/sessions.db \ SELECT snippet(messages_fts) FROM messages_fts WHERE messages_fts MATCH 深色;能搜出「深色主题」相关的片段就说明情景式记忆的写入和检索都生效了。OpenClaw 的sessions.db没有 FTS5 索引只能按 session_id 查原始记录检索能力弱一截。5.3 信号三TaoToken 调用记录最后一个信号来自 TaoToken 侧。在控制台的调用记录里你能看到两个 Agent 的请求都带着同一个 Key但请求特征不同Hermes 在压缩触发时会额外调用一次辅助模型做记忆 flush日志里会出现flush_memories()的记录对应一次只开放 memory tool 的 API 调用。OpenClaw 没有这个机制调用记录里只有常规对话请求。调用记录入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content如果你在记录里看到 Hermes 的请求数比 OpenClaw 多出几次且时间点集中在长会话的中后段那大概率就是记忆 flush 和压缩在起作用。5.4 成功结果的判断标准把三个信号合起来成功的标准是Hermes 的USER.md有内容、SQLite 能 FTS5 搜到历史、TaoToken 记录里有 flush 调用OpenClaw 的memory.md有内容、session 记录可查、但没有额外的 flush 调用。满足这些就说明同一 Key 下两个 Agent 的记忆模块都跑通了且差异可观测。6. 本篇常见错排查我在实测里踩了几个坑列出来帮你省时间。401 报错但 curl 能通。大概率是 Agent 读环境变量的方式和你想的不一样。Hermes 读api_key_env指定的变量名OpenClaw 也是但如果你在settings.json里写了api_key_env: TAOTOKEN_API_KEY却在另一个 shell 里 export进程就看不到。确认启动 Agent 的 shell 里echo $TAOTOKEN_API_KEY有值。记忆文件一直不增长。先看轮次。Hermes 的nudge.interval默认 10flush_min_turns默认 6短会话不会触发写入。OpenClaw 的auto_save在会话结束时才写中途查文件是空的。把会话拉长到 10 轮以上再查。SQLite 里搜不到中文。FTS5 默认分词器对中文支持有限如果搜「深色」没结果试试搜单个字或者用LIKE兜底sqlite3 ~/.hermes/sessions.db \ SELECT content FROM messages WHERE content LIKE %深色% LIMIT 5;Skills 没有自动创建。Hermes 的min_tool_calls默认 5任务太简单不会触发。另外auto_create要设为true。OpenClaw 的mode是static本来就不会自动创建这是设计差异不是故障。两个 Agent 的 session 串了。我给两个 Agent 用了同一个 session 名memory-test-01但它们的 db 路径不同所以不会真串。如果你把db_path配成同一个文件那就会互相覆盖务必分开。TaoToken 调用记录里看不到 flush。flush 只在压缩触发时才发生而压缩需要上下文跨过阈值。短会话不会触发把对话拉长到 token 估算超过 50% 再看。7. 长期编码与 Agent 场景的 CTA如果你打算把这类 Agent 用在长期编码或者自动化任务上记忆系统的差异会随着使用时长被放大。Hermes 的四 store 拆分和 nudge 节奏适合需要跨会话积累知识的场景OpenClaw 的简单 Markdown 存储适合轻量、一次性的任务。两者都能通过同一个 TaoToken Key 接入切换成本很低。想深入试 Hermes 的记忆闭环可以从模型对话入口先跑几轮对话观察记忆写入的节奏https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content如果你要长期跑编码类 AgentCoding Plan 提供了更适合持续调用的通道配置https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入过程中遇到报错先查 API Keys 和接入文档大部分 401 和 404 都能在那里找到答案https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentClaude Code 相关的 Anthropic 通道配置可以参考https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content实测下来把两个 Agent 的记忆模块放在同一个 Key 下对比最大的收获不是谁更强而是你能清楚看到「记忆持久化」这件事在不同架构里的成本结构Hermes 用预算约束换信号密度OpenClaw 用简单结构换上手速度。选哪个取决于你的任务需要跨会话积累多少知识。
