Hindsight 如何修正或删除 Agent 错误记忆？2026 验收指南

本周先在隔离测试库中定位错误事实属于单条记忆、派生观察还是源文档，再选择修订、失效、清除观察或删除文档；不要把软失效当成彻底删除。若你的验收要求是数据彻底清除，先核对当前部署版本的 API 删除语义，再用测试验证。

这篇指南适合负责上线验收的技术负责人，以及维护 Hindsight Agent 记忆的后端开发者和产品工程师。
如果你只想了解部署或 Token 成本，可以先看其他部署资料；这里聚焦错误记忆治理与变更验收。

先分清源文档、事实单元与派生观察

Hindsight 中的 memory unit（记忆单元） 是从内容中提取出的事实；observation（观察结果） 则是由多个事实整理出的知识。源文档保存输入内容，并能关联到提取出的记忆。三者有关联，但不是同一个可删除对象。官方记忆管理文档列出记忆单元的查询、读取、历史查看与修订接口；官方文档管理说明则说明文档用于追踪记忆来源。

先从 Agent 实际召回的结果取回记忆 ID、类型、来源文档 ID 和文本。无法从召回记录追溯到来源时，不要直接对整个记忆库执行清理。记忆列表接口支持按文档和事实类型筛选；列表接口说明还列出状态、文本搜索等查询条件。这样可以把单条错误事实与同一文档产生的其他有效事实分开。

⚠️ 需要留意：官方 API 文档和部署版本可能不同。本文描述的是官方开发文档与 API 参考中列出的行为；自托管实例或较早版本，应先核对对应版本的接口与响应。

至少有三种容易误判的情况：

• 改了记忆，但没改源文档： 记忆之后可能因源文档重处理而再次生成。
• 清除了观察，却留下错误事实： 后台重新整合时，错误事实可能再次影响观察结果。
• 界面显示请求成功： 后台图谱或观察整合任务仍可能处于排队、处理中或失败状态。

错误事实仍会召回时，修订与失效怎么选

如果事实只是提取错了，但你知道正确内容，优先修订单条记忆。官方记忆管理接口允许修正事实文本等字段，并说明相关观察和链接会在后台重新计算；PATCH 返回并不代表所有派生处理已经完成。若事实不再成立且没有一个新事实可以替代，则可将记忆标记为 invalidated（失效）。失效会使其退出召回和整合，但仍可恢复并用于审计。

区分“错误”与“过时”很重要。“用户任职于 A 部门”实际应为 B 部门，通常适合修订；“旧服务器已经下线”且不应再被当作现状，则适合失效。如果你只是记录到一个新事实，先评估是否应保留历史事实，再验证整合后的结果；不要为追求召回干净而无差别删除历史。

修订或失效都不能自动证明所有副本都已从系统中清除。失效尤其不应表述为永久删除：官方文档说明它可恢复，并保留用于审计。若业务要求彻底删除，要把需求范围明确到源文档、关联记忆及相关派生数据，并针对当前版本逐项核验。

派生观察过时时，单独清除并等待重整合

如果原始事实正确，只有归纳出的观察不准确，才考虑清除对应观察。DELETE /v1/default/banks/{bank_id}/memories/{memory_id}/observations 用于清除某条记忆派生出的观察；官方接口明确说明，记忆本身不会被删除，并会触发后续整合。响应中包含 deleted_count，可用于记录本次接口报告清除的数量。清除观察接口说明

清除并不等于“以后永远没有这条观察”。该接口会为重新整合重置相关状态；如果事实仍然有效，后台可能据此生成新的观察。验收时要同时查原始记忆与观察结果，并确认后台操作结束，不能只看 deleted_count 或请求返回成功。

你可以通过官方 Recall 接口说明复核调用行为：召回可按 world、experience、observation 三类事实限定结果；未指定时，接口会搜索全部类型。验收目标应与产品真实查询路径一致，而不是只查单一类型后就宣布错误记忆已消失。

源文档仍有旧内容时，先修源头再处理记忆

记忆修订或失效并不会修改它来自的源文档。若源文档继续保留错误内容，后续重处理可能再次提取出同一事实，覆盖你刚做的修订或失效。官方文档明确提醒，重新处理文档会基于原始文本重新提取；因此先纠正源头，再决定重处理或删除，最后检查观察和记忆列表。

要删除源文档时，当前官方接口说明描述的范围包括该文档及其关联的记忆单元和链接，并标注操作不可撤销。你可以从删除文档接口确认端点与级联范围，再通过文档查询、按来源筛选的记忆列表和实际召回结果进行复核。该接口说明不能被扩大解释为已证明备份、日志或其他外部副本也已清除；不要对数据留存作未经核实的承诺。

按可复现步骤验收，不凭界面提示下结论

把测试放在隔离库，使用不含真实敏感信息的测试事实。变更前记录记忆 ID、源文档 ID、观察 ID，以及 Agent 运行时使用的查询。这样失败时，你能判断是数据仍存在、查询路径不同，还是后台处理还没结束。

建议按以下顺序操作：

1. 复现问题： 用 Agent 实际会发出的查询执行召回，保存响应中的事实文本、类型、记忆 ID 和来源信息。
2. 确认对象： 按 ID 读取记忆单元，并检查它指向的源文档；若结果是观察，查看它关联的来源事实或历史。
3. 选定变更： 单条事实内容错误则修订；事实已失效则软失效；原始事实无误但观察过时则清除观察；源头也需消除时再评估文档删除。
4. 修正输入： 如果源文档仍包含旧说法，先更新或删除源文档，再决定是否重新处理。否则旧事实有机会被重新提取。
5. 追踪后台操作： 记录请求 ID、API 响应与操作状态。官方操作说明把异步任务状态区分为 pending、processing、completed、failed 四种；出现失败时查错误信息，不要把排队当作完成。异步操作说明
6. 重复召回测试： 重跑原查询，并测试语义相近的问法；确认错误事实不再进入实际 Agent 使用的召回结果，修正后的事实能按预期出现。
7. 核对残留与回归： 检查源文档、记忆列表和观察结果；再执行相关业务查询，确认清理没有误伤其他有效事实。

对于调试记录，可参考官方 API 参考页核对当前实例暴露的端点，并把接口文档版本、服务版本、变更前后响应和异步操作最终状态一并归档。API 路径存在，不代表你的实例版本一定支持完全相同的字段或行为；必要时以隔离环境的实测为准。

用两张对照表确定处理动作与验收证据

官方 API Reference 可作为核对当前端点的入口。对于自托管环境，还应记录本机服务版本和配置；接口行为不一致时，先在隔离环境复现，再把结论写入上线验收记录，而不是用云端页面替代本地验证。

常见问题

• 如何判断 Agent 仍在召回错误记忆？
  使用 Agent 实际请求的查询执行召回，并保存返回的记忆 ID。若结果来自观察，继续追查其来源事实；若来源事实仍有效但观察过时，才处理观察。随后用原查询与语义相近的问法复测，避免只验证一个精确字符串。

• 失效记忆后还会不会保留数据？
  官方文档描述失效记录仍可审计、可恢复，因此它不是永久删除。若需求是彻底删除，先确认目标部署版本支持的删除接口、删除范围和数据留存规则，再做隔离环境测试。不要仅凭失效状态向用户承诺数据已彻底清除。

• 清除观察后，原始记忆会不会一起消失？
  不会。清除观察会重置相关整合状态并触发重新整合，原始记忆仍在；只要来源事实继续有效，新观察仍可能被生成。若错误存在于事实本身，应修订或失效事实单元，并再验证观察。

• 删除源文档后怎样确认处理完成？
  保存文档 ID 和相关记忆 ID，执行删除后分别检查文档列表、按来源筛选的记忆列表、观察及 Agent 召回结果，同时等待后台操作达到完成状态。若关注备份、日志或外部副本，需另查相应系统规则；单个接口响应不能证明那些范围已清除。

记忆治理适合在有版本记录、可隔离测试的环境里执行。若你的验证工作还需要 macOS 专属客户端或构建工具，自购设备适合长期、稳定使用；若只是短期测试，购置设备会占用预算和维护精力，也可以评估租用 Hashvps 的 Mac 环境。若工作负载与 macOS 无关、需要持续高负载或依赖本地物理接口，优先选匹配的长期方案，不必为了 Hindsight 本身迁移到 Mac。准备临时测试环境前，可先查看 Hashvps 帮助中心及服务条款中的数据与使用说明，确认环境、数据责任和使用方式符合你的验收要求。