一个人能干的活，为什么要派三个人去
这个判断我憋了快半年——多 agent 编排，2026 年会被工程师扔掉一半。
不是说它没用。是说大部分公司不需要它。我们去年接了一个做精密零件生产的客户，他们要在质检环节用 AI 看图纸、比对公差、出报告。一开始我们按教科书来：一个「拆解任务」的 Agent，一个「查标准」的 Agent，一个「对比数据」的 Agent，还有一个「写结论」的 Agent，四个 Agent 编排在一起。当时觉得架构很漂亮。
问题出在上线第二周。一个简单的零件，三个 Agent 互传消息时，有一个环节把「0.05mm」误解成了「0.5mm」，报告结论直接写「超标」。客户半夜电话打过来，我们查了三小时才定位到——不是模型幻觉，是编排里上下文传递被截断了。
最后我干了件粗暴的事：把四个合一，就留一个 Agent，给它三个 tool（读图纸、查标准库、写报告），取消所有跨 agent 通信。那次上线之后，再没出过同类错误。
那刻我开始怀疑：我们是不是为了编排而编排。
编排带来的可观测性，远不如想象中好
市面上吹多 agent 编排的一个主论调，是「可观测性」——每个 Agent 的输入输出都能监控，便于调试和迭代。嗯，写这句话的时候我自己都笑了。真实情况是：当你把四个 Agent 串成链，某个环节出错，日志是一堆 JSON，你得一个个往回翻，搞清楚到底是谁传给谁的什么东西出了问题。
我记得那天晚上，同事说了一句：「这就跟拆定时炸弹似的，每根线都要捋。」
相比之下，单 agent 加 tool use，日志天然就是线性的。哪个 tool 入参出参不对，一眼能看出来。可观测性？单 agent 的链路才是真的可观测。编排之后，表面上看每个节点都有日志，实际上一团乱麻——这算哪门子收益。
当然，我不是说编排框架的设计者不行。他们肯定比我聪明。但我现在更相信：工具链的复杂度本身会吃掉可观测性的价值。除非你的场景真的复杂到单一 context 装不下，否则加 agent 就是加故障点。
但 5-10% 的场景，多 agent 还是省不掉
我也不能被自己带偏，刻意回避多 agent 真正有用的地方。我们后来碰到另一个客户，做跨境物流清关的——他们的作业流横跨五个系统，每个系统返回的数据格式、时效性完全不同，而且有的系统要等外部审批，不是「调个 API 就返回」这么简单。
这种场景下，单 agent 确实不行。不是上下文长度的问题，是决策路径本身分支太多，而且每个分支的业务规则差异大到不可能写进一个 prompt。我们最终还是用了三个 Agent：一个负责收集数据，一个负责决策分枝，一个负责执行操作——并且给了一个明确的「握手协议」，不允许自由格式传递，全部结构化。
这种设计跑到现在六个月，没出过大乱子。我回头想，能跑稳，也不是因为我们编排得好，而是因为场景本身就是割裂的，Agent 的边界刚好对上系统的边界。也就是说，多 agent 编排不是「为复杂服务」，是「为匹配系统割裂的真实世界服务」。这个区别，很多人没想清楚。
如果我现在接到一个新询盘
可能会先拒绝多 agent。上周有个 SaaS 公司找我聊，说要做 AI 员工，里面要十几个 Agent 协作。我问了一句：「你现有系统是不是按模块割裂的？」他说不，就是一整套业务中台。我说那不如先用一个 Agent 把流程跑通，够不着天花板就不要加椅子。
也许我太绝对了。6 个月后回头看，这个判断可能被打脸——比如 agent 间通信协议成熟了，编排框架自动处理 token 截断和上下文版本化。但现在的状况，我不能假装看不见：多数项目的多 agent 架构，不是来自需求，是来自工程师对「复杂」的审美。
2026 年，如果市面上还是「一个任务拆成四个 agent」的默认方案，那我觉得这行业有点病。