rag with multi agent

单 agent 做 RAG，检索、改写、作答全挤在一次调用里，问题一多就互相打架：检索召回不够没人补，答案跑偏没人挑。多 agent 协作能把这几件事拆开，但拆完立刻多出一堆工程问题——谁先跑、证据怎么传、某个 agent 超时了怎么办、日志怎么记才能复盘。这篇不聊概念，只给拆角色、定接口、设兜底、做评测的可执行做法。

单 agent 做 RAG，改写、检索、作答经常挤在同一次调用里。问题一多就开始互相打架：检索召回不够没人补，答案跑偏没人挑，出了错也不知道该怪哪一环。多 agent 协作的思路就是把这几件事拆开，让每个环节只干一件事，谁掉链子一眼能定位。

但拆完立刻多出一堆工程问题——谁先跑、证据怎么在 agent 之间传、某个环节超时了走哪条退路、日志记什么才能复盘。这篇不谈概念，只给拆角色、定接口、设兜底、做评测的可执行做法。判断标准也会写清楚什么场景下不该拆。

先定角色，再定调用顺序

最小可用的切法是三到四个角色：一个负责改写和规划查询，一个负责检索，一个负责作答，校验可选。再往下切就要留意了，角色越多，交接次数越多，协调成本会慢慢吃掉拆开带来的收益。

• 改写/规划 agent：把用户原话转成可检索的查询，必要时拆成多个子查询
• 检索 agent：拿查询去捞候选片段，只关心召回和排序
• 作答 agent：只看最终证据，负责组织答案和标注引用
• 校验 agent（可选）：检查答案是否被证据支撑，不支撑就打回或降级
• 再细的角色先别加，观察一段时间再说

每个角色要各管一段上下文。检索 agent 只看到查询和候选，作答 agent 只看到最终证据，中间过程不要互相污染。多个检索 agent 并行召回可以，但作答必须等所有检索结果到齐再启动，否则答案会缺一块。

把交接协议写死：证据怎么传、多大、带什么元数据

多 agent 最容易出事的地方就在交接。每个 agent 的输出格式如果各写各的，下游解析会写一堆兼容代码。统一一个证据结构，字段缺一项后面就排不了序、引不了用。

片段正文

真正要喂给作答 agent 的那段文字，不要再带上原文全文

来源标识

能定位到原始文档或条目的 id，用于回查和引用

召回分数

检索阶段给出的相关性打分，供下游排序或过滤

时间戳

这条证据是什么时候拿到的，方便排查缓存和时效问题

给交接内容设上限。只传片段和必要字段，不要把整篇原文丢进下一个 agent 的上下文，既浪费窗口又干扰判断。引用要能回溯：答案里每个结论对应哪个片段，出问题时能直接判断是检索没捞对，还是作答没用上。

超时、并发、降级、日志这四件事先配好再上线

多 agent 链路的故障点比单 agent 多得多，所以这四个机制要在上线前就配好，不要等出问题再补。每个 agent 单独设超时，别用一个总超时兜全局，否则你只知道整条链路慢了，不知道是哪个环节慢。

1. 按 agent 设超时改写、检索、作答分别配自己的超时阈值，超时后走各自定义的降级分支
2. 给链路设步数上限限制总调用次数，检索 agent 反复改查询时能强制停下，避免死循环烧额度
3. 准备好降级路径检索失败退回单轮直接回答；作答 agent 挂了退回拼片段；校验 agent 不可用就跳过校验，别让整条链路一起挂
4. 按轮次记日志本轮查询、召回了哪些片段、走了哪个分支、各段耗时分别记下来，缺这些出了错只能靠猜

降级不是可有可无的兜底，而是设计的一部分。哪条路径允许降级、降级后用户体验会差在哪，最好在写代码前就明确，不然上线后遇到抖动会临时拍脑袋改。

用固定问题集迭代，而不是凭感觉改提示词

多 agent 系统改一处提示词，可能影响整条链路，所以要有固定的问题集来对比。准备一小批覆盖典型问法的固定问题，每次改完重跑同一批，看的是变好还是变差，而不是这次看着感觉不错。

• 检索有没有把对的片段捞回来：看召回结果里有没有正确证据
• 作答有没有用上捞回来的片段：看结论能不能对应到证据
• 常见故障模式先归类：检索漏、检索噪、生成编、链路超时，四类改法完全不同
• 改动一次只动一处，避免多个变量混在一起说不清哪个起了作用

别按印象估延迟和成本，到站内页面核对当时的数字，用真实口径决定要不要加缓存、要不要砍掉某个 agent。模型和价格随时在变，判断依据也要跟着更新。