全行业都狂卷 Harness，Anthropic 还在加码，Codex 负责人却说它正在退场

今年年初，OpenAI 的架构师 Bill Chen 和 Brian Fioca 在一期演讲里详细介绍了 Codex 构建过程中克服的挑战，以及 Coding Agent 本身一些新兴的使用模式。谈及 Coding Agent 的构成时介绍其由三部分组成：用户界面、模型和 Harness。

用户界面显而易见，可能是命令行工具，也可能是集成开发环境，或者是云端或后台 Agent。模型也很直白，比如 OpenAI 的 GPT-5.1 系列模型或其他一些供应商的模型。至于 Harness，这是一个稍微复杂一点的部分，它直接与模型交互，最简化地说，可以将其看作是由一系列提示和工具组合而成的核心 Agent 循环，它为模型提供输入和输出。

Harness 是模型的接口层，它是模型与用户、代码之间进行交互的媒介。它包括了模型需要的所有组件，以便在多轮对话中进行工作，调用工具，并最终为你编写代码，解读用户的需求。对一些产品来说，Harness 可能是其中的关键部分。

Anthropic 前几日也发布了一篇博客文章，名为《Harness design for long-running application development》（长时运行应用开发的 Harness Design），文中提到 Harness 指的是一种 支撑复杂 AI 智能体（Agent）运行的外部框架、控制结构与编排系统。它不是单一的算法，而是一整套工程化的“脚手架”，用于管理和放大 AI 的能力。

它是 Prompt Engineering（提示词工程）之上的更高级抽象。Prompt 决定了单次对话的质量，而 Harness 决定了多轮、多智能体、长时任务的执行流程和可靠性。

Harness 的 核心作用是 解决 AI 在完成复杂、耗时任务时的“失控”问题（Go off the rails），通过外部控制机制弥补模型内在的缺陷（如上下文焦虑、自我美化）。

无论是 OpenAI 还是 Anthropic，都明确认定 Harness 是 Coding Agent 落地的关键，但两家顶级巨头的分歧在于，该把 Harness 做强做厚，还是做薄做轻？

Harness 该做大还是缩小？ 

行业内部也似乎正在形成一种新的共识：决定 AI 编程上限的，不再是模型本身的单次生成能力，而是 Harness Engineering。

在 Anthropic 最近的工程文章展示了他们对 Long-running Agent（长时运行智能体） 的深度探索。为了解决 AI 在长时间任务中“脱轨”的问题，他们构建了一套极其严密的 Harness：

• 结构化交接（Structured Handoff）： 强制 AI 在上下文耗尽前生成“进度文件”，将状态外置。
• 多智能体协作： 引入 Planner（规划器）、Generator（生成器）、Evaluator（评估器）分工。
• 上下文重置机制： 为了避免“上下文焦虑”，直接清空对话历史，仅保留结构化产物，给新智能体一张“白板”。

这种思路的本质是“把 Harness 做强、做厚”。他们认为，只要框架足够健壮，就能撑起最复杂的任务。

但近日，OpenAI Codex 开源负责人 Michael Bolin 做客了一档访谈栏目，释放出了与 Anthropic 把 Harness 做厚做强相反的信号。

这场对话围绕“AI 编码时代，真正改变软件开发范式的究竟是“大模型本身”，还是围绕模型构建的 harness？”这一话题展开。

在访谈中，Michael 认为，Harness 不应该无限膨胀。

Michael 根据 Codex 的构建理念阐述了一个他们看到的重要趋势：理想状态下，harness 应该“尽可能小”，而模型应“尽可能强”。Codex 的设计理念就是减少工具数量、避免过度干预，让模型在更接近真实计算环境（如终端）的空间中自主探索解决路径。这种“AGI 导向”的思路，本质上是在减少人为规则对模型的束缚，把更多决策权交还给模型本身。但 Michael 也提到，在这一过程中，安全（security）和隔离（sandboxing）成为不可妥协的底线，也是 harness 不可替代的核心职责。

Codex 的理念更倾向于 “把 Harness 做薄、做轻”，具体表现在以下几点：

最小化工具依赖： 甚至刻意减少专用工具，转而让模型直接使用通用的终端（Terminal）。

环境而非框架： Harness 仅提供必要的沙箱（Sandbox）安全环境和基础接口，不做过多的流程控制。

能力回归模型： 探索、决策和执行的逻辑，尽量交给模型自身去学习，而不是由外部的编排框架硬编码。

这种思路担心的是，过于复杂的 Harness 反而会把模型“教傻”，或者产生沉重的工程负担，拖慢迭代速度。

OpenAI 和 Anthropic 的两种路径选择给 AI 从业者带来一个必须要思考的问题：Harness，到底是 AI Coding 的终局，还是一个正在被快速放大的中间态？

因为这个问题的答案决定了未来的产品形态：

如果 Harness 是终局： 那么未来的竞争将是“框架之战”。谁拥有最强健、最通用的 Harness（如 Anthropic 展示的多智能体架构），谁就能统治开发流程。AI 编程将演变为“系统工程 + AI”。

如果 Harness 是中间态： 那么现在的复杂框架只是为了弥补当前模型的短板。随着模型能力的指数级提升（如更强的记忆、更长的上下文、更好的推理），这些复杂的外部编排最终会被模型内化。届时，Harness 将退化为一个简单的运行环境（Sandbox），而核心竞争力将再次回归到 基座模型的能力 本身。

Michael Bolin 并非传统意义上的“AI 从业者”。在加入 OpenAI 之前，他曾长期任职于 Google 和 Meta，参与构建开发者工具与基础设施，主导或参与过 Buck、Nuclide、DotSlash 等项目。

对话内容经由 InfoQ 翻译及整理，略有删减：

关于 AI 编码与 Harness Engineering 

主持人：今天很高兴邀请到 Michael Bolin。他是 Codex 的负责人。人们通常认为，AI 编码的核心就是“模型写代码”。但很多在构建智能体的团队认为，真正的变化在于围绕模型设计环境。你更认同哪一种？

Michael： 模型当然会主导整体体验。但我们发现，在 Harness 这一层仍然有很大的创新空间。这不仅仅是一个研究问题。对我们团队来说，关键在于工程与研究之间的协同——共同开发智能体，确保 harness 能够让智能体发挥最佳能力。同时，还要为智能体提供合适的工具，要确保智能体使用的这些工具，在训练阶段就已经被模型“见过并练习过”，这样在真实产品环境中调用这些工具时，模型不会“陌生”或“出错”。

主持人：我们来定义一下 harness，以及它为什么变得如此重要。

Michael：harness 有时也被称为 Agent loop——它负责调用模型、采样，并提供上下文：我想做什么、有哪些工具可用、下一步该做什么。然后模型返回响应——通常是一个工具调用，比如“我想用这些参数调用这个工具，请告诉我返回结果”。

有些工具很简单，比如运行一个可执行文件并返回 stdout 和退出码。我们也做了很多更复杂的工具实验，比如控制机器、控制用户的笔记本，更像是一个交互式终端，而不是简单的命令执行。也可以进行网络搜索等操作。

对于 Codex 来说，因为它是一个编码 Agent，而我们非常重视安全和沙箱机制，因此 harness 的核心工作之一就是从模型获取 shell 命令或计算机操作指令，并确保它们在沙箱中执行，或者遵循用户设定的策略。这部分其实非常复杂。关键是既要释放模型的全部能力，又要确保在用户机器上的安全运行。

主持人：在开源 Codex 时，你们是如何处理安全问题的？

Michael： 这些实现其实都可以在我们的代码库中看到。我们针对不同的操作系统做了不同的处理：在 macOS 上，我们使用了一种叫做 Seatbelt 的技术。在 Linux 上，我们使用了一系列库——包括 Bubblewrap、seccomp 和 Landlock。在 Windows 上，我们实际上构建了自己的沙箱。其中一些组件，比如 Seatbelt，是 macOS 的一部分，所以它们不在开源代码库里——我们就是这么称呼的。但我们的 Windows 沙箱代码在开源代码库里。我们会协调所有这些调用，确保它们以适当的方式通过沙箱，以适应不同的工具调用。

主持人：所以当别人 fork Codex 时，这些安全规则也都包含在里面了吗？

Michael： 是的，不过这里要区分“security”和“safety”。我刚才说的更多是 security，比如你可以运行工具，但只能访问特定文件夹。而行业里说的 safety，更多发生在后端——即模型本身是否会提出合适的工具调用。从 harness 的角度来看，它更像是在执行命令，而哪些命令是安全的，是由模型决定的。

所以，如果你 fork Codex 并继续使用我们的模型，那么你也继承了这部分安全性。但如果你换了别的模型，情况就不一定了。

Codex 是如何发展的？ 

主持人：自从你们推出 Codex 以来，它的发展情况如何？

Michael： 反响非常好，使用量相比年初增长了大约五倍。我们在 2025 年 4 月作为 o3 和 o4 mini 发布的一部分推出，当时模型在工具调用和指令执行方面还不够理想。到了 8 月 GPT-5 发布后，我们更新了 CLI，这是一个关键转折点。之后我们推出了 VS Code 插件，用户增长非常快，甚至超过了 CLI。再后来是今年年初推出的应用，也迅速流行起来。我认为它在很多方面都是真正意义上的首创。

主持人：在你看来，这个应用的创新点是什么？

Michael： 开发者历来大部分时间都花在集成开发环境（IDE）中，。这些都是显而易见、顺理成章的选择。

开发者通常在 IDE 中工作，所以我们进入 VS Code、JetBrains、Xcode 是很自然的。借助 Codex 应用，我们实际上建立了一个全新的界面。我把它看作“任务控制中心”，可以同时管理多个对话。同时它保留了 IDE 的核心能力，比如查看 diff、使用 Command-J 快捷键打开终端，而无需切换到其他窗口。它真正打破了你必须始终将所有代码都放在眼前的固有观念。对很多人来说，能够同时组织和协作多个 Agent 更有价值。这正是我们努力实现的核心功能。

编码代理如何改变开发者的工作流程 

主持人：像 Codex 这样的编码代理，会如何改变开发者的日常工作？

Michael：最大的变化是吞吐量。你可以并行推进很多任务。当然，这带来了一些上下文切换，并不是所有人都喜欢，但如果掌握得好，效率会非常高。

我个人维护着大约五个 Codex 代码库的副本，经常在它们之间切换。有时候，我只是在做其他事情的时候注意到一些小问题，然后快速修复一下。而有时候，我需要花一整天的时间，在会议间隙处理 Codex 的一个重大变更。很多人即使只有五分钟的会议间隙，也会发一条消息，只是为了推动某个任务朝着另一个方向发展。

第二点是，人们正在花更多时间研究如何优化这个工作流程。相对而言，这一切都非常新颖。我应该把一直在做的事情变成一项可复用的技能吗？我应该把这项技能分享给我的团队成员吗？优秀的开发者总是会努力优化他们的内部循环（Inner loop），但这是一个全新的内部循环，每个人都还在摸索中。

第三件备受关注的事情是代码审查。代码审查的数量显著增加，但 Codex 本身也承担了大量的代码审查工作，这节省了大量时间。如何最大限度地利用这些资源仍然是一个不断探索的问题。

主持人：你在最初开发 Codex 时，有没有遇到什么意想不到的事情？

Michael Bolin： 我最大的感受是技术发展太快了。Codex 成立至今还不到一年，考虑到这段时间发生的巨大变化，这真是令人惊叹。

我们在 2025 年 4 月发布时，那是 o3 和 o4 发布计划的一部分。当时我们使用了推理模型，但工具调用和指令执行方面还没有达到我们预期的效果。看到这方面随着时间的推移而不断改进，真是令人欣慰。

早期最令人兴奋的事情之一就是让 Codex 自己编写更多代码——亲眼见证这个过程。比如 agents.md 逐渐成为标准，搭建起框架，让你能够构建出优化自身工作流程的工具。这带来了一种指数级的飞跃，既令人兴奋又充满乐趣。看到同事们真正理解 Codex 并把更多工作转移到 Codex 上——这真是太棒了。

智能体时代的代码库 

主持人：当代码库是由智能体而不是人类来阅读时，它应该是什么样？

Michael：整个智能体编码之旅中一个有趣的现象是，软件开发中一些长期以来被认为是最佳实践的做法，我们却从未真正实践过。文档就是一个例子，测试驱动开发也是如此。人们并非完全忽视它们，但总觉得得不偿失。而现在，在智能体优先的世界里，这些变得非常有价值。人们几乎是在重新发现它们，并且真心实意地重视它们。

例如，想想 agents.md 文件，我们写在里面的所有内容，我认为也同样适用于新加入团队的人——他们需要知道的一切，所有最佳实践。把这些内容写下来，既方便了智能体，也方便了你的队友，这实际上是一种解脱。

也就是说，在 Codex 上，我们自认为已经接受了通用人工智能（AGI）的理念——这意味着智能体应该真正自主决定做什么，而不是我们不断地向它灌输指令。与其编写一份与源代码并行运行、容易导致重复或不一致的文档，我们不如让智能体花时间阅读代码并形成自己的判断。我们会尝试在 agents.md 文件中添加一些它无法从代码中快速获取的信息，例如：如何运行测试，或者哪些测试比哪些测试更重要。但我们尽量避免过度干预，而是让智能体自行决定最佳的执行路径。

主持人：你认为在不久的将来，agents.md 会由智能体自己写吗？

Michael： 很多人已经这么做了，比如在指令中加入“完成后更新 agents.md”。我们团队没有强制这样做，但这是常见做法。

Michael：现在确实有不少人这么做。我看到很多开发者会在自己的提示说明里加上一条类似的要求：任务完成后，顺便更新 agents.md 文件，把过程中值得记录的内容补充进去——包括那些不那么显而易见的信息，或者是在和 Codex 协作开发时逐渐发现的经验。

不过在我们团队内部，这还没有成为一项通用规范。你如果去看代码库的历史记录，也能发现我们并没有系统性地这么做，但在社区里，这种方式已经比较常见了。

另外，学界也开始讨论一个问题：到底应该给智能体提供多少信息才合适。我个人觉得，这很大程度上取决于具体的智能体能力。

在 Codex 的实践中，我们采取的是一种相对克制的方式——不会写成几十页的详细说明，而是只保留一些关键要点，让智能体自己去理解和发挥。

Codex 不生成“垃圾” 

主持人：Context Engineering 似乎是这个过程中越来越重要的部分。对于智能体来说，会不会出现“上下文过多”的问题？

Michael： 从我的经验而非研究角度来看：对于中等规模的任务，我通常会描述一段代码，然后让 Codex 熟悉这部分代码。有时，如果我认为有帮助，我会提供明确的文件指针，但通常我不会——它自己就能很好地搜索代码库。

有一件容易被忽视但却至关重要的事情：确保文件和文件夹命名规范。这本身就是一种良好的习惯，当 Agent 程序搜索代码时，这一点显得更加重要。

大部分上下文信息将来自 agents.md 文件、我编写的提示以及一些文件引用。我还授予了 Codex 访问 GitHub 的权限，这样它就可以查看类似这样的信息：例如，这个拉取请求中也出现了类似的问题，它不仅可以看到代码，还可以看到围绕该拉取请求的讨论。但再次强调，这更多的是为了让 Codex 了解它有哪些选择——就像是给它提供了工具箱里的工具一样——而不是规定它应该如何解决问题。这是一个很好的模型，所以它在这方面做得很好。

主持人：听起来这种工作方式会促使你采用更严格的架构。是这样吗？

Michael：当然。Codex 会遵循它在代码库中发现的模式。如果你一开始就拥有良好的架构，它就会遵循它、维护它，并强制执行你设定的不变式——从长远来看，你就会处于有利地位。当然，这对人类开发者来说也是如此。只是现在的变化速度要快得多，所以如果你有这些标准，你就能更深刻地感受到它们带来的好处。

主持人：你是否仍然看到模型和编码代理中存在大量缺陷？你是如何应对的？

Michael：说实话，我觉得 Codex 里并没有真正称得上“糟糕”的东西。我更多地看到的是，这些模型喜欢编写代码。所以有时候正确的做法是删除代码，你可能需要更明确地说明这一点。但这其实算不上糟糕——更像是：你在这个文件里添加了 500 行代码，也许你应该新建一个文件。这些都更容易解决。

更常见的情况是，Codex 掌握了我尚未接触过的习语或语言特征，并加以运用。我因此学到了新东西。这才是 Codex 带给我惊喜的更多方式——而不是敷衍了事。

模型与 Harness Engineering，谁更重要？ 

主持人：你刚才描述的是，Codex 刚起步的时候，模型还不完善。现在模型已经成熟很多，应用本身也吸引了更广泛的用户群体。但我想问的是，模型与 Harness Engineering 谁更强大？Harness Engineering 是否会在某个阶段不再仅仅是一个封装层，而成为一个更重要的环境？或者说，模型始终占据主导地位？模型和 harness engineering，在你看来哪个更重要？

Michael Bolin： 我明白你的意思，你是想问，有没有可能出现一种情况，Harness Engineering 逐渐消失，不再发挥太大作用？

在我看来这并非不可能。在很多方面，我们都在努力让 harness 尽可能小巧、尽可能轻量级。与其他一些智能体相比，Codex 的一个显著特点是，我们尽量减少智能体拥有的工具。例如，例如 Codex 的工具非常少，没有专门的读文件工具，而是让它使用终端命令。这与我之前提到的“AGI 理念”相呼应：我们给予它广阔的探索空间，让它自行找到最佳的运行路径。

唯一的例外是安全——沙箱是必须的。沙箱机制是防止 Codex 不受控制运行的重要保障。有时，人们会耍点小聪明，试图通过控制代理来操控上下文窗口。但作为 Codex 的作者，我们想说：“收起你的小聪明，我比你懂得多。” 但我们尽量克制。如果 Codex 即将运行一个会输出 1GB 数据的工具，我们的想法是：先让 Codex 将数据写入文件，然后再用 grep 命令搜索，但要让它自由选择如何解决问题。

主持人：你认为有可能将所有这些安全规则、沙盒机制都编码进去吗？还是应该始终有人参与其中？

Michael： 就我们关注的编码任务而言，我认为沙盒机制确实是取代人工干预的主要方法，至少对我们大部分的工作来说是这样。你遇到一个问题，把它交给 Codex，它会在一个受特定方式约束的沙盒环境中运行，让它在这个空间内探索，就能找到最佳解决方案——尤其是在大规模应用的情况下。我同时运行着五个 Codex 的克隆版本。如果我必须每隔几分钟就干预这五个版本，那会从根本上限制它们的吞吐量。

这些纠正措施应该更多地在训练阶段进行，然后在推理阶段发挥作用，而不是需要人为干预。

主持人：所以能力更多会在模型里，而不是 harness？

Michael Bolin： 是的，模型更重要。但 harness 的可靠性仍然非常重要。如果 harness 崩溃，一切就结束了。随着我们不可避免地迈向多智能体和子智能体架构——更多智能体在不同机器间通信——harness 不再仅仅是单台机器上的单个进程，而变成了一个智能体网络。我预计未来会有很多更有趣的工作要做。我的职业生涯大部分时间都在为开发者编写工具；现在我正在为智能体编写更多工具。智能体也可以编写自己的工具，但正如我所说，我们更倾向于使用少量但功能强大的工具，让智能体能够充分探索各种可能性——我们将继续尝试，找到最合适的工具组合。

未来 Agent 的发展方向 

主持人：你认为智能体编码的基础组件有哪些？

Michael：我觉得我们已经看到了很多组成部分。比如我称之为 shell 工具或终端工具的东西，它让模型能够像人一样使用计算机终端，而不仅仅是直接执行命令。它还包括处理流式输出并高效利用这些输出等功能。

记忆是另一个重要领域。过去，每次发起对话都是从零开始——这就是为什么会有 agents.md 以及各种上下文填充机制，以便快速将信息导入模型。如果你查看代码库，会发现很多关于记忆的实验。

此外，不同类型的上下文连接器（context connectors）也正在发生很多变化。最初，我们专注于本地计算机上的计算机任务，但现在它也涵盖了更广泛的工作——例如代表您发送电子邮件、创建文档以及在 Web 浏览器中执行操作。

此外，还有标准的 LLM 基础设施：一般来说，更大的上下文窗口是好事；当达到限制时如何压缩内容；所有这些都在积极探索中，并有助于提升整体代理体验。

参考链接：

https://www.youtube.com/watch?v=6BAqgT3qe98

https://www.infoq.cn/article/HFewc09HcZ1IaDyFj8D0

https://www.youtube.com/watch?v=wVl6ZjELpBk

https://www.anthropic.com/engineering/harness-design-long-running-apps

本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：冬梅，36氪经授权发布。