设计理念

有了 Agent 辅助编程之后，我们一直在思考：怎样才能让软件开发尽可能自动化，并把这种自动化扩展到更大的规模？CodeDAG 是我们对这个问题的一份粗略答卷。以下八条理念概括了我们在设计中的取舍：

• 能自行推进，就不必步步催促。
• 任务相互衔接，上下文各自独立。
• 流程如何写，就能如何执行。
• 错了能回头，才敢放开手。
• 不必时刻干预，仍能随时接管。
• 不只看见结果，也要看清过程。
• 代理能被编排，编排也能被代理。
• 多一种智能，多一种制衡。

能自行推进，就不必步步催促

今天，许多开发者仍通过一轮轮交互与 Agent 合作：发送提示词，等待它完成工作，检查结果，再决定下一步。这让人想到早期在命令行中逐条操作计算机的方式，每一步都需要人继续发出指令。后来，脚本让人可以把一段过程预先写下来，交给计算机连续执行，不必始终守在旁边。

CodeDAG 希望把类似的转变带到 Agent 辅助开发中：将可以连续完成的工作组织成工作流，交给系统自行推进。工作流提交后，任务按依赖执行，多个工作流也能排队接续运行，让开发过程在人离开后仍然继续。

交互式工作仍然适合探索目标、讨论方案等需要随时调整方向的场景。我们的取向是：在条件允许时，优先选择持续执行，把人的注意力从逐轮推动流程中释放出来。这是 CodeDAG 的出发点，后面的设计都围绕如何让持续执行值得信任而展开。

任务相互衔接，上下文各自独立

持续执行可以有不同的组织方式。一个 Agent 可以在长会话中连续处理任务，必要时压缩上下文；多个 Agent 可以组成团队，在执行中不断交换信息；主 Agent 也可以随着进展现场派发子 Agent。CodeDAG 选择以确定的工作流来组织任务：一个任务对应一个 Agent 会话，每个会话围绕自己的任务持有一份独立、稳定的上下文，任务之间的衔接与推进则交给编排引擎。

上下文独立，并不意味着任务之间没有联系。新任务从全新会话开始，所需的上游结论通过代码、文档等明确产物传递，不必继承上游整段对话，也不依赖其他任务不断发来的临时消息。这里的稳定，是指任务目标与信息来源有明确边界：一个任务需要理解的范围主要由它要完成的工作决定，不会随着整个工作流的历史一同膨胀。

让单个 Agent 连续做所有事很方便，但跨任务积累的无关信息与过时假设，容易干扰模型对当前任务的判断；压缩上下文虽然能减少信息量，却也可能遗漏关键约束，或保留结论却丢失它成立的条件。Agent 团队的实时交流可能带来创意，但成员不断影响彼此，也会增加执行过程的不确定性。对软件开发而言，我们更看重可靠与稳定，愿意为此接受更严格的任务组织，也放弃一部分上下文自然延续的便利和实时交流碰撞创意的机会。需要快速试探或开放式创作时，这份成本未必值得；但在较大规模软件开发中，我们认为解耦带来的收益更大。

流程如何写，就能如何执行

分开任务的上下文，还没有回答任务之间应当怎样衔接。主 Agent 即使将执行交给不同的子 Agent，仍需要随着执行进展临时判断任务如何拆分、何时启动、结果交给谁。这种方式很灵活，适合简单任务和随时变化的探索；但随着任务与依赖增多，主 Agent 需要同时顾及的安排与状态也越来越多。单纯依靠模型的注意力维持整套流程，便更容易遗漏依赖、误判推进条件，让实际执行逐渐偏离原本的计划。

CodeDAG 选择先把这些安排写进工作流文件，再由编排引擎按定义执行。哪些任务依赖哪些结果、什么条件下可以继续，都在运行前确定。同一份工作流可以事先检查、反复运行，并在实践后修订，不必由主 Agent 每次在现场重新组织。任务与依赖增多，会带来更多调度工作，却不会改变引擎遵循的规则：即使流程扩展到很大规模，写下的依赖与推进条件仍由引擎逐一落实，不会因为超出单个 Agent 的注意力范围而在执行中走样。

这份可重复的精确性，需要以一部分灵活性为代价：任务结构必须预先表达，执行时遵循这份结构，不能随现场判断任意增删节点。我们要固定的是任务之间的组织关系，而不是 Agent 在任务内部的每一个判断；如何完成工作，仍由任务 Agent 自主决定。CodeDAG 所面向的，是复杂到值得提前设计编排、再让系统可靠落实的场景。

错了能回头，才敢放开手

即使任务边界清楚、编排准确，Agent 仍会犯错。要放心地扩大工作流，我们还需要让局部错误有局部处理的余地。如果一次不合适的改动就可能让整体陷入无法挽回的状态，人便不得不守在每一步之前确认，持续执行也就失去了基础。

因此，CodeDAG 默认隔离每个任务的代码改动。横向并发时，各任务在独立工作区和各自的分支上执行，即使同时修改同一文件，也能追溯改动分别来自哪个任务；纵向顺序执行时，每个任务也有自己的分支，在接收上游结果后开展工作，保留本次改动的边界。隔离的目的是让每一部分都有退路，也让互不依赖的任务能够并发执行，提高整体效率。

在任务结果被接受前，不满意的改动可以丢弃，也可以从任务开始前的干净起点重做。已接受的结果再按依赖传递并汇入集成分支，最终是否合入主分支仍由编排者决定。这让工作流能够容纳局部试错，减少为了避免不可逆后果而在中途反复人工确认的需要。

默认值表达了我们愿意为哪一侧承担成本。Claude Code Dynamic Workflows 沿用子 Agent 默认共享检出、按需启用隔离的方式；CodeDAG 则选择默认隔离，同时保留共享工作区选项。选择默认隔离，也就接受了分支管理与结果合并带来的复杂度。我们选择由工具的设计与实现承担这份成本，让 CodeDAG 负责管理分支和合并结果，使用户获得可逆性的好处，而不必为此承担过多的操作与管理负担。

不必时刻干预，仍能随时接管

有退路，并不意味着只能等执行结束后再处理问题。选择自动化与持续执行，也不要求人放弃对执行过程的控制。我们希望人可以决定哪些地方需要把关，也可以在发现问题时介入，而不必为了保留这些能力始终守在现场。

控制既可以预先安排，也应能在需要时临时介入。工作流可以把审查组织成 Agent 任务，或在关键位置设置人工审核门禁，验证结果后再决定是否继续。遇到计划之外的情况，也可以暂停或恢复工作流及其中的任务，必要时中断执行，或者向任务会话补充一条指令。前者预先确定把关的位置，后者保留执行途中接管的能力，而不要求编排者提前预见所有问题。

我们希望且相信，随着模型进步、工作流逐渐完善，人工验证和临时干预会越来越少。但减少干预，并不意味着放弃干预的能力。一个流程可以长期无人介入，同时始终保留接管的入口；正因为必要时仍能控制，平时才更有信心放手。

不只看见结果，也要看清过程

有效的控制以看得见为前提。知道某个 Agent 正在运行，或者看到它最终交出的结果，往往还不足以判断是否需要干预。我们希望能够实时了解它正在做什么，也能在事后追溯结果是怎样产生的。

因此，CodeDAG 除了提供工作流和任务的状态，还提供包含 Agent 完整输出、工具调用与状态提示的实时日志，并允许进入任务的原生会话查看现场。执行过程留下的记录可以用于复盘与审计，帮助我们追查问题出现在哪一步、任务是否缺少必要信息。可观测性既支持当下是否介入的判断，也为后续改进工作流提供依据。

即使未来的模型已经强到很少需要人介入，我们依然选择保留详细的观察与控制能力。自动驾驶能力的进步，可以让刹车与方向盘更少被用到，却不必成为拆掉它们的理由。我们愿意为这份兜底能力保留系统的复杂度，让自动化始终有一个可以接管、可以追查的安全底线。

代理能被编排，编排也能被代理

让流程可定义、可观察、可干预，并不意味着这些工作必须由人亲自完成。前面选择的精确性，约束的是工作流确定之后的执行，而不是创建工作流时的自主判断。工作流既可以由人编写，也可以由 Agent 理解目标、拆分任务并设计依赖，把自己的规划变成明确的执行安排。Agent 不仅能作为任务的执行者接受编排，也能作为人的代理承担编排。

编排 Agent 的工作也不必止于提交工作流。借助 CodeDAG 的观察与控制能力，它可以在授权范围内持续跟踪进度、验证结果，并在需要时协调返工、干预执行或安排后续工作，直到目标完成。既定流程由引擎落实，规划与管理则由编排 Agent 持续承担，让人不必亲自照看每一步。

乍看之下，这与主 Agent 直接派发子 Agent 很相似，两者都由 Agent 负责规划和协调。区别在于，直接派发时，主 Agent 需要在对话中逐轮判断该启动哪个任务、等待哪些结果，再把结果交给后续任务；借助 CodeDAG 时，它把明确的安排写成工作流，由编排引擎按依赖调度任务、管理分支隔离并汇集结果。编排 Agent 则通过工具查看执行现场、作出判断和实施干预，借助一个精确、功能完整的执行系统来落实自己的安排。

工具的使用扩大了人类能够组织和完成的工作规模。我们相信，编排工具也能为 Agent 提供同样的杠杆，让它管理超出单个会话协调能力的工作。精确的执行系统并不排斥 Agent 的自主性，反而让它的规划与判断能够作用于更大规模的任务，进一步减少人需要亲自安排和协调的工作。

多一种智能，多一种制衡

当 Agent 既承担执行，又越来越多地承担编排，软件开发的自动化程度与规模便会进一步提高，人能够亲自检查的部分所占比例也会越来越小。除了系统本身的约束，还可以由谁来验证与制衡执行中的 Agent？我们的答案是：其他不同的 Agent。

这也是 CodeDAG 选择不绑定单一 Agent Harness 或单一模型的原因。用户可以根据任务选择执行者，也可以让 Claude Code 与 Codex 在同一工作流中分工与互审。一个 Agent 的判断不必成为最后结论，另一个 Agent 可以从不同角度验证它，质疑它依赖的前提，找出它没有注意到的问题。

制衡的价值不只来自 Agent 的数量，更来自判断的差异。这种合作与对抗可以沿着明确的任务边界展开：各自独立形成判断，再通过产物交叉核查，保留不同视角，避免过早互相影响。独立的上下文既服务于执行的稳定，也为相互验证保留了空间，让验证不再只依赖人的逐项检查。

支持多种 Harness 和模型，会增加工具适配与维护的成本；我们仍然选择保持开放，让用户根据任务选择合适的执行者与验证者。我们期待多样性带来的收益超出简单的分工：不同 Agent 的能力、视角与局限相互作用，可能产生超过各自独立行动的效果。当人的注意力不再足以覆盖每个环节时，系统的约束与不同 Agent 的相互制衡，可以共同支撑更大规模的持续开发。