代码即智能体 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¹
¹University of Illinois Urbana-Champaign ²Meta ³Stanford University
† 核心贡献者，✉ 通讯作者
摘要： 近年来，大语言模型（LLM）在理解和生成代码方面展现出强大能力，覆盖范围从竞争性编程到代码仓库（repository）级别的软件工程。在新兴的智能体（agent）系统中，代码已不再仅仅是生成的目标产物，它日益成为支撑智能体推理（reasoning）、行动（acting）、环境建模（environment modeling）及基于执行的验证（verification）的操作性基底（operational substrate）。本文以”执行框架（harness）”为视角审视这一转变，并引入代码即智能体 harness（code as agent harness）这一统一视角——将代码置于智能体基础设施的核心。为系统性地研究这一视角，本综述围绕三个相互关联的层次展开。第一层，我们研究 harness 接口（harness interface），即代码如何将智能体与推理、行动和环境建模相连接。第二层，我们考察 harness 机制（harness mechanisms）：面向长时程执行的规划（planning）、记忆（memory）与工具使用（tool use），以及使 harness 可靠且自适应的反馈（feedback）驱动控制与优化方法。第三层，我们讨论 harness 的扩展（scaling the harness）——从单智能体系统延伸至多智能体（multi-agent）场景，共享代码制品（code artifacts）在其中支撑多智能体的协调、审查与验证（verification）。贯穿三个层次，本文总结了代码即智能体 harness 的代表性方法与实际应用，涵盖编码助手、GUI/OS 自动化、具身智能体（embodied agent）、科学发现、个性化与推荐、DevOps 及企业工作流（workflow）。此外，本文进一步梳理了 harness 工程面临的开放挑战，包括：超越最终任务成功指标的评估、不完整反馈下的验证、无回归的 harness 改进、跨多个智能体的一致共享状态、针对安全关键行动的人类监督，以及向多模态环境的扩展。以代码作为智能体 AI 的 harness，本综述为迈向可执行、可验证与有状态的 AI 智能体系统提供了统一的路线图。
关键词（Keywords）：智能体 Harness、编码智能体（Coding Agent）、Harness 工程（Harness Engineering）、智能体 AI（Agentic AI）
Github：https://github.com/YennNing/Awesome-Code-as-Agent-Harness-Papers
1. 引言
近年来，大语言模型（LLM）在理解和生成代码方面展现出强大能力 [1, 2, 3]，在竞争性编程 [4] 到代码仓库级软件工程 [5] 等各类任务中均取得了出色表现。在此基础上，代码在智能体系统中的角色正不断扩展，已超越”待生成的目标制品”的范畴。程序日益成为智能体与环境交互的媒介：
图 1：代码即智能体 harness 的分类体系（原文图见 PDF 第 2 页）
基于程序辅助推理（program-aided reasoning）的方法将中间计算外化为可执行代码 [6, 7, 8]；机器人与具身智能体利用生成的程序作为与物理或模拟世界交互的可执行策略 [9, 10]；软件工程或交互式环境则以代码库（codebase）、执行轨迹（execution traces）、测试和运行时反馈作为环境状态与动态变化的结构化表示，智能体在其中进行规划、行动和行为修正 [11, 5, 12]。综合来看，这些进展指向一种更宏观的视角：代码不仅是大语言模型生成的产物，更是一种可执行（executable）、可检查（inspectable）且有状态（stateful）的媒介，智能体通过它进行推理、行动、观察反馈并验证进展。我们将这一视角称为代码即智能体 harness。
近期关于”智能体 harness”的讨论 [13, 14, 15, 16] 为理解这一转变提供了有价值的系统层面视角。智能体 harness 指围绕大语言模型构建的软件层，其中包含工具、API、沙箱（sandbox）、记忆、验证器、权限边界（permission boundaries）、执行循环和反馈通道，从而将一个无状态的模型转变为能够执行长时程任务的功能性智能体 [17, 18, 19, 20, 21, 22, 23]。在这一视角下，自主性的瓶颈不仅在于基础模型的推理能力，还在于将模型输出与长时程行动及持久状态相连接的系统可靠性。
为厘清代码在这一更宏观的 harness 视角中所扮演的角色，我们区分了长时程智能体系统的三个相互耦合的要素：模型内部能力（model-internal capabilities）、系统提供的 harness 基础设施（system-provided harness infrastructure）以及智能体发起的代码制品（agent-initiated code artifacts）。”模型内部能力”指模型的推理、规划（planning）、仿真和评估能力；”系统提供的 harness 基础设施”指预定义的工具、API、沙箱、记忆系统、验证器、权限边界、遥测系统和工作流（workflow），它们将模型输出连接至外部行动和反馈，是 harness 工程的主要关注对象 [24, 25]。相比之下，智能体发起的代码制品目前尚未得到充分研究，它们是智能体在任务执行循环内部创建、执行、观察、持久化和共享的交互式代码对象。通过执行反馈，这些制品帮助智能体进行推理、行动、验证进展、存储状态并与其他智能体协调。代表性示例包括：回归测试、临时工具、DSL 程序、可执行工作流、可复用技能（reusable skills）以及中间程序状态。Claude Code [26]、Codex [27]、LangChain [28] 等代表性系统以及企业级智能体平台均展示了这些要素如何共同支撑长时程智能体系统中的自适应能力。
基于上述区分，我们重新审视代码在智能体系统中的角色。现有综述通常将代码视为大语言模型的最终输出产物；与之不同，本文聚焦于智能体发起的代码制品，以及模型能力如何通过与 harness 基础设施的交互来构建和演化这些制品——代码在其中充当接口、智能体能力与多智能体协调的组织中心。在各类智能体系统中，代码不仅用于产生解决方案，还用于执行推理、接地（grounding）行动、维护状态并暴露反馈。我们将这一视角称为代码即智能体 harness：代码作为智能体推理、行动与自适应的可执行且可检查的媒介。这将研究范畴从”生成正确程序”转移至”理解代码如何支撑可靠的闭环智能体行为”。
为系统性地刻画代码即智能体 harness，本文将综述组织为三个相互关联的层次，如图 1 所示。这一组织方式展示了代码如何在智能体循环内部成为操作性媒介：首先作为推理、行动和环境表示的 harness 接口进入循环；进而支撑管理规划、记忆、工具使用、执行和修复的 harness 机制；最终成为多个智能体在代码仓库、测试、轨迹、工作流和执行状态上协调的共享制品。
第一层，Harness 接口：用于推理、行动与环境建模的代码（§2）研究代码如何构成模型与任务环境之间的基本接口。在该层，代码是将模型输出转化为可执行且可检查结构的媒介。我们回顾用于推理的代码（code for reasoning），程序将中间计算外化，并借助解释器、符号求解器（symbolic solvers）、执行轨迹或过程奖励来检验和精炼推理 [7, 6, 8, 29, 30, 31]；继而回顾用于行动的代码（code for acting），生成的程序作为策略（policy）、工具调用（tool call）、行为树（behavior tree）或用于具身、GUI 及软件环境的可复用技能 [9, 10, 32, 33, 34, 35]；最后考察用于环境建模的代码（code for environment modeling），程序状态、代码仓库、轨迹、模拟器和测试表示智能体交互的状态、动态变化和反馈信号 [36, 37, 38, 5, 12, 39]。该层确立了 harness 的核心接口：代码使推理可执行、行动可编程、环境状态可检查。
在此接口基础上，第二层，Harness 机制：规划、记忆、工具使用、控制与优化（§3）研究经代码 harness 的智能体如何在单次生成步骤之外保持可靠性。一旦代码被置于智能体循环内，harness 必须决定下一步执行什么、保存有用状态、暴露合适工具，并将失败转化为纠正行动。为此，我们回顾以下方法：通过分解、结构性接地（structural grounding）、轨迹搜索（trajectory search）或工作流编排（workflow orchestration）来组织长时程软件任务的规划方法 [40, 41, 42, 43, 44]；维护工作状态、检索代码仓库证据、存储可复用经验并支撑共享交互历史的记忆方法 [45, 46, 47, 48]；将智能体连接至 API、代码仓库、执行环境和验证工具的工具使用方法 [19, 49]；以及利用静态分析（static analysis）、运行时错误、测试和人类反馈通过反复执行来修正代码的反馈驱动控制与 harness 优化方法 [50, 51, 52, 53]。该层将第 §2 中的接口转化为可操作的 harness：规划控制执行轨迹、记忆保存状态、工具扩展行动空间，反馈驱动的自适应则闭合了失败与修正之间的循环。
调研范围（Survey Scope）
本综述研究代码即智能体 harness：以代码为中心的智能体系统，其中推理、行动、状态、反馈与验证均围绕可执行（executable）、可检查（inspectable）且有状态（stateful）的程序来组织。本文将截至 2026 年的相关文献整理为三个相互关联的层次：
- Harness 接口：代码以推理基底（reasoning substrate）、行动接口和环境表示的形式进入智能体循环。
- Harness 机制：规划、记忆、工具使用、控制与 harness 优化，支撑以代码为中心的智能体在长时程执行与修正中的可靠性。
- 扩展 Harness：共享代码制品、执行状态、代码仓库和结构化工作流，支撑多智能体系统中的协调、审查与集体验证。
第三层，扩展 Harness：基于代码的多智能体编排（§4）将 harness 从单一智能体延伸至协作生态系统。当多个智能体共同操作代码时，harness 不仅需要支撑个体的推理与执行，还必须协调角色、共享中间制品、维护公共状态并验证集体进展。我们从以下维度回顾多智能体代码中心系统：智能体角色（如管理者、规划者、编码者、审查者和测试者）；协作模式（如编程、修复、辩论、红队对抗（red-teaming）和对抗性交互）；以及从集中式协调到分布式或流式协作的工作流拓扑 [54, 55, 56]。该层展示了代码如何成为编排自主性的共享 harness：代码仓库、测试、轨迹和结构化制品提供公共工作空间，使智能体能够相互协调、检查和改进行为。
超越分类体系本身，本文还考察了智能体发起的代码交互在五个应用领域中的表现。在编码辅助（coding assistance）领域，智能体在实时代码仓库上撰写补丁、测试和问题解决工作流 [5, 57, 58]；在 GUI 与 OS 自动化领域，智能体合成并执行基于 DOM 树（DOM tree）、无障碍 API 和可执行评估器（executable evaluators）接地的界面命令 [59, 60]；在科学发现（scientific discovery）领域，智能体动态组合并执行跨仿真、实验室协议和数据分析的假设检验流水线 [61, 62, 63, 64]；在个性化与具身控制（personalization and embodied control）领域，智能体根据环境反馈撰写和修订可执行策略、模拟器和技能库 [9, 10, 32]。此外，本文进一步梳理了 harness 工程面临的开放挑战，包括：超越最终任务成功指标的评估、不完整反馈下的验证、无回归的 harness 改进、跨多个智能体的一致共享状态、人类监督，以及向多模态环境的扩展（scaling）。本综述为研究代码——不仅作为某些智能体生成的产物，更作为它们赖以执行、自适应并协调可靠行为的运行时媒介——提供了一幅路线图。
贡献（Contributions）
- 概念框架：我们将代码即智能体 harness 形式化，将代码从生成制品重新定位为可执行、可验证且有状态的 AI 智能体系统的操作基底。
- 分类体系与综合：我们将代码即智能体 harness 组织为三个相互关联的层次——harness 接口、harness 机制与扩展 harness——并综合了代表性方法。
- 应用与未来议程：我们将分类体系与真实世界应用相连接，并梳理了评估、验证（verification）、安全性和协调方面的关键挑战。
目录
- 1 引言
- 2 Harness 接口：用于推理、行动与环境建模的代码
- 2.1 用于推理的代码
- 2.1.1 程序委托推理（Program-Delegated Reasoning）
- 2.1.2 形式化验证与符号推理接口（Formal Verification and Symbolic Reasoning Interfaces）
- 2.1.3 迭代式代码接地推理（Iterative Code-Grounded Reasoning）
- 2.2 用于行动的代码
- 2.2.1 接地技能选择（Grounded Skill Selection）
- 2.2.2 程序化策略生成（Programmatic Policy Generation）
- 2.2.3 终身基于代码的智能体（Lifelong Code-Based Agents）
- 2.3 用于环境建模的代码
- 2.3.1 结构化世界表示（Structured World Representations）
- 2.3.2 执行轨迹世界建模（Execution-Trace World Modeling）
- 2.3.3 代码接地评估环境（Code-Grounded Evaluation Environments）
- 2.3.4 可验证环境构建（Verifiable Environment Construction）
- 2.1 用于推理的代码
- 3 Harness 机制：规划、记忆、工具使用、控制与优化
- 3.1 智能体 Harness 的规划
- 3.1.1 线性分解规划（Linear Decomposition Planning）
- 3.1.2 结构接地规划（Structure-grounded Planning）
- 3.1.3 基于搜索的规划（Search-based Planning）
- 3.1.4 基于编排的规划（Orchestration-based Planning）
- 3.2 智能体 Harness 的记忆与上下文工程
- 3.2.1 工作记忆（Working Memory）
- 3.2.2 语义记忆（Semantic Memory）
- 3.2.3 经验记忆（Experiential Memory）
- 3.2.4 长期记忆（Long-Term Memory）
- 3.2.5 多智能体记忆（Multi-Agent Memory）
- 3.2.6 上下文压缩与状态卸载（Context Compaction and State Offloading）
- 3.3 智能体 Harness 的工具使用
- 3.3.1 面向函数的工具使用（Function-Oriented Tool Use）
- 3.3.2 环境交互工具使用（Environment-Interaction Tool Use）
- 3.3.3 验证驱动的工具使用（Verification-Driven Tool Use）
- 3.3.4 工作流编排工具使用（Workflow-Orchestration Tool Use）
- 3.4 通过计划-执行-验证循环进行 Harness 控制
- 3.4.1 从调试到 Harness 级控制（From Debugging to Harness-Level Control）
- 3.4.2 规划即合约形成（Planning as Contract Formation）
- 3.4.3 沙箱执行与带权限的状态转移（Sandboxed Execution and Permissioned State Transition）
- 3.4.4 通过确定性传感器进行验证（Verification through Deterministic Sensors）
- 3.5 面向自适应 Harness 优化的智能体 Harness 工程
- 3.5.1 深度遥测作为优化基底（Deep Telemetry as the Optimization Substrate）
- 3.5.2 演化智能体（The Evolution Agent）
- 3.5.3 受治理的 Harness 变异（Governed Harness Mutation）
- 3.1 智能体 Harness 的规划
- 4 扩展 Harness：基于代码的多智能体编排
- 4.1 通过多智能体协作改进编码支持
- 4.1.1 功能角色专业化与人类引导规划（Functional Role Specialization and Human-Guided Planning）
- 4.1.2 基于共享程序状态接地的多样交互模式（Diverse Interaction Modes Grounded in Shared Program State）
- 4.1.3 面向智能体协调的优化工作流拓扑（Optimized Workflow Topology for Agentic Coordination）
- 4.2 执行反馈与共享 Harness 同步
- 4.2.1 执行反馈集成（Execution Feedback Integration）
- 4.2.2 共享 Harness 同步（Shared-Harness Synchronization）
- 4.3 立场：共享代码中心 Harness 基底
- 4.3.1 共享 Harness 表示（Shared Harness Representation）
- 4.3.2 Harness 状态收敛（Harness-State Convergence）
- 4.4 模式与趋势（Patterns and Trends）
- 4.1 通过多智能体协作改进编码支持
- 5 新兴领域与开放问题
- 5.1 新兴领域与具体应用
- 5.1.1 编码助手（Code Assistants）
- 5.1.2 GUI/OS 智能体作为程序世界（GUI/OS Agents as a Program World）
- 5.1.3 自主具身智能体（Autonomous Embodied Agents）
- 5.1.4 用于科学发现的智能体作为程序世界（Agents for Scientific Discovery as Program Worlds）
- 5.1.5 智能体个性化（Agent Personalization）
- 5.2 开放问题
- 5.2.1 Harness 级评估与预言机充分性（Harness-Level Evaluation and Oracle Adequacy）
- 5.2.2 超越可执行反馈的语义验证（Semantic Verification Beyond Executable Feedback）
- 5.2.3 无回归的自演化 Harness（Self-Evolving Harnesses without Regression）
- 5.2.4 事务性共享程序状态与语义冲突解决（Transactional Shared Program State and Semantic Conflict Resolution）
- 5.2.5 作为 Harness 状态的人在回路安全与问责（Human-in-the-Loop Safety and Accountability as Harness State）
- 5.2.6 多模态代码 Harness 系统（Multimodal Code-Harness Systems）
- 5.2.7 迈向 Harness 工程科学（Toward a Science of Harness Engineering）
- 5.1 新兴领域与具体应用
2. Harness 接口：用于推理、行动与环境建模的代码
harness 通过将语言模型的输出接地（grounding）于外部执行、持久状态与可验证反馈（feedback），将无状态语言模型转化为具有功能的智能体（agent）。任何 harness 设计所面临的最根本问题是：什么媒介将模型与其任务环境相连接？
我们认为，代码即是答案。与自然语言不同，代码是可执行的（executable），意味着模型的输出成为具有形式化可验证结果的操作；代码是可检查的（inspectable），意味着中间计算过程被暴露为结构化的执行轨迹，harness 可以读取、存储并据此行动；代码是有状态的（stateful），意味着不断演化的程序以持久、可修改的形式在各步骤间表示任务进展。值得强调的是，这些属性并非代码作为符号系统的固有特性，而是使代码成为 harness 接口的关键特质：可执行性使 harness 能够验证（verification）模型的意图；可检查性使故障可被诊断并反馈（feedback）；有状态性确保智能体的交互历史不会在步骤间丢失。
范围界定。 本文对”代码”的使用范围较广，但并非隐喻性的。在本综述中，代码指可执行或可机器检查的制品，包括程序、脚本、形式化规约、证明脚本、API 模式（schema）、工具定义、测试、代码仓库（repository）、模拟器、配置文件，以及由可执行系统生成或被其消费时的执行轨迹与日志等代码邻近执行制品。相比之下，原始感知、物理状态、人类意图，以及模型内部的潜在推理（reasoning）本身并非代码。它们可以通过代码被感知、估计、序列化、验证或执行，但不应与代码接口相混淆。划定这一边界十分重要：代码即智能体 harness（code as agent harness）并不取代感知、具身（embodiment）、人类目标或模型推理，而是在智能体循环中使其中特定方面变得可执行、可检查和有状态。
我们围绕代码在智能体系统中承担的三种角色来组织这一接口。用于推理的代码（Code for reasoning）将内部逻辑外化为可验证的计算，允许外部解释器、符号求解器、执行轨迹或过程奖励来检验和精炼推理（§2.1）。用于行动的代码（Code for acting）将高层意图转化为接地于具身（embodied）、GUI、软件或工具使用（tool use）环境中的可执行操作（§2.2）。用于环境建模的代码（Code for environment modeling）通过程序状态、代码仓库、模拟器、测试和日志来表示世界状态、转移动态与反馈信号，供智能体执行、编辑和查询（§2.3）。总体而言，这三种角色定义了 harness 接口：代码使推理可执行、使行动可编程、使环境状态可检查。
2.1. 用于推理的代码
智能体 harness 的核心作用之一是将模型推理从瞬时的文本生成转化为可执行且可验证的计算。早期的提示技术（如纯思维链（CoT，chain-of-thought）[65]）完全在自然语言中进行推理与计算，迫使模型在单一文本流程中同时完成问题分解和中间运算。尽管语言模型通常能有效提出推理步骤，但在忠实执行符号推理、逻辑推理或算术计算方面仍不可靠 [7]。更重要的是，纯文本推理几乎无法为智能体 harness 提供验证中间状态、检查执行行为或跨步骤持久化计算进展的能力。
因此，推理用代码（code-for-reasoning）将代码引入为模型与 harness 之间的执行接口，超越了纯文本推理。模型生成可执行程序，由外部运行时（runtime）、解释器、符号求解器或验证模块执行并评估。这将高层推理与底层计算分离：模型提出过程，harness 执行它们，
图 2：代码作为 harness 接口的概览，通过可执行程序、工具调用、状态追踪与反馈轨迹将智能体连接到推理、行动和环境建模。（原文图见 PDF 第 8 页）
观察运行时行为，存储中间状态，并将执行结果输入后续推理。
近期工作进一步将这一接口从”程序执行作为外部计算器”扩展为”执行制品作为可复用推理信号”。输入输出、执行轨迹、变量状态、控制流结构和函数级调用均可作为中间状态，由 harness 进行验证、评分并反馈至后续推理。现有工作因此可以归纳为三种范式：程序委托推理（program-delegated reasoning）、形式化验证与符号推理（formal verification and symbolic reasoning），以及迭代代码接地推理（iterative code-grounded reasoning）。以下各小节分别详述。
图 3：harness 接口路线图，按代码在推理、行动和环境建模中的角色组织，各角色内的代表性工作按时间顺序排列。（原文图见 PDF 第 9 页）
2.1.1. 程序委托推理
程序委托推理（Program-Delegated Reasoning）将可执行程序作为问题分解与计算之间的主要接口。模型不再依赖纯自然语言推理，而是生成由外部解释器执行以产生形式化接地输出的代码。早期工作 [66, 7] 表明，将计算委托给程序可通过将中间推理转化为结构化、可验证的执行轨迹来显著提升可靠性。Program-of-Thoughts（PoT）提示 [6] 进一步系统化了这一范式，通过将推理显式分解为可执行程序，随后由 POET [67] 和 MathCoder [68] 等扩展工作提升了执行保真度和领域专业化程度。后续工作探究了程序委托有效的条件，包括执行正确性、任务结构和运行时交互的作用。例如，Chain of Code（CoC）[8] 和 CIRS [69] 分析了可执行推理相较于纯语言推理如何改变故障模式。更晚近的工作将这一接口扩展到孤立任务执行之外：跨语言推理框架 [70] 表明，基于程序的推理可通过共享可执行结构在语言环境间泛化；而基于方法的推理 [71] 引入了跨任务持久存在的可复用程序化过程。CodeAdapt [72] 等更新近的系统进一步表明，将语言模型与可执行推理接口紧密耦合可以超越专用推理导向模型。此外，CodeI/O [73] 将上下文接地程序转化为代码输入-输出预测任务，通过可执行验证暴露逻辑流规划、状态空间搜索、决策树遍历、模块化分解等推理原语，同时保持程序性严谨性。
2.1.2. 形式化验证与符号推理接口
混合神经-符号方法（Hybrid neural-symbolic methods）将灵活的基于语言的推理与结构化的符号计算相结合，将代码和符号制品作为持久的中间表示，而非仅将程序视为生成的文本。早期表述如 Graph-of-Thoughts [74] 将思维链（CoT）推理泛化为图结构轨迹，使中间状态能够分支、合并和复用。在此基础上，自我验证反射 [75]、MA-LoT [76] 和 Socratic 自我精炼 [77] 引入了迭代验证循环，其中符号一致性检查指导生成解题路径的精炼。
近期工作通过基于代码的接口进一步加强了神经生成与符号执行之间的耦合。CodeSteer [78] 和 Code-as-Symbolic-Planner [79] 显式地协调自由形式的语言推理与可执行符号操作，将程序视为 harness 可以跨多个阶段检查、变换和执行的结构化基底。VisualCoder [80] 通过使程序行为对控制流图可见来扩展这一思路。通过将生成的推理与可视化控制流图和执行路径对齐，它将动态程序行为转化为可检查的
用于程序行为预测的制品。总体而言，这些方法将神经-符号接口从文本代码扩展到了 harness 可引用、验证和复用的多模态执行制品。
一条互补的研究路线将机器可验证的形式化语言本身作为推理接口。Lean [81]、Isabelle [82] 和 Coq [83] 等证明助手提供了基于严格逻辑基础的形式证明语言，使每一步推理都可由验证器检查。早期基于大语言模型（LLM）的定理证明系统（包括 ReProver [84]、DeepSeek-Prover [85] 和 TheoremLlama [86]）建立了将语言模型与证明助手反馈结合用于数学推理的实用方案。更新近的系统（如 DeepSeek-Prover-V2 [87]、Kimina-Prover [88]、MA-LoT [76] 和 Goedel-Prover-V2 [89]）通过审慎式证明搜索、自我修正以及反复生成和验证证明来改进这一过程。形式化验证接口也在超越数学定理证明的方向上不断拓展：HybridReasoning [90] 将形式化证明器应用于支持自然语言推理；Lean4Physics [91] 和 PhysLib [92] 将基于 Lean 的验证扩展到物理领域；VERINA [93] 和 Goedel-Code-Prover [94] 将形式化方法适配于代码验证。Lean4Agent [95] 进一步将这一轨迹推广到智能体系统，通过使用 Lean4 对智能体工作流（workflow）和轨迹进行建模与验证。从 harness 的视角来看，这些系统展示了形式化语言如何不仅充当推理工具，还充当约束、认证和审计智能体行为的可执行契约。
2.1.3. 迭代代码接地推理
迭代代码接地推理（Iterative code-grounded reasoning）聚焦于生成、执行与反馈之间的闭环交互。在这些系统中，推理并非一次性过程，而是接地于可执行状态转移的迭代计算轨迹。NExT [30] 等早期工作通过对程序轨迹进行推理来训练模型预测执行行为，从而将中间推理接地于运行时语义。相关工作 [96] 同样强调可执行轨迹比最终文本输出单独提供更丰富的监督信号。在此基础上，后续方法引入了显式的”生成-执行-验证-精炼”循环：CodePRM [31] 和 ORPS [97] 利用执行结果评估和精炼中间推理轨迹，使 harness 能够通过运行时反馈（而非纯粹的下一词元预测）引导推理。沿同一方向，CYCLE [98] 和 Self-Edit [99] 等系统利用执行感知的修正信号迭代修订生成的解。强化学习通过将执行反馈作为推理轨迹上的优化信号，进一步强化了这一范式：CodeRL [100]、CodeRL+ [101] 和 RLTF [102] 等方法通过单元测试奖励优化函数正确性，而 StepCoder [103] 等方法则在优化过程中融入细粒度的编译器和运行时反馈。RLEF [104] 将这一交互形式化为接地于多步执行反馈的策略优化，使推理策略能够通过迭代运行时交互进行自适应。更新近的方法转向完全交互式的推理环境：EG-CFG [21] 在生成过程中直接注入执行信号以支持步骤级修正，而 R1-Code-Interpreter [105] 等系统则在持久交互会话中交织推理与多轮代码执行。
2.2. 用于行动的代码
除推理外，智能体还必须将模型连接到决策会产生真实可执行效果的外部环境。在这一阶段，代码不再主要充当计算媒介，而是作为将模型输出转化为接地操作（如工具调用、机器人控制策略、GUI 动作或软件命令）的行动接口。通过这一接口，harness 将高层意图转化为能够与具身（embodied）、数字和交互式环境进行交互的可执行行为。
表 1：代码作为推理基底的代表性系统。
| 方法 | 机制 | 推理范式 | 核心创新 |
|---|---|---|---|
| PoT [6] | 委托 | 混合注释 | 将代码与自然语言 CoT 融合 |
| PAL [7] | 委托 | 程序辅助 | 将逻辑与计算解耦 |
| CodeAdapt [72] | 委托 | 可泛化逻辑 | 代码使能的 LLM 超越推理模型 |
| CodeI/O [73] | 委托 | I/O 预测 | 将代码转化为可验证输入输出推理任务 |
| SATLM [29] | 形式化 | SAT/SMT 求解 | 使用符号求解器作为可机器检查的推理后端 |
| ReProver [84] | 形式化 | Lean 证明搜索 | 将 LLM 生成与证明助手反馈相结合 |
| Dpsk-Prover [85] | 形式化 | Lean 定理证明 | 为形式化数学证明生成训练 LLM |
| Dpsk-Prover-V2 [87] | 形式化 | 审慎式证明 | 通过分解与自我修正进行 Lean 证明搜索 |
| Goedel-Code-Prover [94] | 形式化 | Lean 代码证明 | 搜索层次化 Lean 证明用于代码验证 |
| Lean4Agent [95] | 形式化 | 智能体验证 | 在 Lean4 中对智能体工作流和轨迹建模与验证 |
| Chain of Code [8] | 混合 | LMulator | 模拟不可执行的语义代码 |
| SATLM [29] | 混合 | 形式逻辑 | 使用 SAT/SMT 求解器作为推理后端 |
| CodeSteer [78] | 混合 | 符号控制 | 在符号代码与神经文本间显式转换 |
| VisualCoder [80] | 混合 | CFG 接地 | 将代码推理与可视化控制流制品对齐 |
| NExT [30] | 迭代 | 轨迹接地 | 通过程序轨迹预测执行行为 |
| MathCoder [68] | 迭代 | 反馈驱动 SFT | 交织代码、输出与反射 |
| CodePRM [31] | 迭代 | 过程奖励 | 在推理-执行轨迹上学习奖励函数 |
| RLEF [104] | 迭代 | 多步 RL | 利用执行反馈直接优化策略 |
| EG-CFG [21] | 迭代 | 执行引导 | 在生成过程中直接集成执行信号 |
| R1-Code-Int. [105] | 迭代 | 完全交互 | 自主交织推理与多轮执行 |
| ExecVerify [106] | 迭代 | 逐步 RL | 使用语句级和变量级执行奖励 |
| FunPRM [107] | 迭代 | 函数步骤 PRM | 将函数视为可验证的过程-奖励单元 |
| ReCode [108] | 迭代 | 过程 RL | 以推理过程奖励强化代码生成 |
核心挑战因此在于接地（grounding）：harness 必须将抽象的语言输出映射为遵守目标环境约束（包括具身限制、接口 API、环境动态和安全要求）的可执行行为。与推理用代码不同，在行动执行中，解释器通常可直接验证正确性；而在部分可观察、动态演化的环境中，失败可能通过无效状态转移、延迟反馈或无声的执行错误而涌现。例如，机器人可能试图抓取其工作空间之外的物体，却不产生任何显式的运行时异常。
重要的是，可执行行动代码是连接这些组件的接口，而非替代品。在具身（embodied）设置中，感知模块提供观察，可供性（affordance）或可行性模型估计哪些行动是可行的，运动规划器和控制器将符号命令连接到传感器和执行器，安全层约束危险或无效行为。在 GUI 和软件设置中，类似组件包括屏幕解析器、DOM 或无障碍树、后端 API、用户意图模型、权限系统和程序化验证器。代码位于模型与这些组件之间：它序列化观察、调用接地（grounding）和规划（planning）模块、触发可执行行动，并将验证结果暴露回 harness。
行动用代码（code-for-acting）因此将结构化可执行程序引入为模型与环境之间的控制接口，使 harness 能够通过交互反馈执行、监控、验证、复用和精炼行动。这一接口可以以不同形式实现：预定义的技能库（skill library）、
表 2：代码作为行动接口的代表性系统。
| 方法 | 机制 | 行动范式 | 核心创新 |
|---|---|---|---|
| AutoHarness [109] | Harness 生成 | 行动验证 | 自动合成 code harness 以调解模型行动并过滤无效环境交互 |
| SayCan [9] | 技能选择 | 基于可供性 | 将 LLM 规划与物理可行性相连接 |
| KnowNo [110] | 技能选择 | 共形预测 | 为模糊指令校准规划器不确定性 |
| SkillVLA [111] | 技能选择 | 双手接地 | 将接地扩展至组合式技能复用 |
| BOSS [112] | 技能选择 | 技能引导 | 通过引导实践合成新的可执行技能链 |
| LLM-Guided Traj. [113] | 技能选择 | 轨迹生成 | 生成多样化操作轨迹和可执行成功条件 |
| LRLL [114] | 技能选择 | 终身接地 | 通过记忆与自我探索演化技能接口 |
| CaP [10] | 策略生成 | 层次化 Python | 生成响应式机器人控制策略 |
| RoboCodeX [33] | 策略生成 | 多模态树 | 跨导航合成树结构化代码 |
| Code-BT [34] | 策略生成 | 行为树 | 通过代码到行为树规划施加规则约束 |
| ALRM [115] | 策略生成 | 闭环控制 | 将程序化生成与 ReAct 执行相集成 |
| CP-Agent [116] | 策略生成 | 约束求解 | 使用持久执行循环进行形式约束模型修复 |
| Robot-Code Sim. [117] | 策略生成 | 静态仿真 | 将 LLM 用作机器人代码评估的静态模拟器 |
| GenSwarm [118] | 策略生成 | 多机器人控制 | 跨机器人智能体协调策略生成与部署 |
| NormCode [119] | 策略生成 | 受治接口 | 通过半形式代码强制审计性与数据隔离 |
| RACAS [120] | 策略生成 | 协作控制 | 面向闭环协作控制的机器人无关架构 |
| Voyager [32] | 终身 | 技能库 | 面向开放性任务的自主课程 |
| LYRA [121] | 终身 | 人在回路 | 将人类修正编码为可复用结构化技能 |
| ViReSkill [122] | 终身 | 视觉接地 | 在环境失败时利用技能记忆缓存进行重规划 |
| UI-Voyager [35] | 终身 | 自我演化 | 面向移动端 GUI 智能体的拒绝微调与自蒸馏 |
| SkillsCrafter [123] | 终身 | 持续技能 | 在可执行操作技能累积时缓解遗忘 |
生成的控制策略、持久技能记忆（memory）、GUI/API 工具协议，或显式的行动验证 harness。AutoHarness [109] 通过自动合成一个 code harness（调解 LLM 与环境之间的交互、在执行前过滤无效行动）使最后一种形式显式化。这凸显了行动用代码的核心 harness 视角：代码不仅是待执行的行动，也是将模型意图与感知、接地（grounding）、可供性估计、控制器、API、执行器和安全约束相连接的可执行边界。
2.2.1. 接地技能选择
接地技能选择（Grounded Skill Selection）研究智能体如何通过可复用的技能接口将高层语言意图映射为可执行行为。这些系统不是直接生成底层行动，而是将环境视为智能体 harness 可调用、组合和在环境约束下精炼的可执行能力集合。SayCan [9] 通过将语言规划（planning）与接地技能执行相耦合建立了核心范式，使智能体不仅能基于语义相关性、还能基于具身可行性来选择行动。后续工作沿多个方向扩展了这一执行接口：KnowNo [110] 引入不确定性感知的共形预测控制，使 harness 能够检测模糊状态并在不安全执行前触发澄清；BOSS [112] 通过语言引导的实践合成新的可执行技能链来应对固定技能库的刚性，使 harness 能够随时间扩展其行动空间；[113] 通过使用 LLM 引导生成来构建多样化操作轨迹，解决了接地交互的数据瓶颈问题；
并为自动重试和重标注生成可执行成功条件。LRLL [114] 引入记忆（memory）和自引导探索以在跨任务的持久且演化的技能接口中维持存在。最后，SkillVLA [111] 将这一范式扩展至组合式双手交互，强调接地行动接口必须在日益复杂的具身设置中支持结构化技能复用与组合。
2.2.2. 程序化策略生成
程序化策略生成（Programmatic Policy Generation）将代码本身视为模型与环境之间的控制接口。harness 不再从预定义技能中选择，而是直接将可执行策略实例化为程序，这些程序规约控制逻辑、感知条件分支、反馈回路和 API 交互。CaP [10] 通过将 LLM 生成的 Python 程序作为可执行机器人策略将这一范式具体化。在此基础上，RoboCodeX [33] 引入多模态树结构化代码生成以支持更复杂的操作和导航行为。后续工作聚焦于扩展交互基底：RoboPro [124] 从大规模现实视频合成可执行策略代码，而 Code-BT [34] 将生成的程序编译为支持受约束执行和迭代运行时反馈的行为树。在机器人领域之外，CP-Agent [116] 展示了持久执行循环可以通过迭代执行与修复支持形式约束求解智能体。为减少对昂贵物理环境的依赖，[117] 将语言模型配置为机器人代码评估的静态执行模拟器。GenSwarm [118] 进一步将程序化控制扩展至多智能体（multi-agent）机器人系统，其中 harness 必须跨多个具身智能体协调策略生成、约束分析和部署。在系统层面，NormCode [119] 通过引入具有强制数据隔离的半形式化编程接口强调治理与可审计性，使执行轨迹和控制逻辑保持可检查和受约束。最后，ALRM [115] 和 RACAS [120] 将这些思路整合为持久闭环控制架构，在统一智能体 harness 内集成代码生成、执行、监控和迭代交互。
2.2.3. 终身代码型智能体
终身代码型智能体（Lifelong Code-Based Agents）研究可执行交互接口如何在长周期交互中持久存在、演化和积累能力。在这些系统中，代码不仅是执行机制，也是 harness 存储可复用行为、交互轨迹和环境知识的持久记忆（memory）基底。Voyager [32] 通过在 Minecraft 中自动构建课程和持续扩展技能库，为开放性交互建立了这一范式。将这一思路扩展至具身环境，LRLL [114] 引入持久记忆（memory）、自引导任务探索和技能抽象，以在无需梯度更新的情况下克服固定策略库的局限。终身 harness 的核心挑战在于交互反馈与修正往往是瞬时的且难以复用。LYRA [121] 通过将人类修正转化为可复用的可执行技能和检索增强的记忆结构来解决这一问题。类似地，ViReSkill [122] 结合视觉接地重规划与技能记忆（skill-memory）缓存，在环境失败和输出变化下保持稳定交互。近期工作进一步聚焦于持久部署下的持续自适应与自我演化：SkillsCrafter [123] 引入持续语言条件化操作结构，以在可执行能力积累时缓解灾难性遗忘；UI-Voyager [35] 通过失败驱动的自适应和自蒸馏将自我演化交互范式推广至 GUI 智能体。总体而言，这些系统超越了一次性执行，转向持续扩展、精炼和复用可执行交互接口的持久智能体 harness。
2.3. 用于环境建模的代码
智能体还必须维护与其交互的环境的显式表示。若缺乏这种表示，环境仅能通过文本观察、API 返回值或稀疏反馈信号间接暴露给智能体。因此，环境状态往往是隐式的、瞬时的且难以验证的，使得跟踪状态转移、评估交互结果或在长周期任务中复用历史交互变得十分困难。这一局限在复杂的软件、机器人和多步交互式环境中尤为突出，因为在这些场景中，成功的交互依赖于持续维护一致的世界状态和接地的反馈。
环境用代码（code-for-environment）通过将可执行程序引入为环境接口本身来解决这一局限。这些系统不将环境视为不透明的外部过程，而是通过模拟器、代码仓库（repository）、测试、执行轨迹、日志和状态转移程序等计算制品来具象化环境结构与动态。这使智能体能够在整个交互过程中显式地存储、检查、执行和修改环境状态。通过可执行代码表示环境具有两大主要优势：第一，可执行环境暴露可验证的状态转移，使智能体能够通过执行评估交互结果，而非依赖模糊的自然语言判断；第二，基于代码的环境具有持久性和可修改性，智能体可以在交互过程中查询、模拟、编辑和精炼。智能体 harness 因此可以将推理与行动接地于显式的计算状态和运行时动态，而非仅通过语言与不透明的世界交互。现有工作可以归纳为四种范式：结构化世界表示（structured world representations）、执行轨迹世界建模（execution-trace world modeling）、代码接地评估环境（code-grounded evaluation environments），以及可验证环境构建（verifiable environment construction）。
表 3：代码作为环境表示的代表性系统。
| 方法 | 机制 | 环境范式 | 核心创新 |
|---|---|---|---|
| ViStruct [125] | 结构化 | 类/对象层次 | 将视觉场景编码为数据结构 |
| FactoredScenes [126] | 结构化 | 房间程序 | 组合对象/关系函数用于 3D 布局生成 |
| PoE-World [127] | 结构化 | 程序化专家 | 将符号世界模型扩展到简单网格世界之外 |
| Code2World [38] | 结构化 | 渲染感知 RL | 将 GUI 状态预测重构为可渲染的 HTML 生成 |
| SemCoder [128] | 轨迹 | 语义对齐 | 用详细执行轨迹对代码进行配对 |
| WorldCoder [36] | 轨迹 | 基于模型的 RL | 合成转移与奖励模型 |
| CWM [37] | 轨迹 | 开放权重轨迹 | 在程序执行轨迹上原生训练大型 LLM |
| RWML [129] | 轨迹 | 自监督 RL | 将仿真下一状态与实际环境状态对齐 |
| AWM [130] | 轨迹 | 世界建模 | 跨任务对齐多个可执行世界模型 |
| WorldMind [131] | 轨迹 | 模型融合 | 从知识源协调可执行世界模型 |
| SWE-bench [5] | 评估 | 代码仓库级测试 | 将单元测试用作客观世界状态 |
| AgentBench [12] | 评估 | 多环境交互 | 跨操作系统、数据库和游戏进行基准测试 |
| CRUXEval [132] | 评估 | 执行任务 | 对函数输入输出预测进行基准测试 |
| End Terms. [39] | 评估 | 程序化 RL 环境 | 自动化生成终端使用评估任务 |
| InterCode [11] | 评估 | 交互式执行 | 将编程任务构建为带沙箱反馈的行动 |
| LiveCodeBench [133] | 评估 | 实时编程评估 | 持续更新基于执行的评估流水线 |
| CRUXEval-X [134] | 评估 | 多语言执行 | 跨语言扩展输入输出执行评估 |
| CoRe [135] | 评估 | 运行时推理 | 通过以执行为中心的任务评估代码推理 |
| CodeGlance [136] | 评估 | 多模态代码评估 | 在视觉和结构设置下评估代码理解 |
| SWE-smith [137] | 构建 | 合成 SWE 环境 | 生成代码仓库级任务和执行环境 |
| EnvScaler [138] | 构建 | 工具交互环境 | 用程序化验证器合成工具使用环境 |
2.3.1. 结构化世界表示（Structured World Representations）
结构化世界表示通过显式的程序化结构对环境进行建模，使智能体能够执行、检查和操作这些结构。与仅依赖潜在嵌入或文本描述来表征世界状态不同，这类方法将对象关系、空间布局和交互动态编码为结构化的计算制品。例如，ViStruct [125] 将编程语言结构作为视觉结构知识提取的显式接口，使多粒度视觉事件能够通过一致的可执行结构加以表示。FactoredScenes [126] 则将室内环境建模为组合式”房间程序”，通过可复用的对象与关系函数来定义物理上一致的场景布局。在此基础上，PoE-World [127] 将该思路推广至可扩展的符号世界建模，引入了一种组合式框架，融合多个小型程序化专家来表示日益复杂的环境动态。近期系统进一步将结构化环境接口拓展至高保真度的交互世界。Code2World [38] 将图形用户界面（GUI）状态预测重新表述为可渲染的 HTML 生成问题，使环境转换能够通过可执行的渲染代码加以表示和评估。Code2Worlds [139] 则将该框架进一步延伸至四维仿真环境，通过语言到仿真的程序生成，利用物理感知的执行循环来减少环境构建与交互过程中的语义-物理不一致性。
2.3.2. 执行轨迹世界建模（Execution-Trace World Modeling）
执行轨迹世界建模研究智能体如何直接从可执行的交互轨迹中学习环境动态。与仅将代码执行视为最终评估步骤不同，这类方法将运行时转换本身作为环境行为的首要表示。SemCoder [128] 通过训练语言模型对函数行为、语句级执行效果以及输入-输出转换进行推理，从而在静态程序与运行时语义之间架起桥梁。在此视角下，Code World Model（CWM）[37] 直接从程序轨迹中学习预测性的世界模型，使智能体能够通过可执行动态预见未来的环境状态。WorldCoder [36] 进一步引入了一种基于模型的交互框架，智能体在其中以 Python 程序的形式显式地编写并更新可执行的世界模型。相较于将环境知识隐式存储于模型参数中，该方法使智能体能够维护可编辑的计算表示，并在规划与交互过程中对其进行执行、修订和复用。后续工作将这一范式推广至持续性与交互式的世界模型自适应：RWML [129] 将执行轨迹与强化学习相结合，在运行时交互中精化环境动态；AWM [130] 和 WorldMind [131] 则研究如何在任务和知识来源之间对多个可执行世界模型进行对齐、融合与协调。
2.3.3. 基于代码接地的评估环境（Code-Grounded Evaluation Environments）
基于代码接地（grounding）的评估环境以可执行系统作为衡量智能体行为与交互质量的接口。与仅依赖文本输出的静态基准不同，这类环境暴露出智能体可以直接观察和评估的显式运行时状态转换、执行反馈及可验证的交互结果。InterCode [11] 通过将编码任务重新表述为交互式执行环境确立了这一范式：代码作为动作，执行反馈作为观察，沙箱运行时提供接地交互。CRUXEval [132] 进一步通过可执行的输入-输出预测任务评估程序理解能力，而 LiveCodeBench [133] 则引入了持续更新的评估流水线，以评测在不断演化的问题分布下的执行、自我修复和运行时推理能力。SWE-bench [5] 将可执行评估推广至真实世界的软件代码仓库（repository），要求智能体修改大规模代码库，并通过代码仓库级别的单元测试执行而非单纯的文本正确性来评估结果。更广泛地看，AgentBench [12] 证明了可执行交互环境能够在多样化的具身（embodied）及数字化任务中评估推理（reasoning）与决策能力。随后，CRUXEval-X [134]、CoRe [135]、GeoGramBench [140]、CodeGlance [136] 和 Endless Terminals [39] 等基准进一步将这一范式扩展至多语言、多模态和持续交互的评估场景，使运行时交互而非静态答案匹配成为主要的评估接口。
2.3.4. 可验证环境构建（Verifiable Environment Construction）
一个新兴方向将可执行环境视为不仅仅是评估智能体的基准，更是可通过编程方式合成、扩展和验证的 harness 制品。这对长时域（long-horizon）智能体而言尤为重要——harness 不仅需要提供任务提示，还需要提供可运行状态、转换动态、反馈通道以及验证断言（oracle）。SWE-smith [137] 通过从现有代码库构建代码仓库级任务和执行环境，将软件工程智能体的数据规模扩展至更大范围，将软件代码仓库转化为可复现的程序世界，用于智能体训练与评估。EnvScaler [138] 则将这一思路推广至软件工程之外，通过程序化方式合成支持工具交互的环境，并配合场景和基于规则的轨迹验证器。从 harness 的视角来看，这些方法将环境接口本身转变为构建对象：代码不仅规定智能体编辑或执行什么，还规定状态转换、工具功能以及用于判断交互是否成功的验证器。
3. Harness 机制：规划、记忆、工具使用、控制与优化
Harness 机制构成了核心系统层，使基于代码的 harness 智能体在单次生成步骤之外也能保持可靠性。一旦代码进入智能体循环，软件生成便不再仅仅是从提示生成正确程序的问题，而是演变为模型、可变任务状态与人工设计的 harness 基础设施之间的交互过程。模型提供判断：分解目标、选择动作、解读反馈并决定何时修订。可变状态记录代码仓库证据、工作记忆（working memory）、执行轨迹、验证（verification）结果、记忆及关于任务的中间信念。Harness 基础设施暴露工具和执行基底，持久化并压缩状态，通过策略层和权限层约束动作，路由反馈（feedback），并验证每次状态转换是否可接受。从这一角度来看，harness 机制并非孤立的附加模块，而是协调的控制面，将模型决策转化为可执行环境中有界、可观察且可修订的变更。在其基本形式中，代码允许智能体调用现有的可执行接口；进一步地，智能体还可以动态地编写任务专属的可执行接口。这些由智能体编写的制品使 harness 更具自适应性，因为它们允许执行环境围绕当前任务进行重塑。然而，动态编写的代码并不替代更宏观的人工设计 harness 基础设施。可靠性仍依赖于模型侧的判断以及人工设计的策略、沙箱边界、权限层、验证断言、审计日志和人工审核关卡。因此，代码充当可执行媒介存在于 harness 内部，而 harness 则是更大范围的策略治理系统，决定哪些代码可以被执行、信任、持久化、复用或提升至未来的工作流（workflow）中。
在本节中，我们综述代码智能体 harness 机制的五个相互作用的类别。规划（§ 3.1）通过将目标外化为分解、结构约束、搜索轨迹或工作流级编排，组织长时域任务的执行。记忆（memory）与上下文工程（§ 3.2）通过保留工作上下文、检索代码仓库证据、存储
图 4：智能体 harness 机制路线图概览（原文图见 PDF 第 17 页）
可复用经验、支持共享历史，以及将状态卸载至活跃上下文窗口之外，来管理跨长交互的可变状态。工具使用（tool use，§ 3.3）将智能体与受治理的可执行接口相连接，包括 API、代码仓库、终端、沙箱、验证工具以及工作流编排器。通过”计划-执行-验证”循环（Plan-Execute-Verify loop）的 harness 控制（§ 3.4）将反馈引导的调试重新界定为更宏观的控制过程：计划形成预期变更的合约，执行在沙箱化和授权的环境中应用这些合约，验证则使用确定性传感器和人工审核关卡来决定状态应被接受、修订、上报还是回滚。最后，智能体 harness 工程（§ 3.5）研究如何通过深度遥测、进化智能体、基于回放的评估以及受治理的 harness 变异来测量和改进 harness 本身。
3.1. 智能体 Harness 的规划（Planning for Agent Harness）
规划在智能体 harness 中扮演核心角色，原因在于真实世界的软件工程任务很少允许从自然语言意图到正确实现的直接一次性映射。从 harness 的视角来看，规划不仅仅是大语言模型（LLM）的内部推理能力，更是 harness 控制 的一种形式：它构建智能体将意图外化为可执行步骤的方式，调度与代码制品和工具的交互，并随时间调节推理、执行与修订的轨迹。除了生成代码 token，有效的智能体 harness 必须将长时域问题求解组织成一套连贯的行动方案，决定追求哪些中间目标、以何种顺序执行、检查或修改哪些制品，以及当执行反馈揭示错误、缺失依赖或违反约束时如何修正轨迹。这一需求在代码仓库级别的编辑、网页交互、竞技编程和硬件设计中尤为突出，因为在这些场景中智能体必须在大型动作空间、稀疏反馈以及深度相互依赖的子问题上运作。在这类场景中，一个基本挑战在于目标任务的复杂性与无约束智能体执行的有限可靠性之间的矛盾：若缺乏显式规划机制作为 harness 控制，智能体可能过早承诺于脆弱的解路径、忽视潜在依赖，或无法将推理、检索、执行与修订协调为稳定的工作流。
早期以规划为导向的系统主要将规划视为线性分解步骤：模型先生成自然语言的解题大纲，再将其翻译为代码。然而，随着代码智能体被应用于更复杂的环境，规划逐渐从简单的预生成脚手架演化为更丰富的 harness 级控制机制。规划可以通过代码仓库结构或外部知识来接地（grounding），以约束智能体的动作空间；可以通过在多条候选轨迹上进行显式搜索来提升鲁棒性；也可以分布于专业化的智能体角色和反馈循环之间，在系统级协调执行。基于 harness 控制实现的主要位置，我们将代码智能体中现有的规划方法归为四类：线性分解规划、结构接地规划、基于搜索的规划 和 基于编排的规划。
图 5：智能体 harness 规划机制概览（原文图见 PDF 第 18 页）
3.1.1. 线性分解规划（Linear Decomposition Planning）
在这一规划范式中，智能体首先生成单一的显式可执行步骤序列，然后按照此分解方案进行生成 [141, 40, 41, 142, 143]。该范式的轻量级前身是 ReAct [144]：智能体在一条串行轨迹中交替进行思考、动作和观察。在该框架中，每个推理步骤将当前子目标外化并约束下一个动作，从而将轨迹本身转化为一种逐步控制的 harness。这一模式最直接地体现在 Self-Planning [40] 中：模型首先将意图分解为简洁的高层编号步骤，然后在该计划指导下逐步生成代码。Plan-And-Act [145] 通过分离规划器与执行器使这一 harness 更为显式：规划器生成结构化的高层计划，并在新观察到来时反复刷新线性脚手架，使规划策略能够在适应环境反馈的同时保持任务级控制。WebAgent [41] 将这一思路扩展至网页
自动化领域：将用户指令分解为连续的子指令，在当前子目标条件下对任务相关的 HTML 进行摘要，然后从该线性子指令序列合成可执行的 Python 动作。KareCoder [141] 在知识增强的场景中遵循类似的模板：模型首先从外部知识库构建知识感知的逐步提示，再用该提示生成代码，使规划成为问题理解与实现之间的结构化中间层。近期工业实践表明，这种线性脚手架可以从短暂的提示制品提升为持久化的 harness 对象。在长时域编码工作流中，PLAN.md、Implement.md 等文件以及状态日志记录里程碑、验收标准、验证命令和恢复规则，允许智能体跨上下文重置或多轮对话执行（multi-session execution）进行加载、更新、验证和文档化进展 [146, 147]。在这一视角下，规划不再仅仅是内部推理轨迹，而是一个由文件系统支撑的控制对象：它可以被人类审阅、用 Git 进行版本管理、被子智能体（subagent）使用，并作为实现的唯一事实来源。这类方法的主要局限在于，它们通常只承诺于单一的分解轨迹：当初始计划不完整或方向有偏差时，harness 可以提升持久性和可审计性，但对于所选路径之外的探索仍然提供有限支持。
3.1.2. 结构接地规划（Structure-grounded Planning）
在这一研究路线中，智能体不从自由形式的自然语言提示中单独推导其动作序列，而是将规划接地于任务环境的显式结构化表示，例如依赖图、代码仓库图、电路图或知识图谱。这些结构充当自然的 harness 脚手架：它们暴露相关实体，编码依赖关系，并引导子任务应以何种顺序生成、修订或验证。例如，CodePlan [42] 在编辑义务之上构建计划图，并通过依赖分析和变更影响传播推导新步骤。代码仓库理解方法 [148, 149, 150, 148] 则将代码库转化为异构图或富文本代码图，然后利用图集成推理来定位相关实体，并在结构依赖而非扁平文本上下文的基础上对下游生成进行条件化。GraphCodeAgent [151] 用双图 harness 扩展了这一思路：需求关系图（Requirement Relation Graph）捕获自然语言需求间的关系，结构-语义代码图（Structural-Semantic Code Graph）捕获代码仓库依赖。同样的原则也出现在近期智能体原生的代码仓库实践中：架构说明、API 规范和测试指南等文件将项目知识转化为可检查（inspectable）、版本可控的制品，供智能体在行动前查阅 [152, 153, 154]。这将结构接地规划推广至图构建之外：相关结构确定了显式规则、构建命令、目录边界、编码规范和设计约束，从而在程序层面促进一致且稳定的 harness 控制。专业领域遵循相同的模式 [155, 156]：VerilogCoder [156] 将子任务规划接地于任务与电路关系图，使每个子任务都被信号、转换和示例所丰富；而 DomAgent [155] 则使用知识图谱将自上而下的结构化知识与自下而上的示例相结合，用于领域专属的代码生成。总体而言，这些工作表明，结构接地规划通过将项目或领域知识转化为显式的、可检查的 harness 对象来引导智能体的长期行为，从而提升了一致性、依赖感知性和长时域一致性。
3.1.3. 基于搜索的规划（Search-based Planning）
基于搜索的规划在推理时分配计算资源，以系统性地探索、评估并在多条候选解路径中做出选择。与将智能体绑定于单一计划不同，其核心思路是扩展决策空间，并利用反馈来控制哪些备选方案应被继续探索、修订或
放弃。第一组方法 [157, 158] 在思维空间（thought space）中实例化这一 harness：它们不直接编写代码，而是首先在高层观察、策略或推理轨迹上进行分支，以在实现之前增加概念多样性。在这一视角下，更好的规划来自于覆盖更广泛的思路空间，并利用反馈来精化推理本身，而不仅仅是修复最终代码。第二组 [43, 159, 160, 161] 在编码动作的轨迹空间中进行搜索：这些方法将编码建模为在策略选择、实现、调试与修订上的分支过程，并依赖执行信号或学习得到的评论者来决定扩展哪些节点。因此，当智能体能够从次优决策中回溯并比较部分轨迹时，长时域编码质量得以提升。另一研究路线，如 ReLoc [162] 和 SFS [163]，将规划视为代码空间中的搜索：这些方法通过变异、修订或局部优化来迭代地探索邻近程序，以验证反馈或细粒度评分信号为指导。在上述方法之外，近期系统越来越多地将候选计划、补丁、日志、测试和执行轨迹视为持久制品而非临时生成。SWE-Search [164] 将蒙特卡洛树搜索（Monte Carlo Tree Search）与软件工程智能体相结合，以探索替代修复轨迹；CodeTree [43] 则在统一的树中组织策略探索、解生成和精化。更宏观地看，Meta-Harness [13] 将这一思路推升至 harness 级别：通过赋予智能体访问先前源代码、评分和执行轨迹的文件系统权限，在 harness 范围内进行搜索。这些进展表明，基于搜索的规划不仅是一种模型侧的采样策略，也是一个 harness 级别的状态管理问题：运行时必须保留候选项、暴露证据、运行验证器，并决定哪条分支值得进一步计算。
3.1.4. 基于编排的规划（Orchestration-based Planning）
基于编排的规划是一种规划范式，其中核心规划功能通过面向系统级协调的 harness 设计来实现。在这一范式中，harness 治理智能体或模块如何专业化角色、执行阶段、路由反馈并触发验证循环，从而决定在长时域代码生成工作流中下一步应采取哪些动作。第一种常见模式 [50, 51, 52] 是以反馈为中心的编排：系统在不同模块之间分配编码、测试、分析和修复任务，使进展由反复的以执行接地的反馈和自适应升级驱动。在这一组中，规划不是预先存在的制品，而是失败如何被检测、解读并路由至后续动作的涌现属性。第二种模式 [44, 166, 165] 是阶段性工作流编排，将代码生成表述为结构化的软件过程流水线，包括理解、检索或预览、规划或蓝图制定、编码、调试和修复等阶段。这一组方法的主要优势在于将复杂生成分解为具有显式交接规则的可解释阶段，实际的规划能力来自跨阶段控制、候选剪枝以及
迭代精化。第三种模式 [167, 168, 169, 170] 是以控制器为中心的编排：规划嵌入于中间制品的转换以及路由基底本身之中。在这里，系统通过诸如形式化规范流水线、建议阶段（位于定位与修复之间）、类型化中间表示、共享黑板或专业化的规划器-编码器协作等机制组织决策，使下一个计划由脚手架的控制逻辑而非单一文本提示决定。
近期 harness 系统使这一编排视角愈发明确。Anthropic 的长时域 harness 将规划、生成和评估分离为不同角色，利用结构化制品和独立评估来在长会话中维持进展 [15, 171]。Cursor 的大规模自主编码实验同样将规划器-工作器协调作为从聚焦的单智能体任务扩展（scaling）至多个并行智能体协作共享项目的手段 [172]。最通用的表述出现在自然语言智能体 harness（Natural-Language Agent Harnesses）中，其中高层 harness 逻辑（如角色、阶段、合约、适配器、状态约定和失败分类法）以可编辑的自然语言编写，并由智能 Harness 运行时（Intelligent Harness Runtime，IHR）[173] 执行。IHR 在运行时解释这些高层自然语言指令，并在显式合约、预算、工具接口和环境状态的约束下将其转化为受约束的执行步骤。这将基于编排的规划重构为运行时解释问题：计划不仅是一份文档，而是一个可执行的 harness 规范，在模型输出、文件系统状态、工具、验证器和多智能体委派之间进行调解。
讨论： 代码生成的规划可以被理解为 智能体 harness 的核心形式：一个控制层，组织大语言模型（LLM）智能体如何分解任务、将决策接地于程序结构、在推理时探索备选方案，并协调多阶段的软件工程工作流。从这一视角来看，规划是以一个关键问题为核心的一组 harness 机制：如何决定智能体下一步应该做什么，以及如何使这一决策过程在长时域编码任务中保持受约束、可检查（inspectable）和连贯。值得注意的是，代码生成中的规划无法与评估问题截然分离。当前关于规划收益的诸多结论高度依赖于周围的执行条件，包括执行环境、反馈质量、工具访问、轨迹预算，以及基准是否真正考验长程依赖管理而非局部补丁生成。如果执行信号微弱、修订预算不切实际，或基准未能暴露多步协调错误，那么报告的规划增益可能并不反映智能体级问题求解中的真实改进。因此，规划不仅是一个方法设计问题，也是一个智能体与环境之间的 harness 问题。展望未来，核心挑战不在于构建更大的规划器或更长的推理轨迹，而在于设计更可靠的智能体 harness 以支持规划：能够决定何时遵循、修订或放弃计划的自适应承诺机制；能够暴露依赖与进展的结构上有意义的规划状态；使用反馈而不过度消耗计算的高效探索-修订策略；以及能够忠实测量规划质量而非仅看最终通过率的严格长时域评估范式。
3.2. 智能体 Harness 的记忆与上下文工程（Memory and Context Engineering for Agent Harness）
记忆（memory）已成为代码智能体的核心基础设施，这在很大程度上是因为真实世界的软件工程任务本质上是长时域且状态密集的 [174, 175]。与单轮代码补全不同，实际的编码场景要求智能体在多轮交互中维持一系列相互依赖的步骤，例如需求理解、代码定位、证据检索、多文件编辑、测试执行、缺陷修复和回归验证 [176, 177]。这引入了一个根本性的张力：模型有限的上下文窗口与任务持续扩展的中间状态之间的矛盾。从 harness 的视角来看，记忆不仅仅是更大的上下文窗口或向量数据库。
图 6：智能体 harness 的记忆与上下文工程机制概览（原文图见 PDF 第 22 页）
它是一个状态管理层，决定哪些信息应保留在活跃的模型上下文中，哪些信息应被压缩为摘要，以及哪些信息应被卸载至持久的外部存储 [178]。若缺乏有效的记忆机制和上下文管理，智能体在长程推理过程中可能轻易丢失关键线索、在之前已完成的搜索和分析上重复劳动，或在后续修改中破坏早期步骤所建立的局部一致性 [179, 175]。
早期系统在很大程度上依赖提示来保存历史信息，将记忆视为对话历史或非结构化的草稿本。然而，随着代码仓库级别的修复和其他长时域编码任务的出现，仅仅积累自然语言历史越来越难以可靠地支撑复杂的软件工程循环 [180]。因此，记忆正越来越多地作为系统组件被外化，具备可检索、可治理和可溯源的特性。在本小节中，我们根据记忆在软件工程循环中的主要功能角色对代码智能体中的记忆进行分类。在这一视角下，现有方法可以大致归为五类：工作记忆（working memory）、语义记忆（semantic memory）、经验记忆（experiential memory）、长期记忆（long-term memory）以及多智能体（multi-agent）记忆。此外，我们还将讨论上下文压缩与状态卸载这两类横切性的上下文工程机制，它们决定了大型执行制品如何在活跃的模型上下文与持久的任务状态之间流转。代表性工作见表 5。
3.2.1. 工作记忆（Working Memory）
工作记忆支持沿当前编码任务轨迹的状态维护 [181]。其核心关注点不在于保留多少历史，而在于在有限的上下文预算下哪些信息片段对下一步动作最为有用。在代码智能体中，工作记忆通常以结构化提示区域的形式出现，包括状态摘要、失败测试记录、文件列表或关键调用栈信息。其目的是缓解上下文爆炸问题，减少重复定位，并保持正在进行的修复或编辑轨迹的局部一致性 [57, 182, 183, 45]。从 harness 的视角来看，工作记忆是模型与代码环境之间的活跃控制面：它决定智能体在选择下一次工具调用、编辑或验证步骤之前所观察到的内容。SWE-agent [57] 和 RepairAgent [183] 等代表性系统表明，即使在相同的底层模型下，通过不同的工作记忆设计，代码仓库级别的修复性能也可能存在显著差异。
表 5：代码智能体 harness 中具有代表性的记忆与上下文管理机制。
| 方法 | 角色 | 管理状态 | Harness 操作 | 主要用途 |
|---|---|---|---|---|
| SWE-agent [57] | 工作记忆 | 修复轨迹；运行时状态 | 结构化状态追踪 | 在文件、命令和测试中为代码仓库修复提供接地 |
| CodeMem [45] | 工作记忆 | 上下文槽位；编辑状态 | 预算制槽位管理 | 在上下文限制内稳定多步骤编辑 |
| RepairAgent [183] | 工作记忆 | 缺陷证据；工具输出 | 动态提示状态更新 | 在自主循环中传递证据 |
| AutoCodeRover [46] | 语义记忆 | 代码仓库结构；代码证据 | 结构感知检索 | 为代码仓库结构中的定位与补丁生成提供接地 |
| RepoCoder [47] | 语义记忆 | 检索到的仓库上下文；代码片段 | 迭代仓库检索 | 扩展证据以支持上下文感知的代码生成 |
| CodeRAG [187] | 语义记忆 | 仓库知识；代码路径 | 查询；多路径检索与重排序 | 为长上下文代码补全筛选仓库知识 |
| MemGovern [48] | 经验记忆 | 轨迹；反思；评述 | 受控经验回放 | 在过滤噪声的同时复用高质量经验 |
| ExpeL [189] | 经验记忆 | 反思轨迹；习得经验 | 反思回放 | 将反思作为任务解决策略加以复用 |
| MemCoder [190] | 长期记忆 | 提交记录；根因分析；已验证修复 | 结构化记忆；自内化 | 学习仓库特定的意图到代码映射 |
| TALM [191] | 长期记忆 | 任务历史；推理轨迹；已验证代码 | 向量检索；整合 | 复用历史片段以支持树状结构生成 |
| MIRIX [192] | 多智能体记忆 | 跨智能体状态；交互历史 | 跨智能体记忆路由 | 在专业角色之间路由共享记忆 |
| ChatDev [193] | 多智能体记忆 | 对话历史；软件制品 | 阶段级上下文传递 | 在基于角色的阶段间维护上下文 |
| LongCodeZip [194] | 上下文压缩 | 长代码上下文；仓库代码片段 | 粗到细压缩 | 在保留推理线索的同时压缩代码 |
| SWE-Pruner [195] | 上下文压缩 | 交互上下文；周围代码 | 任务感知剪枝 | 在智能体决策前去除无关上下文 |
| SWEZZE [196] | 上下文压缩 | 问题上下文；修复要素 | 轻量级习得压缩 | 提炼出紧凑、聚焦于修复的证据 |
根据交互状态和执行反馈（feedback）的组织方式，不同方案在此基础上有所差异。CodeMem [45] 同样将上下文视为受管理的资源，通过预算制记忆槽位来稳定多步骤编辑。
3.2.2. 语义记忆（Semantic Memory）
语义记忆（semantic memory）为当前编码过程提供与任务相关的外部证据 [184, 175]。在代码智能体的场景中，此类证据通常与代码仓库（repository）相关且具有程序结构，包括类定义、函数实现、调用关系、配置文件、文档、问题描述、依赖元数据以及历史实现模式。因此，语义记忆将外部代码库转化为一个可查询的证据空间，harness 可从中检索相关内容并注入到活跃上下文（context）中 [46, 185, 186, 187, 188]。AutoCodeRover [46] 和 RepoCoder [47] 等代表性工作表明，代码仓库级编码任务不仅需要检索更多内容，更需要检索与程序结构对齐的证据。基于抽象语法树（AST）的结构化分块、迭代查询改写，以及以当前定位线索为条件的检索策略，可以大幅提升检索上下文对下游生成的实用性。从这一意义上看，语义记忆将代码库转化为当前决策过程的结构化证据层。
3.2.3. 经验记忆（Experiential Memory）
随着代码智能体从单任务完成向持续修复与跨项目泛化方向演进，经验记忆（experiential memory）或情节记忆（episodic memory）受到了越来越多的关注 [197, 198]。与维护当前轨迹的工作记忆（working memory）或检索仓库证据的语义记忆不同，经验记忆捕获跨任务积累的可复用经验，例如修复轨迹、失败案例、调试记录以及更高层次的策略模式 [189, 199, 200]。其核心价值在于实现跨任务迁移。通过经验卡片、反思缓冲区以及记录与回放流水线等机制，系统可以将过去成功或失败的调试过程转化为可供未来问题求解复用的单元 [199, 48, 201]。MemGovern [48] 等工作进一步表明，存储经验的质量比其规模更为重要：未经治理的历史记录可能引入语义噪声、错误传播和错误检索，而经过筛选与质量控制的经验记忆则更有可能成为仓库级修复的有效资产。
3.2.4. 长期记忆（Long-Term Memory）
当编码轨迹变得更长时，工作记忆和语义记忆单独使用已难以满足需求——系统还必须应对记忆增长、压缩导致的证据失真以及长期漂移等挑战。这使得长期记忆（long-term memory）的检索规划与记忆管控成为日益重要的研究方向 [202, 203, 204, 205, 206]。研究焦点因此从记忆容量转向记忆治理：何时写入、何时压缩、何时检索，以及如何避免污染。MemGPT [207] 和 MemoryOS [208] 等代表性系统将讨论从存储什么推进到何时写入、何时压缩、何时检索以及如何避免污染。近期以代码为核心的研究进一步将这一思路植根于软件工程工作流（workflow）中。MemCoder [190] 利用结构化的历史提交和经人工验证的解决方案作为持久化记忆，使仓库特定的经验得以随时间累积。TALM [191] 将长期记忆整合进多智能体代码生成，通过检索历史问题—解决方案轨迹并整合重叠记忆来控制冗余。这些工作共同表明，对于代码智能体而言，长期记忆不应仅仅是历史的简单堆积，而应以紧凑、可控的形式保存经验证且可复用的知识。否则，记忆可能从长周期软件工程的资源演变为放大噪声、引发陈旧与错误的负担。
3.2.5. 多智能体记忆（Multi-Agent Memory）
多智能体记忆（multi-agent memory）将状态管理从单个智能体扩展至共享的 harness。从系统视角看，代码生成中的记忆具有强烈的协作维度 [209, 210]。在多智能体框架中，记忆不仅是独立状态的容器，也是跨专业角色进行信息共享、意图传递和一致性维护的媒介 [211]。AgentCoder [50]、MapCoder [44]、MIRIX [192]、ChatDev [193] 和 G-Memory [211] 等代表性工作展示了记忆如何支撑多智能体规划（planning）、生成与轨迹协调。在这种场景下，核心挑战不再只是检索相关内容，而是控制共享粒度、防止信息泛滥，并支持高层决策与细粒度执行轨迹之间的双向访问 [210]。因此，多智能体代码生成中的记忆日益呈现出共享黑板或协作状态图的形态，而非单纯的个体存储单元 [212, 213]。
3.2.6. 上下文压缩与状态卸载（Context Compaction and State Offloading）
上下文压缩（context compaction）与状态卸载（state offloading）是代码智能体 harness 中跨越各记忆类别的上下文工程机制 [214]。其目标不在于定义另一种记忆类型，而在于管控活跃模型上下文（context）与持久任务状态之间的边界。长周期软件工程工作流持续生成大量制品，例如构建日志、执行轨迹、仓库差异、测试输出和中间规划文档。将这些制品直接放入提示词会迅速撑爆上下文窗口、放大噪声，并遮蔽与决策相关的证据。harness 因此必须决定哪些观测应保留在活跃上下文中、哪些应压缩为简洁摘要、哪些应卸载至带有可检索句柄的外部存储 [178]。上下文压缩将漫长的交互历史和大量工具输出压缩为结构化、可溯源的摘要。例如，失败的测试报告可被精简为失败测试名称、关键堆栈帧、可疑文件及完整日志链接 [196, 215, 194, 195]。状态卸载通过将全保真制品保留在活跃窗口之外（例如文件、数据库、追踪存储，或 MCP 风格服务器等协议式资源接口）来补充这一过程。智能体收到的是紧凑摘要和资源标识符，而非原始日志或轨迹。通过将与决策相关的上下文与持久的全保真证据分离，上下文压缩与状态卸载使记忆更具可扩展性（scalable）、可审计性，并与执行时验证（verification）相兼容。
讨论： 在代码即智能体 harness 系统中，记忆可被理解为连接上下文管理、仓库证据检索、经验迁移、长期记忆控制与多智能体同步的统一状态管理层。它既不是单一数据结构，也不是放大的上下文窗口，更不仅仅是一个向量数据库，而是协调任务相关状态在长周期软件工程工作流中如何存放与复用的机制。工作记忆（working memory）使下一步行动保持接地；语义记忆（semantic memory）暴露仓库证据；经验记忆（experiential memory）支持跨任务迁移；长期记忆（long-term memory）保存已验证的知识；多智能体记忆（multi-agent memory）则跨角色同步共享状态。上下文压缩与状态卸载进一步将这一层延伸，通过将与决策相关的活跃上下文与持久的全保真制品分离，使记忆更具可扩展性、可审计性，并与执行时验证相兼容。重要的是，代码智能体中的记忆研究无法与评估可靠性相割裂。许多关于记忆收益的结论依赖于评估流水线的质量 [216, 217]：若测试不足、日志解析存在缺陷，或基准测试受到记忆化和数据污染影响，则报告的改进可能无法反映稳健的长周期行为。展望未来，核心挑战不在于简单地扩大记忆容量，而在于构建更高质量的写入门控机制、结构对齐的检索键、保留溯源信息的压缩机制、可靠的状态卸载协议，以及能够衡量记忆是否真正帮助智能体在长轨迹中保持接地、一致与可验证的严格评估范式。
3.3. 智能体 Harness 的工具使用（Tool Use for Agent Harness）
工具使用（tool use）是代码智能体 harness 的行动与观测层。一旦代码被置于智能体循环中，模型不仅需要生成文本，还需要搜索代码仓库、编辑代码、执行测试、调用 API、查询文档，并验证中间结果 [218, 219]。工具因此扩展了智能体的行动空间，同时暴露外部反馈（feedback）信号，使 harness 具有可执行性（executable）和可检查性（inspectable）。从代码即智能体 harness 的视角来看，工具使用并非代码生成的辅助能力，而是模型意图与外部系统之间受管控的接口。一个可靠的 harness 必须决定哪些工具可用、其模式（schema）如何暴露、每个工具获得哪些权限、执行在何处发生、结果如何净化或压缩，以及何时需要人工审批以防范风险操作。近年来，智能体 SDK 和软件智能体平台通过将工具、会话、防护栏（guardrails）、交接机制、工作空间和执行环境打包为可复用的 harness 组件，使这一转变愈加明显 [58, 220, 221]。与此同时，包括容器化或微虚拟机（microVM）工作空间在内的沙盒执行环境，将智能体行动与宿主系统隔离，使代码执行更具可复现性和可审计性 [22, 222, 223]。
图 7：智能体 harness 工具使用机制概览（原文图见 PDF 第 26 页）
此 harness 层视角还凸显了工具生命周期控制（tool lifecycle control）的重要性。在工具执行之前，harness 可施加权限检查、策略规则、参数验证或人工介入门控。执行之后，harness 可净化输出、汇总大型日志、将追踪卸载至持久存储、更新记忆或触发验证工具。生命周期钩子使这些控制点变得显式，从而将工具使用从模型选择的原始行动转变为智能体执行循环中的受监控状态转换。
现有代码智能体工具使用工作因此可按工具所服务的主要 harness 功能加以组织，分为四类：(1) 面向功能的工具使用（function-oriented tool use），(2) 面向环境交互的工具使用（environment-interaction tool use），(3) 验证驱动的工具使用（verification-driven tool use），以及 (4) 工作流编排的工具使用（workflow-orchestration tool use）。面向功能的工具将智能体接地于 API、库和外部文档；面向环境交互的工具允许智能体在代码仓库、终端、IDE、浏览器和沙盒中行动；验证驱动的工具通过测试、lint 检查器、类型检查器、静态分析器和运行时错误提供确定性反馈（feedback）；工作流编排工具则将多种工具、角色、记忆更新与生命周期策略协调为可靠的长周期执行流程。具有代表性的工作汇总于表 6。
3.3.1. 面向功能的工具使用（Function-Oriented Tool Use）
这一研究方向主要使用工具来填补模型编程知识的空白，尤其是在 API、库、文档和外部代码实用工具方面 [19, 224, 225, 227, 228, 229]。ToolCoder [19] 以一个清晰的瓶颈为出发点：代码模型常常幻化（hallucinate）出不存在的 API，或在训练覆盖稀疏的公私库上选择不当的函数。为此，它将 API 搜索工具集成进代码生成过程，并训练模型判断何时调用工具以及如何从检索结果中筛选 API。其核心贡献因此不在于更好的语法生成，而在于更好的知识获取与 API 接地（grounding）。更广泛而言，面向检索的方法降低了对参数化记忆的依赖，使代码生成对长尾 API、私有库和持续演进的软件生态系统 [225, 230] 更具适应性。当主要瓶颈在于模型缺乏对应使用哪个函数、API 或库构造的可靠知识时，这类方法最为有效。因此，核心设计挑战在于查询构造、结果筛选、证据压缩，以及将检索到的知识稳健注入下游生成。这些智能体方法特别适用于面向 API 的生成、库迁移和私有 SDK
表 6：代码智能体 harness 中具有代表性的工具使用机制。
| 方法 | 角色 | 工具边界 | Harness 操作 | 主要用途 |
|---|---|---|---|---|
| ToolCoder [19] | 面向功能 | API 搜索工具 | 通过触发预测选择 API | 将生成接地于检索到的 API |
| CodeQA [224] | 面向功能 | API/文档查询工具 | 工具增强的 API 质量保证 | 检索 API 证据以辅助编码 |
| RAG-for-Code [225] | 面向功能 | 代码仓库、文档、API | 检索增强上下文 | 面向长尾库的知识积累 |
| CodeAgent [185] | 面向环境交互 | 仓库文件、测试 | 仓库导航、编辑、验证 | 通过环境交互实现仓库级编码 |
| SWE-agent [57] | 面向环境交互 | Shell、编辑器、仓库、测试 | 智能体—计算机接口循环 | 通过 shell 命令解决 GitHub 问题 |
| AgentCoder [50] | 验证驱动 | 测试生成 | 程序员—测试员—执行器循环 | 通过生成测试精炼代码 |
| VeriGuard [226] | 验证驱动 | 执行、测试、验证器 | 验证器引导的工具循环 | 通过验证对代码进行门控和修复 |
| ToolNet [49] | 工作流编排 | API、工具、执行 | 习得多工具策略路由 | 跨工作流路由工具调用 |
| MapCoder [44] | 工作流编排 | 编码智能体 | 多智能体工具支持的工作流 | 协调规划、生成与调试 |
| OpenHands [58] | 工作流编排 | 工作空间、终端、浏览器、文件、运行时 | 统一软件智能体工作空间 | 通过可复用接口完成长周期任务 |
但单纯的检索往往不足以应对需要跨文件理解与推理（reasoning）、运行时调试或仓库范围依赖分析的任务。
3.3.2. 面向环境交互的工具使用（Environment-Interaction Tool Use）
与面向功能的工具不同，面向环境交互的方法将工具视为智能体在软件工程环境中行动的接口 [231, 232, 233, 234]。其核心问题不再只是获取缺失的函数，而是在代码仓库、开发制品和执行环境中有效操作。CodeAgent [185] 表明，现实中的仓库级代码生成并非简单地从提示词中补全一个函数，模型必须定位相关文件、理解依赖关系、查阅文档、实施修改，并通过测试验证结果。为支持这一过程，CodeAgent 集成了编程工具，以及用于信息检索、代码符号导航、代码实现和在真实仓库上进行测试交互的智能体策略。SWE-agent [57] 将这一思路进一步延伸，通过形式化智能体—计算机接口（agent-computer interface），使 shell 命令、文件编辑和测试执行成为主要交互通道。RepairAgent [183] 同样为智能体配备了面向修复的专用工具，用于读取代码、搜索修复要素、应用补丁和运行测试。这些方法共同勾勒出面向环境交互工具使用的核心轨迹，对仓库级生成、问题解决和开放式软件工程任务尤为重要。
3.3.3. 验证驱动的工具使用（Verification-Driven Tool Use）
第三类工作主要将工具用于生成后的验证（verification）和迭代改进。验证驱动的工具使用将外部工具视为 harness 的确定性传感器。与面向功能和面向环境交互的工具相比，这类方法不强调外部检索或广泛的仓库导航，而是将测试、执行结果、编译器错误、运行时轨迹、类型检查器、静态分析器以及验证器反馈（feedback）作为提升代码质量的主要信号 [226, 235, 236, 237]。
AgentCoder [50] 以程序员智能体、测试设计智能体和测试执行智能体构成闭环，实现代码生成、测试构建、执行和精炼的完整循环。在这一范式中，工具的核心角色是验证而非检索。从代码即智能体 harness 的视角来看，验证工具使智能体的进展具有可检查性（inspectable）：测试失败、堆栈轨迹、覆盖率缺口、类型错误和静态分析警告成为更新工作记忆（working memory）并引导下一步行动的结构化观测。关键的设计问题在于如何将这些观测路由回循环 [226]。由于原始日志可能过长或对活跃上下文过于嘈杂，harness 应解析、汇总并卸载验证轨迹，同时保留用于审计和回放的全保真制品。
3.3.4. 工作流编排的工具使用（Workflow-Orchestration Tool Use）
工作流编排工具使用关注如何将多种工具、角色和控制策略组织为连贯的智能体工作流（workflow）[238, 239, 240, 241]。在长周期软件任务中，智能体可能需要多次循环完成以下过程：检索证据、定位缺陷、修改文件、运行测试、检查失败、更新记忆、请求审批。挑战不在于简单地添加更多工具，而在于决定何时调用每个工具、授予何种权限、在何种条件下调用，以及其结果应如何更新 harness 状态 [49]。近年来的智能体 SDK 和软件智能体平台通过将带类型的工具模式（schema）、会话状态、工作空间、防护栏（guardrails）、交接机制、追踪和人工审查机制打包为可复用的 harness 组件，使编排层变得显式。生命周期钩子进一步细化了这一边界：前置钩子可验证参数、执行权限策略或阻断风险命令，后置钩子可净化输出、压缩日志、更新记忆或触发后续验证。MapCoder [44] 等代表性系统通过将智能体分配到示例召回、规划、代码生成和调试等任务，将复杂编码问题分解为协调的子问题，体现了工作流编排的思路。CodeAgent [185] 同样研究了工具调用在仓库级工作流中应如何调度与结构化。这一类别对长周期代码智能体尤为重要——在此类场景中，现实的软件任务需要在显式控制策略下完成需求分解、上下文选择、候选探索、基于执行的验证以及最终修复 [49, 242]。
讨论：代码智能体中的工具使用已从孤立的 API 检索演进为涵盖行动、观测、验证和治理的完整 harness 机制。面向功能的工具将实现选择接地于外部知识；面向环境交互的工具允许智能体在代码仓库和执行环境中行动；验证驱动的工具提供确定性反馈（feedback）；工作流编排工具则通过 SDK、沙盒、防护栏和生命周期钩子协调上述能力。核心挑战已不再是模型能否调用工具，而是 harness 能否使工具使用安全、可审计，并适用于长周期执行。未来的代码智能体 harness 应支持带类型的工具模式（schema）、权限感知调用、沙盒执行、生命周期钩子、结果净化、上下文压缩、状态卸载以及可复现的追踪。这些机制能够确保工具在扩展智能体行动空间的同时，不牺牲可靠性、安全性或可验证性（verifiability）。
3.4. 通过规划—执行—验证循环实现的 Harness 控制（Harness Control through the Plan, Execute, and Verify Loop）
代码即 harness 系统需要一个控制循环，将模型意图转化为有边界、可观测、可修订的状态转换。本小节将这一循环框架化为规划—执行—验证（Plan–Execute–Verify，PEV）循环：harness 首先将预期变更及其验证标准外化，然后在沙盒化的权限受控环境中执行变更，最后通过确定性传感器和人工审查门控验证结果状态。这一框架将规划（planning）、执行、调试与验证（verification）统一为单一 harness 层级控制过程的各个部分。
图 8：通过 PEV 循环实现的 harness 控制概览（原文图见 PDF 第 29 页）
3.4.1. 从调试到 Harness 层级控制（From Debugging to Harness-Level Control）
前述各小节将规划（planning）描述为轨迹控制，将记忆（memory）描述为状态管理，将工具使用描述为受管控的行动接口。反馈（feedback）引导的调试将这些机制连接为闭环：规划指定预期变更，记忆保留相关证据，工具执行并检查行动，验证信号决定智能体是否应继续、修订或停止。随着以代码为核心的智能体从单轮生成迈向仓库级软件工作，调试因此更应被理解为对可执行程序状态的控制，而非事后的纠错阶段。生成的程序可能因语法错误、运行时异常、输出不正确、边界情况处理不完整、不安全操作或违反项目特定规范而失败，这使得单次生成往往不足够 [243]。近期系统通过编译器、运行时、测试、静态分析器、人工审查和辅助智能体的反馈（feedback）来修订代码 [244, 245, 246, 23]。从 harness 视角来看，这一过程可重新框架化为规划—执行—验证（PEV）循环：智能体将预期轨迹外化，在受控环境中执行有边界的行动，并在进行下一次状态转换前验证结果状态。围绕智能体 harness 构建的软件工程生态系统也印证了这一视角：近期的整理资源将编排、工作状态、执行基底、评估 harness、可观测性和治理界定为可分离的 harness 层，而非偶然的实现细节 [247, 248, 249, 25]。
在这一视角下，harness 充当控制论调控器（cybernetic governor）：一个观测智能体行动效果并调节后续状态转换的控制层。它不仅仅是将错误消息转发给模型，而是通过 lint 检查器、解析器、编译器、类型检查器、单元测试、集成测试、静态分析器、模糊测试器、运行时监视器和持续集成（CI）流水线等确定性传感器观测代码仓库和执行环境。这些传感器将编码轨迹转化为可检查的信号，包括通过/失败结果、诊断信息、失败轨迹、覆盖率缺口、安全警告、资源限制以及策略违规。随后，harness 可以决定是继续执行、修订补丁、请求更多上下文（context）、将任务路由至另一模块、降低权限，还是上报至人工审查员。表 7 汇总了这一控制面；本小节的其余部分将沿循环流程依次介绍：从合约形成，到沙盒化状态转换，再到确定性验证（verification）与证据接地修复。
表 7：PEV 循环 harness 控制的代表性方法与系统。
| 方法 | PEV 角色 | 核心机制 | 信号与门控 |
|---|---|---|---|
| CodePlan [42] | 规划，结构化 | 依赖规划图 | 仓库链接、评述 |
| MapCoder [44] | 规划，编排 | 地图—代码—测试阶段 | 交接、测试、失败 |
| OpenHands [250] | 完整 PEV harness | 有状态编辑—执行工作空间 | 差异、日志、测试、审批 |
| SWE-agent [57] | 执行，命令行界面 | 可回放的 shell 接口 | 命令、补丁、测试 |
| Daytona [251] | 执行，云沙盒 | 隔离的开发工作空间 | 文件、限制、快照 |
| E2B [252] | 执行，代码浏览器沙盒 | 云端代码浏览器沙盒 | 标准输出、限制、UI 状态 |
| Self-Debugging [243] | 验证，自调试 | 解释引导的修复 | 错误、测试 |
| Reflexion [244] | 验证，反思记忆 | 语言反馈（feedback）记忆 | 结果、评述 |
| Debug Like a Human [245] | 验证，逐步调试 | 运行时逐步检查 | 轨迹、变量、断言 |
| Iterative Refinement [246] | 验证，规划—验证反馈 | 项目上下文修复 | 编译器诊断 |
| QualityFlow [253] | 验证，质量门控 | 质量反馈路由 | 测试、成功、停止条件 |
| AgentCoder [50] | 验证，多智能体修复 | 程序员—测试员—执行器循环 | 测试、失败、评述 |
| AutoSafeCoder [52] | 验证，安全传感器 | 静态检查、模糊测试 | 告警、轨迹、测试 |
| VeriGuard [226] | 验证，经过验证的生成 | 验证器防护层 | 证明、测试、告警 |
| LiteLLM [254] | 权限网关 | 代理策略路由 | 审批、拒绝、成本日志 |
3.4.2. 规划作为合约形成（Planning as Contract Formation）
规划阶段将用户请求转化为下一次状态转换的显式合约。一个健壮的规划不仅分解请求的实现步骤，还识别相关文件、预期不变式、验证命令、回滚点以及高风险操作。这使规划成为 harness 制品，而非未被观测的推理（reasoning）轨迹。在仓库级任务中，这类制品通过指定哪些组件可以被读取、哪些文件可以被编辑，以及在完成前必须满足哪些验证标准，来约束后续行动空间 [40, 42, 44]。仓库本地指令与工具协议进一步强化了这一合约层：AGENTS.md 风格的指导文档、MCP 服务器注册表、带类型的工具模式（schema）、适配器和协议网关，使可用行动在执行前便可检查，而非在执行过程中被机会性地发现 [255, 256, 257, 258, 259, 260, 261, 262]。PEV 框架还明确了为何规划与调试不应相互割裂：验证失败会更新规划，而规划决定了哪些验证证据是有意义的。
3.4.3. 沙盒执行与权限受控状态转换（Sandboxed Execution and Permissioned State Transition）
执行阶段将规划实现为有边界且可观测的状态转换。沙盒环境是这一循环的操作基底：它提供隔离的文件系统、依赖状态、shell、语言运行时、浏览器或 IDE 接口，以及智能体生成的行动可以运行而不直接危及宿主系统的资源边界 [263, 22]。当前执行基底的研究可以功能集群来理解，而非视为无差别的目录。编码沙盒暴露文件系统、Git 操作、shell、包管理器和代码执行后端 [251, 252, 264, 265, 266, 250]；计算机使用基底增加了浏览器、桌面、语言服务器协议（LSP）或 IDE 状态 [267, 268, 269, 270, 271]；而持久运行时则强调微虚拟机（microVM）或 WebAssembly（WASM）隔离、快照、热池、可恢复会话、基准测试环境以及始终在线的操作上下文（context）[272, 273, 274, 275, 276, 277, 278]。沙盒还提升了可复现性，因为 harness 可以在可比条件下重放相同的补丁、命令、随机种子、依赖锁文件或测试配置。若缺少这一稳定的基底，验证信号便会变得难以解释，且故障可能反映的是环境漂移而非程序缺陷 [250, 217, 279]。
执行还必须经过权限管控。多层级模型将低风险的观察操作与高风险的行动操作区分开来：只读层支持代码仓库（repository）浏览、检索、静态检查和日志分析；沙箱（sandbox）编辑层支持在隔离工作空间内进行本地补丁、测试执行和临时依赖安装；完全访问层涵盖网络访问、凭证管理、部署命令、包发布、破坏性文件系统操作以及 Git 历史变更。最终层的操作应由强制性的人机协作（Human-In-The-Loop，HITL）门控机制把守，因为其后果可能超出沙箱范围。近期的软件智能体系统和 harness 工程（harness engineering）工作正越来越多地通过显式工具、会话、策略、审批提示和审计日志来暴露这些控制点 [280, 250, 281, 178, 282, 283]。网关与策略层随后提供生产环境的对应机制：用于模型路由、工具注册、代理级日志、集中式护栏、安全自动化和可证伪审批证据的系统，将治理能力延伸至提示词本身之外 [254, 284, 285, 262, 286, 287, 288, 289, 290, 291]。
3.4.4. 通过确定性传感器实现验证（Verification through Deterministic Sensors）
验证（verification）阶段负责关闭循环，并在必要时通过将新状态与显式约束进行比较来重新开启循环。编译与静态分析反馈（feedback）在完整执行之前提供低成本的传感信号，包括解析器诊断、类型错误、lint 警告和安全告警 [246, 292, 293]。运行时信号则暴露仅在具体执行路径上才会出现的故障，例如异常、断言失败、无效 API 调用、资源耗尽和超时 [294, 295, 245]。基于测试的反馈进一步评估观察到的行为是否满足预期规范，使用的手段包括单元测试、集成测试、回归测试、模糊测试（fuzzing）或针对特定基准的评估器 [243, 296, 297, 298]。评估 harness 将这一思路从单条测试命令扩展到可重复的任务分布：它们将评估器逻辑、模拟钩子、红队用例或强化学习风格的环境编码进来，从而能够在受控条件下对不同 harness 变体进行比较 [299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309]。与自然语言批评相比，这些传感器具有确定性，或至少具有足够的可复现性，可作为控制信号使用。人工或智能体批评在故障证据稀少时仍有价值，但在受治理的 PEV 循环中，它们应当对传感器输出加以诠释，而非取而代之 [244, 310, 54]。
验证同样为修复、反思和终止提供证据，因此这些活动被视为验证阶段的结果，而非独立的阶段。当某项检查失败时，相同的传感器证据可以决定 harness 应要求模型诊断故障、检索缺失上下文、生成局部补丁、将任务路由至测试或安全智能体，还是放弃当前分支。自我反思机制有助于将原始诊断信息转化为可操作的假设，例如故障是否来源于错误的控制流、遗漏的边界情况、对 API 的误解，或测试不充分 [311, 166]。然而，反思只有在始终以可执行证据为基础时才是可靠的。AgentCoder、AutoSafeCoder 和 QualityFlow 等系统通过将智能体批评与独立执行、静态分析、模糊测试或测试质量门控相结合，体现了这一原则 [50, 52, 253]。终止同样应由验证而非模型置信度来决定：当所需检查全部通过、额外尝试不再改善状态、风险层级发生变化，或需要人工审查时，循环即可停止。
讨论： 将迭代调试重新框架为 PEV 循环，强调可靠性来自受治理的状态转换，而非仅仅来自更好的修复提示。规划（planning）将预期变更和风险假设外化；执行在沙箱化和经过权限管控的环境中应用这些假设；验证使用确定性传感器判断状态是否可接受；而 HITL 门控则在行动空间越过安全边界时保留问责能力。这一框架将静态分析、运行时错误、测试、批评、
图 9：harness 工程用于自适应 harness 优化的总览图（原文图见 PDF 第 32 页）
自我反思和人工审查统一为调节智能体轨迹的控制论 harness 的组成部分，该 harness 基于可执行的程序状态进行调节。
3.5. 面向自适应 harness 优化的智能体 harness 工程（Agentic Harness Engineering for Adaptive Harness Optimization）
智能体 harness 工程（Agentic Harness Engineering，AHE）命名的是一个 harness 层面的设计问题：如何度量和修订将语言模型转化为编程智能体的软件基底。提示工程改变的是指令，上下文工程改变的是向模型呈现的证据，而 AHE 则将运行环境本身作为分析对象，涵盖工具模式（tool schemas）、规划制品（planning artifacts）、记忆（memory）策略、检索策略、沙箱配置、验证传感器、权限层级、路由规则、多智能体（multi-agent）工作流（workflow）以及人工审查门控 [281, 178]。这一视角的价值在于：编程智能体中许多观察到的故障源于上下文缺失、工具接口脆弱、验证器薄弱、token 成本过高、重试策略不当或权限边界不匹配，而非模型生成本身的问题。
现有工作可归纳为三条互补的研究路线。AutoHarness 研究代码 harness 的自动合成 [14]；Meta-Harness 将 harness 设计形式化为面向模型的基础设施的优化问题 [13]；以可观测性（observability）为驱动的 AHE 则强调对智能体循环在哪个环节失败以及哪个 harness 组件应当调整进行遥测（telemetry）丰富的诊断 [281]。关于反思式提示演化、自进化工作流以及实时软件工程智能体的相关工作支持着同一系统观：改变模型外围的脚手架可以在不重新训练基础模型的情况下改变智能体行为 [18, 312, 182]。OpenAI、Anthropic 和 LangChain 的工程指南汇聚于同一实践结论：可靠的智能体需要显式的 harness 循环、工具契约、轨迹回放、评估套件、上下文预算和受控执行边界 [248, 249, 313, 314, 28]。
3.5.1. 深度遥测作为优化基底（Deep Telemetry as the Optimization Substrate）
AHE 的核心基底是深度遥测（deep telemetry）：将模型决策、harness 行动、环境状态与结果相关联的结构化轨迹。浅层日志可能仅记录最终答案或通过/失败结果，而深度遥测以更丰富的细节记录决策过程：提示词与检索到的上下文、token 用量与成本、模型/工具延迟、工具参数、权限请求、编辑的文件、沙箱快照、命令输出、测试结果、堆栈追踪、lint 警告、分支决策、被拒绝的备选方案、人工干预以及最终
任务结果。在以代码为中心的场景中，这些轨迹尤为宝贵，因为程序执行本身已通过日志、测试、差异（diffs）和运行时行为暴露状态转换 [128, 96, 37]。在生产系统中，这一角色越来越多地由记录轨迹、指标、提示词、模型流量、评估结果和成本信号的可观测性与可靠性技术栈承担 [315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327]。因此，评估、可观测性和治理系统提供了互补的遥测渠道：评估器暴露任务层级的回归，追踪技术栈暴露轨迹层级的成因，策略网关暴露违反边界的行为，这些都可以被进化智能体（Evolution Agent）转化为 harness 修订。
遥测将 harness 修订从零散的调试转变为比较式诊断。Token 成本轨迹揭示检索或反思阶段在不改善验证结果的情况下消耗预算的情形。决策树轨迹显示智能体在何处反复选择无效工具、编辑无关文件，或在失败策略之间来回循环。故障轨迹将缺失依赖、测试薄弱、幻觉 API、不稳定的沙箱、过于宽松的工具调用或过早终止等重复模式归类成簇。由于这些信号与具体制品相关联，可以跨 harness 版本进行回放和比较，从而能够评估某项变更究竟是在提升可靠性，还是仅仅改变了表面行为 [216, 217]。
3.5.2. 进化智能体（The Evolution Agent）
进化智能体（Evolution Agent） 是一种元层级智能体，它利用深度遥测来提出、评估和推广针对 harness 组件的修订。与任务智能体（task agent）编辑目标代码仓库不同，进化智能体编辑的是后续任务智能体的运行条件。其输入是一组轨迹语料；其输出可能是修订后的提示模板、检索策略、更精确的工具模式（tool schema）、新增的验证器、变更的权限规则、工作流拓扑调整或新的回归测试。这一角色与自进化多智能体系统密切相关——在那些系统中，专属智能体检查执行日志、将故障归因于工作流组件，并更新协作结构 [328, 329]。在 harness 场景中，同一思路从多智能体拓扑推广到智能体运行时的整个控制面。
典型的进化智能体循环包含五个阶段。首先，它通过从 PEV 执行中收集遥测数据来观察（observes）轨迹。其次，它通过将成本、延迟、无效行动、测试失败或权限拒绝归因于具体的 harness 组件来诊断（diagnoses）故障模式。第三，它提出（proposes）候选修订，例如重写工具描述、修改上下文打包规则、添加 linter、调整重试限制或在高风险命令前插入 HITL 门控。第四，它在保留任务或回放轨迹上使用确定性传感器和回归测试评估（evaluates）修订后的 harness。最后，它推广（promotes）仅那些在不损害已解决用例的前提下改善可靠性、成本或安全性的变更。这使 AHE 与 PEV 循环处于同一工程规范之内：提出的变更必须被执行、验证，并在采纳前形成审计记录。
3.5.3. 受治理的 harness 变更（Governed Harness Mutation）
AHE 不应与无约束的自我修改相混淆。由于进化智能体修改的是控制后续任务智能体的 harness，其行动比普通代码修复需要更强的治理。候选 harness 变更应在沙箱中评估，与固定回归套件进行比对，并记录可审计的变更理由。影响权限边界、网络访问、凭证处理、部署行为或人工审查要求的变更，应在激活前获得 HITL 批准。从这个意义上说，进化智能体本身也受制于 PEV 循环：它规划一次 harness 变更，在隔离的评估环境中执行该变更，通过遥测和回归测试验证结果，并将高风险变更上报至人工审查。
讨论： 智能体 harness 工程将代码即 harness 的视角从运行智能体扩展到分析
| 方法 | 类别 | 遥测 | 修订目标 |
|---|---|---|---|
| AutoHarness [14] | Harness 合成 | 故障、测试夹具、断言 | Harness 代码和测试 |
| Meta-Harness [13] | Harness 搜索 | 代码、分数、轨迹 | 提示词、工具、脚本 |
| AHE [281] | 遥测驱动优化 | 成本、决策、延迟、故障 | 上下文、工具、验证器 |
| GEPA [18] | 反思式提示演化 | 分数、反馈、批评 | 提示词和指令 |
| EvoMAC [328] | 工作流拓扑演化 | 切换、空闲角色、循环 | 智能体角色和图 |
| SEW [312] | 自进化工作流 | 工作流分数、故障 | 阶段顺序和角色 |
| Live-SWE [182] | 在线智能体演化 | 实时问题轨迹 | 策略、工具、记忆 |
| GroundedTTA [232] | 测试时自适应 | 状态-行动证据 | 自适应规则 |
| RLEF [104] | 执行反馈学习 | 执行奖励、故障 | 反馈奖励信号 |
| DeepEval [300] | 评估 harness | 场景和指标轨迹 | 回归套件、门控 |
| FeedbackEval [23] | 修复评估基准 | 反馈任务分数 | 故障分类和评估集 |
| Langfuse [315] | 可观测性平台 | Span、成本、延迟、评估 | 仪表板和回放 |
| OpenLLMetry [321] | 轨迹插桩 | OpenTelemetry span、调用 | Harness 插桩 |
| Promptfoo [299] | 评估 harness | 分数、回归、故障 | 评估门控和红队测试 |
| LiteLLM [254] | 网关治理 | 路由、预算、故障 | 预算、回退、层级 |
表 8：具有遥测驱动修订目标的智能体 harness 工程代表性方法。
运行它们的基础设施。深度遥测为在提示词、工具、记忆（memory）、沙箱、验证器、权限和工作流中定位故障提供证据。进化智能体利用这些证据来提出和评估 harness 变更，将 harness 设计转变为一个由验证和人工审批治理的迭代、可度量的工程过程。
4. 扩展 harness：基于代码的多智能体编排（Scaling the Harness: Multi-Agent Orchestration over Code）
随着 AI 系统处理的问题从函数级代码合成扩展到代码仓库级系统工程，单智能体的根本性局限开始显现：（1）上下文窗口约束使单个智能体无法在工作记忆中同时持有整个代码库、完整的交互历史和执行轨迹；（2）专业化要求使同时执行规划、合成、测试、审查和调试的单一通才智能体效率低下；（3）缺乏独立的协调与验证（verification）渠道，使智能体难以在长时程执行过程中可靠地检测并纠正自身错误。多智能体系统引入了一个强有力的原则：一旦这些职责分布于专属角色，智能体 harness 本身就变得更加模块化、可检查（inspectable）和自适应。ChatDev [330]、MetaGPT [55] 和 AgentCoder [50] 等早期系统通过将软件开发职责划分给架构师、程序员、测试员、审查员和执行者等不同智能体，展示了这一转变。这些角色专属智能体通过结构化通信协议和共享代码制品进行协调，将代码从单纯的输出目标转变为整体 harness 进行规划、行动（acting）、验证和自我改进的共享基底。
在本节中，我们系统综述了将多智能体系统（MAS）用于扩展（scaling）编程 harness 这一快速增长的研究方向，并提出关于为 AI 智能体构建共享的以代码为中心的 harness 基底的新立场。
图 10：通过多智能体编排扩展智能体 harness 的总览图，展示了角色专属智能体、共享的以代码为中心的基底、执行反馈与同步，以及自适应协作拓扑如何解决单智能体在上下文、专业化和自我纠错方面的局限（原文图见 PDF 第 35 页）
4.1. 通过多智能体协作改善编程支持（Improved Coding Support through Multi-agent Collaboration）
多智能体系统最直接的贡献在于：通过将 harness 分解为专属但相互协调的组件，从而改善编程支持。这些系统不是将规划、合成、执行和验证集成在单一智能体循环中，而是将职责分布于通过共享代码制品和反馈信号交互的角色。这种分工使整体 harness 更有能力处理复杂的软件任务，同时也使其内部工作流更具可检查性和可控性。在实践中，这一改进通过三个紧密相关的设计维度来实现：角色如何专业化、智能体如何基于共享程序制品进行交互，以及工作流拓扑如何组织它们的协作。
4.1.1. 功能角色专业化与人工引导规划（Functional Role Specialization and Human-Guided Planning）
在人类软件开发中，不同角色专注于开发过程的不同方面。许多 MAS 通过为不同智能体分配不同的功能角色，自然地映射了这种分工。专业化使每个智能体能够聚焦于共享代码 harness 的特定切片，发挥其独特能力和视角来贡献整体任务。在此，我们详细阐述在综述文献中识别出的最常见功能角色，并指出许多系统实现了多个角色，且角色之间的边界可以是流动的。
程序合成智能体（Program synthesis agents） 程序合成智能体负责生成或转换代码。它们消费规范、规划或反馈信号，并生成或修订代码制品。这是综述系统中最常见的角色。代表性实例包括 Self-Collaboration [56] 中的 Coder、AgentCoder [50] 中的 Programmer、MetaGPT [55] 中的 Engineer、ChatDev [330] 中的 Developer，以及 MAGE [339] 中的 RTL 生成智能体。
图 11：多智能体编排下代码 harness 扩展路线图，按工作流协作、共享代码仓库状态、执行验证和自适应协调组织（原文图见 PDF 第 36 页）
程序理解智能体（Program understanding agents） 程序理解智能体分析现有代码或规范，以产生更高层级的表示。它们拥有的是对代码意义的解读，而非代码本身的实现。这一类别包括 MAGIS [332] 中的 Repository Custodian、HyperAgent [333] 中的 Navigator、Lingma SWE-GPT [340] 中的 RepoUser，以及 CleanAgent [341] 中的 Column-type Annotator。
验证智能体（Verification agents） 验证智能体通过生成测试用例、运行静态分析或模拟执行来评估代码质量。AgentCoder [50] 中的 Test Designer 独立于被测代码生成测试用例，以避免循环推理——这是一项针对模式崩溃问题的设计原则，即智能体带有偏见的测试通过了自己有缺陷的代码。QualityFlow [253] 中的 Test Quality Checker 在元层面上处理这一问题，在测试被用作反馈之前对其进行过滤。AutoSafeCoder [52] 中的 Static Analyzer 和 Fuzzing Agent 通过静态 CWE 分析和动态崩溃检测提供以安全为导向的验证。CANDOR [342] 中的 Panelists 根据自然语言规范而非代码本身独立审计预言机的正确性，刻意避免受到有缺陷实现的污染。
执行智能体（Execution agents） 执行智能体直接与程序运行时交互。值得注意的是，AgentCoder [50] 中的 Test Executor 是一个确定性的 Python 脚本（而非大语言模型（LLM）），它清晰地将推理与执行分离，并将反馈信号接地于客观的程序行为。HyperAgent [333] 中的 Executor 通过交互式 bash shell 运行单元测试和集成测试。MAGE [339] 中的 Judge Agent 与 RTL 仿真工具交互，生成每个时钟边沿的波形快照。
规划智能体（Planning agents） 规划智能体将整体软件开发任务分解为子任务，并将其分配给合成智能体。MetaGPT [55] 中的 Architect 和 Project Manager、MAGIS [332] 中的 Manager、FlowGen [335] 中的 Scrum Master，以及 SoA [212] 中的 Mother 智能体均承担任务分解职能。SoA [212] 中的 Mother 智能体尤为值得注意：它们在运行时根据每个子函数的推断复杂度动态生成 Child 智能体，使规划与智能体初始化相互依存。
EvoMAC [328] 的一个显著特色是引入了在其他任何综述系统中均未出现的两种新颖元角色：Gradient Agent——读取执行日志以识别哪些智能体导致了故障；以及 Updating Agent——修订智能体提示词并相应地重构工作流 DAG。这些角色在 MAS 本身的层面上运作，而非在程序层面，使系统能够根据执行反馈调整自身结构。
4.1.2. 基于共享程序状态的多元交互模式（Diverse Interaction Modes Grounded in Shared Program State）
与以消息传递为主要交互方式的通用 MAS 不同，以代码为中心的交互以制品媒介通信为特征：智能体观察并修改共享的代码制品，其交互接地（grounding）于这些制品及其执行结果所暴露的客观状态。这些协调渠道比单纯的源代码更宽泛：智能体通过 API、文件、差异、测试、日志、模式、黑板（blackboard）和显式工作流状态进行通信。在大多数系统中，这些渠道是人工设计的 harness 的一部分，而智能体则动态地向其中写入或修改流通的制品。我们识别出四种交互模式。
协作合成（Collaborative synthesis） 协作合成发生在两个智能体共同构建一个程序组件时，类比于结对编程 [343]。PairCoder [334] 中的 Navigator-Driver 搭档是最直接的实例化：Navigator 生成并选择解决方案计划，Driver 实现这些计划，双向信息流动。CodePori [331] 在 Dev_01 和 Dev_02 之间实现协作合成，两者在三轮中交换代码草稿。这种模式在综述系统中相对罕见，大多数系统更倾向于顺序交接而非真正的共同构建。
批评与修复（Critique and repair） 批评与修复是综述文献中最主要的交互模式。验证或评估智能体检查代码制品并产生结构化反馈；合成智能体随后根据反馈修订制品。这一模式在几乎所有综述系统中都以某种形式出现。其关键设计决策包括：（a）批评是由大语言模型模拟还是以执行为基础（Self-Collaboration [56] 使用模拟的大语言模型测试员，而 AgentCoder [50] 使用真实的 Python 执行器）；（b）反馈信号的丰富程度（从 SEW [312] 中的二元通过/失败到 EvoMAC [328] 中枚举已满足需求、函数错误和未满足需求的结构化执行日志）；（c）在回退之前允许的修复迭代次数。
对抗性验证（Adversarial validation） 对抗性验证是验证（verification）的一种更主动的形式：一个智能体通过对抗性输入尝试破坏代码，而非被动地审查代码。AutoSafeCoder [52] 通过其 Fuzzing Agent 实现了这一机制——该智能体利用类型感知变异（type-aware mutation）生成导致程序崩溃的输入种子，并执行代码以产生崩溃追踪。这种模式与”批判-修复”模式有本质区别：模糊测试器不解释哪里出了问题，而是展示一个具体的执行失败，即编码智能体必须应对的反例。MAGE [339] 同样将模拟不匹配作为对抗性信号：调试智能体接收到首个时钟边沿失败前后的精确波形窗口，从而能够进行有针对性的修复。
推理辩论（Reasoning debate） 推理辩论是指多个智能体就某一决策的正确性或规范解释展开争论，最终达成共识。ChatDev [330] 引入了”通信式去幻觉（communicative de-hallucination）”机制：助手智能体在提交回复之前，通过角色互换提出澄清性问题。FlowGen [335] 中的 Scrum 冲刺会议支持围绕共享上下文缓冲区进行无序的多智能体讨论，最终由 Scrum Master 综合得出决策。CANDOR [342] 实现了最为结构化的辩论机制：三位独立的 Panelist（小组成员）评估 oracle 正确性，并由 Curator（策展人）通过多数投票汇总其裁定。MAGIS [332] 的启动会议则采用一种循环发言模式，Manager 智能体与所有 Developer 智能体协商任务依赖关系，以防止冲突。
4.1.3. 面向智能体协调的优化工作流拓扑
智能体交互的拓扑结构——谁与谁通信、以何种顺序通信、通信多少次——是多智能体系统（MAS）代码生成中最关键的设计决策之一。本文沿两条主轴对各类拓扑加以梳理。
预定义启发式拓扑 大多数受调查系统采用镜像既有软件开发生命周期（SDLC）模型的拓扑结构。这些拓扑在设计时确定，不会随任务复杂度或系统性能动态调整。
链式（瀑布式）拓扑（Chain (Waterfall) topologies） 将智能体按严格线性顺序排列，工件从规划单向流向合成再流向验证。ChatDev [330] 和 MetaGPT [55] 是典型范例，明确对瀑布式 SDLC 建模：设计 → 编码 → 测试。FlowGen [335] 将三种 SDLC 模型操作化为不同的拓扑：FlowWater（严格瀑布链）、FlowTDD（需求 → 设计 → 测试 → 实现 → 修复，测试驱动的重排序）和 FlowScrum（循环迭代冲刺）。本文的独特之处在于直接比较了三种镜像 SDLC 拓扑对代码质量的影响。L2MAC [344] 同样遵循链式拓扑，但引入了一个新颖的转折：指令计划中的每一步由一个全新上下文的智能体执行，使整个链条成为一系列独立的大语言模型（LLM）调用，它们只共享外部文件存储。
循环（敏捷/迭代）拓扑（Cyclic (Agile/Iterative) topologies） 引入回边（back-edge），允许代码根据验证反馈（feedback）被修订。AgentCoder [50] 实现了程序员 → 测试执行器 → （若失败则）→ 程序员的循环，最多迭代 5 次。Self-Collaboration [56] 在其瀑布链中嵌入了编码器 ↔ 测试器的回边，最多 4 次迭代。PairCoder [334] 通过多计划探索增强了循环模式：预先通过 k-means++ 聚类生成 n 个候选解决方案计划以保证多样性，一旦通过基于历史的循环分析检测到死胡同，系统就可以切换到下一个候选计划。MAGE [339] 将线性初始化链与循环调试-判断循环相结合，并引入高温候选采样，以同时探索多个程序变体。
层级拓扑（Hierarchical topologies） 在工作节点智能体池之上设置一个或多个管理智能体，支持分解-委派模式。MAGIS [332] 拥有一个 Manager，可根据候选文件动态实例化 Developer 智能体；每位 Developer 编辑其分配的文件并向管理-评审层汇报。HyperAgent [333] 在多个代码仓库（repository）导航和编辑工作节点之上设置一个规划者，将自顶向下的分解与自底向上的代码仓库证据相结合。SoA [212] 通过允许 Mother 智能体根据推断出的子任务复杂度递归派生 Child 智能体，将这一层级关系进一步推进。这些系统将 harness 编排本身视为一个资源分配问题。
星型拓扑（Star topologies） 以一个枢纽智能体为中心，协调多个并行工作节点智能体。CANDOR [342] 的第 3 阶段小组是一个典型示例：一位需求工程师向三条独立的 Panelist+Interpreter 流水线扇出，由 Curator 汇聚其输出。MetaGPT [55] 的发布-订阅消息池则构成了一个事实上的星型拓扑，共享消息池充当枢纽。
目标驱动与自适应拓扑 规模较小但快速增长的一类系统将拓扑本身视为待优化的设计变量，优化目标为代码质量信号。FlowReasoner [338] 和 BOAD [337] 等近期系统进一步强化了这一趋势，将多智能体组织本身视为可针对每项任务生成、搜索或优化的自适应对象。
动态智能体池扩展（Dynamic agent pool scaling） 是自适应性最简单的形式：智能体数量随任务复杂度扩展（scaling），但拓扑类型固定。SoA [212] 通过母子智能体的层级树来实现这一点，Mother 智能体在运行时决定将任务分解为多少个子函数，并相应地派生 Child 智能体。关键洞察在于：每个智能体的上下文窗口保持有界，复杂度通过扩展智能体池而非扩大单个上下文窗口来应对。MAGIS [332] 同样根据代码仓库分析中识别出的候选文件数量，动态实例化 Developer 智能体。BOAD [337] 将这一思路从动态扩展延伸至层级发现：它不是手动固定专用子智能体结构，而是将有用的定位、编辑和验证子智能体的选择建模为一个赌博机优化问题，结果表明自动发现的层级团队可以超越手工设计的团队。
反馈驱动的 DAG 重构（Feedback-driven DAG restructuring） 以 EvoMAC [328] 为最佳代表。其工作流（workflow）是一个有向无环图（DAG），节点对应智能体，边定义信息流。每次迭代后，Gradient Agent 读取执行日志以将失败归因到具体智能体，Updating Agent 则相应修改提示词和图结构。这是本综述中唯一一个 harness 拓扑会根据执行反馈（feedback）在结构层面发生改变的系统。
运行时自我重组（Runtime self-reorganization） 是 SEW [312] 的方案：系统使用直接进化（DE）和超级进化（HE）算子，对 LLM 生成的结构化格式（BPMN、CoRE、Python、YAML）工作流（workflow）描述进行整体生成和变异。SEW [312] 不优化智能体参数，而是优化工作流结构本身，包括智能体调用的顺序、路由逻辑和反馈路径。其优化过程自动发现的两个典型拓扑（线性链和反馈循环）从优化中涌现而非人工设计。FlowReasoner [338] 将这种自适应视角进一步推进：通过训练一个查询级元智能体，在外部执行反馈的驱动下，为每个输入问题生成定制化的多智能体系统，使拓扑选择本身成为审慎推理过程的一部分，而非固定的系统设计。
表 10：代表性 MAS 执行反馈与收敛设计汇总（原文图见 PDF 第 41 页）
| 系统 | Harness 基底 | 拓扑 | 执行反馈 | 收敛方式 |
|---|---|---|---|---|
| 预定义拓扑 | ||||
| AgentCoder [50] | 执行 | 循环 | 测试通过/失败 | 正确性（测试门控） |
| MAGE [339] | 执行（波形） | 链式循环 | 检查点波形 | 基于分数的正确性 |
| MapCoder [44] | 执行，隐式 | 循环 | 测试通过/失败 | 正确性 |
| AutoSafeCoder [52] | 执行（静态，模糊） | 循环 | CWE 警告、崩溃 | 安全性收敛 |
| QualityFlow [253] | 执行（真实，想象） | 门控循环 | 通过/失败，想象执行 | 正确性（质量门控） |
| CodeCoR [166] | 执行，隐式 | 循环 | 语法，测试通过/失败 | 基于分数的软正确性 |
| MARCO [345] | 执行（性能） | 双节点循环 | 时间、内存、FLOPS | 性能，正确性 |
| 自适应拓扑 | ||||
| SoA [212] | 执行，隐式差距 | 层级树 | 测试通过/失败 | 正确性（隐式回退） |
| SEW [312] | 隐式 | 进化 | 测试通过/失败 | 隐式 |
| EvoMAC [328] | 执行 | 文本 DAG | 编译器，执行日志 | 正确性（固定迭代） |
| FlowReasoner [338] | 执行，隐式 | 查询工作流 | 执行反馈 | 目标驱动自适应 |
| Trae Agent [336] | 代码仓库，执行 | 搜索流水线 | 测试，剪枝信号 | 基于分数/选择 |
4.2. 执行反馈与共享 harness 同步
本节讨论一组智能体如何利用代码的可执行性，以及如何维护对程序状态的一致共享视图。这一维度是以代码为中心的 MAS（多智能体系统）的决定性特征：共享 harness 具有唯一的可执行性，能产生客观的 oracle 信号。我们聚焦于两个子问题：使用了哪些类型的执行反馈（feedback），以及共享状态如何在智能体间同步。
4.2.1. 执行反馈集成
编译器与语法反馈 编译器与语法反馈在运行前捕获结构性错误，被许多系统所采用。ChatDev [330] 将测试阶段的编译器错误反馈给程序员，但在单个阶段内仅进行一次性纠正。L2MAC [344] 通过其评估模块 $E(D)$ 在每次文件写入后运行语法检查，将其视为阻止指令流水线推进的阻塞条件。
测试通过/失败信号 测试通过/失败信号是最常用的执行反馈类型。AgentCoder [50] 将整个循环的核心置于独立生成的测试用例能否通过：迭代在完全通过或达到 5 次迭代预算时终止。QualityFlow [253] 引入了一个值得关注的变体：想象执行（Imagined Execution）——大语言模型（LLM）逐步模拟 Python 解释器并预测测试结果，无需实际运行代码，在 MBPP 上达到 98%+ 的精度和召回率，同时避免了可见测试用例的标签泄漏。Self-Collaboration [56] 的模拟 LLM 测试器与其真实编译器消融实验的性能高度相近，提出了一个颇具挑战性的实证问题：何时实际执行是必要的，何时语言模拟的执行就已足够？
模糊测试崩溃追踪（Fuzzer crash traces） 模糊测试崩溃追踪代表一种质上不同的反馈类型：它不提供通过/失败的结果，而是提供一个具体的失败输入。AutoSafeCoder [52] 使用类型感知变异生成导致崩溃的输入种子，并将崩溃输入和退出码传递给 Coding Agent。这种对抗性反馈比通用失败信号更具信息量，因为它将 bug 定位到特定的输入类别。
静态分析警告 静态分析警告在不执行代码的情况下提供有关代码结构和安全属性的反馈。AutoSafeCoder [52] 针对 MITRE 漏洞数据库使用 CWE 映射的静态分析，使 Static Analyzer Agent 能够提出针对特定漏洞类别的修复建议。
性能分析结果 性能分析结果被 MACRO [345] 独特地加以利用，该系统将代码优化而非正确性作为主要任务。Performance Evaluator Agent 测量执行时间、内存使用量和 FLOPS，MACRO [345] 还独特地以实时网络搜索来检索研究文献中的相关优化技术。
细粒度模拟反馈 MAGE [339] 的独特贡献是本综述文献中粒度最细的执行反馈。State Checkpoint 机制在每个时钟边沿记录信号值，并向 Debug Agent 提供围绕第一个失败时钟周期的波形窗口，从而实现子测试粒度的有针对性修复。
4.2.2. 共享 harness 同步
顺序交接（Sequential handoff） 顺序交接是最常见的同步机制：每个智能体接收前驱智能体的输出，并将自己的输出传递给后继智能体。程序状态仅以流水线中最近工件的形式存在。这对于简单的线性流水线已经足够，但在多个智能体并行或迭代地修改代码仓库的多智能体设置中，会产生不可见的状态分歧。这也是代码中介协调的局限性所在：即使智能体共享可执行工件，harness 仍施加信息论约束——通道带宽有限、摘要存在压缩损失、日志会变得嘈杂、缓存视图会过时，并行分支引发关于权威性与一致性的悬而未决问题。代码为协调提供了更丰富的基底，但并不能消除这些分布式系统约束。
共享黑板（Shared blackboard） 共享黑板提供一个所有智能体都可读写的全局可访问程序状态。L2MAC [344] 将这一机制实现得最为简洁：文件存储 $D$ 是一个外部持久结构，从不被覆写，只会被扩展和修订；Control Unit 管理所有读写操作，确保每次智能体调用都获得精确控制的上下文窗口。MAGIS [332] 的代码仓库进化记忆 $M$ 是一个持久键值存储，将文件版本映射到 LLM 生成的摘要，并随文件在问题解决过程中的变化而增量更新，通过一个专用黑板支撑代码仓库级推理。Self-Collaboration [56] 是最早明确命名并调用黑板架构的系统之一，建立了供三个角色（分析者、编码者、测试者）共同读写的共享记忆。
带合并的并行分支（Parallel branches with merge） 并行分支带合并的模式出现在多个智能体同时修改独立组件、其变更随后在某一阶段被集成时。MAGIS [332] 为每个候选文件实例化一个 Developer；每位 Developer 独立修改其分配的文件，所有变更最终合并为最终代码仓库差异（diff）。HyperAgent [333] 通过 Redis 队列并行运行多个 Navigator 和 Editor 实例，结果在 Planner 层进行合并。
结构化上下文调度（Structured context scheduling） 结构化上下文调度是对每个智能体所见内容及其时机的显式管理，是 L2MAC [344] 的核心创新。Control Unit 在指令步骤之间重置上下文窗口，为每次新调用提供包含先前进度的有针对性摘要（$M_{rs}$），而非完整的对话历史。当上下文窗口接近容量时，Control Unit 将部分结果存入 $D$ 并以压缩视图重新初始化，明确指示 LLM 根据剩余上下文余量读取或跳过哪些文件。这一机制不是通过扩大上下文窗口，而是通过精心控制其内容来解决上下文窗口问题。MetaGPT [55] 通过发布-订阅消息池实现了一种更轻量的上下文调度：每个智能体只订阅与其角色相关的文档类型，从而获得共享状态的过滤视图。
层级记忆（Hierarchical memory） 层级记忆将短期工作上下文与长期积累知识相结合。ChatDev [330] 明确区分了短期记忆（阶段内完整对话）和长期记忆（跨阶段传递的提取解决方案）。Cogito [346] 实现了层级记忆，借鉴神经生物学架构：用于即时任务状态的短期记忆、积累专业知识的长期知识库，以及随时间不断改进演化抽象的成长单元。HyperAgent [333] 使用轻量级 LLaMA-3.1-8B 摘要器在存入层级记忆之前压缩执行日志，防止上下文膨胀。
智能体池扩展（Agent pool scaling） 智能体池扩展从另一个维度解决上下文管理问题：它不是管理单个智能体所看到的内容，而是将上下文负载分散到更多智能体上。SoA [212] 是典型示例：随着任务复杂度增长，通过派生更多智能体来保持每个智能体的上下文有界。这是 harness 状态问题的一种结构性解决方案：与其构建所有智能体都能查询的共享表征，SoA [212] 将任务状态分区到各智能体，每个智能体持有一个有界的切片。其局限在于牺牲了全局一致性：智能体只能推理其分配的子函数，而无法推理完整程序。
其他 QualityFlow [253] 的回退机制代表了一种同步模式：初始代码工件从不被覆写，如果调试轨迹使质量下降，系统可以回滚到先前的共享 harness 状态。这是本综述系统中唯一一个明确管理状态历史而非始终向前推进的工作。
4.3. 立场：共享以代码为中心的 harness 基底
我们为下一代多智能体智能提出一个新的立场：共享以代码为中心的 harness 基底（shared code-centric harness substrate）。这一立场源于文献中识别出的核心空白：缺乏对共享代码状态的正式、持久表征，使智能体能够跨迭代进行查询和更新。我们认为，构建这样一个 harness 基底对于实现鲁棒、可扩展的多智能体智能既是可行的，也是必要的。
表 11：以共享程序状态表征与同步为中心的代表性 MAS 设计汇总（原文图见 PDF 第 44 页）
| 系统 | Harness 基底 | 智能体角色 | 执行反馈 | 收敛/同步方式 |
|---|---|---|---|---|
| L2MAC [344] | 黑板，代码仓库，执行 | 规划、合成、验证（评估器） | 语法，测试通过/失败 | 每指令步骤正确性 |
| Cogito [346] | 黑板（三层记忆） | 神经生物学模型 | 无 | 层级记忆同步 |
| CleanAgent [341] | 执行（弱），隐式 | 规划、理解、合成、执行 | 运行时错误 | 通过执行成功收敛 |
| Lingma SWE-GPT [340] | 代码仓库，执行 | 理解、合成、验证 | 语法，git apply，测试 | 固定限制隐式收敛 |
| SyncMind [347] | 代码仓库，执行（形式化 $S_k/B_k$） | 合成-理解，oracle 理解 | 测试通过/失败，运行时错误 | 正确性，资源约束同步 |
| BOAD [337] | 代码仓库，执行 | 带专用子智能体的编排者 | 测试通过/失败，验证奖励 | 层级发现，协调 |
| CANDOR [342] | 执行（Java，JaCoCo） | 规划、合成、验证、理解、辩论 | 编译器，覆盖率，测试 | 正确性，覆盖率，共识 |
4.3.1. 共享 harness 表征
任何 MAS 的基础性问题是：这些智能体所栖居的基底是什么？在代码即智能体 harness 中，自然的答案是共享程序环境——即智能体集体作用、共同生产、修订和评估代码时所产生和演化的工件、执行上下文与质量信号的集合。我们将其称为共享 harness 基底，并区分现有系统表征它的四个形式化层次。
隐式/仅文件表征（Implicit / File-only Representation） 最常见也最不形式化的类别将共享 harness 简单视为当前代码文件或代码文件集合。智能体将最新代码工件作为输入上下文的一部分接收，并生成修改或评估后的版本。不存在持久的、可查询的表征：共享状态在每次智能体调用时从对话历史中隐式重建。这一类别涵盖了许多基础系统：ChatDev [330]、MetaGPT [55]、FlowGen [335]、MapCoder [44]、CodeCoR [166]、SEW [312] 和 CodePori [331]。这种表征虽然实现简单，但存在根本性局限：智能体只能通过其最近上下文窗口的狭窄视角推理共享状态。状态分歧 [347]——即智能体对代码状态的内部信念与真实状态产生偏差——对系统不可见，且无法被检测或纠正。
基于代码仓库的表征（Repository-based Representation） 更丰富的一类系统将共享 harness 表征为可导航的代码仓库：一个具有目录结构、文件间依赖图、调用层次和版本历史的文件系统。这种表征支持智能体推理代码库中哪里需要做修改、哪些组件依赖于被修改的函数、以及代码库随时间如何演化。MAGIS [332] 引入代码仓库进化记忆，缓存文件级摘要，并在问题解决过程中随文件变化通过 git diff 进行增量更新。HyperAgent [333] 为智能体提供代码仓库导航工具（get_tree_structure、go_to_definition、code_search、get_all_references），将代码仓库视为结构化知识库。Lingma SWE-GPT [340] 通过抽象语法树（AST）骨架压缩代码仓库视图，保留函数签名和类定义以支持高效导航。SyncMind [347] 是本综述中唯一将代码仓库基底形式化定义为真值状态 $S_k$ 并测量 $S_k$ 与智能体信念状态 $B_k$ 之间分歧的工作。
基于执行的表征（Execution-based Representation） 基于执行的表征是代码生成中最具特色的类别，通过执行行为来表征共享基底，而在通用 MAS 中没有直接对应。状态不是代码看起来是什么样子，而是代码做了什么：它是否编译、通过了哪些测试、模糊测试器发现了哪些漏洞、运行速度多快，以及其运行时行为是否符合规范。这种基于执行的表征提供了客观的 oracle 信号，是不受幻觉或偏见影响的基本真值，而这种幻觉或偏见会影响纯语言智能体的评估。利用这种表征的系统包括 AgentCoder [50]、AutoSafeCoder [52]、QualityFlow [253]、MACRO [345]、EvoMAC [328]、CANDOR [342] 和 MAGE [339]。值得注意的是，MAGE [339] 实现了本综述文献中粒度最细的执行反馈，通过 State Checkpoint 波形快照，以时钟边沿的粒度进行操作。
黑板/共享状态表征（Blackboard / Shared-State Representation） 第四类引入了一种显式的、全局可访问的数据结构，供所有智能体读写（类似于 AI 中的经典黑板架构 [348]）。这种共享状态是本综述文献中对形式化 harness 基底最接近的近似：它跨智能体调用持久存在，可被查询和更新，并为所有智能体提供一致的程序状态视图。Self-Collaboration [56] 是最早明确调用黑板隐喻的系统之一，建立了供三个角色（分析者、编码者、测试者）共同读写的共享记忆。L2MAC [344] 实现了本综述文献中最原则性的黑板：一个具有语义有意义路径的持久文件存储 $D$，通过 Control Unit 访问，Control Unit 显式管理每个智能体所见的状态切片。GameGPT [210] 使用共享上下文缓冲区以减少多轮游戏开发中的冗余信息重传。Cogito [346] 借鉴神经生物学架构，实现三层记忆：短期工作状态、长期知识库和用于演化抽象的成长单元，作为一种结构化的 harness 表征。
核心空白 这四个类别中系统的分布揭示了一个引人注目的规律：绝大多数文献属于隐式/仅文件类别，缺乏对共享 harness 基底的任何形式化模型。这正是推动代码即智能体 harness 框架的核心空白所在。程序作为多智能体领域中独特的工件，是可以执行的。它能产生客观的、非语言信号，这些信号原则上可以锚定一个形式化的共享基底。然而大多数系统未能在架构层面利用这一特性，而是依赖智能体仅通过自然语言来推理代码质量。
4.3.2. harness 状态收敛
收敛确定了多智能体编码 harness 应于何时停止迭代并接受当前程序状态作为满意结果。在许多现有 MAS 中，收敛仍被隐式定义，要么通过智能体之间的共识，要么通过外部迭代预算。然而，代码即智能体 harness 具有独特优势：由于共享基底是可执行的，收敛可以基于客观的行为信号而非仅仅依赖对话共识。我们识别出六种收敛模式，从广泛使用的测试门控收敛和隐式收敛，到较为少见的安全性收敛、性能收敛和基于共识的收敛标准。
正确性收敛（Correctness convergence） 正确性收敛（测试门控）是最原则化和广泛使用的客观标准：当所有测试用例通过时系统成功终止。AgentCoder [50]、L2MAC [344]、SyncMind [347] 和 CANDOR [342] 均实现了测试门控收敛。PairCoder [334] 通过死胡同检测增强了这一机制：如果相同的 buggy 代码或反馈出现在迭代历史中，系统切换到下一个候选计划而非循环。FlowGen [335] 使用测试门控收敛，但基于 LLM 生成的测试而非基准测试，引入了潜在的质量隐患：系统可能收敛于通过自身有偏测试、但在外部评估中失败的代码。
安全性收敛（Security convergence） 安全性收敛由 AutoSafeCoder [52] 独特实现：当静态分析未标记任何 CWE 漏洞且模糊测试器未诱发崩溃时，系统成功终止。这种多标准收敛是支持基于执行 harness 框架的有力论据——两个收敛标准都基于客观程序行为，而非智能体意见。
性能收敛（Performance convergence） 性能收敛是 MACRO [345] 的重点：当用户定义的运行时和内存阈值得到满足时，优化循环终止，由 Performance Evaluator 针对实际执行基准进行测量。这是唯一一个将性能而非正确性作为主要收敛标准的系统。
基于分数的收敛（Score-based convergence） 基于分数的收敛使用智能体对中间输出计算的量化质量分数来决定何时停止。MAGE [339] 按模拟不匹配分数 $s(r) = 1 - m(r)/tc(r)$ 对候选程序排序，持续迭代直到最高分达到 1.0。CodeCoR [166] 在每个智能体阶段使用四标准二值分数（清晰度、相关性、简洁性、上下文）来剪枝中间输出，并在其 Ranked Code Set 中选择排名最高的代码作为最终输出。它设定了软正确性收敛，提交最佳可用结果而非等待完美解决方案。Trae Agent [336] 在代码仓库规模引入了一种密切相关的搜索-选择视角：将问题解决建模为一个最优解搜索问题，使用模块化生成、剪枝和选择智能体在大型候选补丁空间中导航。在这种设置下，收敛不仅是反复修复的问题，还涉及在代码仓库感知证据下对竞争解决方案进行排序、过滤和选择。
共识收敛（Consensus convergence） 共识收敛汇聚多个评审智能体的判断。CANDOR [342] 实现了三位 Panelist 对 oracle 正确性的多数投票。MAGIS [332] 使用 QA Engineer 的 LLM 判断作为接受信号，尽管这是单智能体共识而非多智能体投票。QualityFlow [253] 使用其 Code Quality Checker 作为单一门控信号——这是一种高效设计，质量检查器同时充当收敛 oracle 和系统控制器，支持提前退出（75–84% 的问题在第一次生成调用后即收敛）。
隐式收敛（Implicit convergence） 在固定阶段数或迭代次数后终止流水线、无任何客观质量标准，是文献中最普遍的收敛模式，也是该领域最显著的空白。ChatDev [330] 在固定阶段数后终止，或在连续两轮生成相同代码后，或在 10 轮后终止——这些均非客观质量信号。MetaGPT [55] 在完成固定的 SOP 阶段后终止。Self-Collaboration [56] 在测试者始终未批准的情况下，$n = 4$ 次迭代后回退到隐式收敛。EvoMAC [328] 运行固定 $K$ 次文本反向传播循环迭代。隐式收敛现象的普遍存在，是缺乏形式化共享基底的直接后果：若没有对程序状态的客观表示，系统便无从建立收敛的原则性判据。
4.4. 模式与趋势
在各系统中，角色专业化、共享状态表示、执行接地（execution grounding）以及工作流（workflow）拓扑等方面的差异，并非相互独立的工程选择，而是相互作用、共同决定一组智能体（agent）能否在长周期编码任务中保持一致性。本小节从所调研的系统中提炼主要规律，既归纳当前系统的共性结构性瓶颈，也梳理指向更健壮共享 harness 的设计原则。
隐式 harness 状态约束 在所调研系统中，绝大多数（ChatDev [330]、MetaGPT [55]、FlowGen [335]、CodePori [331]、SEW [312]、MapCoder [44]、CodeCoR [166]）均在没有共享代码 harness 显式表示的情况下运行。这些系统依赖智能体在每次调用时从对话历史中隐式重建状态。这一设计对程序状态简单且不跨智能体碎片化的函数级任务尚能应对，但该隐式方法从根本上引入了一个漏洞：若没有形式化的共享基底，智能体便无法可靠地检测到其内部理解何时偏离了真实程序状态 [347]。从代码即智能体 harness 的视角来看，对隐式状态表示的依赖是系统脆弱性的技术根源，而非一种可扩展（scaling）的便利之举。
代码中介通道无法消除协调瓶颈 从自由对话转向代码中介协调是一项真实的架构进步，但其价值不宜被高估。文件、API、差异（diff）、测试、日志、模式（schema）、黑板以及工作流状态，都不过是任务状态被编码、传输和重建的部分通道。每种通道都在保真度、延迟和覆盖范围之间作出权衡：测试将语义压缩为通过/失败，摘要以牺牲细节为代价保存上下文，日志有接地性但噪声大，共享黑板提升了持久性，却同时带来权威性和一致性问题。因此，核心设计问题并不仅仅是代码是否存在，而是哪些制品具有权威性、如何压缩，以及跨通道冲突如何解决。
执行反馈（feedback）作为语言推理与形式推理（reasoning）之间的桥梁 文献中最深刻的分歧，在于以执行结果作为基准真相的系统与依赖语言模型判断的系统之间。将共享状态接地于执行的系统（AgentCoder [50]、AutoSafeCoder [52]、QualityFlow [253]、EvoMAC [328]、MAGE [339]）能够获取客观的预言机信号，即那些不可能产生幻觉的信号。然而，一个令人意外的发现使这一图景更加复杂：Self-Collaboration [56] 与 QualityFlow [253] 表明，大语言模型（LLM）模拟执行在不实际运行代码的情况下，预测真实结果的精准率与召回率均可达到 98% 以上。这说明执行反馈的价值并非在所有失败模式下均匀分布——它在处理语言模拟从结构上无法覆盖的边角案例（运行时崩溃、资源耗尽、边界条件错误、性能回归）时尤为突出，但对于许多可修正的缺陷，模拟推理可能已经足够。一个成熟的 harness 应将两者整合：以语言推理作为快速路径，仅在需要执行（execution）作为验证（verification）预言机的失败模式下才转交执行。
共享 harness 的两种互补表示 所调研的系统揭示了两种概念上正交的视角：基于代码仓库（repository）的表示（结构视图：哪些函数调用了哪些函数，数据如何流动，依赖关系是什么）和基于执行的表示（行为视图：代码运行时做了什么，状态如何在运行时演化，在不同输入下会出现哪些紧急失败）。MAGIS [332] 与 HyperAgent [333] 主要在代码仓库视图下运行，使智能体能够推理代码库架构；AgentCoder [50] 与 MAGE [339] 主要在执行视图下运行，将共享状态接地于运行时信号。然而在所调研的系统中，没有一个能完全将两种视图统一为单一 harness 基底，从而使智能体既可以推理代码的静态结构，又能推理其动态行为。最深层的 harness 应整合这两种视角，回答诸如”哪些组件运行慢”（同时需要调用图与性能分析数据）或”这次重构是否破坏了外部代码依赖的 API”（同时需要静态分析与动态测试）之类的问题。
拓扑复杂度与 harness 状态形式化程度负相关 拥有显式形式化共享基底的系统使用更简单的拓扑，而缺乏形式化共享状态的系统则采用日益复杂的拓扑结构作为结构性补救。L2MAC [344] 拥有最清晰的形式化 harness 基底（带有显式上下文调度的持久文件存储），仅使用简单的顺序链配合精密的状态管理。相比之下，EvoMAC [328] 和 SEW [312] 等隐式系统则发展出了精心设计的自适应拓扑（动态有向无环图、工作流变异、智能体池扩展），试图在缺乏原则性共享表示的情况下优化协作结构。这表明拓扑复杂度在一定程度上是一种症状：当基底被形式化表示且可查询时，智能体可以通过简单、透明的协议进行协调；当基底是隐式的，智能体则需要更丰富的交互模式来弥补缺失的状态信息。
上下文管理是隐式共享状态的代价 一个引人注目的规律是，许多系统正是因为缺乏形式化的共享基底，才发展出了精密的上下文管理机制。L2MAC [344] 的控制单元、MetaGPT [55] 的发布-订阅池、SoA [212] 的智能体池扩展，以及 Cogito [346] 的三层记忆（memory），都是对同一底层问题的回应：如何让智能体获得一个大到无法放入任何单一上下文窗口的代码 harness 的连贯视图。一个成熟的 harness 基底可以通过提供对任务状态的原则性、可查询表示——智能体按需访问，而非强迫系统在每一步精心管理每个智能体所见的内容——来统一这些分散的解决方案。
智能体专业化提升共享状态度量的关键性 随着智能体角色多样性的增加——从基本的编码者-测试者对，到拥有架构师、管理者、导航者、执行者和验证者角色的系统——对统一共享基底的需求愈发迫切。若缺乏对代码状态的共享理解，规划智能体可能基于过时的代码库快照来分解任务，执行智能体可能针对与合成智能体意图不同的版本运行测试，而验证智能体的反馈也可能出现偏差。EvoMAC [328] 通过其 Gradient 与 Updating 智能体来应对这一问题，这两个智能体在多智能体系统（MAS）层面显式监控失败归因。SyncMind [347] 将该问题形式化为智能体信念偏差 $|B_k - S_k|$，并提出显式同步协议。因此，智能体角色的增殖绝非单纯的工程选择，它是推动更成熟共享 harness 发展的驱动力。拥有丰富角色体系的多智能体（multi-agent）系统若缺乏共享 harness，便无法稳健运行。
图 12：代码即智能体 harness 在五个新兴领域的概览，包括代码助手（code assistant）、GUI/操作系统智能体（GUI/OS agents）、科学发现、个性化以及具身智能体（embodied agent）。（原文图见 PDF 第 49 页）
5. 新兴领域与开放问题
在通过接口、机制和编排模式对代码即智能体 harness 进行刻画之后，我们现在审视这一范式如何在具体应用领域中得以实现，以及它所揭示的开放问题。在代码助手、GUI/操作系统智能体、科学发现、个性化以及具身智能体等领域，代码不仅作为模型输出，更作为状态表示、行动执行、记忆、反馈与治理的操作基底。这些领域使以代码为中心的智能体系统的前景变得切实可见，同时也揭示了围绕评估、验证（verification）、安全、协调、多模态接地以及 harness 演化等方面的一组共性未解挑战。
5.1. 新兴领域与典型应用
本小节调研五个应用领域，代码即 harness 系统在这些领域已尤为显著地落地。代码助手在代码仓库、测试、开发工具和协作工作流上运作；GUI/操作系统智能体通过可执行行动和程序化检查器操控渲染界面；科学智能体将假设、实验、分析和实验室协议组织为可执行管道；个性化智能体通过结构化用户反馈和可编辑偏好状态来调适推荐策略；具身智能体（embodied agent）则将高层意图接地于受物理约束支配的可执行技能中。这些领域共同展示了代码如何将模型输出与真实系统相连接，以及周边 harness 的设计如何塑造可靠性、可控性和长周期自主性。
5.1.1. 代码助手
代码助手（code assistant）提供了以代码为中心的智能体系统走向实用的最清晰应用领域之一。早期系统主要支持局部补全或单轮代码生成。近期的助手则在代码仓库级工作流上运作，其中编辑、工具使用（tool use）、验证与拉取请求（pull-request）交互构成了一个闭环智能体过程。这一转变体现在 SWE-agent [57]、OpenHands [58] 等研究系统，以及 Claude Code [26]、Codex [27]、GitHub Copilot 编码智能体 [349] 和 DeepAgents [350] 等面向生产的平台上。在这些系统中，助手不再是独立的代码生成器，而是嵌入在开发环境中，代码仓库状态、工具、验证例程和协作工作流共同提供了行动与反馈的操作上下文。
以代码仓库为中心的工作空间 现代代码助手在代码仓库而非孤立代码片段上运作。源文件、测试、构建脚本、依赖元数据、议题（issue）、分支和拉取请求构成了一个持久工作空间，智能体可以跨多个步骤检查、修改和验证。这使得代码仓库级辅助与其说是将相关文件放入提示词的问题，不如说是在庞大且持续演化的代码库上构建特定任务工作视图的问题。RepoCoder [47]、CodexGraph [351] 和 AutoCodeRover [46] 等系统通过代码仓库索引、依赖感知检索、基于图的代码表示以及在编辑前进行的智能体定位来解决这一问题。从这个意义上说，代码仓库成为代码助手进行规划（planning）、行动并接收反馈的操作基底。
可执行开发 Harness 可执行开发 harness 正在成为代码助手的运行时和控制平面。近期系统不再将模型暴露于扁平的工具列表中，而是将其包裹在一个受管理的开发循环中，该循环控制代码仓库访问、文件编辑、命令执行、审批边界、上下文隔离、日志记录和验证。这一趋势在生产系统中清晰可见：Claude Code 将本地终端/IDE/浏览器编码包装进一个带有编辑、命令执行、权限、钩子、记忆和子智能体的工具中介循环；Codex 与 GitHub Copilot 编码智能体将类似循环转移到带有沙箱、分支、审批和可审计拉取请求输出的托管云端或 GitHub 原生工作空间；DeepAgents 则将规划、文件系统支撑状态、上下文管理、代码执行和子智能体委托作为可复用 harness 组件暴露出来 [26, 27, 350, 349]。这类循环越来越多地通过开放协议（如模型上下文协议（Model Context Protocol）[352, 260]）来中介，这些协议标准化了 harness 向模型暴露工具、上下文和资源的方式，并支持跨系统的工具复用。与此同时，近期研究将 harness 本身视为优化对象而非固定包装器：AutoHarness [14] 从环境反馈中合成代码 harness，Meta-Harness [13] 利用先前候选方案和执行轨迹对 harness 代码进行搜索，Agentic Harness Engineering [281] 通过可观测性演化编码智能体 harness，Natural-Language Agent Harnesses [353] 则将角色、契约、适配器和状态约定外部化为可编辑的 harness 规范。这些进展共同表明，代码助手领域的实践进步，不仅取决于基础模型本身的改进，也日益取决于其周边执行运行时，包括沙箱、权限、上下文管道、遥测和验证钩子。
执行反馈作为有接地性的验证 代码助手的一个显著特性是机器可检验反馈（machine-checkable feedback）的可用性：编译器诊断、测试结果、代码检查器（linter）警告和运行时跟踪。Agentless [354] 表明，由测试执行引导的故障定位与补丁生成管道，在无需精心设计的智能体控制的情况下，即可在 SWE-bench [216] 上取得有竞争力的结果。RepairAgent [183] 和 Live-SWE-agent [182] 则将这一循环扩展为由测试结果驱动的自主程序修复，而 AlphaCodium [355] 则证明，测试驱动的流程工程（test-driven flow engineering）相比单次提示（single-shot prompting）能大幅提升竞争性编程表现。执行因此将每个候选编辑从文本假设转化为对程序世界的可验证变换。
代码仓库规模的记忆与上下文管理 代码仓库规模例行性地超出任何合理的上下文窗口，迫使代码助手维护显式的结构化记忆（memory）。检索增强补全 [47]、基于图的代码索引 [351]、面向文档的智能体（如 RepoAgent [356]），以及近期的上下文检索基准（如 ContextBench [357]），都将 §3.2 中的记忆抽象实例化为一种代码特有的变体：存储项（如函数、测试、轨迹以及检索到的议题上下文）本身是可执行的，或与可执行状态直接关联，可以被重新运行、检查、定位而不仅仅是重读。近期记忆系统进一步扩展了这一观点，将可复用的智能体过程或代码仓库经验作为过程性记忆和经验性记忆存储 [45, 48]。这缩小了传统智能体架构中记忆与环境之间的差距，使抽象管理尤为关键，因为助手必须为给定的子任务选择合适粒度的代码和经验进行呈现。
开发者意图与项目约定作为潜在状态 除显式代码仓库状态外，实用的编码助手还必须推理潜在的开发者意图和项目约定。一个有用的补丁不仅要通过可见的测试，还要符合代码仓库的架构、编码风格和内部 API 复用，这些属性近期研究称之为生成代码的有机性（organicity）[358]。忽视这些约束的智能体可能产出技术上正确却仍被维护者拒绝的补丁 [358, 359]，而基准分析则表明，一些看似已解决的 SWE-bench 议题依赖的是议题文本中的解决方案泄露，而非真正的意图推理 [360]。因此，编码辅助是一个部分可观测的程序世界问题：文件、测试和工具输出提供了可观测状态，而设计理由、隐式约束和团队约定则必须从议题线程、历史提交、代码评审和积累的交互历史中加以推断。这将 SyncMind 中研究的信念状态偏差从共享的多智能体状态延伸至个体智能体与用户的对齐，对代码仓库 [347] 而言尤其如此。建模这种潜在状态，对于从功能性代码生成迈向值得信赖的开发者协作而言至关重要。
从内联补全到自主 SWE 智能体 代码助手的演化可以视为智能体围绕模型的开发 harness 不断扩展的过程。早期系统（如基于 Codex 的补全 [1]）以及商业助手（如 Copilot [361]）依赖轻量级 IDE harness：在该架构中，本地上下文被呈现，内联建议被生成，开发者依然是主要的执行者、验证者和状态管理者。生产力 [361] 和可用性 [362, 363] 研究表明，即便是这种轻量级 harness 也至关重要，因为建议的价值取决于其与开发者不断演化的程序状态和意图的对齐程度。在自主端，SWE-agent、OpenHands、AutoCodeRover 和 Agentless 等系统在代码仓库级 harness 内运行，从孤立代码生成转向有状态（stateful）的检查、编辑、执行和修订。
从补丁生成到软件生命周期参与 代码助手还在从孤立补丁生成向更广泛的软件生命周期参与迁移。SWE-bench 将代码仓库级辅助框架为议题到任务问题 [5]，而 SWE-Lancer [364] 和 SWE-Bench Pro [365] 等更新的基准则评估跨越多个文件且需要专业工程投入的长周期、具有经济意义的软件可交付成果。Terminal-Bench [366] 和 AppWorld [367] 等相关基准进一步体现了同样的转变——面向需要智能体通过命令、工具和可执行应用状态运作的交互式环境 [368, 369]。在部署层面，这一趋势表现为在持久工程工作流（包括拉取请求评审、CI/CD 反馈和生产议题解决）中工作的智能体，而非面对静态代码仓库快照 [370, 371]。在生产规模下，LingmaAgent 报告称，在阿里云上自主部署的议题解决智能体，全自主处理了 16.9% 的内部议题，手动干预下处理了 43.3% [372, 373]。这表明代码助手正在成为工作流（workflow）的参与者，而不仅仅是补丁生成器。
多智能体代码辅助与共享代码仓库 在能力谱的高端，代码辅助越来越呈现多智能体形态，规划者、编码者、测试者和审查者角色在共享代码仓库上协同运作。ChatDev [330]、MetaGPT [55]、CodeAgent [185] 和 METAL [374] 展示了角色专业化与共享可执行制品相结合，如何使协调模式得以持续，而这是单一智能体在长周期任务中难以维持的。代码仓库连同其测试和执行轨迹，既成为通信媒介，也成为收敛目标，直接实例化了 §4 中的共享程序世界。然而，并发编辑可能悄然使其他智能体持有的假设失效，从而暴露出同一节中讨论的全局状态同步挑战。
Harness 作为蒸馏平面 2026 年的一个标志性进展是，生产 harness 不再仅仅是部署基础设施，正在成为下一代代码助手模型训练数据的主要来源。Cursor 的 Composer 基于真实 Cursor 使用轨迹进行持续在线强化学习训练，收紧了已部署智能体行为与模型更新之间的循环 [375, 376]。OpenAI 的 codex-1（o3 的衍生版本）[27]、GPT-5-Codex [377] 和 GPT-5.1-Codex-Max [378] 则被明确训练于镜像 Codex harness 循环的长周期多轮编码交互，而 Anthropic 内部的 Claude Code 用狗粮测试（dogfooding）则以其团队使用 Claude Code 白皮书 [379] 中记录的类似反馈通道为模型贡献训练数据。与此同时，harness 本身正在成为显式的优化对象：AutoHarness [14] 利用较小的大语言模型合成 harness 代码以过滤非法行动，Agentic Harness Engineering [281] 通过可观测性驱动的演化循环封闭 harness 组件，Meta-Harness [13] 形式化了模型与 harness 的联合优化，而 Live-SWE-agent [182] 在运行时编辑自身脚手架——这些进展共同表明，”智能体”与”智能体周边的 harness”之间的边界，正在成为一个可学习的平面。
代码助手 Harness 的开放挑战 生产 harness 的成熟揭示了若干编码特有的开放问题，这些问题与下一小节讨论的跨领域议程相互补充。首先，超越单元测试的验证（verification）在很大程度上仍未解决：PatchD-iff [380] 和 SWE-Bench++ [381] 所揭示的预言机充分性危机，Aardvark [382] 和 Codex Security [383] 所应对的安全-正确性差距，以及功能性补丁与被接受补丁之间的有机性差距 [358, 359]，都指向一个当前 harness 所不足的验证平面。其次，长周期智能体循环中的失败归因仍不成熟：经验研究（如”多智能体系统为何失败？”[384]）、Who&When 归因数据集 [385]、AgenTracer [386] 和 AgentDebug [387] 报告的最佳步骤级归因准确率在 14–53% 区间，表明生产 harness 缺乏原则性调试所需的结构化轨迹。第三，自主代码执行的安全治理需要基于能力的原语，而这在实践中仍然罕见：Aethelgard 的学习型能力管理器 [388]、容错事务型沙箱 [389] 以及微软的 Agent Governance Toolkit [390]，代表了在并发智能体行动下执行最小权限原则的早期探索。第四，仅在 AutoHarness、AHE 和 Live-SWE-agent 等有限场景中展示的 harness 自我演化，提出了非自我修改 harness 所没有的稳定性和回滚问题。第五，在活跃代码仓库上的多智能体状态同步，将 SyncMind 的信念状态偏差问题 [347] 推广到人类、自主智能体和 CI 系统并发变更共享程序状态的环境。最后，配对编程用户体验中的信任校准仍是一个研究不足的人因问题，涉及何时打断、何时设置检查点、何时委托以及何时推迟等决策，尽管其对于 harness 驱动的自主性能否安全扩展至企业工作流至关重要。
代码助手因此是以代码为中心的智能体系统最清晰的生产实例，也是当前正在工业界与学术界共同涌现的 harness 工程学科最严苛的测试床。
5.1.2. GUI/操作系统智能体作为程序世界
图形用户界面和操作系统，或许比基础模型智能体的任何其他有形应用都更构成字面意义上的程序世界：智能体接收到的每一个观测都是可执行代码的渲染输出（HTML、CSS、布局 XML、无障碍访问 API、由窗口管理器驱动的帧缓冲区），其采取的每一个行动都是对另一段代码的调用（DOM 事件、adb shell 命令、OS 事件循环捕获的按键、Playwright 脚本）。正因如此，GUI/操作系统智能体已成为验证代码是统一感知、行动、环境动态和记忆的接地（grounding）媒介这一中心论题的标准测试场。以下我们系统地展开这一视角。
GUI/操作系统作为部分可观测程序世界 我们将 GUI/操作系统环境建模为部分可观测马尔可夫决策过程（Partially Observable Markov Decision Process）$\langle S, \mathcal{A}, \mathcal{O}, T, R \rangle$，其中潜在状态 $s \in S$ 是一个或多个进程的完整程序状态（浏览器的完整 DOM 及 JavaScript 堆、Android 模拟器的 Activity 栈和内容提供者、Linux 虚拟机的文件系统和窗口树）。智能体从不直接观测 $s$，而是观测 $o \in \mathcal{O}$，在现代系统中，这有四种代码定义的形式之一：（i）WebArena 和 Mind2Web [60, 59] 中的序列化 DOM 或 HTML 子树；（ii）由 Android 的 UIAutomator 或 macOS/Windows 无障碍访问 API（如 AndroidWorld 和 WindowsAgentArena 中采用）暴露的无障碍访问树（AXTree），例如被 AgentOccam [391, 392, 393] 所采用；（iii）带有边界框或 Set-of-Mark 坐标标注的截图，如 SeeAct、WebVoyager、OSWorld 和最新原生模型所使用 [394, 395, 396, 397]；（iv）混合表示，交织像素、无障碍访问元数据和 HTML，如 WebArena 的 BrowserGym 观测空间和 CogAgent 的双分辨率编码器 [398, 399]。行动空间 $\mathcal{A}$ 同样是代码：一个元组 $\langle action_type, target, value \rangle$，编译为 DOM/无障碍访问调用（element.click()、setText(node_id, "...")）或 OS 级键盘/鼠标原语（pyautogui.click(x,y)、xdotool key）。至关重要的是，转移函数 $T$ 并非被学习而是被执行：浏览器引擎、Android 运行时或宿主操作系统以确定性方式产生下一个观测。智能体通常被框架为类人计算机用户：通过与人类相同的图形通道感知视觉界面、推理用户指令并执行行动。智能体策略 $\pi(a|h)$ 因此最好理解为一个程序合成器，在给定历史 $h$ 的条件下，生成下一段可执行代码；而环境则是解释器。
代码作为用户界面与 GUI 智能体之间的桥梁 近期研究将代码视为高层模型推理与底层 UI 执行之间的中间接口 [396, 400, 401]。这一接口提供两个主要优势：首先，它抽象掉了嘈杂的视觉细节，在模型的语义规划与系统的可执行控制层之间建立了自然边界。其次，它将感知、行动和评估融合为单一的代码即 harness 管道。
在行动侧，这是更广泛的 CodeAct 范式 [402] 在 GUI 领域的具体体现：智能体不再生成 JSON 工具调用，而是生成组合 click(x, y)、type(text)、scroll(dx, dy)、key("Enter") 等原语以及任意库调用（如 requests、subprocess、selenium）的 Python 或 JavaScript 代码片段。Cradle 通过让一个大语言模型输出驱动键盘和鼠标操作任意应用程序（包括 AAA 游戏）的可执行 Python，使这一点显式化，通过技能整理和自我反思而非特定任务 API 实现了对先前未见软件的泛化 [403]。WebArena、BrowserGym 和 TheAgentCompany 同样直接暴露以执行为基准的 Playwright 风格代码行动 [60, 398, 404]。
在感知侧，SeeClick、CogAgent、Ferret-UI、OS-Atlas、ShowUI、Aria-UI、UGround、UI-TARS 和 GUI-Libra 等近期原生 GUI 模型，将接地视为从像素到可执行坐标的函数，训练大型视觉语言模型生成 $(x, y)$ 或 bbox 令牌，这些令牌可直接传入行动 API [405, 399, 406, 407, 408, 409, 410, 411, 412]。通过将规划者→接地者→执行者管道压缩为单一 VLA 模型（其输出令牌流本身即为可运行代码），这些系统消除了历史上将语言规划与有接地性行动分离的脆弱字符串匹配层，正如 SeeAct 的分析所记录的——接地（grounding）而非规划（planning）才是 Mind2Web 上的主要瓶颈 [394]。
在评估侧，代码定义的环境支持可执行反馈：成功不由学习到的奖励模型判定，而是通过对行动后系统状态运行评估器脚本来确定。WebArena 的 URL/字符串断言、OSWorld 对操作系统文件 I/O 和应用状态的逐任务 Python 检查器、AndroidWorld 基于 adb 的状态检查，以及 Spider2-V 的企业工具检查，都体现了同一模式：评估器是一段代码，在智能体完成后审查程序世界 [60, 396, 391, 413]。这形成了闭环：代码生成环境，代码是智能体的行动，代码裁决结果。
记忆作为持久程序状态 对于以代码为接地的 GUI 智能体，记忆最好理解为持久程序状态层：结构化制品，生命周期超出当前 UI 状态，可在后续交互中被检索、组合或执行。近期研究探索了不同类型的记忆：（i）UI 状态的工作记忆将当前观测压缩为任务相关抽象：Synapse 的状态抽象模块将 HTML 过滤为少量任务相关元素，支持轨迹即示例提示以及通过相似度检索先前轨迹的示例记忆 [414]。（ii）长期跨应用/跨会话记忆以结构化文档和技能库的形式实现：AppAgent 为每个应用编译一份探索文档，记录每个 UI 元素的已学习功能，供后续任务查阅 [415]；Mobile-Agent-v2 引入了一个专用规划智能体，其记忆在子任务间跟踪长周期进展 [416]；Cradle 维护一个显式的技能整理模块，将成功的代码片段积累为可复用库 [403]。尽管这些设计与宿主应用的 UI 本体论紧密耦合，PlugMem 提出了一种与任务无关的插件记忆模块，将原始交互轨迹蒸馏为紧凑的以知识为中心的命题性与规范性知识记忆图，可无缝迁移到长周期对话和多跳检索 [417]，适用于 web 智能体。（iii）自演化 GUI 智能体（在本综述中已提及的 UI-Voyager [418]）以及 AutoGLM 通过在线课程强化学习扩展了这一理念，持续扩展有接地性行为的库；OS-Genesis 和 UI-TARS 则在数百台虚拟机上使用反射式轨迹收集，作为蒸馏记忆的一种形式 [419, 420, 411]。在这三种情形下，记忆本身都是代码制品——例如 JSON 文档、Python 技能模块，或代码格式化轨迹的向量索引——直接可执行，或直接可组合到智能体的下一个动作中。
UI 模拟器与沙箱作为可执行动态环境 GUI/OS 智能体的模拟器栈或许是该领域中环境动态本身即是代码这一论断最直观的体现。早期基准测试如 MiniWoB++ 将每个任务定义为一个独立的 HTML/JavaScript 页面并附带可编程奖励函数 [421]；WebShop 将其扩展至在自托管购物网站上包含 118 万件真实亚马逊商品 [422]。Mind2Web 缓存真实网站轨迹用于离线评估，而 WebArena 和 VisualWebArena 则将四个完整的开源站点 fork 进 Docker 容器，配以确定性重置和逐任务功能检查器 [59, 60, 423]。OSWorld 进一步将范围扩展至 369 个真实 Ubuntu/Windows/macOS 任务，运行于一次性虚拟机中，其初始状态、黄金动作及 Python 评估脚本均为版本控制制品 [396]；WindowsAgentArena 在 Windows 11 上以 Azure 并行执行实现了相同架构 [392]；Spider2-V 将 OSWorld 扩展至涵盖 BigQuery、dbt 和 Airbyte 的专业数据工程流水线 [413]。在移动端，AndroidWorld 提供了 116 个由自然语言模板动态参数化的可编程任务，奖励信号来自设备系统状态，AndroidArena 和 AndroidLab 则提供互补的跨应用评估 [391, 424, 401]。BrowserGym 和 WorkArena 将上述众多框架统一于一个 Gym 风格的 API 下，并新增了 23,150 个企业级 ServiceNow 任务实例 [398]，而 AgentBench 的 OS 和 Web 轨道以及 OpenHands 驱动的 TheAgentCompany 基准将 GUI 控制置于更广泛的知识工作仿真场景中 [425, 404]。最新的 Code2World 在模型层面明确了程序-世界立场：通过训练一个视觉语言编码器来预测下一个 GUI 状态为可渲染的 HTML，从而将世界模型本身变成一个可执行制品，并以渲染结果作为强化学习信号 [426]。综合来看，这些沙箱印证了本综述的核心论断：智能系统中的环境动态正越来越多地以代码形式编写——它们是可 fork、可 diff、版本可控、可复现的，这是任何学习型模拟器都无法比拟的。
从仿真到生产：可执行反馈（feedback）回路 使模拟器易于使用的代码即 harness 接口，也促成了异常迅速的生产部署跨越，因为智能体的输入/输出契约——截图输入、代码（或坐标类型的函数调用）输出——在两种场景下完全一致。Anthropic 的 Claude Computer Use 开放了一个公测 API，模型在其中拍摄沙箱桌面截图并将键盘/鼠标动作输出为结构化工具调用 [427]。OpenAI 的 Operator 及其底层的 Computer-Using Agent（CUA）随后跟进，将 GPT-4o 的视觉能力与通过强化学习训练的推理（reasoning）相结合，统一于点击/滚动/输入的动作空间 [428]。Google DeepMind 的 Project Mariner 提供了一个由 Gemini 驱动的 Chrome 扩展，能够观察渲染后的 DOM、进行规划（planning）并代表用户执行浏览器动作，目前正被集成进 Search 的 AI Mode 和 Gemini 应用 [429]。ByteDance 的 UI-TARS-1.5/2 及其关联的 UI-TARS 桌面产品、智谱的 AutoGLM（网页浏览器插件和安卓应用）以及腾讯的 AppAgent 系列证明，同一架构可从实验室迁移至消费端设备 [411, 419, 415]。AutoWebGLM 作为 CogAgent 的生产级兄弟，通过一个将规划（planning）与接地（grounding）解耦的”中间接口”，展示了从 arXiv 预印本到已部署浏览器智能体的完整路径 [430]。早期的工业探索，如 Adept 的 ACT-1/ACT-2 和 Rabbit 的 Large Action Model，预见了这一轨迹，但先于可执行反馈基础设施成熟到足以支撑部署的时代。
展望未来，文献在三个前沿方向上形成共识，均以代码即 harness 的术语来表达。第一，将感知、规划（planning）、接地（grounding）与动作内化于单一视觉语言行动（VLA）模型的原生端到端智能体，正在取代模块化的规划器+接地器流水线。第二，可执行世界模型承诺通过将下一个 UI 状态预测为可渲染代码（而非像素或非结构化文本）来赋予智能体类人的前瞻能力。第三，具身（embodied）、指令跟随的 GUI 智能体将整个设备（例如，终端、浏览器、原生应用和外设）视为一个统一的程序世界。这些方向的共同线索在于：代码是定义观测、动作、评估、记忆（memory），乃至世界模型本身的通用语言。
5.1.3. 自主具身智能体
具身智能体（embodied agent）在物理世界或其仿真环境中运行，通过视觉和力觉传感器的结构化输出感知环境，并通过受物理约束（如可达性、碰撞与动力学）约束的电机指令执行动作。
代码作为连接智能体与世界的控制边界 与纯粹的推理（reasoning）智能体不同，具身智能体（embodied agent）在物理约束下运行，违反约束时可能无声失败：机器人可能尝试抓取工作空间外的物体而不产生任何明确的失败信号 [431]。这将正确性的负担从运行时前移至动作生成时——智能体的输出在到达执行器之前必须已经具备足够的表达力来组合出经过验证的操作意图。代码天然满足这一要求，既充当接地（grounding）接口，也充当安全边界。作为接地（grounding）接口，它通过原语技能调用 [9, 110, 111, 112]、合成的 Python 控制策略 [10, 33, 124, 117, 118] 和结构化行为树程序 [34]，将大语言模型（LLM）的高层意图翻译为符合具身约束的指令。作为安全边界，它在执行时约束可接受的动作集合 [119, 116, 226]。
面向有接地（grounding）可验证（verifiable）具身动作的分层 harness 具身智能体（embodied agent）需要一个分层 harness，将语义推理（reasoning）与可执行的、受物理约束的、人类可治理的控制分离开来 [432]。基础模型负责具身能动性的语义层：解释目标、分解任务、推断可供性（affordance）、选择技能、提出动作，并在观测变化时重新规划 [433, 32]。代码和经典机器人软件通过暴露类型化的机器人 API、参数化原语技能、调用几何库、调用运动规划器以及支持检查、回放、版本控制和验证（verification），定义了可接受动作的边界 [124, 10, 434, 435]。感知模型和状态估计器将原始传感器流转换为规划器和控制器可使用的结构化状态 [436, 437]。物理系统和底层控制器则执行具身特有的约束，如运动学、动力学、避碰、工作空间限制、接触力、时序和稳定性。
可复用技能作为具身记忆（memory） 代码在将单一动作接地至物理可行性的同时，在长时域任务中运行的具身智能体（embodied agent）还必须跨任务积累经验。在这种情况下，代码扮演了第二个角色：使动作可验证（verifiable）的同一可执行形式，也使其可存储和可复用。记忆（memory）因此自然地以技能库（skill library）的形式呈现——一个记录过往行为、并可在未来任务中作为动作调用的代码制品集合。这种双重身份将具身记忆（memory）与第 3.2 节中的其他记忆（memory）抽象区分开来：技能不仅仅是智能体读取的内容，更是智能体重新执行的内容。Voyager 率先以不断增长的技能库（skill library）开创了这一范式，专为 Minecraft 中的开放式任务设计 [32]，其他工作沿多个方向扩展了这一思路：桌面操作 [114]、人工纠错 [121]、视觉接地（grounding）重规划 [122] 以及持续学习 [123]。这一原则甚至跨越进入了 GUI 领域 [418]。在所有这些系统中，挑战已从生成技能转移至治理技能库（skill library）：处理遗忘、抽象与接地（grounding）对齐。
协调且可审计的真实世界部署 从仿真迁移到真实世界部署带来了超越单一智能体的挑战：多机器人必须协调，行为必须可审计，技能必须跨具身形式迁移。代码自然地能够应对三者。在协调方面，它为多机器人策略合成 [118] 和机器人无关的协作架构 [120] 提供了基底。在可审计性方面，它支持工业安全的治理机制 [119, 235] 和经验证的闭环控制 [115]。在跨具身迁移方面，相同的基于代码的技能抽象使得在双臂机器人上实现组合复用成为可能 [111]。在减小仿真到现实差距（sim-to-real gap）、扩展（scaling）多智能体协调以及在环境演化时维护安全性方面，仍存在若干开放挑战。
5.1.4. 科学发现（scientific discovery）领域的程序世界智能体
科学研究是代码即智能体 harness 最自然的试验场之一：科学方法本身就是一个假设—设计—执行—观测—修订的闭环，每个跃迁都由一个制品（越来越多地是一段程序）所居中。现代科学已可以实现数字化的端到端闭合：假设被编码为微分方程或生成模型，实验协议以 XDL 或 Opentrons 脚本编写，仪器通过 Python API 驱动，分析运行于 Jupyter 笔记本中，其单元格构成可验证（verifiable）的推理（reasoning）轨迹。这使科学发现（scientific discovery）成为实例化代码三重角色的理想领域：代码作为推理（reasoning）的媒介（如符号推导、形式证明、程序作为假设），代码作为行动（acting）的基底（如调用湿实验机器人、模拟器、统计流水线），以及代码作为可执行环境本身（如分子动力学引擎、自主实验室、虚拟研究团队）。近期系统如 AI Scientist v1/v2 [63, 438]、AI co-scientist [439]、Virtual Lab [440] 和 Biomni [64] 通过将整个研究工作流（workflow）提升为单一的可执行程序图，使这一代码即 harness 框架更加具体。
科学发现（scientific discovery）作为部分可观测程序世界 我们将一个研究项目视为部分可观测程序世界 ⟨S, A, T, O, R⟩。状态 S 是一个结构化程序记忆（memory），包含当前最优假设、积累的文献、代码制品、中间数据集和实验观测。动作 A 是类型化的代码表达式：文献检索查询、调用符号或数值求解器、生成新实验脚本、修改训练流水线，或机器人控制命令。转移函数 T 由 Python 解释器、Lean 内核、量子化学包、机器人合成器实现，在完全端到端系统（如 AI Scientist v2 [438]）中则由一个统筹管理所有这些组件的树搜索实验管理器实现。观测 O 对应执行输出（数值结果、图表、错误信息、同行评审分数），而潜在奖励 R 编码诸如新颖性、可复现性和统计显著性等目标。至关重要的是，科学智能体的策略本身就是一段程序：ChemCrow [61] 通过结构化工具调用组合了 18 个专家设计的化学工具；Coscientist [62] 交替使用 Python 执行、网页搜索和机器人 API 动作；AlphaProof [441] 将每个”推理步骤”表达为一个 Lean 策略，证明助手在更新状态前对其进行验证（verification）。这一视角将传统上自然语言描述的类别（如假设、协议、主张）重新诠释为具体的程序对象，其执行轨迹可被记录、回放和审计。
统一构想、实验、分析与传播 传统科学描述将构想、实验设计、数据分析和成果传播分解为使用不同工具的独立工作流（workflow）。以代码为中心的智能体将这些折叠成单一的可执行流水线。ResearchAgent [442] 和 SciAgents 风格系统通过遍历文献实体图来迭代细化假设，每个候选想法被具体化为结构化对象，可传递给下游规划器（planner）。BioPlanner [443] 将湿实验协议形式化为伪代码，其可接受函数可被类型检查、检索和组合，为生物学提供了 XDL 为化学所提供的同等组合基底 [444]。Agent Laboratory [445] 及其预印本共享扩展 AgentRxiv [446] 将科研工作流（workflow）明确分解为文献综述、实验和报告撰写三个程序级阶段，由专业化的博士生、博士后和工程师智能体协作完成，互换 Python 文件、LaTeX 和 arXiv 记录。AI Scientist [63, 438] 更进一步，将整篇机器学习论文表示为单一的可执行轨迹：系统编写实验代码，由编程助手执行，用视觉语言模型读取图表，并生成包含其自产图表的 LaTeX 手稿。在所有这些系统中，曾经由自然语言制品构成的异构流水线，转变为由类型化代码对象构成的同构流，在每个阶段实现端到端优化和自动验证（verification）[447, 402]。
记忆（memory）作为持久程序状态 长时域研究依赖于记忆（memory）：先前的实验、失败的尝试、引用图谱和内隐的实验室知识。以代码为中心的智能体将这些记忆（memory）外化为持久程序状态。在工作记忆（working-memory）层面，智能体维护可执行的草稿板，通常是 Jupyter 内核或 CodeAct 风格的 Python REPL [448]，其实时变量、数据框和图表构成推理（reasoning）的即时上下文。El Agente Q [449] 和 Biomni [64] 体现了分层记忆（memory）：短暂的工具输出缓存于情节缓冲区（episodic buffer），而结构化制品（质粒图谱、优化几何构型、拟合模型）则写入持久文件存储，供后续智能体步骤重新加载。在长期记忆（long-term）层面，PaperQA / PaperQA2 [450] 和 Google 的 AI co-scientist [439] 将科学文献本身视为索引知识库，通过工具调用检索段落、扩展引用、检测矛盾；这使得在数百万条先前结果上进行假设评估成为可能，而无需膨胀提示词。AgentRxiv [446] 将这一思路更进一步，为自主研究智能体提供一个共享预印本服务器：由一次运行产生的假设、代码和发现被作为持久程序制品上传，供未来的运行构建，从而将累积的科学进展实例化为一个全局共享、版本控制的程序状态。Biomni 的动作发现智能体 [64] 挖掘数万篇 bioRxiv 论文，在 25 个生物医学子领域构建统一工具注册表，使”记住如何克隆一段质粒”成为从持久存储导入经验证代码级协议的具体行为。
模拟器作为可执行动态环境 科学智能体依赖于物理和计算现实的模拟器，代码即 harness 的视角将这些统一视为可执行的转移模型。在计算化学领域，El Agente Q [449] 将 DFT 引擎、几何优化器和热力学工具封装为大语言模型（LLM）可调用的函数，用于推演备选反应轨迹；在六个大学级基准上，它以超过 87% 的任务成功率运行，同时生成每次模拟的透明动作轨迹日志。ChemCrow [61] 类似地集成了 RDKit、逆合成引擎和反应预测器，使智能体能够在提交湿实验运行之前虚拟地”执行”候选合成路线。在结构和系统生物学领域，Virtual Lab [440] 将 ESM、AlphaFold-Multimer 和 Rosetta 组合成一个 Python 流水线，通过该流水线，一个大语言模型首席研究员智能体和其下属的科学家智能体联合设计了 92 种 SARS-CoV-2 纳米抗体，其中两种在 JN.1 和 KP.3 变体上验证了结合能力，整个过程仅用了几天的模拟会议时间。在算法和数学科学领域，AlphaProof [441] 将 Lean 定理证明器作为可执行环境，在将语言模型强化之前，正式验证每个候选证明步骤；AlphaEvolve [451] 则编排一个进化循环，在该循环中，Gemini 生成的代码编辑由自动评估器执行和评分，从而产生新的矩阵乘法算法和数学构造。在每种情况下，模拟器即是世界：程序状态仅通过经验证的执行演化，从而消除了困扰纯文本科学推理（reasoning）的大部分幻觉问题 [447]。
从仿真到生产：自动驾驶实验室（self-driving labs）作为可执行反馈（feedback）回路 科学智能体的决定性测试是其闭环是否跨越至物理现实的边界。自动驾驶实验室（SDL）是该领域的生产系统：它们通过代码 API 暴露真实仪器——液体处理器、XRD 扫描仪、光谱仪、机械臂——并将智能体生成的程序作为其主要输入。Berkeley 的 A-Lab [452] 结合机器学习合成配方与自主机器人，在 17 天的持续运行中从目标列表 58 种化合物中合成了 41 种新型无机化合物；早期薄膜 SDL [453] 确立了贝叶斯优化循环可以封装为 Python 服务并无人值守运行的范例。Coscientist [62] 通过在 Emerald Cloud Lab 和内部液体处理平台上，仅凭单个英文提示自主规划、执行和分析钯催化铃木（Suzuki）和薗头（Sonogashira）偶联反应，跨越了有机化学的这一门槛。Cronin 团队的 Chemputer 及其 XDL 化学描述语言 [444] 将这一契约形式化：文献中发布的任何合成都可以解析成硬件无关的 XDL 代码，该代码像面向化学领域的 LLVM IR 一样，可编译至任何兼容的机器人平台上运行。在生物学领域，Biomni [64] 生成端到端的分子克隆协议，人类评审者认为其水平相当于斯坦福资深博士后，而 Google 的 AI co-scientist 的药物再利用和抗菌素耐药性假设则在帝国理工和斯坦福的合作湿实验室中得到了实验验证 [439]。MatPilot [454] 将假设生成认知模块与驱动物理合成机器人的自主实验验证模块明确耦合，实例化了用于材料科学的完整生成—执行—反馈（feedback）回路。这些系统使本综述的核心论点变得有形可感：在自动驾驶实验室中，智能体的策略即是代码，实验室即是运行时，发表记录即是日志。
迈向可指令的科学 代码即 harness 科学智能体的最后一个维度是可控性：在保持严格执行语义的同时，以高层科学意图引导智能体的能力。基准测试迅速涌现以衡量这种能力。MLAgentBench [455] 在 13 个开放式机器学习研究任务上评估语言智能体，要求智能体读取代码、运行实验并改进指标。MLE-bench [456] 将其扩展至 75 个 Kaggle 机器学习工程竞赛；发布时最佳脚手架（OpenAI o1-preview 配合 Weco AIDE 树搜索智能体 [457]）在 16.9% 的竞赛中达到 Kaggle 铜牌水平，而 AIDE 的获奖率约为次优智能体的三倍。ScienceAgentBench [458] 汇编了 102 个改编自同行评审论文的任务，涵盖生物信息学、计算化学、地理信息系统和认知神经科学，将每个目标输出统一为独立的 Python 程序，这是代码作为数据驱动科学通用接口的明确背书。DiscoveryBench [459] 以 264 个跨六个领域的多步假设搜索任务对此进行补充，揭示了当前智能体的失败模式（最佳系统得分约 25%）。在可控性方面，指令跟随的进展体现在 AI co-scientist [439] 等系统中，科学家通过自然语言研究目标和约束来引导多智能体辩论；体现在 Biomni [64] 中，其图形界面接受自然语言查询并返回可审计的代码执行；体现在 Virtual Lab [440] 中，人类 PI 指定高层目标，AI PI 动态配置专业化智能体团队。AlphaEvolve [451] 和 AlphaProof [441] 代表了目标条件化的极端：智能体仅获得一个目标函数或定理陈述，闭合的代码执行循环搜索满足验证器（verifier）的任何程序。在这些系统中，指令跟随通过将用户目标转化为运行时可严格执行的类型化程序规范来实现。
综合来看，近期关于科学发现（scientific discovery）智能体的工作体现了本综述的核心转变：从静态预测走向交互式、有状态（stateful）、可执行的决策制定。假设不再是自由浮动的句子，而成为参数化程序；实验不再是实验室笔记本，而成为版本控制代码；分析不再是一次性脚本，而成为下游智能体可重新执行的可复现制品；实验室不再是不透明的物理场所，而成为通过文档化 API 可寻址的生产运行时。其结果是一个闭合的生成—执行—反馈（feedback）回路，其中单一基底——代码——承载着科学推理（reasoning）、科学行动和科学环境本身，为 AI Scientist [63, 438]、AI co-scientist [439]、Virtual Lab [440]、Biomni [64]、Coscientist [62] 和 AlphaEvolve [451] 等智能体提供了可相互比较、组合并持续改进的统一基础。正如 MLAgentBench [455]、MLE-bench [456]、ScienceAgentBench [458] 和 DiscoveryBench [459] 等基准所精确指出的那样，开放的挑战不是代码即 harness 的智能体能否模仿孤立的科学任务，而是它们能否被信任以完全自主地驱动完整的闭环——这一挑战，程序世界抽象同时提供了正确的本体论和正确的实验 harness。
5.1.5. 智能体个性化（Agent Personalization）
个性化（personalization）与推荐系统为以代码为中心的智能系统提供了一种独特的应用场景。与编程、GUI 控制或科学发现（scientific discovery）不同，这里的环境不仅是一个软件系统，还包括一个意图、满意度和长期目标只能被部分观测的人类用户。随着推荐系统从静态排序向交互式智能体转变，核心挑战变为：如何通过反复交互来维护、更新和治理用户模型。代码之所以有用，不仅仅因为它执行推荐策略，更因为它为偏好表示（preference representation）、反馈（feedback）处理、约束执行和策略适应提供了可检查（inspectable）的基底。
从静态推荐到交互式个性化（personalization） 传统推荐系统通常将个性化（personalization）视为预测问题：给定历史交互，系统对候选物品评分并返回排序列表 [460, 461]。基于大语言模型（LLM）的推荐系统通过支持对话式偏好获取、解释和多步精化来拓宽这一视野。早期基于提示的方法将大语言模型（LLM）与用户历史一起查询，要求其直接生成推荐 [462, 463]。更智能化的系统则将推荐分解为候选检索、过滤、重排序、解释和反馈（feedback）收集等环节。新兴的智能推荐方法 [464, 465, 466] 通过使用大语言模型（LLM）并借助工具调用和结构化中间状态来协调推荐子任务，实例化了这一方向。Agent4Rec [467] 和 iAgent [468] 进一步用合成用户模拟推荐会话，支持对交互策略的离线评估。这些系统标志着推荐从一次性评分向自适应过程的转变，每次交互都可能修正系统对用户的认知。
偏好状态作为可编辑制品 个性化（personalization）智能体与其他智能系统的关键区别在于：最重要的状态并非完全可观测的。用户偏好是潜在的、情境相关的且往往不稳定的。用户可能出于便利而非真正的兴趣点击某个物品，因时机不对而跳过某个物品，或在不同会话间改变目标。因此，个性化（personalization）智能体需要明确的偏好状态，既能吸收嘈杂的行为信号，又保持可解释和可纠正。以代码为中心的表示为结构化这种状态提供了实用方式。短期兴趣可以存储为近期交互日志、情境摘要或会话级偏好向量。长期偏好可以作为记录稳定兴趣、约束和用户提供的纠正的结构化记忆（memory）对象来维护。AMem [469] 及相关基于记忆（memory）的系统 [199, 470] 展示了如何将长期用户信息维护为可编辑文档或结构化记录。MemRec [471] 进一步研究了协作信号如何支持个性化（personalization）推荐的记忆（memory）管理。与不透明的纯嵌入记忆（memory）相比，结构化偏好记忆（memory）更易于检查、修改和复用。用户可以用自然语言纠正一个已存储的偏好，系统可以在生成未来推荐之前更新相应状态。
反馈（feedback）作为策略适应 个性化（personalization）智能体由反馈（feedback）驱动，但反馈（feedback）往往是稀疏的、延迟的且具有歧义性的。点击、停留时间、评分、购买、跳过和对话纠正都只提供关于用户满意度的部分证据。生产推荐系统已经依赖代码定义的反馈（feedback）流水线来记录交互、计算指标、运行 A/B 测试，并触发模型或策略更新。在智能化场景下，这些流水线成为个性化（personalization） harness 的一部分：它们决定记录哪些信号、如何解释它们，以及智能体何时应当适应。用户模拟器 [472, 473, 464] 提供了一种在受控行为假设下研究此类适应的离线方法，允许在真实部署前对推荐策略进行测试。近期基于大语言模型（LLM）的模拟器通过生成更丰富的合成用户档案和交互轨迹来扩展这一思路。然而，核心难点依然存在：模拟反馈（feedback）可能无法匹配真实用户行为，尤其当推荐本身会影响未来偏好时更为突出。
可控的、可指令的个性化（personalization） 智能个性化（personalization）的一个重要机遇在于：从优化隐式参与信号，转向遵循显式用户指令。用户可能希望获得满足特定约束的推荐，如避免某些来源、限制重复类别、平衡探索与熟悉度，或优先考虑长期目标而非短期参与。这些需求难以通过单一的学习评分来表达，但可以表示为结构化约束、过滤器或奖励函数。基于大语言模型（LLM）的对话推荐器可以用自然语言获取此类偏好，并将其转化为策略规范 [462]。基于约束的推荐进一步表明，公平性、多样性和曝光度要求可以在服务时执行，而非隐藏在模型参数中 [474]。基于解释的系统为可控性提供了另一条路径：如果系统解释了推荐某个物品的原因，用户可以纠正其理由，而纠正后的解释可以更新偏好状态。这使个性化（personalization）更具交互性和可审计性，因为用户可以塑造的不仅是输出，还有未来输出背后的逻辑。
个性化（personalization） Harness 的开放挑战 个性化（personalization）提出了若干比其他领域更为尖锐的挑战。第一，偏好接地（grounding）问题悬而未决。与代码助手（可依赖测试）或 GUI 智能体（可检查界面状态）不同，个性化（personalization）智能体缺乏可靠的真实用户满意度预言机（oracle）。点击量和参与度等代理指标在过度优化时可能产生误导甚至有害。第二，偏好记忆（memory）引入了隐私和治理风险。长期用户模型可能包含敏感的行为模式，因此 harness 必须明确规定存储内容、存储位置、更新方式，以及用户如何检查或删除这些数据。第三，个性化（personalization）本质上是多利益相关方的：平台可能优化参与度，创作者可能寻求曝光，用户可能重视福祉或自主性。将这些目标简化为单一奖励函数可能会掩盖利益冲突。
5.2. 开放问题
代码即 harness 系统将智能 AI 的核心挑战从孤立的模型生成转移到了完整执行回路的可靠性。一旦智能体通过工具、记忆（memory）、代码执行、共享状态和环境反馈（feedback）采取行动，故障可能源自弱验证器（verifier）、过时上下文、不安全的工具访问、不一致的多智能体状态、不足的多模态接地（grounding）或治理不善的自我改进。这些问题无法仅凭最终任务成功率来诊断。本节概述了当将 harness 视为一等系统组件，以构建在长时域真实世界环境中可执行（executable）、可检查（inspectable）、有状态（stateful）、可验证（verifiable）和受治理的智能系统为目标时，所浮现的关键开放问题。
5.2.1. Harness 级评估与预言机（oracle）充分性
一旦大语言模型（LLM）嵌入代码智能体 harness，评估便变得困难。在此场景下，性能不再仅由基础模型决定，还由周围的运行时决定：检索哪些代码仓库（repository）文件、暴露哪些工具、允许多少次重试、智能体是否能执行测试、失败如何汇总、以及哪个验证器（verifier）决定成功。然而，现有的大多数评估衡量的是端到端任务成功率：生成的解决方案是否通过测试、解决了某个问题，或完成了某个交互任务。这类指标混淆了基础模型的能力、harness 的质量、工具的可靠性、反馈（feedback）的信息量以及环境的难度。这在代码仓库（repository）级软件工程中尤为突出——智能体可能在利用薄弱或不完整测试套件的情况下通过可见测试；在 GUI/OS 任务中——脚本化检查器可能错过不安全或不期望的中间动作；以及在科学或具身（embodied）场景中——在模拟器中成功执行可能并不意味着结果在科学上有效或物理上安全 [216, 365, 364, 366, 133, 458]。
因此，一个关键的开放问题是定义 harness 级指标，以评估操作基底本身。这些指标应以执行可靠性、反馈（feedback）质量、上下文可持续性、安全性、协调性和可复现性的测量来补充最终任务准确性。有用的维度包括：(i) 轨迹效率，如工具调用次数、令牌数、执行次数和挂钟时间；(ii) 验证强度（verification strength），如测试覆盖率、预言机（oracle）多样性和假阳性率；(iii) 恢复能力，如智能体能否在无效动作后诊断并修复故障；(iv) 状态一致性，如记忆（memory）、代码仓库（repository）状态、执行轨迹和智能体信念是否保持同步；(v) 安全合规性，如权限、沙箱和人工审批门控是否被遵守；以及 (vi) 可回放性，如完整轨迹能否从日志和制品中重建与审计 [475]。这一议程的核心瓶颈是预言机（oracle）充分性：评估器是否捕捉了预期任务而非仅是一个狭义的可执行代理。开放问题不仅仅是构建更难的基准，而是将代码智能体 harness 作为可执行运行时系统来评估。
5.2.2. 超越可执行反馈（feedback）的语义验证（verification）
预言机（oracle）充分性问题在可执行反馈（feedback）方面尤为突出——尽管可执行反馈（feedback）是以代码为中心的智能体的核心，但它可能制造一种虚假的正确性感：代码可以运行，轨迹可以检查，测试可以通过，故障可以回馈给修订过程。然而，执行的可靠性仅与附加的预言机（oracle）一样强。单元测试可能不完整，静态分析器可能存在过近似，GUI 检查器可能错过不可接受的中间动作，科学脚本可能编码无效假设，而机器人模拟器可能隐藏物理风险。因此，harness 可能恰恰因为拥有可执行反馈（feedback）而变得过度自信：智能体看到测试通过了，但通过的测试并不是完整的规范。
核心缺失的抽象是一个具有明确作用域的验证（verification）栈。与其将通过/失败视为单一的终端信号，未来的 harness 应当组合多种验证（verification）制品：单元测试、集成测试、基于属性的测试、模糊测试器、覆盖率报告、形式规范、静态分析器、类型检查器、安全扫描器、运行时监视器、模型评审和人工审查。每种制品都应声明其验证内容、无法验证的内容以及提供的置信度。这对于自修复和自演化 harness 尤为重要：若验证器（verifier）薄弱，智能体将学会对错误信号进行优化。一个有益的方向是使每个被接受的动作都携带一个证据包，包含运行的检查项、保留的假设、未经测试的区域以及剩余风险。在这种视角下，验证（verification）不是最终的关卡，而是智能体（agent）、harness 与环境之间一份持续演进、可检查（inspectable）的契约。
其他有前景的方向还包括：反馈（feedback）校准、独立验证、变形测试、差分测试、基于属性的测试生成、执行轨迹摘要以及不确定性感知评审 [476, 477, 478]。可靠的反馈还应根据类型以不同方式路由：编译器错误可触发局部语法修复，测试失败可触发行为诊断，覆盖率缺口可触发测试生成，而评审意见不一致则可触发仲裁。更宏观的目标是构建反馈闭环——这些反馈不仅是被动响应，更应具备认识论意识：harness 应当知晓某个信号何时强到足以触发行动、何时仍属微弱，以及何时需要补充证据。
5.2.3. 无回归的自演化 Harness
当前大多数 harness 都依赖人工设计：开发者手动选定规划（planning）循环、记忆（memory）格式、工具集、权限规则、调试流程和智能体拓扑。然而，随着任务越来越复杂多样，固定不变的 harness 可能趋于次优。适用于竞赛编程的 harness 未必适合代码仓库（repository）修复；为图形界面导航调优的 harness 可能不适合科学工作流（workflow）；在某类任务分布上表现出色的多智能体（multi-agent）拓扑，换一个任务分布可能白白浪费算力。这表明，未来系统应将 harness 本身视为可编程组件，使其能够适应新环境，而非仅仅作为基础模型外层固定的封装。
自动化 harness 演化已初现端倪。AutoHarness 能综合生成用于约束无效动作的代码 harness [14]，MetaHarness 在 harness 代码空间上进行搜索 [13]，Agentic Harness Engineering 从可观测性信号中演化 harness 组件 [281]，相关方法还通过反思、搜索或执行反馈优化提示、上下文和工作流 [18, 312, 17]。这些系统共同指向一种更宏观的范式：由某个统筹性优化过程分析运行时反馈——包括计算开销、决策路径、工具使用轨迹、记忆压力和具体失败案例——并提出对 harness 自身的修改建议。此类修改可重组子智能体之间的通信、调整记忆分配、修订检索或验证策略，或改变执行反馈在系统中的路由方式。因此，”自动化 harness 演化”本身并非开放问题（open problem）所在；真正困难的问题在于：harness 能否在不过拟合、不削弱安全性、不增加成本、不掩盖失败、不在罕见但重要的任务上发生回归的前提下实现自我改进。
核心洞见在于：harness 的变更应被视为对安全关键运行时的代码修改。每项拟议的编辑都应携带一份变更契约，说明：修改的是哪个组件、针对的是哪种失败模式、预测的改进是什么、必须保持的不变量有哪些、哪种评估方式可以证伪该契约，以及如何回滚。这一点尤为重要，因为 harness 的变更会影响智能体行为的未来分布：新的检索策略可能在提升基准精度的同时增加幻觉证据；新的工具模式可能在降低 token 开销的同时削弱权限边界；新的验证器可能在提高通过率的同时接受了质量低下的解决方案。未来的工作应致力于开发携带证据的 harness 演化机制，包括：留存回归套件、安全不变量、金丝雀部署、回滚语义，以及为何某次 harness 编辑确实有效的因果证据。目标不是让 harness 频繁变动，而是让每一次变动都有充分的理由支撑。一个实用的研究议程包括：为 harness 组件定义变更算子；建立遥测标准；在多样化任务上评估演化后的 harness；在演化过程中强制执行安全不变量；以及将 harness 的改进与基础模型的改进区分开来。
5.2.4. 事务性共享程序状态与语义冲突消解
从单智能体扩展（scaling）到多智能体系统，代码仓库便成为一个共享的 harness 基底。规划者、编码者、测试者、评审者、安全智能体以及人类可能同时读写相互重叠的制品。前几节已指出，许多系统仍依赖顺序交接、共享日志或纯文件状态，而较新的系统则引入了黑板、仓库记忆、执行反馈以及显式信念状态同步 [330, 55, 50, 250, 347]。开放问题在于：单靠同步无法提供事务语义或假设层面的一致性——这些机制往往只同步制品，而非假设。一个智能体可能基于旧版仓库快照进行规划，另一个可能测试了一个更新的补丁，第三个可能记住了一条已过时的不变量，而人类评审者可能引入了一条新约束却未传播到系统其余部分。
缺失的抽象是事务性共享程序状态。智能体不应仅仅向公共日志追加消息；每个动作都应声明其读集、写集、假设、版本依赖、验证义务以及冲突策略。冲突检测不应仅在文件差异层面，还应延伸至规划、测试、检索证据、权限、记忆条目以及潜在用户需求层面。未来的 harness 需要语义层面的冲突消解机制，而不仅仅是文本层面的，包括：语义合并、回滚、感知依赖的锁定、信念状态协调、冲突解释以及合并后的重新验证。传统版本控制、数据库、CRDT 和构建系统提供了有益的类比，但智能体系统还会产生传统工具看不到的冲突：不兼容的规划、过时的记忆、重复的子任务、不一致的工具权限，以及对用户目标的分歧性诠释。一项关键的研究挑战是：判断何时冲突可以自动消解、何时需要外部人工判断。此类机制还需要超越合并正确性的度量标准，包括：合并成功率、语义回归率、回滚频率、冲突复发率，以及人工干预的成本。
5.2.5. 人在回路中的安全性与问责制作为 Harness 状态
随着代码即智能体 harness 系统被越来越多地应用于高风险场景，安全性不能仅依赖基础模型，也不能仅以自然语言指令的形式编码。在软件部署、网络安全、金融、医疗、科学实验、企业自动化和具身控制（embodied agent）等关键领域，智能体动作可能影响生产系统、私人数据、外部用户、物理设备或机构合规。因此，harness 不仅需要发挥上下文管理器和工具执行器的作用，还需要作为模型意图与真实世界后果之间的安全治理者。它应当按风险对拟议动作分类、强制执行权限分级、拒绝违反硬约束的动作，并对不可逆或存在重大后果的状态转换要求人类审批。例如，当智能体请求凭证、修改安全关键代码、访问用户数据、部署服务、发出金融或医疗建议，或控制物理设备时，harness 应能覆盖基础模型并暂停自主执行，直至人类做出决策 [52, 263, 119]。
未来的 harness 需要明确的治理机制，以调节模型意图与环境动作之间的关系。一种有用的设计模式是多层权限模型。最低层，智能体可以读取文件、检查日志、运行静态分析；较高层，它们可以编辑本地文件、执行沙箱代码、访问网络、调用外部 API、修改共享仓库或影响生产系统。每一层都应指定允许的动作、约束条件、审计日志、回滚机制，以及针对高风险操作的人在回路中的门控。此类治理还必须对上下文敏感：同一条命令在一次性沙箱中可能是安全的，在生产仓库中则可能是危险的；同一条网络请求在文档检索时可能无害，在传输本地状态时则可能有风险。因此，权限不仅取决于工具身份，还应取决于参数、环境状态、数据敏感性以及预期副作用。开放问题包括：策略规范、副作用预测、沙箱逃逸防护、密钥处理、安全工具模式、可逆执行，以及在自主性与安全性之间权衡的度量。
这一安全角色同时也改变了人类反馈应如何表示的方式。人在回路（human-in-the-loop）控制不应仅以偶发的提示中断形式出现，而应成为持久的 harness 状态。每一次审批、拒绝、策略例外或评审修正，都应更新 harness 的权限规则、升级策略、验证标准和未来的记忆检索。同样，高风险审批应是可审计的状态转换：记录提出了什么动作、展示了什么证据、浮现了什么风险、谁批准或拒绝，以及之后责任边界如何变化。开放问题是：设计出能够判断何时自主执行是恰当的、何时必须有人类判断介入的 harness。在这种视角下，可靠的代码即智能体 harness 系统不仅需要可执行代码和可验证的反馈，还需要可执行的问责制：一个在智能体动作到达真实世界之前对其进行过滤、否决、升级和记录的安全层。
5.2.6. 多模态代码 Harness 系统
目前大多数代码智能体 harness 仍围绕文本状态设计：提示、文件、日志、工具输出、测试和执行轨迹。然而，许多新兴的智能体系统运行在关键状态为多模态的环境中。图形界面（GUI）智能体观察截图、可访问性树和渲染后的界面状态；具身智能体依赖以自我为中心的图像、深度信息、力觉信号、物体姿态以及模拟器或机器人状态；科学智能体检查图表、显微镜图像、分子结构和实验读数。在这些场景中，harness 不能再将感知视为被动地输入给模型的信息，而必须将多模态观测作为持久化、可查询、可验证的状态进行管理。
一个核心挑战是多模态上下文压缩。视觉观测体量庞大、冗余严重，且往往只与任务部分相关。一张 GUI 截图可能包含数百个元素，而只有一个按钮是关键的；一段具身轨迹可能包含数千帧，而只有少数几帧揭示任务关键的目标关系、接触事件或失败原因。未来的 harness 需要能够保留任务相关视觉证据、而不仅仅是压缩 token 开销的压缩机制。这催生了一种多层记忆设计：原始图像或帧作为不可变证据存储；目标级、区域级、元素级和姿态级标注提供结构化的中间状态；紧凑的文本或符号摘要只暴露技能检索和规划所需的信息。开放问题在于：应保留、抽象、遗忘还是将哪些多模态信息晋升至长期记忆，尤其是当后续失败揭示某个早期的视觉或物理细节至关重要时。
视觉接地（grounding）引入了第二个挑战：将观测与动作对齐。在以文本为中心的 harness 中，动作往往可以对照文件、命令或测试结果进行检验。而在视觉环境中，智能体必须将语言目标映射到图像区域、界面元素、物体、坐标、姿态和可执行动作。GUI 智能体必须知道一次规划中的点击对应到正确渲染的按钮；具身智能体必须知道一次抓取命令的目标是在当前摄像头视角和物理构型下的预定目标。这需要 harness 层面的接地契约，将感知、动作和验证关联起来。每个动作不仅应携带自然语言理由，还应携带一个接地引用——指向其所依赖的证据，例如边界框、目标标识符、UI 元素、帧索引、区域特征、目标位置或朝向。执行完成后，harness 应验证预期的接地状态是否如期变化，而非仅依赖模型的自我报告。
在多模态场景中，可靠的反馈也更难获取。文本错误信息或单元测试失败提供的是明确信号，而视觉和物理反馈往往是隐式的、延迟的或模糊的。一个按钮可能看起来已被点击，但实际上未触发正确的状态转换；机器人可能看似持住了物体，但抓取并不稳固；图表可能看似支持某个结论，但坐标轴刻度改变了解读。因此，未来的 harness 需要多模态验证栈，结合视觉状态检查、目标追踪、OCR 或 UI 树检查、模拟器状态、物理传感器、触觉反馈和任务特定验证器。更重要的是，每个反馈信号都应暴露其作用范围和不确定性：例如，边界框检测器验证定位但无法验证任务完成；模拟器状态验证目标位置但不保证物理鲁棒性；OCR 结果验证视觉文本但不保证语义正确性。这同时也呼唤世界建模与动作建模之间更紧密的整合：harness 应预测视觉或物理世界在某个动作后预期如何变化，将该预测与观测到的结果对比，并利用差异来诊断失败。在具身和机器人场景中，这类预测误差信号对于恢复尤为重要，因为失败可能源于遮挡、打滑、碰撞、不可达姿态或前置条件违反，而非来自显式错误消息。将多模态反馈视为经过校准的证据而非二元成功信号，对于安全的长时域自主执行至关重要。
多模态记忆还应支持技能演化。在以视觉为主的领域，如 GUI 控制和具身操作，可复用的技能不能仅以文本或代码片段表示。一个有用的技能往往将多模态前置条件、可执行动作模式和预期后置条件耦合在一起：智能体在行动前应看到什么、应执行什么程序、UI 命令或电机原语，以及应随之发生什么视觉、物理或状态变化。例如，一个 GUI 技能可以编码：如何从截图中定位设置菜单、点击正确区域，并验证新面板出现。一个具身技能可以编码：如何识别可抓取目标、选择接近姿态、执行原始控制器，并通过视觉、力觉或触觉反馈确认目标已移入夹爪。此类技能应从成功轨迹、失败尝试和人类修正中演化，同时保留其接地证据。harness 必须因此决定：视觉-动作模式何时可复用、应以多高的抽象度存储，以及如何跨布局、视角、具身形态、传感器和任务进行适配。
5.2.7. 走向 Harness 工程的科学
综合来看，这些开放问题表明，代码即 harness 研究正朝着一门更宏观的 harness 工程（harness engineering）科学演进。研究对象不再仅仅是模型或生成的程序，而是完整的闭环系统：上下文、记忆、工具、执行、反馈、安全性、协调与评估。取得进展需要：能够暴露长时域失败的基准测试、使轨迹可审计的遥测系统、能够分离 harness 组件贡献的度量指标，以及使智能体能够在持久化程序世界中安全运行的设计原则。
最重要的未来系统将很可能兼具四项属性。第一，它们将是可执行的（executable），将决策接地到代码、工具、测试和环境中。第二，它们将是可检查的（inspectable），暴露规划、状态、来源和失败原因。第三，它们将是有状态的（stateful），在长时域轨迹和多个智能体之间保存任务相关信息。第四，它们将是受治理的（governed），确保自主性受到权限、验证和问责制的约束。这四项属性共同定义了可靠的长时域智能体 AI 的下一个前沿。
参考文献
(参考文献列表共约 35 页,请参见原文 PDF 第 67–102 页,此处不再翻译。)