Harness Engineering 是围绕 AI Agent 设计和构建约束机制、反馈回路、工作流控制与持续改进循环的系统工程实践。

其核心哲学可概括为八个字：人类掌舵，智能体执行。它并不优化大模型本身的参数或能力，而是优化模型运行的外部环境——就像给一匹神力强大但难以预测的独角兽配上黄金缰绳、水晶马车和车夫，让它既保留神力，又跑得又快又稳。

二、为什么需要 Harness Engineering？

过去两年，AI 工程经历了三个递进的阶段：

1.Prompt Engineering（提示工程） 怎么把话说清楚？ 单次对话输入

2.Context Engineering（上下文工程） 怎么给足背景信息？ 系统提示、知识库、动态上下文

3.Harness Engineering（驾驭工程） 怎么让 AI 在真实世界里持续可靠地执行任务？ Agent 框架、工具边界、协作架构、反馈循环、安全约束

Prompt Engineering 解决"说什么"，

Context Engineering 解决"给什么信息"，

Harness Engineering 解决"在什么条件下运行"——包括沙箱环境、工具权限、状态记忆、错误恢复、人工监督节点等。

三、Harness 的三大核心组件

1.  Context Engineering（上下文工程）：不仅是给 Agent 一份静态文档，而是构建持续增强的知识库 + 动态上下文（如可观测性数据、浏览器状态）。

2.  Architectural Constraints（架构约束）：通过自定义格式、结构测试和机械化规则强制边界，而非让 Agent 随意发挥。例如限定依赖层级（Types → Config → Repo → Service → Runtime → UI），防止模块化分层被破坏。

3.  Garbage Collection（垃圾回收）：定期运行的 Agent 负责扫描过时文档，自动发起修复请求。这对应软件工程中的"技术债务"概念——与其让债务累积，不如持续小额偿还。

四、真实案例：环境设计比换模型更重要

Harness Engineering 的颠覆性在于：改变环境带来的收益，可能远超升级模型。

•  OpenAI 内部实验：一个三人工程师团队，在五个月内未手写一行源代码，仅通过设计 Harness（提示词、反馈、CI 验证），让 Codex Agent 自主交付了约 100 万行代码 的内部产品。

•  LangChain 基准测试：在 Terminal Bench 2.0 上，仅优化 Agent 外部环境（文档结构、验证回路、追踪系统），排名从全球第 30 位跃升至第 5 位，得分从 52.8% 飙升至 66.5%，底层模型一个参数都没改。

•  Can Boluk 的格式实验：仅将代码编辑格式从传统 patch 改为自定义的 Hashline 格式，Grok Code Fast 1 的基准得分就从 6.7% 跃升至 68.3%。一个格式的改变，等于十个模型升级。

五、总结

Harness Engineering 标志着工程师角色的根本转变：从代码编写者转向环境设计师。

正如 Mitchell Hashimoto 所言：

Agent 的每一次失败，都是环境设计不完善的信号。 正确的回应不是换一个更强的模型，而是重新设计它运行的环境。