这是什么：arXiv 2605.18747《Code as Agent Harness: Toward Executable, Verifiable, and Stateful Agent Systems》的中文导读。原文 102 页、约 3.7 万词正文（不含参考文献），采用 CC BY 4.0 许可。 这不是什么：不是全文逐句翻译。本文按原文 19 个小节逐节梳理，不跳过任何一节；其中摘要、核心定义、开放问题清单为完整翻译，其余为结构化提炼。 原文：https://arxiv.org/abs/2605.18747 ｜ 引用请引原文。

摘要（完整翻译）

近年的大语言模型在理解与生成代码上已展现出很强的能力，从竞赛编程一直到仓库级的软件工程。而在正在成型的智能体系统中，代码不再只是一个待产出的目标产物，它越来越多地成为智能体进行推理、行动、环境建模与基于执行的验证的运行底座。

作者用 agent harness（智能体承载层） 这个视角来概括这一转变，并提出 code as agent harness：一个把代码视为智能体基础设施根基的统一观点。围绕这一视角，全文分三层展开：

1. Harness Interface（承载层接口）——代码如何把智能体连接到推理、行动与环境建模；
2. Harness Mechanisms（承载层机制）——支撑长程执行的规划、记忆与工具使用，以及让承载层可靠、可自适应的反馈驱动控制与优化；
3. Scaling the Harness（承载层的扩展）——从单智能体走向多智能体，共享的代码产物如何支撑协作、评审与验证。

三层之上，作者汇总了代表性方法与实际应用，覆盖编程助手、GUI/OS 自动化、具身智能体、科学发现、个性化与推荐、DevOps 与企业工作流。最后提出承载层工程的开放问题：超越”任务最终成功率”的评估、反馈不完整时的验证、无回归的承载层改进、多智能体间的一致共享状态、安全攸关动作的人类监督、以及向多模态环境的扩展。

三个必须先分清的概念

原文最重要的概念工作，是把长时运行智能体系统拆成三个耦合但不同的东西。这个区分是全篇的地基：

第三类是本文的重点。例子包括：回归测试、临时工具、DSL 程序、可执行的策略、脚本化的工作流。它们通过执行反馈帮助智能体推理、行动、验证进度、存储状态、并与其他智能体协调。

agent harness 的定义（完整翻译）：包裹在 LLM 外面的那一层软件——工具、API、沙箱、记忆、校验器、权限边界、执行循环与反馈通道——它把一个无状态的模型变成一个能够长时间执行任务的、可用的智能体。

在这个视角下，自主性的瓶颈不只是基座模型的推理能力，还有那个把模型输出连接到长程动作与持久状态的系统的可靠性。

§1 导论

代码在智能体系统中的角色正在扩张——从”被生成的产物”变成”智能体借以推理、行动、并对环境建模的介质”。原文举了三条已经在发生的线索：

• 程序辅助推理：把中间计算外化成可执行代码，让解释器、符号求解器、执行轨迹或过程奖励来检查与修正推理；
• 机器人与具身智能体：把生成的程序当作可执行策略，去与物理或仿真世界交互；
• 软件工程与交互式环境：把代码库、执行轨迹、测试、运行时反馈当作环境状态与动力学的结构化表示，智能体在其中规划、行动、修正。

合起来看，代码是一种可执行、可检查、有状态的介质——智能体通过它推理、行动、观察反馈、验证进度。这就是 code as agent harness。

全文的三层组织方式，遵循的是”代码如何进入智能体回路”的顺序：先作为接口进入（推理、行动、环境表示），再支撑起机制（规划、记忆、工具使用、执行与修复），最后成为多智能体在代码库、测试、轨迹、工作流、执行状态上协调的共享产物。

§2 承载层接口：面向推理、行动与环境建模的代码

这一层研究代码如何构成模型与任务环境之间的基本接口。代码在这里是把模型输出转换成可执行、可检查结构的介质。

原文在本节开头设了一个 scope boundary（范围边界），明确本综述讨论的是代码作为运行介质，而非代码生成本身的模型能力。

§2.1 面向推理的代码

程序把中间计算外化出来，从而让解释器、符号求解器、执行轨迹或过程奖励能够检查并改进推理过程。核心价值在于：推理一旦写成代码，就从”不可验证的自然语言”变成”可执行、可复核的对象”。

§2.2 面向行动的代码

生成的程序直接充当策略（policies）、工具调用、行为树（behavior trees）或可复用技能，服务于具身、GUI 与软件环境。这里的转变是：动作不再是一次性的 API 调用，而是可编程、可复用、可组合的代码单元。

§2.3 面向环境建模的代码

程序状态、代码库、执行轨迹、模拟器与测试，共同构成对环境状态、动力学与反馈信号的表示。智能体不是在”描述”环境，而是在一个可执行的环境表示里操作。

本层的结论：代码是智能体让推理可执行、动作可编程、环境状态可检查的方式。

§3 承载层机制：规划、记忆、工具使用、控制与优化

这是全篇的系统核心层——让被代码承载的智能体在”单次生成”之外依然可靠。

一旦代码进入智能体回路，软件生成就不再只是”从 prompt 产出正确程序”的问题，而变成三者之间的交互：

• 模型提供判断：拆解目标、选择动作、解读反馈、决定何时修正；
• 可变状态记录仓库证据、工作上下文、执行轨迹、校验结果、记忆与对任务的中间信念；
• 承载层基础设施暴露工具与执行底座、持久化并压缩状态、用策略与权限层级约束动作、路由反馈、并验证每一次状态转移是否可接受。

作者强调的判断：承载层机制不是可插拔的附加模块，而是一组协同的控制面，把模型决策转化为在可执行环境中有边界、可观察、可修正的变更。

这里还有一个层次递进：基础形态是智能体调用已有的可执行接口；进一步，智能体可以动态撰写任务专属的可执行接口。后者让执行环境能围绕当前任务重塑，因而更具适应性——但也带来新的风险面。

§3.1 规划：作为承载层控制

真实软件工程任务几乎不存在”自然语言意图 → 正确实现”的一步映射。规划在这里不是 LLM 的内部推理能力，而是一种承载层控制：它决定智能体如何把意图外化为可执行步骤、如何调度与代码产物和工具的交互、以及如何随时间调节推理—执行—修正的轨迹。

有效的承载层必须组织长程问题求解：追求哪些中间目标、以什么顺序执行、检查或修改哪些产物、以及当执行反馈暴露出错误、缺失依赖或违反约束时如何修正轨迹。

在仓库级编辑、Web 交互、竞赛编程、硬件设计中，这一需求最为突出——动作空间大、反馈稀疏、子问题深度互相依赖。核心矛盾：目标任务的复杂度 vs. 无约束智能体执行的有限可靠性。 没有显式规划作为控制，智能体容易过早锁定脆弱的解法路径。

方法谱系涵盖：任务分解、结构化落地（structural grounding）、轨迹搜索、工作流编排。

§3.2 记忆与上下文工程

真实软件任务本质上是长程且状态密集的。与单轮补全不同，实际编码要跨多轮维持一串互相依赖的步骤：需求理解 → 代码定位 → 证据检索 → 多文件编辑 → 测试执行 → 缺陷修复 → 回归验证。

由此产生根本张力：模型有限的上下文窗口 vs. 任务持续膨胀的中间状态。

作者给出的关键定性：从承载层视角看，记忆不是”更大的上下文窗口”，也不是”一个向量数据库”，而是一个状态管理层——它决定哪些信息应留在活跃上下文、哪些应压缩成摘要、哪些应卸载到持久外部存储。

缺乏有效记忆与上下文管理的后果很具体：长程推理中丢失关键线索、重复已完成的搜索与分析、后续修改破坏早前建立的局部一致性。

早期系统主要靠 prompt 保存历史，把记忆当作对话历史；本节梳理了从这一起点向结构化状态管理的演进。

§3.3 工具使用：受治理的接口

工具是代码智能体承载层的动作与观察层。代码进入回路后，模型不仅要生成文本，还要搜索仓库、编辑代码、执行测试、调用 API、查询文档、验证中间结果。工具因此既扩展了动作空间，也暴露出让承载层可执行、可检查的外部反馈信号。

作者的核心论点：工具使用不是代码生成的辅助能力，而是模型意图与外部系统之间一个”受治理的接口”（a governed interface）。 一个可靠的承载层必须决定：

• 哪些工具可用；
• schema 如何暴露；
• 每个工具获得什么权限；
• 执行发生在哪里；
• 结果如何被净化或压缩；
• 什么时候高风险动作需要人类批准。

近期的 agent SDK 与软件智能体平台正把这一转变显式化——将工具、会话、护栏（guardrails）、交接（handoffs）、工作区与执行环境打包成可复用的承载层组件。沙箱是并行的一条线。

§3.4 承载层控制：Plan–Execute–Verify 回路

代码即承载层的系统需要一个控制回路，把模型意图转化为有边界、可观察、可修正的状态转移。作者把它构造为 PEV（Plan–Execute–Verify）：

1. Plan——承载层先把”打算做的变更”及其验证标准外化出来；
2. Execute——在沙箱化、带权限的环境中执行该变更；
3. Verify——通过确定性传感器（deterministic sensors）与人类评审关卡（human-review gates）验证结果状态。

这个框架把规划、执行、调试、验证与升级（escalation）统一成同一个承载层级别的控制过程。

前三小节的关系在此闭合：规划是轨迹控制，记忆是状态管理，工具使用是受治理的动作接口；反馈引导的调试把它们连成闭环——计划指定意图变更，记忆保存相关证据，工具执行并检查动作，校验信号决定智能体应当继续、修正、还是停止。

§3.5 Agentic Harness Engineering（AHE）：自适应的承载层优化

AHE 命名了一个承载层级别的设计问题：如何度量并修改那个”把语言模型变成编码智能体”的软件基底。

三者的分工很清楚：

AHE 的分析对象包括：工具 schema、规划产物、记忆策略、检索策略、沙箱配置、验证传感器、权限层级、路由规则、多智能体工作流、人类评审关卡。

为什么这个视角有用（这是全文最实用的一句判断）：代码智能体的许多失败，源头是缺失的仓库上下文、脆弱的工具接口、薄弱的校验器、过高的 token 成本、糟糕的重试策略、错配的权限边界——而不是模型生成本身。

现有工作可读成三股互补的线：AutoHarness 研究代码承载层的自动合成；Meta-Harness 把承载层设计表述为一个针对”面向模型的基础设施”的优化问题；可观测性方向则关注度量。

§4 承载层的扩展：基于代码的多智能体编排

当任务从函数级代码合成走向仓库级系统工程，单智能体的三个根本局限开始显现：

1. 上下文窗口限制——单个智能体无法把整个代码库、长交互历史与执行轨迹同时放进工作记忆；
2. 专业化需求——用一个通才智能体同时做规划、合成、测试、评审、调试，效率低下；
3. 缺少独立的协调与验证通道——智能体无法在长程执行中可靠地发现并纠正自己的错误。

多智能体系统引入的原则很有力：一旦这些职责被分配到专门化角色上，承载层本身就变得更模块化、更可检查、更可适应。 早期系统（ChatDev、MetaGPT、AgentCoder）已经展示了这一转变：把软件开发职责拆给架构师、程序员、测试员、评审者、执行者等不同智能体。

§4.1 通过多智能体协作改进编码支持

最直接的贡献是：把承载层分解成专门化但互相协调的组件。规划、合成、执行、验证不再挤在同一个智能体回路里，而是分布到多个通过共享代码产物与反馈信号交互的角色上。这让整体承载层更能处理复杂软件任务，同时让内部工作流更可检查、更可控。

具体通过三个设计维度实现：

• 角色如何专业化——多数 MAS 自然地镜像人类软件开发的分工；
• 智能体如何在共享程序产物上交互；
• 工作流拓扑如何组织协作。

§4.2 执行反馈与共享承载层的同步

这是代码中心 MAS 的决定性维度：共享承载层是独一无二地”可执行”的，能产出客观的 oracle 信号。 本节回答两个子问题：用哪些类型的执行反馈；如何在智能体之间同步共享状态。

执行反馈的类型谱系：

• 编译器与语法反馈——在运行前捕获结构性错误。不同系统的处理强度差别很大：有的只在单个阶段内做一次性纠正，有的在每次文件写入后运行语法检查，并把它当作阻塞条件，不通过就不许流水线前进。
• 测试通过/失败信号——最常用的一类。有的系统把整个回路都建立在”独立生成的测试用例是否通过”之上，并设置迭代预算上限（例如 5 次）作为终止条件。

§4.3 立场：共享的、以代码为中心的承载层基底

这是作者明确提出的 position（立场性主张），不是文献综述。

动机来自文献中的核心空白：缺少对共享代码状态的形式化、持久化表示，使得智能体无法跨迭代地查询与更新它。 作者主张，构建这样一个承载层基底既可行也必要。

任何 MAS 的根本问题是：这些智能体栖居在什么基底之上？在 code as agent harness 的框架里，自然的答案是共享程序环境——智能体共同作用其上、并随其产出/修订/评估代码而演化的那一整套产物、执行上下文与质量信号。作者称之为 shared harness substrate，并区分了现有系统表示它的四个形式化层级。

其中最常见、也最不形式化的一类，是把共享承载层完全隐式处理。

§4.4 模式与趋势

关键洞察：角色专业化、共享状态表示、执行落地、工作流拓扑这四者的差异，不是彼此独立的工程选择——它们相互作用，共同决定一群智能体能在多长的任务跨度上保持一致性。

现状诊断很直接：被调研的大多数系统（ChatDev、MetaGPT、FlowGen、CodePori、SEW、MapCoder、CodeCoR 等）都没有对共享代码承载层的显式表示。 它们依赖智能体在每次调用时从对话历史里隐式重建状态。

这一设计在函数级任务上可行——程序状态简单，不会在智能体之间碎片化。但在更大的任务上就会失效。

§5 新兴领域与开放问题

在用接口、机制、编排模式刻画了”代码作为承载层”之后，本节考察这一范式在具体应用领域中如何落地，以及它暴露出哪些开放问题。

跨越编程助手、GUI/OS 智能体、科学发现、个性化、具身智能体这些领域，代码不只是模型输出，更是状态表示、动作执行、记忆、反馈与治理的运行基底。这些领域让代码中心智能体系统的前景变得具体，同时也暴露出一组共同的未解难题：评估、验证、安全、协调、多模态落地、承载层演进。

术语对照表（EN → ZH）

为什么这篇值得存进 aiOS

这篇综述描述的东西，就是我们已经在跑的系统——但它给了一套词汇和诊断框架：

1. 三元区分说明了一件事：我们花在基座模型选型上的注意力，可能远超它对可靠性的实际贡献。作者的判断很直接——多数失败来自缺失的仓库上下文、脆弱的工具接口、薄弱的校验器、糟糕的重试策略、错配的权限边界，而不是模型生成。
2. AHE 把”运行环境本身”变成可优化对象。skills/、CLAUDE.md、权限规则、AgentDeck、记忆文件——这些不是配置，它们就是 harness，应当被当作工程对象来度量和修订。
3. §4.3 的立场直接命中我们的痛点：多智能体缺少”形式化、持久化、可跨迭代查询与更新的共享状态表示”。Dao / Big / Cody / MA 之间靠的正是隐式重建——作者说这在小任务上可行，在大任务上会碎片化。
4. §5.2 的评估问题值得直接借用：不要只看”任务做没做成”，要看轨迹效率、验证强度、恢复能力。

本文为 arXiv 2605.18747（CC BY 4.0）的中文导读，由 Dao 编写于 2026-09-06。原文 102 页，引用与学术使用请以原文为准：https://arxiv.org/abs/2605.18747