核心思想
Claude Code Harness 是一个 MIT 许可的工作流插件，用
spec.md（产品契约）和Plans.md（任务台账）作为唯一事实来源，把智能体编码约束成”计划 → 工作 → 评审 → 发布”的五动词闭环，每个阶段都有显式关卡，并由 Go 原生运行时（冷启动 1–2ms）执行 13 条护栏规则。作者强调它是一套工作流与证据系统，而非现成的安全层——还坦率列出了版本漂移、TDD 默认不强制、基准测试偏窄、旧文档残留等 4 处毛刺。
它是一个工作流插件，而非什么神奇的安全层。
大约 7 分钟，带你看清：这个收获 1730 颗星的 Claude 插件到底交付了什么、那个把智能体编程变成”交付证据”的五动词闭环、撑起它的 13 条护栏，以及 README 没点明的 4 处毛刺。
当你把 Claude Code 放进一个代码仓库里任其驰骋时，计划停留在对话里，测试变成可有可无，代码评审来得太迟，发布说明只能凭记忆事后拼凑。
Claude Code Harness 是一个采用 MIT 许可证的插件，它把这套工作流装进一个五动词闭环，并把两个文件当作唯一的事实来源。
它所代表的转变，才是真正值得留意的地方：智能体工具正在从"对话输出"转向"交付证据"。
速览： v4.12.7、Go 原生运行时、超过 1700 颗星、超过 190 个 fork、33 个共享技能。
为什么值得一看
Claude Code 生态这一阵子悄悄走向成熟。Hermes Agent、Superpowers 等几个项目，已经越来越不像提示词包，而更像是围绕模型包裹出来的一套操作系统。Harness 也走在同一条赛道上。
它的赌注很窄、很具体：模型能写出有用的代码，但围绕它的整套流程却总在跑偏——计划悬而未决、范围悄悄膨胀、评审塌缩进实现里、发布说明靠回忆重建。
这个仓库创建于 2025 年 12 月，此后每天都有提交。到 v4.12.7 版本，它已经积累了超过 1700 颗星和超过 190 个 fork，最近一次推送在 2026-05-27。没有 Hacker News 帖子，没有 Reddit 讨论，也没有 YouTube 演示。只有一条简短的 Threads 动态，外加稳定的发布节奏。高质量，但低调得几乎没人注意。
它究竟是什么
作者是 Chachamaru，一位以日语为母语的独立开发者。他为仓库里所谓的 “vibecoders” 打造了 Harness——也就是那些独自一人、通过智能体跑完整个合同开发周期的开发者。
真正挑大梁的，是两个”唯一事实来源”文件：
- spec.md 是产品契约，规定哪些东西必须始终成立。
- Plans.md 是任务台账，记录正在做什么、已经做完什么、被什么卡住了。
五个动词命令架设在它们之上：/harness-setup、/harness-plan、/harness-work、/harness-review 和 /harness-release。安装之后，默认做法就从”让智能体去写代码”变成了：先写规格说明，只实现已批准的那一小片，验证，独立评审，再打包成证据。
这个仓库不是什么小小的提示词包。它交付了一份 Claude 插件清单、一份 Codex 插件清单、OpenCode 镜像、一套 Go 运行时、钩子（hook）定义、安装脚本、33 个共享技能、测试，以及发布工具链。共 1529 个被追踪的文件。按字节数算，Shell 以 2.13 MB 居首，Go 以 1.56 MB 紧随其后，再往下是 JavaScript、TypeScript，以及薄薄一层 Python。
它是怎么运转的
运行闭环
计划、工作、评审、发布。每个阶段都有一道明确的关卡。用户必须先批准生成出来的契约，才会写下任何一行代码。评审中发现的重大问题会阻断”完成”。发布前的预检（preflight）会在任何最终动作之前，逐一核对标签、版本号、变更日志和证据打包。
有一条规则为整个闭环定下了基调：智能体没有亲眼见过的数据，就保持”未知”，而不是被悄悄地编造出来。这一点是写在规格说明里的，而非靠默契心照不宣。
Go 运行时
护栏引擎从 v4.0（代号 “Hokage”）起被用 Go 重写。冷启动（cold start）的目标是 1–2 毫秒，相比之下，它所替换掉的那套老旧的 bash 加 TypeScript 路径大约要 40–60 毫秒。SQLite 通过纯 Go 驱动 modernc.org/sqlite 接入。无需 CGO、无需 Node.js，也不必安装任何编译工具链。
包的结构本身就在强制保证这份速度契约：
- hook-fastpath 负责规则评估、编解码和类型定义。没有文件 I/O，没有网络，没有 goroutine。
- worker-runtime 负责 SQLite 存储、会话生命周期、breezing 编排，以及 OTel 导出。
配置则被收拢进单独一个文件。harness.toml 是源头，harness sync 会从它重新生成 plugin.json、hooks.json 和 settings.json。用户只改一个文件，而不是五个。
这个仓库通过 hooks/hooks.json 接驳了 58 个命令钩子条目和 4 个智能体钩子条目，覆盖了 pre-tool、post-tool、permission、session、notification、stop 和 task 等各类事件。
其中只有 pre-tool、post-tool 和 permission 这三条路径是 Go 二进制文件直接掌管的。其余的仍然要绕道 shell 处理器；而当钩子配置依赖那些围着二进制文件包了一层的遗留 bash 包装器时，项目自带的 doctor 会发出警告。
护栏规则
运行时内置了十三条规则（R01–R13），每一条都绑定到一个具体的工具操作面。
- 拒绝（Deny）规则 会拦截 sudo、git push —force、—no-verify、—no-gpg-sign，对 .env/.git//*.pem/*.key 的写入，以及对受保护分支的 git reset —hard。
- 询问（Ask）规则 会在遇到 rm -rf、安装软件包、force-with-lease 推送、npx，以及直接推送到 main 或 master 时暂停下来确认。
- 警告（Warn）规则 覆盖对疑似密钥文件的读取（仍然允许，但会被标记出来），以及对 package.json、Dockerfile 和 CI 工作流的修改。
设计文档里坦诚地写明了它的取舍：钩子系统在遇到基础设施层面的错误时会”失败放行”（fail open）。那些确定性的拒绝规则只要能跑起来，就照样会拦截。但万一钩子的管道本身坏掉了，这套设计宁愿放行该动作，也不愿打断用户的会话。
宿主适配层级
Harness 会明确说出它支持什么、不支持什么。能力矩阵列出了四个层级：
这个项目明确拒绝去声称自己无法证明的功能对等。这种”拒绝”本身，就是一处值得留意的设计抉择。
如何上手
完整的操作指南见文末附录。
在 Claude Code 里敲四行：
claude
/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setup然后发出一个小小的初始请求：
/harness-plan Improve the README onboarding flowHarness 会写入或更新 spec.md 与 Plans.md，并返回一份计划，包含范围、验收标准、依赖、未知项和停止条件。用户要做的是批准或纠正，而不是手写这份计划。
它要求 Claude Code v2.1+ 以及对仓库的写入权限。老用户在重装之前，应当先运行 bin/harness doctor —migration-report。它会盘点出陈旧的插件缓存、重复的 Codex 技能、OpenCode 文件以及旧的符号链接——但一个都不会删。
AlphaSignal 的看法
采用之前，有四处毛刺值得你心里有数。
已检出仓库内部的版本漂移。 VERSION、plugin.json 和 harness.toml 都报告为 v4.12.3，而内置的二进制文件（./bin/harness version 和 ./bin/harness-darwin-amd64 version）却报告为 4.11.4（Hokage）。项目自带的 doctor 能逮住这个不一致，并建议执行 cd go && make install。通过插件市场安装会带上正确的二进制；而”克隆后直接从 bin 运行”那种安装方式不会。
默认并不强制 TDD。 README 暗示在工作步骤会做 TDD 验证，但 harness.toml 出厂时 TDD 强制是关闭的。R14——也就是那条 TDD 护栏——被注册为本地试用路径，而非一条阻断性规则。
Breezing 基准测试比看上去要窄。 报告显示，在 30 次运行中，带验证指令时为 14/15 通过，不带时为 3/15。报告自己也点明了局限：只有三个任务、一个模型（通过 Z.AI 的 haiku 档位调用的 GLM-4.5-air）、表面之下只涉及两类真实的 bug、一个两阶段自适应设计，而且它测的是”验证指令”而非完整的 Breezing 流水线。是有用的信号，但不能算系统有效性的证明。
残留自 TypeScript 时代的文档漂移。 docs/CLAUDE_CODE_COMPATIBILITY.md 仍然引用着 v3.10.2 和 Node.js 要求，而当前的 README 和 Go 运行时规格都说不再需要 Node。一些技能文件里也还残留着已被删除的概念。项目里之所以存在 deleted-concepts.yaml，恰恰就是因为每次大版本迁移之后，这类残渣总会冒出来。
更站得住脚的论断，反而是那个更收敛的论断。对 Claude Code 用户来说，Harness 提供了一种结构化的方式，把智能体的工作变成经过评审、有证据背书的仓库变更。把它当成一套工作流与证据系统来用，而不是一层已经做完的安全层。
当你放手让模型来开车时，你的智能体工作流里哪一环最容易松垮：计划、测试，还是发布说明？
所有来源链接都在第一条回复里。近期更新的完整拆解 + 每日信号，尽在我们的 newsletter（链接见简介）。
附录：完整命令演练
安装与设置
claude
/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setupSetup 会安装项目指引、命令操作面、钩子，以及一次基线检查，让整套工作流从一个已知状态出发。
/harness-plan <request>
示例：
/harness-plan Add a JSON export endpoint to the user API它会产出：
- 一份写入 spec.md 的规格增量（spec delta）；如果该请求并不改变产品契约，则给出一条有据可查的”跳过规格的理由”（spec skip reason）。
- 写入 Plans.md 的任务行，包含范围、验收标准、依赖、未知项和停止条件。
用户要在写下任何一行代码之前，先批准或纠正这份契约。
/harness-work <task>
示例：
/harness-work 1.1.1实现一个已批准的切片，并记录验证证据。工作步骤拒绝默不作声地扩大范围。一旦工作量超出了已批准的那一行，闭环就会停下来发问。
/harness-review
它作为一个独立步骤运行，不会被搅进实现过程里。重大问题会阻断”完成”，次要问题则作为建议返回。结论格式是固定的：APPROVE 或 REQUEST_CHANGES。
/harness-release —dry-run
核查变更日志状态、VERSION/plugin.json/harness.toml 三者间的版本同步、标签边界，以及发布证据的打包。预演（dry-run）会报告”将会发生什么”，但不执行任何实际的发布动作。
Codex CLI 路线（只是兼容，并非对等）
git clone https://github.com/Chachamaru127/claude-code-harness.git
cd claude-code-harness
./scripts/setup-codex.sh --user镜像后的技能以 harness-plan](https://x.com/search?q=%24harness-plan&src=cashtag_click)、[harness-work、$harness-review 的形式调用。Codex 能拿到契约注入和运行后检查，但拿不到 Claude Code 的 pre-tool 钩子强制能力。
OpenCode 路线（镜像 + 引导）
/path/to/claude-code-harness/scripts/setup-opencode.sh它把 harness 的技能镜像成 OpenCode 兼容的文件。运行时对等并不在承诺之列。
老用户健康检查
bin/harness doctor --migration-report它会盘点陈旧的 Claude 插件缓存、缺失的斜杠命令条目、重复的 Codex 技能、OpenCode 文件、备份路径，以及 harness-mem 状态。什么都不会删。在重装或清理之前，先跑一遍它。
相关笔记
- 不碰模型与提示词，让编程智能体更聪明 —— 同样出自 AlphaSignal，讲如何在不动模型与提示词的前提下让编程智能体更强
- Harness 工程：智能体时代真正的护城河 —— 为什么 harness 才是智能体时代真正的护城河
- Agent Hooks：智能体工作流的确定性控制 —— 用钩子为智能体工作流加上确定性护栏，与本文的 13 条护栏规则呼应
- 你不知道的 Claude Code：架构、治理与工程实践 —— Claude Code 的治理与工程实践全景