Hermes-Agent：上下文与记忆管理策略
目录
- 这一篇解决什么问题
- 先对齐：Hermes 的「记忆」与官方文档结构
- 短期上下文：对话、工具输出与窗口压力
- 压缩与用量：/compress、/usage、/insights 的工程用法
- 长期记忆：持久化、检索与摘要
- Skills：与记忆闭环如何配合
- Context Files：项目级上下文如何进入每一轮
- Cron：定时任务如何改变「记忆节奏」
- 隐私、留存与合规：你必须做的三件事
- 与多 Agent 并行时的记忆边界
- 日常运维节奏（建议）
- 原文与延伸阅读
这一篇解决什么问题
Hermes 的官方 README 在特性列表里强调 closed learning loop：包含 agent-curated memory、周期性 nudges、复杂任务后的技能生成、技能在使用过程中自改进、FTS5 会话搜索、跨会话摘要、以及 Honcho dialectic user modeling 等（见 README A closed learning loop 段落）。这些能力如果“全开且不加治理”，最常见的后果是：
- 上下文被撑爆：工具输出过长、检索结果过多、摘要不到位，导致模型抓不住重点。
- 记忆被污染：把临时敏感信息写进长期记忆，或把错误结论固化成技能。
- 合规不可解释：用户问「你凭什么记得这个」，团队答不出来。
本篇把 Hermes 的上下文与记忆拆成可操作策略：短期怎么压缩、长期怎么沉淀、哪些东西必须人工治理。权威内容以官方文档为准：Memory、Skills、Context files。
先对齐：Hermes 的「记忆」与官方文档结构
在 Hermes 里，「记忆」往往不是单一数据库字段能概括的，而是多模块组合：
| 模块 | 你应把它当作什么 | 原文 |
|---|---|---|
| Memory | 持久化记忆与最佳实践 | Memory |
| Skills | 可复用流程与 agentskills.io 标准 | Skills |
| Context files | 项目级上下文注入 | Context files |
| Session search / FTS | 会话检索与跨会话召回 | README 特性描述 + Memory 文档 |
短期上下文：对话、工具输出与窗口压力
短期上下文包括：用户消息、历史轮次、工具输出、系统提示。它的核心矛盾是：工具输出是“信息”，也是“噪音”。
建议你为团队约定三条硬规则：
- 工具输出默认要裁剪：只把“结论字段 + 必要证据链接/片段”回注，不要把整页 HTML/JSON 原样塞进对话。
- 长任务拆阶段：每一阶段输出一个结构化中间结果（表格/JSON），下一阶段只引用中间结果。
- 失败输出要短：错误信息应包含“可行动字段”（错误码、路径、建议动作），避免模型在长错误栈上浪费推理。
压缩与用量：/compress、/usage、/insights 的工程用法
README 的 CLI vs Messaging Quick Reference 给出跨界面命令对照，其中包括 /compress、/usage、/insights [--days N] 等（以你版本为准）。建议把它们理解成三层运营动作：
/usage：观测与归因
- 用途：看 token 压力来自哪里（模型、工具、还是历史）。
- 落地：把“异常用量”定义成告警阈值（例如单日 token 翻倍），先定位是否工具输出失控。
/compress：换空间换风险
- 用途：用摘要换上下文窗口。
- 风险：摘要可能丢失关键约束（尤其是法律/合规/数值阈值）。
- 补偿：把关键约束放到 Context files 或 Skills 的“硬规则”里，而不是只依赖对话摘要。
/insights：周期性回顾
- 用途：按天/周查看使用模式，用于调整工具集与技能策略。
长期记忆：持久化、检索与摘要
README 提到 FTS5 会话搜索与 LLM summarization 用于跨会话 recall（见 A closed learning loop）。工程上这意味着：
- 检索不是替代思考：检索到的历史片段可能过时、可能含错误结论；需要“引用 + 校验”机制。
- 摘要不是替代记录：摘要适合导航，不适合作为唯一事实来源。
建议你为业务定义「事实源层级」：
- 权威事实源（数据库/工单系统/文档仓库）
- 会话检索结果（作为线索）
- 模型生成（作为草稿，需要校验）
Skills：与记忆闭环如何配合
Skills 是 Hermes 里把流程固化下来的关键模块（见 Skills）。与记忆闭环结合时，建议：
- 技能生成要审核：自动生成的技能默认进入“待审核”状态（流程上），避免错误流程被固化。
- 技能版本化：至少记录变更原因与适用范围；否则会出现“技能互相打架”。
Context Files：项目级上下文如何进入每一轮
Context files 让「项目上下文」在对话中稳定存在（见 Context files）。它的价值是降低每轮对话的重复说明；风险是：
- 文件过大：同样会占用上下文；需要分层与拆分。
- 更新不及时：项目已变更但 context 未更新，会造成稳定错误。
建议把 context 文件当作“可维护的代码”：有 owner、有 review、有变更记录。
Cron：定时任务如何改变「记忆节奏」
Cron 让助手在无人值守时运行（见 Cron）。它会改变记忆系统的节奏：
- 更频繁的摘要与报告：可能把更多噪声写入记忆，需要过滤模板与阈值。
- 更严格的权限：定时任务往往比交互更危险（无人确认）。
隐私、留存与合规：你必须做的三件事
- 明确留存周期：哪些记忆 7 天、哪些 90 天、哪些必须不落库。
- 最小披露：能检索不代表应该展示；对敏感字段做脱敏与访问控制。
- 可解释：用户询问时，能说明“来自哪条会话记录、何时生成摘要”。
与多 Agent 并行时的记忆边界
当你使用多子代理（见本站 多 Agent 方案），记忆边界必须明确：
- 子代理默认不应共享完整长期记忆，除非业务需要。
- 若共享，必须定义“共享字段”与“脱敏规则”。
日常运维节奏（建议）
- 每周：检查一次
/usage异常与工具输出长度；抽查 skills 与 context 文件是否过期。 - 每月：做一次 memory/skill 清理：合并重复、删除错误结论、补齐失败案例。
- 每次升级 Hermes：跑
hermes doctor，阅读 Updating 相关说明与 release notes（如果有）。
周维护：建议拆成“观测—清理—校验”三步
- 观测：看
/usage是否异常；工具输出是否突然变长；是否出现重复检索。 - 清理：删除明显过期的临时记忆片段（策略需符合你的留存规则）；合并重复 skills。
- 校验：随机抽一条“记忆驱动的回答”，追问证据来源是否仍有效（避免陈旧摘要当事实）。
数据分级（建议团队强制执行）
| 级别 | 示例 | 进入长期记忆的规则 |
|---|---|---|
| L0 公开 | 已发布文档链接 | 可进入摘要与技能 |
| L1 内部 | 项目排期、非敏感流程 | 可进入，但需脱敏字段 |
| L2 敏感 | 客户身份信息、密钥 | 默认不允许写入；必须加密/外部密钥系统 |
| L3 高敏 | 金融/医疗等 | 按合规处理；通常不应进入通用记忆 |
Cron 与记忆：无人值守的“写入风险”
定时任务更容易把噪声写入记忆（因为缺少人类当场纠正）。建议：
- Cron 输出先走“摘要模板”，再决定是否写入长期记忆。
- 对 Cron 触发的工具启用更严格的失败阈值与告警。
与多 Agent 并行时的记忆边界（再强调）
并行子代理若共享同一记忆存储，隔离会失效。建议默认策略：子代理只写结构化中间结果，由主会话决定是否沉淀到长期记忆。详见本站 多 Agent 方案。