企业官网建设流程全解析

Comet Supervisor多Agent并行开发实战：复杂需求如何按DAG依赖拆解协调交付

【免费下载链接】cometComet: agent skill harness for turning ideas into evaluated workflows项目地址: https://gitcode.com/rpamis/comet

Comet Supervisor 是 Comet（agent skill harness，把想法变成可评估工作流的 Agent 技能框架）内置的多Agent并行开发能力：它把一个复杂需求按DAG 依赖拆成多个子任务（Child Change），让多个 Agent 在隔离的 worktree 中并行实现与验证，再按依赖顺序合并、统一验收。这篇文章带你快速理解它的工作原理与使用流程。

为什么需要 Comet Supervisor 多Agent协作？

传统单 Agent 开发模式有个天然瓶颈：一个会话、一条串行流水线。当需求同时包含"新增 API、改造 CLI、更新文档、补充端到端测试"等多个交付物时，只能排队执行，耗时长且上下文容易膨胀。

Comet Supervisor 的解法是 Durable DAG Orchestration（持久化 DAG 编排）：

• 规划：Agent 把一个父需求拆成多个 Child Change，并声明depends_on依赖关系
• 调度：Runtime 校验依赖图无环，计算当前可运行的任务集合（ready set），控制并发上限
• 执行：多个 Agent 各自进入 Runtime 创建的独立 worktree，互不干扰
• 恢复与集成：进程中断后可恢复，结果按依赖顺序合入统一集成分支，最后只做一次整体验证与收尾

一句话总结：多Agent是加速器，DAG 与 Runtime 才是可靠性边界——即使宿主平台不支持多Agent，单 Agent 顺序执行也永远可用，只是快慢之分。

三步上手：一个需求、多个Agent、一次交付

第一步：确认拆分，把复杂需求变成子任务 DAG

在 Shape 阶段，Agent 会按"可独立实现、可独立验证、真实依赖"三个标准拆分需求，生成精简的children.yaml计划（schema 为comet.native.children.v2），每个 Child 只含名称、摘要和depends_on依赖。

比如一个典型依赖图：

A（新增领域 API）──> B（CLI 调用 A）──> D（端到端测试） C（独立更新文档）───────────────────> D

Runtime 会做确定性校验：名称重复、依赖不存在、依赖成环都会被直接拒绝。跨模块需求还会被要求指定一个 integration Child，只负责连接、fallback 和端到端验证。拆分确认规则详见 supervisor-plan 规范。

💡关键设计：B depends_on A不只代表"等 A 完成"，而是B 的源码基线必须包含 A 验证通过的 commit——避免出现"状态上有依赖、代码上没继承"的假并行。

第二步：按 readyChildren 并行派发子任务

用户只需确认一次父级 Shape，之后 Runtime 只派发readyChildren中依赖已满足的任务，依赖未满足的 Child 不会启动。默认并发上限为 2（可用--max-parallel 1退化为串行）。

派发时每个 Child 会携带完整任务包：worktree 路径、基线 commit、runId、验收项和停止条件。不同宿主平台有不同的承载方式：

• Codex：为每个 ready Child 创建一个独立会话，进入 Runtime 指定的 worktree 工作
• Claude Code：创建 Agent Team，每个 Child 对应一个具名 teammate
• 能力不可用时：自动退化为 subagent 或单会话串行，范围与顺序语义完全一致

多会话协作的宿主适配协议见 Supervisor 多会话调研。

第三步：顺序集成、统一验收、一次收尾

每个 Child 走完active → verified → integrated三步才算完成：

1. 独立验证：每个 Child 由只读 Verifier 逐项评估验收项，失败或中断不算通过
2. 串行集成：Child 通过后，Runtime 把 commit 合入父级 integration worktree 并跑集成检查，通过后才解除后继 Child 的依赖
3. 最终 Verify：所有 Child 集成后，父级在集成 worktree 上对每个验收项做最终验证

如果最终验证发现已确认范围内的失败，协调者会追加一个"修复 Child"，不会改写已集成的历史任务；只有新增用户可见范围时才回到 Shape 重新确认。整个协调协议（派发、回报、集成、取消、恢复）完整定义在 Supervisor coordination 一节。

📌可靠性细节：Runtime 用runId拒绝重复和过期的任务回报；Worker 使用可过期 lease 而非永久锁；即使父级 Runtime 状态丢失，也能从计划、Child 状态和 Git 重建——多Agent崩溃不会把用户卡死。

如何观察和监督并行进度？

开发过程中，可以直接用 Comet 的三栏 Dashboard 在浏览器中查看 Native 进度、Git worktrees、验收结果与归档状态，以及当前变更的下一步建议：

日常入口只需记住两条技能命令：用/comet进入项目配置的 Native 或 Classic 工作流，用comet native status --json随时查看父级与子任务状态。

实现源码在哪里看？

想深入了解 Comet Supervisor 的实现，可以从这些模块入手：

• 核心协调逻辑：native-supervisor.ts（父级协调器门面）、native-children.ts（子任务合同与 DAG 校验）、native-children-contract.ts
• 子任务集成与验收：native-supervisor-check-binding.ts、native-supervisor-evidence.ts、native-supervisor-state.ts
• 工作区隔离：native-supervisor-workspace.ts
• 工作流指令定义：comet-native SKILL 及其 命令参考
• 架构设计文档：Supervisor 计划规范、多 Change 依赖编排调研

常见问题 FAQ

Q：Comet Supervisor 和普通多开几个 Agent 有什么区别？A：普通多开只解决"并行"，Comet Supervisor 还保证依赖正确性（ready set 计算、基线 commit 继承）、状态可恢复（lease、runId 去重）、结果可验收（逐项 Verifier + 最终统一 Verify），最后只交付一个经过整体验证的集成结果。

Q：我的平台不支持多Agent会话怎么办？A：完全没问题。Supervisor 的调度语义与执行速度解耦，宿主能力不足时自动退化为 subagent 或单会话串行执行，DAG 依赖、集成顺序和验收标准保持一致。

Q：并发可以调高吗？A：可以，通过comet native next <change> --max-parallel N指定，默认为 2。并发只影响速度，不影响正确性。

🚀总结：Comet Supervisor 让复杂需求的交付变得可拆解、可并行、可恢复——一份父级计划、一次依赖确认、一个统一状态视图、一次最终交付决定，这正是多Agent并行开发应有的样子。

【免费下载链接】cometComet: agent skill harness for turning ideas into evaluated workflows项目地址: https://gitcode.com/rpamis/comet