维度一：可分解
任务能否拆成边界清晰的子任务，是多 Agent 的前提。怎么判断：看每个子任务是否有独立输入输出与验收标准。边界是拆不干净的任务强行拆分，只会增加协调开销，错误在角色之间来回传递，反而更难定位。
维度二：错误传播
多 Agent 的错误会沿链路放大，单 Agent 的错误相对集中。为什么重要：链路越长，定位与回滚越难。怎么做：给每个环节设校验点与超时，失败即中止并保留中间结果，避免错误被下游继续加工，也便于事后复盘，否则容易在后期返工。
维度三：上下文
工具数量多、上下文差异大时，拆分角色可以减少干扰；工具少、流程单一时，单 Agent 更稳。怎么判断：统计单个任务需要的工具数与上下文长度，超过可控范围再考虑拆分，而不是一开始就按角色切分，否则只会增加协调成本。
维度四：时延成本
多 Agent 会增加调用次数与串行等待，时延与成本随之上升。怎么算：按任务链路估算调用次数与并发度，比较两种方案的单任务成本。边界是对时延敏感的场景，拆分要谨慎，否则体验下降会抵消准确率收益。
维度五：调试权限
多 Agent 的日志要能串起整条链路，否则排查只能靠猜；不同角色还需要不同权限。为什么重要：权限边界不清，越权调用会成为审计问题。怎么做：统一追踪标识，按角色最小授权，并保留人工接管点与审计记录。
适用与不适用
适合谁
- 正在设计 Agent 架构、需要书面依据的技术负责人
- 流程复杂、需要多角色协作的业务场景
不适合谁
- 任务简单、工具数量少、无需多角色协作的场景
- 团队缺少日志与追踪能力的项目，且不愿调整既有流程
典型场景
某招标代理机构要做投标文件初审：资质、格式与技术三部分规则不同，工具也不一样。团队先做单 Agent 版本，发现上下文过长、错误集中在资质判断；改为三个角色分工后准确率提升，但时延增加，最终按环节设置并行与人工复核。
可执行步骤
- 把任务拆成子任务，检查是否有独立输入输出与验收标准，写成清单，并留档备查
- 统计每个子任务的工具数量、上下文长度与调用频率，判断是否超限，同时指定负责人
- 为每个环节设校验点、超时与失败中止策略，并保留中间结果，形成书面记录
- 按链路估算调用次数、时延与单任务成本，做单 Agent 与多 Agent 对比，逐项确认后归档，注明依据与时间
- 统一追踪标识与最小权限，保留人工接管点并写入运维手册，注明依据与时间
常见坑
- 为多而多，把简单流程拆成多个角色，协调开销超过收益，时延明显上升，业务体验变差，最后又拆回去。
- 缺少链路追踪，错误在角色之间传递，排查时只能逐个重跑，定位时间很长，值班压力大，恢复也慢，最终只能推倒重来。
- 角色权限给得过宽，越权调用难以审计，出问题后责任说不清，整改还要重排架构，成本很高，返工代价更高。
自检与验收清单
- 子任务是否有独立输入输出与验收标准，并明确负责人
- 每个环节是否设校验点、失败中止策略与负责人
- 调用次数、时延与单任务成本是否估算并复核，注明依据
- 追踪标识、最小权限与接管点是否落实、演练并留记录
常见问题
多 Agent 一定比单 Agent 准吗？
不一定。拆分能降低单次上下文压力，但会引入协调与错误传播问题。若子任务边界不清，多 Agent 反而更容易出错。建议先做单 Agent 基线，再针对失败类型决定是否拆分，而不是先拆再说。
什么时候必须拆？
当子任务需要不同权限、不同工具集或不同上下文时，拆分更有必要。例如资质审查与格式检查的规则和权限完全不同，放在一个 Agent 里既难授权也难排查。其余情况可以先用单 Agent 加工具。
多 Agent 的时延怎么控？
把无依赖的子任务并行，串行链路只保留必要环节，并为每步设超时与降级方案。对时延敏感的场景，可以让部分角色异步执行，先返回确定结果，再补充次要信息，避免用户长时间等待。