Vibe Coding Agent 任务依赖 DAG：按证据解锁并行开发

把“前端、后端、测试、文档各找一个 Agent”写成四行清单，看起来已经完成拆分，实际上只分了角色，没有分清依赖。前端可能等待尚未确定的错误码，测试可能按旧 schema 写夹具，文档则把两个候选方案中的一个描述成既成事实。四个 Agent 都很忙，集成时才发现只有一条链真正可以开工。

Vibe Coding 的任务依赖 DAG 应描述“什么证据产生后，什么工作才有资格开始”。它不是 多 Agent DAG 调度恢复 所处理的运行时队列、事件重放和崩溃恢复，也不替代Agent 委派协议中的权限与输出 schema。这里的图是一份开发计划工件，用来阻止错误的并行，而不是实现一个通用 scheduler。

节点写交付物，不写角色

节点名称若是“后端 Agent”或“测试 Agent”，就无法判断它何时完成。改成可检查的交付物，例如“冻结 profile API v2 示例”“实现服务端拒绝分支”“补浏览器登录恢复用例”。每个节点至少记录：

1. 输入证据及其 revision；
2. 允许读取和修改的范围；
3. 唯一交付物及格式；
4. 完成判定器；
5. 未决问题和禁止副作用。

node: implement-profile-handler
inputs:
  - api-contract.md@rev3
  - failing-test: rejects-cross-tenant-update
output: src/api/profile/handler.ts patch
acceptance: targeted integration test passes
nonGoals:
  - no database migration
  - no client component changes

一项工作若同时产出合同、实现和验收，就应继续拆分；否则下游无法只依赖其中一个稳定结果。任务上下文包可作为单节点输入，但 DAG 还要说明节点之间为什么存在边。

给依赖边标注语义

所有箭头都写成 dependsOn 会掩盖不同等待原因。至少区分三类：

• HARD：没有父节点产物就无法正确实现，例如消费者依赖已确认的字段语义；
• CONTRACT：可以先做局部准备，但在共享接口 revision 冻结前不得形成最终补丁；
• ACCEPTANCE：实现可完成，只有指定测试或审阅证据到齐后才允许进入集成。

GitHub Actions 的 needs 明确表达 job 的前置关系，并把依赖失败或跳过与下游是否继续联系起来。开发 DAG 不必照搬 CI 工具实现，但必须同样避免把“最好先做”与“缺少就不准开工”混为一谈；合同冻结与最终验收也应使用不同的边类型。

不要把源码依赖图原样复制成任务图。源码 A import B，只说明代码关系；这次任务也许先用既有 B，不需要修改它。反过来，一个法律文案确认与代码没有 import 边，却可能是发布测试的硬前置。仓库依赖图驱动的改动规划提供影响闭包，任务 DAG 再从闭包中挑出本次实际交付依赖。

就绪必须由证据计算

节点进入 READY 前，逐项确认父产物存在、摘要匹配、未被后续编辑失效、接口版本仍是 active、路径所有权没有冲突、验收工具可用。父 Agent 自报“完成”不是就绪证据；只有约定产物通过确定性检查，边才算满足。

Python graphlib.TopologicalSorter 提供拓扑准备、就绪节点和完成通知的基本词汇，也会暴露循环；它能帮助检查图结构，却不会替团队判断一条业务依赖是否真实。对每条边都问一个反事实问题：“若删除这条边，下游会在哪个可观察结果上出错？”答不出来的可能只是组织习惯。

并行宽度也不能超过证据宽度。三个节点虽然拓扑上都 ready，但若都要改同一个共享类型文件、占用同一浏览器 profile 或依赖同一人工决定，仍需串行或重新切分。路径和外部资源分配应进入节点合同，而不是等编辑冲突后再补。

发现新事实时生成新图 revision

勘察常会推翻初始拆分：所谓纯前端改动其实需要服务端错误码，或生成客户端必须先更新 OpenAPI。不要让 Agent 私下增加任务并继续。记录新证据，新增或重定向边，检查是否成环，再生成 DAG revision；已完成节点只有在输入和交付合同未变时才能复用。

若新边指向正在执行的节点，先暂停其提交资格。它可以保留调查笔记，但基于旧前提形成的补丁不能直接进入集成。循环通常说明职责切得不对，例如“合同等实现确认、实现又等合同确认”；解决方法是先提取最小共享接口决策，而不是指定其中一个 Agent 猜测。

用集成结果反查拆分质量

图的完成条件不是所有节点都显示绿色，而是每个叶子交付物能沿边追到当前证据，集成顺序明确，关键用户验收有唯一负责人。若集成阶段频繁出现未声明的共享文件、重复实现或双方都没写的边界测试，应回写 DAG 缺失边，而不是只在最终补丁上灭火。

一张好的开发 DAG 会让并行数量变得保守但真实：无依赖的调查可以同时进行，共享合同先冻结，消费者随后展开，验收证据最后收口。它减少的不是 Agent 数量，而是那些注定要重做的“提前开工”。

延伸阅读

• 任务上下文包
• 仓库依赖图驱动的改动规划
• Agent 委派协议设计
• 多 Agent DAG 调度恢复