Harness Engineering 到底是什么？

一句话定义

Harness Engineering（驾驭工程） 是围绕 AI 智能体设计和构建约束机制、反馈回路、工作流控制和持续改进循环的系统工程实践。它不优化模型本身，而是优化模型运行的"环境"。

核心公式：Agent = Model + Harness

"If you're not the model, you're the harness." — LangChain

词源

"Harness" 原意是马具——缰绳、马鞍、嚼子——一套引导强大但不可预测的动物的完整装备。用在 AI 语境中：AI Agent 就像一匹动力十足但不太守规矩的马，而 Harness 就是那套让它既能跑得快、又不会跑偏的缰绳和马鞍。

核心哲学：人类掌舵，智能体执行（Human Steer, Agent Execute）。

概念起源

2026 年 2 月 5 日：HashiCorp 联合创始人 Mitchell Hashimoto 首次提出这一概念
2026 年 2 月 11 日：OpenAI 在百万行代码实验报告中正式采用 "Harness Engineering" 一词，描述其 Codex 团队如何在 5 个月内用 AI agent 生成了约 100 万行生产代码——零行由人类手写

核心组成部分

1. 前馈控制（Feedforward Controls / Guides）

在 agent 行动之前进行干预，提高一次成功的概率：

结构化文档架构：机器可读的 docs/ 目录，交叉引用的设计文档和执行计划
AGENTS.md：简洁的（约 100 行）"目录文件"，引导 agent 找到正确的资源，而不是把巨量指令塞入上下文
架构约束：机械式强制执行的规则，如依赖流向（Types → Config → Repo → Service → Runtime → UI）
编码规范和引导模板：让 agent 在写第一行代码前就知道该遵循什么模式

2. 反馈控制（Feedback Controls / Sensors）

在 agent 行动之后观察并帮助自我纠正：

Linter / 类型检查：确定性的、快速的代码质量检测
测试套件：单元测试、集成测试、变异测试
AI Code Review：agent 对 agent 的代码审查循环
CI/CD 管道验证：持续集成中的自动验证

3. 执行环境基础设施

沙箱 / 隔离环境：安全的执行空间，命令白名单、网络隔离
文件系统持久化：agent 跨会话保持状态的最基础原语
Bash / 代码执行：让 model 拥有"一台计算机"，而非局限于预配置工具
可观测性与遥测：agent 可以访问日志、指标和链路追踪

4. 上下文管理

Context Compaction：智能压缩/摘要机制，应对上下文窗口逼近限制的情况
工具调用卸载：保留头尾 token，将完整输出卸载到文件系统
渐进式技能加载：避免启动时加载过多工具导致性能退化

5. 长期执行机制

Ralph Loops：拦截 model 的退出尝试，在新的上下文窗口中重新注入原始目标
规划与自我验证：将目标分解为步骤，通过测试套件或独立模型评估进行验证

三种调控维度（Martin Fowler / Birgitta Bockeler 的分类）

维度	前馈控制	反馈控制
可维护性	编码规范、架构文档	重复代码检测、圈复杂度、测试覆盖率、风格校验
架构适应性	性能需求文档、可观测性约定	适应度函数、性能测试、日志质量检查
行为正确性	功能规格说明	AI 生成的测试验证、覆盖率检查、变异测试

目前行为正确性是最薄弱的环节。

关键原则

"给 Codex 一张地图，而不是一本千页手册" — 保持顶层指令文件精简和结构化
让知识机器可读 — Slack 里的讨论、Google Docs 里的文档、脑子里的经验，对 agent 来说等于不存在
代码很便宜，环境质量很贵 — agent 可以大量产出代码，决定质量的是它运行的环境
机械强制优于约定 — Linter、CI 验证、结构测试确保一致性，不依赖人工监督
从行为倒推设计 — "我们想要/想修正的行为 → 帮助模型实现这一行为的 Harness 设计"
对抗上下文腐烂 — agent 在长对话中性能会退化，harness 本质上是良好的上下文工程的载体
质量关口前移（Keep Quality Left） — 快速便宜的检查放在提交前，昂贵的检查放在集成后

实际案例

OpenAI Codex 团队

5 个月生成约 100 万行生产代码，零行人类手写
分层架构由自定义 linter 和结构测试强制执行
定期 "垃圾回收" 扫描架构漂移，agent 建议修复方案
估计构建速度是手写的 10 倍

Stripe Minions 系统

pre-push hooks 运行启发式选择的 linter
"反馈左移" 策略
Blueprint 机制将反馈传感器集成到 agent 工作流

Claude Code

仅通过改变 harness（不改模型），Terminal Bench 2.0 排名从 Top 30 跃升至 Top 5
证明了 harness 优化本身就能带来巨大的性能提升

工程师角色的转变

传统	Harness Engineering 时代
写代码	设计 agent 运行环境
手动 code review	构建自动化审查循环
约定俗成的规范	机械强制的架构约束
调试具体 bug	优化反馈回路和传感器
写文档给人看	写文档给 agent 读

"Harnessability"（可驾驭性）

并非所有代码库都同样适合被 harness。成功取决于：

强类型系统
清晰可定义的模块边界
框架抽象层
可控的技术债务
绿地项目可以从第一天就嵌入可驾驭性

三篇核心文章的视角对比

主题	OpenAI	Martin Fowler	LangChain
核心定义	环境设计学科	控制系统（前馈/反馈）	模型之外的一切
类比	马具（缰绳、马鞍、嚼子）	控制论 / 控制理论	等式：Agent = Model + Harness
人的角色	环境设计者，不是代码编写者	Harness 循环的掌舵者	从行为倒推设计 Harness 的工程师
最薄弱领域	未明确指出	行为正确性 harness	长时间执行中的上下文腐烂
核心洞察	代码便宜，环境质量贵	调节器的多样性 ≥ 被调节系统的多样性	仅改 harness 就能从 Top 30 到 Top 5

总结

三篇文章殊途同归：在 AI Agent 时代，差异化的工程工作不是构建模型，而是构建模型周围的一切——约束、反馈循环、文档、工具和验证系统，让模型的智能在生产环境中可靠地发挥作用。