multi-agent rag

单智能体 RAG 跑一阵子就会暴露问题：一个问题要查好几个方向，一个智能体既改写查询又筛结果又写答案，改着改着就串味；想拆成多个角色分工，又发现谁调谁、失败怎么退、日志怎么看全没想清楚。这篇不重复讲 RAG 原理，只给拆角色、定接口、控并发、做降级和评测的工程做法，以及上线后被问「为什么这次没查到」时的排查顺序。

单智能体 RAG 刚上线那阵子往往还行，问个事实、查个条目都能答上来。跑一段时间就会暴露问题：一个问题要查好几个方向，同一个智能体既改写查询、又筛结果、又写答案，改着改着就串味，最后连它自己都说不清到底查了什么。想拆成多个角色分工，又发现谁调谁、失败怎么退、日志怎么看全没想清楚。

这篇不重复讲 RAG 原理，只讲工程做法：怎么判断该不该拆、角色怎么划、接口怎么定、并发和超时怎么控、怎么降级、上线后被问「为什么这次没查到」时按什么顺序排查。判断类的结论都会写清什么情况下不适用。

什么情况下值得拆成多智能体

先别急着拆。单问题单跳、语料同质的场景，单智能体加好分块和重排就够了，硬拆只会多出几层延迟和失败点。拆角色本质是在拿「可控性」换「复杂度」，只有当单智能体确实扛不住时这笔交易才划算。

• 不值得拆的硬指标：语料只有一个库、问题大多是单点事实查询、团队还没有稳定的评测集；这三条占了两条以上，就先别拆，把分块、重排和召回做扎实更重要
• 拆的粒度按「职责」不按「模型」：检索、改写、校验、汇总各一个角色就够，别再按数据源再切一层，角色一多日志和排查成本是翻倍的
• 角色数量不要超过任务真实需要的分支数：一个只会被调用一次的角色，本质上就是一个函数，写成函数比写成智能体更好维护

角色划分与接口契约

规划者

把原始问题拆成若干可独立检索的子问题，输出结构化列表，不负责抓数据

检索者

执行单个子问题的查询，回传片段原文加来源标识，不负责判断够不够

校验者

根据证据判断是否充分、是否存在冲突，输出通过或补充检索的结论

汇总者

只吃校验者递上来的证据包，产出一致口径的答案，不直接连检索工具

接口契约比角色数量更重要。每个角色定义固定的输入输出结构，缺字段就直接报错，不要让它猜。检索者必须回传来源标识和片段原文，这两样东西是事后复盘的全部依据；汇总者也别让它自己去临时查一遍，否则重复调用加上口径不一致，等于白拆。

「够不够」的判断尽量写成显式条件，而不是让模型自由发挥。比如证据条数下限、来源覆盖的文档数、冲突条数阈值，这些能落成数字就先落成数字。不适用的场景是探索型问题：这类问题本来就没有标准答案边界，可以让校验者放宽判定，但一定要在日志里标记出来，否则事后没人知道那次是放宽过的。

编排、并发与超时预算

1. 先选最稳的编排形态串行管线（规划→检索→校验→汇总）最容易排查，先用它把链路跑通；只有检索分支彼此完全独立时再上并发扇出，别一上来就并行，出错时你连是哪一支挂的都看不出
2. 给整条链路设总预算只设单步超时是不够的：每一步都没超，加起来照样超。总预算按用户能等的时长倒推，再把预算分摊到每一步；某一步经常吃满预算，就先优化它而不是提高总预算
3. 并行度按限流倒推并行数别凭感觉设，按账号的并发和速率口径来。到 /price-watch 核对当时的限额与速率数字，再决定扇出宽度
4. 迭代检索必须封顶设轮次上限，再加一条「连续两轮没有新增有效来源就停」。没有这条，问题稍难一点就会无限循环，额度烧得莫名其妙

• 缓存按子问题粒度做：同一子问题短时间重复出现直接复用上次片段，但必须带过期时间
• 语料更新后旧缓存要能主动失效，否则最坏情况是用户拿到已经改过的旧结论
• 每一步的耗时都记进日志，超时排查时才有据可查，别只记总耗时

失败降级、日志与评测

降级顺序要提前写死，不要等挂了再临时想。某个检索分支失败，就用其余分支继续；校验者判定证据不足，就返回「没查到可靠来源」，而不是硬编一个答案糊过去；汇总环节失败，就退回拼接原始片段并明确标注未做总结。三种退法各有适用边界，硬编那条任何时候都不要用。

排查顺序建议这样走：先看是不是接口报错或限流，再看到底命中了哪些来源，最后看校验者的判定对不对。挂掉和答错是两类问题，接口报错看传输和限额，答得不对看检索命中和校验判定，混在一起看只会白花时间。这跟单智能体时代的排查思路不一样，单智能体你只能看一段日志，多智能体反而给了你分阶段的抓手。

• 评测按角色拆开做：检索角色看召回，校验角色看误判率，汇总角色看引用是否对得上来源
• 先把各角色分别测稳，再跑端到端；否则端到端分数掉了，你根本不知道该改谁
• 端到端只看一个数不够，出问题时要能回到角色级日志，落回具体是哪一环

多智能体的价值不在智能体数量，而在每个角色的输入输出都能被检查、被复现。