多智能体何时胜过单体模型?

多智能体什么时候真比单体模型好用？这个问题听起来像站队，其实更像在问：你的任务，到底是“一个人想清楚就行”，还是“一群人得互相盯着才不翻车”。

单体模型的强项很直白：路径短、调用简单，一次把话说圆。问它解释概念、改一段文案、给个初步方案，往往干脆利落。可一旦事情拉成长链路——先规划、再执行、再核对、还要反复改——它就容易失焦。上下文越堆越满，角色在脑子里互相打架，前面埋下的小错也会一路被放大。这时候比的就不是“单次作答漂不漂亮”，而是错误能不能被拦住、责任能不能追得上。

多智能体换的是组织方式。有人拆目标，有人检索或写代码，有人专门挑刺，有人做汇总和止损。它们靠消息、共享状态或编排流程交接，而不是把所有职责塞进同一次长推理。你可以把它想成可复盘的项目组：高手单干赢在爆发力，项目组赢在分工清晰、信息可追踪、失败能局部回退。

那什么时候多智能体更值得上？粗看有几类信号。任务横跨多个互相冲突的目标，比如既要正确又要合规、既要快又要可解释；中间结果需要可验证，比如测试过不过、构建成不成功、检查有没有报警；以及流程本身允许分支、并行、评审回流，而不是一条流水线走到黑。自动化软件工程很典型：需求澄清、实现、测试、缺陷修复可以拆开，哪里坏了回哪里，不必整单推倒。研究分析、工业现场的排程与质检，也常靠“检索—归纳—质疑—结论”这类制衡，降低一本正经漏掉关键前提的概率。

反过来，也别神话。短问答、边界清楚、一次生成就够用的场景，硬上多角色，多半只是更贵的扯皮。没有清晰目标、失败回放和边界约束，竞争与协作不会自动变成进化，只会放大噪声。并行一多，还会出现资源争用、意见互相打架、性能不升反降。更务实的做法往往是：先收窄并行宽度，明确谁能改系统状态、哪里必须人工确认，再谈加角色。

筛选市面上的“多 Agent 工作流”，不妨问三句。角色是不是对应真实技能边界，而不是换皮同款提示词？中间有没有可验证产物，而不只是自然语言互夸？有没有竞争、回退和止损，而不是一条道走到黑？若你正在试，不必先堆庞大集群；写、测、审这样一个能闭环的小团队，常常比一上来十几个角色更接近“在反馈里变强”，而不是在热闹里变散。