持久化检索：对话代理效率提升新范式

对话代理在处理信息检索时，面临一个关键的设计选择：是让主代理直接检索，还是委托给专门的子代理？不同的选择会影响检索历史如何维护、每次模型调用接收什么上下文，以及后续问题需要重新检索哪些信息。近期一项研究对比了三种设计，并提出了持久化检索子代理方案，在效率与成本之间找到了新的平衡点。

三种检索架构的对比

研究比较了三种设计：基于技能的主代理检索、非持久化检索子代理（生成发现响应），以及提出的持久化检索子代理。持久化方案的核心在于跨轮次维护检索历史，并将检索到的证据直接返回给主代理，而不是让子代理生成合成响应。此外，主代理还可以向同一个子代理请求更正。

这种设计转变意味着检索子代理的角色从“生成答案”变为“维护检索状态并提供证据”，主代理则负责评估证据并生成最终回答。这类似于将检索与推理分离，让每个组件专注于自身擅长的任务。

检索子代理（Retrieval Sub-agent） 指在主代理之外独立承担信息检索任务的模型实例，通常通过工具调用（如搜索API、数据库查询）获取外部知识。与主代理直接检索相比，子代理可以封装检索逻辑、隔离上下文，但也引入了代理间通信开销。持久化（Persistent） 在此语境下特指子代理在多个对话轮次间保留检索历史与状态，而非每轮重新初始化；非持久化子代理则每次请求都从零开始，输出一份“发现响应”后即丢弃状态。主代理（Main Agent） 负责对话管理、证据评估与最终回答生成，其与子代理的职责划分决定了上下文窗口的占用方式和模型调用次数。

实验设置与评估维度

研究在企业问题上评估了三种设计，涵盖独立提问、共享对话中的提问以及依赖上下文的后续提问。这些场景模拟了真实对话中信息需求动态变化的复杂性。评估跨越五个多轮设置，确保了结果的稳健性。

实验关注的核心指标包括：记录的代理-模型token使用量、估算API成本以及平均响应时间。这些指标直接关系到实际部署中的运营成本和用户体验。

代理-模型token（Agent-Model Tokens） 指在代理架构中，主代理与子代理各自调用底层大模型时所消耗的输入与输出token总和，而非仅统计最终用户可见的对话token。这一指标能更真实地反映多代理系统的推理开销，因为子代理的每次工具调用决策、证据整理和响应生成都会产生模型调用。估算API成本 通常基于各模型每百万token的输入/输出单价加权计算，不同模型（如主代理用强模型、子代理用轻量模型）的混合使用会显著影响总成本。平均响应时间 则涵盖从用户提问到最终回答返回的端到端延迟，包括子代理检索、代理间通信和主代理生成的全部耗时。

效率优势：更少的token与更低的成本

与基于技能的主代理检索相比，持久化检索方案使用了43.3%更少的记录代理-模型token，估算API成本降低45.0%，同时平均响应时间减少了9.1%。这一结果凸显了持久化检索在降低运营开销方面的显著优势。

成本降低的主要来源可能是避免了重复检索和上下文重建。在基于技能的方案中，主代理可能需要在每次调用时重新获取信息，而持久化子代理保留了历史，减少了冗余的模型调用。

与非持久化检索的权衡

与非持久化检索子代理相比，持久化方案将每个问题的响应时间减少了15.6秒，但使用了65.1%更多的token，估算API成本高出29.1%。这表明持久化检索在响应速度上占优，但代价是更高的资源消耗。

这种权衡反映了设计目标的不同：非持久化方案可能更注重单次交互的成本，而持久化方案则优化了多轮对话的整体效率。对于需要快速响应的场景，持久化方案可能更合适；而对于成本敏感的应用，则需要仔细权衡。

非持久化检索子代理 的典型工作流是：每轮对话中，主代理将当前问题（可能附带少量上下文）传给子代理，子代理执行检索并生成一段综合性的“发现响应”，随后该子代理实例被销毁，检索历史不跨轮保留。这种方式在单轮独立提问时token开销较低，因为无需维护和传递历史状态；但在多轮对话中，后续问题若依赖前文信息，主代理不得不重新发起检索或携带大量上下文，导致重复调用。持久化方案则通过保留检索状态，使后续问题可以增量检索或请求更正，从而在响应速度上占优，但历史状态的存储与传递本身会占用额外token，这解释了为何持久化方案token用量反而更高。

设计启示：检索与生成的解耦

该研究最重要的启示或许是检索子代理角色的转变。传统上，检索子代理被期望生成综合性的发现响应，但这可能导致信息损失或扭曲。持久化方案让子代理专注于维护检索状态和提供原始证据，主代理则基于这些证据进行推理和生成。

这种解耦类似于人类处理复杂问题的方式：先收集相关资料，再基于资料进行思考。它允许主代理灵活地评估证据的相关性和可靠性，并在需要时请求更正，从而提升最终回答的质量。

检索与生成解耦（Decoupling Retrieval from Generation） 借鉴了信息检索与自然语言生成分离的经典架构思想：检索组件负责召回和排序证据，生成组件负责基于证据进行推理与表达。在对话代理中，这种解耦的好处是避免子代理在生成“发现响应”时过早进行信息压缩或综合，从而减少信息损失和幻觉风险；主代理拿到原始证据后，可以结合对话历史灵活判断相关性。代价是主代理需要处理更长的证据上下文，对上下文窗口管理和证据筛选提出了更高要求。这一思路与检索增强生成（RAG）中“先检索后生成”的流水线一脉相承，但将其扩展到了多代理、多轮次的对话场景。

局限与未来方向

研究虽然展示了持久化检索的优势，但仍有局限。实验集中于企业问题，其他领域（如开放域对话）的适用性有待验证。此外，持久化方案在token使用上的增加可能对某些应用构成挑战，需要进一步优化检索历史的压缩和表示方法。

未来的研究可以探索如何动态调整检索策略，结合持久化和非持久化的优点，以及如何将持久化检索扩展到多模态场景。

总结

持久化检索子代理通过维护跨轮次检索历史并返回证据，在降低token使用和API成本方面表现出显著优势，同时提升了响应速度。尽管与非持久化方案相比存在成本权衡，但其设计理念——将检索与生成解耦——为对话代理的效率优化提供了新思路。对于构建企业级对话系统的团队，这一研究值得深入参考。