从问答到任务完成：智体系统与驾驭设计的综述（下）
26年6月来自港城大、悉尼大学和上海TokenRhythm 公司的论文“From Question Answering to Task Completion: A Survey on Agent System and Harness Design”。
基于大语言模型（LLM）的智体标志着从被动问答向主动任务完成的转变：它们能够感知环境、调用工具、维护状态，并跨越较长的时间跨度执行操作。随着智体系统从提示工程（prompt engineering）演进到工作流与上下文工程、驾驭（harness）工程以及伴随协同进化的智体原生训练，一个核心问题日益凸显：智体性能的瓶颈究竟何在——是源于基础模型、驾驭，还是两者之间的耦合关系？本综述从“模型-驾驭”的视角审视基于LLM的智体。
首先明确智体的功能定义，并从实现层面将其界定为“基础模型与驾驭相耦合”的系统。随后，分析以模型为中心的扩展（scaling）所面临的局限性，梳理了智体工程的四种范式，并将驾驭拆解为六项相互耦合的运行时职责：感知、上下文、控制、行动、状态以及验证/治理。基于这一拆解，将任务特性与域需求映射到驾驭配置上，回顾了基准测试与评估实践，并综合分析关于运行时设计如何影响长程任务完成、效率及可靠性的“模型-驾驭”相关证据。最后，指出在价值感知评估、安全性、驾驭泛化能力以及模型-驾驭协同进化方面尚待解决的挑战。本综述主张，不应将智体简单视为配备辅助工具的模型；相反，智体的质量（涵盖成功率、效率、安全性和泛化能力）源于模型能力、运行时基础设施、任务结构与评估设计之间的相互作用。
。。。。。。继续。。。。。。
“驾驭工程”（Harness engineering）将优化目标从孤立的提示词（prompts）或工作流转向了负责稳定智体（agent）执行过程的运行时（runtime）。基于形式化定义，该运行时可分解为六个组件：H = ⟨I_obs, C, L, I_act, S, V⟩。这种分解并非旨在呈现软件架构图，而是为了明确运行时所承担的关键职能——这些职能反复决定了模型的能力能否转化为可靠的任务执行结果，具体包括：模型的观测内容、进入上下文的信息、执行推进的方式、可用的动作、持久化的状态，以及运行过程的检查或约束机制。
1 观测接口
观测接口（I_obs）决定了哪些环境信号会呈现给模型，以及这些信号如何被呈现。它将外部状态（如终端输出、文件差异、屏幕截图、Web DOM、API 响应、事件流和日志）转换为当前模型调用可处理的观测信息。其设计空间涉及三个反复出现的问题：哪些状态是相关的？应以何种抽象层级表示这些状态？何时应刷新观测信息？这些选择至关重要，因为许多长程任务中的失败不仅仅源于推理失误，还源于状态的可读性问题：所需状态缺失、淹没在噪声中、已过时，或者其表示方式无法支持下一步的决策。一些代表性系统具体印证了这一点。SWE-agent 表明，在基础模型不变的情况下，重新设计智体与计算机之间的接口可以显著提升编码智体的性能 [21]。在 Web 和桌面应用场景中，WebArena 和 OSWorld 等基准测试同样揭示任务成功与否取决于能否将视觉和结构上复杂的接口状态转换为模型实际可用的形式 [17], [18]。因此，总体原则并非呈现所有可用状态，而是以忠实且可用的形式呈现与决策相关的状态。这里主要的权衡在于信息的丰富度与可处理性：丰富的观测信息有助于增强模型对环境的理解（grounding），但会增加上下文成本和干扰因素；压缩后的观测信息更易于处理，却可能丢失对任务至关重要的关键信息。一个尚未解决的难题是：如何设计出在部分可观测性、多模态状态及长程交互轨迹下，既能保持信息忠实度又能提供决策价值的观测接口。
2 上下文管理器
上下文管理最初是智体工作流中的核心关注点。在智体驾驭中，它与观测、控制、动作、持久化及验证机制并列，成为关键的运行时组件之一。上下文管理器C 决定了哪些可用信息以何种形式进入当前的模型调用。在将观测信息、工具输出、检索到的证据、记忆记录、摘要、指令及任务产物转化为下一步操作所需的“工作上下文”之前，上下文管理器负责对其进行筛选、压缩、排序和刷新 [142], [166]–[168]。其主要设计选择涉及内容的纳入、表征方式、更新策略，以及向活跃智体或子智体暴露的共享状态量。正如“上下文工程”（context engineering）所指出的，长程任务的性能表现更多取决于能否在时间推移中维持连贯的任务状态，而非仅仅增加提示词（prompt）的长度 [29], [144], [169]–[171]。
几种实现模式反复出现。基于检索的系统按需引入外部文档或存储的状态。以记忆为中心的系统（如 MemGPT）将活跃上下文与更大的外部存储区分开来 [31]。工业级应用越来越多地将任务状态外部化为显式构件（artifacts），并有选择地重新调用这些构件，而不是依赖单一且不断增长的对话记录 [146]。主要的权衡在于保真度与可管理性之间：原始历史记录保留了细节但扩展性差，而摘要和检索的上下文成本较低，却可能遗漏或扭曲重要状态。因此，关键区别不在于提示词的长短，而在于上下文是“整体式”（monolithic）的还是“受控式”（managed）的。一个关键的未决问题是：如何在保持上下文成本可控的同时，确保摘要的忠实度和状态的完整性——尤其是在长程任务场景下，上下文修复需要与验证及恢复机制协同工作时 [172]。
3 控制循环
控制循环 L 负责组织跨步骤、工具及可能的任务交接（handoffs）的执行过程。它将观察、推理、行动和反馈转化为一个可运行的流程。该组件决定了智体遵循何种模式：是简单的“感知-动作”循环、ReAct 风格的循环、“规划-执行-验证”流程，还是分层及多智体的工作流 [38], [108], [136]–[138]。主要的设计考量包括：模型与运行时（runtime）之间如何分配控制权，何时创建或修订规划，何时引入任务委派，协调是串行还是并行进行，以及何时终止执行。长程任务的成功不仅取决于模型的推理质量，还取决于运行时能否在不确定性环境下保持执行的稳定性。
现有系统在这一设计空间中占据着不同的位置。有些系统保留了轻量级的迭代循环，而另一些则强制采用明确的“规划器-执行器-验证器”分解模式或多智体协作机制。近期以“驾驭”（harness）为导向的研究将编排本身视为优化目标：例如，NLAH 将控制逻辑视为可编辑的构件，而 Meta-Harness 则将控制配置视为可搜索的设计空间 [23], [24]。因此，这一层面的设计不仅仅是增加步骤，更在于决定在执行轨迹上施加何种程度的结构约束。其中主要的权衡在于适应性与稳定性之间：更自由的循环能够应对意外状态，但也更容易出现行为漂移、重复失败及协作开销；而更强的编排机制虽能提高可靠性，却可能降低效率或过度限制探索空间。一个持续存在的挑战在于设计控制策略，使其在不同的时间跨度和应用领域内保持鲁棒性，同时避免让任务委派、验证及恢复过程的代价变得过高。
4 动作接口
动作接口 I_act 负责将模型输出映射为可执行的操作。它定义了智体能做什么、如何指定动作、适用何种权限，以及动作结果如何作为后续观测信息返回。近期关于工具使用的研究进一步表明，动作接口的质量是决定智体可靠性的关键因素。针对工具调用失败的诊断分析发现，智体失败的原因往往并非缺少工具，而是工具选择不当、调用方式有误，或是工具未能有效融入执行轨迹之中 [173]。ET-Agent 探讨针对工具集成推理的行为校准问题 [174]，而 ToolTok 则将工具表示为 Token，以提升 GUI 智体的效率与泛化能力 [175]。
从驾驭的角度来看，这一层决定了智体的有效动作空间。其设计空间涵盖了工具粒度（底层环境与高层 API）、工具规范（自由格式指令与结构化模式）、路由与互操作性（本地工具与基于协议的生态系统，如 MCP）以及治理机制（权限、副作用控制及调用约束）。现有研究表明，性能不仅取决于工具是否存在，更取决于动作接口如何确保这些工具易于使用、组合及治理。
典型的实现形式多种多样，从终端和浏览器到结构化的可调用 API 均包含在内。 SWE-agent 是“观察-动作”协同设计的典型范例：重新设计智体与计算机之间的接口，既改变了模型的感知内容，也改变了其行动方式，从而在基础模型不变的情况下提升了性能 [21]。诸如 MCP 之类的协议导向型基础设施，推动了跨异构服务的工具访问向标准化接口层转变 [65]；而 MCPWorld 和 OSWorld-MCP 等基准测试则用于评估智能体能否在真实环境中可靠地调用此类服务 [147], [150]。其中主要的权衡在于灵活性与可控性：底层工具通用性强但难以稳健使用，而高层工具提高了可靠性，却可能过度限制智能体的行为。一个悬而未决的问题是：当工具使用与长程任务中的验证、沙箱隔离及恢复机制相结合时，应如何设计既具备表达力又易于管控的行动抽象。
5 状态与制品存储
状态与制品存储（State and Artifact Store）组件 S 负责跨步骤、跨会话及跨子任务持久化保存执行状态。它通过存储任务进度、执行轨迹、规划、检查点、差异（diffs）、生成文件、记忆记录及其他可复用制品，提供了超越当前上下文窗口的连续性。其设计考量涵盖了存储状态的粒度、持久化范围、存储形式以及更新策略。长程智体往往失败，并非因为未存储状态，而是因为保存了错误的状态、无法检索到所需状态，或者将过时状态误视为当前状态。
文献中反复出现了几种策略。一些系统依赖于会话级历史记录和检查点存储。面向记忆的方法（如 MemGPT）引入了超越当前上下文的显式长期记忆 [31]。以制品为中心的驾驭（harness）则通过日志、差异、检查点及可审查的运行时对象来追踪状态 [146]。这些方法的共同点在于，它们都从瞬时的交互轨迹转向了可复用的系统状态。主要的权衡在于完整性与易用性：更丰富的状态能提升连续性、可审计性及任务交接能力，但也会增加检索负担与噪声，并带来记忆过时的风险。实际挑战不在于存储更多内容，而在于决定哪些内容值得持久化保存、哪些应当压缩，以及哪些应当舍弃。一个重要的未决问题是：如何在支持回滚、委托和记忆重用的同时保持状态保真度，且不积累偏差或过时信息 [172]。
6 验证与治理
验证与治理层（V层）在运行时对执行过程进行检查、约束和修复。验证机制包括测试、断言、验证器模型、判定信号以及其他用于评估执行是否按预期推进的手段。治理机制则涵盖审批关卡、沙箱隔离、预算控制、回滚、重试、上报以及安全终止等措施。这一视角在近期的多智体治理研究中得到了体现。例如，“AI委员会”（AI Committee）利用多个智体对网络来源的数据进行验证与修正 [151]；而“行动或拒绝学习”（act-or-refuse learning）则研究智体在安全的多步骤工具使用过程中，应何时采取行动、保持中立或停止操作 [176]。这些例子表明，治理不仅是一种部署层面的约束，更是智体执行过程中一个明确的决策层。这两者紧密耦合：验证过程产生关于运行情况的证据，而治理机制则决定了驾驭（harness）被允许或被要求如何利用这些证据。因此，可靠的智体不仅依赖于强大的推理能力和丰富的工具支持，还取决于检查与约束机制是否得到强制执行，而非仅仅依赖于智体对提示词（prompt）的顺从。
一些代表性系统清晰地展示了这种双重角色。在编程智体中，测试、代码检查工具（linter）和断言提供了相对强有力的验证信号，而回滚和沙箱执行机制则用于控制副作用 [16], [20]。在网络、桌面及其他开放式环境中，治理的作用更为关键，因为其中的操作可能具有部分不可逆性，且往往缺乏清晰的判定依据（即“干净的预言机”/clean oracles）[17], [18]。这里主要面临的是自主性与鲁棒性之间的权衡：较宽松的约束允许更广泛的探索，但也增加了有害行为和不可恢复偏差的风险；而较严格的治理虽能提升安全性和可恢复性，却可能拖慢执行速度或阻碍有益行为。一个亟待解决的问题是设计出具有选择性且兼顾成本效益的验证与治理机制，使驾驭（harness）能够区分“可恢复的局部错误”与“深层的任务级崩溃”，从而避免频繁触发不必要的中断或回滚。
7 驾驭中的跨层交互
尽管上述六个组件在分析层面上是可区分的，但它们并非独立运作。某一组件的设计决策往往会改变其他组件所承担的负担。观测接口 I_obs与上下文管理器 C 紧密耦合：更丰富的观测信息虽能改善“落地”（grounding），但也增加了信息进入活跃上下文之前的选择、压缩及格式化成本 [125]。动作接口 I_act 直接与验证及治理模块 V 交互：表达能力更强的动作能扩展系统能力，但也需要更严格的权限控制、沙箱隔离、回滚机制及审计功能。状态与制品存储 S 会反向作用于上下文和验证环节，因为持久化的计划、日志、检查点及制品，既决定了哪些信息能重新呈现给模型，也决定了评估进展时可利用何种证据 [31], [172]。
因此，驾驭（harness）的设计是一个系统耦合问题，而非六个模块各自独立优化的过程。改进某一层可能会将风险转移至其他环节：更强的压缩虽能降低成本，却可能削弱下游的验证效果；更丰富的动作虽能提升任务覆盖率，却会增加治理压力；更持久的状态虽能增强连续性，但也可能引入过时或相互冲突的证据。这种耦合性使得任务结构本身也成为了驾驭设计的一部分。不同的领域、时间跨度、预言机（oracle）能力及自主性要求，会对 I_obs、C、L、I_act、S 和 V 施加不同的压力分布。因此，这种统一的架构模式也成为了一种解读任务全貌的视角：任务之间的差异，体现在它们侧重于哪些运行时职责，以及哪些配置选项起到了决定性作用。
任务结构决定了执行驾驭（execution harness）的哪些部分成为性能关键点。从驾驭的构成来看，任务不仅仅是一个应用标签，更是一组涵盖观测、上下文、控制、动作、状态和治理维度的压力特征。长时程（long horizons）、部分可观测性、弱反馈、不可逆动作以及自主性要求，会将压力转移到不同的配置选择上，例如上下文选择、动作抽象、验证循环、检查点、权限关卡和升级规则。因此，核心问题在于：在特定的任务条件下，哪种运行时职责会成为制约因素。
1 基于驾驭-觉察的任务分类法
智体任务不仅因应用标签而异，更因其结构属性而不同；这些属性决定了驾驭中的哪些组件会制约性能、可靠性、成本或安全性。利用三个维度来刻画这些压力：任务时程、环境类型和自主性水平。这三个维度共同确定了主要瓶颈，即故障最常集中的那个组件或少数几个组件。
复杂性与任务时程。有四个粗略的层级，其中从L2到L3的转变通常最为关键。单步任务和短时程多步任务往往可以通过局部推理、轻量级动作访问和局部检查来处理。长时程任务会对上下文管理器（Context Manager）、状态与工件存储（State and Artifact Store）以及控制循环（Control Loop）产生持续压力，因为规划、中间工件、失败尝试和部分结果必须在单个提示词窗（prompt window）之外保持有效。在L4层级，开放式监控或探索任务还需要预算控制、停止标准和升级策略，从而将瓶颈从单纯的生成质量转移到显式的验证与治理环节。
环境类型。环境类型决定了驾驭必须观测什么以及能够暴露哪些动作 [177]–[183]。终端（terminals）和代码仓库（repositories）会对动作接口、观测接口以及验证与治理组件施加压力，因为命令、差异（diffs）、日志和测试往往可以封装为结构化的动作、观测和验证信号。浏览器和桌面环境则引入了视觉或DOM层面的基础关联（grounding）、会话状态以及持久性副作用，从而增加了在观测构建、动作抽象和权限边界方面的压力。知识环境（包括网络搜索、文献检索和结构化数据库）将瓶颈转移到了“上下文管理器”以及“状态与工件存储”环节，因为其主要挑战在于管理证据的质量、来源及综合分析。物理环境引入了实时性约束和不可逆性，使得“控制回路”以及“验证与治理”机制比纯数字环境更为关键。社会环境则增加了规范、协商及策略性应对等因素，从而提升了更丰富的观测设计与审慎升级（escalation）策略的价值。
自主性水平。自主性是一个跨领域的维度。“人在回路”（human-in-the-loop）的设定允许高风险决策通过审批关卡进行管控。半自主系统负责常规操作，但在不确定性增加时会将任务升级上报。全自主系统则必须通过验证、回滚、日志记录及故障安全终止等机制，在驾驭内部消化更多此类负担。自主性最好被理解为对驾驭（harness）要求的“乘数效应”：系统预期独立行动的程度越高，“观测接口”以及“验证与治理”就越会从可选的护栏转变为主要的瓶颈环节。
综合来看，这些维度在系统的六大框架组件上构成了特定的压力分布：任务视界（task horizon）主要对上下文、状态和控制环节施加压力；环境类型主要影响观测、行动及安全边界；自主性则主要考验验证、日志记录和恢复能力。这种视角将任务分类转化为系统框架的配置问题：关键不在于任务属于哪个应用领域，而在于其结构性压力下，哪些运行时职责会成为瓶颈。
2 针对不同领域的驾驭适配
下文所述的各个领域应被视为上述“压力特征视图”（pressure-profile view）的具体实例，而非独立的分类体系。每个领域都以独特的方式组合了任务视界（horizon）、环境、预言机强度（oracle strength）、不可逆性及自主性，从而改变了驾驭的主要瓶颈所在。软件工程是以验证为主导的；Web 与 GUI 交互以落地（grounding）为主导；科学发现以综合构建（synthesis）为主导；医疗辅助以安全性（safety）为主导；而具身智体（embodied agents）则以控制（control）为主导。这些案例展示了当任务压力发生变化时，相同的驾驭架构如何导致不同的配置侧重点。
软件工程（验证主导型）
软件工程将主要瓶颈置于验证与治理（Verification and Governance）环节 [184]–[187]。构建过程、单元测试、代码静态分析（linting）及执行日志提供了大多数其他域所缺乏的机械性反馈信号 [16]。这些强预言机（strong oracles）机制支持“生成-测试-修复”的闭环循环，其中验证器的输出成为下一轮迭代的依据。Claude Code、SWE-agent 和 OpenHands 等系统进一步表明，在模型能力不变的情况下，重新设计动作接口（包括文件与命令接口、差异视图及补丁检查）能带来可量化的性能提升 [6], [10], [21]。状态与制品存储（State and Artifact Store）同样至关重要：表达能力强的动作访问机制必须与检查点、补丁制品、安全回滚及受限的副作用控制相结合。随着任务规模从代码片段级生成（L2）扩展到代码库级问题解决（L3-L4），上下文管理器（Context Manager）以及状态与制品存储也成为瓶颈要素，用于在长执行轨迹中追踪规划、失败的假设及中间制品 [188]–[191]。
• 配置启示。在验证主导型场景中，运行时质量问题转化为闭环优化问题；驾驭的应对策略包括验证器循环、“生成-测试-修复”循环以及可逆执行机制。
Web 与 GUI 交互（基础关联主导型）
Web 和 GUI 智体将主要瓶颈从验证（verification）转移到了落地（grounding）：核心难点在于构建模型可利用的观测信息以及模型可安全执行的动作 [17], [18], [150], [192]–[196]。观测接口（Observation Interface）必须将屏幕截图、DOM 状态、交互历史和会话信息转化为可用的信号。动作接口（Action Interface）必须决定是将动作呈现为脆弱的底层选择器，还是呈现为结构化的浏览器与桌面操作。随后，上下文管理器（Context Manager）会针对当前步骤选择并压缩这些信号。由于许多 Web 任务缺乏单一的机械式判定标准（oracle），其验证过程在结构上比代码任务更薄弱。导航错误、表单提交和账户操作可能产生持久的副作用，因此验证与治理（Verification and Governance）依然是瓶颈的一部分，而非次要问题。随着任务从简短的表单填写（L2）发展到多页面工作流（L3），再到长周期的监控任务（L4），落地的负担也随之加重。
• 配置启示：以落地为主导的场景需要协同设计观测接口与动作接口；性能取决于驾驭（harness）所暴露的状态是否既能支持安全、稳健的动作执行，又能提供正确的信息形式。
科学发现与研究（以综合/合成为主导）
科学智体将主要瓶颈转移到综合（synthesis）环节：核心运行时问题在于如何跨越长时程可靠地整合证据 [197]–[202]。承受压力最大的组件包括上下文管理器、状态与产出物存储（State and Artifact Store）以及验证与治理模块。在此场景下，验证的功能与代码任务不同：它不再是闭合基于测试的修复循环，而是必须评估证据来源（provenance）、源数据质量以及推理的一致性。ChemCrow 和 BioDiscoveryAgent 等工具丰富的系统表明，动作接口可以扩展能力，但若缺乏来源追踪，长时程推理可能会退化为看似合理却缺乏支撑的叙述。研究任务主要属于 L3-L4 级别：文献综述、假设生成和实验设计要求驾驭比代码或 Web 场景更积极地将证据、中间主张和产出物外部化。
• 配置启示：以综合为主导的场景缺乏闭环验证机制；必须利用来源追踪、中间审查阶段以及以产出物为中心的记忆机制，来替代最终状态判定标准。
医疗应用（以安全为主导）
医疗智体继承研究场景下的合成需求，但也引入一项性质截然不同的约束：主要的瓶颈转移到安全性方面 [203]–[206]。在支撑架构体系中，“验证与治理”跃居首位，紧随其后的是“观测接口”与“上下文管理器” [207]。必须准确呈现患者病史、指南及最新研究结果；关键操作必须设有权限管控；面对不确定性时，系统应触发审慎的上报机制，而非盲目继续执行。其目标并非实现最大程度的自主性，而是提供受限且可审查的辅助支持。在此架构下，“验证与治理”是保障性能的关键组件，而非仅仅是合规性的附加功能。
• 配置启示。以安全为核心的场景侧重于优化受控的授权机制：审批关卡、可审计性及审慎的恢复策略是系统的核心组件，而非外部负担。
具身智能场景（以控制为核心）
具身智体将主要瓶颈转移至实时控制环节，从而提升“控制回路”在系统组件中的地位 [34], [208]–[211]。基于高级语言的推理速度难以满足连续交互的需求，因此系统架构通常采用分层设计：顶层负责深思熟虑的规划，底层负责反应式控制，中间层则通过持久化的技能或状态表征将两者连接起来。“状态与制品存储”模块负责维护目标、子目标、地图或可复用的行为模式。由于物理动作往往不可逆，“验证与治理”显得至关重要。“动作接口”直接对接执行器、仿真器或感知模块，而非传统的软件 API。具身智能任务几乎完全涵盖 L3-L4 级别，使得长时程状态外部化成为一项基本要求。
• 配置启示。以控制为核心的场景将部分技术栈下沉至语言处理回路之下，这促使系统设计、底层控制器与训练阶段的自适应机制之间实现更紧密的集成。
跨领域综合分析。上述五个领域遵循同一条分析主线：随着域约束条件的变化，主要瓶颈在系统各组件间发生转移。该瓶颈从编程领域的“验证与治理”出发，经由 Web/GUI 领域的“观测接口”与“动作接口”，流转至研究领域的“上下文管理器”及“状态与制品存储”，再到医疗领域的“验证与治理”，最后在具身智能场景中落脚于“控制回路”。这种转移模式表明，仅凭域标签无法充分描述系统特征。对于系统配置而言，关键在于哪个组件承担“故障预算”（即容错限度）。
3 从任务特性到系统配置
上述域案例研究展示瓶颈转移的现象，但更具普适性的经验则蕴含在域层级之下。跨域来看，相似的任务特性会引发相似的驾驭（harness）响应：长程任务（long horizons）需要外化状态，部分可观测性需要结构化观测，强预言机（strong oracles）支持验证器循环，弱或延迟的预言机需要溯源与审查机制，不可逆操作需要治理机制，而高自主性则需要日志记录、预算控制及恢复机制。
验证器的能力强弱决定了配置工作的重心。在存在强自动预言机的场景下（如以验证为主的软件工程），驾驭可以重点投入于通过验证器循环和修复周期实现的闭环优化。而在预言机较弱或存在延迟的场景下（如以综合生成为主的研究领域或以安全为主的医疗领域），瓶颈会向上游转移，侧重于溯源管理、中间审查及保守的终止标准。因此，在比较不同域时，不应仅关注任务成功率，还应考量驾驭（harness）所能获取的反馈信号的质量与延迟。
操作的不可逆性和系统的高自主性使得约束条件变得至关重要。在以读取为主或可逆的数字环境中，通常可以通过重试和检查点机制来实现恢复。然而，在以现实世界交互（grounding）为主的网络交互、以安全为主的医疗辅助以及以控制为主的物理场景中，操作可能产生持久的副作用。因此，验证与治理机制不再是外围的附加功能，而是构成了主要瓶颈的一部分。高自主性进一步强化了这一模式，因为驾驭必须承担起原本由人类操作员负责的职责。
无论在哪个领域，长程任务的性能表现都依赖于外化状态。无论是代码库规模的编程（L3）、文献综合分析（L3-L4）还是具身探索（L4），单一的提示词窗口（prompt window）往往都无法作为合适的记忆单元。持久化的产出物、摘要、检查点、计划和日志，共同确保了任务轨迹在时间跨度上的连贯性。由此带来的配置启示是：上下文管理器（Context Manager）与状态及产出物存储（State and Artifact Store）必须协同设计——摘要决定了当前可见的内容，而产出物和检查点则决定了后续可恢复的内容。
在报告评估结果时，也应同时报告任务压力情况。当基准测试重点考察那些与目标部署场景主要瓶颈相匹配的系统架构组件时，其参考价值最高。因此，基准测试报告不仅应描述模型，还应说明得出结果时所处的任务压力及驾驭配置。
评估使得模型-驾驭（harness）之间的互动变得直观可见。因此，基准测试得分应被视为“模型-驾驭”这一组合的产出结果：同一个模型在不同的上下文策略、工具接口、控制循环、验证流程及重试限额下，其表现可能会截然不同。本节利用具有代表性的基准测试，在三种交互场景下验证了这一观点：具有强测试预言（test oracles）的软件工程任务；涉及命令行执行与环境操作的终端任务；以及依赖浏览器环境（grounding）与有状态交互的Web任务。针对这些场景，试图回答三个问题：更强大的基础模型能在多大程度上解释性能差异；在控制模型变量后，性能仍存在多大程度的波动；以及运行时成本、延迟、超时行为和执行轨迹（trace）的可用性如何影响对任务成功与否的解读。
1 基准测试概览与评估工作
现有的评估工作可被组织为一个将智体（agent）运行过程转化为可解读证据的流水线：基准测试定义任务，执行基础设施规范运行流程，评判方法对结果进行评分与诊断，而持续评估实践则将这些反馈信号用于系统改进。
作为任务定义的基准测试。特别是基于LLM智体的代表性基准测试。除了应用领域各异外，这些基准测试还侧重于考察驾驭的不同能力：SWE-bench [16] 测试代码库导航、代码编辑及隐藏测试用例验证；WebArena [17]、VisualWebArena [192] 和 OSWorld [18] 测试Web/GUI环境感知（grounding）、状态追踪、多模态感知及安全接口控制；Terminal-Bench [20] 测试命令行执行与环境操作；LoCoMo [172] 和 OS-Harm [212] 则测试记忆持久性与有害行为控制。这些基准测试共同标志着评估方式向“生态真实性”的转变——即利用浏览器、终端和操作系统来揭示那些封闭式数据集往往难以捕捉的、长程交互中的失败案例。
执行与执行轨迹基础设施。针对编程和终端（terminal）智体，SWE-agent [21]、OpenHands [10]、Repo2Run [213]、R2E-Gym [214] 和 HAL [215] 等系统利用受控环境、沙箱执行、标准化运行流程及执行轨迹（trace）收集，确保评估过程既可复现又便于诊断。这种基础设施有助于区分评估驾驭自身的行为与因依赖项漂移、评分器失效、工具接口变更或重置不一致而产生的伪影。
判定与归因方法。可执行测试和基于状态的检查器为编程及终端任务提供了强有力的判定依据（oracle），而开放式输出则往往需要采用“大模型作为裁判”（LLM-as-judge）或人工审核机制。G-Eval [216]、MT-Bench [217] 以及关于“大模型作为裁判”的相关综述 [218] 展示了基于模型的评估器所具备的潜力与风险，包括偏差、不一致性以及评估器漂移等问题。在评估驾驭工程实践中，判定环节至关重要，因为它能将失败归因于模型推理、上下文构建、工具暴露、执行控制、安全约束或评估器自身的问题。
持续评估实践。LangChain 的智体评估工具 [219]、DeepEval [220]、RAGAS [221] 和 lm-evaluation-harness [222] 等驾驭支持周期性测试、轨迹检查、基于裁判的指标以及监控式评估。它们的作用不仅限于报告排行榜分数，更在于确保评估过程在提示词（prompt）变更、工具更新、上下文策略修订及部署监控等场景下均可复用。
2 超越任务成功率的评估维度
目前，大多数公开的智体排行榜仍依据单一的、以结果为导向的分数对系统进行排名。例如，SWE-bench [16] 报告的是已解决问题的比例 [228]，而 Terminal-Bench [20] 主要报告任务层面的完成度得分 [229]。然而，近期的评估研究 [21]、[23]、[24] 愈发强调，仅凭准确率已不足以全面评估智体。例如，Sayas [230] 呼吁开展成本可控且可复现的评估。 CLEAR [231] 明确评估成本、延迟、效能和保障性。ReliabilityBench [232] 研究了在类生产环境压力下的各项指标，包括一致性、鲁棒性和容错能力。针对流程的评估（Procedure-aware evaluation）[233] 表明，任务看似完成的表象下，可能掩盖不安全或无效的执行轨迹。由于智体（agent）的运行涉及模型推理、驾驭设计、环境搭建、工具接口及评估逻辑等多个环节，故障可能源于该链条中的任何一部分。尽管任务成功率仍是主要的衡量指标，但若要对驾驭进行有意义的比较，则需从多个额外维度对结果进行更深入的分析：
• 任务成功率：最终目标是否达成。
• 可靠性：在随机运行、重试及环境变化的情况下，性能是否保持稳定。
• 效率：Token 消耗量、API 成本及计算成本。
• 延迟：实际耗时（wall-clock time）或交互次数。
• 安全性：操作是否在允许的范围内进行，并避免产生有害的副作用。
• 流程质量：执行轨迹是否可检查、可恢复且有据可循。
这些维度解释了为何最终得分相似的方案在实际驾驭（harness）上可能存在巨大差异。一种方案可能通过长轨迹、反复重试和大量的上下文积累来换取更高的成功率，而另一种方案则可能以低得多的成本和延迟实现略低的成功率。从部署的角度来看，关键不在于单纯的成功率，而在于在资源受限的情况下有效完成任务。
在接下来的实证分析中，重点关注在公开报告和排行榜日志中普遍可获取的维度：任务成功率、运行时间、超时行为以及 Token 使用量（在数据可用的情况下）。关于经济成本的讨论则较为谨慎，因为相关的公开数据往往不完整，且通常取决于特定执行机制的计费方式、缓存处理策略以及对模型价格的假设。
3 驾驭（Harness）对 SWE-bench Verified 结果的影响
SWE-bench Verified [16] 包含 500 个经人工验证的 GitHub Issue，这些 Issue 选自 12 个 Python 代码仓库，每个 Issue 都配有一套隐藏的测试集，用于提供确定性的“通过/失败”判定依据。评估在依赖项版本固定的沙盒化 Docker 容器中进行，因此观察的差异反映的是系统能力，而非环境因素造成的偏差。通过剔除原始 SWE-bench（包含 2,294 个实例）中规范模糊或测试失效的案例，Verified 子集为跨系统比较提供了更清晰的信号。解决一个实例需要定位缺陷、修改源文件并通过隐藏的回归测试；由于不同的驾驭划分这些阶段的方式各异，该基准测试非常适合研究脚手架（scaffolding）设计如何影响测得的性能。
由于不同来源在模型快照、推理设置、重试次数限制及脚手架细节上并不总是一致，因此最有意义的比较应局限于同一行类别或相同的评估设置内。厂商报告的分数仅作为性能上限的参考，不应被解读为针对开源驾驭的受控消融实验结果。例如，报告显示 Opus 4.5 配合 mini-SWE-agent 使用时采用了“扩展思考”（extended thinking）模式，而同一来源报告 Opus 4 在“中等推理”设置下的成绩为 74.4%，Opus 4 为 67.6%；OpenAI mini-SWE-agent 这一行对应的是类似 GPT-5-2“扩展思考”风格的排行榜设置，而 GPT-5 (2025-08-07) 在“中等推理”下的成绩为 65.0%，至于 80.0% 这一厂商参考值，则是 Claude 系统卡 [228], [234] 中报告的 GPT-5.2 结果。同样地，DeepSeek 相关的行区分了 V3 与 V3.2 的高推理能力配置，而 Gemini 相关的行则区分了 Gemini 3 Pro 与后续的 Gemini 3.1 Pro 报告结果（包括 Gemini 3.1 Pro 在其官方配置下取得的 80.6% 的成绩 [235]）。这些界限划分并未使表格失效，但意味着在提出最强有力论断时，应基于同一行族（row-family）内的数据进行比较，并将厂商或推理策略的变更视为“性能上限参考”（upper-envelope evidence），而非严格控制的消融实验结果。
所比较的驾驭（harnesses）在脚手架复杂度方面跨度很大。Agentless [236] 移除了交互式智体循环，转而采用固定的“定位-修复-验证”流水线。SWE-agent + tools [21], [237] 通过面向 Bash 的修复循环提供 Shell 和编辑工具接口，而 mini-SWE-agent [238] 则将这一设计简化为极简脚手架，将大部分编排工作留给模型自身完成。OpenHands + CodeAct 2.1 [10] 提供了功能更丰富的软件工程运行时环境，支持文件编辑、网页浏览及 IPython 代码执行。AutoCodeRover [239] 和 PatchPilot [240] 代表了结构化程度更高的修复工作流，利用代码库搜索、定位、复现、验证和精炼等步骤来约束修复过程。Vendor scaffold一栏列出专有脚手架 [234], [241]–[244] 上厂商报告的最佳得分，作为性能上限的参考基准。综合来看，这些系统提供了一个有价值的视角，展示了在代码库级编程任务中，脚手架设计如何与骨干模型能力相互作用（尽管这种比较并非严格受控的实验）。
具体而言，模型能力与驾驭设计共同决定了最终的性能表现。在同一驾驭内，骨干模型的升级能带来显著的性能提升：SWE-agent + tools 的得分从 Claude 3.5 Sonnet 时的 49.0% 提升至 Opus 4 时的 73.2%，增幅达 24% [237], [245]；mini-SWE-agent 也呈现出类似的趋势，得分从 52.8% (Claude 3.7 Sonnet) 提升至 76.8% (Opus 4.5) [228]。即便针对同一模型，所选用的“驾驭”（harness）也会产生显著且一致的影响。以 GPT-4o 为例，各脚手架的测试结果差异明显：使用 SWE-agent 时为 23.2%，而使用 Agentless 时则高达 38.8%。Claude 3.5 Sonnet 的表现也呈现类似趋势，结果介于 SWE-agent（33.6%）与 PatchPilot（53.6%）之间，而 SWE-agent + tools、Agentless、AutoCodeRover 以及 OpenHands + CodeAct 2.1 的表现则处于中间水平。Claude Opus 4/4.5 的结果差异虽相对较小，但依然存在：SWE-agent + tools 为 73.2%，mini-SWE-agent 为 76.8%，OpenHands + CodeAct 2.1 为 77.6%。这些数据表明，基于同一底层模型，仅因脚手架的不同，成功解决的任务实例数量便可能出现数十个之差。
脚手架的复杂程度并不能预示其有效性。在使用 Opus 4.5 模型时，mini-SWE-agent（代码量仅约 100 行 Python）达到了 76.8% 的成功率，仅略低于功能更为丰富的 OpenHands + CodeAct 2.1 沙箱环境（77.6%）[228], [245]。这些结果表明，脚手架的有效性更多取决于接口设计而非功能数量：一个设计精简但原语（primitives）选择得当的脚手架，完全能够实现与功能完备的智体框架几乎相当的性能。
供应商报告的得分（反映了专有的脚手架优化）始终优于最佳开源结果。OpenHands 配合 Opus 4.5 取得 77.6% 的得分 [245]，落后于供应商报告的 80.9% [234] 约 3%；对于 Gemini 3 Pro，这一差距缩小至 2%（74.2% 对 76.2%）[238], [244]。GPT-5 变体之间的差距则更大（72.8% 对 80.0%），尽管模型版本和推理配置的差异使得这种比较变得复杂 [228], [234]。在同代 Claude 和 Gemini 模型中，这种 2%–4% 的优势归因于脚手架层面的决策（如提示词设计、候选方案选择和计算规模扩展），而非模型本身能力的差异。
4 驾驭（Harness）对 Terminal-Bench 2.0 结果的影响
Terminal-Bench 为 SWE-bench 提供了一个互补的视角，因为智体必须在交互式命令行环境中操作，而不仅仅是提交最终补丁 [20]。每项任务都包含自然语言指令、沙盒终端工作区、可执行测试脚本和参考解决方案；因此，任务成功的定义是智体能否将环境转变为通过测试的状态。任务通常涉及文件检查、工具安装或调用、命令执行、日志解读、工件编辑以及明确的终止决策。因此，该基准测试非常适合研究执行驾驭，因为终端交互综合考察了观测设计、上下文管理、控制循环策略、动作暴露、状态持久化和验证机制。
本文分析使用了官方 Terminal-Bench 2.0 排行榜和公开提交日志作为数据源 [229], [246]。官方提交的评估流程包括：每项任务进行五次试验（-k 5），使用任务特定的基准环境和默认约束，且不得更改超时设置或 CPU、内存及存储限制 [246]。排行榜的完整性规则对利用“奖励黑客”手段（如从互联网获取任务答案）生成的轨迹施加了额外惩罚，从而降低了上报分数反映的是基准测试数据泄露而非最终任务完成情况的风险 [247]。在性能分析中，仅使用那些骨干模型（backbone model）和驾驭（harness）均可明确识别的条目，剔除了模型字段标记为混合（mixture）或“Multiple”（多个）的条目，以确保图表中的每个数据点都对应明确的模型身份。由此得出的证据并非基于随机消融实验，因为公开提交的内容在提示词（prompt）、版本、预算及实现细节上可能存在差异。
尽管如此，这种观测性比较仍具有参考价值：同一模型可能出现在多个驾驭下，而同一驾驭也常与多个模型搭配使用。在资源分析方面，以 HuggingFace 官方公开提交仓库为主要数据源，并通过严格的元数据匹配将提交内容与当前可见的排行榜条目进行对应。该公开仓库包含 75 个带有元数据和日志的提交项，涵盖了 32,604 条试验记录。其中，48 个提交项与当前可见排行榜上的条目严格匹配。奖励、智体运行时间（agent-runtime）和总运行时间（full-runtime）字段的覆盖率很高（分别为 97.2%、98.1% 和 100.0%），而输入/输出 Token 字段覆盖了 45.0% 的试验记录，美元成本字段的覆盖率仅为 15.2%。因此，运行时间和超时统计数据构成了资源效率分析的主要依据，Token 统计数据作为补充证据，而货币成本数据则不用于跨驾驭的比较分析。这些统计数量界定了证据的范围，而非构成一个独立的完整结果表：共有 27 个公开提交项被排除在完整的资源分析表之外，原因包括 24 个在当前排行榜上不可见或名称不匹配，以及 3 个匹配结果存在歧义。若采用较宽松的可见条目检查标准，在 142 个可见排行榜条目中可找到 55 个匹配项（占 38.7%），涉及 51 个不同的提交项，但这仅用于检查覆盖率的合理性。
综合来看，Terminal-Bench 的结果区分了两种效应，且并未将其中任何一种视为决定性因素。模型升级能提升整个驾驭（harness）系列的表现，但针对同一模型，评测驾驭的具体选择——涉及终端状态呈现、上下文管理、命令执行及验证器反馈等方面——仍可能导致其得分产生超过 10% 的波动。资源统计数据则揭示了面向部署场景的一个关键考量：更高的准确率可能需要更长的交互轨迹、更繁重的上下文负载或更稳健的超时处理机制，而这些资源开销本身也是所评估的实际能力的一部分。因此，在 Terminal-Bench 中，能否可靠地完成终端任务，取决于在既定的基准测试约束下，模型的交互能力与驾驭的运行时设计之间匹配度的高低。
5 WebArena 中的“驾驭”（Harness）效应
WebArena [17] 是针对 Web 智体（web agents）应用最广泛的可复现基准测试之一。它在自托管网站上评估智体，这些网站涵盖了购物、讨论论坛、GitLab 风格的软件协作、内容管理、地图和知识资源等真实应用场景。与那些通常需要人工或基于大语言模型（LLM）进行评判的开放式浏览基准测试不同，WebArena 采用基于程序自动化的方式，通过检查网站状态和特定任务的预期答案来判定成功与否。这使得它非常适合研究“Web 智体驾驭”（即智体运行的支撑环境）相比单纯的“模型基线”能带来哪些额外贡献：浏览器智体必须将文本目标以及视觉或 DOM 观测信息转化为导航、搜索、表单填写、状态跟踪和错误恢复等操作，而评估系统则提供了一个相对明确的任务成功信号。
总体而言，WebArena 在 Web 交互场景下强化了“模型-驾驭”这一视角。在代码生成基准测试中，驾驭决定了测试用例、代码编辑操作及代码库上下文的呈现方式；而在 WebArena 中，它决定了模型如何感知页面、选择浏览器操作、从导航错误中恢复，以及验证网站状态是否按预期发生了改变。与“LLM 作为评判者”（LLM-as-judge）的方案相比，程序化评分降低了评估偏差，但并未完全消除测量风险：脆弱的检查逻辑、模棱两可的指令以及环境信息泄露仍可能导致结果失真。若需得出高置信度的结论，在条件允许的情况下，优先使用经人工核查的变体（如 WebArena Verified [259]）更为稳妥，因为它们既保留了 WebArena 可复现的运行环境，又修正了评估逻辑和指令中存在的问题。因此，在报告浏览器智能体的成功率时，最好将其视为“模型-驾驭”这一完整系统在特定条件下的表现，并同时说明其观测模式、操作接口、搜索或重试预算、记忆策略以及相关源数据。
6 基准测试洞察
通过比较不同基准测试中驾驭（harness）的表现，可以总结出几点经验。
驾驭的设计应与基准测试的判定机制（oracle）相匹配。当基准测试提供强有力的自动反馈时（例如带有测试用例的编程任务），高效的驾驭会利用验证循环、补丁优化和回滚机制。Terminal-Bench 在命令行环境中印证了这一原则：实用的驾驭能将命令输出、文件状态和完成度检查转化为可操作的反馈，从而指导终止、重试或修复操作。当判定机制较弱或反馈滞后时（例如在研究或实际工作任务中），驾驭则需更多地依赖溯源追踪、中间审查和保守的停止策略。
自主性和复杂性并非越高越好。完全开放式的循环虽然探索范围广，但也可能导致上下文累积、状态漂移及成本增加。当目标明确且成功与否可由程序自动判定时，结构化流水线（如“定位-修复-验证”模式）的表现往往优于更具自主性的循环模式；同时，精简的辅助框架也能达到与功能丰富的运行时环境相当的效果。设计的关键不在于驾驭赋予模型多大的自主权，而在于哪些自由度能帮助模型充分利用基准测试的反馈结构。
模型与驾驭的兼容性至关重要。如果驾驭暴露了错误的动作空间或导致上下文窗口过载，即使是强大的模型也可能表现不佳；反之，若辅助框架能契合模型的交互习惯及基准测试的反馈结构，即便设计简单也能高效运行。在 Terminal-Bench 2.0 上，同一模型在不同驾驭下的准确率差异可达两位数百分点；在 WebArena 上，对于 GPT-4o 而言，纯模型基线与浏览器智体辅助框架之间的性能差距甚至超过 40%。这些差异表明，兼容性是模型与驾驭组合所特有的一种经验性特征，而非单纯的实现细节。
评分结果取决于运行时配置。工具权限、上下文策略、重试次数限制、沙箱约束以及任务完成标准等因素，都会影响最终测得的性能表现。Terminal-Bench 的公开日志进一步显示，即使是排行榜上的提交方案，其运行时间和超时特征也存在显著差异。因此，只有结合产生该分数的运行时配置，基准测试的分数才具有可解释性。相关报告应至少包含以下信息：模型版本、驾驭标识、工具权限、重试与超时策略、执行环境、Token 或 API 使用情况（如适用），以及执行轨迹或验证器元数据。
迈向价值-觉察的评估体系。实证结果支持从“以分数为中心”的排名转向“兼顾价值”的智体评估。更强大的模型提升了性能上限，但具体的“驾驭”（harness）设计决定了其中多少能力能转化为可靠、高效且可审计的任务执行成果。因此，未来的评估不仅应考量任务是否成功，还应涵盖资源消耗、延迟、超时行为、恢复质量、安全约束以及执行轨迹的可审计性。这一观察促成“兼顾价值”的评估目标，即综合考量任务成功与否以及成本、延迟、风险、可靠性和过程质量。
