很多人对 AI 编码的理解，还停留在一个很朴素的阶段：

给模型一句需求，让它吐一段代码。

但如果你真的想把 Agent 用到工程生产里，很快就会发现，问题根本不在“模型会不会写代码”，而在：

它有没有一个能稳定完成任务的运行环境。

这也是为什么最近越来越多团队开始谈一个关键词：

Harness Engineering。

它不是某个框架，也不是某个协议，而是一种新的工程方法。

简单说：

当 Agent 开始承担越来越多的开发工作时，工程团队的核心任务，正在从“亲自写代码”转向“设计环境、表达意图、构建反馈回路”。

这就是我理解的 Harness Engineering。

一、Harness 到底是什么

很多人第一次看到 harness，会把它理解成“工具集”或者“脚手架”。

这两个理解都只对了一半。

在 Agent 工程语境里，harness 更像是一个让 Agent 能可靠工作的可控运行框架。它至少包含下面几部分：

• 工具接入方式：终端、浏览器、文件系统、数据库、知识库、CI
• 任务边界：Agent 能做什么，不能做什么，做到什么程度要停
• 反馈机制：测试、日志、指标、截图、review、lint、构建结果
• 约束与规则：代码规范、目录结构、提交要求、评审流程
• 任务闭环：失败时怎么重试，成功时怎么验证，什么时候升级给人

如果没有这些东西，所谓“AI 编码”通常只会变成一次性代码生成。

如果这些东西搭好了，Agent 才可能从“会写一点代码”升级到“能持续完成工程任务”。

二、为什么现在工程师的工作正在变化

OpenAI 在 2026-02-11 发布的《Harness engineering: leveraging Codex in an agent-first world》里，讲得非常直白：

• 他们做了一个实验，用 Codex 从空仓库开始构建产品
• 所有代码、测试、CI、文档、观测与内部工具都由 Codex 写出
• 人的主要职责，不再是直接写代码，而是设计环境、明确目标、建立反馈回路

这里最值得注意的，不是“0 手写代码”这个标题党卖点，而是背后的工程结论：

当 Agent 真正进入主流程后，瓶颈会从“代码产出速度”转移到“环境是否足够清晰、可见、可验证”。

换句话说，模型不再只是一个回答问题的系统，而是一个需要被“驯化进工程闭环”的执行体。

三、Harness Engineering 真正在解决什么问题

1. 让 Agent 看得见

Agent 最大的问题之一，不是不会推理，而是“看不见”。

它看不见的东西，基本就等于不存在。

比如：

• Slack 里的临时讨论
• 人脑里的口头共识
• 没有写进仓库的架构原则
• 只能让人手工点开的监控系统

所以 Harness Engineering 的第一件事，不是加更多 prompt，而是把信息变成 Agent 可见的对象：

• 仓库内文档
• 可查询日志
• 可访问指标
• 可重放 UI 状态
• 可执行的脚本
• 可验证的规则

这也是为什么越来越多团队开始重视：

• AGENTS.md
• skills
• repo 内设计文档
• execution plans
• 本地观测栈
• 浏览器自动化

它们的共同目标都不是“文档更漂亮”，而是让 Agent 真正能看懂系统。

2. 让 Agent 能自证

如果一个 Agent 只能写代码，不能验证代码，那它本质上还是高级补全。

真正的工程 Agent，必须能回答这几个问题：

• 我改了什么
• 为什么这么改
• 测试过没有
• UI 是否正常
• 性能有没有退化
• 构建是否通过
• review 意见有没有处理

这就要求 harness 不只是“执行工具”，还要提供反馈闭环。

比如：

• 运行单测并读取结果
• 拉起应用并自动做 UI 检查
• 查询日志和指标
• 根据 review comment 自动补改
• 在失败后重试或转人工

没有这一层，Agent 的上限就很低。

3. 让 Agent 在边界内自由

最差的做法，是一边想让 Agent 快，一边靠人工在每一步死盯细节。

最好的做法，是把硬约束提前写进系统，让 Agent 在约束内高速度运行。

比如你不需要规定它每一行代码怎么写，但你可以规定：

• 数据必须在边界校验
• PR 必须通过测试
• UI 修改必须经过截图对比
• 文档变更要同步更新
• 性能指标不能超过阈值

这就是一个很重要的转变：

不是微操实现，而是约束不变量。

Harness Engineering 的核心，不是让人干更多活，而是让系统替人守住底线。

四、为什么“写代码”正在让位于“造环境”

以前优秀工程师的核心竞争力，往往是：

• 抽象能力
• 编码速度
• 调试能力
• 架构判断

现在这些能力仍然重要，但表达形式变了。

在 Agent-first 团队里，更值钱的能力正在变成：

• 你能不能把任务讲清楚
• 你能不能把反馈机制搭出来
• 你能不能把约束写进系统
• 你能不能把隐藏知识沉淀进仓库
• 你能不能把模糊目标变成可验证标准

也就是说，工程师没有消失，只是工作的抽象层变高了。

从这个角度看，Harness Engineering 不是“工程师被替代”，而是“工程师职责升级”。

五、Harness、Skill、MCP 分别扮演什么角色

这几个词经常一起出现，但不要混为一谈。

Harness

负责运行环境、反馈闭环、约束机制和任务编排边界。

它解决的是：

Agent 怎样稳定干活。

Skill

负责把具体任务经验封装成可复用能力单元。

它解决的是：

Agent 遇到某类任务时，应该怎么做。

MCP

负责把工具、资源和上下文能力接给模型或 Agent。

它解决的是：

Agent 能连什么、怎么连。

所以一个常见组合是：

Harness 定义运行框架
Skill 提供任务套路
MCP 提供工具接入

这三者一起，才更像一个能在生产里持续运转的 Agent 系统。

六、做不好 Harness Engineering，团队最容易踩的 4 个坑

坑 1：把 prompt 当成万能控制器

很多团队遇到 Agent 出错，第一反应就是“把 prompt 写得更长一点”。

但如果日志不可见、测试不可跑、UI 不可验证、文档不可发现，prompt 再长也只是补丁。

坑 2：只有执行，没有验证

Agent 改代码很快，但没有验证链路时，它只会更快地产生不确定性。

速度不是问题，无法证明对错才是问题。

坑 3：知识不进仓库

如果关键知识还停留在聊天记录、会议口头结论和人脑里，Agent 永远只能“半盲工作”。

坑 4：把 Agent 当实习生，而不是系统组件

实习生靠人盯，系统靠机制跑。

如果你的使用方式永远是“它写一点，我补一点，我再改一点”，那你构建的不是 Agent 工程体系，而只是更快的代码草稿器。

七、我对 Harness Engineering 的一个直白判断

未来 AI 编码团队的竞争力，不会只取决于谁的模型更强。

更关键的问题会变成：

• 谁的仓库更适合 Agent 理解
• 谁的流程更适合 Agent 执行
• 谁的反馈回路更适合 Agent 自证
• 谁的约束系统更适合 Agent 持续演化

从这个意义上说，Harness Engineering 其实是在设计“Agent 的工作场所”。

一个混乱、不可见、不可验证的工程环境，再强的模型进去也会掉速、失真、乱改。

一个结构清楚、反馈完整、约束明确的环境，普通模型也能持续产出很高价值。

八、结语：下一代工程效率，不只是 AI 写得快，而是系统喂得好

如果你还把 AI 编码理解成“让模型多写几段代码”，那你看到的只是最表面的一层。

真正的变化在更深处：

工程团队正在从代码生产者，变成 Agent 运行系统的设计者。

这也是为什么我越来越觉得，未来最重要的问题不是：

这个模型能写多少代码？

而是：

你有没有给它一个足够好的 harness，让它把代码写对、改对、验对，并稳定交付？

这，才是 Harness Engineering 真正值钱的地方。

参考资料

• OpenAI：Harness engineering: leveraging Codex in an agent-first world（2026-02-11）