Agentic 搜索架构模式：能进生产的五种
摘要：推理循环是最便宜的那部分。真正决定一套代理式检索能不能落地的，是它外面的控制环：类型化工具、上下文隔离、硬预算，以及一个能把任务打回去的评估器。
关键要点
- 收益是实测的。 在同一个嵌入模型下，代理式检索把 nDCG@10 提高 8.7 个点。
- 代价也是实测的。 同一项研究给出每条查询 107.4 秒，而单次检索是 0.67 秒；每条查询输入 token 达 764.1K、输出 5.8K。
- 子查询彼此独立时，计划执行优于 ReAct。 延迟大约是标准检索的两倍，而 ReAct 在可并行的问法上要到四倍。
- 上下文隔离是阻断错误传播的那个模式。 主机—管理—worker 的分层设计，让一条烂子查询不至于污染最终答案。
- 生产事故多数是预算事故。 没有 token 上限、没有墙钟上限的循环不是架构，而是一次等待被触发的故障。
一、"代理式"到底加了什么
传统检索是一次过：编码问法、取 top-k、重排、作答。代理式检索在中间加了一层决策——由系统决定搜什么、搜几次、拿到的证据够不够答。
这层决策换来的是泛化。在域外任务上，固定的检索流水线会明显退化，而同一个代理循环在两个不同榜单上都还能打。它也换来了一个可测的质量增量：在嵌入模型不变的前提下，nDCG@10 提高 8.7 个点——说明增益来自问法构造与迭代，而不是换了个更好的编码器。
代价在同一份测量里同样清楚：每条查询 107.4 秒对 0.67 秒，输入 764.1K token、输出 5.8K。两个数量级的延迟差、五位数的 token 账单，这不是四舍五入的误差，它直接改变了系统能用在哪，也是为什么架构比选模型更重要。
二、五种模式，各自什么时候是错的
| 模式 | 形态 | 适用 | 失效场景 |
|---|---|---|---|
| 计划执行 | 一次规划产出类型化子查询，再并行执行 | 多条件问题、看板、合规核查 | 子查询彼此依赖 |
| ReAct 循环 | 想—做—看，反复到证据足够 | 探索式调研、陌生语料 | 延迟预算在五秒以内 |
| 分层 worker | 主机拆解、管理聚合、worker 并行且上下文隔离 | 大语料、长会话 | 编排开销超过检索耗时 |
| 检索即工具 | 把搜索、过滤、SQL 作为类型化函数给模型调 | 结构化与非结构化混合 | 工具 schema 与索引漂移 |
| 评估器把关 | 一个检查器给证据打分，不通过就重规划 | 高风险答案、受监管领域 | 评估器与规划器共享盲区 |
第一种是主力。当一个问题能拆成互不依赖的几段，规划一次、并行执行，延迟就停在标准检索的一个小倍数上，而不是随推理步数线性增长。
ReAct 更适合"确实不知道该搜什么"的时候，它也是最容易打爆延迟预算的模式，因为每一次观察都是一次模型调用。
分层设计存在的理由很朴素：上下文饱和。所有子查询的结果都落进同一个窗口，后面的推理就会退化。把 worker 上下文隔开、在管理层聚合，能保住最终综合的干净，并行也吸收掉一部分额外成本。
检索即工具是多数团队实际在跑的东西，因为它让同一个代理既回答"制度怎么规定"，也回答"上个月有多少工单超时"，不用两条流水线。它的失效点是 schema 漂移：工具描述说一套、索引是另一套，代理会安静地搜错字段。
评估器把关多花一个模型来判断证据是否支持答案。受监管场景有用，但前提是评估器的失败分布与规划器不同——否则两边会漏掉同一件事。
三、我们会怎么搭这个控制环
- 状态放在模型外面。 计划、已执行的子查询、证据集，都放在编排器自己的存储里。模型会改写自己的草稿区，编排器不能依赖它。
- 类型化工具加校验 schema。 每次工具调用在执行前先过 schema，而 schema 由索引定义生成，从根上避免漂移。
- 两个硬预算。 token 上限与墙钟上限，由编排器执行，不靠提示词。任一触顶就返回支撑最好的局部答案，并标注置信度。
- 证据台账。 每个召回段落带 ID、来源、时间戳、分数。最终答案引用 ID，不引用散文。这是答案可审计的前提。
- 评估器带重规划路径。 证据不过关就带着失败原因回到规划，只回一次；第二次失败就给出拒答并说明缺什么。
- 按步可观测。 记录每一步的延迟、token 消耗、召回条数。聚合 trace 会把吃掉 80% 预算的那一步藏起来。
第三点是多数团队投入不足、但其实很便宜的一环。提示词里写"请高效"不是预算，一个能终止循环的计数器才是。
还有一个模式值得单独命名，因为它才是压住成本的东西：在子查询层做缓存，而不是在答案层。两个问题只要共享主体名与时间区间，就可以复用同一次检索结果，前提是缓存键由归一化子查询加索引版本构成。答案层缓存注定低效，因为每个问法的最终答案都不同；子查询层缓存命中率够高，而且索引一变就能干净失效。
反方观点是：缓存会让循环变懒。确实会——规划器会复用先前结果而不是重新构造，而这正是你想要的，因为重新构造一条本来就能用的子查询，纯烧 token。
四、我们在一个真实合同检索项目里改了什么
一个有代表性的案例：企业合同库，1,400,000 份文档，平均问法是一条带两个到三个条件的法务问题。第一版代理用的是 ReAct 循环，p95 打到 9 秒，token 花费让财务来问话。
我们换成计划执行。一次规划调用产出三到五个类型化子查询（主体、条款类型、时间区间、管辖地），对同一个混合索引并行执行，然后一次综合。p95 降到 3.4 秒，nDCG@10 同时上升，因为子查询把条件拆开了，而不是指望一个向量同时装下所有条件。
两件没预料到的事。第一，规划器需要一条"最多五个子查询"的硬上限——超过之后召回不再提升，延迟线性增长。第二，最大的收益来自证据台账而不是循环本身：答案一旦引用段落 ID，法务复核的纠错率就下降，因为他们能直接核对原条款，不用重读一遍答案。
工具 schema 这件事值得单独说，因为它是藏得最久的故障。工具用散文描述（"按相对方检索合同"）时，模型会传一段自由文本相对方，索引再拿它去匹配错字段——比如把主体名匹配到文档标题上。把工具定义成"索引字段枚举加每字段校验类型"，让模型在里面挑。散文式工具会产出针对错字段的、看起来很合理的查询，这比调用失败更糟，因为证据看起来是相关的——而错的相关证据，最终会变成一份自信的错误答案。
五、边界，以及那些看着高级的错觉
- 代理越多不等于能力越强。 超过三到四个 worker，编排开销开始主导，答案质量走平。
- 并行只对独立工作有效。 对相互依赖的子查询做扇出，产出的是一份建立在错证据上的、看起来很漂亮的答案。
- 107 秒是研究环境下的数字，不是服务标准。 生产只有在无界循环里才会撞到，修法是预算，不是更快的模型。
- 流式输出掩盖延迟，但不消除延迟。 我们的日志里，用户在看着 token 往外蹦的时候，30 秒还是关掉了页面。
- 评估器会继承规划器的偏见。 把关环节换一个模型家族，或者用规则型检查器。
- 每条查询多少 token，才是真约束。 按 764.1K 输入 token 算，每月 10,000 条查询的部署，先是产能规划问题，然后才是质量问题。
最后一个结构性的点，关于评估：循环要按任务成功率与证据覆盖率打分，不能只看排序指标。一个系统召回了排得很漂亮的段落，但这些段落合起来答不了问题，它的 nDCG 提高了，任务却失败了。两个都记；当排序质量上升而任务成功率不动时，说明规划器产出的子查询是索引能排、但满足不了的。
常见问题
问： 到底要不要上代理？
A： 如果一次检索就能答，就别上。先量"需要第二条子查询"的问法占比；低于 15% 时，换个更好的重排器更便宜。
问： 先上哪个模式？
A： 计划执行加类型化工具。它在各类问法上都能扩展，延迟也可预测。
问： 成本怎么封顶？
A： 编排器里设硬 token 与时间预算，再加租户级月度上限和一条优雅降级路径。
问： 上下文隔离值不值这个复杂度？
A： 单次会话召回超过 20 个段落就值；低于这个量，单窗口加一个好摘要器就够了。
问： 循环怎么评估？
A： 固定问法集加分级相关性；排序质量看 nDCG@10，循环本身看任务成功率与每步延迟。
问： 安全怎么管？
A： 在工具层做授权，不在提示词层。代理应该根本调不到用户角色无权使用的工具。
关于通智云
通智搜索把代理式检索做成受控能力：类型化工具、硬预算、证据台账、按步可观测，让循环的质量收益能穿过生产环境的延迟指标。
相关阅读
数据来源
- 超越语义相似度：代理式检索的性能与成本——同一嵌入模型下 nDCG@10 提高 8.7 个点；每条查询 107.4 秒对 0.67 秒；输入 764.1K、输出 5.8K token。
- 企业生产环境的 Agentic RAG——计划执行延迟约为标准检索两倍，ReAct 在可并行问法上为四倍。
- InfoSeeker：分层并行代理框架——主机—管理—worker 拆解与严格上下文隔离。
- 生产级代理式搜索架构——控制环、评估器、运行时预算与可观测性。
