用可检索记忆替代不断膨胀的提示词

审计草稿漏掉历史发现，就继续往提示词里塞旧报告，直到没人能准确回答：模型上一次到底看过什么？作者把这视为审计流程里的控制缺口，并将历史信息迁入 Hindsight，让检索成为独立、可记录的步骤。

这篇短文值得读的地方，是它划清了提示词、历史记忆和正式记录的职责。不过，作者展示的是一次改造经验，没有给出成本或准确率的对照数据。

把历史塞进提示词，为什么越补越难管

作者最初的补救方式很直接：模型漏掉一条旧发现，就给提示词构建器加一个加载器。

下面这段代码把最近四个季度的报告，以及当前控制项的历史发现，一起拼进提示词：

parts = [RULES, RUBRIC]
parts += [r.full_text for r in load_reports(last_n_quarters=4)]
parts += [f.to_text() for f in load_findings(control_id)]

要看的是 last_n_quarters=4：它按时间范围装入报告全文，没有先判断每份报告与当前任务的关系。

作者发现，这种方式会同时带来三个问题。成本跟着历史总量增长，而不是跟着当前需要的信息增长；旧结论和修正后的结论挤在同一段文本里，缺少明确的先后关系；事后也难以还原某次生成究竟使用了哪些内容。

作者把它形容为在字符串里搭数据库，却没有结构和顺序。这个比喻很贴切：拼接代码负责把文字送进去，却没有解决历史事实如何更新、如何检索、如何追查的问题。

Hindsight 改的是信息进入模型的路径

作者把历史迁入开源 agent 记忆系统 Hindsight。提示词留下规则、评分准则和新证据，过去发生的事实则作为带日期的事件保存，需要时再取回。

这段代码展示了两个独立动作：先留存历史，再围绕当前控制项检索：

client.retain(bank_id="audit-ops", content=text,
              timestamp=occurred_at.isoformat())

memories = client.recall(bank_id="audit-ops",
    query=f"Prior findings and status for control {control_id}")

要看的是 timestamp=occurred_at.isoformat()：顺序来自事件发生时间，不再依赖文字在提示词里的排列位置。

按原文描述，recall 结合语义、关键词、图和时间搜索，既能处理 AC-2 这样的控制项编号，也能处理「上个季度」这样的时间条件。作者还把每次召回的内容与草稿一起记录，让「模型参考了哪些历史」有迹可查。

在备份恢复的例子里，系统能找出 Q2 的历史发现、一次已完成的测试，以及仍缺少的第二次测试。它据此建议按问题复发处理，最终分类仍交给审阅者。

提示词承担当前任务的工作记忆，历史信息通过可检查的检索步骤进入模型。

作者同时保留了边界：记忆系统不能替代正式记录系统，评分准则仍应留在提示词里。

我的判断

我赞同作者把检索显式化。对需要追查依据的生成流程来说，记录召回内容，比只知道「加载过最近几份报告」更有用。把事件时间存成真实时间戳，也比让模型自行猜测哪段文字更新更可靠。

但原文没有证明 Hindsight 优于普通数据库、全文搜索或常见的检索增强生成（RAG）方案。语义、关键词、图和时间搜索是作者描述的能力，检索准确率提高多少、成本下降多少，文章都没给数据。这部分应当按经验之谈看待。

还有两处不能替作者补全：旧事实被纠正后如何处理，原文没说清；记录召回内容能追查历史依据，却不足以保证完整复现一次生成，因为模型版本、提示词和生成参数等是否保存，文中也没交代。

如果历史少、内容稳定，直接放进提示词仍然简单。历史持续增加、修订频繁，又需要审阅依据时，独立检索才更有讨论价值。

能拿来做什么

• 如果你的 AI 编程流程已经不断向提示词追加旧需求、问题记录或报告，可以先区分当前规则、新证据和历史事实，再判断哪些历史需要按任务检索。
• 在 Node 编排的生成流程里，把检索结果与本次产物关联保存，让审阅者能查看模型实际取回了哪些内容。
• 用已知历史检查召回结果，特别验证事件先后、结论修正和未完成事项，不能只看生成文字是否顺畅。
• 对需要人工分类的任务，让模型提供历史依据和建议，并保留正式记录系统与审阅环节。