Harness Engineering：开发者的下一个必修课
当 AI Agent 写了 100 万行代码后，真正决定成败的不是模型，而是 Harness。深入解析 2026 年最重要的工程新范式。
一个公式改变了一切
2026 年 2 月，OpenAI 发布了一篇博文，描述了一个令人震惊的事实：3 名工程师用 Codex Agent 编写了约 100 万行代码、提交了 1500 个 PR，零人工编写代码。
这不是实验室里的 demo，而是一个真实的生产级工具。
紧接着，Anthropic、LangChain、Martin Fowler 团队相继发布了相关文章。一个新的工程学科被正式命名：
Agent = Model + Harness
Harness（驾驭层）指的是围绕 AI 模型的所有基础设施——工具集成、上下文管理、反馈循环、编排逻辑、安全护栏——除了模型本身以外的一切。
而 Harness Engineering（驾驭工程），就是设计、构建和优化这一包裹层的工程实践。
为什么这不是"换了个名字的 Prompt Engineering"
很多人的第一反应是：这不就是 Prompt Engineering 换了个说法吗？
不是。这三者是递进关系：
| 层级 | 关注点 | 类比 |
|---|---|---|
| Prompt Engineering | 问什么 | 给司机下达目的地 |
| Context Engineering | 给模型发送什么信息 | 为司机提供地图和路况 |
| Harness Engineering | 整个系统如何运行 | 设计整辆车——方向盘、刹车、车道边界、仪表盘 |
AI 领域博主 Louis Bouchard 的比喻很精准：
"模型是引擎。Context 是燃料和仪表盘信息。Harness 是汽车的其余部分——方向盘、刹车、车道边界、维护计划、警示灯，以及门在高速公路上不会脱落的保证。只关注引擎和燃料，你仍然能造出一辆糟糕的汽车。"
一个实验证明了 Harness 的价值
LangChain 做了一个基准测试：仅改变 Harness，不改变模型，他们的编码 Agent 在 Terminal Bench 2.0 上从第 30 名跃升到第 5 名，完成率从 52.8% 提高到 66.5%。
同样的大脑，不同的身体，天差地别的表现。
这就是为什么四大 AI 实验室（OpenAI、Anthropic、Google DeepMind、Anysphere）在几乎零协调的情况下，独立收敛到了几乎相同的 Harness 架构。
Harness 的六大核心组件
如果把 Harness 比作操作系统，它的架构可以这样理解：
| 组件 | 职责 | 操作系统类比 |
|---|---|---|
| 工具集成层 | 连接 API、数据库、代码执行 | 设备驱动 |
| 记忆与状态管理 | 工作上下文、会话状态、长期记忆 | RAM + 文件系统 |
| 上下文工程 | 为每次模型调用动态策划信息 | 进程调度器 |
| 规划与分解 | 引导模型通过结构化任务序列 | 任务调度器 |
| 验证与护栏 | 格式验证、安全过滤、自我纠正 | 防火墙 + 权限系统 |
| 模块化与可扩展 | 可插拔组件，按需启用/禁用 | 内核模块 |
Phil Schmid 总结的操作系统类比更加直观：
- CPU（原始处理）→ LLM（模型推理）
- RAM（有限工作内存）→ 上下文窗口
- 操作系统 → Harness
- 应用程序 → Agents
你不会让应用程序直接操作 CPU 寄存器，同样，你也不应该让 Agent 在没有 Harness 的情况下裸奔。
控制论视角：前馈与反馈
Martin Fowler 团队的 Birgitta Boeckeler 引入了控制系统（Cybernetics）的框架，这是理解 Harness 最优雅的方式：
前馈控制（Feedforward）—— 在 Agent 行动前预防错误
- 计算性前馈：项目引导脚本、代码模板、OpenRewrite 规则
- 推理性前馈：AGENTS.md、Skills 文件、架构约束文档
反馈控制（Feedback）—— 在 Agent 行动后检测并纠正
- 计算性反馈：Linter、类型检查器、结构化测试、CI 管道
- 推理性反馈：AI 代码评审、LLM-as-Judge 评估
关键洞察：前馈和反馈缺一不可。
- 只有反馈 → Agent 反复犯同样的错误，然后再修
- 只有前馈 → 编码了规则但永远不知道是否有效
最佳实践是两者协同：前馈减少错误发生的概率，反馈在错误漏网时兜底。
与传统软件工程有什么不同
这是一次结构性的范式转变：
| 维度 | 传统软件工程 | Harness Engineering |
|---|---|---|
| 代码作者 | 人类 | AI Agent |
| 工程师角色 | 编写代码 | 设计 Agent 运行的环境 |
| 质量保证 | 人工代码审查 | 自动化前馈/反馈控制系统 |
| 调试基础 | 源代码 | 运行时 Traces |
| 系统行为 | 确定性 | 非确定性（LLM 推理） |
| 文档消费者 | 人类开发者 | AI Agent + 人类 |
| 技术债务 | 代码债务 | Harness 债务 |
Arize AI 的 Mikyo King 说得很清楚：
"在传统软件中，你通过阅读源代码来理解应用做什么。在 Agent 驱动的应用中，代码是脚手架，实际的决策发生在模型运行时内部。"
AgentPatterns.ai 提出了一个更深刻的概念——严格性转移（Rigor Relocation）：工程严格性从代码审查和风格指南，转移到设计干净的 Harness 和机械性强制约束。一条 linter 规则能在所有会话中捕获违规；一次 PR 审查只能捕获一次。
三大真实案例
案例一：OpenAI 的 Symphony 系统
3 名工程师，100 万行代码，零人工编写。他们的 Harness 三大支柱：
- 上下文工程 —— 代码仓库作为唯一事实来源，将知识组织为"地图，而非百科全书"
- 架构约束 —— 严格的分层架构（Types → Config → Repo → Service → Runtime → UI），由 linter 和结构化测试强制执行
- 熵管理 —— 后台 Agent 定期扫描代码偏差并自动开 PR 修复
团队最初每周五花 20% 时间清理"AI slop"（Agent 产生的低质量代码），后来将这个过程也自动化了——用 Agent 清理 Agent 的混乱。
案例二：Anthropic 的三 Agent 架构
受 GAN（对抗生成网络）启发，Anthropic 工程师设计了一个长时运行的 Harness：
- Planner Agent → 将 1-4 句话扩展为完整产品规格
- Generator Agent → 按 Sprint 逐个实现功能
- Evaluator Agent → 用 Playwright 像真实用户一样测试应用
关键发现：同样的模型（Opus），使用完整 Harness 的输出质量远超单 Agent 系统。他们生成一个数字音频工作站花费约 4 小时、$124 Token 成本。
案例三：Everything Claude Code
GitHub 上 140K+ Stars 的开源项目，自定义为"Agent Harness 性能优化系统"：
- 38 个专业化 Agent（规划、架构、TDD、代码审查、安全扫描等）
- 156 个 Skills（渐进式披露：Level 1 仅加载元数据，Level 2 加载完整内容）
- 持续学习系统：自动从会话中提取模式，转化为可复用的 Skills
它验证了一个核心理念：工具优于提示（Tools Over Prompts）。确定性工具（hooks、linters、类型系统）比概率性指令更可靠——指令在上下文压力下会退化，机械规则无法被覆盖。
Harness 成熟度四级模型
你的团队在哪一级？
| 级别 | 描述 | 具体做法 |
|---|---|---|
| Level 1 | 基础 | 编写 CLAUDE.md / AGENTS.md 约束文档，使用 Agent 配合结构化提示 |
| Level 2 | 中级 | 自定义 linting 规则、情景记忆、多 Agent 工作流、MCP 服务器、Hooks |
| Level 3 | 高级 | 完整编排管道（从 backlog 到合并 PR）、并行多 Agent 构建、自我改进的约束文档 |
| Level 4 | 企业级 | 组织级上下文仓库、Agent 舰队管理、安全优先的 Agent 平台 |
大多数个人开发者目前在 Level 1-2，优秀团队在 Level 2-3。Level 4 还在早期探索阶段。
五条实战建议
1. 从最简单的方案开始
Anthropic 的建议：不要在理解真正需要什么之前就过早优化。一个写得好的 CLAUDE.md + 几条 linter 规则，可能比一个复杂的多 Agent 编排系统更有效。
2. 构建以删除为目标（Build to Delete）
每一段 Harness 逻辑都应有过期日期。模型在进步，昨天需要的 workaround 可能明天就是多余的负担。每次新模型发布时，重新审视你的 Harness，删除不再需要的部分。
3. 编码不变性，而非具体实现
规定什么必须为真（依赖方向、数据验证、测试覆盖），不规定如何实现。好的 Harness 约束结果，给 Agent 自由选择路径。
4. 工具优于指令
能用 linter 规则强制的，就不要写在 Markdown 文档里希望 Agent "记住"。确定性强制 > 概率性引导。
5. 警惕 Harness 债务
Harness 本身也是产品，也会产生 bug 和漂移。定期审计你的规则文件、hooks 和 Agent 配置，确保它们仍然反映当前的代码库状态。
该注意的反模式
在实践中，这些坑值得特别警惕：
- 巨型 AGENTS.md —— 把所有知识塞进一个文件，结果是更多噪音、更多过时内容、更多被静默忽略的规则
- 裸 Agent 循环 —— 不设任何 Harness，模型 + 循环 = "自信地反复犯同样的错误"
- 过度信任 AI 生成的测试 —— Agent 写的测试可能只是在验证它自己的错误实现
- 忽视安全攻击面 —— CLAUDE.md 中的 prompt injection 可能危及整个工作流；权限过宽的 MCP 服务器是另一个风险点
写在最后
Harness Engineering 不是一个炒作概念。它代表了软件工程职业的一次结构性转变：从编写代码转向设计 AI Agent 可以可靠工作的环境。
Andrej Karpathy 描述了自己的工作流从 80% 手动编码 + 20% Agent，反转为 80% Agent 编码 + 20% 手动调整。这个反转正在越来越多的开发者身上发生。
当 Agent 承担了大部分编码工作，你对 Harness 的理解深度，就决定了你能驾驭多复杂的系统。
不要等到所有人都在谈论它的时候才开始。现在就动手——从写好你的第一个 CLAUDE.md 开始。
关注Claw开发者，获取更多 AI 工程实践分享。如果这篇文章对你有帮助，欢迎转发给你的技术团队。