OpenWiki 自我纠正记忆系统解析

OpenWiki 如何构建"自我纠正"的记忆系统？ 记忆系统的关键能力不是"记住"，是"知道何时不该再相信"。OpenWiki 通过把 wiki 内容拆解为"主张 + 版本化证据"的结构，让文档系统...

OpenWiki 如何构建"自我纠正"的记忆系统？ 记忆系统的关键能力不是"记住"，是"知道何时不该再相信"。OpenWiki 通过把 wiki 内容拆解为"主张 + 版本化证据"的结构，让文档系统能够自动发现哪些知识因代码演进而变得可疑，并在后续更新中验证或纠正它们，形成自我纠正的闭环。 OpenWiki repo - @LangChain github.com/langchain-ai/o… # 要解决的问题：长期记忆的"遗忘难题" 当前关于 Agent 记忆的讨论大多聚焦在两个环节：如何创建记忆、如何检索记忆。但长期记忆还有一个被普遍忽视的问题： · 当事实的来源发生变化时，原本正确的记忆会悄悄过时，而系统没有任何可靠机制察觉这一点。 · 长期积累会导致两种退化：记忆漂移和记忆污染。 这个问题在 OpenWiki 上尤为尖锐，因为它的知识来源是持续演进的代码。 # 核心机制：三层设计 1. 绑定主张与证据（Grounding） 让 wiki 的每一条实质性事实主张都有据可查： · Agent 在写 wiki 页面时，必须同时识别出页面中的事实主张，并标注代码中支持该主张的证据。 · 例如 wiki 写"失败任务默认重试三次"，系统会把这条主张和支持它的代码一并记录。 · 运行时还会为证据记录版本号，使这条主张日后可以被重新验证。 由此，wiki 不再是一堆文本，是一个"主张—证据"的依赖图：每条知识都能追溯到它赖以成立的代码。 2. 过期检测（Staleness Detection） · 机制非常朴素：比较"当初支持该主张的证据版本"与"当前证据版本"，不一致即标记为 stale（过时）。 · 关键设计：stale ≠ 错误。它只意味着"这条主张不能再被安全地假设为真，需要重新核对"。很多代码变更并不会真正推翻相关主张，但足以构成"重新审视"的理由。 · 另一个精巧之处：不需要单独持久化状态标记。staleness 是从"存储的证据版本 vs 当前版本"实时推导出来的，因此"不确定性"天然是持久的——在证据被重新核对之前，怀疑不会丢失。 3. 纠正闭环（Correction） · 主张被标记 stale 后，系统会检查当前证据：若主张仍然成立，仅刷新证据版本；若已不成立，则 wiki 文本与证据一起更新。 · 最重要的行为约束：stale 状态一直保持，直到验证真正发生。未被处理的 stale 主张会被保留到下次更新，而不是被静默丢弃。 · 这与"从头重新生成 wiki"有本质区别：系统保留已有知识，只跟踪并纠正受影响的部分。 # 实际运行方式与成本模型 · 过期检测在每次 wiki 更新开始时运行，先于 Agent 做任何事。运行时遍历全部主张，逐条比对证据版本——这是确定性检查，不调用模型，因此即使有数千条主张也很快。 · Agent 从不主动"清扫"主张集合。它在正常更新中读到某个页面时，该页的 stale 主张会随内容一起呈现，Agent 顺手完成"重新验证并刷新证据"或"纠正主张与文本"。 · 由此得到一个优雅的成本特性：更新成本随代码变更量伸缩，而不是随主张总量伸缩。 # 评估方法与结果 为了量化"遗忘能力"，作者设计了一个可复现的评估： 方法：将一个代码仓库按一系列 git 提交重放，在预设检查点触发 wiki 更新。提交包含新功能、行为变更、bug 修复和回滚（revert）。 分类标准（每次更新后对 wiki 中的事实主张逐条判定）： · Supported：当前代码支持该主张； · Stale：曾经正确，但代码已变、不再成立； · Hallucinated：在仓库历史上从未为真； · Unverified：无法证实也无法证伪。 结果（同一提交序列，对比有无 claims 运行时）： · Stale 主张从 80 条降至 9 条； · Hallucinated 主张从 15 条降至 0 条； · 单次运行实例：某次代码变更使 17% 的主张变 stale，到下一检查点 stale 归零，supported 从 77% 恢复至 98%。 Colin Francis @colifran_ x.com/i/article/2092… 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 59 ⚡