导读

这篇综述关注一个正在迅速成形的趋势：在 AI 代理系统中，代码不再只是模型生成的最终产物，而正在成为代理推理、行动、记忆、验证和多代理协作的基础设施。论文将这一视角概括为 code as agent harness，即“代码即代理基础设施”：代码既是可执行的操作介质，也是可检查的中间状态，更是可以长期保存、共享和演化的系统对象。

与传统代码生成综述不同，本文不把重点放在“模型如何写出代码”，而是追问代码如何支撑代理系统本身。作者将相关研究组织为三个层次：接口层讨论代码如何连接推理、行动和环境建模；机制层讨论规划、记忆、工具使用、执行验证和自适应优化；扩展层讨论多代理如何围绕共享代码状态协同工作。这个组织方式非常适合理解当下 AI coding agent、GUI/OS agent、科研代理和企业工作流代理背后的系统工程逻辑。 这篇综述的价值在于，它把许多看似分散的方向统一到“基础设施工程”问题下：怎样让代理的行为可执行、可验证、可回滚、可审计，并能在长周期任务中保持状态连续性。对于关注 AI Agent、代码智能体、软件工程自动化、多代理协作和可验证执行系统的读者，这篇论文提供了一张相当清晰的技术地图。

Abstract / 摘要

近年来，大语言模型在代码理解与生成方面展现出强大能力，从竞技编程到仓库级软件工程均取得显著进展。在新兴的代理系统中，代码已不再仅仅是LLM的最终输出产物，它日益成为代理推理、行动、环境建模以及基于执行的验证的操作基础。本文通过“代理基础设施”（agent harness）的视角框架化这一转变，并提出“代码即代理基础设施”（code as agent harness）的统一观点：将代码作为代理基础设施的核心。论文围绕三个相互连接的层次组织综述：首先是接口层，代码作为连接代理与推理、行动和环境建模的界面；其次是机制层，包括规划、记忆、工具使用，以及反馈驱动的控制与优化；最后是扩展层，从单代理系统扩展到多代理设置。论文总结了代表性方法和实际应用，涵盖编码助手、GUI/OS自动化、具身代理、科学发现、个性化推荐、DevOps和企业工作流，并指出了基础设施工程面临的开放挑战。

1 Introduction / 引言

大语言模型在代码理解和生成方面展现出强大能力，从竞技编程到仓库级软件工程均有出色表现。然而，在代理系统中，代码的角色正在发生根本性转变：程序不再仅仅是需要生成的最终产物，而是越来越被用作LLM代理进行推理、行动和环境建模的媒介。 “代理基础设施”这一概念为理解这种转变提供了系统级视角。所谓代理基础设施，是指围绕LLM构建的软件层，包含工具、API、沙箱、记忆、验证器、权限边界、执行循环和反馈通道，从而将无状态的模型转变为能够执行长周期任务的代理。在这种视角下，自主性的瓶颈不仅在于基础模型的推理能力，更在于连接模型输出与长周期行动和持久状态的基础设施系统的可靠性。 为厘清代码在基础设施中的角色，论文区分了三个相互耦合的要素：模型内置能力（model-internal capabilities，指模型的推理、感知、规划等能力）、系统提供的基础设施（system-provided harness infrastructure，指预定义的工具、API、沙箱、记忆系统等）、以及代理发起的代码制品（agent-initiated code artifacts，指代理在执行循环中创建、执行、观察、修订、持久化和共享的交互式代码对象）。现有综述通常将代码视为LLM的最终产物，而本文聚焦于agent-initiated code artifacts，研究模型能力如何通过与harness基础设施交互来构建和演化这些代码制品，以及代码如何作为接口、能力和多代理协调的组织中心。 图1展示了论文的整体分类体系，将代码作为代理基础设施分为三个连接层：接口层、机制层和扩展层，并涵盖从代码助手到科学发现等多个应用领域。 论文围绕三个相互连接的层次组织综述：

• 基础设施接口（§2）：代码作为推理、行动和环境建模的界面；
• 基础设施机制（§3）：规划、记忆、工具使用、控制和优化；
• 基础设施扩展（§4）：从单代理系统到多代理设置。

论文贡献包括：概念框架（形式化code as agent harness）、分类与综合（三个连接层的代表性方法）、应用与未来议程。 图 1：代码即代理基础设施的分类体系。论文将 code as agent harness 组织为三层：接口层连接推理、行动和环境建模；机制层覆盖规划、记忆、工具使用、控制和优化；扩展层讨论基于代码的多代理编排，并进一步映射到代码助手、GUI/OS 代理、具身代理、科学发现代理等应用领域。来源：原论文 PDF 第 2 页。

2 Harness Interface: Code for Reasoning, Acting, and Environment Modeling / 基础设施接口：用于推理、行动和环境建模的代码

基础设施将无状态的语言模型转变为功能性的代理，其核心设计问题是：什么媒介连接模型与其任务环境？论文认为答案是代码。代码是可执行的（executable），模型输出成为具有可验证结果的操作；是可检查的（inspectable），中间计算暴露为结构化轨迹；是有状态的（stateful），演化中的程序以持久、可修改的形式代表任务进度。 论文围绕代码在代理系统中的三个角色组织本节：代码用于推理（externalize internal logic into verifiable computation）、代码用于行动（translate high-level intent into executable operations）、代码用于环境建模（represent world state, transition dynamics, and feedback signals）。 图2展示了代码作为基础设施接口的总体概览，代码通过可执行程序、工具调用、状态追踪和反馈轨迹将代理连接到推理、行动和环境建模。 图3给出了基础设施接口的路线图，按代码在推理、行动和环境建模中的角色，以及按时间顺序排列的代表性工作。 图 2：代码作为基础设施接口的总览。图中展示代码如何通过可执行程序、工具调用、状态跟踪和反馈轨迹，把代理连接到推理、行动和环境建模过程。来源：原论文 PDF 第 8 页。

2.1 Code for Reasoning / 用于推理的代码

代码用于推理将模型推理从临时文本生成转变为可执行和可验证的计算。早期提示技术如思维链在自然语言中执行推理，但不可靠且难以验证。代码用于推理引入代码作为模型与基础设施之间的执行接口，模型生成可执行程序，外部运行时、解释器、符号求解器或验证模块可以执行和评估这些程序。

# 2.1.1 Program-Delegated Reasoning / 程序委派推理

程序委派推理使用可执行程序作为问题分解与计算之间的主要接口。早期工作如PoT、PAL证明将计算委托给程序可显著提高可靠性。Chain of Code、CIRS分析了可执行推理如何改变失败模式。CodeI/O将上下文程序转换为代码输入输出预测任务，暴露推理原语。

# 2.1.2 Formal Verification and Symbolic Reasoning Interfaces / 形式验证与符号推理接口

混合神经符号方法结合灵活的基于语言的推理与结构化符号计算。Graph-of-Thoughts将思维链推理泛化为图结构轨迹。CodeSteer明确协调自由形式的语言推理与可执行符号操作。证明助手如Lean、Isabelle提供基于严格逻辑基础的形式证明语言，每个推导步骤可由验证器检查。DeepSeek-Prover、TheoremaLlama等系统将语言模型与证明助手反馈结合。

# 2.1.3 Iterative Code-Grounded Reasoning / 迭代代码接地推理

迭代代码接地推理专注于生成、执行和反馈之间的闭环交互。NExT训练模型通过程序轨迹预测执行行为。CodePRM使用执行结果评估和精炼中间推理轨迹。Reinforcement learning将执行反馈作为推理轨迹的优化信号，CodeRL、StepCoder等方法通过单元测试奖励优化功能正确性。

2.2 Code for Acting / 用于行动的代码

代码不仅仅是计算媒介，还成为将模型输出转换为接地操作的行动接口，如工具调用、机器人控制策略、GUI动作或软件命令。

# 2.2.1 Grounded Skill Selection / 接地技能选择

SayCan建立了核心范式，将语言规划与接地技能执行相结合。KnowNo通过保形预测引入不确定性感知控制。BOSS通过语言引导练习合成新的可执行技能链。

# 2.2.2 Programmatic Policy Generation / 程序化策略生成

Code-as-Policies将LLM生成的Python程序作为可执行机器人策略。RoboCodeX引入多模态树结构代码生成。Code-BT将生成程序编译为行为树控制器。NormCode强调治理和可审计性。

# 2.2.3 Lifelong Code-Based Agents / 终身代码代理

2.3 Code for Environment / 用于环境建模的代码

代码用于环境建模通过计算制品如模拟器、代码库、测试、执行轨迹和状态转换程序来物化环境结构和动态。

# 2.3.1 Structured World Representations / 结构化世界表示

ViStruct使用编程语言结构作为视觉结构知识提取的显式接口。FactoredScenes将室内环境建模为组合式“房间程序”。Code2World将GUI状态预测重构为可渲染HTML生成。

# 2.3.2 Execution-Trace World Modeling / 执行轨迹世界建模

SemCoder训练语言模型推理运行时语义。Code World Model从程序轨迹中学习预测世界模型。WorldCoder让代理显式编写和更新可执行世界模型。

# 2.3.3 Code-Grounded Evaluation Environments / 代码接地评估环境

InterCode将编码任务重构为交互式执行环境。SWE-bench通过仓库级单元测试评估代理。AgentBench展示可执行交互环境可评估跨多种具体和数字任务的推理能力。

# 2.3.4 Verifiable Environment Construction / 可验证环境构建

SWE-smith通过从现有代码库构建仓库级任务和执行环境来扩展软件工程代理数据。EnvScaler程序化合成工具交互环境。

3 Harness Mechanisms: Planning, Memory, Tool Use, Control, and Optimization / 基础设施机制：规划、记忆、工具使用、控制与优化

基础设施机制构成使代码挂钩代理在单步生成之外保持可靠的系统级核心层。模型提供判断，可变状态记录仓库证据和工作上下文，基础设施暴露工具并约束行动。 图4给出了代理基础设施机制的路线图，展示了从规划、记忆、工具使用到控制和优化的代表性工作随时间的发展。 图5展示了代理基础设施的规划机制分类，包括线性分解、结构化规划、基于搜索的规划和编排式规划。 图 3：代理基础设施机制路线图。图中概括了规划、记忆与上下文工程、工具使用、计划-执行-验证循环，以及自适应基础设施优化等机制如何共同支撑长期代理任务。来源：原论文 PDF 第 17 页。

3.1 Planning for Agent Harness / 代理基础设施的规划

规划在代理基础设施中发挥核心作用，因为现实世界的软件工程任务很少允许从自然语言意图直接映射到正确实现。规划是一种基础设施控制形式：它结构化代理如何将意图外化为可执行步骤。

# 3.1.1 Linear Decomposition Planning / 线性分解规划

代理首先生成单一的、显式的、可执行的步骤序列，然后遵循此分解进行生成。ReAct是这种模式的轻量级前身。

# 3.1.2 Structure-grounded Planning / 结构化接地规划

规划可以锚定在仓库结构或外部知识中，以约束代理的行动空间。RepoCoder、CodePlan等利用依赖图或仓库结构指导规划。

# 3.1.3 Search-based Planning / 基于搜索的规划

通过多候选轨迹的显式搜索来提高鲁棒性。ReThinkMCTS采用蒙特卡洛树搜索，MapCoder搜索多个生成映射。

# 3.1.4 Orchestration-based Planning / 编排式规划

将规划分布到专业化代理角色和反馈循环中，在系统级别协调执行。Self-Planning、OpenHands等在不同结构下编排规划。

3.2 Memory and Context Engineering for Agent Harness / 代理基础设施的记忆与上下文工程

记忆管理跨长交互的可变状态，包括工作记忆、语义记忆、经验记忆、长期记忆、多代理记忆、上下文压缩与状态卸载。

# 3.2.1 Working Memory / 工作记忆

维护当前交互上下文和临时状态。有效工作记忆管理对长周期执行至关重要。

# 3.2.2 Semantic Memory / 语义记忆

检索和利用仓库证据、文档和领域知识。CodeRAG等系统通过检索增强的语义记忆支持代码代理。

# 3.2.3 Experiential Memory / 经验记忆

存储可重用的交互经验。ExpeL、MemCoder等存储和检索过去的执行经验。

# 3.2.4 Long-Term Memory / 长期记忆

持久化跨会话和任务的知识与技能。LongCodeZip等方法支持长期知识保留。

# 3.2.5 Multi-Agent Memory / 多代理记忆

在多个代理之间共享交互历史和知识状态。ChatDev等系统利用共享记忆支持多代理协调。

# 3.2.6 Context Compaction and State Offloading / 上下文压缩与状态卸载

压缩和卸载超过活动上下文窗口的状态，以避免上下文过长问题。TALM等方法通过状态压缩和卸载支持长周期执行。

3.3 Tool Use for Agent Harness / 代理基础设施的工具使用

工具使用将代理连接到受治理的可执行接口，包括API、仓库、终端、沙箱、验证工具和工作流编排器。

# 3.3.1 Function-Oriented Tool Use / 面向功能的工具使用

ToolCoder、CodeAgent等将代码代理连接到特定功能API。

# 3.3.2 Environment-Interaction Tool Use / 环境交互工具使用

工具支持与环境交互，如终端、文件系统和网络服务。

# 3.3.3 Verification-Driven Tool Use / 验证驱动的工具使用

工具支持代码验证，如测试运行器、静态分析器和形式验证器。

# 3.3.4 Workflow-Orchestration Tool Use / 工作流编排工具使用

工具支持多步骤工作流编排，如PR工作流、CI/CD管道。

3.4 Harness Control through the Plan, Execute, and Verify Loop / 通过计划-执行-验证循环的基础设施控制

基础设施控制将反馈驱动的调试重构为更广泛的计划-执行-验证循环：计划形成关于预期变更的合约，执行在沙箱和权限环境中应用变更，验证使用确定性传感器和人工审查门来决定状态是否应被接受、修订、升级或回滚。

3.5 Agentic Harness Engineering for Adaptive Harness Optimization / 自适应基础设施优化的代理基础设施工程

基础设施工程研究基础设施本身如何通过深度遥测、演化代理、重放评估和受治理的基础设施变异来测量和改进。

4 Scaling the Harness: Multi-Agent Orchestration over Code / 扩展基础设施：基于代码的多代理编排

当多个代理在代码上操作时，基础设施必须支持角色协调、共享中间制品、维护共同状态和验证集体进展。 图 4：通过基于代码的多代理编排扩展代理基础设施。图中展示角色专门化代理、共享代码中心基底、执行反馈和自适应协作拓扑如何缓解单代理在上下文、专业化和自我纠错方面的限制。来源：原论文 PDF 第 35 页。

4.1 Improved Coding Support through Multi-agent Collaboration / 通过多代理协作改进编码支持

# 4.1.1 Functional Role Specialization and Human-Guided Planning / 功能角色专业化与人类引导规划

专业化角色包括经理、规划者、编码者、审查者和测试者。ChatDev等系统分配不同角色给不同代理。

# 4.1.2 Diverse Interaction Modes Grounded in Shared Program State / 基于共享程序状态的多样化交互模式

协作模式包括编程、修复、辩论、红队测试和对抗性交互。共享程序状态是这些交互的基础。

# 4.1.3 Optimized Workflow Topology for Agentic Coordination / 优化的工作流拓扑用于代理协调

工作流拓扑从集中式协调到分布式或流式协作。AgentCoder、CodeAgent展示了不同的拓扑。

4.2 Execution Feedback and Shared-Harness Synchronization / 执行反馈与共享基础设施同步

共享制品如仓库、测试、轨迹和结构化工件提供共同工作空间，代理通过它协调、检查和改进彼此行为。

4.3 Position: The Shared Code-Centric Harness Substrate / 立场：共享的以代码为中心的基础设施基底

共享基础设施表示和基础设施状态收敛是多代理代码中心系统的基础挑战。

4.4 Patterns and Trends / 模式与趋势

多代理编排向共享、同步、可验证的基础设施基底演进，支持协调、检查和集体验证。

5 Emerging Fields and Open Problems / 新兴领域与开放问题

5.1 Emerging Fields and Tangible Applications / 新兴领域与具体应用

代码作为代理基础设施的应用跨越编码助手、GUI/OS自动化、具身代理、科学发现、个性化推荐、DevOps和企业工作流。

# 5.1.1 Code Assistants / 代码助手

代理在实时代码库上编写补丁、测试和问题解决工作流。SWE-bench等基准评估代理能力。

# 5.1.2 GUI/OS Agents as a Program World / 作为程序世界的GUI/OS代理

代理基于DOM树、可访问性API和可执行评估器合成和执行界面命令。

# 5.1.3 Autonomous Embodied Agents / 自主具身代理

代理动态编写和修订可执行策略、模拟器和技能库以响应环境反馈。Voyager、RoboCodeX等是代表性工作。

# 5.1.4 Agents for Scientific Discovery as Program Worlds / 作为程序世界的科学发现代理

代理执行假设-测试管道，涵盖模拟、实验室协议和数据分析。Hypothesis-Testing Agent、BioSim等系统代表该方向。

# 5.1.5 Agent Personalization / 代理个性化

代理通过可执行策略和用户配置文件支持个性化交互。Long-term Profile、Adaptive Policy等是该方向的核心技术。

5.2 Open Problems / 开放问题

论文列出了七个开放挑战：

# 5.2.1 Harness-Level Evaluation and Oracle Adequacy / 基础设施层面评估与Oracle充分性

评估需要超越最终任务成功，考虑过程指标如效率、鲁棒性、可解释性和安全性。

# 5.2.2 Semantic Verification Beyond Executable Feedback / 超越可执行反馈的语义验证

验证需要超越运行时错误和测试反馈，理解代码的语义正确性。

# 5.2.3 Self-Evolving Harnesses without Regression / 无回归的自我演化基础设施

基础设施需要在不引入回归的情况下持续改进。深度遥测、演化代理和重放评估是关键技术。

# 5.2.4 Transactional Shared Program State and Semantic Conflict Resolution / 事务性共享程序状态与语义冲突解决

多代理系统中共享程序状态的一致性和冲突解决是核心挑战。

# 5.2.5 Human-in-the-Loop Safety and Accountability as Harness State / 作为基础设施状态的人工参与安全与问责

安全关键行动需要人工监督，确保代理行为的安全性和问责性。

# 5.2.6 Multimodal Code-Harness Systems / 多模态代码基础设施系统

扩展到多模态环境，支持视觉、语音等输入，以及物理世界交互。

# 5.2.7 Toward a Science of Harness Engineering / 迈向基础设施工程科学

基础设施工程需要发展系统化的理论和实践方法，包括设计原则、评估框架和最佳实践。

原文信息

英文题目：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 arXiv ID：2605.18747 类别：cs.CL, cs.AI Comments/项目信息：GitHub: https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers 原文链接：http://arxiv.org/abs/2605.18747v1