智能体在组织的政策、手册、wiki、工单和代码之间工作时，必须驾驭分散在各系统和团队中的知识。找到相关段落只是开始。它们还需要确定哪些规则适用、哪些已经改变，以及一个来源如何影响另一个来源。
持久记忆层会保存知识和关系，供智能体跨任务复用。没有它，智能体往往不得不在每个问题上重建这种理解，使其工作成本高昂且容易出错。这在银行和保险行业尤其具有挑战性，因为政策和指南经常相互修订或取代。
我们测试了OpenWiki，这是我们开源的 wiki 编译器，作为这一记忆层。在需要跨来源连接的问题上，该 wiki 使智能体的准确率比仅用搜索高出约 5 倍。添加一个证据图——将 wiki 陈述与支撑段落连接起来，并链接相关来源——使准确率进一步提升 27%，引用一致性翻倍。
为什么要用编译式 wiki？
RAG 流水线通常使用语义或混合搜索来检索孤立的片段，让智能体自己去拼凑这些片段之间的关系。我们探索过用智能体式 RAG和基于图的元数据过滤来改进检索，但找到相关段落只是工作的一部分。跨来源问题需要追踪引用、解决冲突规则并理解依赖关系。记忆保存了这种理解，使智能体不必在每个问题上重建它。
编译式 wiki 通过将源材料综合成相互链接的页面来提供这一记忆层，这些页面解释关键概念及其关系。wiki 会随来源变化而更新，为智能体提供可复用的上下文。
OpenWiki是我们基于Deep Agents构建的开源 CLI，它创建这些 wiki 并附带回溯到来源的引用。我们最初构建它，是为了让编码智能体不必在每个任务上重新发现架构和代码行为。
每条 OpenWiki 陈述都建立在一个claim，一个与支撑来源行及其哈希值相关联的断言。当这些行发生变化时，哈希值随之改变，使 OpenWiki 无需调用模型即可标记受影响的断言，从而节省 token 成本，并使陈旧性检测更加确定。只有这些断言会被送入模型进行确认、修订或撤回，使记忆层能够随着来源变化而自我修正。我们在在 OpenWiki 中构建自我修正的记忆中对此进行了解释。
构建测试文档库
我们构建了一个合成的保险文档库，包含111 份长文档。我们选择保险领域，是因为保单和批单经常相互引用、修订和覆盖；这正是让检索变得困难的那类跨文档依赖关系。
为了给基准测试打分，我们创建了一份包含 972 条事实的台账，并控制了每条事实应出现的位置、文档之间如何相互引用，以及版本之间发生了什么变化。我们用 LLM 生成周围的文本，并运行自动化检查以确保所需事实存在。
最后，我们有意让语料库变得杂乱，混入了过时版本、矛盾内容、间接引用链、多样的措辞以及超长文档，以更好地匹配智能体在真实企业文档库中面对的情况。
我们如何配置实验
我们在两种条件下评估了同一个检索智能体：Search（对原始文档进行关键词搜索）和Wiki（同一个智能体，但可以访问由 OpenWiki 编译、带来源链接的 wiki）。底层模型、指令、文档和问题均保持不变——只有智能体对编译记忆的访问权限发生了变化。
我们测试了80 个简单的查找类问题以及50 个关联类问题，后者需要跨文档追踪依赖关系（例如，识别某个条款依赖于什么，或当它变化时会影响什么）。我们将每个问题问了三次，以衡量多次运行之间的波动。
指标（“更好”意味着什么）：
- 准确率（0–1）：评分器根据 972 条事实台账生成的检查清单，核对答案和引用的证据（对必需事实给予奖励，对矛盾内容进行扣分）。
- 一致性（0–1）：三次运行中被引用证据的重叠度（引用集合的平均成对 Jaccard 相似度）。这衡量的是智能体是否可靠地将其答案建立在相同来源上，而不是答案是否正确。
- 成本 + 延迟：每个问题的模型花费（美元）和实际耗时。
wiki 在哪些地方有帮助，在哪些地方表现不佳
OpenWiki 将 111 篇文档的库编译成一个约为原始大小十分之一的 wiki，花费 $4.15。之后添加 17 篇文档每篇约花费 $0.09。以下分析不包括编译和更新成本，仅报告检索和回答成本。
我们使用简单查找作为对照。这些单段落问题几乎不需要跨文档的保险上下文，因此我们并不期望 wiki 能带来多少帮助。搜索和 wiki 的结果相似（准确率 0.84 对 0.83；引用重叠度 0.72 对 0.74；每个正确答案 $0.020 对 $0.021），而延迟从 9 秒增加到 12 秒。
关联性问题需要利用领域特定关系跨来源进行推理。在这里，wiki 将准确率提升了约 5 倍，从仅用搜索时的 0.10 提升到 0.52。其编译后的上下文帮助智能体应用领域知识，并以更少的工具调用找到相关关系，将每个正确答案的成本从约 $0.55 降至 $0.19。
尽管有这些准确率和成本上的提升，wiki 智能体的证据检索仍然不稳定。引用重叠度从简单查找的 0.74 下降到关联性问题的 0.25。引用稳定性并不衡量正确性，但证据的变化会改变答案，尤其是当来源相互冲突时。对于关键业务职能，团队需要的是可复现、可审计的答案，而不仅仅是更好的平均准确率。
wiki 帮助智能体跨来源应用领域知识。剩下的挑战是让通往支撑证据的路径更加可重复。
添加证据图
为了让检索更加一致，我们添加了一个轻量级的证据图：一张将 wiki 引用转化为声明、wiki 页面、段落和主题之间显式、带类型边的映射。OpenWiki 的引用是 Markdown 文件中的文本引用。该图通过将它们物化为带类型的边，使这些引用变得持久。这为智能体提供了一条稳定的路径可循，而不必用搜索重新发现相同的链接。
我们分两步构建了这个图：
- 将每个段落存储为一个新的原语。一个确定性流程将每份文档拆分为段落，并为每个段落分配唯一标识符。这些段落成为信息的原子单元，将论断链接到确切的支撑段落，而非整份文档。
- 用带类型的边连接这些段落。我们用带类型的边连接了段落、论断和 wiki 页面：论断
cite段落，较新的文档supersede较旧的文档，以及章节refers_to其他文档。每条边都标明关系，而不仅仅是连接。我们以两种方式构建边。有些是从文档引用中确定性地提取的。由于 wiki 论断本身已带有文本引用，我们可以物化出诸如refers_to和supersedes这样的带类型边，而无需再调用一次模型。
该图的构建耗时不到一秒，并解析了测试库中所有显式的交叉引用，因此智能体可以沿着链接走，而不必在每个问题上重新发现连接。
该图的职责是证据导航，而非对组织所知的一切进行建模。综合仍由 wiki 提供。与提取密集型知识图谱流水线不同，这一层复用现有的引用和引文，而不是用模型提取并对齐实体。构建过程无需额外的模型调用，不过从 wiki 派生的边仍依赖于其模型生成的引文的准确性。
有两个工具让智能体可以浏览这张地图：locate找到一个与问题匹配的起点，以及expand沿着它的连接前往支撑段落和相关文档。在只有一条路径的地方，expand会自动跟随；在路径分叉的地方，智能体选择下一步去哪里。这种定位相关节点并收集相连上下文的模式也出现在 GraphRAG 系统中，例如微软的 GraphRAG。
@tool(parse_docstring=True)asyncdeflocate(terms:str, within:str|None=None) ->dict:"""查找起点：将问题的词语与文档标题进行匹配，章节标题、wiki 页面和声明语句。...@tool(parse_docstring=True)asyncdefexpand(node:str, edges:list[str] |None=None, hops:int=1) ->dict:"""打开一个节点并列出其带类型的边（cites、refers_to、supersedes、amends、attaches_to 及其反向边）。当 hops > 1 且只有一种边类型时，在只有单条路径的情况下沿该边遍历，遇到分支即停止。"""...更高的准确率、更低的成本、更快的回答
添加显式证据路径后，每一项指标都优于仅使用 wiki。准确率提升了 27%，引用一致性翻倍，回答时间中位数下降了 40%，每个正确答案的成本下降了 58%。证据图以更具方向性的检索补充了 wiki 的上下文，在不使智能体完全确定性的前提下同时提升了准确率和一致性。
何时值得为添加记忆付出成本？
编译式 wiki 最有说服力的场景是重复的跨来源推理。在我们的实验中，wiki 帮助智能体应用领域关系，而不是通过搜索重建这些关系。但仅靠记忆层并不能让证据检索保持一致。添加显式的图边提升了引用一致性和准确率，同时减少了检索工作量。
wiki 为轻量级证据图提供了坚实的基础，该证据图从其现有的引用和文档引用中确定性地推导而来。这让我们无需额外的模型调用，也无需对组织所知的一切进行建模，就能添加显式的证据路径。
wiki 是否值得投入取决于复用程度。我们报告的答案成本不包含编译成本，而添加文档每份约花费 0.09 美元。对于简单的查询，摄取和持续维护的成本可能超过检索节省的成本——在这类场景中，仅靠搜索同样准确且更快，尤其是在企业规模下。
当多个智能体反复回答跨越相同离散来源的问题时，这种权衡会发生变化。共享 wiki 保留了这些来源之间的关系，而图边则引导智能体找到支撑证据。在我们的测试中，这种组合以更低的每个正确答案成本产出了更准确的答案。只要有足够的复用，避免重复重建上下文所带来的节省就能抵消构建和维护记忆的成本。
下一步
接下来，我们希望更动态地构建 wiki，只编译和保留智能体在跨来源问题上所需的上下文，而不是整个仓库。
我们还希望探索声明和类型化边，作为其他类型智能体记忆的基础。将知识与证据关联起来，并检测其何时发生变化，有助于为语义记忆（事实）、情景记忆（发生了什么）和程序性记忆（如何做事）提供依据。
想把 wiki 加入你的智能体？查看我们的 OpenWiki 资源：
致谢
感谢 Colin Francis 和 Nick Hollon 对 OpenWiki 及评估工作的思考！