协调者的智能应该用来匹配查询复杂度和委派范围。对每个请求都跑所有 agent 是固定流水线，不是智能编排者。动态选择——分析每个查询、只委派需要的 agent——减少延迟、降低成本，同时保留对复杂案例的彻底性。
固定流水线反模式
一个有 5 个子代理的研究协调者对每个查询都跑全部 5 个，即使”论文 X 是什么时候发表的？“——一个只需要搜索 agent 的问题（约 5 秒）。结果：简单的事实查询耗时 45 秒，跟复杂研究查询一样。用户抱怨简单问题响应太慢。
根因：协调者用固定流水线，不管查询复杂度。简单和复杂查询延迟相同是明确的信号。
成本影响
一个月 500 查询的系统的生产数据：
- 固定流水线：$0.10/查询 × 500 = $50/月
- 动态选择：简单（$0.02）+ 中等（$0.05）+ 复杂（$0.10）= $23.25/月
- 节省：53.5% — 主要来自 45% 的查询只路由到一个 agent
协调者的分析步骤成本远低于调用不必要的子代理。它是一笔多倍回本的投资。
自适应委派
如果初始评估低估了复杂度怎么办？开发者让”检查一下我的工具函数”——看起来只需要风格检查，但函数里有并发 bug。
方案：两阶段委派。先用初始选定的 agent。如果第一阶段结果表明有额外关注点（风格 agent 标记了可疑模式），协调者通过调用额外 agent 来升级。这保留了快速路径的效率，同时捕获需要更深分析的案例。
提升选择准确度
实施动态选择后，某系统的数据：85% 正确，10% 选少了（回答不完整），5% 选多了（轻微浪费）。10% 的选少驱动了客户投诉。
修复：分析选少的案例，识别模式（比如看起来是单关注点但实际是多关注点的请求），在协调者的 prompt 中加 few-shot 例子，示范这些常被误判模式的正确选择。方法对 85%+ 的案例有效——校准边缘情况就好，不要放弃整个方法。
协调者做选择
不需要单独的分类器模型来做 agent 选择。协调者已经在分析查询做任务分解了——动态 agent 选择是这个分析的自然延伸。加一个分类器是重复工作，需要训练数据，还引入了误分类风险。
一句话总结： 分析每个查询、只委派需要的 agent——动态选择节省 53%+ 成本，简单查询延迟从 45 秒降到约 10 秒，初始评估低估复杂度时可以用两阶段委派来自适应。