误区一：复杂就多体
任务链长不等于要拆成多个角色。先看是不是流程没定义清楚：把步骤写成顺序表、给每步配一个工具，单 Agent 往往就能跑通。拆多体的真实理由是可并行、可隔离、可用不同模型，而非听起来更高级；拆完仍要共享同一份上下文来回传递，复杂度只会放大。边界是收益覆盖复杂度。
误区二：多体投票更准
让多个 Agent 各答一遍再投票，只在错误互相独立时有效；同一模型、同一提示词、同一份材料产生的错误高度相关，投票会把同一个错重复确认三遍。要提升准确率，应该换信息源、加检索或加人工复核，而不是增加副本数量。怎么判断错误是否独立，看同一份材料是否被重复确认。
误区三：并行一定更快
并行受三件事约束：子任务之间是否真的独立、工具是否允许并发写、结果合并能否自动完成。写同一张表、抢同一个接口额度时，并行会变成互相等待与覆盖。做之前先画依赖图，把共享资源的环节串起来，其余再并行。怎么落地，先画依赖图，再决定并行粒度。
误区四：维护更容易
多 Agent 是分布式系统：有消息协议、超时、重试、幂等与追踪。单 Agent 改一句提示词即可回归，多体改一个节点要重跑整条链路。团队没有日志与重放能力时，多体上线后的排障成本会超过它省下的开发时间，后来没人敢动。这条边界要求团队先有排障能力，再谈拆分。
误区五：分工自动生长
角色边界、输入输出格式、失败后谁接管，都必须人工定义并写进接口说明。指望模型自己协商分工，初期看似能跑，样本一换就散。判断方法很直接：如果团队画不出一张带字段的交接图，说明还没准备好做多 Agent，先补流程文档。怎么判断准备好了，看能否画出带字段的交接图。
适用与不适用
适合谁
- 任务可拆成异构子任务、接口清晰的团队
- 需要按数据权限隔离不同角色的业务场景
- 已有评测集与调用链追踪能力的团队
不适合谁
- 把多 Agent 当作提升准确率捷径的项目
- 没有日志与重放能力、排障靠猜的团队
典型场景
某制造企业的售后工单要同时查设备手册、查历史工单、判断是否在保。团队先做一个 Agent 串行调用三个检索工具，发现手册解析不准才是主要瓶颈；补好解析后单 Agent 已够用，只在需要并行核验时把手册核对拆成独立节点，交接字段写进接口说明，由售后主管复核签字。
可执行步骤
- 先写清任务的步骤顺序与每步的输入输出，把依赖关系画成一张图，标出共享资源
- 用单 Agent 加工具跑一版基线，记录失败类型、平均步数与人工接管的原因，作为对照起点
- 只把可并行、可隔离或需不同权限的环节拆成独立角色，其余保持串行，别为拆而拆
- 为每个交接点定义字段格式、超时时间与接管人，并写进接口说明文档由双方确认
- 用同一评测集对比拆分前后的通过率与排障耗时，连续观察两周再决定是否保留
常见坑
- 把流程混乱当成模型能力不足，先拆多 Agent，结果每个角色都在猜上游要什么，返工比原来更多。
- 多个 Agent 共用一份可写表格，又没有加锁与幂等，重复写入让数据对不上，排查要花好几天。
- 只用演示样例验证拆分效果，真实单据一多就超时，合并环节拿不到完整结果，任务整体失败。
- 没定义失败接管人，链条中间卡住无人处理，工单在系统里挂了很久才被业务方发现，信任很难补回。
自检与验收清单
- 是否画出了带字段的任务依赖图与交接点，并标明每一段的责任人
- 是否先用单 Agent 跑过基线并留存失败样本与平均步数
- 拆分理由是否属于并行、隔离或异构工具，而不是感觉上复杂
- 每个交接点是否有超时时间与明确的接管人，且写进文档
- 是否有调用链日志可用于重放排障，并能定位到具体节点
常见问题
两个 Agent 对话算多 Agent 吗？
算一种编排形态，但价值不在对话本身。若两个角色只是互相转述同一份材料，合并成一个更省成本；只有当两边的工具集、权限或模型明显不同，拆开才有意义，否则只是把一次调用变成多次调用，延迟与账单一起上涨。
多 Agent 会不会更容易出错？
出错概率通常上升，因为多了交接与合并两个环节。可控的做法是把交接写成结构化字段、给合并环节设校验规则，并在评测集里专门放跨节点的失败样例，逐条确认能否被拦住，而不是等上线后靠运气。
小团队适合直接上多 Agent 吗？
不建议。小团队人力集中在业务上，缺少维护编排与追踪的余量。先用单 Agent 把流程跑顺、把评测集建起来，等确实出现并行或权限隔离需求，再考虑拆分，迁移成本也更低，回退时还有基线可比。