检查一：子任务能否独立
判断标准是每个子任务能否在不看其他子任务中间结果的情况下完成。如果必须共享同一份草稿反复修改，拆开只会增加传话；如果能各自拿到输入、各自产出结构化结果，才具备拆分的基础，也才谈得上并行。这也是为什么先说任务独立性，再谈角色设计。
检查二：上下文装得下吗
单 Agent 的失败常来自上下文过长：早期材料被挤掉，回答开始漏条件。此时优先做检索与摘要，而不是加角色；只有当不同子任务需要完全不同的材料集、且合并后必然超长时，拆开才划算，否则先修检索。边界在于上下文能否分片，而不是角色数量多少。
检查三：错误能定位吗
多 Agent 出错时要知道是哪一环、哪次交接出的问题。清单里应有一项：是否有调用链日志、能否重放单条任务。若排障只能靠翻聊天记录，说明先要补的是可观测性，不是编排，补完再评估拆分。怎么补可观测性，先做调用链日志与单任务重放。
检查四：工具允许并发吗
并行读写同一张表、同一个接口配额，会带来覆盖与限流。检查项包括：写操作是否有幂等键、是否有锁或队列、超时后由谁补偿。三项中缺一项，就把相关环节串行处理，其余部分再考虑并行拆分，不要一次改完。为什么写操作要串行，因为覆盖与限流都会破坏结果。
检查五：谁维护评测
拆分后评测集要按节点拆，还要有端到端的整体用例。若团队没有人力维护两套评测与一条链路，多 Agent 上线三个月就会失去质量基线，届时既不敢改也不敢停，只能继续加补丁，最后推倒重来。边界是人力，没有第二个人就别维护两套评测。
适用与不适用
适合谁
- 正在做架构评审、需要书面依据的技术负责人
- 已有单 Agent 原型、想确认是否该拆的团队
- 被要求上多 Agent、但想先验证收益的项目
不适合谁
- 还没有可运行的单 Agent 基线
- 不愿意投入日志与评测建设的团队
典型场景
某银行运营团队要做对公开户材料预审，方案里写了五个 Agent 分工。评审时按清单逐项检查：子任务可独立、上下文各自可控，但五个角色要写同一张补正表，并发会覆盖。团队于是把写操作收敛到一个节点，其余四个只读并行，交接字段固定为六项，并指定运营主管做接管人。
可执行步骤
- 用真实任务跑单 Agent 基线，记录失败类型、平均步数与接管比例
- 给每个候选子任务标注输入来源、输出字段与依赖关系，形成一张交接表
- 检查写操作、接口配额与超时补偿是否具备，缺一项就先串行处理，别急着并行
- 确认日志能重放单条任务、评测可按节点拆分，并由同一人维护到底
- 按门槛逐项打勾，未过项写明补救责任人与完成时间，留档备查，下次评审可查
常见坑
- 清单只在会上口头过一遍，没有留下打勾记录，三个月后没人说得清当初为什么拆、谁同意的。
- 把工具数量当成拆分依据，工具多的环节被切成三个角色，实际只是同一份材料被转述三次。
- 忽略写冲突，两个 Agent 同时更新补正表，客户收到两份不同意见，投诉后才回头查日志。
- 评测只做端到端、不按节点记录，出问题时无法判断是检索环节还是合并环节拖累了通过率。
自检与验收清单
- 是否已完成单 Agent 基线并留存失败样本与步数
- 每个子任务是否写明输入来源、输出字段与依赖关系
- 写操作是否具备幂等、锁或补偿机制，并有测试记录
- 日志能否重放单条任务，并定位到具体交接点
- 拆分门槛是否逐项打勾并留档，未过项有责任人
常见问题
清单要打多少分才能拆？
建议设四项硬门槛：子任务独立、写操作可控、日志可重放、评测可拆。四项全过再评估收益；缺一项就先补齐，不要用先上线再补的方式推进，补的时候往往已经出了对外的事故，代价远高于提前一个月准备。
拆了之后还能合回去吗？
能，前提是交接字段结构化、编排层与业务逻辑分开。若拆的时候把业务规则写进了各角色的提示词，合回去就要重写；设计时把规则放在共享配置里，回退成本会低很多，也便于逐段合并。
业务方坚持要多 Agent 怎么办？
用对照实验回答：同一批任务跑单 Agent 与拆分方案，比通过率、平均耗时与排障时间。把结果摆出来通常能收敛分歧；如果拆分确实更好，也顺势拿到了可复用的评测基线，后续扩展有据可依。