Claude Code Harness：把代理编码变成有门禁的交付循环
Claude Code 专用开发工具 - 通过自主计划工作审查周期实现高质量开发。
秒懂
- 它是什么？
- Claude Code Harness 用 spec、计划、任务账本、独立审查和发布前检查约束代理编码过程。
- 适合谁用？
- 它适合需要审计代理改动、并愿意先批准计划的工程团队，不适合把代理当作无确认自动部署器的场景。先运行 `/harness-setup`，再用 `/harness-plan Improve the README onboarding flow` 检查生成的 spec.md、Plans.md、未知项和停止条件是否符合你的仓库。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Shell（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
从聊天请求转成可批准的合同
Harness 针对的是代理编码中的流程漂移：计划留在聊天里，测试在期限压力下被省略，审查晚于合并，发布证据依赖事后回忆。它要求先写规格，再只实现获批切片，接着验证、独立审查，最后打包证据。项目 README 明确说它不会让模型变聪明，而是固定模型周围的程序与边界。
`/harness-plan` 生成 `spec.md` 和 `Plans.md`，内容包括范围、验收标准、依赖、未知项和停止条件。使用者需要批准或修正这份契约，代理才继续执行。这个设计把“需求理解错了”的风险提前暴露，但也把人的审批变成必经步骤；若团队不维护计划，工具本身不能替代产品决策。
Harness 的流程价值取决于每个阶段留下的材料是否真的被下一阶段消费。试验时应检查 spec.md 的未知项不会被自动填成事实，Plans.md 的验收条件能在 review 和验收视图中逐项对应，并确认停止后的 JSONL 记录没有泄露命令正文。只有当 work、sync 和 release 对同一任务给出一致结果，计划账本才有实际审计价值。
采用 Harness 时，计划批准不是形式步骤。计划中的范围决定代理可以触碰哪些文件，验收标准决定 review 是否有明确依据，停止条件决定不确定信息如何处理。工作阶段完成后，应把实际 diff 与 Plans.md 逐项对比；同步阶段发现漂移时，先修改计划或停止任务，不应让发布阶段替未获批改动背书。安全日志中的规则编号、类别和裁决可以帮助复盘，但命令文本不写入也意味着操作者要保留自己的任务记录。
Claude Code Harness 的核心不是命令数量，而是每一步都留下可检查的中间结果。规格描述意图，计划列出可执行任务，工作阶段产生代码，审查阶段提出独立判断，同步阶段揭示漂移，发布阶段整理证据。安全引擎把高风险动作放在调用前处理，JSONL 记录让停止原因可追踪。这个流程能减少口头状态，但并不会自动替人确认需求、审阅代码或承担发布责任。
Harness 也把未知信息保留为 unknown，避免代理用猜测填补空白。
对 Claude Code Harness 而言，流程材料是交付证据的一部分。spec.md、Plans.md、任务账本、审查结果、同步报告和发布前验收应能互相指向。若某项改动无法对应批准任务，工作应停在 review 或 sync，而不是进入 release。安全规则的裁决记录可以辅助复盘，但仍需结合仓库权限、令牌范围和部署环境完成团队自己的检查。
阅读项目材料时，最有用的做法是把已声明的能力、尚未说明的边界和可以重复执行的检查分开记录。这样既能保留项目自己的定位，也能避免把示例命令误读成完整部署方案，把统计数字误读成质量结论，把许可证名称误读成安全保证。对于需要长期运行的组件，还应保存版本、配置、输入、输出和失败日志，升级后用同一组样本比较变化。对于只在本机试用的工具，则应先清理测试凭据和临时数据，再结束试验。
五个动词串起一次交付
Harness 的主表面由 plan、work、review、sync、release 五个动词组成，安装阶段另有 `/harness-setup`。`/harness-work` 实现一个批准的任务，`/harness-work all` 执行整个已批准计划；计划要求测试时，工作阶段需要遵守 TDD 门槛。`/harness-review` 与实现分离，重大发现会阻止完成。
`/harness-sync` 比较计划和实际实现，报告漂移；`/harness-release` 只把通过验证的证据放入 CHANGELOG、标签和发布。阶段之间留下的是下一阶段所需材料，而不是一句“已经完成”的状态。实际采用时，应先用一个小任务观察每个阶段产生的文件和失败行为，再扩大到全计划运行。
运行时地板和项目护栏不是一回事
每次工具调用会先由 Go 引擎裁决。运行时地板覆盖计费、网络出口、秘密读取、生产部署，以及任务工作树之外的破坏，README 将其描述为五类不可覆盖的拒绝。配置、环境变量和权限模式都不能绕过这一层。
R01 到 R15 是可调护栏，涉及向 `main` 直接推送、写入受保护路径、强制推送和历史重写等操作，部分规则可由项目配置。风险确认移到计划阶段，并携带过期时间、任务范围和使用次数。每次停止写入 JSONL 日志，只记录规则、类别和裁决；命令正文不落盘，通常只留哈希与长度，秘密读取和计费连这些也不记录。这里是流程承诺，不等于独立安全审计。
多会话通信解决的是状态盲区
多个代理在同一仓库或不同 worktree 工作时，最危险的不是少发一条消息，而是错误理解别人已经改了什么。Harness 维护本机活动会话 roster，路径通过 `git --git-common-dir` 解析，因此可以看到其他 worktree。`bin/harness session list` 显示 team 和 agent；`bin/harness inbox send --team <t> --from <a> --to <b> --subject <s> "<body>"` 发送消息。
这套通信层能让工作边界显式化，却不会自动解决冲突。采用者仍需把文件范围、任务状态和交接内容写进计划或消息，并在 review 阶段检查实际 diff。README 提及多代理共享文件的失败风险，但该数字属于项目材料中的引用，不能当作你的仓库一定会得到同样比例。
非工程师看到的是进度证据
项目提供三个单屏 HTML 视图。计划简报展示理解、选项、风险和验收标准；进度视图展示进行中、待办、完成数量和漂移警报；验收视图在发布前展示每项标准的通过或失败，并允许发布、等待或拒绝。这些视图是判断进度的界面，不是正确性的证明。
安装路线覆盖 Claude Code 插件市场、Codex CLI 的 `scripts/setup-codex.sh --user`、Cursor 的 `scripts/setup-cursor.sh` 和 Grok 的 `scripts/setup-grok.sh`。README 还列出候选或内部兼容工具，并要求宿主通过各自 H1-H8 检查后才升级支持层级。现有用户可用 `bin/harness doctor --migration-report` 盘点过期缓存和状态，文档称该动作不会删除内容。
编辑结论
它适合需要审计代理改动、并愿意先批准计划的工程团队，不适合把代理当作无确认自动部署器的场景。先运行 `/harness-setup`，再用 `/harness-plan Improve the README onboarding flow` 检查生成的 spec.md、Plans.md、未知项和停止条件是否符合你的仓库。
社区笔记