多智能体协作真正有用的时候，通常不是因为模型需要更多人格，而是因为任务天然存在分工、冲突检查、并行探索、专业边界或风险复核。一个智能体能稳定完成的任务，不必拆成多个智能体。固定流程能解决的任务，不必伪装成开放协作。只有当单一智能体在视角、工具、权限、上下文或验收上明显不足时，多智能体才值得引入。

这篇文章讨论一个务实问题：多智能体协作什么时候有用，什么时候没有用。我们把协作拆成四个核心场景：讨论、评审、执行和防内耗。讨论用于探索方案，评审用于发现错误，执行用于把复杂任务拆到不同能力边界，防内耗用于控制成本、循环和责任不清。目标不是追求“看起来很多AI在工作”，而是让AI系统在真实任务里更可靠、更可控、更能交付。

一、多智能体不是更高级的默认形态

很多团队一开始做Agent，就想做多智能体。原因很容易理解：现实中的人类团队就是分工协作，软件开发有产品、架构、开发、测试、运维，内容生产有策划、资料、作者、编辑、审校，企业流程有申请、审批、执行、复核。把这些角色映射成多个智能体，看起来符合组织经验，也更容易做出复杂演示。

但大模型智能体不是人。人类团队里的角色拥有长期记忆、组织责任、专业训练、真实权限和社会约束；智能体角色通常只是Prompt、工具集合、上下文窗口和一段调度逻辑。给模型起名为“架构师”“审计员”“执行官”，并不会自动产生可靠专业分工。如果每个智能体背后都是同一个模型、同一批资料、同样的错误倾向，只是换了口吻，多智能体可能只是把同一种偏差重复多次。

Anthropic在讨论有效Agent时区分了workflow和agent：路径清楚、步骤固定的任务，工作流通常更可靠；路径开放、需要动态决策的任务，才更适合Agent。这个判断也适用于多智能体。很多任务看起来复杂，其实只是固定流水线：抽取字段、检索资料、生成摘要、格式校验、发送通知。这样的任务更适合单Agent加工具，或者确定性流程加模型节点，而不是让多个智能体自由聊天。

多智能体的成本也是真实的。每个智能体都需要上下文、指令、工具说明和状态同步；每轮交互都会增加token、延迟和失败概率；不同智能体之间的结论可能冲突，需要仲裁；工具权限如果分配不清，可能出现越权或重复操作；评审智能体如果没有独立证据，只会把执行智能体的话换一种方式赞同。协作不是免费增强，而是系统复杂度投资。

所以，多智能体设计的第一原则是：先证明单智能体或确定性流程不够，再引入协作。不是为了架构好看，也不是为了让日志热闹。判断标准很具体：是否需要多个视角减少盲点？是否需要独立评审降低风险？是否需要并行搜索缩短时间？是否需要不同工具权限隔离？是否需要专业子任务分别优化？如果答案都是否定的，多智能体大概率会变成内耗。

二、什么时候讨论有用：开放问题、方案分歧和未知空间

讨论型多智能体适合开放问题。比如新产品方案、架构选型、竞品研究、教学设计、复杂故障排查、法律风险初筛、市场进入策略。这类任务没有唯一标准答案，早期需要探索多种可能。一个智能体容易沿着第一条看起来合理的路线继续展开，多智能体讨论可以故意制造不同视角，让系统不那么早收敛。

讨论有用的前提是角色差异真实。不是“甲专家”“乙专家”轮流说泛泛观点，而是角色代表不同目标函数。产品视角关心用户价值和采用门槛，工程视角关心可实现性和维护成本，安全视角关心权限、数据和滥用风险，运营视角关心流程落地和反馈机制。不同角色必须有不同评判标准，否则讨论只会变成重复表达。

讨论还要有明确问题。比如“我们要不要上多智能体？”太空；“客服知识库问答是否需要增加独立事实核查Agent？”就具体得多。后者可以讨论证据来源、错误类型、延迟预算、核查成本、人工兜底和上线指标。问题越清楚，讨论越容易产出决策。多智能体不是头脑风暴聊天室，而是结构化争议生成器。

讨论型协作最适合在方案阶段使用，不适合无限延伸到执行阶段。早期让多个智能体提出选项、识别风险、列出假设很有价值；一旦路线确定，就应该收敛到负责人和执行计划。很多多智能体系统烂尾，是因为讨论没有结束条件。每个智能体都还能补充一点，每个风险都还能展开一点，最后没有人负责把结论变成下一步。

讨论要产出可比较选项，而不是产出更长文字。一个好的讨论结果应该包含：候选方案、适用条件、收益、代价、风险、需要验证的假设、推荐结论和反对意见。没有这些结构，讨论只是更复杂的长回答。多智能体讨论的价值不是“多说”，而是把关键不确定性摊开，让决策者看见取舍。

多智能体讨论也要避免伪多样性。如果多个智能体使用同一模型、同一温度、同一资料和相似Prompt，它们很可能在同一类错误上达成共识。要提升讨论质量，可以给不同角色不同资料优先级、不同审查清单、不同工具权限和不同输出任务。比如一个只看用户反馈，一个只看技术限制，一个只看合规条款，一个只看成本模型。差异越真实，讨论越有意义。

三、什么时候评审有用：高风险输出和可验证错误

评审型多智能体是最值得优先采用的模式之一。原因很简单：生成和评审是两种不同任务。生成者容易维护自己的叙事，评审者可以专注找错、找漏、找不满足约束的地方。代码评审、合同审阅、医学或法律信息、财务分析、对外发布内容、工具执行计划，都适合引入独立评审智能体。

评审有用的前提是有标准。没有标准的评审，只会变成“我觉得还可以”。评审智能体需要明确检查维度：事实是否有依据，引用是否能打开，计算是否可复算，格式是否满足Schema，是否遗漏用户问题，是否有越权承诺，是否泄露内部信息，是否触发高风险动作，是否需要人工确认。标准越清楚，评审越像质量门，而不是第二个作者。

评审还必须独立。独立不是完全不知道上下文，而是不能只依赖生成者的自我陈述。评审智能体应该能访问原始输入、资料来源、工具结果、代码diff、测试日志或业务记录。否则它只能评审语言是否顺滑，不能评审事实是否成立。一个执行智能体说“测试已通过”，评审智能体应该看测试输出，而不是相信这句话。

评审型协作特别适合“可验证错误”。代码是否通过测试、引用是否存在、金额是否相加正确、表格字段是否缺失、审批是否需要确认，这些都可以被查证。越能查证，评审越有价值。反过来，如果任务只是主观创意，比如广告标题风格，多个评审智能体可能会给出一堆互相冲突的偏好，增加噪音。

评审结果要能阻断流程。很多系统把评审智能体当装饰：它说有风险，执行还是继续；它说引用不足，最终答案还是输出。真正有用的评审应该连接到流程控制：通过、要求修订、请求人工确认、禁止执行。尤其是带副作用的工具操作，评审不通过就不能提交。

评审也有成本边界。低风险、低价值、可逆的任务，不一定需要多智能体评审。比如内部草稿润色、个人笔记摘要、简单格式转换，用单Agent自检或程序校验就够。评审智能体应优先用于高风险、高曝光、高成本错误场景。多智能体协作要把算力花在风险最高的地方。

四、什么时候执行有用：任务能拆成真实子责任

执行型多智能体适合复杂任务，但前提是任务能拆成真实子责任。真实子责任不是“你负责想，你负责写，你负责鼓励”，而是输入、工具、权限、输出和验收都不同。比如研究任务可以拆成资料搜集Agent、证据整理Agent、写作Agent和事实核查Agent；软件任务可以拆成定位Agent、修改Agent、测试Agent和评审Agent；业务流程可以拆成资料收集Agent、表单准备Agent、审批确认Agent和执行Agent。

子责任要有清晰交付物。资料搜集Agent交付来源列表和摘要，不交付最终结论；写作Agent交付正文，不擅自新增未经核验事实；测试Agent交付命令、结果和失败原因，不修改业务代码；审批Agent交付是否满足提交条件，不替用户点击不可逆操作。每个智能体都应该有自己的输入输出契约，否则协作会变成互相甩上下文。

执行型协作适合并行化。比如调研十个资料源，可以让多个检索Agent并行查不同来源；代码迁移可以让不同Agent检查不同模块；大文档审查可以让不同Agent负责事实、结构、合规和语言。并行的收益是时间和覆盖面。但并行之后必须有汇总和去重，否则最终结果会重复、冲突和层级混乱。

执行型协作也适合权限隔离。不是所有智能体都应该拥有所有工具。规划Agent可以只读，执行Agent可以写入，评审Agent可以读日志和diff但不能提交，发布Agent必须等待用户确认。权限隔离能减少模型误操作的伤害，也能让审计更清楚。把所有工具给所有智能体，再靠Prompt要求它们克制，不是生产级设计。

执行协作的难点是状态同步。一个Agent修改文件后，另一个Agent必须知道当前版本；一个Agent检索到新证据后，写作Agent必须知道证据可信度和限制；一个Agent执行失败后，规划Agent必须更新计划。LangGraph这类框架强调状态图、持久化和中断恢复，正是因为长任务不能只靠对话历史维持状态。多智能体越多，状态越要结构化。

执行型协作还需要仲裁机制。当两个Agent给出不同结论，谁说了算？可以由主管Agent仲裁，可以由评分器仲裁，可以由程序规则仲裁，也可以交给用户。关键是不能让冲突自然漂浮在最终回答里。用户需要的是结论和依据，不是看一群智能体各说各话。

五、什么时候多智能体没用：简单任务、假角色和无验收

多智能体在简单任务中常常没用。比如“把这段话改得更自然”“提取下面文本里的日期”“把JSON格式化”“解释一个概念”。这类任务输入明确、输出短、风险低，一个模型就能完成。拆成规划、执行、评审三层，只会增加延迟和成本。系统设计应该尊重任务复杂度，简单任务就走简单路径。

假角色也没用。所谓假角色，是多个智能体没有独立资料、没有不同工具、没有不同标准，只是被Prompt要求“扮演不同专家”。它们产生的分歧往往是随机措辞，产生的一致也不是可靠共识。多智能体要有真实差异：不同任务、不同信息、不同约束、不同权限、不同验收点。没有真实差异，角色越多越像戏剧，不像工程。

无验收的多智能体没用。几个智能体讨论很久，最后没有程序检查、没有证据引用、没有测试结果、没有用户确认，这并不会比单Agent更可靠。协作必须落到可验证结果：文件是否生成，测试是否通过，引用是否有效，风险是否关闭，用户动作是否完成。没有验收，多智能体只是把“不确定”包装得更热闹。

无状态的多智能体也很危险。每个智能体都只看一段对话摘要，容易丢失关键条件；一个Agent以为已经确认，另一个Agent不知道；一个Agent用旧资料，另一个Agent用新资料；最终汇总者又把冲突混在一起。多智能体系统必须把任务状态、资料版本、工具结果和决策记录保存下来。否则协作规模越大，漂移越严重。

另一个常见无效场景是“让模型互相说服”。多轮辩论有研究价值，也可能在某些推理任务中提高结果，但在生产里不能盲目使用。模型会被措辞、顺序和自信程度影响，未必因为事实而改变。辩论如果没有外部证据、没有评分标准、没有结束条件，就会增加成本并制造虚假的严谨感。

还有一种无效场景是“主管Agent万能调度”。很多架构图中间有一个Supervisor，周围挂满专业Agent。这个结构可以用，但主管不能只靠自然语言判断一切。它需要路由规则、任务状态、工具元数据、失败处理和人工介入条件。否则主管Agent自己也会迷路：该交给谁、何时停止、如何处理冲突、如何判断完成，都变成新的不确定性。

六、讨论模式：从发散到收敛

讨论模式适合解决“我们有哪些选择”而不是“请直接执行”。一个好的讨论流程通常分四步。第一步，明确问题和决策标准。第二步，不同角色分别给出方案和风险。第三步，互相质询关键假设。第四步，由汇总者形成推荐结论、保留意见和验证计划。没有第四步，讨论就不会收敛。

讨论角色要少而精。两个到四个通常足够。角色过多会导致每轮信息稀释，汇总压力增大。比如一个AI知识库产品方案，可以设产品Agent、工程Agent、数据Agent和风险Agent。产品Agent回答用户价值，工程Agent回答实现路径，数据Agent回答资料质量和评测，风险Agent回答误导和权限。每个角色都围绕自己的标准发言。

讨论不应该重复完整上下文。每个Agent拿到自己需要的摘要和证据即可，最终由汇总者拿完整状态。否则所有Agent都读同样材料、说同样内容，成本会飙升。上下文分配本身就是系统设计的一部分。多智能体协作不是让每个Agent都知道全部，而是让每个Agent知道自己负责判断的部分。

讨论要产出决策材料。比如用“方案A、方案B、方案C”的方式列出收益、成本、风险、适用条件和验证方式。不要把每个Agent的原话都贴出来。最终用户不需要看内部争论过程，需要看经过整理的结果。生产级UI和内容交付也应避免出现“某某Agent认为”这种开发者视角文案，除非产品本身就是面向调试。

讨论还要设置时间或轮次限制。比如每个角色一轮提案、一轮质疑、一轮回应，然后必须收敛。开放讨论如果没有上限，很容易变成循环。智能体总能找到新角度，但业务需要在有限信息下决策。多智能体系统必须承认“足够好”的完成条件。

讨论模式最重要的指标，不是生成多少观点，而是后续决策是否更稳。可以用这些问题评估：是否发现了单Agent漏掉的关键风险？是否提出了不同可行方案？是否减少了错误假设？是否让人工决策更快？如果讨论只增加篇幅，没有增加决策质量，就应该缩减。

七、评审模式：把独立检查做成质量门

评审模式可以设计成生成者和评审者分离。生成者负责完成任务，评审者负责按清单检查。比如写作任务中，作者Agent负责正文，事实核查Agent检查来源和断言，编辑Agent检查结构和重复，发布Agent检查面向用户的表达。代码任务中，修改Agent负责补丁，测试Agent运行命令，审查Agent检查风险和无关改动。

评审清单要和任务风险匹配。技术长文要查事实、来源、重复段落、标题层级和读者可读性；客服回复要查政策依据、承诺边界、情绪安抚和下一步；代码变更要查复现、测试、影响范围、安全和兼容；数据报告要查口径、公式、异常值和图表解释。评审智能体不应该泛泛说“更清晰一点”，而应该指出具体失败点。

评审输出要短而可执行。最好是通过、阻断、建议改进三类。阻断项必须有证据，建议项不能混进阻断项。否则执行者不知道哪些必须改，哪些只是偏好。评审型多智能体最怕“意见很多但没有优先级”。优先级不清会拖慢交付。

评审可以结合程序工具。代码评审要跑测试，文档评审可以统计字数和重复，引用评审可以检查URL，结构评审可以解析Markdown标题，数据评审可以重新计算。模型适合判断语义和风险，程序适合硬检查。把两者结合，比让多个模型互相点评更可靠。

评审要保留失败记录。每次评审发现的问题，都应该归类：事实错误、证据缺失、结构混乱、约束违反、格式错误、权限风险、工具失败。长期看，这些记录能反向改进生成Prompt、工具设计和任务边界。多智能体协作不只是当次提高质量，也应该积累可复用的质量知识。

评审也要防止过度保守。评审Agent如果被要求“找尽可能多问题”，可能会把正常取舍也当错误。对于开放内容，评审标准要区分事实错误、重要遗漏、表达建议和个人偏好。只有前两者应该阻断，后两者可以作为建议。生产流程不能让评审无限扩大权力。

八、执行模式：让每个智能体拥有清楚工作面

执行模式的关键是任务契约。每个智能体接收什么输入，允许什么动作，必须产出什么，失败时怎么报告，都要清楚。比如检索Agent的契约可以是：根据查询找到权威来源，输出标题、链接、发布时间、核心结论和可信度说明；不得写最终观点。写作Agent的契约可以是：只使用资料表中的信息写正文，缺证据处留空或标注无法判断；不得新增来源。核查Agent的契约可以是：逐条检查正文断言是否能回溯到资料。

执行模式要避免“上下文倾倒”。把所有资料都发给所有Agent，会浪费成本，也会增加干扰。检索Agent需要搜索目标和来源标准；写作Agent需要经过筛选的资料；核查Agent需要正文和资料映射；发布Agent需要最终版本和发布规则。不同工作面需要不同上下文。上下文越精准，模型越容易稳定执行。

执行模式里的工具要按角色分配。检索Agent有浏览器和搜索工具，写作Agent可能没有外网工具，测试Agent有命令执行工具，发布Agent有提交或发送工具但需要确认。工具分配不是为了麻烦，而是为了减少错误半径。如果写作Agent能随意搜索，它可能引入未经筛选的新信息；如果评审Agent能修改结果，它可能悄悄改变作者意图。

执行模式还需要汇总器。多个子任务输出后，必须有人去重、合并、排序、解决冲突。汇总器不是简单拼接器。它要知道最终用户目标，保留可靠结论，丢弃重复内容，标记冲突和不确定性。没有汇总器，多智能体输出常见问题是重复段落、风格不一、结论冲突和信息层级混乱。

执行模式的完成条件要外部化。不要让执行Agent自己说完成就完成。检索完成要看来源数量和质量，写作完成要看字数、结构和引用，代码完成要看测试，业务操作完成要看系统返回状态。完成条件可以由程序、评审Agent或人工共同判断。多智能体执行最怕每个Agent都说“我这边好了”，但整体任务没有完成。

执行模式还要支持恢复。长任务中某个Agent失败，不应该让整个任务从头开始。状态图、检查点、可重试步骤和失败报告很重要。比如资料检索失败可以换来源，写作失败可以保留大纲重写，测试失败可以回到修改Agent，发布失败可以保留草稿等待确认。没有恢复机制，多智能体越复杂，失败体验越差。

九、防内耗：控制循环、冲突和成本

多智能体内耗最常见的形态是循环。规划Agent交给执行Agent，执行Agent提出问题，规划Agent重新规划，评审Agent又要求补充，执行Agent再回去查，最后任务一直不结束。循环不一定是坏事，修复失败需要迭代；但循环必须有上限、目标和退出条件。比如最多两次修订，连续失败则报告阻塞；同一工具错误不得重复三次；信息不足必须追问用户。

第二种内耗是冲突不解决。一个Agent认为可以上线，另一个Agent认为风险高，汇总者把两边都写进最终回答，让用户自己判断。这不是协作，是转嫁责任。系统必须有冲突处理规则：硬约束优先于偏好，证据充分优先于主观判断，高风险评审优先于执行者自评，人工确认优先于自动动作。规则越早定义，协作越少扯皮。

第三种内耗是重复劳动。多个Agent都去查同一资料、都写同一部分、都检查同一格式。重复有时可以用于独立验证，但必须有目的。没有目的的重复只是浪费。可以通过任务分片、共享资料库、结果缓存和清晰职责减少重复。需要独立验证时，也要让两个Agent使用不同方法或不同来源，而不是重复同一路径。

第四种内耗是成本失控。多智能体系统的token和延迟增长很快。每个角色都读完整上下文、每轮都输出长篇解释、每个步骤都评审，会让产品不可用。成本控制要从设计阶段开始：简单任务走快速路径，复杂任务才走协作路径；低风险任务不强制评审；摘要替代全量上下文；工具结果结构化；历史状态定期压缩；日志不进入用户界面。

第五种内耗是责任不清。用户最终看到错误结果时，到底是规划错、执行错、评审漏、工具错还是资料错？如果系统没有记录每个智能体的输入输出和工具调用，就无法定位。多智能体系统必须可审计。审计不是把所有内部对话展示给用户，而是在后台记录足够信息，方便团队改进和追责。

防内耗还有一个产品原则：不要把多智能体过程直接展示成最终体验。最终用户通常不关心几个Agent如何开会，他们关心结果是否可靠、下一步是什么、风险在哪里。除非用户明确需要调试视图，否则界面应该呈现清晰结论、依据、状态和行动按钮，而不是内部角色聊天记录。多智能体是实现方式，不应污染用户表达。

十、常见架构：主管、网络、层级和流水线

多智能体架构常见有四类：主管式、网络式、层级式和流水线式。主管式由一个Supervisor接收任务、分配给子Agent、汇总结果。它适合任务类型较多、需要路由和仲裁的场景。缺点是主管容易成为瓶颈，也可能因为上下文不足做错分配。主管必须有明确路由规则、状态视图和停止条件。

网络式让多个Agent互相交接，谁有能力谁继续。它适合开放探索和协作研究，但风险是对话路径难控，容易循环。网络式需要强状态管理和消息约束，否则每个Agent都可能把任务推给别人。LangGraph文档中提到多智能体可以通过supervisor、handoff等方式组织，本质上就是在控制谁拥有当前任务和下一步。

层级式适合大任务。高层Agent负责目标分解，中层Agent负责子任务管理，底层Agent负责工具执行。它像组织结构，适合复杂工程、内容生产和运维流程。缺点是层级越深，信息损耗越大。每一层都可能摘要错误、遗漏条件或扩大解释。因此层级式要有关键证据回溯机制，不能只传自然语言总结。

流水线式是最稳定的一类。任务按固定阶段流转，例如检索、抽取、生成、评审、修订、发布。每一阶段可以由一个智能体或模型节点负责，也可以混合程序工具。流水线不如开放多Agent灵活，但在生产里常常更可靠。很多看起来需要多智能体的任务，其实适合流水线加少量条件分支。

架构选择应从任务出发。客服问答通常适合检索加回答加核查流水线；复杂咨询适合讨论后收敛；代码修复适合执行加测试加评审闭环；企业流程适合主管式路由加权限隔离；开放研究适合网络式探索但必须有收敛器。不要先画多Agent架构图，再把任务硬塞进去。

架构还要考虑人机协同。多智能体不是把人完全排除。高风险动作、价值判断、资料缺失、权限变更、外部发布，都可能需要人工确认。系统应该知道何时停下来问人，而不是让Agent互相讨论到假装确定。人类介入点设计得好，多智能体反而更可靠。

十一、工程落地：从最小协作闭环开始

落地多智能体，不建议一上来做完整“AI公司”。更稳的方式是从最小协作闭环开始：一个执行Agent，一个评审Agent，一个明确验收。比如文档生成场景，先让作者Agent写，审校Agent查事实和重复，程序统计字数和引用，失败则回到作者修订。这个闭环能跑稳，再扩展检索Agent、结构Agent或发布Agent。

落地时要先定义状态对象。任务ID、当前阶段、输入资料、子任务状态、工具结果、文件版本、用户确认、失败原因、最终输出，都应该结构化。不要让多个Agent只靠聊天历史协作。状态对象越清楚，恢复、评审、审计和成本控制越容易。

第二步是定义消息协议。Agent之间传递的不是随意长文，而是结构化结果：目标、已完成、证据、开放问题、阻塞、建议下一步。自然语言可以存在，但关键字段要稳定。否则下游Agent要从上游散文里猜重点，错误会层层放大。

第三步是定义工具权限。每个Agent能用哪些工具，工具是只读还是写入，是否需要确认，失败如何处理，结果如何记录，都要明确。工具权限应该由系统强制，不只写在Prompt里。尤其是生产业务里，删除、提交、发送、支付、发布、审批都必须有硬边界。

第四步是定义质量门。哪些任务必须评审，哪些错误会阻断，哪些错误允许自动修复，哪些情况必须问用户。质量门应该和任务风险匹配。不要让所有任务都走最重流程，也不要让高风险任务一路自动通过。风险分级是多智能体系统能否可用的关键。

第五步是做真实评测。用真实用户问题、真实资料、真实工具和真实失败情况测试。不要只看演示对话。评测指标可以包括任务完成率、人工介入率、平均轮次、平均成本、阻断准确率、误报率、重复率、用户可采纳率。多智能体是否有用，最终要看这些指标，而不是看架构是否先进。

落地还要保持可替换。今天一个子任务用Agent，明天可能发现程序规则更稳；今天用主管式路由，明天可能改成固定流水线；今天用两个评审维度，明天可能合并。多智能体架构不要绑死业务。生产系统要允许根据数据收缩，而不是越做越复杂。

十二、判断清单：什么时候该用多智能体

可以用一组问题判断是否值得引入多智能体。第一，任务是否有天然分工？如果没有，先用单Agent。第二，子任务是否需要不同工具、资料或权限？如果没有，角色差异可能是假的。第三，是否存在高风险输出需要独立评审？如果有，评审Agent很可能值得。第四，是否能并行探索并明显节省时间？如果不能，并行协作收益有限。

第五，是否有清晰验收标准？没有验收，多智能体只会增加话语量。第六，是否有状态管理和失败恢复？没有状态，长任务会漂移。第七，是否有冲突仲裁规则？没有仲裁，分歧会被推给用户。第八，是否有成本预算？没有预算，协作很容易不可持续。第九，是否能从协作中记录可复用经验？如果不能，系统每次都从零开始讨论。

如果这些问题大多回答不上来，就不要急着上多智能体。可以先做单Agent加工具，加一个评审步骤，再加程序验收。很多生产场景在这个阶段已经足够。多智能体不是成熟度的象征，可靠交付才是。

如果这些问题答案清楚，多智能体会很有价值。它能让开放问题获得多视角，让高风险输出经过独立检查，让复杂任务按责任边界执行，让工具权限更可控，让长任务更容易恢复。它把模型从“一个会说话的助手”扩展成“一组受控协作的工作单元”。前提是系统知道每个工作单元为什么存在。

多智能体协作最好的形态，是用户感受不到混乱。用户看到的是清晰结论、可靠依据、必要确认和可执行下一步；后台则有分工、评审、状态和审计。协作不是表演，而是质量机制。什么时候它能提高质量，就用；什么时候它只增加内耗，就删掉。

十三、场景示例：知识库、代码、内容和业务流程

把原则放进具体场景，会更容易判断多智能体是否值得。第一个典型场景是企业知识库问答。用户问一个制度问题，系统先检索资料，再生成回答，再做事实核查。这里不一定需要很多智能体，但至少可以拆成回答者和核查者。回答者负责把资料转成用户能理解的结论，核查者负责检查每个关键断言是否有资料支撑，资料冲突时要求回答者说明冲突。这个协作有明确收益，因为知识库问答的主要风险就是“说得像真的但没有依据”。

知识库场景中，多智能体不应该表现成几个角色在前台聊天。用户不需要看“检索员认为”“审核员认为”。用户需要的是：根据哪些资料，可以得到什么结论；哪些问题资料没有覆盖；下一步应该找谁或做什么。后台协作越复杂，前台越要简洁。否则用户会把系统内部过程误解成结论本身。

第二个场景是代码修改。单Agent可以读代码、改代码、跑测试，但容易在修改范围和验收上出问题。更稳的协作是：定位Agent负责复现和根因，修改Agent负责最小补丁，测试Agent负责运行相关命令，评审Agent负责检查无关改动和回归风险。每个Agent不必都是完全独立模型，也可以是同一模型在不同任务契约下运行。关键是生成、执行和评审分开。

代码场景中，评审Agent必须看真实diff和测试结果，不能只听修改Agent总结。它要回答：问题是否真的被复现？改动是否只触及必要文件？测试是否覆盖失败路径？是否引入硬编码、权限绕过或兼容问题？如果评审发现阻断项，流程应该回到修改，而不是把风险写进最终说明后继续合并。多智能体的价值在于质量门，而不是多几段工程解释。

第三个场景是内容生产。长文、报告、白皮书和课程材料常常需要资料搜集、结构设计、正文写作、事实核查、编辑润色。多智能体在这里有用，因为各阶段目标不同。资料Agent追求来源质量和覆盖面，结构Agent追求论证顺序，作者Agent追求表达完整，核查Agent追求事实可回溯，编辑Agent追求重复减少和读者体验。它们的工作面不同，协作可以减少遗漏。

内容场景也很容易内耗。最常见问题是每个Agent都想重写全文，导致风格反复变化；或者评审Agent提出大量审美建议，让正文越改越散。解决办法是定义权限：核查Agent只指出事实问题，编辑Agent只改结构和重复，作者Agent负责最终统一表达。建议要分级，事实错误必须改，表达建议可选择。否则内容协作会从提高质量变成无限润色。

第四个场景是业务流程自动化。比如员工报销、采购申请、客户跟进、合同流转、售后处理。这里多智能体有用的原因不是讨论，而是权限和阶段。资料收集Agent可以帮助用户补齐信息，规则Agent检查是否符合政策，审批准备Agent生成申请材料，执行Agent在用户确认后提交系统，复核Agent检查提交状态。不同阶段有不同权限，不能让一个自由Agent从咨询一路自动提交。

业务流程场景最需要防止副作用。任何创建、发送、提交、取消、删除、支付、审批动作都应有确认和记录。多智能体可以把“建议”和“执行”隔离：建议Agent没有写权限，执行Agent只能在确认后调用工具，复核Agent读取结果但不能重复提交。这样即使建议有误，也不至于直接造成真实损失。

第五个场景是复杂研究和决策支持。比如技术选型、市场进入、供应商比较、AI模型选择。讨论型多智能体可以让不同角色提出互相冲突的目标：成本、性能、安全、可维护性、合规、用户体验。这里的价值是暴露取舍，而不是生成唯一答案。最终仍需要汇总者给出推荐和条件：如果预算优先，选什么；如果合规优先，选什么；如果上线时间优先，选什么。

这些场景说明，同样叫多智能体，实际目的完全不同。知识库重在核查，代码重在质量门，内容重在分阶段生产，业务流程重在权限隔离，研究决策重在多视角讨论。不能用同一套角色聊天模板解决所有问题。先识别主要风险，再设计协作结构，才是可落地路径。

十四、产品体验：用户看结果，系统管协作

多智能体系统容易犯一个产品错误：把后台协作过程当成卖点展示给用户。界面上出现多个AI头像、长篇角色对话、工具日志、内部状态、调度说明，看起来很透明，实际会增加理解负担。大多数最终用户不需要知道有几个智能体参与，他们只需要知道结果是否可信、依据是什么、接下来能做什么。

面向用户的表达应该统一。即使后台有多个Agent，最终输出也应该像一个专业团队给出的整理结果，而不是会议纪要。可以展示“结论”“依据”“风险”“下一步”“需要确认”，但不要展示“规划Agent说”“执行Agent说”“评审Agent反对”。内部角色名是实现细节，不是用户语言。

状态展示也要面向任务，而不是面向模型。用户关心“正在检索资料”“正在检查引用”“等待你确认提交”“测试未通过”，不关心“Agent A调用工具B返回JSON”。同样，错误提示应该说明用户能理解的原因：资料不足、权限不够、系统暂时不可用、需要补充字段、存在冲突。不要把栈信息、接口名、参数名、模型内部判断暴露给最终用户。

多智能体产品还要让用户能控制关键节点。讨论阶段可以让用户选择方案，执行前可以让用户确认动作，评审失败时可以让用户查看阻断原因，资料不足时可以让用户补充。用户控制点越清楚，系统越可信。相反，如果多个Agent在后台自动决定一切，用户只看到最终结果，就很难建立责任边界。

对团队内部工具，适度展示协作过程有价值。工程师可能需要看工具调用、状态图和评审日志；运营可能需要看失败原因和人工介入点；产品经理可能需要看任务完成率和成本。关键是区分调试视图和最终用户视图。调试信息属于后台，不应该混进正式回答。

多智能体体验还要避免“等待无反馈”。协作会增加耗时，如果用户只看到加载动画，会觉得系统卡住。更好的方式是展示阶段状态，但文字要克制：查找资料、整理答案、检查风险、准备结果。不要展示模型内部思考，也不要每一步都输出长解释。阶段状态帮助用户理解进度，最终结果负责交付价值。

最后，多智能体不应该成为复杂度借口。用户不会因为后台有五个Agent就原谅错误答案、重复内容或慢响应。产品体验的评判标准仍然是任务完成质量。协作只有在用户结果更好时才值得存在。

十五、组织方式：让多智能体像团队，不像群聊

多智能体系统如果要长期运行，需要像团队一样有职责、交接、验收和复盘，而不是像群聊一样谁都能说两句。每个智能体都应有稳定职责，不随任务临时漂移。一个负责检索的智能体，不应突然写最终结论；一个负责评审的智能体，不应擅自执行修改；一个负责发布的智能体，不应越过确认。

交接物要标准化。人类团队协作时会用需求文档、设计稿、代码diff、测试报告、审批单；智能体也需要类似结构。上游不要把散乱对话扔给下游，而要交付结构化结果：已完成事项、证据、未解决问题、建议下一步、风险等级。交接物越稳定，协作越不依赖模型临场理解。

验收权要明确。谁能宣布任务完成？是主管Agent、程序检查、评审Agent、用户，还是外部系统状态？不同任务答案不同。代码任务可能以测试和评审通过为准；业务提交以系统返回成功编号为准；内容任务以编辑和事实核查通过为准；高风险动作以用户确认和系统结果为准。没有验收权，多智能体会出现每个角色都完成但整体无人负责。

复盘机制同样重要。每次失败都应该记录：哪个阶段失败，失败原因是什么，是否可自动修复，是否需要改Prompt、工具、资料或权限。多智能体系统会产生更多日志，如果不复盘，只会堆积噪音。把失败转成模式库、评审清单和工具改进，协作系统才会越用越稳。

组织方式还要允许裁撤角色。某个Agent长期没有发现独立问题，或者输出总被其他步骤覆盖，就应该删除或合并。多智能体不是角色越多越成熟。成熟系统会根据数据缩减无用环节，把复杂度留给真正有风险的地方。

从这个角度看，多智能体协作不是“AI开会”，而是任务系统。它需要分工、协议、权限、状态、验收、复盘。缺少这些，多个智能体只是在同一个不确定空间里互相放大不确定性；具备这些，它们才能像一个受控团队一样处理复杂工作。

参考资料

1. Anthropic Engineering: Building Effective Agents, https://www.anthropic.com/engineering/building-effective-agents
2. LangGraph Docs: Multi-Agent Systems, https://langchain-ai.github.io/langgraph/concepts/multi_agent/
3. OpenAI Agents SDK Docs: Agents, Handoffs, Guardrails and Tracing, https://openai.github.io/openai-agents-python/
4. Microsoft AutoGen Documentation, https://microsoft.github.io/autogen/
5. Microsoft AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation Framework, https://arxiv.org/abs/2308.08155
6. CrewAI Documentation, https://docs.crewai.com/
7. CAMEL: Communicative Agents for Mind Exploration of Large Language Model Society, https://arxiv.org/abs/2303.17760
8. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework, https://arxiv.org/abs/2308.00352
9. ChatDev: Communicative Agents for Software Development, https://arxiv.org/abs/2307.07924
10. Multi-Agent Debate Improves Reasoning in Large Language Models, https://arxiv.org/abs/2305.14325
11. ReAct: Synergizing Reasoning and Acting in Language Models, https://arxiv.org/abs/2210.03629
12. AgentBench: Evaluating LLMs as Agents, https://arxiv.org/abs/2308.03688
13. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, https://arxiv.org/abs/2310.06770
14. Voyager: An Open-Ended Embodied Agent with Large Language Models, https://arxiv.org/abs/2305.16291