什么是 Harness Engineering？AI 时代软件工程的新范式

2026 年开年，开发者社区最热的词不是某个新模型，而是一个关于「环境」的词：Harness Engineering。

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

这背后，就是 Harness Engineering 在发挥作用。

从"提示词工程"说起

三年时间，AI 工程经历了三次明显的范式跳跃。

第一阶段是提示词工程（Prompt Engineering）：核心问题是"怎么把话说清楚"，开发者花大量精力调整 Prompt 的措辞、格式和示例，让模型输出更准确。

第二阶段是上下文工程（Context Engineering）：核心问题变成了"怎么给 AI 喂信息"，重点从 Prompt 措辞转向知识库构建、代码片段注入、历史对话管理。

但这两个范式有个共同盲点：它们都在优化"输入什么"，却没有认真对待"在什么条件下运行"。

当 AI Agent 能写出百万行代码，真正的挑战不是让它写得更好，而是让它稳定、可靠、不失控地工作。这就是 Harness Engineering 要解决的问题。

什么是 Harness Engineering

Harness Engineering（驾驭工程）是一种围绕 AI 智能体构建约束机制、反馈回路和控制系统的工程实践。它不优化模型本身，而是优化模型运行的「环境」。

“Harness” 这个词来自马具——缰绳、马鞍、嚼子。驾驭工程不是去削弱 AI 的能力，而是为它打造一套黄金缰绳，让它跑得又快又稳。

这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次提出，随后 OpenAI 在其"百万行代码"实验报告中正式采用，Martin Fowler 撰文深度分析，一个月内成为工程社区的高频词。

Hashimoto 的原话是：

“harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.”

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

四根护栏：Harness 的核心组件

综合 OpenAI、Anthropic、LangChain 等团队的实践，Harness 可以归纳为四个核心组件。

上下文工程（Context Engineering）

不是给 Agent 一份 1000 页的静态说明书，而是维护一个稳定、小巧的入口，教会 Agent 根据任务按需检索更多上下文。上下文是稀缺资源，过多的指导会挤掉任务空间，变成"陈旧规则的坟场"。

Mitchell Hashimoto 的 Ghostty 项目中，AGENTS.md 里每一行都对应一个历史 Agent 失败案例——文档是活的反馈循环，不是静态制品。

架构约束（Architecture Constraints）

OpenAI 团队建立了严格的层级依赖模型：

Types → Config → Repo → Service → Runtime → UI

下层不能反向依赖上层。所有规则被编码为自定义 Linter，违反即 CI 阻止合并。关键细节是：Linter 的错误信息本身也是上下文工程——它不只说"你违反了规则 X"，而是解释"为什么这个规则存在"，这样 Agent 读到错误后能自我修正，不需要人类介入。

用 Go 来理解这个思路，就像强制接口约束：

// 不允许 Service 层直接依赖 UI 层
// 架构约束通过 interface 隔离，违反则编译失败
type StoragePort interface {
    Save(ctx context.Context, data []byte) error
    Load(ctx context.Context, id string) ([]byte, error)
}

// Service 只依赖抽象，不依赖具体实现
type ArticleService struct {
    store StoragePort // 只能通过接口访问，永远不知道底层是 MySQL 还是 Redis
}

反馈循环（Feedback Loop）

传统开发中，人类工程师负责 Code Review。在驾驭工程中，这变成了 Agent 对 Agent 的方式：Codex 在本地审核自身更改，运行测试套件，带着错误信息循环回模型，直到通过。如果 AI 写的测试用例"通过"了带有 Bug 的代码，Harness 会判定测试无效，强迫它重新思考测试边界。

熵管理（Entropy Management）

随着时间推移，代码库会逐渐混乱，技术债务会积累。OpenAI 的策略是持续小额偿还，而不是等问题严重时集中处理——专门运行一个"Doc-gardening Agent"（文档园丁代理），在后台扫描文档与代码之间的不一致，发现过时内容就自动提交 PR 修复。Agent 为 Agent 维护文档。

为什么这件事比换模型更有价值

安全研究员 Can Boluk 做了一个极端的实验：仅仅改变 Agent 的代码编辑格式，从传统 patch 改为他设计的 Hashline 格式，Grok Code Fast 1 的基准得分就从 6.7% 跳到 68.3%。

一个格式的改变，等于十个模型升级。

这揭示了一个反直觉的事实：在 AI Agent 编码领域，决定结果好坏的最大变量，往往不是模型有多聪明，而是模型被放在了一个什么样的环境里。

OpenAI 在报告结尾写道：“我们当前最棘手的挑战集中在设计环境、反馈回路和控制系统方面。” 当模型的能力竞赛仍在继续，真正的杠杆已经转移到了「环境」一侧。

常见问题

Harness Engineering 是 Anthropic 还是 OpenAI 提出的？

这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 在 2026 年 2 月 5 日首次提出。六天后，OpenAI 在其百万行代码实验报告中正式采用这一术语，随后 Martin Fowler 撰文分析，迅速在社区传播开来。

Harness Engineering 和 Context Engineering 有什么区别？

Context Engineering 关注"给 AI 喂什么信息"，优化的是注入上下文的质量和方式。Harness Engineering 更上一层，关注"AI 在什么样的系统环境下运行"，包括架构约束、反馈回路、错误恢复机制等。Context Engineering 是 Harness 的一个组成部分，而不是并列关系。

普通开发团队现在就能用 Harness Engineering 吗？

可以从三件小事入手：① 维护一份随着 Agent 失败案例更新的 AGENTS.md；② 把关键架构约束写成 Linter 规则而不是文档；③ 给 Agent 的 CI 流程加上"带错误信息的自动重试"钩子。不需要等基础设施完备，这三件事今天就能做。

Harness Engineering 会取代传统软件工程吗？

不会取代，而是在它之上叠加一层。传统的测试、架构设计、代码审查这些实践依然有效，Harness 只是把这些实践的执行者从"人类"变成了"部分由 Agent 驱动的自动化系统"。工程师的角色从"代码的编写者"转向"环境的设计者"。

如果你的团队正在引入 AI 辅助开发，或者 Agent 时不时翻车让你头疼，欢迎在评论区聊聊——是哪种失败模式最常见？有没有自己摸索出的"护栏"经验？