多智能体不是单智能体的自然升级。增加角色可能提高专业分工，也会增加协调、成本和错误传播。
一、先看任务，而不是角色数量
如果任务可以由一套知识、工具和权限完成，单智能体通常更容易开发、测试和治理。只有当任务包含明显不同的专业职责或需要相互校验时，多智能体才可能带来价值。
把一个简单流程拆成多个角色，往往只是把代码复杂度转移为对话复杂度。
二、单智能体的优势与边界
单智能体上下文集中、状态清晰、调用链较短，适合个人助手、专业查询和边界明确的任务办理。
当工具过多、任务跨度过大或不同职责存在权限隔离时，单一上下文可能变得臃肿，并增加工具选择错误。
三、多智能体的三种常见模式
第一种是主管—执行者模式，由主管分解任务并汇总结果；第二种是专家协作模式，不同智能体负责数据、技术或业务分析；第三种是生成—评审模式，一个智能体产出，另一个检查。
无论采用哪种模式，都要明确任务分派、共享信息、结束条件和冲突处理。
四、多智能体增加的新风险
智能体之间传递的信息可能丢失或被误解，局部错误也可能在协作链中放大。更多模型调用还会增加延迟和成本。
权限设计尤其重要。不同角色不应因为协作而自动获得彼此全部权限。
五、一个实用的选择顺序
企业可以先尝试确定性工作流，再使用单智能体处理不确定环节；只有在专业分工、并行处理或独立评审确有必要时，再引入多智能体。
好的架构选择不是角色最多，而是在可控复杂度下稳定完成任务。
先判断任务能否由一个上下文完成
如果任务目标明确、工具数量有限、执行链路较短，一个智能体通常更容易控制。上下文集中，调试和审计也更直接。只有当任务包含明显不同的专业角色、可以并行处理的子任务，或需要相互复核时，多智能体才可能带来价值。
多智能体增加的不只是能力，还有协调成本
多个智能体需要传递任务、共享必要信息、处理结果冲突，并确定由谁形成最终结论。角色划分不清时，可能出现重复工作、相互等待和错误传播。智能体越多，运行时间、模型调用成本和审计复杂度也会增加。
企业可以用四个问题作出选择
第一，子任务是否需要不同专业知识或不同工具权限；第二，子任务是否可以并行；第三，结果是否需要独立复核；第四，协调收益是否明显高于新增复杂度。如果只有“让不同角色分别说一遍”的需求，并不一定需要真正的多智能体架构。
更稳妥的建设顺序
先用一个智能体完成端到端闭环，识别真正的瓶颈；再把知识检索、数据分析、合规复核等边界清晰的部分拆分为专业角色；最后建立统一的任务状态、消息格式和冲突处理规则。分工应来自任务结构，而不是来自技术展示需要。