Harness Engineering：从驾驭模型到构建 AI 工厂
2026 年，AI 编程工具的竞争焦点发生了根本性转变：决定 AI 助手好不好用的，不再是模型本身，而是包裹在模型外面的那层"Harness"。同一个模型，在不同的 Harness 下，性能差距可以达到 78% vs 42%。
这篇文章将带你深入了解 Harness Engineering——这个正在重新定义 AI 工程实践的新兴领域。
一、什么是 Harness Engineering？
Harness 的字面意思是"马具/缰绳"——用来驾驭一匹强壮但不受控的马。在 AI 语境下，Harness 就是 LLM 之外的一切：工具定义、记忆系统、权限模型、反馈循环、文档规范、多 Agent 编排……
Harness Engineering 就是设计、构建和维护这套基础设施的工程学科。它的核心理念来自 Mitchell Hashimoto（HashiCorp 联合创始人）：
"每当你发现 Agent 犯了一个错误，就花时间设计一个方案，让它永远不再犯同样的错。"
这不是一次性的 Prompt 调优，而是持续积累的基础设施建设。
二、从 Prompt 到 Harness：三代演进
第一代：Prompt Engineering（2022-2024）
关注怎么问问题。精心设计提示词、少样本学习、思维链（Chain of Thought）……但 Stanford HAI 的研究发现，prompt 优化超过合理基线后，质量提升不到 3%。
第二代：Context Engineering（2025）
由 Dex Horthy 在"12-Factor Agents"框架中提出，关注给模型送什么信息。管理上下文窗口、RAG 检索、工具定义、对话历史……但这仍然局限在单个 Agent 的单次交互范围内。
第三代：Harness Engineering（2026）
关注整个系统怎么运转。跳出单次交互的视角，设计工具编排、权限模型、反馈循环、多 Agent 协作、CI/CD 集成……Harness 层面的改进可以带来 28-47% 的质量提升。
三、Harness 的六大核心组件
1. 文档层（Documentation Layer）
这是 Harness 中最容易上手、回报也最高的部分。
- CLAUDE.md：Claude Code 的项目配置文件，每次会话自动加载
- AGENTS.md：Agent 的"团队知识库"，记录代码规范、踩坑经验、架构决策
- .cursorrules：Cursor 的等效配置
Mitchell Hashimoto 的实践：每次 Agent 犯错，就在 AGENTS.md 里加一行规则。日积月累，Agent 变得越来越"懂"你的项目。
# CLAUDE.md 示例
## 代码规范
- 使用 TypeScript strict mode
- 所有 API 端点必须有 Zod schema 验证
- 不允许使用 any 类型
## 常见坑点
- 数据库迁移必须是幂等的
- Redis key 必须设置 TTL
- 前端组件必须支持 SSR2. 工具定义（Tool Definitions）
Agent 能做什么，取决于你给它什么工具。
- 内置工具：文件读写、Shell 命令、代码搜索
- MCP 服务器：通过 Model Context Protocol 扩展能力（数据库查询、API 调用、浏览器操作）
- 自定义脚本：项目特定的构建、测试、部署工具
Stripe 的做法尤为激进——他们通过 "Toolshed" 连接了 400+ 内部工具到 AI Agent，让 Agent 能直接操作几乎所有内部系统。
3. 权限与安全模型（Permission & Safety）
模型负责"决定做什么"，Harness 负责"判断能不能做"——两者必须分离。
- 分层权限：只读 → 确认后执行 → 自动执行
- 护栏引擎：阻止 force-push、删除生产数据、暴露密钥等危险操作
- 沙箱隔离：OpenAI Codex 在完全隔离的沙箱中运行，操作的是代码副本而非线上环境
4. 反馈控制（Feedback Controls / Sensors）
这是让 Agent 能够"自我纠错"的关键。
- 计算型反馈：测试、Lint、TypeCheck——快速且确定性
- 推理型反馈：AI 代码审查、语义分析——更慢但更丰富
- CI 管道：每次提交自动验证，形成持续的质量闭环
5. 前馈控制（Feedforward Controls / Guides）
与其等 Agent 犯错再纠正，不如提前设好"防护栏"。
- 架构约束：通过自定义 Linter 强制执行模块边界
- 依赖规则：禁止某些模块间的直接依赖
- 代码风格：自动格式化、命名规范
6. 编排层（Orchestration Layer）
当你需要多个 Agent 协同工作时，编排层就是"指挥中心"。
- 任务分解：将大任务拆分为可并行的小任务
- 状态管理：追踪每个 Agent 的进度和产出
- 上下文隔离：Claude Code 的子 Agent 各有独立的上下文窗口，互不干扰
四、反馈循环：Harness 的灵魂
理解 Harness Engineering 最关键的一点是：它是一个不断积累的复利系统。
- Agent 犯错 → 测试失败、Lint 报错、类型检查不通过
- Harness 捕获错误 → 阻止有问题的代码提交
- Agent 自我修复 → 根据错误信息重新生成代码
- 工程师更新规则 → 在 CLAUDE.md / AGENTS.md 中添加一条新规则
- 永久生效 → 所有未来的 Agent 实例都不会再犯同样的错
这就是 Mitchell Hashimoto 所说的："每一次犯错都是一次投资。" 随着规则不断积累，Agent 变得越来越可靠——不是因为模型变聪明了，而是因为 Harness 变厚了。
五、实战案例
OpenAI Codex：百万行代码零人工编写
OpenAI 在 2026 年 2 月披露了一组惊人数据：
- 一个小团队使用 Codex 构建了 100 万+行代码的产品
- 零人工编写的代码——所有代码都由 Agent 生成
- 每天消耗约 10 亿 token（约 $2-3k/天）
- 5 个月内合并了 ~1500 个 PR
他们的秘诀不是更好的模型，而是用 Elixir 构建的 "Symphony" 编排系统和精心设计的 AGENTS.md 文件体系。
Stripe：400+ 工具接入的 AI 工厂
- 通过 "Toolshed" 接入 400+ 内部工具
- 每周由 Agent 合并 1000+ PR
- "Minions" 系统自动处理 Slack 中的任务请求
- "Blueprints" 将反馈传感器集成到标准工作流
Claude Code：80+ 模块化组件
- 每次会话从 80+ 模块化组件中拼装独特的 Prompt
- 子 Agent（Plan、Explore、Task）拥有隔离的上下文窗口
- Hooks 系统实现生命周期事件自动化
- MCP 协议扩展工具能力边界
独立开发者 Peter Steinberger (OpenClaw)
- 一个人同时运行 5-10 个 Agent
- 月提交量达 6600+
- 个人产能堪比一个小型工程团队
六、如何开始你的 Harness Engineering 实践
Level 1：写好你的 CLAUDE.md（10 分钟）
这是投入产出比最高的起点。在项目根目录创建 CLAUDE.md，写入：
# 项目概述
[一句话描述你的项目]
# 技术栈
- 语言：TypeScript
- 框架：Next.js 15
- 数据库：PostgreSQL + Prisma
# 开发命令
- 启动：npm run dev
- 测试：npm test
- Lint：npm run lint
- 类型检查：npx tsc --noEmit
# 代码规范
[你希望 Agent 遵守的规则]
# 已知坑点
[Agent 容易犯的错误]Level 2：接入反馈循环（30 分钟）
确保你的项目有：
- 可运行的测试套件
- Lint 配置（ESLint / Prettier）
- 类型检查（TypeScript strict）
- pre-commit hooks（Husky + lint-staged）
有了这些，Agent 的每次修改都会自动得到反馈，形成 "写代码 → 检查 → 修复" 的自动循环。
Level 3：扩展工具能力（1-2 小时）
通过 MCP 服务器给 Agent 接入更多工具：
// .claude/settings.json
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["@anthropic-ai/mcp-server-postgres", "postgresql://..."]
},
"github": {
"command": "npx",
"args": ["@anthropic-ai/mcp-server-github"]
}
}
}Level 4：多 Agent 编排（进阶）
当你的项目需要处理大型任务时，考虑使用 Ralph 这样的编排工具，让多个 Agent 实例分工合作、自动推进——这正是我们上一篇文章介绍的内容。
七、争议与思考
Harness Engineering 并非没有争议。批评者认为这不过是给 CI/CD、Lint、文档规范这些老概念贴了个新标签——"我们做了二十年的软件工程最佳实践，现在换个名字就变成新学科了？"
这个批评有一定道理。但支持者认为，关键区别在于：
- 系统性：传统实践是分散的，Harness Engineering 将它们统一为一个围绕 AI Agent 的系统性框架
- 受众变了：这些基础设施现在不只是给人用的，还要给 AI 用——设计思路需要调整
- 复利模型：传统规范是静态的，Harness 是在与 Agent 的持续交互中动态积累的
无论你怎么看这场命名之争，有一点是确定的：在模型能力日趋趋同的今天，你围绕模型构建的基础设施，比选择哪个模型更重要。
总结
Harness Engineering 的核心启示很简单：
不要追求更好的模型，而是为现有模型构建更好的工作环境。
就像一个优秀的工程团队，不只依赖个人能力，还依赖流程、工具链、Code Review、CI/CD、文档体系。AI Agent 也一样——它需要的不只是一颗聪明的"大脑"，更需要一整套精心设计的"工作环境"。
这就是 Harness Engineering 的意义：从驾驭模型，到构建 AI 工厂。
延伸阅读：