Claude Code爆火背后的Agent Harness底层逻辑，UIUC、Meta、斯坦福深度解读

过去两年，大模型写代码这件事已经不算新鲜了。从代码补全到 GitHub issue 修复，从竞赛编程到仓库级软件工程，人们习惯用一个简单标准来评判 coding agent：代码能不能写对？测试能不能通过？

但Claude Code、Codex这类系统的出现，把讨论的焦点不知不觉往下沉了一层。真正强的coding agent，并不只是“会写代码”那么简单。它还要能在较长时间窗口内做这些事情：读仓库、做计划、改文件、跑命令、看报错、修故障、维护上下文，并在多轮反馈中持续推进任务。

这套让模型长期可靠“跑起来”的执行系统，就是Agent Harness。很多关于harness的讨论，关注的仍然是模型外面该包什么：工具、API、沙箱、记忆、权限边界、验证器、反馈循环。它们回答的是“一个可用的Agent需要哪些系统组件”。

但来自伊利诺伊大学香槟分校（UIUC）、Meta和斯坦福（Stanford University）的102页综述《Code as Agent Harness》往前追问了一步：

• 论文标题：Code as Agent Harness

• 论文：https://arxiv.org/pdf/2605.18747

• GitHub仓库：https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers

注意，这里的“代码”不只是模型最终生成的那段程序，也不是说Agent框架本身是由代码写成的。它指的是Agent在harness中不断生成、运行、修改、保存和共享的一系列代码化中间物：Plan.md、测试脚本、shell命令、patch、执行日志、workflow、技能库、仿真器、验证器，甚至共享仓库状态。

传统代码生成里，代码通常是模型最后交付的产物；

换句话说，这篇综述把代码视为Agent系统中的可执行、可检查、有状态媒介，并从接口、机制、多Agent扩展三个层次展开了论述。

为什么Harness需要代码作为核心载体？

一个纯粹的大语言模型本质上是无状态的。它可以根据上下文生成下一段文本，但不会天然保存任务进度，也不会自动维护外部世界的状态变化。Harness的作用，就是把模型接入真实的执行环境。

代码之所以适合成为harness的核心载体，是因为它有自然语言不具备的三个属性：

。

可执行，意味着模型的意图可以变成真实操作。一个计划不只是“我将修改文件”，而是可以落地为shell command、patch或测试脚本。

可检查，意味着执行过程会产生客观反馈。编译错误、运行时错误、测试结果、日志和trace，都能告诉系统当前发生了什么，而不只是依赖模型自我解释。

有状态，意味着任务进度可以被持久保存。仓库、文件系统、配置、测试、commit history、skill library都能记录Agent已经做了什么、失败在哪里、下一步应该接着哪里做。

所以，这篇survey和一般harness综述最大的不同，不是又列一遍工具、记忆和沙箱，而是把代码放在了中心位置：

代码如何打通Harness的接口？

这篇综述的第一层是Harness Interface：代码如何成为模型和外部世界之间的接口。

首先，

。过去模型依赖自然语言的Chain-of-Thought来做推理，但文本推理很难验证。PoT、PAL等方法把中间推理转成程序，让解释器完成计算；Lean/Coq相关的工作则进一步把推理变成机器可检查的证明过程。关键不在于“模型会写程序”，而在于推理本身被外部化成了可执行对象。

其次，

。对于Claude Code或Codex，行动不是一句“我会修复bug”，而是实际修改文件、运行测试、查看报错、再生成patch。对于机器人，SayCan、Code as Policies、Voyager等工作展示了另一种形式：语言目标被转成技能调用、控制脚本或可复用函数。

第三，

。Agent要长期运行，就必须知道环境状态。软件仓库、测试结果、执行日志、DOM tree、仿真器、数据分析脚本，都可以成为Agent理解世界的结构化表示。SWE-bench、AgentBench等可执行评测环境也正是基于这一点：任务不再只是静态问答，而是在一个可执行环境中完成。

代码在接口层连接了reasoning、acting和environment modeling，让Agent的推理、行动与环境状态进入同一个可执行闭环。

（代码作为接口层的发展路线图。）

Harness如何用代码管理状态与反馈？

真实任务很少一步完成。修复一个bug，可能要多次定位、修改、测试和回滚；操作一个网页系统，可能要跨多个页面和工具；做一个科学实验，可能要提出假设、运行模拟、分析数据，再根据结果调整下一步。

这时，关键不只是模型更强，而是Agent的每一步是否能被组织进一个可控的执行循环。

不再只是模型脑内计划，而可以变成Plan.md、workflow或可执行任务图。也不只是“更大的上下文窗口”，而是哪些仓库证据、执行日志、失败经验、历史patch应该被保存、压缩或卸载到外部状态中。也不只是API调用，而是通过终端、沙箱、测试框架、静态分析器等工具改变外部世界。

最核心的是

。计划定义操作范围，执行在沙箱或受限环境中发生，验证依赖测试、linter、静态分析和运行日志。像SWE-agent、OpenHands这类系统之所以重要，不只是因为它们会调用工具，而是因为它们把“写代码—运行—失败—修复”组织成了可重复的状态转移过程。

规划、记忆、工具使用和执行反馈共同构成了代码中心Harness架构，支撑Agent长程运行。

多Agent协作时，代码是共享基底

当任务复杂到单个Agent无法完成，多Agent协作就成为一个自然的方向。一个Agent做manager，一个做planner，一个写代码，一个写测试，一个做reviewer。

但多Agent的真正难点不是“多叫几个模型一起讨论”，而是它们如何共享同一个世界状态。

如果多个Agent只靠聊天记录协作，很容易出现状态发散：每个Agent都以为自己理解了当前进展，但它们对代码到底被改成什么样、测试失败在哪里、哪些修改已经生效，可能并没有共同的认知。

代码在这里提供了更稳定的共享基底。仓库、测试、PR、issue、CI log、review comment、执行trace，都可以成为多个Agent共同读写和验证的对象。真正的协作不是“互相说服”，而是围绕共享程序状态不断收敛。

（在多Agent系统中，共享仓库、测试、执行状态和workflow构成协作基底。）

从Claude Code到机器人：代码正在成为Agent的操作系统

Code as Agent Harness最先在coding agent中变得明显，这并不意外。软件世界天然可执行、可测试、可回滚、可记录，因此最适合作为Agent落地的样板间。

但这个趋势并不止于写代码。在GUI/OS Agent中，网页和操作系统正在被转化为可编程环境，DOM tree、accessibility tree、Playwright脚本都让界面操作变成可执行的状态转移。在机器人领域，语言意图需要变成技能库、控制脚本和仿真反馈，抽象目标只有落到可执行代码里，才能被物理约束检查。在科学发现中，假设、实验、模拟、数据分析和实验记录可以被组织成代码流水线，Agent不只是生成想法，而是通过可执行的pipeline推进发现过程。

因此，未来很多Agent不一定都叫coding agent，但它们很可能都会运行在某种code-centric harness之上。

（Code as Agent Harness从代码助手扩展到GUI/OS、机器人、科学发现、个性化系统等场景。）

开放问题：下一代Agent不能只评测最终结果

当Agent变成长期执行系统，评测方式也必须随之改变。过去的benchmark主要看最终结果：答案对不对、测试过没过、任务完成没有。但对于code-harnessed agent，这远远不够。

一个Agent可能最终通过了测试，但过程中做了大量危险修改、污染了共享状态，或者引入了隐藏的regression。另一个Agent可能没有完成任务，但执行轨迹清晰、失败原因明确、状态可恢复。在真实部署场景中，后者未必更差。

论文因此提出了几个开放问题：如何做harness-level evaluation，不仅评估最终输出，也评估计划、工具调用、状态转移和反馈使用；如何处理incomplete feedback，因为测试通过不代表程序真正正确；如何实现regression-free self-evolution，避免harness在自我优化时引入新的失败模式；如何解决多Agent共享状态中的语义冲突；以及如何把human-in-the-loop变成可记录、可追责、可验证的系统状态。

过去，代码是模型的考题。

现在，代码正在成为Agent的操作系统。