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

两年转瞬即逝，大模型编写代码早已不再新奇。从代码自动补全到 GitHub issue 修复，从竞赛编程到仓库级软件工程，大家普遍采用一个直观标准来评估 coding agent：代码能否正确无误？测试能否顺利通过？

然而，你是否曾深思这样一个问题？随着 Claude Code、Codex 等系统的涌现，事情正被推向更深层次的维度。真正强大的 coding agent，绝不仅仅是“会写代码”。它还需要能够在长时间窗口内阅读仓库、制定计划、修改文件、执行命令、分析报错、修复失败、维护上下文，并在多轮反馈中持续推进任务。

这套让模型长期稳定“运转”的执行系统，被称为 Agent Harness。以往关于 harness 的讨论，更多聚焦于模型外围应包裹什么：工具、API、沙箱、记忆、权限边界、验证器、反馈循环。它们回答的是“一个可用 Agent 需要哪些系统组件”。

但这份来自伊利诺伊大学香槟分校（UIUC）、Meta 和斯坦福的 102 页综述，标题即为《Code as Agent Harness》，它追问了一个更本质的问题：当 Agent 被置于长期任务环境时，真正将推理、行动、反馈、验证与协作串联起来的操作对象是什么？

答案是：代码。

• 论文标题：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 Harness 语境下，代码会进入整个执行循环，承载计划、执行、反馈、验证和状态管理，它正成为组织长期执行过程的核心媒介。

简而言之，这篇综述将代码视为 Agent 系统中可执行、可检查、有状态的媒介，并从接口、机制、多 Agent 扩展三个层次展开了深入探讨。

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

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

你可能会问，为什么偏偏是代码？答案在于，代码具备自然语言不具备的三大硬属性：可执行、可检查、有状态。

可执行，意味着模型的意图可以转化为真实操作。一个计划不再只是“我将修改文件”，而是可以具体化为 shell command、patch 或测试脚本。可检查，意味着执行过程会产生客观反馈。编译错误、运行时错误、测试结果、日志和 trace，都能向系统传达当前正在发生什么，而不是单纯依赖模型自身的解释。有状态，意味着任务进度可以被持久保存。仓库、文件系统、配置、测试、commit history、skill library 都能记录 Agent 已经做了什么、在哪里失败、下一步该从哪里继续。

因此，这篇 survey 与一般 harness 综述的最大区别，不是又罗列一遍工具、记忆和沙箱，而是把代码置于中心位置：代码，是 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 等可执行评测环境也正是基于这一点——任务不再是静态问答，而是在可执行环境中完成的。

代码进入 Harness Interface 后，推理不再只是文本，行动不再只是承诺，环境也不再只是描述。它们全都变成了可以执行、检查和更新的状态。

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

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

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

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

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

一个成熟的 Agent，不应畏惧报错。报错、测试失败和执行日志，正是代码 harness 控制 Agent 行为、让它逐步收敛的反馈传感器。

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

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

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

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

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

多 Agent 系统的共同语言，不应只是自然语言对话，而应该是可执行的共享代码状态。

从 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 之上。

模型像大脑，harness 像身体和神经系统；而代码，就是那个把大脑、身体、反馈和记忆连接起来的操作系统。

Open Problems：下一代 Agent 不能只评测最终结果

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

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

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

AI Agent 的下一步，不只是让模型更会回答，而是让整个代码化执行过程更可检查、更可恢复、更可治理。

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

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Claude Code爆火背后的Agent Harness底层逻辑：UIUC Meta斯坦福深度解读要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题