一个 agent 加 tool use 就够了
我最近在内部复盘时发现，我们团队搭建的多 agent 编排项目，有八成其实根本不需要。
上个月有个典型例子。客户需要一个智能客服+工单系统，需求文档里写满了“跨 agent 协作”“多轮对话编排”“上下文路由”。三个工程师兴奋地画了架构图：Agent A 做情感分析，Agent B 做知识库检索，Agent C 做工单摘要生成。每个 agent 之间用消息队列沟通，还配了个编排引擎负责状态机流转。
我让他们停一下。先问一个问题：如果只有一个 agent，给它三个 tool——情感分析 API、知识库搜索、摘要生成——会怎样？
试了一天。效果一样。而且调试时特别爽——单个 agent 的 trace 干干净净，每一步 tool call 的输入输出都看得清。而之前那个三 agent 方案，跨 agent 的追踪全是噪声：A 发给 B 的消息格式错了，B 解析花了 300ms，C 还等 B 的确认才能继续。为了“可观测性”我们花了三倍时间搭链路，最后看到的信息还不如单 agent 的日志直接。
这个自己也曾犹豫。我当时觉得多 agent 才是“先进”做法，行业里都在讲编排。但实际跑下来，单 agent + tool use 在很多场景下更可靠、更可观测、更容易调试。
编排的可观测性是个伪命题
很多人说多 agent 编排的好处是“可观测性”——你能看到每个 agent 的决策过程，能追踪消息流转。
但真相是：这种可观测性常常是幻觉。
我们有个项目，三个 agent 协作做客户意图识别和后续动作。A agent 输出意图标签，B agent 根据标签生成回复，C agent 检查合规。看起来很美。但一旦出现错误，你要翻 A 的输出、B 的 prompt、C 的判断逻辑，还要看消息传递过程中有没有被截断或乱码。真正排查问题时，你往往需要回放整个 session，而 session replay 在编排系统中很难做到。单个 agent 的 tool call 记录反而清晰得多。
我承认，如果编排框架足够成熟，比如有原生的分布式追踪和 session 回放能力，情况会好一点。但 2026 年的现状是，大多数编排库还停留在“能用”阶段，生产级的可观测性工具非常稀缺。
再说一个数据：我们内部统计过，为了搭编排系统，团队平均多花了 40% 的开发时间，但故障定位时间只减少了 10%。这笔账不划算。
但 5% 的场景我必须用它
话说在前面——6 个月后我可能被打脸。
但现阶段，我坚持一个决策框架：先单 agent + tool use 跑通，只有当单 agent 的 prompt 长度无限膨胀、tool 数量超过 10 个且彼此冲突、或者有明确的分阶段异步需求（比如一个 agent 执行 A 后等几天才触发 B），我才考虑拆分。
我们遇到过的真实场景是金融风控中的“跨系统数据核实”。客户要求：先查外部黑名单，如果有命中，再查内部交易流水，如果流水有异常，再发起人工审查。每一步依赖前一步的结果，且每个步骤的数据源权限不同、响应时间差异大。这时候一个 agent 管不过来——不是技术上限，而是 prompt 太长，tool 之间逻辑耦合严重。拆成三个 agent，每个负责一个阶段，通过状态机编排，反而清晰。
但那之后，我们花了很大力气做 session 回放。每次风控决策都要能完全重放所有 agent 的对话和决策路径，否则合规过不了。这才是多 agent 编排的真正价值所在——复杂管控需求下，可观测性不是可选项，而是必要品。
为什么我们高估了多 agent
反思一下，我自己之前也被带偏了。2025 年团队参加了好几个 hackathon，看到别人用多 agent 做 demo 很酷，框架也宣传“编排是 AGI 的必经之路”。回来就想把现有项目全改成多 agent。
结果呢？一个内部知识库问答系统，原来用单 agent + RAG 跑得好好的，强制改成三个 agent（一个做 query 分解，一个做文档检索，一个做答案合成），不仅响应慢了 30%，还多了不少幻觉。而且检索 agent 偶尔会调用错误 tool，导致整个 pipeline 卡住。最后还是改回去了。
我觉得大部分工程师（包括我自己）喜欢多 agent 是因为它让系统看起来更“智能”、更像人类协作。但工程不是作秀。额外复杂度必须换来量化的收益。
现在我的原则是：
- 能用单 agent 绝不用多 agent
- 如果一定要拆，先定义好“拆之后的可观测性方案”
- 没有 session 回放能力的编排系统，宁可不拆
这一轮 AI 工程化的浪潮中，很多人把“多”等同于“好”。我倒觉得，2026 年的关键词应该是“少而精”——少一点 agent，多一点可靠。