「多 Agent 一定比单 Agent 强」错在哪？

多人团队不一定比一个人高效，开个会要对齐半天，这个常识放到智能体上同样成立。「多 Agent 一定比单 Agent 强」错在哪？错在把人海战术搬进了系统：拆得越多，沟通成本越高，出错面越大，而回报未必按人数涨。

错在哪：通讯成本是隐藏大头

单智能体干活，思考过程在自己脑子里；多智能体协作，每一步都要把上下文写成文字传给下家，传丢了、传偏了、传冗余了都出问题。三个智能体互相交接，接口就有六种组合，谁输出什么格式、谁兜底谁，全是新增的出错点。协调的复杂度涨得比能力快。上下文稀释是另一重代价：多个智能体协作时，每个都要带上任务背景的全量说明，同样的背景写五遍，窗口占用翻五倍，单智能体一份说明就够。协作不是免费的，窗口空间在系统里同样稀缺。

正确说法：单智能体优先

默认做法是先用单智能体把任务跑通，跑不动再拆。豆包、DeepSeek 这类模型的长上下文已经能装下不少复杂任务，很多所谓的多智能体需求，单模型加清晰的任务清单就够了。拆分要有理由：要么上下文确实装不下，要么环节之间确实需要不同配置，而不是为了架构图好看。衡量是否够用的标准也很实在：任务成功率、总耗时、总调用费用三个数字，单智能体达标就不折腾。架构服务于指标，指标不迁就架构，这句话在选型时反复有用。

什么时候真该拆成多个

三种情况值得拆。一是角色对立：写作的和挑刺的分开，自己查自己容易走过场。二是资源隔离：一个高频轻任务和一个低频重任务抢同一套配置，拆开互不拖累。三是权限收窄：对外发消息的和对内整理数据的分开，出事时影响面小。满足其一再拆，一个理由都套不上的，维持单体。拆之前先归因：跑不动是上下文装不下，还是提示词含糊、工具没配对？后两种修法便宜得多，把大手术留给真正装不下的场景。

三种该拆的情形，代价和收益对得上再动手。

拆分冲动常和工具堆料长在一起，见 「工具越多能力越强」错在哪？一次讲明白；多智能体还容易助长全自动幻想，以为分工完了就能撒手，「Agent 能全自动搞定一切」错在哪？ 拆过这个念头的漏洞。

决定拆了之后怎么落地

真要拆，先定三件事：每个智能体的职责一句话说清、交接格式白纸黑字、失败时谁兜底指名道姓。然后再考虑用不用现成框架。零代码平台看着省事，但流程思维省不掉，「零代码就不用懂流程」错在哪？ 讲过为什么画布替不了脑子；拆完后出错重试的复杂度也翻倍，「Agent 出错重试就好」错在哪？ 提前读能少踩坑。灰度也是必须的：新旧架构并行跑一段时间，用真实流量对比，确认新架构全面达标再切换，随时留一条退回单体的路。日常维护时也别忘了回看：当初拆分的理由还成立吗？上下文窗口在变大，去年装不下的今年可能装得下，合并回去反而省心。

拆分判断三问

• 单智能体真的跑不动了吗
• 每个新拆出的角色一句话说得清吗
• 交接格式和兜底责任定了吗

三问过半答不上，就先维持单体。

一句话收住：智能体的强弱看任务匹配和边界设计，不看编制表上的人数，这个误区破掉之后，选型会清爽很多。

多智能体与单智能体快问快答三则

• 多智能体就没有适用场景吗？：有，角色对立、资源隔离、权限收窄三类场景拆了确实值，前提是协调成本算得清。
• 怎么验证多智能体方案值得？：同一个任务两种架构各跑一遍，比整体成功率和总耗时，别比架构图好看程度。
• 拆了之后还能合回去吗？：能，每个角色的提示词和工具单独管理，合回去就是换个调度方式的事。