1. 为什么记忆系统是 HermesAgent 的生死线如果你用过一段时间的 AI Agent大概率遇到过这种尴尬昨天刚跟它讲清楚项目用 FastAPI 加 SQLite今天开新会话它又问你「请问您想用什么技术栈」。这不是模型变笨了而是它压根没记住你。HermesAgent 想解决的就是这件事——它把记忆拆成五层从最底层的 SQLite 会话记录到最上层的技能提取再叠一个 Honcho 式的用户建模让 Agent 跨会话保持连续性。这篇是深度拆解系列的第五篇聚焦记忆系统与用户建模的工程落地。我会用 TaoToken 的统一 Key 把配置骨架跑起来给你一份可复制的 settings.json 和 config.toml然后做一次「写入—召回」验证确认本地记忆闭环真的能观测到。适合已经在折腾 Agent 记忆、或者准备给自研 Agent 加用户画像的开发者。读完你能拿到一套能跑的最小配置而不是停留在架构图层面。先说清楚 HermesAgent 记忆的五层结构后面配置才有对照。L1 是 SessionDB用 SQLite 存原始对话零外部依赖L2 是 FTS5 全文搜索加 LLM 摘要负责跨会话回忆L3 是 Agent 策展记忆Agent 自己判断什么值得长期保存L4 是 Honcho 辩证用户建模用「当前画像 vs 新证据」合成更新L5 是技能记忆从经验里提取可复用技能。这五层最终都要注入系统提示词才能影响行为。我试过只配 L1 和 L2 就跑结果 Agent 能回忆起「上次聊过部署」但完全不知道你是谁、偏好什么风格。所以用户建模这层不能省它决定了 Agent 是「记得事」还是「记得你」。2. TaoToken 前置统一 Key 与接入准备HermesAgent 的记忆链路里L2 的语义摘要、L3 的策展评估、L4 的用户建模合成全都要调 LLM。如果每个环节各配一个厂商 Key配置文件会迅速失控。TaoToken 的价值就在这里一个统一 Key 覆盖这些调用配置里只维护一份 base_url 和 api_key换模型也不用改多处。你需要先拿到 Key。访问控制台创建控制台入口https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentconsoleAPI Keys 管理https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentapi-keys创建后把 Key 存到环境变量别硬编码进配置文件。我习惯这样export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api注意 base_url 用https://taotoken.net/api不要加 UTM 参数那是给网页链接用的API 端点保持干净。Key 的权限建议只开对话和补全记忆系统用不到其他能力。接入文档在这里配置字段对不上时可以查接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc如果你后面要跑长期编码或 Agent 任务记忆写入频率会很高可以考虑 Coding Plan 分摊成本Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan前置就这些。核心原则一句话记忆系统的所有 LLM 调用走同一个 Key配置里只留一个 provider 段。3. 可复制配置settings.json 与 config.toml 骨架HermesAgent 的配置分两块settings.json管运行时行为config.toml管记忆层参数。下面这份骨架是我实测能跑通的最小集你可以直接抄。先看settings.json重点是 provider 段统一指向 TaoToken{ provider: { name: taotoken, base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, default_model: claude-sonnet-4-20250514, auxiliary_model: claude-haiku-4-20250514 }, memory: { enabled: true, session_db: ~/.hermes/sessions.db, fts5_enabled: true, curation_interval_minutes: 30, max_recall_items: 10 }, user_modeling: { enabled: true, backend: honcho, profile_path: ~/.hermes/profiles/default/user_profile.json, synthesis_model: claude-sonnet-4-20250514 } }这里default_model用于主对话auxiliary_model用于摘要和策展这类轻量任务分开配能省不少 token。api_key_env指向环境变量名不写明文。再看config.toml管记忆层的存储和召回策略[memory.session] db_path ~/.hermes/sessions.db retention_days 90 max_messages_per_session 500 [memory.search] engine fts5 enable_llm_summary true summary_max_tokens 500 recall_limit 10 [memory.curation] enabled true nudge_interval_minutes 30 importance_threshold medium long_term_dir ~/.hermes/memory/long_term short_term_dir ~/.hermes/memory/short_term [user_modeling.honcho] thesis_weight 0.6 antithesis_weight 0.4 min_evidence_count 3 profile_update_batch 5几个参数值得解释。retention_days控制会话保留天数太长会拖慢 FTS5 检索importance_threshold设为 medium 意味着只有中高重要度的信息才进长期记忆避免记忆过载min_evidence_count 3表示至少积累三条观察证据才更新用户画像防止单次对话的噪声污染画像。目录结构建议提前建好mkdir -p ~/.hermes/memory/long_term mkdir -p ~/.hermes/memory/short_term mkdir -p ~/.hermes/profiles/default如果你要多实例隔离用HERMES_HOME切换HERMES_HOME~/.hermes/profiles/work hermes每个 profile 有独立的 sessions.db、memory 目录和 user_profile.json互不干扰。4. 验证请求跑通一次记忆写入与召回配置写完不算数得验证记忆真的写进去、也能召回来。这一步我拆成三个动作写入、触发策展、召回。第一步启动一个会话并写入一条明确信息HERMES_HOME~/.hermes/profiles/default hermes chat在对话里输入记住我的项目用 FastAPI SQLite部署偏好 Docker Compose不喜欢过度工程化。Agent 会正常回复。此时这条消息已经进了 SessionDB但还没进长期记忆。你可以直接查库确认sqlite3 ~/.hermes/sessions.db \ SELECT role, substr(content,1,40) FROM messages ORDER BY timestamp DESC LIMIT 3;应该能看到你刚输入的那条。第二步触发策展。策展是定时 nudge 的不想等就手动触发hermes memory curate --profile default这个命令会让 Agent 回顾近期未处理消息评估价值后写入长期记忆。执行完检查文件ls ~/.hermes/memory/long_term/ cat ~/.hermes/memory/long_term/project_setup.md如果配置正确你会看到类似这样的内容# 项目配置偏好 - 技术栈FastAPI SQLite - 部署Docker Compose - 风格务实避免过度工程化 - 重要度high第三步召回验证。开一个全新会话问一个不直接提关键词的问题HERMES_HOME~/.hermes/profiles/default hermes chat输入帮我写个简单的服务启动脚本。如果记忆链路通了Agent 的回答应该体现 FastAPI 和 Docker Compose 的偏好而不是泛泛而谈。你也可以直接看召回日志hermes memory recall --query 部署方案 --profile default输出会显示 FTS5 命中的历史消息和 LLM 摘要。到这一步写入—策展—召回闭环就跑通了。用户建模的验证稍微不同。连续几轮对话后检查画像文件cat ~/.hermes/profiles/default/user_profile.json你会看到画像从最初的{role: 开发者}逐步深化加入 framework、style 等字段。这就是 Honcho 辩证建模在起作用当前画像作为 thesis新观察作为 antithesis合成后更新。5. 本篇常见错排查配置跑不通时八成是下面几个坑。Key 没生效报 401。先确认环境变量在当前 shell 可见echo $TAOTOKEN_API_KEY如果为空说明 export 没在当前会话执行或者写进了别的 shell 配置。另外检查settings.json里api_key_env拼写是否和变量名一致大小写敏感。FTS5 检索报 no such module。说明你的 SQLite 编译时没带 FTS5。检查sqlite3 :memory: CREATE VIRTUAL TABLE t USING fts5(x);报错的话需要换一个带 FTS5 的 SQLite或者用 Python 内置的 sqlite3通常自带。HermesAgent 默认走 Python 内置如果你手动指定了系统 sqlite3 路径可能踩这个坑。策展不写入长期记忆。先看importance_threshold如果设成 high很多信息会被过滤掉。再看min_evidence_count用户建模需要积累足够证据才更新。临时调试可以把阈值降到 low确认链路通了再调回去。召回结果不相关。FTS5 是关键词匹配查询词和存储内容用词差异大时命中率低。这时候enable_llm_summary就重要了它会对命中结果做语义摘要再注入。如果摘要质量差检查auxiliary_model是否配了太弱的模型。多 profile 串数据。确认每次启动都带了正确的HERMES_HOME。如果忘了带会落到默认~/.hermes导致 work 和 personal 的记忆混在一起。建议在 shell alias 里固定alias hermes-workHERMES_HOME~/.hermes/profiles/work hermes画像更新太频繁或太慢。调profile_update_batch值小更新快但噪声多值大更稳但滞后。thesis_weight和antithesis_weight控制新旧信息的融合比例想让画像更稳定就提高 thesis 权重。6. 把记忆闭环接进你的 Agent 工作流跑通之后下一步是让它真正服务你的日常。几个实用建议。记忆写入要克制。不是所有对话都值得进长期记忆importance_threshold保持 medium 或 high否则长期记忆目录会迅速膨胀召回时噪声盖过信号。我一般只让 Agent 记住技术栈、部署偏好、编码风格这类跨会话稳定的信息。用户建模要可审计。定期看一眼user_profile.json确认 Agent 对你的理解没跑偏。如果发现画像里出现了错误推断直接编辑文件修正或者用遗忘接口清掉某条证据。HermesAgent 支持让用户查看和修改记忆这个能力别浪费。召回策略按场景调。写代码时召回技术偏好写文档时召回表达风格不同任务注入的记忆应该不同。max_recall_items别设太大10 条左右足够太多会挤占上下文窗口。如果你要验证不同模型在记忆链路里的表现可以用模型对话页面快速对比摘要和建模质量模型对话https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentchat长期跑 Agent 任务的话记忆写入频率高Coding Plan 更划算Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentcoding-plan配置字段有疑问就查接入文档接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentdoc最后提醒一句记忆系统的价值不在架构多漂亮而在你能不能观测到它。每次改完配置都跑一遍写入—策展—召回确认闭环没断。我踩过的坑是改了retention_days之后忘了重建 FTS5 索引结果召回一直返回空排查了半天才发现是索引没更新。重建索引的命令是sqlite3 ~/.hermes/sessions.db INSERT INTO messages_fts(messages_fts) VALUES(rebuild);跑完这条召回立刻恢复正常。记住这个命令能省你不少时间。