Claude Code Harness 是一个为 Claude Code 打造的 disciplined delivery loop（纪律化交付循环）。它的核心目标是解决一个日益严重的问题：
Claude Code 很强，但原始的 Agent 工作容易漂移——计划活在聊天记录里，测试变成可选项，审查来得太晚，发布证据每次都要靠记忆重新构建。
Harness 将这种散乱的工作方式转变为一个可重复的执行路径：
/harness-plan、/harness-work、/harness-review、/harness-sync、/harness-release，保持接口面小而清晰team_validation_mode，并通过 team/sub-agent 或 manual-pass 视角验证 spec/Plans 一致性、记忆复用、产品适配、安全适配和实操性unknown，而非被静默编造Harness 的核心架构围绕 source-of-truth loop（真相源循环）构建：
Investigate → Plan → Work → Review → PR → Release
↓ ↓ ↓ ↓ ↓ ↓
Evidence spec.md Code Verdict Evidence Tag/Release
& Unknowns Plans.md & Tests (Blocker) Pack Artifacts
关键设计决策：
unknown 状态/harness-review 与实现分离，重大发现会阻塞完成/harness-release 只在实现和审查完成后检查发布就绪状态| 技术 | 用途 | 选型理由 |
|---|---|---|
| Go | 核心 guardrail 引擎 | 原生性能、单二进制分发、无运行时依赖 |
| Bash Scripts | 工具适配层（Codex/OpenCode） | 最小侵入性，兼容现有工具链 |
| Claude Plugin Marketplace | Claude Code 集成 | 原生集成，用户体验一致 |
| Markdown | 计划、规格、证据存储 | 人类可读、版本可控、工具可解析 |
Go 原生核心是一个关键选型：它意味着用户不需要安装 Node.js 就能使用 Harness 的 guardrail 引擎。这对于需要在 CI/CD 环境中运行 guardrail 的团队尤其有价值。
非平凡计划会触发 team_validation_mode，通过多个视角验证计划：
这种模式借鉴了多层次验证的思想，避免单一视角的盲点。
/harness-release 不会盲目打包，而是检查：
这确保了 “PR ready” 不等于 “release ready”。
bin/harness doctor --migration-report 不会删除任何数据，而是盘点：
这种模式让用户在清理前先了解现状，避免误删。
以 /harness-plan 为例：
spec.md 和 Plans.md 草稿team_validation_mode整个流程中，数据流向是：
User Input → Harness → spec.md + Plans.md → Approval → Work Execution
↓ ↑
Validation Report Approved Contract
claude
/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setup
| 工具 | 安装命令 |
|---|---|
| Codex CLI | scripts/setup-codex.sh --user |
| OpenCode | scripts/setup-opencode.sh |
安装完成后，运行一个小请求测试：
/harness-plan Improve the README onboarding flow
Harness 会为你生成 spec.md 和 Plans.md 草稿，你只需批准或修正。
然后执行最小的批准任务：
最后运行审查：
/harness-plan Add user authentication with JWT
Harness 会生成：
spec.md：包含范围、验收标准、依赖、未知项、停止条件Plans.md：任务切片和执行顺序你的工作不是手写计划，而是在执行前批准或修正生成的合同。
# 执行单个任务
/harness-work 1.1.1
# 执行已批准计划的全部任务
/harness-work all
/harness-work 会：
独立的审查分离了实现和审查角色，重大发现会阻塞完成。
/harness-release 会检查发布就绪状态、CHANGELOG/tag 边界，并打包证据。
对于更大的任务列表，Harness 支持 Planner/Critic/Worker 风格的团队执行。
这仍然受计划质量和审查的约束。
通过 scripts/codex-companion.sh，Harness 支持 schema 支持的 Codex 第二意见。
注意：原始的 codex exec 不是 Harness 伴生路径。
scripts/setup-opencode.sh 会将 Harness 引导镜像到 OpenCode 兼容的界面。
注意：不声称真实的运行时 parity。
配置 harness-mem 后，Harness 支持跨会话的项目范围记忆和召回。
清除记忆仍然是显式的。
假设你要为一个 Express.js 项目添加 JWT 认证：
/harness-plan Add JWT authentication middleware to Express.js app
Harness 生成 spec.md：
# Spec: JWT Authentication
## Scope
- Add JWT middleware for protected routes
- Create login endpoint that returns JWT
- Add refresh token mechanism
## Acceptance Criteria
- [ ] Unauthenticated requests return 401
- [ ] Valid JWT allows access
- [ ] Expired JWT returns 403
- [ ] Refresh token rotates properly
## Unknowns
- Secret storage mechanism (env vars? Vault?)
- Token expiration time (default 1h?)
## Stop Conditions
- All acceptance criteria verified
- No major security findings in review
Harness 实现切片，添加测试，运行验证。
独立审查可能发现：secret 应该存在环境变量中，而不是硬编码。
根据审查反馈修复，然后：
问题：/plugin install 失败，提示兼容性问题。
解决方案：
bin/harness doctor --migration-report 检查环境问题：/harness-plan 生成的计划不实用。
解决方案：
spec.md 和 Plans.mdteam_validation_mode 是否启用（非平凡计划）问题：Harness 运行缓慢。
解决方案：
harness-mem 的召回范围问题：在 Codex CLI 中使用 Harness 时功能受限。
解决方案：
internal-compatible 状态，不是所有功能都支持raw codex exec 作为 Harness 伴生路径scripts/codex-companion.sh 进行 schema 支持的伴生审查问题：从旧版本迁移时担心数据丢失。
解决方案：
bin/harness doctor --migration-report 先盘点现状Claude Code Harness 填补了 Claude Code 强大能力与工程化纪律之间的空白。通过 5 个动词技能和 Go 原生核心，它将散乱的 Agent 工作转化为可追踪、可验证、可发布的工程流程。
适用场景：
不适用场景：
Harness 的哲学是：你的工作不是手写计划，而是在执行前批准或修正生成的合同。这种方式既保持了 Agent 的灵活性，又引入了工程化的纪律。
项目地址：https://github.com/Chachamaru127/claude-code-harness
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。