知识检索跟着任务进度走

假设一个 Agent 正在排查“接口偶尔超时”。

刚接到任务时，服务架构、依赖关系和常见故障手册都有帮助。它需要先了解请求经过哪些服务、可能在哪里等待，再决定从哪里检查。

几轮调查后，它发现数据库耗时正常，慢请求集中在支付网关，而且主要出现在某次发布之后。接下来，它需要查看网关的调用记录、超时配置和近期变更。

但如果检索仍围绕最初那句“接口超时”返回资料，排在前面的可能还是数据库慢查询手册、网络故障指南。这些文档都与问题相关，Agent 却可能重新走一遍已经查过的路。

问题没有变，任务已经往前走了。检索需要知道这段进展。

“进度”在这里包含具体的调查结果：哪些事实已经确认，哪些原因暂时排除，还有哪些猜测等待验证。这些信息决定了下一次检索应该寻找什么。

继续上面的例子。Agent 怀疑发布引入了超时问题，要判断是否与重试配置有关，至少需要凑齐几类信息：变更记录里改了什么、当前实际生效的配置是什么、慢请求是否出现了对应的重试行为。

即使找回五篇解释“重试可能放大延迟”的文档，也无法单独证明这次故障由重试引起。文档数量增加了，关键证据仍然缺失。

几条分别相关的资料，放在一起，未必足够支持一个判断。

9 月 17 日提交的 The Missing Complement，就把这个问题放进了代码任务的检索过程。

它根据 Agent 已经看到的内容，寻找下一步决策仍然缺少的一组证据，考虑材料之间是否互相补充。在来自 45 个仓库的 500 个任务中间状态上，取 5 条材料时，完整证据集恢复率为 73%，对照方法为 61.4%。这衡量的是所需证据是否找全，不能直接当作任务完成率。

同日提交的 RAFT 则关注历史排障案例。它把已关闭工单整理成调查时间线，检索与当前状态相似的中间节点，再提供从该节点展开的案例过程。

对于正在调查支付网关的 Agent，一份起初也叫“接口超时”的工单未必最有帮助。更有用的可能是某个已经排除数据库、正在核对网关配置的历史案例，以及当时接下来检查了什么。这个例子说明了按排查状态寻找经验的用途。

RAFT 报告了检索命中指标的改善，尚未证明线上故障解决率提高。两项研究的共同价值，是把“Agent 已经知道什么、现在需要判断什么”纳入了检索，而非只围绕最初的问题描述寻找资料。

落实到工程系统中，可以把每次检索前的任务状态整理成一份简短记录：已确认的事实及来源、尚未验证的猜测、接下来要做的判断。系统据此选择资料和数据入口，再检查返回的信息是否补上了缺口。

在超时案例里，历史处理经验可以从知识库检索，当前调用记录和生效配置则需要通过工具读取。检索结果帮助 Agent 确定应该检查哪些配置；工具返回的事实，又会改变下一轮检索方向。两者共同推进调查。

这里有一个容易忽略的要求：调查过程中的判断，也需要允许被修正。

“数据库正常”可能只来自某个时间窗口，“问题发生在发布之后”也只是相关线索。如果这些判断被直接记成永久事实，后续检索就可能一直绕开真正的原因。保留检查范围、时间和原始证据，才能在新线索出现时重新审视它们。

因此，给 Agent 建知识库，除了整理文档，还需要把任务的执行过程接进来。已读内容、调查结果和待验证问题，应当能够影响接下来提供什么资料。

评价检索时，也可以多看一步：这次返回的信息有没有带来新的依据，是否减少了重复调查，是否足以支持下一步验证。这些比“搜到了几篇相关文档”更接近 Agent 的实际工作。

当一个 Agent 要连续工作几十轮，每次检索都应该承接前面的进展。最初需要的是了解全貌的手册，后来可能只缺一条配置、一段日志，或者一次历史调查中的关键检查。

知识供给的价值，就体现在这些具体的下一步里。