先说答案：多数需求单个智能体（Agent）就够了，上多个的前提是任务能拆成彼此独立、边界清晰的块。多智能体不是能力的简单叠加，协作本身有开销，拆得不好反而比单打独斗更慢更贵。
类比装修：一个工头统筹所有工序，够用且省沟通；全屋定制、中央空调、软装各请一家，专业是对了，但协调成本和来回沟通的风险跟着上来。失效之处在于，智能体之间没有工头那种天然权威，靠协议和消息对齐，沟通损耗比人类团队更直接。
任务拆分方式决定架构
判断标准看任务结构：如果各个环节必须共享同一份上下文才能做好，比如一份数据要反复推敲，单智能体串着做更稳；如果各块互不干扰、只交换结果，比如同时翻译十个文件，拆给多个并行更快。拆分粒度错了，要么上下文来回搬运，要么各干各的对不上。
协作带来的额外开销
多智能体的成本不止是人数相加：每条传递的消息都要拼进上下文，轮次越多越贵；协调方本身要消耗调用来分配任务、汇总结果；一个环节误解意图，错误会沿着链路放大。记账时要按链路归因，口径见多 Agent 的成本怎么核算？拆开细算。
什么时候确实需要多个
三类场景值得上多个：并行量大，单线程处理不过来，拆分后各跑各的，速度成倍提升；角色对立，比如生成与检查分开，自查容易手软，分开才挑得出问题；专业隔离，不同环节需要不同的工具和提示词，混在一个上下文里互相干扰。满足其一再考虑，别为架构而架构。
从单个升级到多个的信号
出现这些信号再升级：单个上下文经常溢出，塞不下任务所需信息；串行排队明显拖慢交付；不同环节对工具的需求已经互相冲突。升级前先确认单智能体的参数没调尽，比如并发与超时安排是否还有余量，以及失败隔离是否做到位，见超时的兜底动作有哪些？从原理到落地。
四个维度并排看，什么时候一个就够、什么时候该拆。
| 判断维度 | 偏单个 Agent | 偏多个 Agent |
|---|---|---|
| 任务结构 | 各环节必须共享同一份上下文，比如一份数据要反复推敲 | 各块互不干扰、只交换结果，比如同时翻译十个文件 |
| 协作开销 | 一条链路，省掉消息搬运与协调调用 | 每条消息都拼进上下文，协调方还要消耗调用分配任务 |
| 适用场景 | 多数日常任务 | 并行量大、生成与检查分开、专业隔离 |
| 升级信号 | 并发与超时还有余量，失败隔离做到位 | 上下文溢出、串行排队拖慢交付、工具需求互相冲突 |
单多选型对照表
- 共享上下文的活单个做，独立分块的活多个跑
- 协作开销按链路记账，别只数智能体个数
- 生成与检查分开，比自查更能挑出问题
- 上下文溢出、串行瓶颈出现再升级
一句话记住：别为了多而多，先问拆开解决什么问题。
讯飞星火的智能体应用和豆包的智能体场景里，多数日常任务单个就能拿下，真要多角色协作时，工具接入方式的统一性也得跟着考虑，见MCP 和函数调用差在哪？两种接入方式；与界面自动化方案混搭的取舍，见Agent 和传统 RPA 差在哪？；动手操作走浏览器还是接口，见浏览器操作和 API 调用差在哪？。
多智能体的沟通设计再展开一点：消息要带「为什么」而不只是「是什么」。只发结果，接收方缺上下文，容易误解；带上关键前提和约束，下游才能接得住，这也是人类协作的经验，只是机器之间更要写明，因为它们不会追问。失败隔离也要提前设计：一个协作方反复失败时，别让它拖垮整条链路，及时把它摘出去，让其余部分先跑完，失败的块单独补。升级到多智能体后，评测也要跟着变：除了整体完成率，还要看每个角色的贡献是否符合预期，某个角色长期没产出就是架构信号。
关于单多Agent再多问三句
- 多个智能体谁来当负责人？：通常设一个协调方负责分发与汇总，其余按工种分设，避免全员互聊。
- 它们之间怎么传递信息？：靠结构化消息或共享存储，传递时要带上下文摘要，光发结果对方接不住。
- 拆得越细越好吗？：不是，每多一个协作方就多一层沟通损耗，拆到能并行就停，别追求形式上的团队。
