Harness Engineering（一）：当工程师开始设计 Agent 的工作环境

过去谈 AI 编程，人们最常问的是：模型能写多少代码？

这个问题已经越来越难以衡量 AI 编程的真正能力。当 Agent 能连续工作数小时，独立搜索代码、修改文件、运行测试、处理审查意见并发起 Pull Request 时，代码产量便不再是唯一的限制。更关键的是：Agent 能否理解目标、看清环境、验证结果，并在偏离目标时及时纠正。

OpenAI 在一项内部实验中把这种变化推到了极致。他们从一个空仓库开始，五个月后积累了约一百万行代码。早期只有三名工程师负责引导 Codex，却累计创建并合并了约 1,500 个 Pull Request。应用逻辑、测试、CI、文档、可观测性和内部工具全部由 Codex 生成，人类没有直接编写代码。

这也不是为了制造漂亮的产量数字。产品已经交付给数百名内部用户和外部 Alpha 测试者使用，并在一次次部署、出错和修复中接受真实检验。团队估算，整个产品的开发时间大约只有人工编写全部代码所需时间的十分之一。

这个案例真正值得关注的，不是“一百万行”本身，而是工程师开始把精力投入到另一件事上。

人类负责掌舵，Agent 负责执行。工程师不再只构建产品，也开始构建 Agent 能够可靠工作的环境。

这就是 Harness Engineering。

代码变便宜后，人的注意力成为系统瓶颈

传统软件团队的交付速度主要受实现能力限制。即使需求已经明确，仍然要有人完成设计、编码、测试、审查和修复。增加工程师，通常也就意味着增加产能。

编程 Agent 改变了这套约束。实现速度提高后，团队很快会遇到另一组问题：

• Agent 不知道某个架构决定为什么存在。
• 它能改 UI，却不能独立确认交互是否正确。
• 它能看到错误日志，却无法把日志与具体请求关联起来。
• 它完成了局部需求，却违反了代码库的依赖边界。
• 它生成了大量改动，但人工测试和代码审查根本来不及处理。

这些问题不能靠“再生成一次”稳定解决。模型也许下一次会做对，但团队并没有获得可复用的能力。

OpenAI 团队的做法，是把每一次受阻都视为工作环境暴露出了一处缺口。Agent 缺少工具，就补上工具；缺少项目知识，就把知识写进代码库；无法确认 UI 是否正确，就让它能够检查浏览器和应用状态；某条规则反复被违反，就把它固化为 lint 规则或结构测试。

于是，工程师不再只修正一次错误的结果，而是开始改进持续产出结果的整个系统。

Harness Engineering 不是提示词优化

Prompt 是 Harness 的一部分，却不等于 Harness。

一条 prompt 可以说明单次任务要做什么。Harness 则决定 Agent 在整个执行过程中能看到什么、能采取哪些行动，以及靠什么判断任务已经完成。对编程 Agent 来说，Harness 至少包含五个层次：

知识：项目目标、架构、产品规则和历史决策是否容易查找
环境：代码、浏览器、日志、指标和运行状态是否可观察
工具：搜索、编辑、测试、部署和协作动作是否可执行
约束：权限、依赖边界和质量规则是否能被自动检查
反馈：失败、审查意见和线上问题能否转化为下一次运行可复用的能力

如果缺少这些能力，团队就只能不断加长 prompt，每次都把背景、提醒和检查清单重新交给 Agent。眼前的任务或许能完成，下一次却仍要从头再来。

Harness Engineering 要做的，是把临时提醒变成工作环境中的稳定能力。Agent 不必每次都被告知“不要跨层调用”，因为结构测试会直接拦截违规改动；不必依赖人来转述某次 Slack 讨论，因为决策及其理由已经写入版本化文档；也不必等待人工打开页面确认，因为它可以自行启动隔离的应用实例并检查页面状态。

好的 Harness 不是给 Agent 塞入更多要求，而是让正确做法更容易执行，让错误更早暴露。

工程师的角色从实现者转向系统设计者

这并不意味着工程师不再重要。相反，Agent 产出越多，就越需要把人的判断用在更能影响全局的地方。

工程师仍然要决定：

• 哪些问题值得解决，什么才算完成。
• 哪些架构边界必须保持，哪些实现细节可以自由选择。
• 哪类失败可以自动修复，哪类风险必须交给人判断。
• 哪些反馈只适用于当前改动，哪些应该固化为系统规则。
• 什么时候增加脚手架，什么时候删掉已经过时的约束。

区别在于，这些判断不应只停留在一次代码审查中。高价值的经验要进入代码库、工具和检查机制，供此后的每一次 Agent 运行复用。

这带来了新的工程杠杆。过去，资深工程师主要通过编写核心模块和审查代码来影响团队；现在，他们还可以通过设计 Harness，让同一条原则持续作用于成百上千次 Agent 执行。

先把失败分类，再决定补哪一层

团队不必复制 OpenAI 的极端实验，也不必从“禁止人写代码”开始。更现实的起点，是找出一种反复出现的 Agent 错误，再判断工作环境缺少了什么。

失败表现	不要只做什么	应该补的能力
Agent 经常误解项目结构	反复解释目录	仓库地图和架构索引
每次修复后仍要人工打开页面	增加一句“请验证”	Agent 可操作的应用实例和浏览器工具
同一种审查意见反复出现	每次重新留言	lint、类型检查或结构测试
长任务中遗忘早期决定	把所有历史留在上下文	版本化计划、决策日志和状态文件
PR 数量超过人工审查能力	要求审查者加快速度	风险分级、自动检查和 Agent 审查

这种分类很重要。Agent 失败不一定说明模型能力不足。很多时候，真正的问题是它无法从环境中获取完成任务所需的信息、操作能力或反馈。

衡量 Harness，要看 Agent 能否独立完成闭环

可以用四个阶段来粗略判断团队的 Harness 成熟度：

1. 生成阶段：Agent 生成代码，人负责提供上下文、运行测试和确认结果。
2. 执行阶段：Agent 可以搜索、编辑、运行命令，并完成边界明确的小任务。
3. 验证阶段：Agent 能启动应用、复现问题、检查日志和 UI，并拿出证据说明修改有效。
4. 改进阶段：每次失败都会推动文档、工具、eval 或约束更新，从而减少同类错误。

真正的分界线不在于团队用了多少 AI 工具，而在于 Agent 能否独立走完“理解任务—采取行动—验证结果”的闭环，以及人的判断能否不断沉淀到这个闭环中。

这也是 Harness Engineering 系列接下来要讨论的内容。下一篇先从最容易被低估的一层开始：怎样让代码库成为 Agent 可以导航的知识系统。

本文整理自 OpenAI 的文章 Harness engineering: leveraging Codex in an agent-first world，核心观点来自原文。

Harness Engineering 系列

• （一）当工程师开始设计 Agent 的工作环境（本文）
• （二）给 Agent 一张代码库地图
• （三）让软件运行状态对 Agent 可读
• （四）把工程规则变成可执行约束
• （五）当 Agent 的产出超过人的注意力
• （六）Agent 也会复制技术债务

相关阅读

• 智能体需要 Harness，不只是更强的模型 —— Harness 的基础定义，以及模型之外的上下文、工具、约束、验证和纠正。
• 生产级 Agent 的评估与监控 —— 怎样把真实失败沉淀成系统改进依据。