Code as Agent Harness：当代码不再是产物，而是Agent的神经系统

论文：Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems
作者：Xuying Ning 等 | UIUC × Meta × Stanford
链接：https://arxiv.org/abs/2605.18747

一、一个被忽视的视角

我们讨论AI Agent时，注意力总是习惯性地投向模型本身——参数规模、推理能力、上下文长度。但这篇论文提出了一个被长期忽视的问题：如果LLM是大脑，那它的"神经系统"是什么？

在过去，这个问题的答案通常是自然语言。模型生成一段文本，然后外部系统去解析这段文本，再决定该调用什么工具、修改什么文件。文本是桥梁，但它有一个根本缺陷—— 不可执行。

想象一个厨师（LLM）在厨房里做菜。传统的做法是让厨师用自然语言描述每一步操作："先切洋葱，再热锅，然后倒油..." 厨房里的助手听完描述后，再去执行。问题是：如果描述含糊了怎么办？如果助手理解错了怎么办？如果某个步骤失败了，厨师能不能立刻知道？

这篇论文的核心主张很简单：让厨师直接写代码。不是写给人看的菜谱，而是写给机器执行的脚本。切洋葱变成一个函数chop(onion)，热锅变成heat(pan, 180)，每一步都可执行、可验证、可回滚。

这就是"Code as Agent Harness"的直觉：

代码不是Agent的产出物，而是Agent的神经系统——连接感知、推理和行动的介质。

二、为什么是代码？三个不可替代的属性

论文给出了一个精练的论证：自然语言有三大盲区，代码恰好补上了。

这三点不是"代码写起来更精确"这种审美判断。它们是 工程约束——当你想让一个系统持续运行数小时、跨越数百个步骤、在失败后自动修复时，自然语言根本撑不住。

论文区分了两个容易混淆的概念：

• System-provided harness：系统预先定义好的工具、API、沙盒、验证器（比如OpenClaw的工具层）
• Agent-initiated code artifacts：Agent在执行过程中自己创建、修改、执行的代码对象（比如临时脚本、回归测试、可复用技能、中间程序状态）

前者是"厨房的基础设施"，后者是"厨师在烹饪过程中随手写下的便签和自创技法"。现有研究大多关注前者，而这篇论文把焦点转向了后者—— Agent自己发起的代码交互。

三、三层架构：代码如何成为Agent的神经系统

论文把"Code as Agent Harness"组织成三个相互连接的层次。这不是为了好看而画的分层图——每一层对应Agent从"单次生成"进化到"持续运行"时必须解决的一类问题。

第一层：Harness Interface（接口层）

这是"代码怎么进入Agent循环"的问题。论文把它拆成三个角色：

1. Code for Reasoning（推理的外骨骼）

Chain-of-Thought的问题不是想法不好，是无法验证。模型说"我计算了平均值"，但你不知道它真的算了吗？算对了吗？

Program-of-Thoughts（PoT）和后续工作（Chain of Code、CodePRM、RLEF等）的核心洞见是：让模型生成可执行的程序，把推理外包给解释器。模型负责提出策略（"用动态规划"），解释器负责执行细节（"数组越界？返回错误，模型再改"）。

更进一步的，像Lean4Agent这样的系统，甚至把 形式化证明 纳入Agent循环——不是"我觉得这个策略对"，而是"证明器确认这个策略在逻辑上无懈可击"。

2. Code for Acting（行动的翻译器）

Agent不能只在脑子里推理，它必须操作世界——点击按钮、移动机械臂、提交GitHub PR。传统的做法是把模型输出映射到预定义的动作空间，但这很僵硬。

论文综述的方向是：让Agent生成程序化的策略。不是"调用工具A"，而是"写一个函数，根据当前DOM状态决定点击哪个元素"。这些策略是可执行的、可检查的、可迭代的。

代表工作包括：Voyager的技能库（Minecraft里Agent写自己的js代码来控制角色）、GUI Agent的程序化界面操作、以及Claude Code和Codex这类系统的代码级行动。

3. Code for Environment Modeling（世界的沙盘）

Agent需要理解它所处的环境。传统做法是让模型直接"读"环境——看截图、读文档。但论文指出了一个更高效的方式：用代码表示环境状态。

代码仓库本身就是结构化的世界表示。执行轨迹（trace）记录了Agent每一步操作后的系统状态。测试用例定义了环境的"物理定律"——如果你改了这行代码，哪些测试会失败？

最妙的是 可验证环境构造（Verifiable Environment Construction）：Agent可以写代码来构造自己的测试环境。比如"我写一个模拟器，验证我的策略在不同参数下是否稳定"。

第二层：Harness Mechanisms（机制层）

接口解决了"怎么连"的问题，机制层解决"怎么持续运行"的问题。长周期任务不是一次生成就能搞定的，Agent需要：

1. 规划（Planning）

把大任务拆成可执行的代码块。论文综述了四种规划范式：

• 线性分解：像写函数一样，把任务拆成顺序执行的子函数
• 结构接地：利用代码的结构（类、模块、依赖图）来组织规划
• 搜索式规划：在代码空间中搜索可能的执行轨迹（类似AlphaGo在棋盘上搜索）
• 编排式规划：用工作流引擎协调多个代码单元的执行顺序

2. 记忆（Memory）

代码天然是记忆的载体：

• 工作记忆：当前正在编辑的文件、打开的变量
• 语义记忆：代码库的架构知识、API文档
• 经验记忆：过去成功的解决方案、失败的尝试
• 长期记忆：可复用的技能库、回归测试集合

论文特别提到一个关键问题：Context Compaction（上下文压缩）。当Agent运行了很久，上下文窗口满了怎么办？答案是：把状态"卸载"到代码结构中——把对话历史变成注释，把中间结果变成变量，把决策过程变成Git提交记录。

3. 工具使用（Tool Use）

工具不是"外部API调用"那么简单。论文区分了四类工具使用：

• 函数式工具：调用预定义的API（像调用库函数）
• 环境交互工具：直接操作外部环境（浏览器、文件系统、数据库）
• 验证驱动工具：用测试、类型检查、静态分析来验证代码
• 工作流编排工具：协调多个工具的执行顺序和依赖关系

4. 控制与优化（Control & Optimization）

这是让Agent可靠的关键。论文提出了"Plan-Execute-Verify"闭环：

• 规划即契约：Agent生成的计划本身就是可验证的承诺
• 沙盒执行：在隔离环境中运行Agent代码，防止破坏生产环境
• 确定性传感器：用测试通过率、编译错误数等客观指标来衡量状态
• Harness级优化：不只是优化模型参数，而是优化整个Agent系统的执行策略

最有趣的是 Evolution Agent（进化Agent） 的概念——一个专门负责改进harness本身的Agent。它观察主Agent的执行轨迹，提出harness改进方案（"加个内存缓存？""换个规划策略？"），然后在沙盒中验证改进是否有效。

第三层：Scaling the Harness（多Agent扩展层）

单个Agent的神经系统已经够复杂了。当多个Agent协作时，问题变成了：它们如何共享同一个"神经系统"？

论文的答案是：代码本身就是共享介质。

想象一个软件开发团队：

• 产品经理写需求文档（自然语言）
• 架构师画设计图（半结构化）
• 程序员写代码（可执行）
• 测试员写测试用例（可验证）

在传统团队里，这些是不同的媒介，需要不断翻译和同步。而在"Code as Agent Harness"的范式下，所有角色都在同一个代码仓库中工作：

• Manager Agent：生成任务分解的代码（工作流定义）
• Coder Agent：实现功能代码
• Reviewer Agent：读取代码，生成审查意见（也是代码注释或测试）
• Tester Agent：运行测试，生成测试报告

它们共享同一个"世界表示"——Git仓库的状态、CI/CD的执行结果、代码覆盖率报告。当一个Agent修改了代码，其他Agent立刻能通过git diff看到变化。

论文还讨论了多Agent协作的拓扑结构：

• 集中式：一个Manager Agent协调多个Worker Agent
• 分布式：Agent之间直接通信，像微服务一样
• 流式：Agent的输出直接作为下一个Agent的输入，形成流水线

以及一个深层问题：Harness-State Convergence（载体状态收敛）。多个Agent同时修改同一个代码库时，怎么保证它们对"当前世界状态"有共同的理解？论文提出这类似于分布式系统中的共识问题——需要版本控制、锁机制、冲突解决策略。

四、从理论到实践：五大应用领域

论文不只是理论框架，还连接到了实际应用：

1. 代码助手（Coding Assistants）

Claude Code、GitHub Copilot Workspace、SWE-agent——这些系统的本质就是把代码作为harness。Agent不只是生成代码片段，而是在一个真实的代码库中执行计划、运行测试、提交PR。

2. GUI/OS自动化

像Computer Use Agent这样的系统，把界面操作视为代码级的程序。不是"点击屏幕坐标(x,y)"，而是"生成一个程序，根据当前DOM状态决定操作序列"。

3. 具身智能

机器人和物理世界Agent用生成的程序作为策略。Voyager在Minecraft中写的js技能库就是一个典型例子——Agent不只记得"怎么挖矿"，它还保存了一个可执行的mine.js脚本。

4. 科学发现

Agent用代码构造假设检验管道：生成模拟代码、运行实验、分析数据、根据结果调整假设。整个科学方法变成了可执行的程序。

5. 个性化与推荐

Agent为用户生成个性化的代码工件——自定义脚本、配置文件、自动化工作流。这些代码既是解决方案，也是持久化的用户偏好表示。

五、开放挑战：未来七道难题

论文在最后提出了七个尚未解决的核心挑战。这些不是"锦上添花"的问题，而是决定这个范式能否从实验室走向生产的关键：

1. Harness-Level Evaluation（超越最终成功率的评估）

现在的Agent评估主要看"最后做对了没有"。但真正的工程问题是：它花了多少步？中间犯了什么错误？能不能在失败后自动恢复？需要设计新的评估指标，衡量Agent的"健壮性"而不仅仅是"正确性"。

2. Semantic Verification Beyond Executable Feedback（超越可执行反馈的语义验证）

代码能运行不代表代码是对的。一个测试通过的函数可能在语义上完全偏离了用户需求。怎么验证"这个实现真的满足了用户的意图"？

3. Self-Evolving Harnesses without Regression（无回归的自进化载体）

如果Agent可以修改自己的harness（Evolution Agent），怎么保证改进不会破坏已有功能？这类似于软件工程中的回归测试问题，但发生在运行时。

4. Transactional Shared Program State（事务化的共享程序状态）

多Agent协作时，对共享代码库的修改应该是原子的、可回滚的。论文提出这需要一个"事务语义"——Agent的每一步操作要么全部生效，要么全部回滚。

5. Human-in-the-Loop Safety（人在回路中的安全与问责）

当Agent拥有执行代码的能力时，安全不再是"不让Agent做坏事"，而是"怎么让人类始终能理解和干预Agent的决策"。

6. Multimodal Code-Harness Systems（多模态代码载体系统）

代码不只是文本——它可以是视觉程序（如节点图）、触觉反馈、语音命令的编码。怎么把这些非文本模态纳入"Code as Harness"的框架？

7. Toward a Science of Harness Engineering（走向载体工程的科学）

最后，论文呼吁建立一个系统性的"Harness Engineering"学科——不只是拼拼凑凑工具，而是像软件工程、系统架构一样，有一套设计原则、评估方法、最佳实践。

六、写在最后

这篇论文最打动我的，不是它的技术深度（毕竟是一篇survey），而是它的视角转换。

过去几年，我们习惯了把代码看作LLM的"输出目标"——就像画家画出画作。但这篇论文提醒我们：代码可以是画布本身。Agent在画布上作画，同时也在观察画布的状态、修改画布的结构、让画布上的元素相互作用。

Claude Code之所以好用，不是因为它生成的代码更漂亮，而是因为它把整个开发环境变成了Agent的神经系统。代码仓库是记忆，终端是行动接口，测试是验证传感器，LSP是环境模型。

这背后有一个更深层的变化：AI正在从"生成内容"走向"操作系统化"。不是给你一段文字让你去读，而是给你一个可执行的环境让你去用。

参考论文：

Ning, X., Tieu, K., Fu, D., et al. (2026). Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems. arXiv:2605.18747. University of Illinois Urbana-Champaign, Meta, Stanford University.

#AI #AgentHarness #LLM #代码生成 #智能体 #论文解读 #ClaudeCode #多Agent系统 #UIUC #Meta #Stanford