1. 为什么 OpenClaw 式记忆越用越慢从流水账到分层存储的认知修正很多人第一次给 Agent 加记忆思路都很朴素把聊天记录全塞进上下文或者写一个不断追加的memory.md。我早期用 OpenClaw 就是这么干的头两天感觉良好第三天开始发现首字延迟从 1 秒涨到 6 秒改一次记忆文件整段对话的缓存全部失效账单也跟着涨。问题不在模型而在记忆的存放位置和更新时机。OpenClaw 的典型误区有三个。第一是「单一上下文幻想」把长期偏好、临时任务、历史对话混在一个 Prompt 里导致每次对话都要重新处理几千 token 的冗余内容。第二是「频繁改写头部」用户说一句「我喜欢简洁回答」Agent 立刻把这条写进系统提示词顶部结果 Prompt Caching 从第一个字符就失配缓存命中率直接归零。第三是「只存不取」记忆文件越写越长却没有检索机制模型要么看不到关键信息要么被无关内容淹没。Hermes Agent 的记忆系统正是针对这三点做的修正。它把记忆拆成四层精简提示词记忆MEMORY.md与USER.md、基于 SQLite 的会话回溯session_search、以 Skills 形式存在的程序记忆、以及可选的 Honcho 深度用户建模。核心思想是冷热分离——高频感知的内容放在 Prompt 里低频回溯的内容放进数据库两者用不同的成本和不同的更新频率管理。这篇文章会带你把这套架构落到自己的 Agent 工作流里。你会看到 System Prompt 的装配顺序为什么不能调换、MEMORY.md的字符限制怎么设、session_search如何用 SQLite 做全文检索以及怎么通过 TaoToken 统一 Key 和 API 通道把整条链路跑通。适合已经在写 Agent、被上下文膨胀和缓存失效折磨过的开发者也适合刚接触 Prompt Caching 想搞懂「为什么改一个字就变慢」的朋友。先说结论记忆系统的关键不是记住更多而是在正确的层级、以正确的成本、记住正确的事情。下面从接入准备开始一步步复现。2. TaoToken 前置准备统一 Key 与 API 通道让记忆实验可复现在动手改记忆架构之前得先把模型调用通道固定下来。原因很实际Hermes 的记忆系统高度依赖 Prompt Caching 的稳定性而不同供应商的缓存策略、模型 ID 命名、Base URL 格式都不一样。如果今天用 A 家的接口、明天换 B 家缓存命中率的数据就没法对比你根本不知道是记忆架构的问题还是通道的问题。TaoToken 在这里的作用是提供一个统一的 Key 和 API 入口把模型对话、Coding Plan、控制台、API Keys 管理收敛到一处。你只需要维护一套凭证就能在 Hermes 的配置里稳定指向同一个 Base URL做记忆实验时变量更少。先拿到凭证。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite API Keys 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。创建时建议按用途命名比如hermes-memory-dev方便后面区分实验环境和生产环境。拿到 Key 之后记下两个东西Base URL 是https://taotoken.net/api以及你要用的 Model ID。Hermes 的记忆压缩和session_search摘要通常会用一个低成本辅助模型主对话用能力更强的模型所以建议准备两个 Model ID。具体可用列表在接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里能查到文档里也写了各模型的上下文窗口和缓存支持情况选之前对一下。如果你打算长期跑编码类 Agent可以顺带看下 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它更适合高频、长会话的场景。只是想先验证模型对话是否通用模型对话页 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 快速试一句就行。这里有个容易踩的坑很多人把 Key 直接写进代码或提交到 Git。正确做法是放进环境变量Hermes 的配置里用占位符引用。下面一节会给出完整的配置片段包括环境变量、settings.json和auth.json三件套确保 Base URL、Key、Model ID 都对齐。注意TaoToken 是合规的 API 接入通道配置时只填官方给出的 Base URL不要自行拼接或改写路径否则会出现 404 或鉴权失败。准备好 Key 和 Model ID 后就可以进入配置环节了。3. 可复制配置System Prompt 装配顺序与 settings.json / auth.json 三件套这一节是全文的核心配置写错后面全白搭。Hermes 的记忆系统之所以能稳住 Prompt Caching靠的是一条严格不可调换的装配流水线。先理解顺序再写配置。System Prompt 的组装顺序从[0]到[10]变动频率从恒定到最高顺序模块职能变动频率[0]Core Identity默认智能体身份设定恒定[1]Tool Guidelines工具使用行为指南恒定[2]Honcho Module可选外部用户建模集成低[3]System Message开发者定义的静态系统消息低[4]MEMORY.md固化的个人笔记快照中仅会话开始更新[5]USER.md固化的用户画像快照中仅会话开始更新[6]Skills Index智能体技能索引中[7]Context Files规则定义文件中[8]Environment日期、时间、OS 平台高[9]History压缩后的历史对话极高[10]User Message当前用户输入最高LLM 的缓存匹配是从第一个字符开始的连续块。把[0]到[7]这些稳定前缀放头部即使对话持续几十轮头部缓存依然命中首字延迟就不会随轮次线性上涨。反过来如果你把Environment或History提到前面每轮都变缓存全废。先配环境变量。在~/.hermes/.env里写TAOTOKEN_API_KEYsk-your-key-here TAOTOKEN_BASE_URLhttps://taotoken.net/api HERMES_MAIN_MODELyour-main-model-id HERMES_SUMMARY_MODELyour-cheap-model-id然后是~/.hermes/settings.json这是主配置文件路径和字段名要和 Hermes 读取的一致{ provider: { base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, main_model: your-main-model-id, summary_model: your-cheap-model-id }, memory: { memory_file: ~/.hermes/memories/MEMORY.md, user_file: ~/.hermes/memories/USER.md, memory_char_limit: 2200, user_char_limit: 1375, session_db: ~/.hermes/sessions/sessions.db, flush_before_compress: true }, prompt: { assembly_order: [ core_identity, tool_guidelines, honcho, system_message, memory_md, user_md, skills_index, context_files, environment, history, user_message ] } }如果你用的是 Codex 风格的鉴权文件~/.hermes/auth.json这样写{ base_url: https://taotoken.net/api, api_key: sk-your-key-here, model: your-main-model-id }三件套对齐检查Base URL 必须是https://taotoken.net/apiKey 必须和api_key_env指向的环境变量一致Model ID 必须和文档里列出的完全匹配。任何一处不一致都会在验证阶段报错。接着建记忆目录和文件mkdir -p ~/.hermes/memories ~/.hermes/sessions touch ~/.hermes/memories/MEMORY.md ~/.hermes/memories/USER.mdMEMORY.md限 2200 字符只记项目背景、工具怪癖、报错教训。USER.md限 1375 字符只记沟通风格、个人身份。注意是字符限制不是 token 限制这样逻辑和具体模型的 Tokenizer 解耦换模型不用重算。初始化 SQLite 会话库sqlite3 ~/.hermes/sessions/sessions.db CREATE TABLE IF NOT EXISTS sessions ( id INTEGER PRIMARY KEY AUTOINCREMENT, session_id TEXT NOT NULL, role TEXT NOT NULL, content TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE VIRTUAL TABLE IF NOT EXISTS sessions_fts USING fts5( content, session_id, tokenizeporter ); session_search就靠sessions_fts这个全文索引表做长尾回溯。配置到这里装配线和持久化层都齐了。4. 验证请求与成功结果session_search 全文检索与记忆冲刷实测配置写完必须验证否则你不知道缓存到底有没有命中、session_search能不能召回。分三步走。第一步验证基础连通。用 curl 打一次模型对话接口curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: your-main-model-id, messages: [{role: user, content: ping}] }返回里能看到choices[0].message.content就说明通道通了。如果这里就报错先跳到第 5 节排障。第二步验证session_search。先往 SQLite 里插几条历史会话sqlite3 ~/.hermes/sessions/sessions.db INSERT INTO sessions (session_id, role, content) VALUES (s1, user, 我们三个月前讨论过用 SQLite 做 Agent 记忆的冷存储), (s1, assistant, 是的冷热分离能显著降低首字延迟); INSERT INTO sessions_fts (content, session_id) VALUES (我们三个月前讨论过用 SQLite 做 Agent 记忆的冷存储, s1), (是的冷热分离能显著降低首字延迟, s1); 然后跑一次全文检索sqlite3 ~/.hermes/sessions/sessions.db SELECT session_id, content FROM sessions_fts WHERE sessions_fts MATCH SQLite AND 记忆 LIMIT 5; 能召回那条三个月前的记录说明长尾回溯链路通了。Hermes 在真实运行时会用一个低成本辅助模型对召回结果做摘要再把精华结论反馈给主模型而不是把原始会话全塞回去。第三步验证记忆冲刷。在长对话触发压缩前Hermes 会下达指令让模型把值得留存的偏好写入MEMORY.md。你可以手动模拟一次echo ## 项目背景 - 使用 TaoToken 统一 API 通道 - 主模型与摘要模型分离 ## 教训 - 不要在会话中途改写 Prompt 头部会破坏缓存 ~/.hermes/memories/MEMORY.md wc -c ~/.hermes/memories/MEMORY.mdwc -c输出要小于 2200。超了就精简只留经过验证的事实不记 TODO 和任务进度。成功结果长这样连续对话 20 轮后首字延迟稳定在 1 秒出头没有随轮次上涨session_search能召回早期会话MEMORY.md在新会话开始时被重新加载会话中途的写入落盘但不立即改变当前 Prompt。这三点同时满足说明记忆修正效果复现成功。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照配置和验证过程中报错基本集中在四类。逐个对照。401 Unauthorized。最常见的原因是 Key 没生效或 Base URL 写错。检查~/.hermes/.env里的TAOTOKEN_API_KEY是否和settings.json的api_key_env指向一致auth.json里的api_key是否同步。Base URL 必须是https://taotoken.net/api多一个斜杠或少一个路径段都会 401 或 404。改完记得重启 Hermes 进程环境变量不会热加载。local proxy failed。这个报错通常出现在你本地配了转发规则但目标地址不可达。先确认没有多余的本地转发配置直接指向 TaoToken 的 Base URL 即可。检查settings.json的provider.base_url和auth.json的base_url是否都是官方地址两处不一致会导致请求走到错误端点。reading choices 报错。典型信息是cannot read property choices of undefined说明返回体结构和你预期的不一样。多半是 Model ID 写错了接口返回了错误对象而不是正常的choices数组。对照接入文档里的 Model ID 列表逐个核对注意大小写和连字符。另外确认请求头Content-Type: application/json没漏。OAuth 相关报错。如果你用的是 Codex 风格鉴权auth.json字段名写错会触发 OAuth 流程失败。确认三个字段base_url、api_key、model缺一不可。不要混用环境变量和auth.json两套凭证选一套即可混用会导致鉴权头重复或冲突。再补一个隐蔽的坑MEMORY.md超过 2200 字符后Hermes 可能截断或拒绝加载表现为「记忆明明写了却读不到」。用wc -c定期检查。USER.md同理上限 1375 字符。排障顺序建议先 curl 验证通道再查配置文件三件套最后看记忆文件大小和 SQLite 索引。大部分问题在前两步就能定位。6. 把记忆修正接进你的 Agent 工作流从验证到长期运行跑通验证之后接下来是让它稳定运行。几个实操建议。会话中途写入记忆会落盘但不会立即改变当前 Prompt只有新会话或触发压缩重建时才生效。这个设计是为了维护缓存稳定性别想着「写完立刻生效」那会破坏整个装配线的意义。如果你确实需要中途生效手动触发一次压缩重建。session_search的召回质量取决于 SQLite 全文索引的维护。定期VACUUM和重建sessions_fts避免索引膨胀。召回结果交给低成本辅助模型摘要时控制摘要长度只回传结论不回传原文。模型选择上主对话用能力强的摘要和记忆冲刷用低成本的。两个 Model ID 都通过 TaoToken 统一通道调用切换时只改配置不改代码。长期跑编码类 Agent 的话Coding Plan 比按量调用更划算接入方式在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 有说明。最后回到那句核心判断真正的诀窍不在于记住更多而是在正确的层级、以正确的成本记住正确的事情。Prompt 负责高频感知SQLite 负责低频回溯MEMORY.md和USER.md负责固化事实Skills 负责程序化操作。四层各司其职缓存才稳延迟才低账单才可控。把这套配置跑一遍你会明显感觉到 Agent 从「越用越慢」变成「越用越稳」。