SOTA Sync
返回 FEED
AGENT2026-05-26

Hermes Agent 的 Hindsight：让 AI 记住你的代码库

Hermes Agent 的 Hindsight：让 AI 记住你的代码库

每一次 AI 编码会话都从零开始。

你打开新聊天，粘贴上下文、你的技术栈、你的规范、上周做的架构决策、三月花了两天 debug 的 bug。然后下次再做一遍。再下次。问题不是 AI 编码工具不擅长编码，而是它们对你的代码库没有记忆。

Hermes Agent with Hindsight 是例外。每次会话增加它对项目的了解。到第 20 次会话，Hermes 已经知道你的模块边界、命名规范、已知脆弱区域，以及那个反复出现的认证问题的根因。你停止解释，它开始知道。

Hindsight 提取什么

Hermes 不存储 transcript。Hindsight 提取和保留的是事实——从你的对话中拉取的原子化、可检索的知识片段。

一次典型的编码会话后，这些事实自动进入记忆：

  • "项目使用 ESM 模块，不是 CommonJS，导入时始终使用 .js 扩展名"
  • "认证中间件在过期 refresh token 上静默失败，已知问题，截至 3 月 14 日"
  • "SQLAlchemy 在二月性能测试后被移除，改用 raw asyncpg"
  • "团队规范：所有 async handler 包裹在 handle_errors() 装饰器中"

这些都不需要你明确告诉 Hermes 记住。Hindsight 的写入管道从你的会话自然流程中提取——从你的问题、你描述的 bug、你沿途解释的决定。

什么不会变成记忆：原始文件内容、逐行代码、冗长的终端输出。提取步骤本身就是过滤器。对话填充、重复的上下文设置、程序噪音，none 能存活。剩下的是一个不断增长的事实索引，Hermes 带入每一次未来会话。

生命周期：每次 turn 的两端

每次 turn 之前：Hindsight 预取历史中最相关的记忆，注入 system prompt。Hermes 在看到你的消息之前先看到这些上下文。

每次响应之后：你的对话被异步保留。Hindsight 在后台提取事实。你这 turn 讨论的内容从下一 turn 开始可搜索。

两分钟设置

Hermes v0.14.0 原生集成 Hindsight。设置是单个向导命令：

hermes memory setup  # 选择 "hindsight"

确认记忆已激活：

hermes memory status

配置位于 ~/.hermes/hindsight/config.json。默认值适用于大多数工作流。

memory_mode 控制记忆如何在 Hermes 中呈现：

  • hybrid（默认）：记忆在每次 turn 前自动注入，加上 hindsight_recall、hindsight_retain、hindsight_reflect 工具对模型可用
  • context：仅自动召回，没有显式操作，无需思考
  • tools：模型必须显式调用 hindsight_recall；不自动注入任何内容

编码工作 hybrid 是正确的默认设置。你获得每次 turn 的自动召回，加上要求 Hermes 显式 surface 它对特定组件了解的能力。

部署方面：跨机器工作或团队共享记忆用 cloud。想要完全本地、无外部依赖用 local 模式——在后台运行嵌入式 PostgreSQL daemon。首次启动约一分钟初始化数据库；后续启动很快。

三个高杠杆工作流

1. 在现有工作上开始新会话

没有记忆时，恢复现有项目意味着在实际工作之前先设置上下文：粘贴 README、解释技术栈、重新建立上次在做什么、提醒 Hermes 它应该已经知道的规范。复杂项目上，这个开销吃掉每次会话的 10-15 分钟。

有记忆时，Hermes 用之前会话积累的事实开始每次会话。它知道技术栈。它知道规范。它知道上周在 debug 什么。

会话的第一条消息变成实际工作。

注入内容由 budget 设置控制。mid（默认）时，Hindsight 获取 10-15 条最相关的记忆，足以覆盖项目核心事实而不淹没上下文窗口。high 时检索更深入：更多上下文、更多 token。大多数编码工作流 mid 是正确平衡。跳回跨多个模块的复杂调查时，high 值得额外成本。

2. Debug 反复出现的问题

代码库记忆的最高杠杆价值是跨会话的模式识别。有些 bug 不是一次性的，是更深架构问题的症状，以不同形式在数月内反复出现。

没有记忆时，你独立 debug 每个实例。你可能追踪同样的根因三次而没有连接点。

有记忆时，Hermes 召回之前的实例。描述一个新的失败模式，它 surface 相关上下文：两个月前识别的根因、撑到下次重构的 workaround、在这些失败中反复出现的组件。

值得 payoff 的事实类型：

  • "速率限制器对 X-Internal: true header 的请求绕过认证检查，两次权限提升未遂的来源"
  • "异步任务队列在 Redis 连接重置时静默丢弃 job，需要显式 ACK 处理，不是 fire-and-forget"
  • "GraphQL resolver N+1 模式在每次新 schema 添加后重现，需要在 code review 中标记 DataLoader 强制执行"

这些不是你会在 debug 会话开始时粘贴的事实。它们是区分盲目 debug 和全上下文 debug 的机构知识。

prefetch_method: reflect 值得为此工作流启用。不是通过语义搜索检索单个事实，reflect 要求 LLM 在所有相关记忆上合成一个连贯摘要再注入。它更慢，但对"帮我理解这类 bug"查询，合成的上下文比单个事实列表更有用。

3. 接入他人的代码

如果你加入一个同事一直在用 Hermes 和 Hindsight 的项目，使用共享 bank，记忆 bank 已经有他们会话的上下文。

查询 Hermes 对特定模块的了解：

  • "你对支付模块了解什么？"
  • "认证服务出现过什么 quirks 或已知问题？"
  • "我们为什么从 SQLAlchemy 迁移走？"

Hermes surface 之前会话积累的事实：架构上下文、已知边界情况、过去的决定及背后的理由——不需要任何人把它们写进 README、wiki page 或找不到的 Slack thread。

这不是文档。它是从未进入文档的机构知识。

团队共享记忆

默认 bank_id 是 hermes。同一项目的每个开发者可以通过设置相同的 bank_id 共享记忆 bank：

{
  "bank_id": "payments-service",
  "mode": "cloud"
}

多个开发者用共享 bank 时，记忆从所有会话中复利。一个开发者积累的知识——一个棘手模块的未记录行为、一个来之不易的 debug 洞察、一个部署坑——自动对团队其他人可用。

什么复利得好：代码库事实、架构决策、已知问题、规范。这些描述代码库，不是人，安全共享。

什么保持分离：个人工作流偏好、无关个人上下文。那些用单独的 bank。

Bank 命名：一个项目一个 bank，不是一个开发者一个。三个人用不协调的 hermes 共享 bank 会变成噪音；支付团队都用 payments-service 共享 bank 会变成机构记忆。

自主编码 Agent 的基石

丰富的、当前的 mental models——规范、架构、已知脆弱区域——给 agent 足够的结构化上下文来做决定和推动变更，不需要人类在每个任务开始时 briefing。持久会话记忆是达到那个基线的方式。

Hermes with Hindsight 是唯一上下文跨会话累积的编码工作流。其他工具重置。这个不。

价值随使用复利。会话一，Hermes 对你的项目一无所知。会话五，它知道技术栈和规范。会话 30，它知道项目的历史、脆弱区域、塑造当前形态的决定。那时你已经停止解释那些东西，不是因为你跳过了上下文，而是因为你永远不需要再次提供它。一旦 mental model 足够丰富，你不只是在和一个编码助手对话。你在和一个了解代码库如同你一样的 agent 并肩工作。

继续阅读