【别再怪模型脑子不够了】OpenAI 这套 Harness Engineering，到底是怎么把同一个 Agent 榨出更猛战斗力的？

前言

这两天我专门去扒了一圈 OpenAI 最近在讲的Harness Engineering。

一开始我还以为这又是个新框架名字，或者又是哪个包装得花里胡哨的新 Agent 套件。

结果越看越发现，老哥，这东西真正有意思的地方，恰恰不是“又发明了一个多牛的新模型”，而是它在说一件特别工程、但也特别扎心的事：

很多时候，模型没你想象中那么废，真正废的，可能是你给它准备的工作环境。

这话听起来有点损，但我觉得真挺对。

因为很多人做 Agent，第一反应都是：

• 换模型
• 升参数
• 上更强 reasoning
• 再堆点提示词
• 不行就再换一家

可 OpenAI 这波更像是在说：

先别急着骂马不行，有没有可能，是你鞍子歪了、缰绳乱了、地上全是坑，马刚起跑就摔沟里了？

所以这篇我就不整那些虚头巴脑的，我直接按我自己看源码之后的理解，给你讲清楚三件事：

• Harness Engineering 到底是什么
• OpenAI 开源出来的codex里，哪些地方能看出这套思路
• 为什么“不改模型，只改环境和工程结构”，真的可能把 Agent 表现拉高很多

先说结论：

这玩意本质上不是新模型范式，而是 Agent 的工程外骨骼。

一、Harness 到底该怎么理解？别翻成一个死词，理解成“工程鞍具”就行

很多人看到harness这个词，会先想翻译。

严格说，它不是单纯的saddle。

saddle更像“马鞍”，而harness更像一整套：

• 马具
• 挽具
• 束具
• 把力量导出来的那套装备

所以放在 AI 工程里，我反而不建议你死盯字典翻译。

你就把它理解成：

让 Agent 能稳定干活的一整套工程约束层。

也可以叫：

• 工程鞍具
• Agent 外骨骼
• 外部执行框架
• 约束与反馈系统

说白了，它不是模型本身，
而是模型外面的世界。

这个世界包括什么？

• 仓库结构
• 目录边界
• 规则文档
• 工具接入
• 沙箱权限
• 测试反馈
• CI 校验
• 文档同步
• 状态存储
• 审批流程

这些东西平时大家嫌它“不性感”。

但真到了 Agent 场景里，你会发现：
这些看起来不像 AI 的东西，反而最像生产力。

二、我这次实际看到了哪些源码

这次我主要顺着openai/codex这个开源仓库往下看。

能直接看到、而且和 Harness Engineering 强相关的东西，主要有下面这些：

• openai/codex仓库本身
• 根目录AGENTS.md
• codex-rs/core/prompt.md
• codex-rs/README.md
• docs/config.md
• docs/install.md
• docs/contributing.md
• docs/agents_md.md
• docs/sandbox.md

先说个特别关键的判断：

OpenAI 这次真正开出来的，不是一个叫 harness 的独立大框架，而是一套能从现有源码里看出思路的“Agent 工程组织方法”。

也就是说，重点不是“装哪个包”。
重点是“你怎么组织环境，才能让模型像个人一样持续稳定干活”。

三、先看最关键的一层：AGENTS.md，这玩意真不是普通 README

我觉得 OpenAI 这波最狠的一点，就是把很多原来只存在于人类老员工脑子里的“团队默契”，给编译成了 Agent 能直接吃下去的规则。

这个东西就是AGENTS.md。

1）它不是摆设，它是 agent 会真的读进去的指令层

codex-rs/core/prompt.md里明确写了AGENTS.md的规则：

• 仓库里可以有多个AGENTS.md
• 它们按目录树生效
• 越深层的规则优先级越高
• 对你最终修改到的文件，只要该目录在某个AGENTS.md作用域内，你就得遵守

这事有多重要？

特别重要。

因为以前很多团队规则都是这种状态：

• 这个目录最好别乱动
• 这个文件命名有讲究
• 这个模块不能继续长胖了
• 这个配置改了记得同步 schema
• 这个接口字段不要乱省略
• 这个测试在 Bazel 下跟 Cargo 下不一样

你看，人类都懂。
但模型未必稳定懂。

现在好了，OpenAI 干脆把这些东西写进AGENTS.md，直接变成仓库里的“本地法律”。

2）我在AGENTS.md里看到的，不只是代码风格，而是工程纪律

这份文件里很典型的一些规则，味道已经非常工程了：

• crate 命名要统一前缀
• 少用模糊布尔参数，调用点要自解释
• 模块别越长越离谱
• 超过一定规模就拆文件
• 改依赖要同步 lockfile
• 改配置要同步 schema
• 改 API 要补文档
• UI 改动要带 snapshot test
• 大量跟 Bazel/Cargo 双运行方式兼容有关的约束

你发现没有？

这已经不是“提示词工程”了。

这叫：

把仓库做成一套 agent 也能遵守的工程制度。

老实说，这一刀我觉得很关键。

因为多数 Agent 真正翻车，不是它不会写代码，
而是它不知道：

在这个仓库里，什么叫对。

四、再看第二层：prompt.md，Agent 不是自由发挥，是按工作协议在干活

codex-rs/core/prompt.md里还有一层特别关键的东西。

这玩意相当于 Codex 的“工作章程”。

里面我看到几个很有代表性的行为约束。

1）先跟用户说你要干嘛，再动手

它要求 agent 在调工具前先发一个简短 preamble。

这个设计乍一看像是礼貌问题，
其实不是。

它真正的价值在于：

• 让用户知道 agent 现在打算干嘛
• 让任务分阶段更清楚
• 让 agent 自己的行动更有结构

你别小看这一步。
很多长链路任务里，agent 一旦缺少这种“自解释动作”，很容易越做越散。

2）不要猜，能查就查，能读就读

里面明确要求：

• 不要编答案
• 不清楚就继续读文件、查上下文
• 直到问题解决再结束

这其实是在给 agent 加一道非常朴素但非常值钱的护栏：

别靠幻觉收尾。

3）改代码要优先追根因，不要做表面补丁

这条也很有意思。

OpenAI 在 prompt 里不是鼓励 agent 瞎改一通，而是明确强调：

• 优先修根因
• 不要顺手修一堆无关问题
• 如果仓库有测试和构建方式，要考虑验证

这就说明它们不是把 agent 当“自动补全器”，
而是当成一个要遵守开发纪律的工程参与者。

五、再看第三层：codex-rs的组织方式，本身就很像 Harness 思路的体现

codex-rs/README.md里面把整个 Rust CLI 的结构分得很清楚。

关键模块大概是这样：

• core/：核心业务逻辑
• exec/：无界面、自动化用的 headless CLI
• tui/：终端里的全屏交互界面
• cli/：多工具入口

我挺喜欢这个拆法。

因为它不是那种“所有东西都塞一个大仓库里，最后谁也说不清谁负责什么”。

它明显是在做两件事：

1）把职责分层

• 业务逻辑归core
• 交互方式归tui
• 自动化执行归exec
• 命令封装归cli

这样做的直接好处就是：

agent 更容易知道自己该去哪一层改。

2）减少中央大文件变成垃圾堆的概率

OpenAI 在AGENTS.md里其实也明确提到了：

• 不要把高频核心文件越堆越胖
• 超大模块优先拆出去

这背后其实就是一个非常现实的判断：

仓库不仅要给人看，也要给 agent 看。

你仓库一乱，模型就像进了老小区地下室：

• 电线乱拉
• 标识不清
• 门牌模糊
• 杂物堆满

它不是不能找，
但找错、改错、漏改的概率会瞬间上升。

六、环境变量和沙箱这一层，才是很多人低估的地方

你如果只把 Harness Engineering 理解成“把提示词写清楚”，那就看浅了。

我这次在AGENTS.md、docs/config.md、codex-rs/README.md里看到一个很明显的信号：

OpenAI 特别重视 agent 所处的执行边界。

这包括：

• 沙箱模式
• 网络权限
• 写权限范围
• MCP 工具审批
• 本地状态目录
• 证书与企业代理兼容
• 完成一轮任务后的通知机制

1）--sandbox直接就是一等公民

codex-rs/README.md里直接讲了几种 sandbox 模式：

• read-only
• workspace-write
• danger-full-access

这个设计就很说明问题。

它在告诉你：

Agent 不是默认什么都能干。

你得明确告诉它：

• 能不能写
• 能写到哪
• 能不能碰网络
• 是不是已经在隔离环境里

2）环境变量不是边角料，是行为开关

我在AGENTS.md里还看到和沙箱有关的环境变量，比如：

• CODEX_SANDBOX_NETWORK_DISABLED
• CODEX_SANDBOX

而且它特别提醒：

• 别乱改相关逻辑
• 有些测试会根据这些环境变量直接跳过

为什么？

因为很多 Agent 的翻车现场，不是不会推理，而是：

• 它以为自己能联网，结果不能
• 它以为自己能起某个进程，结果权限不够
• 它以为这个命令在当前环境可用，结果没有
• 它以为本地和 CI 行为一样，结果不是

所以说到底，
环境变量在 Agent 时代不是小配置，而是能力边界的开关。

3）MCP 工具审批也被纳入配置层了

docs/config.md里还提到：

• Codex 可以连接 MCP server
• 不同 MCP 工具可以有单独 approval 配置

这个点我觉得非常有价值。

因为一旦 Agent 真进入企业环境，工具层面一定会碰到一个问题：

不是每个工具都应该同等开放。

比如：

• 查文档的工具可以松一点
• 改代码的工具谨慎一点
• 执行部署的工具必须严格一点
• 涉及外部系统的操作，最好带审批链

这就是典型的 Harness 思维：

不是让模型更敢做事，而是让系统更清楚它什么时候该做、做到哪一步要停。

七、测试和验证这层，才是真正把 Agent 从“会写”拉到“写得稳”的地方

我这次看AGENTS.md时，另外一个明显感觉就是：

OpenAI 很重视把“结果是否正确”这件事，做成一个对 Agent 来说尽可能清晰的反馈系统。

1）UI 变更要有 snapshot

它明确提到：

• UI 或可见输出变了，要更新 snapshot test
• 而且要 review snapshot 变化

这个东西非常值钱。

因为对 agent 来说，最怕的不是有错误，
最怕的是：

错误没法稳定复现，也没法稳定归因。

2）尽量比较完整对象，而不是零碎字段

这也是典型的“让反馈更结构化”的思路。

如果一个测试只零零散散比几项字段，agent 很容易产生一种错觉：

“哦，我把这几个字段糊对了，应该就差不多了。”

可真相经常是：

• 结构错了
• 语义错了
• 上下游契约错了
• 只不过没测出来

3）Bazel / Cargo 两套环境都要照顾

这个也挺能说明工程味。

很多项目人类自己都经常会遇到：

• 本地过了
• CI 挂了
• 一个运行器过，另一个不过

你把这种不稳定环境直接丢给 Agent，
那就等于让它一边写一边猜地板哪块会塌。

所以 OpenAI 的很多规则，本质上是在做一件事：

把反馈噪声降下来。

而反馈一旦清晰，Agent 的表现真的会明显上升。

八、为什么不改模型，光改仓库结构、工具层和反馈层，就可能把成绩拉高很多？

这个问题是整件事最核心的地方。

我现在的理解是：

模型能力像发动机，Harness 像整车传动系统。

发动机没换，
但你把：

• 方向盘
• 变速箱
• 刹车
• 仪表盘
• 路况标线
• 维修工具
• 故障报警

全补齐了，
整台车的表现当然会完全不一样。

具体拆开看，我觉得至少有这几层原因。

1）减少搜索空间

Agent 真正贵的，不是打字。

而是：

• 找文件
• 判权威入口
• 识别死代码
• 避免被旧文档误导
• 判断哪个实现才是真的

仓库一乱，Agent 大量 token 都浪费在“找路”上。

2）提高上下文密度

一个整理过的仓库，给模型喂进去的上下文质量会高很多。

简单说就是：

少一点垃圾，强一点信号。

你别看这话土，
可这就是事实。

3）让动作边界更清楚

当 agent 明确知道：

• 这里可读
• 那里可写
• 这个工具要审批
• 这个测试是可信的
• 这个命令只在某环境成立

它的行为就会稳很多。

4）把失败变成可诊断问题，而不是玄学

差的环境里，Agent 失败之后你看到的常常是：

• 不 work
• 又报错了
• 改了还是不对

好的 harness 里，失败会被拆成：

• schema 没更新
• snapshot 漏同步
• lockfile 漂移
• 权限不够
• 资源路径不兼容
• 工具审批没过

你看，这就从“玄学翻车”变成“工程问题”。

而工程问题，就能被系统性解决。

九、所以网上说的“从 30 多名到第 5 名”，我怎么理解？

这一句我单独说下，免得讲得太满。

我这次能确认的是：

• OpenAI 公开确实在强调 Harness Engineering
• 公开叙事里也确实在强调“几个月几乎不手写代码”
• 核心观点就是：很多进步来自 harness，而不是单纯换模型

但那个“从 30 多名到第 5 名”具体对应哪个榜单，我这次没能直接把 OpenAI 正文全文抓下来逐字核对。

所以更稳妥的表述我觉得应该是：

网上流传的那个名次跃升，很符合 OpenAI 这次想表达的核心：同一个脑子，在更好的工程鞍具里，战斗力会飙得非常明显。

这点我认为方向是完全对的。

十、如果让我用一句最土、但最容易记住的话概括这套范式

我会这么说：

Harness Engineering 不是把模型变聪明，而是别让模型刚上工位就踩坑。

坑都有哪些？

• 仓库乱
• 文件太肥
• 规则没写明
• 工具权限模糊
• 测试反馈不稳
• 文档过期
• 环境边界不清
• 中间件状态混乱

这些坑，人都烦，
模型更烦。

而且模型一烦，不是抱怨两句，
它是真会改错地方、走错流程、掉进死循环。

所以你后面会越来越发现：

Agent 工程的高级感，不在于整了多少炫酷词，而在于你把多少坑提前填平了。

十一、这套思路对我们自己做 Agent 项目，有什么直接借鉴价值？

我觉得特别大。

而且不是那种“听着有道理，但落不下来”的大。

是能直接开干的那种大。

如果让我给自己的多 Agent 项目列一个 Harness 改造清单，我会先从下面几件事下手。

1）先给仓库立规矩，不要全靠脑补

最直接的做法就是：

• 根目录放一份总规则
• 复杂子系统单独放局部规则
• 明确作用域和优先级

内容可以包括：

• 哪些目录谁负责
• 哪些入口是权威逻辑
• 哪些文件别继续加东西了
• 改配置后要同步什么
• 改接口后要同步什么
• 测试优先跑哪些

2）把中央大文件拆掉

这个我现在越来越信。

很多 Agent 项目喜欢搞一个超级 orchestrator，
最后所有路由、状态、工具调用、异常处理、提示词拼接，全塞一个文件里。

人都看得头大，
模型进去更像进迷宫。

3）给工具调用加分级权限和审批

尤其是这些动作：

• 写文件
• 执行命令
• 改数据库
• 发外部请求
• 发布部署

这些绝对别一锅端全开放。

4）把验证层做扎实

不要让 Agent 改完之后只能靠“看起来像对了”。

至少要有：

• 局部测试
• 基本构建检查
• 关键输出 snapshot
• 配置/schema 一致性校验

5）清理仓库垃圾和死代码

这个动作非常土，
但收益可能比你换一轮模型还直接。

因为垃圾文件对 Agent 的伤害，和对人是一样的：

它会制造伪线索。

十二、我自己看完后的真实感受

说实话，我看完这套东西之后，最大的感受不是“OpenAI 又发明了个新名词”。

我真正的感受是：

AI coding 这件事，开始从卷大脑，慢慢转向卷工位了。

以前大家比的是：

• 谁更聪明
• 谁推理更强
• 谁上下文更长

后面可能越来越比的是：

• 谁的 Agent 更懂仓库规则
• 谁的工具接得更顺
• 谁的沙箱更合理
• 谁的审批机制更成熟
• 谁的测试反馈更稳定
• 谁的工程结构更适合机器修改

这个变化我觉得特别现实。

因为真进生产环境之后，
决定你能不能连续跑 100 个任务不翻车的，
很多时候还真不是“模型临场灵不灵”，
而是“你的工程地基稳不稳”。

这就是我觉得 Harness Engineering 值得认真看的原因。

它不是又来了一套空对空术语，
而是在提醒我们：

模型外面的世界，终于开始被当成一等公民来设计了。

总结

这篇如果只留一句话，我觉得可以是：

OpenAI 这次讲的 Harness Engineering，本质上是在说：同一个 Agent，放在垃圾工位上和放在精心整理过的工程系统里，战斗力会像两种生物。

我这次从openai/codex里实际看到的几个关键点是：

• AGENTS.md把团队默契变成 agent 可执行规则
• prompt.md把 agent 行为做成工作协议
• core / exec / tui / cli这种分层结构让职责更清晰
• sandbox、环境变量、MCP 审批把能力边界写死
• 测试、snapshot、schema、lockfile 这些验证链让反馈更稳定

所以它牛的地方，不是“偷偷改了模型脑子”。

而是：

它把模型外面的那套工程鞍具，越做越像样了。

以后谁家 Agent 更能打，
我越来越觉得，未必只看参数和榜单，
还得看一件更朴素的事：

谁家的工位收拾得更像个能长期打仗的地方。

参考资料

• OpenAIcodex仓库：https://github.com/openai/codex
• AGENTS.md：https://github.com/openai/codex/blob/main/AGENTS.md
• codex-rs/core/prompt.md：https://github.com/openai/codex/blob/main/codex-rs/core/prompt.md
• codex-rs/README.md：https://github.com/openai/codex/blob/main/codex-rs/README.md
• docs/config.md：https://github.com/openai/codex/blob/main/docs/config.md
• docs/install.md：https://github.com/openai/codex/blob/main/docs/install.md
• docs/contributing.md：https://github.com/openai/codex/blob/main/docs/contributing.md

作者：AI极客老X
发布时间：2026年3月26日
原创声明：本文为个人学习整理，转载请注明出处。

老X的土话总结：别老怪模型不够聪明，很多时候先把工位收拾干净，脑子自己就灵了。