2.3 Harness Engineering：先理解可控系统

Harness Engineering 关心的是 Agent 在什么系统里工作：它读什么、能改什么、怎么验证、失败后怎么恢复。

本节只讲概念边界。要按步骤搭一个最小 harness，读 6.6 为一个项目搭最小 Harness；要直接复制项目模板，读 9.4 最小项目模板和落地步骤；要找日常执行提示词和检查清单，读 8. 最佳实践。

一个 harness 包含什么

输入：issue / PRD / prompt
上下文：AGENTS.md / CLAUDE.md / docs / specs
工具：shell / Git / MCP / browser / code search
执行：Claude Code / Codex / OpenCode / subagents
验证：test / lint / typecheck / build / e2e
审查：diff review / code review / security review
恢复：Git / worktree / plan files / task state
沉淀：rules / skills / retrospectives

这是一套围绕 Agent 的工程环境。它不是一个固定工具名，而是一组边界、入口、验证和恢复机制。

为什么需要 harness

当任务变大后，单靠 prompt 会出现：

• 上下文窗口爆掉。
• Agent 忘记测试。
• Agent 改了无关文件。
• 中途失败后无法恢复。
• 同类任务每次都重新教。
• 写代码和审代码混在一起。
• 多个 Agent 互相覆盖。

Harness 的作用是把这些风险前置控制。

最小可用 harness

个人开发者可以从这套开始：

项目根目录：
  AGENTS.md 或 CLAUDE.md
  README.md

任务目录：
  prd.md
  plan.md

执行工具：
  Claude Code、Codex 或 OpenCode

验证命令：
  test
  lint
  typecheck
  build

复盘：
  每次重复错误写回规范或 skill

不要一上来就追求复杂系统。最小 harness 跑顺之后，再加 MCP、skills、Trellis、CCG、Superpowers。

成熟 harness 的标志

你可以用下面清单检查：

• 任务入口清楚：每个任务都有目标、范围、验收。
• 上下文可复用：新会话不需要从零解释项目。
• 权限可控：高风险操作需要人工确认。
• 验证默认执行：完成前不会跳过测试。
• 状态可恢复：中断后能从文件继续。
• 经验可沉淀：重复错误会进入规则或 skill。

Harness 不是越重越好

如果任务很小：

prompt + 本地 Agent + diff review

就够了。

如果任务复杂：

PRD + plan + Agent + MCP + skill + test + review + worktree

才值得。

工具复杂度应该跟任务复杂度匹配。