Apr 16, 2026

Harness Engineering：AI Agent 时代的软件工程新学科

什么是 Harness Engineering

2025年末，Mitchell Hashimoto（Terraform、Ghostty 等知名开源工具的作者）提出了一个概念，迅速在 AI 工程社区引发共鸣：

Harness Engineering：当你发现一个 Agent 犯了一个错误，你花时间工程化地解决它——使得这个 Agent 再也不会犯同样的错误。

这听起来简单，但背后蕴含着一种全新的工程思维范式。

传统软件开发中，我们写代码、跑测试、修 Bug、优化性能——这些都是以人为中心的工程活动。但当 AI Agent 开始写代码、跑测试、甚至修复 Bug 时，约束 AI 行为、管理 AI 工作流、确保 AI 输出质量的工程实践就变得不可或缺。这门新的工程学科，就是 Harness Engineering。

为什么它突然重要了

2024年至2025年，AI Coding Agent 从极客玩具演变成了生产级工具。OpenAI 的实验显示，在 Harness Engineering 的支撑下，AI Agent 在五个月内生成了超过 100万行代码，且这些代码最终被合并到生产代码库中。

但瓶颈从来不是 Agent 写代码的能力——而是我们给 Agent 搭建的”脚手架”是否足够稳固。

这个脚手架，就是 Harness。它决定了：

Agent 接收什么样的上下文
Agent 在什么条件下执行什么动作
Agent 的输出如何被验证
错误如何被捕获和纠正

核心框架：Feedforward 与 Feedback

Martin Fowler 在其文章中提出了理解 Harness Engineering 的核心框架——Feedforward（前馈） 和 Feedback（反馈）。

Feedforward：事前引导

Guides（引导工具） 在 Agent 行动之前发挥作用，目的是提高 Agent 一次做对的概率。

常见的 Guides 包括：

规则（Rules）：编码了不应做什么的指令，例如”禁止直接提交到 main 分支”
规范文档（Spec Docs）：系统设计意图和架构约束的说明
How-to 指南：特定操作的正确步骤
语言服务器和 Linter：提供结构化的代码质量反馈

Feedback：事后校正

Sensors（感知器） 在 Agent 行动之后观察输出，帮助 Agent 自我修正。

常见的 Sensors 包括：

评审 Agent：专门的子 Agent 负责审查主 Agent 的输出
静态分析工具：Linter、类型检查器、依赖分析
测试套件：自动化测试验证功能正确性
运行时监控：日志、错误率、SLO 指标

关键洞察

Martin Fowler 指出：只有反馈没有前馈的 Agent 会不断重复同样的错误；只有前馈没有反馈的 Agent 则永远不知道自己制定的规则是否有效。 两者缺一不可。

Harness 的四大组成

Harness Engineering 不是单一技术，而是一套系统化的工程实践，核心包含以下几个组成部分：

1. 会话编排（Session Orchestration）

管理 Agent 的生命周期——何时创建会话、如何传递上下文、如何结束会话、如何在长时间任务中保持状态。

2. Agent 特化（Agent Specialization）

不是让一个通用 Agent 做所有事，而是为不同任务设计专门的 Agent。例如：

一个 Agent 负责代码生成
一个 Agent 负责代码审查
一个 Agent 负责测试生成
一个 Agent 负责文档更新

3. 输出验证（Output Validation）

在 Agent 输出进入生产流程前，必须有自动化的验证环节。常见的验证方式包括：

编译通过
单元测试全部通过
Linter 无警告
人工评审通过

4. 任务排序与并行（Task Sequencing & Parallelism）

复杂任务需要被分解为有序的子步骤，每个步骤的输出作为下一步的输入。Harness 需要决定哪些任务可以并行，哪些必须串行。

与 Prompt Engineering 的区别

很多人会把 Harness Engineering 和 Prompt Engineering 混为一谈——但它们处于不同的抽象层次。

维度	Prompt Engineering	Harness Engineering
关注对象	单次交互的质量	多 Agent 协作的可靠性
抽象层次	提示词本身	Agent 工作流和基础设施
核心问题	如何写好一句话	如何让 Agent 系统持续正确运转
生效范围	单次会话	整个系统和所有会话

如果把 AI 系统比作一辆汽车：

Prompt Engineering 是调整驾驶员的操作手册
Harness Engineering 是设计整辆车的工程架构——包括方向盘、刹车、仪表盘、引擎、底盘

OpenAI 的实践

OpenAI 在其 Harness Engineering 实验中总结了以下几点关键经验：

1. 人类始终在循环中，但工作层次变了

人类的角色不再是逐行审阅代码，而是：优先级排序、将用户反馈转化为验收标准、验证最终结果。当 Agent 遇到困难，这不是 Bug，而是信号——说明某个工具、约束或文档缺失，需要被添加回系统中。

2. 自定义 Linter 是关键杠杆

OpenAI 用自定义 Linter 强制执行架构规范（结构化日志、命名约定、类型规范、文件大小限制），并刻意让 Linter 的错误信息包含修复指令——这是一种”正向的 Prompt 注入”。

3. 架构约束不是阻碍，而是加速器

“先有架构再写代码”这件事，通常被认为是大公司的奢侈。但 OpenAI 的实验表明，在 AI Agent 时代，架构约束是早期必需品：没有约束，AI 生成的代码会快速腐化到无法维护的程度。

实践建议

如果你正在或准备使用 AI Coding Agent，以下几点 Harness Engineering 实践值得尽早建立：

建立规范优先于让 Agent 自由发挥。在 Agent 开始工作前，先定义好架构规范和编码规则。
用 Linter 和测试作为强制约束。不要依赖 Agent 的”自觉”，要让规范能够被自动化执行。
建立评审 Agent 作为标准流程。一个专门的审查 Agent 可以显著降低错误率。
让错误成为改进 Harness 的信号。每次 Agent 犯错，都应该追问：是前馈不足还是反馈不足？应该在哪个层次解决？
工具和文档是 Harness 的核心资产。好的工具生态和文档积累，会让 Agent 的可靠性随时间不断提升。

小结

Harness Engineering 不是一个新框架、新库或新模型——它是 AI 工程化的一个新阶段。当 AI Agent 开始独立承担软件开发工作，我们需要一套全新的工程纪律来管理这个过程。

这门学科的核心洞察其实很朴素：好系统不是因为组成它的组件优秀，而是因为组件之间的协作被精心设计。对于 AI Agent 系统，这句话比以往任何时候都更正确。

相关资源：