条件一：任务可分解
能拆成有明确输入输出的子任务，且子任务之间的依赖关系可以描述。若步骤彼此强耦合、必须同时看到全部上下文，多角色拆开反而要反复同步状态。判断办法是试着把流程画成有向图，看节点能否独立验收。
条件二：子结果可验证
每个子任务的输出要能被规则或人工快速判定对错，例如字段是否齐全、金额是否一致、条款是否命中。无法验证的子结果会被下游直接采信，错误在链路中被放大。可验证性是拆分的前提，不是结果。
条件三：权限可隔离
不同角色应只拿到完成自身任务所需的最小工具与数据权限。共享一个高权限账号最省事，也最危险：任一角色被诱导越权，整条链路都受影响。按角色发放凭证，并在日志中区分调用来源。
条件四：状态可持久化
多轮协作需要把中间状态存下来，支持中断恢复与事后复盘。只存在内存里的会话一旦超时或重启就丢失，长流程很难跑完。状态存储还要能按任务查询，否则出问题只能靠日志一点点拼凑。
适用与不适用
适合谁
- 流程长、环节多、需要中断恢复的业务
- 已有工具清单与数据权限体系的企业
不适合谁
- 任务强耦合、无法拆成独立子任务的场景
- 所有角色共用一个高权限账号的做法
典型场景
某企业的理赔流程涉及资料核验、条款比对与金额试算。团队先把流程画成有向图，发现条款比对可独立验收，资料核验依赖影像质量。据此只拆出两个角色，其余保留在单角色内，并为每个角色单独发放只读凭证。
可执行步骤
- 把流程画成有向图，标出可独立验收的节点以及彼此的依赖
- 为每个子任务定义可被规则或人工快速判定的输出标准与责任
- 按角色发放最小权限凭证，并在日志中区分调用来源与任务
- 把中间状态落库，支持中断恢复、按任务查询以及事后复盘
常见坑
- 子任务无法验证就拆分，错误会被下游直接采信，链路越长被放大的程度越高。
- 所有角色共用一个高权限账号，一次诱导越权就影响全链路，追责也分不清来源。
- 中间状态只放在内存里，长流程遇到超时或重启就得从头再来，用户体感很差。
自检与验收清单
- 流程是否能画成有向图并标出验收节点
- 每个子任务是否有可被规则判定的输出标准
- 角色是否按最小权限发放凭证并留记录
- 中间状态是否落库并按任务可查询
常见问题
单智能体能做为什么要多角色？
多数情况下单角色加固定流程更稳。只有在上下文长度、专业分工或权限隔离上确实受限时，拆分才带来收益。先确认限制在哪，再决定拆不拆，比先设计角色再找理由要靠谱。
状态要存多久？
按业务留存要求定，通常至少覆盖一个完整流程周期加复盘期。状态里可能含客户信息，存储要遵循数据分级与最小化原则，到期清理并记录访问日志，避免成为新的数据风险点。
权限隔离会不会影响效率？
会增加配置工作量，但换来的是可控的爆炸半径。折中做法是按任务类型预设几套凭证组合，而不是每个角色单独配置。关键是任一角色越权时，不至于影响整条链路。