何时用 CodeDAG
CodeDAG 与你现在的做法有什么不同、适合什么样的工作，以及它目前做不到的事。
Claude Code 和 Codex 本身就能同时处理几件事，也能派出子 Agent，Claude Code 还有 Dynamic Workflow。这些方式各有擅长的范围，CodeDAG 并不取代它们，它针对的是其中一类工作：多个相互关联的任务组成一个完整的工作流，需要按依赖一路跑到结束，中途不用人看着，结果还能审核、能回退。几行就能改完的小改动，或者方向还要边做边定的探索，直接用 Claude Code 或 Codex 更合适。
你可能已经在用的方式
| 方式 | 适合的情况 | 力不从心的地方 | CodeDAG 的不同 |
|---|---|---|---|
| 把所有任务写进一个大 prompt，交给单个 Agent | 几步之内就能完成、前后联系紧密的工作。不需要任何准备，Agent 始终掌握全部来龙去脉。 | 步骤一多，会话越拉越长，早先读过的文件和过时的中间结论堆在上下文里，后面的判断越来越不可靠。所有事也只能一件接一件地做。 | 每个任务从一个全新的会话开始，上下文里只有这个任务需要的内容；互不依赖的任务可以同时执行。 |
| 连续排队发 prompt | 顺序明确的一串小步骤。趁 Agent 还在工作时把后续指令排上，你不必守着逐条交代。 | 所有指令仍在同一个会话里依次执行，既不能并行，也不能把其中几步交给另一个 Agent 或模型。 | 先后顺序由依赖决定，没有依赖关系的任务同时执行；每个任务都可以单独指定 Agent 和模型。 |
| 让主 Agent 编排 subagents 或 agent teams | 规模不大、需要边做边判断的工作。主 Agent 可以根据进展随时调整分工。 | 下一步做什么由主 Agent 逐轮决定。任务和依赖一多，它要同时记住计划和各方的进度，容易漏掉依赖、误判推进时机，也没法照原样再跑一遍。agent teams 的成员之间也没有 worktree 隔离，要靠划分文件来避免冲突。 | 任务和依赖事先写进工作流文件，由 CodeDAG 按定义推进，规模变大也不会走样，同一份工作流可以反复运行。默认每个任务在自己的分支上工作。 |
Ralph loop，或用 claude -p、codex exec 写脚本循环 | 把同一件事反复做到达标，或者把固定的几步串起来。做法完全由你掌握，也方便接进已有的脚本和工具链。 | 暂停、从断点恢复、失败重试和并行时的隔离，都要自己在脚本里实现。非交互方式运行的 Agent，中途也很难插话纠偏。 | 工作流和其中每个任务都能暂停、中断和恢复，恢复时在原来的会话里继续；每个任务都是交互式会话，运行中可以进去直接对话。 |
| 使用并行工作区 Agent 看板工具 | 同时推进几件互不相关的事。每件事在自己的 worktree 或会话里进行，由你分派，再逐个查看进度和改动。 | 它们以一个个独立的任务或 issue 为单位。任务之间有依赖时，什么时候开始下一件、怎样把上一件的结果交给它、最后怎样合到一起，都要你来安排。 | 以多个关联任务组成的完整工作流为单位：默认情况下，上游被接受后，CodeDAG 先把它的结果合并进下游的分支，再启动下游，最后把所有结果汇到一个集成分支上。 |
| Claude Code Dynamic Workflow | 由 Claude 写脚本，在有明确测试或验证方法的前提下，做大批量迁移与重构。 | 只能调动 Claude 的子 Agent；难以看到执行细节；运行中不接受人的中途干预纠偏。 | 这是与 CodeDAG 最接近的一种方式，详细差异见下一节。 |
与 Claude Code Dynamic Workflow 相比
Dynamic Workflow 是 Claude Code 内置的编排方式，也是和 CodeDAG 最接近的一种：两者都把“下一步做什么”从模型的逐轮判断里拿出来，交给一份事先写好的定义去执行。
两者的区别在于管到哪里。Dynamic Workflow 是一个 Claude Code 会话里的功能：它调动这个会话的子 Agent，启动之后不接受你的输入，过程中能看到的运行细节也非常少。CodeDAG 管的是一段开发工作从排队、执行、审核到合并的全过程：任务可以分别交给 Claude Code 或 Codex，每个任务都是一个能进去对话的会话，改动落在各自的分支上，在你指定的地方停下来等你审核，暂停之后可以在原会话里继续而不必重跑。
| CodeDAG | Claude Code Dynamic Workflow | |
|---|---|---|
| Agent 与模型 | 每个任务可以交给 Claude Code 或 Codex（后续会支持更多 Agent），并单独指定模型，比如让一个模型实现、另一个模型审查。 | 只能调动 Claude Code 自己的子 Agent，模型限于 Claude 系列。 |
| 运行中介入 | 每个任务都是一个原生会话，运行中可以随时进去，直接给 Agent 新的指令。 | 官方明确运行中不接受用户输入。 |
| 人工审核 | 可以让任何一个任务或整个工作流做完后停下来等你审核。不满意时，可以让 Agent 接着改、从头重做，或者自己动手改，满意后再放行。 | 运行中没有人工审核的环节。 |
| 分支、合并与回退 | 每个任务在自己的分支上改代码，结果自动合并，主分支不动；不想要的改动可以单独丢弃。 | 子 Agent 默认直接改同一份代码；即使是额外设置隔离开的改动，也不会自动合并。 |
| 进度与状态 | 状态不只说进度，还告诉你要不要处理：任务出了问题会停下并写明原因，处理后接着做。 | 状态只反映执行进度，出了问题的 Agent 直接以失败结束。 |
| 执行轨迹 | 每个任务从开始到结束的完整轨迹都能查看，执行中和结束后都可以。 | 每个 Agent 只能看到最近 3 次工具调用和最终结果。 |
| 暂停与恢复 | 工作流和单个任务都能暂停、中断和恢复，恢复时做到一半的会话可以接着做。 | 只能暂停工作流级别，无法指定暂停某个任务；恢复时，做到一半的会话需要重跑。 |
| 定义方式 | 声明任务与依赖的 YAML 文件，有哪些任务、谁依赖谁，一眼就能看清。 | Claude 写成的 JavaScript 脚本，不够直观，且对不熟悉 JavaScript 的用户不友好。 |
归结起来，两者最根本的差别在于你想不想把控制权握在自己手里。Dynamic Workflow 像一次性外包：把活交给 Claude Code，等它跑完，拿回一份结果，过程中你插不上手，干活的也只能是 Claude。CodeDAG 像自己带团队做项目：过程中你随时可以查看、接手和把关；每一步交给 Claude Code 还是 Codex、用哪个模型，也由你决定，因为它是独立于这些 Agent 的工具，不把你绑定在某一家上。所以，既想让 Agent 替你把活干完，又想保有对过程的控制权和对 Agent 的选择权，就用 CodeDAG。
用了 CodeDAG 也不必放弃 Dynamic Workflow。任务 Agent 就是一个普通的 Claude Code 或 Codex 会话，在自己的任务里照样可以派子 Agent，或发起 Dynamic Workflow，CodeDAG 会等它们都结束，才判定这个任务完成。对大量同类对象做同一件事，不依赖顺序、不必做分支隔离的工作，比如检查每个路由、迁移几百个文件，就可以这样安排：把批量展开的部分写成一个任务，由任务里的主 Agent 调动子 Agent，这个任务只消耗 1 点 CodeDAG 额度；它前面的方案、后面的测试和审查仍然是 CodeDAG 的任务，人工审核、暂停与恢复都照常可用。
不是同一类的产品
n8n、Dify、Zapier 这类工作流平台也用节点和连线组织流程，但一个节点通常是一次模型调用或一次 API 请求，流程运行在服务器或云端，处理的是数据和消息，不在你的本地仓库里改代码。Airflow 这类数据管道编排工具同样用 DAG 组织任务，产物是数据，不是代码。CodeDAG 的每个节点都是一个完整的编码 Agent 会话，在你本机的 Git 仓库里工作，产物是分支上的代码改动。
怎么判断这件事该不该用 CodeDAG
判断一件事要不要交给 CodeDAG，可以依次回答三个问题：这段工作能不能委托出去，编排值不值得，CodeDAG 的边界能不能覆盖。能不能并行改代码、要不要设人工审核，都不是前提；一条只有先后顺序、全程自动接受的工作流，同样是 CodeDAG 的正常用法。
- 能不能说清下一段工作的目标和交付物？ 你不必预先规定每一步怎么实现，那是任务 Agent 自己的判断；但要能说清每个任务做到什么程度算完成、结果留在哪里，Agent 才能不等你逐轮确认就推进下去。如果目标和取舍还需要一轮轮讨论，先在交互会话里把它们谈清楚，再决定哪些部分值得编排。
- 编排能不能减轻这次工作的实际负担？ 常见的负担有这几种：步骤之间有依赖，后一步要等前一步的结果；有一批任务可以同时推进；想让另一个 Agent 独立审查；要跑很久，你不想守着；需要随时查看进度、暂停、恢复，或者在关键处把关。只要有其中一项，而且省下的精力值得准备工作流、按任务消耗额度，就值得编排。工作流也不一定要自己写，装了 CodeDAG Guide 插件的 Agent 可以替你写好并提交，见让 Agent 帮你编排。单次问答，或者很快就能改完的小改动，直接交给 Claude Code 或 Codex 更省事。
- 完成目标必需的做法，在 CodeDAG 当前的边界之内吗？ CodeDAG 在单个本地 Git 项目里工作，任务之间的关系要在提交前确定。如果目标离不开执行中动态增删任务、自动衔接多个仓库或者自动推送结果，就把其中 CodeDAG 能承担的部分拆出来交给它，其余部分自己处理，或者换用别的工具。其中执行中增删任务的替代做法见 CodeDAG 目前的限制。
三个问题都有肯定的回答，也就是有一段能连续委托的工作，编排带来的收益值得投入，而且没有挡住目标的产品边界，这件事就适合交给 CodeDAG。
CodeDAG 目前的限制
下面几项是 CodeDAG 目前的限制，都已列入后续版本的规划。在支持之前，可以先用表中的替代方案。
| 限制 | 解释 | 替代方案 |
|---|---|---|
| 没有条件分支与循环 | 任务和依赖在提交时就固定了，CodeDAG 不会根据执行结果决定执行哪些任务，也不会回到前面的任务重新执行。 | 把可能用到的任务都预先排好，在 prompt 里写明判断条件；需要反复尝试的工作放在一个任务内部完成。见常见问题。 |
| 不能在执行中增删任务 | 工作流按提交时的内容执行到底。 | 拆成前后两个工作流：前一个把结论写进文件，再由你或编排 Agent 据此写出并提交下一个。 |
| 没有图形界面 | 状态和日志都在终端里查看。 | 用 cdg status 看整个项目的队列，用 cdg dag status 看一个工作流里的每个任务，加上 --watch 会持续刷新。见想知道现在怎么了：三个层级的 status。 |
下一步
- 安装与登录：安装
cdg，登录 CodeDAG 账号。 - 快速开始：第一个工作流：在自己的仓库里跑通一个只新增文件、不改动已有代码的工作流。
- 设计理念：CodeDAG 为什么这样设计，以及每项取舍的代价。
最后更新