我终于搞懂了 Harness：它不是论文，也不是标准，更不是 Codex 独有

我终于搞懂了 Harness：它不是论文，也不是标准，更不是 Codex 独有

最近在看 Codex、Claude Code、AI Agent 相关内容时，经常会看到一个词：

Harness。

第一次看到这个词时，我其实非常困惑。

它是一篇论文提出的概念吗？

是一套类似 HTTP、MCP 的标准吗？

是一个开源项目吗？

还是 OpenAI Codex 独有的某个东西？

查了一些资料之后，我发现，这个词最容易让初学者产生误解的地方在于：

Harness 既可以表示一种思想，也可以表示某个产品中这套思想的具体代码实现。

这篇文章就完全站在技术小白的角度，把 Harness 从头讲明白。

---

一、先记住一句话：Harness 不是大模型

如果整篇文章只记一句话，可以记这一句：

模型负责“想”，Harness 负责“让模型真正把事情做完”。

比如我们使用普通聊天模型时，可以问：

“帮我把这个登录页面改成蓝色。”

模型可能告诉你：

“可以修改 CSS，把 background-color 改成 blue。”

但是它只是告诉你“应该怎么改”。

它并没有真的进入你的项目，也没有帮你找到文件、修改代码、启动项目、检查错误。

而 Codex 这种 AI 编程 Agent 就不一样。

你告诉 Codex：

“帮我修改登录页面，只修改样式，不修改接口。”

它可能真的开始执行：

读取项目
↓
查找登录页面代码
↓
查看相关 CSS
↓
修改文件
↓
运行项目
↓
执行测试
↓
发现报错
↓
继续修改
↓
再次测试
↓
完成任务

这里就出现了一个很关键的问题：

到底是谁负责控制模型一步一步往下执行？

这背后，就需要 Harness。

---

二、Harness 这个词本身是什么意思？

Harness 本来就是一个普通英文单词，并不是 AI 行业专门创造出来的。

它原本有“马具、挽具、控制装置、连接装置”之类的意思。

可以这样理解：

一匹马本身非常有力量，但是如果想让它稳定地拉车，就需要一整套马具把马和车连接起来，并且控制它怎么行动。

这套“连接、约束、控制、发挥能力”的装置，就叫 Harness。

后来，软件行业也很早就开始使用这个词。

比如软件测试领域一直都有一个词：

Test Harness，测试 Harness。

它大概表示：

把程序、测试数据、测试工具、执行流程、测试结果等东西组织起来，形成一套能够自动执行测试的环境。

到了今天的 AI Agent 时代，Harness 这个词又变得非常合适。

因为大模型虽然非常聪明，但是单独的大模型其实只是一个“大脑”。

它还需要一套系统告诉它：

• 现在有什么工具可以使用；
• 可以读取哪些文件；
• 可以执行哪些命令；
• 工具执行完之后怎么把结果重新告诉模型；
• 当前任务有没有完成；
• 上下文怎么保存；
• 权限怎么控制；
• 哪些危险操作不能执行。

把这些能力组织起来的这一层，就可以称为：

Agent Harness。

---

三、Harness 是一篇论文吗？

不是。

至少我们现在讨论的 Agent Harness，并不是类似 Transformer 那样：

“某一篇著名论文提出了一种新的理论，然后整个行业按照论文去实现。”

Harness 更接近一个逐渐形成的软件工程术语和架构概念。

大家发现：

如果想让大模型真正成为 Agent，都必须解决一批类似的问题。

例如：

模型怎么使用工具？

模型怎么读取文件？

模型怎么连续执行多个步骤？

模型出错之后怎么办？

模型怎么知道任务已经完成？

于是，逐渐把负责这一层工作的东西称为 Harness。

所以，并没有一个明确的人可以说：

“Agent Harness 是我在某年某月发明出来的。”

它更像“Web 框架”“操作系统”“数据库中间件”这种概念。

---

四、Harness 是标准吗？

这也是最容易混淆的问题。

答案是：

目前并没有一个统一的、所有 AI Agent 都必须遵守的 Harness 标准。

也就是说，并不存在这样一本正式规范：

《Agent Harness 1.0 标准》

里面规定：

第一步必须调用模型；

第二步必须调用工具；

第三步必须保存上下文；

第四步必须怎么处理错误……

目前并没有这种所有厂商都必须执行的标准。

所以，从技术上来说：

任何公司，甚至任何程序员，都可以自己实现一套 Harness。

OpenAI 可以写自己的。

Anthropic 可以写自己的。

其他 AI 公司可以写自己的。

我们自己的公司也完全可以写一套。

---

五、既然没有标准，是不是想怎么写就怎么写？

理论上可以。

但实际上，大家面对的问题非常相似。

一个比较完整的 Agent Harness，一般都会涉及下面这样的过程：

用户提出任务
↓
调用大模型
↓
模型判断下一步该做什么
↓
调用工具
↓
获得工具执行结果
↓
把结果重新交给模型
↓
模型继续判断
↓
再次调用工具
↓
不断循环
↓
直到任务完成

这就是 Agent 中非常核心的：

Agent Loop，也就是智能体循环。

除此之外，还需要解决几个非常现实的问题。

1. 工具

模型到底可以使用什么？

例如：

• 读取文件；
• 修改文件；
• Shell；
• Git；
• 浏览器；
• 数据库；
• API；
• MCP。

2. 权限

模型是不是可以执行所有命令？

当然不行。

比如模型突然想执行一个删除整个服务器数据的危险命令，就不能真的让它执行。

所以 Harness 通常还需要：

• 沙箱；
• 权限控制；
• 命令限制；
• 人工确认；
• 安全策略。

3. 上下文

一个复杂任务可能需要执行几十步，甚至几百步。

模型需要知道：

“我刚才已经做了什么？”

“现在做到哪一步了？”

“前面读取过哪些文件？”

这就涉及：

• Conversation；
• Context；
• Memory；
• Session。

4. 错误处理

例如 Agent 修改代码之后执行：

npm run build

结果报错了。

Harness 不能直接结束任务。

它需要把报错结果再次交给模型。

模型看到错误之后，重新分析，再修改代码，然后再次执行。

于是就形成：

执行
→ 报错
→ 分析
→ 修改
→ 再执行
→ 再检查

因此，虽然现在任何人都可以自己实现 Harness，但是最终需要解决的问题大体类似。

---

六、Harness 和 Codex 到底是什么关系？

现在再来看 Codex Harness，就很好理解了。

Harness 并不是 Codex 发明的概念。

OpenAI 只是为 Codex 实现了一套属于自己的 Harness。

所以，可以简单理解成：

Harness
↓
是一类架构思想和运行框架

Codex Harness
↓
是 OpenAI 为 Codex 实现的一套具体 Harness

这个关系有点像：

数据库
→ MySQL
→ PostgreSQL

操作系统
→ Windows
→ Linux

浏览器
→ Chrome
→ Safari

Agent Harness
→ Codex Harness
→ 其他 Agent 自己的 Harness

所以以后再看到“Harness”和“Codex Harness”，一定要区分。

Harness 是一类东西。

Codex Harness 是 OpenAI 的一个具体实现。

---

七、Codex Harness 到底在干什么？

以一个非常简单的例子来说。

你告诉 Codex：

“帮我修复这个项目的登录 Bug。”

接下来可能发生：

第一步，Harness 把你的要求交给模型。

第二步，模型判断：

“我要先搜索 login 相关文件。”

第三步，Harness 真正执行搜索。

第四步，把搜索结果重新交给模型。

第五步，模型判断：

“我要读取 Login.vue。”

第六步，Harness 去读取文件。

第七步，把文件内容交给模型。

第八步，模型判断应该怎么修改。

第九步，Harness 真正修改文件。

第十步，模型要求运行测试。

第十一步，Harness 执行测试。

第十二步，测试失败。

第十三步，Harness 把错误日志重新交给模型。

第十四步，模型继续分析和修改。

第十五步，再次测试。

第十六步，测试通过，任务结束。

你会发现：

模型主要负责判断“下一步做什么”。

而：

Harness 负责真正执行、反馈、继续循环。

---

八、为什么现在大家越来越重视 Harness？

以前大家聊 AI，经常关注：

GPT 强不强？

Claude 强不强？

Qwen 强不强？

也就是说，大家主要关注“模型”。

但是到了 Agent 时代，仅仅看模型已经不够了。

因为一个模型再聪明，如果它：

不能读取文件；

不能执行命令；

不会调用工具；

不知道当前环境；

任务执行失败后不会重新尝试；

没有权限控制；

没有测试反馈；

那么它最终还是只能“告诉你应该怎么做”。

而不是：

真正帮你把事情做完。

所以可以这样理解：

模型决定 Agent 聪不聪明。

Harness 决定 Agent 能不能真正干活。

甚至在某些情况下：

同一个模型，放在不同 Harness 里面，最终的实际效果也可能差很多。

---

九、普通聊天模型和 Agent 最大的区别是什么？

普通聊天模型大概是：

你
↓
模型
↓
回答

回答完，一轮就结束了。

但是 Agent 更像：

你
↓
模型
↓
工具
↓
模型
↓
工具
↓
模型
↓
工具
↓
不断循环
↓
完成任务

所以 Agent 最关键的变化之一，就是：

模型不再只负责“回答问题”，而是开始观察环境、使用工具、执行操作、检查结果。

而 Harness，就是负责把这些东西真正串起来的一层。

---

十、MCP 和 Harness 是一回事吗？

不是。

这个地方也非常容易混。

可以先简单理解成：

Harness 是整个 Agent 的工作系统。

MCP 更像 Harness 里面连接外部工具的一种标准接口。

例如：

Harness 里面可能有：

• 文件工具；
• Shell；
• Git；
• 浏览器；
• MCP。

而 MCP 又可以连接：

• GitHub；
• 数据库；
• 企业内部系统；
• 各种第三方服务。

所以：

MCP 可以成为 Harness 的一部分，但 MCP 本身不等于 Harness。

这也很好地解释了一个问题：

虽然 Harness 整体目前没有统一标准，但是 Harness 内部的某些模块，是可以逐渐标准化的。

这有点像网站。

网站到底设计成什么样，没有统一标准。

但是网站内部会使用：

HTTP、HTML、CSS、JavaScript 等各种标准。

未来 Agent Harness 很可能也是类似的发展方式。

---

十一、Harness 到底有没有代码？

这个问题要分开看。

Harness 作为一个概念，本身没有“开源不开源”这种说法。

因为它是一种思想、一种架构、一类东西。

但是：

某一家公司实现出来的 Harness，当然是有真实代码的。

例如 OpenAI 实现了 Codex Harness。

其他公司也可以实现自己的 Harness。

如果某家公司愿意把自己的实现代码公开，那就可以开源。

如果不愿意公开，那就是闭源。

所以以后如果听到别人说：

“Harness 开源了。”

其实这句话并不严谨。

更准确的问法应该是：

“你说的是哪一套 Harness 开源了？”

例如：

“Codex Harness 的相关实现是不是开源了？”

这才是一个完整的问题。

---

十二、Codex Harness 是开源的吗？

OpenAI 的 Codex 本身有公开的 GitHub 仓库：

https://github.com/openai/codex

目前该仓库采用 Apache 2.0 License。

OpenAI 也公开介绍过 Codex Harness 的 Agent Loop、工具执行、会话、沙箱等相关设计。

因此，我们确实可以看到大量 Codex 的实际实现代码。

但是仍然要注意：

“Harness 是开源的”这种说法不准确。

应该说：

Codex 中与 Harness 相关的具体实现，有大量代码是公开的。

---

十三、如果我们自己开发一个 Agent，也可以有自己的 Harness 吗？

当然可以。

假设公司内部部署了一个 Qwen 模型。

一开始只有：

用户
↓
Qwen
↓
回答

这还只是一个普通的大模型应用。

后来，公司又开发了一套程序。

这套程序可以：

• 读取服务器文件；
• 修改代码；
• 执行 Linux 命令；
• 访问数据库；
• 调用企业内部系统；
• 使用知识库；
• 保存上下文；
• 管理用户权限；
• 控制危险命令；
• 失败后自动重试。

同时它还能让 Qwen：

思考
↓
调用工具
↓
获得结果
↓
继续思考
↓
再调用工具
↓
再获得结果
↓
一直执行到任务完成

那么，公司自己开发的这一层，本质上就可以称为：

Agent Harness。

完全不需要 Codex。

---

十四、Harness Engineering 又是什么？

理解了 Harness，再看 Harness Engineering 就简单很多了。

Harness Engineering，可以简单翻译成：

Harness 工程。

以前开发软件时，工程师主要考虑：

“我怎么把代码写好？”

但是 Agent 开始真正参与开发之后，工程师还需要考虑：

“我怎么把整个项目和环境建设好，让 Agent 能稳定把事情做好？”

例如：

• 项目目录是不是足够清晰？
• 文档是不是完整？
• Agent 能不能快速找到规则？
• 测试是不是完善？
• 修改以后能不能自动验证？
• 错误信息能不能及时反馈给 Agent？
• Agent 有哪些权限？
• 哪些操作必须人工确认？
• 项目有没有清晰的规范？

这些工作，就已经不只是单纯“写 Prompt”。

它开始变成一种新的工程能力。

也就是：

Harness Engineering。

---

十五、最后用一个工厂的比喻彻底理解 Harness

假设我们建设了一座智能工厂。

那么：

大模型是什么？

相当于工厂里一个非常聪明的机器人。

Prompt 是什么？

你给机器人的任务。

Tool 是什么？

机械臂、螺丝刀、焊机等工具。

Skill 是什么？

机器人的标准作业指导书。

Memory 是什么？

机器人以前工作留下来的经验。

Sandbox 是什么？

机器人被允许活动的安全区域。

MCP 是什么？

机器人连接外部系统的一种标准接口。

那么：

Harness 是什么？

就是把机器人、工具、工作流程、安全规则、权限、反馈机制等全部组织起来的一整套工厂运行系统。

所以，一个完整的 AI Agent，大致可以理解成：

大模型
+
Harness
+
工具
+
环境
+
权限
+
上下文

真正能够持续执行任务的 Agent

而 Codex，大致可以理解成：

OpenAI 的模型
+
Codex Harness
+
开发工具
+
执行环境
+
相关服务

一个能够真正参与软件开发的 AI 编程 Agent

---

十六、总结：Harness 到底是什么？

最后把整篇文章浓缩成几个最常见的问题。

1. Harness 是论文吗？

不是。

2. Harness 是正式国际标准吗？

目前不是。

3. Harness 是 OpenAI 发明的吗？

不是。Harness 这个词和类似思想在软件工程领域早就已经存在。

4. Harness 是 Codex 独有的吗？

不是。

5. Codex Harness 是什么？

是 OpenAI 为 Codex 实现的一套具体 Agent Harness。

6. Harness 有代码吗？

Harness 作为概念没有代码，但每家公司实现自己的 Harness 时，都会变成真实的软件代码。

7. 任何人都可以实现 Harness 吗？

可以。目前并没有规定 Harness 必须按照某一种统一方式实现。

8. MCP 是 Harness 吗？

不是。MCP 更像 Harness 可以使用的一种工具连接标准。

9. 为什么现在 Harness 越来越重要？

因为随着模型能力越来越强，一个 Agent 最终好不好用，已经不只取决于模型本身，还取决于有没有一套好的 Harness，把模型、工具、环境、权限、上下文和反馈循环组织起来。

最后，如果非要让我用一句最容易理解的话解释 Harness，我会这样说：

Harness 就是把一个“只会思考和回答问题的大模型”，变成一个“能够使用工具、不断执行、检查结果，并最终真正完成任务的 Agent”的那套运行框架。

理解这一句话之后，再看 Codex Harness、Agent Harness、Harness Engineering，其实就都不难了。