为什么要写这条 SOP

用华为云码道（CodeArts）代码智能体处理复杂工程任务时，最常见的低效模式是「串行硬做」：主代理逐个文件阅读、逐处修改、逐个跑验证，上下文越滚越大，单轮耗时长，还容易在中途丢失任务全貌。而很多任务天然可以并行——给多个模块分别补单测、在几十个文件里做同一种 API 迁移、方案调研与代码实现同时推进。这类工作只要拆得开，就应该交给子代理并行执行，主代理只负责拆解、分发与汇总。

问题在于：智能体默认不会主动并行，除非有明确的规则告诉它「必须这么做」。与其每次在对话里口头强调，不如把「主动分发子代理」写成 SOP.md 的硬性条款，让智能体每次开工前自动对照执行。

什么是 SOP.md

SOP.md 是放在工作区根目录、智能体每次开工都会读取的作业规范，相当于给 AI 的《团队工作守则》。它和给人看的流程文档的区别在于：条款必须可判定（做没做到一目了然），而不是方向性建议。写清触发条件、执行步骤和红线，智能体才会把它当流程约束来遵守。

可以直接落地的 SOP.md 模板

# 任务执行 SOP（面向 CodeArts 智能体）

## 1. 开工前：先评估可并行性
- 收到任务后，先输出「任务拆解清单」：列出全部子任务及依赖关系。
- 若互不依赖的子任务 >= 2，必须派发子代理并行执行，
  禁止主代理串行硬做。

## 2. 分发规则
- 探索类子任务（读代码、查文档、定方案）：派发只读子代理，多个并行。
- 实现类子任务（写代码、补测试）：按模块/文件边界拆分，每个子代理
  只负责自己的文件范围，避免写冲突。
- 每个子代理的指令必须自带完整上下文：目标、涉及文件路径、验收标准、
  输出格式，不依赖主代理的对话历史。

## 3. 汇总规则
- 子代理全部返回后，由主代理统一合并：解决冲突、跑全量验证。
- 任一子代理失败先重试一次；仍失败则降级为主代理串行处理，
  并在最终总结中说明降级原因。

## 4. 红线
- 未输出「任务拆解清单」就动手实现 = 流程违规。
- 可并行的任务被串行执行 = 流程违规。
- 主代理代做本应分发的子任务 = 流程违规。

把这份文件放进工作区根目录，并在系统提示或会话开场要求智能体「先读 SOP.md 再动手」，规则即可生效。

几点实践体会

1. 上下文隔离是子代理最大的价值。 子代理读几十个文件也不会污染主代理的上下文，主代理只接收结论，任务后半程依然「头脑清醒」。
2. 输出格式要在 SOP 里定死。 比如规定子代理按「结论 / 改动文件 / 遗留风险」三段返回，否则汇总阶段要花大量时间整理各路结果。
3. 写操作不要跨代理并行。 同一个文件被两个子代理同时修改，合并的代价远大于省下的时间；并行只留给互不重叠的文件范围。
4. 拆分粒度以「一个子代理一次会话能收尾」为准。 拆得过细，分发与汇总的开销会吃掉并行收益。

小结

把协作规则写进 SOP.md，本质是提前和智能体约定「何时必须并行、怎么拆、怎么合并」。这样 CodeArts 在面对多模块改造、批量迁移、全量补测试这类任务时，会主动分发子代理并行推进，整体耗时通常显著缩短，主代理的上下文也更干净。规则写得越可判定，执行得越稳定——这正是 SOP 的价值所在。