从问答到任务完成：智体系统与驾驭设计的综述（下）

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 horizo​​n主要对上下文、状态和控制环节施加压力环境类型主要影响观测、行动及安全边界自主性则主要考验验证、日志记录和恢复能力。这种视角将任务分类转化为系统框架的配置问题关键不在于任务属于哪个应用领域而在于其结构性压力下哪些运行时职责会成为瓶颈。2 针对不同领域的驾驭适配下文所述的各个领域应被视为上述“压力特征视图”pressure-profile view的具体实例而非独立的分类体系。每个领域都以独特的方式组合了任务视界horizo​​n、环境、预言机强度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 horizo​​ns需要外化状态部分可观测性需要结构化观测强预言机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-agent33.6%与 PatchPilot53.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设计决定了其中多少能力能转化为可靠、高效且可审计的任务执行成果。因此未来的评估不仅应考量任务是否成功还应涵盖资源消耗、延迟、超时行为、恢复质量、安全约束以及执行轨迹的可审计性。这一观察促成“兼顾价值”的评估目标即综合考量任务成功与否以及成本、延迟、风险、可靠性和过程质量。未来方向略从评分到价值-觉察的智体优化学习如何验证、恢复与适应驾驭的泛化与专用化