RFC 驱动的多 Agent DAG：把大需求拆成可合并的工作单元

大多数人第一次用 AI agent 处理大任务时，本能反应是把所有需求塞进一个超长 prompt，然后等它跑完。这能出结果，但结果往往像一块大泥巴——难以验收、无法局部回滚、一处出错整体卡死。

我把这个问题的根源归结为一点：没有把「可并行的工作量」和「必须串行的依赖关系」分离开来。RFC 驱动的 DAG 编排，就是在正式动手之前先把这张图画清楚。

什么是 RFC 驱动的 DAG

RFC（Request for Change / Comments）在这里不是正式文档，而是一份结构化的输入——描述这个功能的目标、边界、约束，以及「做完了」长什么样。

DAG（有向无环图）描述工作单元之间的依赖关系。每个节点是一个独立可验证的工作单元，边是依赖：B 必须在 A 完成之后才能开始。

把两者结合起来，流程大致是：

1. RFC 接收：澄清需求边界，明确验收标准
2. DAG 拆解：按依赖关系把 RFC 切成多个工作单元
3. 单元分配：每个单元分给一个 agent，或人工处理
4. 并行实施：无依赖关系的单元同步推进
5. 单元验证：每个单元独立跑验收测试后进入合并队列
6. 合并队列 + 集成测试：按依赖顺序合并，每次合并后跑集成测试
7. 最终系统验证：全部单元合并后的回归确认

关键在第 2 步。把 RFC 图画清楚，后面的每一步才可以机械执行。

工作单元的六个字段

每个工作单元需要定义清楚六件事：

• id：唯一标识，便于引用和追踪
• depends_on：前置依赖的单元 id 列表，决定了它在 DAG 里的位置
• scope：这个单元能改什么、不能改什么的边界声明
• acceptance_tests：完成条件，可客观判断，不靠感觉
• risk_level：Tier 1（孤立文件改动）/ Tier 2（多文件行为变更）/ Tier 3（schema / 权限 / 性能 / 安全类改动）
• rollback_plan：如果这个单元出问题，怎么撤回而不影响已合并的其他单元

这六个字段看起来繁琐，但它们强迫你在动手之前想清楚三件事：边界在哪里、怎么算完成、出了问题怎么办。没想清楚就开始执行的单元，会在合并阶段制造麻烦。

合并队列的三条规则

单元通过验收之后不能随便合并，需要走一个合并队列：

1. 不合并有未解决依赖失败的单元——依赖链上任何一个单元失败，下游单元的验收结果可能是假阳性
2. 合并前 rebase 到最新集成分支——并行推进期间集成分支可能已经被其他单元改过，stale base 会产生幽灵冲突
3. 每次合并后重跑集成测试——每次合并都是一次新的系统状态，不能复用上次的集成测试结果

第三条最容易被跳过，理由通常是「只合了一个小单元，没必要全跑」。但集成测试的价值正是在于发现「单元各自通过，组合在一起出问题」的场景。

单元卡住时怎么恢复

实际执行中，总会有单元卡住——agent 陷入循环、边界定义有歧义、依赖的前置单元改了接口。

恢复策略是：把卡住的单元逐出活跃队列，先快照当前发现（已经弄清楚了什么、卡在哪里），然后把该单元重新分解成更窄的 scope，带着新约束重新入队。

「缩窄 scope 重试」比「加长 prompt 硬撑」有效得多。卡住往往不是 agent 能力不够，而是这个单元本身承载了过多不确定性——拆得更细，不确定性就能被隔离到更小的范围里处理。

一句话心法

大需求的可靠执行，不依赖更强的单次生成，而依赖更清晰的分解——把「做完了」的定义前置到每个工作单元里，合并才不会变成赌博。