用 DSH 编排 Codex 与 Claude Code：多 Agent 代码复核流程

0.1.3-alpha.1：普通子 Agent 与实验性团队分开判断

2026-09-05 的固定源码复核显示，Release 所述 Agent Team 消息变化位于实验性的团队实现；其同名 send_message 不能直接等同于下文普通直属父子 Agent 工具。本文基础案例仍保留 0.1.1-rc.2 的 Provider 适用范围，未新增运行实测。

实验性团队中，运行中的成员在步骤边界接受 steer，空闲成员可开始后续工作，离线 teammate 按实现尝试冷恢复；投递携带 team、message 和 sender 标识，并通过队列与 checkpoint 记录状态。团队成员间通信的权限与普通直属父子限制不同。该源码能力不是当前 npm 默认 Web Profile 已提供所有团队功能的证明，也不是消息必然即时送达的承诺。

审核工作流时先确认加载的是哪组工具，再记录发送对象、来源、接收状态及验收结果。保留完整任务合同，不因为有 steer 就省略上下文；不要给旧的 Codex／Claude Code 一次性 Provider 添加未经证据支持的会话连续性。

依据：实验性团队工具说明 ↗（外部链接，在新标签页打开）、消息投递实现 ↗（外部链接，在新标签页打开）。升级还需核对 Session v2 与 alpha.1 限制。

这个流程解决什么问题

这套流程用 DeepSeek Harness（DSH）保存目标和验收条件，把代码实现交给 Codex，把独立审查交给 Claude Code，再由主 Agent 汇总冲突、运行最终检查并交给人工批准。重点不是同时启动更多 Agent，而是让实现者与审查者看到同一份需求、承担不同职责，并留下可以复核的 Git diff、测试结果和问题清单。

本文依据 DSH 0.1.1-rc.2 固定提交以及 Codex、Claude Code 官方资料编写。它是一份可复现的工作流配方，不是跨产品运行报告：本站没有安装或运行 Claude Code，没有使用真实账号凭据，也没有测量速度、质量和费用。实施前应先阅读DSH、Codex 与 Claude Code 的选型边界。

先准备一个低风险任务

第一次演练不要选择部署、数据库迁移、依赖大版本升级、鉴权或生产配置。推荐使用已有测试覆盖的小型修复，例如：

修复注册表单把只包含空格的用户名当作有效输入的问题；只允许修改表单校验与对应测试，不修改 API、依赖和公共类型。

开始前人工确认：

• 工作树状态已记录，现有用户改动不会被覆盖；
• 已建立单独分支或可恢复的工作区；
• 允许修改的文件和禁止修改的范围明确；
• 测试命令、类型检查和 lint 命令可用；
• 测试数据不包含生产密钥、客户信息或私有仓库外数据；
• 实现和审查 Provider 使用的权限模式符合团队策略。

数据如何在主 Agent 和子 Agent 之间流动

用户需求与人工边界
        ↓
DSH 主 Agent：整理任务合同与验收条件
        ↓ 独立、自包含任务文本 + 父 Session 工作目录
Codex 产品进程：实现、测试、返回变更摘要
        ↓ 工作树 Git diff + 测试证据
DSH 主 Agent：冻结实现结果，生成审查任务
        ↓ 原始需求 + 验收条件 + diff 范围
Claude Code 产品进程：只读复核、返回问题清单
        ↓ 文件位置 + 影响 + 复现或修复建议
DSH 主 Agent：处理分歧、运行最终检查、汇总证据
        ↓
人工批准提交、推送或部署

DSH 固定版本的 Codex 和 Claude Code Provider 会把父 Session 的工作目录传给新的产品进程，但不会复制父对话。每次调用都是新进程和不可恢复的产品对话。因此任务文本必须自包含；如果审查者提出问题，不能假设下一次调用记得上次结论，应把需求、diff 状态和待解决问题重新写进新任务。

alpha.4 起，持续子 Agent 可以受限双向跟进

0.1.2-alpha.4 用 send_message 取代旧的单向 report 工具。首次派发仍要提供完整、自包含的任务合同；对于已经创建且可继续的直属子 Agent，父 Agent 可以发送补充要求。常驻可继续的子 Agent 也能在直属父 Agent 在线时返回问题或中间证据，最终结果仍由主 Agent 汇总并交给人工验收。

这不是任意 Agent 消息总线：只支持直属父子，不支持兄弟 Agent 或任意深层后代；冷恢复只覆盖直属子 Agent；父 Agent 离线时没有持久化父级邮箱。目标正在工作时，消息会在最近的步骤边界引导当前任务；目标空闲时才开始后续 turn。不要把 report 和 send_message 当作仅改名，也不要把“已发送”写成跨进程保证送达。

本文的主流程仍以 rc.2 为可安装基线。上述段落来自 alpha.4 固定源码审阅，本站没有运行 alpha.5 多 Agent 工作流；准备评估时先看alpha.5 版本与兼容说明。

第一步：由主 Agent 建立任务合同

不要直接发送“修一下表单”。先形成一份所有参与者共用的任务合同：

目标：拒绝只包含空格的用户名，同时保持已有合法用户名行为不变。
允许范围：src/validation/username.ts、对应测试文件。
禁止事项：不修改 API、依赖、数据库、公共类型或页面样式。
验收条件：
1. 空字符串和全空格字符串均返回原有无效状态；
2. 前后带空格的合法名称按现有产品规则处理；
3. 原有测试全部通过；
4. 新增覆盖空格输入的回归测试。
交付物：变更摘要、文件清单、测试命令与结果、已知限制。
停止条件：需要修改允许范围外文件，或无法确认现有产品规则时停止并报告。

任务合同由主 Agent 保存。实现 Agent 和审查 Agent 都从这里获得原始要求，不能只读取前一个 Agent 的摘要。

第二步：让 Codex 实现并提交证据

给 Codex 的委派任务应包含完整合同，并说明当前角色只是“实现者”：

你是实现 Agent。请在当前 Git 工作区完成下面任务，不要提交、推送或部署。

[粘贴完整任务合同]

开始前检查相关代码和现有测试。只修改允许范围内的文件，运行必要测试。
最后返回：
1. 修改了哪些文件以及原因；
2. 运行了哪些命令和实际结果；
3. 哪些边界尚未验证；
4. 需要独立审查重点关注什么。
如果必须超出允许范围，停止并说明原因。

实现完成后，主 Agent 不接受一句“已完成”作为证据。至少收集：

第三步：让 Claude Code 独立审查

审查任务应默认只读，并同时包含原始任务合同和待审查 diff 的范围。不要只说“检查 Codex 做得对不对”，也不要把实现者的自我评价当成事实。

你是独立审查 Agent。不要修改文件、提交、推送或部署。

[粘贴完整任务合同]

请审查当前工作树相对基准提交的实际差异，并独立检查：
1. 是否完整满足每条验收条件；
2. 是否修改了允许范围外的文件或行为；
3. 是否遗漏空值、空格、Unicode、兼容性等边界；
4. 测试能否证明修复且不会轻易误通过；
5. 是否引入权限、凭据、网络或供应链风险。

每条发现必须包含严重级别、文件位置、可观察影响和验证方法。
没有发现时，也要列出实际检查范围和未覆盖部分。

Claude Code 官方文档支持为专门任务创建拥有独立上下文、工具和权限的子 Agent。这里利用的是职责隔离，不是对某个产品质量的预设。团队也可以调换实现者和审查者，但必须保持任务合同和验收标准不变。

第四步：处理实现与审查分歧

主 Agent 把每条审查意见分成四类：

不要让两个 Agent 在同一文件上并行反复覆盖。更稳妥的顺序是先完成一个实现快照，再进行只读审查；需要返工时，由主 Agent 明确下一轮唯一写入者。

第五步：最终验收与人工批准

主 Agent 应重新执行最终门禁，而不是复用实现者的口头结论：

git diff --check

再运行项目实际定义的测试、类型检查和 lint 命令。不要把示例命令机械复制到没有对应脚本的项目。最终汇总至少包含：

1. 原始目标和最终实现范围；
2. 修改文件及核心行为变化；
3. 实际运行的检查与结果；
4. 已解决、排除和仍未解决的审查意见；
5. 回滚方法；
6. 是否需要人工批准提交、推送或部署。

只有验收条件全部满足、未解释的高风险问题为零，并获得有权限的人批准后，才进入提交或部署。子 Agent 返回成功不等于用户目标已经验收。

哪些情况不适合这套流程

• 任务只有一个明确的小改动，协调成本高于审查收益；
• 两个 Agent 必须同时修改高度重叠的文件；
• 仓库没有测试、规格或可观察的验收方法；
• 任务依赖生产凭据、客户数据或不可逆外部操作；
• 团队无法限制子 Agent 的工作目录、工具或权限；
• 只是为了宣传“多 Agent”，没有独立且可交付的子任务。

对于简单修改，使用一个编码 Agent 实现，再用同一产品的专用代码审查功能检查 diff，通常更省成本。需要理解 DSH 的权限边界时，继续阅读DSH 权限、审批与沙箱指南；需要理解外部子进程与工具边界时，阅读DeepSeek Harness 架构解析。

本案例的验证边界

本文完成 DSH 0.1.1-rc.2 固定源码、OpenAI 官方 Codex 文档和 Anthropic 官方 Claude Code 文档审阅，并将三者的公开能力整理成可执行任务合同。本站没有运行 Claude Code 或真实跨产品委派，没有使用 API Key，也没有产生可供性能比较的运行数据。因此验证级别是 source_reviewed，不是 editor_verified；页面中的示例结果只能在读者自己的授权测试仓库中按实际命令确认。