harness-subagent 上手：让 Claude Code 调度 Codex 与 Grok，跨厂商交叉校验自己的盲区

8 月下旬，开发者 ptmrio 发布开源工具 harness-subagent：你可以停留在自己惯用的主编程智能体里（Claude Code、Cursor Agent、Grok Bot……），把子任务以一次性子代理（one-shot subagent）的形式分派给其他 Harness（Codex、Grok Build、GPT 等）执行，再由主代理综合结果。它背后是一句很扎心的理念——「另一个 Harness 不是神谕」（The other harness is not an oracle）：让模型审查自己的工作，只会复现自身的盲区；引入不同厂商模型交叉校验，才能发现单一模型的系统性缺陷。

⚙️ 本教程适合：已经在用 Claude Code / Codex / Cursor 的开发者与团队，想用「跨厂商交叉校验」提升 Agent 产出质量。前提是你至少装好了两个编程 Agent 运行时。

先搞懂：为什么需要「跨 Harness」编排

过去一年，OpenAI、DeepSeek 相继开源 Harness，「Agent = 模型 + 运行时」成为共识。但单 Harness 有个隐藏问题：同一套模型生态，盲区往往高度重叠。你让 Claude Code 自己审查自己写的代码，它大概率自信地点头——因为「错得一致」也算一致。harness-subagent 的思路是引入异质性：

模式	做法	典型问题
单 Harness 自查	让 Agent 审自己的产出	复现自身盲区，抓不到系统性错误
单模型多轮	同模型反复改	换汤不换药，token 白烧
跨 Harness 交叉	用另一家的 Agent 审	视角独立，容易暴露盲区（本教程）

不是「另一个 Harness 永远对」：跨厂商交叉校验只是引入独立视角，结果仍需人工判断。把它当「第二双眼睛」，不是「第二台裁判」。

Step 1：了解它的三个接口

1 跨框架调用的四种入口

harness-subagent 通过现有 CLI 接口
实现跨框架调用，不侵入各家工具：

1. Claude Code headless 模式
   · claude -p "任务" 非交互执行
   · 适合作为「主代理」

2. Codex exec
   · codex exec "任务" 一次性执行
   · 适合作为「子代理」被调度

3. Grok Build CLI
   · grok build "任务" 云端执行
   · 数字员工式按任务交付

4. 兼容 Agent Skills 规范
   · 技能文件夹可以被
     任一 Harness 读取
   · 技能资产跨框架复用

核心关系：
主 Harness（你习惯的编辑器）
  → 分派 one-shot 子代理
  → 到其他 Harness 执行
  → 取回结果综合

💡 想先补 Harness 基础？可参考《Codex Harness 三层接口》与《DeepSeek Harness 子代理编排》，概念一脉相承。

Step 2：安装与前置准备

2 把两三个 Harness 装齐

1. 确认主 Harness 可用
   · 示例：Claude Code 已登录
   · 任意目录执行 claude -p "hi"
     能正常返回

2. 安装子代理 Harness
   · Codex CLI：
     npm i -g @openai/codex
     codex login（配 API Key）
   · Grok Build CLI：
     按 xAI 官方文档安装
   · GPT 类：准备 OpenAI Key
     或走 Responses API

3. 拉取 harness-subagent
   git clone
     https://github.com/ptmrio/
     harness-subagent
   cd harness-subagent
   npm install

4. 验证联通
   · 用自带的 demo 任务跑一遍
   · 主→子一次往返成功即可

密钥安全：多个 Harness 意味着多份密钥。建议用系统 keychain / 环境变量注入，别写进配置文件明文；可参考《凭证脱敏》的做法。

Step 3：配置「子代理花名册」

3 让主代理认识各位「外援」

在配置里注册可调用的子代理，
每个子代理 = 一个 Harness 入口：

[codex-reviewer]
  harness = "codex"
  mode = "exec"
  prompt = "以资深审查者身份，
    独立审查以下代码，找
    出逻辑与安全问题，不
    要客气，只给结论"
  budget = 200000   # token 上限

[grok-planner]
  harness = "grok"
  mode = "build"
  prompt = "给这个任务做
    一个实现计划，列出
    步骤、风险与验收点"

调度规则（可选）：
· 代码审查类 → codex-reviewer
· 方案规划类 → grok-planner
· 复杂推理类 → gpt-deep

命名规范：子代理名就是你在
对话里 @ 的名字，起得直白点
（如 @codex-reviewer）

💡 花名册的思路与《Hermes Bot Mode 角色 bot 花名册》类似——先定角色，再定入口，最后按任务派单。

Step 4：实战一——让 Codex 审查 Claude Code 的产出

4 最典型的用法：交叉代码审查

场景：Claude Code 完成了一个
模块重构，想确认没有盲区。

在 Claude Code 中发起：

  @codex-reviewer 审查下面
  这段代码（贴代码或给路径），
  重点找：并发安全、边界
  条件、资源泄漏，以及
  「看起来对但其实是错的」
  的地方。

harness-subagent 会：
1. 调 codex exec 独立审查
2. 取回结构化审查意见
3. 附到主会话中

常见结果：
· Codex 找到 2-3 个
  Claude 自查没发现的问题
· 也可能两边一致——此时
  信任度显著提升

关键动作：
· 把审查意见逐条
  标「同意/驳回/存疑」
· 存疑项让两边各自
  再解释一次再定

别让子代理改代码：交叉审查阶段只读不改。等人工确认了问题，再回主 Harness 统一修复，避免两套 Agent 互相覆盖文件。

Step 5：实战二——方案 PK 与结果综合

5 用异质性压制「自信的错误」

场景：要设计一个复杂系统的
架构选型，怕单一模型拍脑袋。

一次性派发多个子代理：

  @codex-reviewer 评估方案 A
  @grok-planner 评估方案 B
  @gpt-deep 做中立仲裁

取回三份意见后，主代理综合：
1. 共识点 → 高置信，直接采纳
2. 分歧点 → 逐条列出
   各方理由，交人工裁决
3. 各自盲区 → 标注「仅一方
   提到，需额外验证」

进阶：跑「对抗式评审」
· 一方当正方，一方当反方
· 逼出论证漏洞
· 参考《多 Agent 群体安全》
  的护栏思路

适用范围：
· 架构选型 / 技术评审
· 高风险代码发布前
· 需求理解对齐

💡 与《Codex 多智能体 V2 自动委派》的区别：那是在一个 Harness 内部委派，这里是跨 Harness 委派——异质性更强，代价是编排更重。

Step 6：成本护栏与落地建议

6 让跨 Harness 协作可控、可算

1. 预算先行
   · 每个子代理设 token 上限
   · 只对「高价值任务」开
     交叉校验，日常任务
     单 Harness 即可
   · 成本账可参考
     《Agent 经济学》

2. 结果要落库
   · 审查记录 + 采纳率
   · 哪些厂商组合有效，
     数据说了算

3. 人为终审
   · 交叉校验是辅助
   · 最终签字的是人
   · 出问题追责对象
     也是人，不是模型

4. 从轻到重
   · 第一周只做「代码审查」
   · 稳定后再加「方案 PK」
   · 别一上来全自动化

典型收益：
· 线上缺陷率下降（早期
  就能抓到系统性盲区）
· 对模型组合的信任
  从「感觉」变「数据」

注意合规：把代码交给不同厂商的云端 Harness，等于把代码送出内网。涉密项目请用自托管 Runner 或本地 Harness（参考《自托管 Runner》），并先过安全评审。

常见问题速查

你遇到的现象	大概率原因 & 解决
子代理一直超时	budget 太小或模型排队：调大 token 上限，或换更快的小模型
两边意见总是一致	可能同源模型：确认子代理用的真是另一家厂商的模型
审查意见太泛泛	prompt 里限定「只给具体行号 + 具体问题」，禁止客套
成本涨得厉害	只在高风险任务开交叉校验，日常开发走单 Harness
密钥泄露风险	环境变量注入 + 凭证脱敏，参考 234 号教程

📚 更多教程 📰 智能体资讯

← 返回教程中心