AI编程核心之争：Anthropic做强Harness框架，OpenAI Codex负责人却主张轻量化

年初，OpenAI的架构师Bill Chen与Brian Fioca在一次演讲中详细剖析了构建Codex所克服的挑战，并探讨了Coding Agent新兴的应用模式。他们指出，一个Coding Agent主要由三部分构成：用户界面、模型以及Harness。

用户界面是显而易见的交互入口，可能表现为命令行工具、集成开发环境，或是云端及后台的Agent。模型部分则较为直白，例如OpenAI的GPT-5.1系列或其他供应商的模型。至于Harness，则是一个相对复杂的核心组件，它直接与模型进行交互。在最简化的视角下，可以将其视为由一系列提示（Prompts）和工具组合而成的核心Agent循环，负责为模型提供输入并处理其输出。

Harness本质上是模型的接口层，充当着模型与用户、与代码世界之间的交互媒介。它集成了模型在多轮对话中工作、调用工具、最终编写代码并解读用户意图所需的所有组件。对于某些产品而言，Harness甚至是其实现价值的关键所在。

日前，Anthropic发布了一篇题为《Harness design for long-running application development》的博客文章。文中明确，Harness指的是一种用以支撑复杂AI智能体（Agent）长期稳定运行的外部框架、控制结构与编排系统。它并非单一算法，而是一整套工程化的“脚手架”，其核心目的在于管理和放大AI模型的内在能力。

Harness是构建在提示词工程（Prompt Engineering）之上的更高层级抽象。如果说提示词决定了单次对话交互的质量，那么Harness则决定了多轮对话、多智能体协作以及长时任务的执行流程与整体可靠性。

Harness的核心作用在于解决AI在执行复杂、耗时任务时可能出现的“失控”问题（Go off the rails），通过外部的控制机制来弥补模型自身可能存在的内在缺陷，例如对上下文长度的焦虑或倾向于自我美化的倾向。

无论是OpenAI还是Anthropic，都明确认定Harness是实现Coding Agent落地的关键环节。然而，这两家顶尖AI巨头在理念上产生了显著分歧：究竟应该将Harness设计得强大而厚重，还是应该追求其轻薄与轻量？

理念分野：Harness框架的厚薄之争

行业内部似乎正在形成一种新的共识：决定AI编程能力上限的，已不再是模型单次生成代码的质量，而是Harness Engineering的水平。

在Anthropic近期的工程分享中，展示了对“长时运行智能体”的深度探索。为了解决AI在长时间任务中容易“脱轨”的问题，他们构建了一套极其严密和复杂的Harness体系：

• 结构化交接：强制要求AI在上下文耗尽前生成“进度文件”，将任务状态外置保存。
• 多智能体分工协作：引入规划器、生成器、评估器等不同角色的智能体进行分工。
• 上下文重置机制：为避免“上下文焦虑”，直接清空对话历史，仅保留结构化的任务产物，为接手的智能体提供一张干净的“白板”。

这种设计思路的本质是 “把Harness做强、做厚” 。Anthropic认为，只要外部框架足够健壮和精密，就能支撑起最复杂的开发任务，确保过程的可靠与可控。

然而，OpenAI Codex的开源负责人Michael Bolin近日在一次访谈中，释放出了与Anthropic截然相反的信号。这场对话围绕一个核心议题展开：在AI编码时代，真正改变软件开发范式的，究竟是“大模型本身”的能力飞跃，还是围绕模型构建的“Harness”工程体系？

Michael在访谈中明确提出，Harness不应该无限膨胀。他基于Codex的构建理念，阐述了一个被他们观察到的重要趋势：在理想状态下，harness应当“尽可能小”，而模型的能力应“尽可能强”。Codex的设计哲学致力于减少专用工具的数量、避免对模型进行过度干预，转而让模型在更接近真实计算环境（例如终端）的空间中自主探索解决方案。这种“AGI导向”的思路，本质上是在减少人为制定的规则对模型的束缚，将更多的决策权交还给模型本身。当然，Michael也强调，在这一过程中，安全性（security）和隔离性（sandboxing）是不可妥协的底线，这也构成了Harness不可替代的核心职责。

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

• 最小化工具依赖：刻意减少专用工具，鼓励模型直接使用通用的终端（Terminal）来解决问题。
• 提供环境而非框架：Harness仅提供必要的沙箱安全环境和基础接口，不过多进行流程控制。
• 能力回归模型本身：将探索、决策和执行的主要逻辑，尽量交由模型自身通过学习和推理来完成，而不是依靠外部编排框架进行硬编码。

这种思路背后隐含的担忧是，过于复杂的Harness反而可能限制模型的创造性，将其“教傻”，或者带来沉重的工程负担，拖慢整个系统的迭代与进化速度。

OpenAI与Anthropic的两种路径选择，给所有AI从业者提出了一个必须深思的问题：Harness，究竟是AI编程的终极形态，还是一个正在被快速放大、终将被模型能力内化的中间状态？

这个问题的答案，将在根本上决定未来AI编程产品的形态：

• 如果Harness是终局：那么未来的竞争将是“框架之战”。谁能够打造出最健壮、最通用的Harness（例如Anthropic展示的多智能体架构），谁就能主导未来的开发流程。AI编程将演变为一场“系统工程与AI能力”的结合竞赛。
• 如果Harness是中间态：那么当前复杂的框架设计，主要是为了弥补现有模型的能力短板。随着模型能力（如记忆、长上下文、推理能力）的指数级提升，这些外部编排逻辑最终会被模型内化吸收。到那时，Harness将退化为一个简单的运行环境（Sandbox），而核心竞争力将再次回归到基座模型本身的能力上。

深入对话：Codex负责人的轻量化哲学

以下是经整理的Michael Bolin访谈要点，探讨了AI编码与Harness工程的未来。

关于AI编码的核心与Harness Engineering的重要性

主持人：在构建智能体的团队中，有人认为真正的变革在于围绕模型设计环境（Harness），而非仅仅是模型写代码的能力。你如何看待？

Michael：模型无疑主导着整体体验。但我们发现，在Harness这一层仍然存在巨大的创新空间。这不仅仅是一个研究课题，对我们团队而言，关键在于工程与研究的协同——共同开发智能体，确保Harness能够让其发挥最佳能力。同时，还要为智能体提供“合适”的工具，并确保这些工具在模型的训练阶段就已经被“见过并练习过”，这样在真实产品中调用时，模型才不会感到“陌生”或容易出错。

主持人：能否具体定义一下Harness，以及它为何变得如此关键？

Michael：Harness有时也被称为Agent循环（Agent loop）。它负责调用模型、进行采样，并提供上下文：包括任务目标、可用工具以及下一步指示。接着，模型返回响应——通常是一个工具调用指令。有些工具很简单，比如运行一个可执行文件并返回结果。我们也实验过更复杂的工具，例如控制整台机器、操作用户的笔记本（更像交互式终端），或是执行网络搜索。

对于Codex这样的编码Agent，我们极度重视安全与沙箱机制。因此，Harness的一项核心工作就是从模型接收Shell命令或计算机操作指令，并确保它们在沙箱中安全执行，或遵循用户设定的策略。这部分实际上非常复杂。关键在于，既要充分释放模型的全部能力，又要确保其在用户机器上安全、受控地运行。

Codex的发展轨迹与安全实践

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

Michael：反响非常积极，使用量相比年初增长了大约五倍。我们在2025年4月随o3和o4 mini模型一同发布，当时模型在工具调用和指令遵循方面还不够完善。8月GPT-5发布后，我们更新了CLI，这是一个关键转折点。随后推出的VS Code插件用户增长极快，甚至超过了CLI。今年初上线的独立应用也迅速流行起来。我认为它在很多方面都是开创性的。

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

Michael：开发者历来大部分时间都花在IDE中，因此我们进入VS Code、JetBrains等环境是顺理成章的选择。但通过Codex应用，我们实际上建立了一个全新的界面。我将其视为一个“任务控制中心”，可以同时管理和协作多个对话。它保留了IDE的核心功能，比如查看代码差异、用快捷键打开终端，而无需切换窗口。它真正打破了“必须时刻将所有代码置于眼前”的传统观念。对许多人来说，能够同时组织并推进多个Agent任务更具价值，这正是我们努力实现的核心功能。

编码Agent如何重塑开发工作流

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

Michael：最显著的变化是吞吐量的大幅提升。你可以并行推进多项任务。这当然会带来上下文切换的成本，并非所有人都喜欢，但如果运用得当，效率将非常高。我个人就同时维护着大约五个Codex代码库的副本，并经常在它们之间切换。

第二点是，人们正花费更多时间研究如何优化这一全新的工作流程。相对而言，这一切都非常新颖。开发者们在思考：是否应该将常用的操作转化为可复用的技能？是否应该与团队成员分享这些技能？优秀的开发者总会优化他们的“内部循环”，而现在，这是一个全新的、所有人都在摸索的“内部循环”。

第三点是代码审查。代码审查的数量显著增加，但Codex本身也承担了大量的审查工作，节省了大量时间。如何最大化利用这些资源，仍然是一个持续探索的课题。

智能体时代的代码库与开发实践

主持人：当代码库的主要读者是智能体而非人类时，它应该是什么样子？

Michael：智能体编码之旅中一个有趣的现象是，软件开发中一些长期被视为最佳实践、却往往未能充分落地的方法，正被重新发现并高度重视。文档和测试驱动开发就是典型的例子。

以agents.md文件为例，我们在其中记录的内容，对于新加入团队的成员同样至关重要——他们需要知道的所有信息和最佳实践。将这些内容清晰地写下来，既方便了智能体，也造福了你的队友，实际上是一种解放。

在Codex团队，我们倾向于接受AGI的理念——即智能体应该能够自主决定如何行动，而不是我们不断向它灌输指令。与其编写一份可能与源代码脱节、容易导致不一致的冗长文档，我们更倾向于让智能体花时间阅读代码并形成自己的理解。我们会在agents.md中补充一些它无法快速从代码中获取的信息（例如如何运行测试、测试的优先级），但尽量避免过度干预，而是让智能体自行决定最佳的执行路径。

主持人：如何确保提供给智能体的上下文是高效且不过载的？

Michael：从实践经验（而非纯粹研究）来看：对于中等规模的任务，我通常会描述一段代码，然后让Codex去熟悉它。有时我会提供明确的文件指针，但通常不会——它自己的代码搜索能力已经很出色。

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

大部分上下文将来自agents.md、我编写的提示词以及一些具体的文件引用。我们还授予Codex访问GitHub的权限，使其可以查看相关的Pull Request及其讨论。但再次强调，这更多是为了让Codex了解它有哪些可选项（就像提供了工具箱），而不是规定它必须如何解决问题。

模型与Harness，孰轻孰重？

主持人：随着模型能力的成熟，Harness Engineering是否会从一个简单的封装层，演变为更重要的“环境”？在你看来，模型和Harness工程哪个更重要？

Michael Bolin：你是想问，Harness Engineering未来是否会逐渐消失，不再重要？

在我看来，这并非不可能。在很多方面，我们都在努力让Harness尽可能小巧、轻量。Codex的一个显著特点是，我们尽量减少智能体可用的专用工具数量。例如，没有专门的“读文件”工具，而是让模型使用终端命令去读取。这与“AGI理念”相呼应：我们给予它广阔的探索空间，让它自行发现最佳路径。

唯一的例外是安全——沙箱机制是必须存在的底线。它是防止Codex不受控制运行的关键保障。我们尽量克制对模型的干预。例如，如果Codex要运行一个会输出巨量数据的工具，我们的想法是：让它先写入文件，再用grep搜索，但要让它自由选择如何解决问题。

主持人：你认为有可能将所有安全规则都编码进模型吗？还是始终需要外部干预？

Michael：就我们关注的编码任务而言，我认为沙箱机制确实是取代人工干预的主要方法。你遇到一个问题，交给Codex，它在一个受约束的沙箱环境中探索并解决。如果我必须频繁干预同时运行的多个Codex实例，那会从根本上限制其吞吐量。这些纠正措施应该更多地在模型训练阶段完成，然后在推理阶段自然生效。

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

Michael Bolin：是的，模型本身更重要。但Harness的可靠性依然至关重要——如果Harness崩溃，一切就结束了。随着我们不可避免地迈向多智能体、跨机器通信的架构，Harness不再仅是单个机器上的单个进程，而会演变成一个智能体网络。我预计未来在这方面会有更多有趣的工作。我的职业生涯大部分在为开发者编写工具；现在，我正在为智能体编写更多工具。智能体也可以编写自己的工具，但我们更倾向于提供少量但功能强大的工具，赋予智能体充分的探索自由。

未来方向：智能体编码的基础组件

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

Michael：我们已经看到了很多组成部分。首先是Shell工具或终端工具，它让模型能够像人类一样使用终端，而不仅仅是执行单条命令，还包括处理流式输出等。

记忆是另一个重要领域。过去每次对话都从零开始，因此出现了agents.md和各种上下文填充机制，以便快速将信息导入模型。代码库中有很多关于记忆的实验。

此外，不同类型的上下文连接器也在快速发展。最初我们专注于本地计算机任务，但现在也涵盖了更广泛的工作，例如发送邮件、创建文档、操作网页浏览器。

当然，还有标准的LLM基础设施：更大的上下文窗口、达到限制时的内容压缩技术等，所有这些积极的探索都有助于提升整体智能体体验。