Skip to main content

第6章：记忆、学习与技能 —— “自我改进”如何落到可持久化闭环

一、三种“记住”不能混为一谈​

Hermes 的长期行为至少有三个层次：

层次记住什么主要实现
会话记忆这次对话发生了什么gateway/session.py、session DB
外部记忆用户偏好、事实、跨会话线索agent/memory_manager.py、MemoryProvider
程序性记忆以后如何完成某类工作skills/、skill_bundles.py、curator/learning

会话历史是事实轨迹；MemoryProvider 是检索和写入边界；Skill 是可以被加载和执行的程序性知识。把三者混成一个 MEMORY.md 会导致上下文污染、权限不清和无法控制的自动写入。

二、MemoryProvider：外部记忆的最小契约​

agent/memory_provider.py:43 定义抽象 provider。MemoryManager 不假设底层一定是本地文件、Honcho、Supermemory、Mem0 或 Hindsight，而是通过 provider 统一调用：

  • 初始化/关闭；
  • prefetch 查询；
  • session boundary 同步；
  • 记忆写入与 metadata；
  • tool schema 和 tool call；
  • session switch、pre-compress、delegation 回调。

这使得本地记忆和云端记忆可以在同一个 Agent 生命周期中并存，但 provider 仍能各自决定检索、版本和失败方式。

三、MemoryManager 的同步与异步边界​

agent/memory_manager.py:364 的 MemoryManager 扮演 orchestrator：

turn start → queue_prefetch_all(query)
          → prefetch_all() 合并可见上下文
          → API call sidecar 注入
tool memory write → notify_memory_tool_write()
turn end/session switch → sync_all()/commit_session_boundary_async()
shutdown → flush_pending()/shutdown_all()

它使用 executor 做外部 provider 的并发预取和后台写入；StreamingContextScrubber 在流式文本中去掉不该展示的 memory block。这里的安全边界很细：记忆写入可以异步，但 session 边界必须提供 flush/commit 语义，否则进程退出时“模型说过要记住”不等于真正写入。

四、记忆工具为什么由 Manager 注入​

inject_memory_provider_tools 会依据 provider 和配置把记忆工具加进工具系统。这样模型只能看见当前启用 provider 的 schema；禁用的 provider 不会以“可调用但永远失败”的工具污染 prompt。

MemoryManager.handle_tool_call 再把模型请求路由到对应 provider。此处有两层权限：工具 registry 决定工具是否被暴露，provider 自己决定该次操作是否允许。

五、Skills：把经验变成可按需加载的程序​

agent/prompt_builder.py:1584 的 build_skills_system_prompt 不会把所有 skill 正文全部塞进每次上下文，而是建立 manifest/目录快照；模型看到名称、描述和可用条件，真正需要时再读取 skill。

agent/skill_bundles.py、skill_commands.py、skill_preprocessing.py 和 tools/skill_manager_tool.py 组成 skill 生命周期：发现、筛选、读取、使用、更新、来源追踪和安全审计。

技能因此处在“工具”和“文档”之间：

  • 它比普通文档更可执行，可能包含脚本；
  • 它比内置代码更可变，可以由用户或 Agent 扩展；
  • 它需要来源、命名空间、写入授权和内容截断，否则就是 prompt injection 的持久化版本。

六、Learning Graph：经验不只是一段摘要​

agent/learning_graph.py、learning_mutations.py 和 learning_graph_render.py 把学习表示成图或结构化事实。图结构的价值是把：

任务 → 观察 → 决策 → 结果 → 技能/记忆变更

从自然语言中分离出来，便于渲染、审计和后续变更。curator.py 和 background_review.py 还可以在后台对 session 或技能进行整理，但它们必须使用独立的 session/身份边界，不能悄悄改变当前前台任务的消息历史。

七、一个“闭环学习”示例​

假设用户让 Agent 处理一类复杂报表：

  1. turn start：MemoryProvider 召回用户偏好的报表格式；
  2. system prompt：skills manifest 告诉模型已有 reporting skill；
  3. Agent 使用工具完成任务；
  4. 工具结果和用户反馈进入 session transcript；
  5. turn end：MemoryManager 在边界提交相关事实；
  6. curator 判断是否形成可复用步骤；
  7. 新 skill 或 skill 改进经过写入来源/安全检查；
  8. 下一次任务只加载 manifest，按需读取改进后的 skill。

八、为什么要有 provenance​

技能或记忆可以影响未来的模型行为，因此 Hermes 使用 tools/skill_provenance.py、写入 origin 和相关测试记录来源。设计目标是回答：

  • 谁写的：用户、Agent、插件、curator 还是导入器？
  • 什么时候写的：当前 turn、session boundary 还是后台任务？
  • 写入依据是什么：用户明确请求、模型建议还是自动总结？
  • 未来使用时，能否回滚或移除？

这使“自我改进”从魔法叙事变成带账本的变更系统。

九、三条工程结论​

  1. 召回不等于注入：memory 先检索，再通过 sidecar 和 scrubber 进入可见上下文。
  2. 技能是持久化的能力扩展：需要像代码一样重视来源、审核、命名空间和执行边界。
  3. 后台学习必须尊重生命周期：它可以异步，但不能绕过 session boundary、credential boundary 和 write provenance。