斯坦福、Meta、UIUC深度解读Claude Code爆火后Agent Harness底层逻辑
代码在智能体执行系统中作为核心媒介，因其可执行、可检查、有状态的特性，将推理、行动、反馈与验证串联为可控循环，并成为多智能体协作的共享基底，推动智能体从答题者转向长期任务的操作系统。
过去两年，利用大模型编写代码已逐渐成为常态。从简单的代码补全到自动修复GitHub issue，从竞赛级编程到整个仓库规模的软件工程，人们评判一个coding agent优劣的标准一直相当直观：生成的代码是否正确？测试能否顺利通过？
然而，随着Claude Code、Codex这类系统的兴起，问题被推向了更深层次。一个真正强大的编程智能体远不止于“会写代码”。它还必须能够在很长的时间跨度内，阅读仓库、制定计划、修改文件、执行命令、监控错误、修复问题、维护上下文，并在多轮反馈中持续推进任务，直到最终完成。
这套能支撑模型长期稳定运行的执行系统，正是所谓的Agent Harness。当前关于harness的讨论，大多聚焦于模型外围需要装配哪些组件：工具、API、沙箱、记忆、权限边界、验证器、反馈回路。这些讨论回答的是“一个可用的Agent需要哪些系统模块”。
而来自伊利诺伊大学香槟分校（UIUC）、Meta和斯坦福的一份102页综述——《Code as Agent Harness》，则更进一步追问了一个核心问题：当Agent被投入长期任务环境时，那个真正将推理、行动、反馈、验证和协作串联起来的操作对象，究竟是什么？
答案非常明确：代码。
此处所指的代码，并非仅仅是模型最终输出的那一段程序，也不单是Agent框架本身用代码编写那么简单。它涵盖的是Agent在harness中不断生成、运行、修改、保存和共享的一系列“代码化中间产物”：例如Plan.md、测试脚本、shell命令、patch、执行日志、workflow、技能库、仿真器、验证器，甚至共享仓库的状态信息。
传统意义上，代码通常是模型最后交付的成果；但在Agent Harness中，代码会融入整个执行循环，承载起计划、执行、反馈、验证和状态管理的重任，正逐步成为harness组织长期执行过程的核心媒介。
《Code as Agent Harness》这篇综述，正是将代码视为Agent系统中可执行、可检查、有状态的核心媒介，并从接口、机制、多Agent扩展三个层次进行了系统性论述。
为什么Harness需要代码作为核心载体？
一个纯粹的大语言模型，本质上并无状态。它能根据上下文生成下一段文本，但不会主动记忆任务进度，也无法打理外部世界状态的变化。Harness的作用，就是将这个模型接入真实的执行环境。
那么，为什么说代码特别适合充当harness的核心载体呢？因为它具备自然语言所没有的三个关键属性：可执行、可检查、有状态。
可执行，意味着模型的意图可以落地为真实操作。一个计划不再只是“我将修改文件”，而是可以转化为shell命令、patch或者测试脚本。
可检查，意味着执行过程会产生客观的反馈。编译错误、运行时异常、测试结果、日志和trace，都能准确告诉系统当前到底发生了什么，而不是仅仅依靠模型自身的解释。
有状态，意味着任务进度可以持久保存。仓库、文件系统、配置、测试、commit历史、技能库，都能记录Agent已经完成了什么、在哪里失败了、下一步该从何处继续。
因此，这篇综述与一般讲解harness的文章最大的不同，在于它没有简单罗列工具、记忆和沙箱，而是将代码置于核心位置：代码是harness中最稳定、最可操作的状态载体。
代码如何打通Harness的接口？
这篇综述的第一层是Harness Interface，重点阐述代码如何成为模型与外部世界之间的接口。
首先，代码让推理变得可执行。过去模型依赖自然语言的Chain-of-Thought进行推理，但文本推理很难验证。而PoT、PAL等方法，将中间的推理步骤转化为程序，由解释器完成计算；Lean/Coq相关的工作则更进一步，把推理变成机器可检查的证明过程。关键不在于“模型会写程序”，而在于推理本身被外部化为一个可执行的对象。
其次，代码让行动变得可落地。像Claude Code或Codex，它们的行动并非一句“我会修bug”，而是切实去修改文件、运行测试、查看报错、再生成patch。在机器人领域，SayCan、Code as Policies、Voyager等工作展示了另一种形式：语言目标被转换为技能调用、控制脚本或可复用的函数。
第三，代码让环境变得可建模。Agent要长期运行，就必须知晓环境状态。软件仓库、测试结果、执行日志、DOM树、仿真器、数据分析脚本，都可以成为Agent理解世界的结构化表示。SWE-bench、AgentBench等可执行评测环境，也是基于这一逻辑：任务不再是静态问答，而是在可执行环境中完成。
代码融入Harness Interface之后，推理不再是空谈，行动不再是口头承诺，环境也不再只是描述。它们都变成了可以执行、检查和更新的状态。
Harness如何用代码管理状态与反馈？
真实任务很少能一步到位。修复一个bug，可能需要反复定位、修改、测试和回滚；操作一个网页系统，可能需要跨多个页面和工具；做一项科学实验，可能需要提出假设、运行模拟、分析数据，再根据结果调整下一步。
此时，关键不仅在于模型更强，更在于Agent的每一步能否被组织进一个可控的执行循环。
Planning不再只是模型脑中的计划，而是可以变成Plan.md、workflow或可执行的任务图。Memory也不仅是“更大的上下文窗口”，还涉及哪些仓库证据、执行日志、失败经验、历史patch应该被保存、压缩或卸载到外部状态中。Tool use也不只是API调用，而是通过终端、沙箱、测试框架、静态分析器等工具去改变外部世界。
最核心的，仍然是计划-执行-验证循环。计划定义了操作范围，执行在沙箱或受限环境中进行，验证则依赖测试、linter、静态分析和运行日志。像SWE-agent、OpenHands这些系统，之所以重要，不仅仅是因为它们会调用工具，而是因为它们将“写代码—运行—失败—修复”这个循环，组织成了可重复的状态转移过程。
一个成熟的Agent不应惧怕报错。报错、测试失败和执行日志，正是代码harness用来控制Agent行为、使其逐步收敛的“反馈传感器”。
多Agent协作时，代码是共享基底
当任务复杂到单个Agent无法搞定时，多Agent协作便成为自然选择。一个Agent做经理，一个做规划，一个写代码，一个写测试，还有一个做审查。
但多Agent真正的难点，不在于“多叫几个模型来讨论”，而在于它们如何共享同一个世界状态。
如果多个Agent只靠聊天记录协作，很容易出现状态发散：每个Agent都觉得自己理解了当前进展，但对代码到底被改成了什么样、测试失败在哪里、哪些修改已经生效，可能并没有共同的认识。
代码在这里提供了更稳定的共享基底。仓库、测试、PR、issue、CI日志、审查评论、执行trace，都可以成为多个Agent共同读写和验证的对象。真正的协作不是“互相说服”，而是围绕共享的程序状态不断收敛。
多Agent系统的共同语言，不应只是自然语言的对话，而应当是可执行的共享代码状态。
从Claude Code到机器人：代码正在成为Agent操作系统
“Code as Agent Harness”这个概念，最先在coding agent中变得明显，这并不令人意外。软件世界天生就是可执行、可测试、可回滚、可记录的，因此它自然成了Agent落地的最佳样板间。
但这个趋势绝不局限于写代码。在GUI/OS Agent领域，网页和操作系统正在被转化为可编程环境，DOM树、accessibility树、Playwright脚本，都让界面操作变成了可执行的状态转移。在机器人领域，语言意图需要变为技能库、控制脚本和仿真反馈，抽象目标只有落到可执行的代码里，才能被物理约束检查。在科学发现领域，假设、实验、模拟、数据分析和实验记录可以被组织成代码流水线，Agent不只是生成想法，而是通过可执行的pipeline来推进发现过程。
因此，未来很多Agent不一定都叫coding agent，但它们很可能都运行在某种以代码为中心的harness之上。
模型就像大脑，harness像身体和神经系统；而代码，就是那个把大脑、身体、反馈和记忆连接起来的操作系统。
开放问题：下一代Agent不能只评测最终结果
当Agent变成一个长期执行系统，评测方式也必须随之改变。过去的benchmark主要看最终结果：答案对不对、测试过没过、任务完成没有。但对于code-harnessed agent来说，这远远不够。
一个Agent可能最终通过了测试，但过程中做了大量危险修改、污染了共享状态，或者引入了隐藏的regression。另一个Agent可能没有完成任务，但执行轨迹清晰、失败原因明确、状态可以恢复。在真实部署中，后者未必更差。
因此，论文提出了几个开放问题：如何做harness级别的评估，不只关注最终输出，还要评估计划、工具调用、状态转移和反馈使用；如何处理不完整的反馈，因为测试通过不代表程序真的正确；如何实现无回归的自我进化，避免harness在自我优化时引入新的失败模式；如何解决多Agent共享状态中的语义冲突；以及如何将人类参与纳入为一个可记录、可追责、可验证的系统状态。
AI Agent的下一步，不只是让模型更会回答，而是让整个代码化的执行过程变得更可检查、更可恢复、更可治理。
过去，代码是模型的考题。
现在，代码正在成为Agent的操作系统。