Code as Agent Harness：迈向可执行、可验证、有状态的智能体系统（完整翻译）

作者

Xuying Ning¹†, Katherine Tieu¹†, Dongqi Fu²†, Tianxin Wei¹†, Zihao Li¹†, Yuanchen Bei¹†, Jiaru Zou³, Mengting Ai¹, Zhining Liu¹, Ting-Wei Li¹, Lingjie Chen¹, Yanjun Zhao¹, Ke Yang¹, Bingxuan Li¹, Cheng Qian¹, Gaotang Li¹, Xiao Lin¹, Zhichen Zeng¹, Ruizhong Qiu¹, Sirui Chen¹, Yifan Sun¹, Xiyuan Yang¹, Ruida Wang¹, Rui Pan¹, Chenyuan Yang¹, Dylan Zhang¹, Liri Fang¹, Zikun Cui², Yang Cao², Pan Chen², Dorothy Sun², Ren Chen², Mahesh Srinivasan², Nipun Mathur², Yinglong Xia², Hong Li², Hong Yan², Pan Lu³, Lingming Zhang¹, Tong Zhang¹, Hanghang Tong¹, Jingrui He¹

¹伊利诺伊大学香槟分校 ²Meta ³斯坦福大学†核心贡献者

摘要

近年来，大型语言模型（LLMs）在理解和生成代码方面展现出强大的能力，从竞赛编程到代码库级别的软件工程均有出色表现。在新兴的智能体系统中，代码不再仅仅是目标输出。它越来越多地作为智能体推理、行动、环境建模和基于执行的验证的操作基底。我们通过智能体框架（agent harnesses）的视角来框定这一转变，并引入代码作为智能体框架（code as agent harness）的概念：一种将代码作为智能体基础设施核心的统一视角。

为了系统性地研究这一视角，我们围绕三个相互关联的层次组织本综述：

第一层，我们研究框架接口，代码在此将智能体连接到推理、行动和环境建模。

第二层，我们考察框架机制：规划、内存和工具使用用于长期执行，以及反馈驱动的控制和优化使框架可靠且自适应。

第三层，我们讨论框架的扩展，从单智能体系统到多智能体设置，其中共享的代码工件支持多智能体协调、审查和验证。

在这些层次中，我们总结了代码作为智能体框架的代表性方法和实际应用，涵盖编码助手、GUI/OS 自动化、具身智能体、科学发现、个性化与推荐、DevOps 和企业工作流。我们进一步概述了框架工程面临的开放挑战，包括超越最终任务成功的评估、不完整反馈下的验证、无回归的框架改进、多智能体间的一致共享状态、安全关键行动的人类监督，以及向多模态环境的扩展。

通过将代码作为智能体 AI 的框架中心，本综述为构建可执行、可验证、有状态的 AI 智能体系统提供了统一的路线图。

关键词：智能体框架、编码智能体、框架工程、智能体 AIGitHub：https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers

1. 引言

近年来，大型语言模型（LLMs）在理解和生成代码方面展现出强大的能力，在从竞赛编程到代码库级别的软件工程等任务中取得了优异表现。基于这些能力，代码在智能体系统中的角色正在从待生成的目标工件扩展开来。程序越来越多地被用作 LLM 智能体推理、行动和建模环境的媒介。

程序辅助推理方法将中间计算外化为可执行代码；机器人和具身智能体使用生成的程序作为与物理或模拟世界交互的可执行策略；软件工程或交互式环境使用代码库、执行轨迹、测试和运行时反馈作为环境状态和动态的结构化表示，智能体在其中规划、行动并修正其行为。综合来看，这些发展表明了一个更广阔的视角：代码不仅是 LLMs 生成的工件，也是智能体推理、行动、观察反馈和验证进度的可执行、可检查和有状态的媒介。我们将这一视角称为代码作为智能体框架。

1.1 什么是智能体框架？

近期关于智能体框架的讨论提供了一个有用的系统级视角来理解这一转变。智能体框架是指围绕 LLM 的软件层，配备工具、API、沙箱、内存、验证器、权限边界、执行循环和反馈通道，从而将无状态模型转变为能够执行长期任务的功能性智能体。在这一视角下，自主性的瓶颈不仅在于基础模型的推理能力，还在于将模型输出连接到长期行动和持久状态的系统可靠性。

为了阐明代码在这一更广泛的框架视角中的角色，我们区分了长期运行智能体系统的三个耦合要素：

  1. 模型内部能力：模型的推理、感知、规划、模拟和评估能力

  2. 系统提供的框架基础设施：预定义的工具、API、沙箱、内存系统、验证器、权限边界、遥测和工作流，将模型输出连接到外部行动和反馈

  3. 智能体发起的代码工件：智能体在任务执行循环中创建、执行、观察、修订、持久化和共享的交互式代码对象

相对而言，智能体发起的代码工件仍然相对未被充分探索。这些工件通过执行反馈帮助智能体推理、行动、验证进度、存储状态并与其他智能体协调。示例包括回归测试、临时工具、DSL 程序、可执行工作流、可重用技能和中间程序状态。

1.2 代码作为智能体框架的核心视角

有了这一区分，我们重新审视代码在智能体系统中的角色。现有综述通常将代码视为 LLMs 的最终产品。相比之下，我们专注于智能体发起的代码工件，以及模型能力如何通过与框架基础设施的交互来构建和演化它们，代码作为接口、智能体能力和多智能体协调的组织中心。

在各种智能体系统中，代码不仅用于产生解决方案，还用于执行推理、基础行动、维护状态和暴露反馈。我们将这一视角称为代码作为智能体框架：代码作为智能体推理、行动和适应的可执行和可检查媒介。这将范围从生成正确程序转移到理解代码如何支持可靠的闭环智能体行为。

1.3 三层组织架构

为了系统性地描述代码作为智能体框架，我们将综述组织为三个相互关联的层次（如图1所示）。这一组织遵循代码如何成为智能体循环内的操作媒介：它首先作为推理、行动和环境表示的框架接口进入；然后支持随时间管理规划、内存、工具使用、执行和修复的框架机制；最后成为多个智能体通过代码库、测试、轨迹、工作流和执行状态进行协调的共享工件。

第一层：框架接口

框架接口：代码用于推理、行动和环境建模（第2节）研究代码如何形成模型与其任务环境之间的基本接口。在这一层，代码是将模型输出转换为可执行和可检查结构的媒介。我们回顾：

  • 代码用于推理：程序外化中间计算，允许解释器、符号求解器、执行轨迹或过程奖励来检查和改进推理

  • 代码用于行动：生成的程序作为策略、工具调用、行为树或可重用技能，用于具身、GUI 和软件环境

  • 代码用于环境建模：程序状态、代码库、轨迹、模拟器和测试表示状态、动态和反馈信号，供智能体交互

这一层建立了核心框架接口：代码是智能体使推理可执行、行动可编程、环境状态可检查的方式。

第二层：框架机制

框架机制：规划、内存、工具使用、控制和优化（第3节）研究代码框架化的智能体如何在单次生成步骤之外保持可靠。一旦代码被放置在智能体循环中，框架必须决定接下来执行什么、保留有用的状态、暴露正确的工具，并将失败转化为纠正行动。因此我们回顾：

  • 规划方法：通过分解、结构化基础、轨迹搜索或工作流编排来组织长期软件任务

  • 内存方法：维护工作状态、检索代码库证据、存储可重用经验并支持共享交互历史

  • 工具使用方法：将智能体连接到 API、代码库、执行环境和验证工具

  • 反馈驱动控制和框架优化方法：使用静态分析、运行时错误、测试和人类反馈通过重复执行来修订代码

这一层将第2节中的接口转变为操作框架：规划控制执行轨迹，内存保留状态，工具扩展行动空间，反馈驱动的适应关闭失败与修订之间的循环。

第三层：多智能体扩展

扩展框架：基于代码的多智能体编排（第4节）将框架从单个智能体扩展到协作生态系统。当多个智能体在代码上操作时，框架不仅必须支持个体推理和执行，还必须协调角色、共享中间工件、维护共同状态并验证集体进度。我们通过以下方式回顾多智能体代码中心系统：

  • 智能体角色：管理者、规划者、编码者、审查者、测试者

  • 协作模式：编程、修复、辩论、红队对抗、对抗性交互

  • 工作流拓扑：从集中式协调到分布式或流式协作

这一层展示了代码如何成为编排自主性的共享框架：代码库、测试、轨迹和结构化工件提供了智能体协调、检查和改进彼此行为的共同工作空间。

1.4 应用领域与开放挑战

除了分类法之外，我们还考察了智能体发起的代码交互如何出现在五个应用领域中：

  • 编码辅助：智能体在活跃代码库上编写补丁、测试和问题解决工作流

  • GUI 和 OS 自动化：智能体合成并执行基于 DOM 树、可访问性 API 和可执行评估器的界面命令

  • 科学发现：智能体动态组合和执行假设测试流水线，涵盖模拟、实验室协议和数据分析

  • 个性化和具身控制：智能体根据环境反馈编写和修订可执行策略、模拟器和技能库

我们进一步概述了框架工程面临的开放挑战，包括超越最终任务成功的评估、不完整反馈下的验证、无回归的框架改进、多智能体间的一致共享状态、人类监督以及向多模态环境的扩展。

本综述为研究代码提供了路线图，不仅将其作为智能体生成的东西，而且作为它们执行、适应和协调可靠行为的运行时媒介。

2. 框架接口：代码用于推理、行动和环境建模

框架通过将模型输出基础于外部执行、持久状态和可验证反馈，将无状态语言模型转变为功能性智能体。因此，任何框架最基本的设计问题是：什么媒介将模型连接到其任务环境？

我们认为答案是代码。与自然语言不同，代码具有以下特性：

  • 可执行性：模型输出成为具有形式化可验证结果的操作

  • 可检查性：中间计算作为结构化轨迹暴露，框架可以读取、存储并采取行动

  • 有状态性：演化的程序以持久、可修改的形式表示跨步骤的任务进度

关键的是，这些不仅仅是代码作为符号的属性；它们是使代码作为框架接口发挥作用的属性。可执行性意味着框架可以验证模型的意图。可检查性意味着失败可以被诊断并反馈。有状态性意味着智能体的交互历史不会在步骤之间丢失。

2.1 代码用于推理

智能体框架的一个核心角色是将模型推理从瞬时文本生成转变为可执行和可验证的计算。早期的提示技术如纯思维链（CoT）完全在自然语言中执行推理和计算，迫使模型在单个潜在文本过程中同时分解问题和执行中间操作。虽然语言模型通常在提出推理步骤方面有效，但在忠实执行符号、逻辑或算术计算方面仍然不可靠。更重要的是，纯文本推理为智能体框架提供了很少的能力来验证中间状态、检查执行行为或在步骤之间持久化计算进度。

代码用于推理因此引入代码作为模型和框架之间的执行接口，超越了纯基于文本的推理。模型生成可执行程序，外部运行时、解释器、符号求解器或验证模块可以执行和评估。这将高级推理与低级计算分离：模型提出过程，而框架执行它们、观察运行时行为、存储中间状态，并将执行结果反馈到未来的推理中。

现有工作可以组织为三种范式：

2.1.1 程序委托推理

程序委托推理使用可执行程序作为问题分解和计算之间的主要接口。模型生成代码，外部解释器执行以产生形式化基础的输出。早期工作表明，将计算委托给程序通过将中间推理移入结构化、可验证的执行轨迹来大幅提高可靠性。

代表性工作：

  • Program-of-Thoughts (PoT)：系统化地将推理分解为可执行程序

  • PAL（Program-Aided Language）：将逻辑与计算解耦

  • Chain of Code (CoC)：分析可执行推理如何改变相对于纯语言推理的失败模式

  • CodeAdapt：紧密耦合语言模型与可执行推理接口，可以超越专门的推理导向模型

  • CodeI/O：将上下文基础的程序转换为代码输入-输出预测任务，暴露逻辑流规划、状态空间搜索、决策树遍历和模块化分解等推理原语

2.1.2 形式化验证和符号推理接口

混合神经-符号方法结合灵活的基于语言的推理与结构化符号计算，使用代码和符号工件作为持久的中间表示。

代表性工作：

  • Graph-of-Thoughts：将思维链推理泛化为图结构轨迹

  • CodeSteer 和 Code-as-Symbolic-Planner：明确协调自由形式语言推理与可执行符号操作

  • VisualCoder：通过控制流表示使程序行为可视化

形式化证明系统：

  • Lean、Isabelle、Coq：提供基于严格逻辑基础的形式化证明语言

  • ReProver、DeepSeek-Prover、TheoremLlama：建立将语言模型与证明助手反馈结合的实用方法

  • DeepSeek-Prover-V2、Kimina-Prover、Goedel-Prover-V2：通过深思熟虑的证明搜索、自我纠正和重复证明生成改进过程

  • Lean4Agent：使用 Lean4 建模和验证智能体工作流和轨迹

2.1.3 迭代代码基础推理

迭代代码基础推理专注于生成、执行和反馈之间的闭环交互。在这些系统中，推理不是单次过程，而是基于可执行状态转换的迭代计算轨迹。

代表性工作：

  • NExT：通过程序轨迹推理来训练模型预测执行行为

  • CodePRM 和 ORPS：使用执行结果评估和改进中间推理轨迹

  • CYCLE 和 Self-Edit：使用执行感知的纠正信号迭代修订生成的解决方案

  • CodeRL、CodeRL+、RLTF：通过基于单元测试的奖励优化功能正确性

  • RLEF：将交互形式化为基于多步执行反馈的策略优化

  • R1-Code-Interpreter：在持久交互会话中交错推理和多轮代码执行

2.2 代码用于行动

除了推理之外，智能体还必须将模型连接到外部环境，在那里决策产生真实的可执行效果。在这个阶段，代码不再主要作为计算媒介，而是作为行动接口，将模型输出转换为基础操作，如工具调用、机器人控制策略、GUI 行动或软件命令。

通过这个接口，框架将高级意图转化为可执行行为，可以与具身、数字和交互式环境交互。中心挑战是基础化：框架必须将抽象语言输出映射到尊重目标环境约束的可执行行为，包括具身限制、接口 API、环境动态和安全要求。

2.2.1 基础化技能选择

基础化技能选择研究智能体如何通过可重用技能接口将高级语言意图映射到可执行行为。

代表性工作：

  • SayCan：建立核心范式，将语言规划与基础化技能执行耦合

  • KnowNo：通过保形预测引入不确定性感知控制

  • BOSS：使用语言引导的实践来合成新的可执行技能链

  • LRLL：引入内存和自我引导探索以维护持久且不断演化的技能接口

  • SkillVLA：扩展到组合双手交互

2.2.2 程序化策略生成

程序化策略生成将代码本身视为模型和环境之间的控制接口。框架直接将可执行策略具体化为指定控制逻辑、感知条件分支、反馈循环和 API 交互的程序。

代表性工作：

  • Code-as-Policies (CaP)：将 LLM 生成的 Python 程序框定为可执行机器人策略

  • RoboCodeX：引入多模态和树结构代码生成

  • Code-BT：将生成的程序编译为行为树控制器

  • CP-Agent：通过迭代执行和修复支持形式化约束求解智能体

  • GenSwarm：扩展程序化控制到多智能体机器人系统

  • NormCode：引入半形式化编程接口，强制执行数据隔离

  • ALRM 和 RACAS：整合代码生成、执行、监控和迭代交互

2.2.3 终身代码基础智能体

终身代码基础智能体研究可执行交互接口如何在长期交互中持久化、演化和积累能力。在这些系统中，代码不仅是执行机制，也是持久内存基底，框架通过它存储可重用行为、交互轨迹和环境知识。

代表性工作：

  • Voyager：通过自动课程和持续扩展的可执行技能库建立范式

  • LRLL：引入持久内存、自我引导任务探索和技能抽象

  • LYRA：将人类纠正转换为可重用可执行技能

  • ViReSkill：结合视觉基础重新规划与技能内存缓存

  • SkillsCrafter：引入持续语言条件操作结构以减轻灾难性遗忘

  • UI-Voyager：通过失败驱动的适应和自我蒸馏将自我演化交互范式泛化到 GUI 智能体

2.3 代码用于环境

智能体还必须维护与之交互的环境的显式表示。没有这样的表示，环境仅通过文本观察、API 返回或稀疏反馈信号间接暴露给智能体。因此，环境状态通常保持隐式、瞬时且难以验证，使得跟踪状态转换、评估交互结果或在长期任务中重用过去的交互历史变得具有挑战性。

代码用于环境通过引入可执行程序作为环境接口本身来解决这一限制。这些系统通过计算工件（如模拟器、代码库、测试、执行轨迹、日志和状态转换程序）来具体化环境结构和动态，而不是将环境视为不透明的外部过程。

现有工作可以组织为四种范式：

2.3.1 结构化世界表示

将视觉场景编码为数据结构、对象/关系函数、程序化专家或可渲染的 HTML。

代表性工作：

  • ViStruct：将视觉场景编码为类/对象层次结构

  • FactoredScenes：组合对象/关系函数用于 3D 布局生成

  • PoE-World：将符号世界模型扩展到简单网格世界之外

  • Code2World：将 GUI 状态预测重新框定为可渲染 HTML 生成

2.3.2 基于执行轨迹的世界建模

将代码与详细执行轨迹配对，合成转换和奖励模型，或训练大型 LLMs 原生处理程序执行轨迹。

代表性工作：

  • SemCoder：将代码与详细执行轨迹配对

  • WorldCoder：合成转换和奖励模型

  • CWM：训练大型 LLMs 原生处理程序执行轨迹

  • RWML：将模拟的下一个状态与实现的环境状态对齐

  • AWM 和 WorldMind：跨任务协调多个可执行世界模型

2.3.3 代码基础评估环境

使用单元测试作为客观世界状态，跨 OS、数据库和游戏进行多环境交互基准测试，或将编码任务框定为带有沙箱反馈的行动。

代表性工作：

  • SWE-bench：使用单元测试作为客观世界状态

  • AgentBench：跨多个环境进行基准测试

  • CRUXEval：基准测试功能输入和输出预测

  • Endless Terminals：自动生成终端使用评估任务

  • InterCode：将编码任务框定为带有沙箱反馈的行动

  • LiveCodeBench：持续更新基于执行的评估流水线

2.3.4 可验证环境构建

生成代码库级任务和执行环境，或合成带有程序化验证器的工具使用环境。

代表性工作：

  • SWE-smith：生成代码库级任务和执行环境

  • EnvScaler：合成带有程序化验证器的工具交互环境

3. 框架机制：规划、内存、工具使用、控制和优化

一旦代码被放置在智能体循环中作为推理、行动和环境建模的接口，框架必须决定接下来执行什么、保留有用的状态、暴露正确的工具，并将失败转化为纠正行动。本节回顾使代码框架化的智能体在单次生成步骤之外保持可靠的机制。

3.1 规划

规划方法组织长期软件任务，通过分解、结构化基础、轨迹搜索或工作流编排。

代表性工作：

  • Self-Planning：智能体自主分解任务

  • WebAgent：结构化基础用于网页交互

  • CodePlan：工作流编排

  • CodeTree：树结构规划

  • MapCoder：多步骤代码生成规划

3.2 内存

内存方法维护工作状态、检索代码库证据、存储可重用经验并支持共享交互历史。

代表性工作：

  • CodeMem：维护工作状态

  • AutoCodeRover：检索代码库证据

  • RepoCoder：存储可重用经验

  • MemGovern：管理共享交互历史

3.3 工具使用

工具使用方法将智能体连接到 API、代码库、执行环境和验证工具。

代表性工作：

  • ToolCoder：连接到 API 和工具

  • ToolNet：工具网络协调

3.4 反馈驱动控制和优化

使用静态分析、运行时错误、测试和人类反馈通过重复执行来修订代码。

代表性工作：

  • AgentCoder：使用静态分析和运行时错误

  • AdaCoder：自适应代码修订

  • AutoSafeCoder：安全驱动的代码优化

  • AgentHarness：框架级优化

4. 扩展框架：基于代码的多智能体编排

当多个智能体在代码上操作时，框架不仅必须支持个体推理和执行，还必须协调角色、共享中间工件、维护共同状态并验证集体进度。

4.1 智能体角色

多智能体系统中的典型角色包括：

  • 管理者：协调整体任务

  • 规划者：分解任务

  • 编码者：实现解决方案

  • 审查者：检查代码质量

  • 测试者：验证功能正确性

4.2 协作模式

代表性工作：

  • AutoGen：灵活的多智能体对话框架

  • MetaGPT：元编程协作

  • Self-Collaboration：智能体自我协作

4.3 工作流拓扑

从集中式协调到分布式或流式协作，代码库、测试、轨迹和结构化工件提供了智能体协调、检查和改进彼此行为的共同工作空间。

5. 应用领域

5.1 编码辅助

智能体在活跃代码库上编写补丁、测试和问题解决工作流。

代表性系统：SWE-bench、SWE-agent、OpenHands

5.2 GUI 和 OS 自动化

智能体合成并执行基于 DOM 树、可访问性 API 和可执行评估器的界面命令。

代表性系统：Mind2Web、WebArena

5.3 科学发现

智能体动态组合和执行假设测试流水线，涵盖模拟、实验室协议和数据分析。

代表性系统：ChemCrow、AI Scientist、BioMNI

5.4 个性化和具身控制

智能体根据环境反馈编写和修订可执行策略、模拟器和技能库。

代表性系统：Voyager、SayCan、Code-as-Policies

5.5 DevOps 和企业工作流

自动化部署、监控和企业级任务编排。

6. 开放挑战

6.1 超越最终任务成功的评估

需要评估中间步骤的质量、可维护性和可解释性，而不仅仅是最终结果。

6.2 不完整反馈下的验证

在部分可观察环境中如何可靠验证智能体行为。

6.3 无回归的框架改进

如何在演化过程中避免引入新错误，同时改进框架能力。

6.4 多智能体间的一致共享状态

如何维护多个智能体之间的状态同步和一致性。

6.5 安全关键行动的人类监督

在高风险场景中如何设计有效的人机协作机制。

6.6 向多模态环境的扩展

如何将代码框架扩展到视觉、音频等多模态场景，保持可执行性、可检查性和有状态性。

7. 结论

本综述提出了代码作为智能体框架的统一视角，将代码从生成目标提升为智能体系统的运行基础设施。通过三层架构（框架接口、框架机制、多智能体扩展），我们系统性地组织了这一新兴领域的研究工作，并概述了实际应用和开放挑战。

代码的三大关键特性——可执行性、可检查性和有状态性——使其成为构建可靠、可验证、自适应的 AI 智能体系统的理想媒介。随着智能体系统从单次生成转向长期自主执行，代码作为框架的角色将变得越来越重要。

我们希望这一综述能为研究者和工程师提供清晰的路线图，推动构建下一代可执行、可验证、有状态的 AI 智能体系统。

论文信息