从问答到任务完成：智体系统与驾驭设计的综述（上）-拓冰建站

26年6月来自港城大、悉尼大学和上海TokenRhythm 公司的论文“From Question Answering to Task Completion: A Survey on Agent System and Harness Design”。

基于大语言模型（LLM）的智体标志着从被动问答向主动任务完成的转变：它们能够感知环境、调用工具、维护状态，并跨越较长的时间跨度执行操作。随着智体系统从提示工程（prompt engineering）演进到工作流与上下文工程、驾驭（harness）工程以及伴随协同进化的智体原生训练，一个核心问题日益凸显：智体性能的瓶颈究竟何在——是源于基础模型、驾驭，还是两者之间的耦合关系？本综述从“模型-驾驭”的视角审视基于LLM的智体。

首先明确智体的功能定义，并从实现层面将其界定为“基础模型与驾驭相耦合”的系统。随后，分析以模型为中心的扩展（scaling）所面临的局限性，梳理了智体工程的四种范式，并将驾驭拆解为六项相互耦合的运行时职责：感知、上下文、控制、行动、状态以及验证/治理。基于这一拆解，将任务特性与域需求映射到驾驭配置上，回顾了基准测试与评估实践，并综合分析关于运行时设计如何影响长程任务完成、效率及可靠性的“模型-驾驭”相关证据。最后，指出在价值感知评估、安全性、驾驭泛化能力以及模型-驾驭协同进化方面尚待解决的挑战。本综述主张，不应将智体简单视为配备辅助工具的模型；相反，智体的质量（涵盖成功率、效率、安全性和泛化能力）源于模型能力、运行时基础设施、任务结构与评估设计之间的相互作用。

基于大语言模型（LLM）的智体（Agent）——即能够感知环境、围绕目标进行推理并执行多步操作的自主系统——标志着从被动问答 [1], [2] 向主动任务完成 [3], [4] 的转变。与早期侧重于优化单轮响应质量的聊天界面不同，现代智体系统以闭环方式运行，能够在较长的时间跨度内调用工具、更新状态并验证结果。其典型代表涵盖多个领域：Devin [5]、Claude Code [6] 和 Codex [7] 等编程智体能够独立诊断并解决整个代码库层面的软件工程任务；Manus [8] 等通用智体能够统筹从研究到数据分析的多步工作流；AutoGPT [9]、OpenHands [10] 和 OpenClaw [11] 等开源平台则为构建定制化智体流水线提供可扩展的框架。

这一格局反映了从“对话能力”向“操作能力”的更广泛转变，同时也改变了性能瓶颈所在的位置。对于问答（QA）任务而言，模型能力的渐进式提升（如增加参数量、扩充训练数据或优化对齐效果）往往能带来直接且可预测的收益。然而，用于衡量此类能力的传统基准测试（如 MMLU [12]、GPQA [13] 和 HumanEval [14]）在顶尖水平上已日趋饱和，且数据污染风险进一步增加了结果解读的复杂性；为此，人们提出了诸如“Humanity’s Last Exam” [15] 等难度更高的评估方案，以恢复评估的区分度。更为关键的是，当评估场景从封闭式问答转向交互式、多步任务完成时，即使是顶尖模型也暴露出显著的可靠性差距——SWE-bench [16]、WebArena [17]、OSWorld [18]、TheAgentCompany [19] 和 Terminal-Bench [20] 等测试均表明，智体任务领域仍有巨大的提升空间。这种静态基准测试（接近饱和）与智体基准测试（远未解决）之间的差异引发一个自然而然的问题：如果仅靠模型规模的扩展无法弥合智体任务中的性能差距，那么究竟什么才是解决之道？

1. 作为性能提升关键的“驾驭”（Harness）设计

越来越多的研究表明，智体（agent）的性能不仅受限于模型自身的原始推理能力，还很大程度上取决于其“驾驭”（harness）的设计——即决定模型感知内容、行动方式以及错误检测与恢复机制的运行时基础设施。SWE-agent [21] 率先通过实证展示了接口设计的重要性，证明在基础模型不变的情况下，重新设计智体-计算机接口（ACI）能显著提升其在 SWE-bench 上的表现。随后，Hashimoto [22] 和 OpenAI [7] 进一步明确了这一概念，将其统称为“驾驭工程”（harness engineering）；他们将智体定义为“模型 + 驾驭”的组合，并确定观测形态塑造（observation shaping）、动作空间设计、执行沙箱、上下文管理及验证循环作为其核心组件。近期，NLAH [23] 将驾驭逻辑形式化为一种可编辑、可移植的自然语言构件，而 Meta-Harness [24] 则将驾驭配置视为一个可优化的搜索空间。

沿袭这一研究脉络，本文采用以驾驭为核心的视角作为统一的分析框架：系统地探讨了运行时基础设施的设计——而非仅仅是模型能力——如何决定智体在多样化任务中的可靠性、效率及泛化能力。进一步指出，这一视角正超越单纯针对单一模型的辅助架构：近期的系统 [25] 已将驾驭视为一种跨多个模型的组合式运行时环境，并日益将其视为一种可学习的对象，其路由、编排及验证策略本身均可进行优化。

2. 智体工程的四种范式

从演进的视角，将近期文献归纳为四种范式。每种范式的出现都是为了解决前一种范式暴露出的局限性，且各自侧重于不同的性能提升手段。

阶段 1：提示工程（Prompt Engineering）侧重于优化发送给模型的单轮指令。诸如少样本示例（few-shot exemplars）[1]、思维链推理（chain-of-thought reasoning）[26]、自洽性（self-consistency）[27] 和思维树搜索（tree-of-thought search）[28] 等技术，能够明确任务要求、规范输出格式并激发模型的潜在能力。然而，提示工程从根本上解决的是表达层面的问题，即“如何提问”。它无法解决信息层面的问题：仅靠提示无法补充缺失的知识、管理动态变化的状态，也无法在长动作序列中保持连贯性。

阶段 2：工作流与上下文工程（Workflows and Context Engineering）将优化单元从单一提示转向围绕多步执行的信息生命周期。其核心在于管控进入模型上下文窗口的信息内容、时机及形式 [29]，涵盖了检索增强生成（RAG）[30]、长期记忆管理 [31]、工具与 API 定义 [32], [33] 以及渐进式技能展示（progressive skill disclosure）[34], [35]。相应的评估标准也发生了变化：重点不再仅仅是单个答案的正确与否，而是构建的上下文能否支持模型完成多步任务。不过，上下文工程本质上仍属于前馈（feedforward）模式：它优化了每一步推理的输入，但缺乏结构化机制来检测偏差、验证中间结果或从错误中恢复。

阶段 3：驾驭工程（Harness Engineering）实现了闭环控制。除了构建合适的上下文外，该范式引入了由反馈驱动的执行机制：模型采取行动，观察环境反馈，并基于观察结果进行推理以决定下一步动作 [36]。更广泛地说，控制驾驭工程将整个运行时基础设施视为主要设计对象 [7], [22]，统筹管理执行沙箱、状态检查点（checkpointing）、验证循环、错误恢复以及子智体间的协作 [23], [24]。核心问题已从“向模型展示什么”转变为“如何确保整个系统按预期运行”：即防止偏离、维持稳定执行以及从错误中恢复。

在这一阶段，进一步的转变已初见端倪。早期的“驾驭“（harness）设计通常是在一个固定的基础模型外层封装人工编写或经搜索生成的运行时策略。而较新的系统正转向多模型驾驭框架：运行时系统负责调度、委派并组合异构模型，以完成规划、工具使用、验证、编码及特定领域子任务 [37]–[39]。与此同时，驾驭本身也变得可学习：驾驭模块、编排逻辑和运行时策略均可作为“一等公民”式的构件进行编辑、搜索或优化 [23], [24], [40]。这改变了对“智体系统”的定义。虽然单个模型配合提示词（prompt）仍可作为轻量级智体运作，但若要可靠地完成长程任务，则越来越依赖于一个基于多模型、可组合且可优化的运行时系统，而非仅仅依靠提示词工程。

阶段 4: ——“智体原生训练与协同演化”——建立在上述“可学习的多模型驾驭”这一视角之上。其第一个方向是“内化”：通过交互式环境，规划、工具使用、验证及错误恢复等智体行为正越来越多地被训练并融入模型参数中 [41]–[44]。第二个方向是“协同演化”：在部署过程中，模型、驾驭及改进循环均可根据执行轨迹（记录了哪些内容应保留、修改或撤销）进行更新 [40], [44]–[46]。这并未淘汰驾驭，而是将设计重心转移到了以下问题：智体行为中有多少由模型学习实现，多少保留在运行时系统中，以及整个系统栈如何随时间推移安全地改进——从而为构建自我演化的智能体系统开辟了路径。

这四个阶段构成了一个概念性的演化视角，而非严格的时间划分；在实际应用中，这四种模式往往并存。本文目标并非引入另一种组件分类法，而是利用这一演化进程及基准测试证据，分析主要的性能瓶颈如何在各阶段间转移，并探讨为何驾驭的设计已成为智体工程的核心议题。

如图1 所示本文的结构：

在关于智体（agent）的文献中，经常混淆两个抽象层级。在功能层面，智体是一个面向目标的闭环系统：它感知外部环境，维护任务状态，进行推理与决策，执行动作，并根据反馈进行适应。在实现层面，基于大语言模型（LLM）的智体并非仅仅是基础模型本身，而是一个由基础模型与执行驾驭（execution harness）构成的耦合系统。模型提供灵活的语言理解、推理、规划及动作建议能力；执行驾驭则提供运行时机制，负责呈现观测信息、构建上下文、执行动作、持久化状态以及验证或从故障中恢复。这种区分调和了经典的智体定义与近期以执行框驾驭为核心的 LLM 智体描述：前者定义了智体必须做什么，而后者则具体说明了这些功能如何在部署的系统中实现。

1 功能视角：什么是智体？

智体的概念早于 LLM 出现。Wooldridge 和 Jennings [58] 将智体描述为一种置身于环境中的系统，它能够感知该环境并针对环境采取行动以实现目标 [59]–[61]。就本综述而言，其关键特征不在于系统是基于符号规则、强化学习还是语言模型实现的，而在于它是否维持着一个以目标为导向的、与环境交互的闭环过程。因此，采用一种功能性定义：智体是一个围绕任务目标组织五项操作的系统，这五项操作包括感知、状态维护、推理与决策、动作执行以及基于反馈的适应。目标和环境制约着特定的运行过程，但它们本身并非智体的内部组件。如图 2 所示，智体接收观测信息，更新内部或外部状态，通过推理与决策选择下一个动作，作用于环境，并将反馈或结果纳入后续行为中。这种闭环特性将智体与“单次模型调用”、静态检索系统以及无法根据观测变化调整行为的固定自动化脚本区分开来。

2 实现视图：模型与驾驭（Harness）

在基于大语言模型（LLM）的智体中，功能循环的实现不仅仅依赖于对模型的推理调用。基础模型是必不可少的，因为它提供了完成开放式任务所需的通用认知能力；然而，仅有模型是不够的，因为模型本身无法定义可用的观测信息、允许的操作、长期状态的存储位置、执行验证方式或故障恢复机制。

参考近期工业界和学术界关于驾驭工程（harness engineering）的讨论 [7], [22]，将基于 LLM 的智体表示为：

A_LLM =⟨M,H⟩=⟨M, I_obs, C, L, I_act, S, V⟩,

其中 M 表示智体的模型层。在最简单的情况下，M 是单个基础模型。在已部署的多模型系统中，M = {M_1 , . . . , M_k } 表示一组具有不同能力、成本和上下文限制的主干模型 [37]–[39]。H 表示围绕 M 运行的执行驾驭（execution harness）。第二个等式将驾驭展开为六个运行时组件，这些组件贯穿于本综述的讨论之中。该表达式是一种面向实现的分解，并非对上述功能定义的替代。当 |M| = 1 时，智体简化为常见的单主干模型设定；当 |M| > 1 时，驾驭还必须决定在每一步由哪个模型执行操作 [25]。模型层与驾驭共同实例化了功能循环：活跃模型基于提供的上下文进行推理并提出后续步骤，而驾驭则决定模型能看到什么、能做什么、执行状态如何持久化，以及如何检测、约束或修复错误。

3 大语言模型（LLM）作为认知引擎

大语言模型（LLM）之所以能成为智体（agent）切实可行的认知引擎，是因为它们整合了以往需要独立模块或特定任务策略才能实现的多项能力。

推理与规划。诸如思维链（Chain-of-Thought）[26]、思维树（Tree of Thoughts）[28], [62]、自洽性（Self-consistency）[27] 和 Reflexion [63] 等提示（prompting）方法表明，能力足够强大的模型能够支持任务分解、分支搜索、自我反思及多步推理。这些能力使模型能够作为一种合理的决策引擎，应对那些无法预先穷尽所有解决方案的任务。

上下文适应。同一个冻结参数的模型（frozen model）可以通过指令、示例、检索到的文档、工具描述及中间产物来调整其行为。这减少了针对不同环境训练独立策略的需求，同时也使得所提供上下文的质量、顺序和压缩方式成为决定模型行为的关键因素。

动作提议与工具使用。当模型能够生成结构化的工具调用指令 [32], [33] 时，它们便不再局限于内部文本生成。它们可以发起对代码执行环境、检索系统、浏览器、API 及外部软件的调用请求。然而，提议并不等同于已执行的动作：系统的可靠性取决于一套驾驭（harness），该机制负责验证、调度、观察所提议的动作，并在必要时拒绝或修正这些动作。

这些优势同时也暴露了模型的局限性。LLM 依然容易出现“幻觉”问题，且存在上下文窗口有限、持久记忆能力较弱、对提示词敏感以及验证长程结果的内在能力不足等缺陷。因此，上述驾驭并非可有可无的工程外壳，而是将模型能力转化为与环境进行持续且可审查交互的运行时（runtime）层。

4 作为运行时基座的驾驭

参考 [7]、[22] 和 [64]，用“驾驭（harness）”一词来指代围绕模型并实现智体（agent）闭环执行的运行时基础设施。驾驭（Harness）的概念涵盖范围比单一工具、记忆模块、提示词模板或工作流脚本更广。它是一个协调层，负责决定哪些观测信息传递给模型、如何构建上下文、智体循环如何推进、如何执行动作、如何持久化状态与产出物，以及如何检测、管控和恢复故障。这一运行时基座可形式化表示为：

H = ⟨I_obs, C, L, I_act, S, V⟩

这六个组件分别是：
• 观测接口 I_obs：将原始环境信号转换为模型可用的观测信息，包括终端输出、文件差异（diffs）、截图、DOM 状态、API 响应、日志、检索的段落及事件流。
• 上下文管理器 C：决定哪些信息进入模型上下文、何时进入以及以何种形式进入；涵盖提示词构建、系统指令、检索、记忆选择、压缩、摘要、工具描述及当前任务状态。
• 控制循环 L：编排“观测-推理-动作-反馈”循环，包括步骤调度、停止条件、重试、反思（reflection）、委派、交接及多智体协作。在多模型场景下，L 还负责实现模型路由和角色分配。
• 动作接口 I_act：将模型输出映射为可执行操作，例如函数调用、MCP 工具、Shell 或代码执行、浏览器操作、文件操作、API 调用及子智体调用。
• 状态与产出物存储 S：持久化执行状态和产出物，包括对话历史、计划、草稿区（scratchpads）、检查点、日志、追踪记录、差异数据、记忆记录、生成的文件及任务产出物。
• 验证与管控层 V：通过测试、断言、验证模型、沙箱策略、权限控制、回滚（rollback）、重试、预算控制、安全约束及审计追踪，对执行过程进行检查、约束和修复。

图 3 展示这一实现视图。该图示应被理解为一种执行架构，而非静态的检查清单：观察、上下文、控制、动作、状态和验证共同构成了围绕模型的耦合运行时环境，它们的相互作用决定了模型的能力能否转化为可靠的任务执行结果。

这种分解方式不同于早期的组件分类法，因为它侧重于运行机制而非单纯的功能划分。例如，虽然“记忆”在功能循环中表现为“状态”，但在实际部署的系统中，它可能通过上下文选择、工件存储、检索索引、会话管理器或检查点策略等多种方式来实现。同样，“动作”也不仅仅是一个抽象的动作空间，而是受到模式（schemas）、权限、沙箱、执行 API 以及副作用控制机制的制约与调节。通过将这些运行时职责与模型本身分离开来，该分解模型解释了为何即便底层模型保持不变，仅通过调整驾驭（harness）也能提升智体（agent）的性能 [21], [23], [24]。

5. 关键基础设施原语

现代基于大语言模型（LLM）的智体中，反复出现几种基础设施原语。它们不应被视为与“驾驭”（harness）并列的概念；相反，它们是在实际部署的系统中对驾驭特定职责的具体实现，使感知、行动、通信和治理等功能变得具体可操作。

工具与函数调用。结构化的工具调用将模型的输出从自由形式的建议转换为机器可执行的调用 [32], [33]。工具模式（schemas）主要属于行动接口 I_act，而工具描述、参数及返回结果也影响着上下文管理器 C 和观测接口 I_obs。

模型上下文协议（MCP）。MCP [65] 规范 LLM 应用程序向智体公开工具、数据源和上下文资源的方式。在符号体系中，MCP 主要通过减少连接器碎片化并实现工具与数据访问的模块化，来强化上下文管理器与行动接口之间的边界。

智体间通信。智体间（A2A）通信协议 [66] 旨在实现由不同供应商或框架构建的智体之间的互操作性。它与控制循环 L 和行动接口 I_act 关系最为密切，特别是在涉及任务委派、协商、辩论或多智体协作的执行过程中。

沙箱执行与审批。当智体能够写入文件、执行代码、浏览网页或调用 API 时，隔离机制既是安全保障，也是确保可复现性的基础原语。沙箱限制文件系统访问、网络出站流量、进程执行及资源使用；而审批策略则决定了在执行某项操作前何时需要人工授权。这些机制主要归属于验证与治理层 V。

智体 SDK 与追踪。诸如 OpenAI Agents SDK [39] 之类的框架，为工具、任务交接（handoffs）、追踪和循环机制提供可复用的抽象。它们将常见的驾驭模式封装为面向开发者的接口，从而提高了运行时行为的可复用性、可观测性和可调试性。

这种映射关系是多对多的，而非一对一的：例如，感知过程不仅依赖于观测接口，还依赖于上下文管理器——后者负责为模型筛选并格式化观测数据；反馈过程涉及验证、控制回路决策以及状态更新。这种多对多映射连接图2中的概念视图与图3中的实现视图。

基于上述定义，常见的应用类型可被视为同一“模型-驾驭”（model-harness）架构的特化形式。编码、Web/GUI、研究、具身智能及特定领域智体均依赖于相同的六个运行时组件，但由于其观测通道、动作空间、反馈信号及安全约束各不相同，它们对驾驭不同部分的侧重也有所差异。

一旦将基于大语言模型（LLM）的智体视为“模型”与“驾驭”的结合体，就能更精确地阐述基础模型规模扩展（scaling）所扮演的角色。规模扩展依然是LLM能够充当现代智体认知引擎的主要原因之一。早期的“扩展化定律”（scaling laws）表明，语言建模损失会随着模型规模、数据量和算力的增加而呈现可预测的改善 [67]；而Chinchilla模型的研究结果则进一步细化这一认知，强调了模型参数量与训练Token数量之间存在算力最优的分配比例 [68]。这种扩展带来的实际影响广泛：更大规模且训练更充分的模型在推理与问题解决 [69]、代码生成 [70], [71]、数学推理 [72], [73] 以及多模态理解 [74], [75] 等方面均表现出更强的能力。这些进步使得更强大的基础模型成为智体系统不可或缺的组成部分，但仅凭模型规模并不能完全解释智体的性能表现。完成长程任务（long-horizon tasks）涉及一系列动作序列，其特性体现在整个轨迹层面：智体必须反复进行观察、构建上下文、选择动作、维护状态、解读反馈以及从错误中恢复。因此，关键问题在于：以模型为中心的解释在何处止步，而运行时设计又在何处介入？其中，两个界限尤为重要：资源-性能界限（resource-performance boundary）与度量界限（measurement boundary）。

“以模型为中心”的扩展局限性，为智体系统提出一个更具体的问题：可靠的智体行为究竟源自何处？早期的基于大语言模型（LLM）的系统将大部分重任寄托于提示工程（prompting），认为通过有效的指令即可激发模型潜在的能力。随着任务对外部知识、工具使用、记忆及中间产物需求的增加，关注重点转向了智体工作流与上下文工程。当这些工作流变得更长、状态依赖更强且更易出错时，瓶颈便从“为模型组织信息”转移到了“围绕模型控制执行”；这一转变将驾驭（harness）从单纯的实现细节提升为核心的设计对象。近来，验证与恢复机制也成为了训练目标，这表明某些智体行为可能已内化为模型自身的能力，而不再仅仅依赖外部的辅助支撑。尽管当前系统中这些阶段并存，但它们共同揭示了瓶颈的演变路径：从提示词引导，到上下文与工作流组织，再到驾驭层面的执行控制，进而发展为组合式且可学习的多模型运行时，最终迈向智体原生训练与模型-驾驭协同演进。图5总结了这一演变过程，将其视为工程投入重心的转移，而非断言后续范式会取代早期范式。

1. 阶段 1：提示工程

在第一阶段，提示（prompt）被视为激发和控制模型潜在能力的主要接口。这一理念始于“上下文学习”（in-context learning），随后通过零样本（zero-shot）和少样本（few-shot）提示、思维链（chain-of-thought）提示、自洽性（self-consistency）、树状推理、自我修正（self-refinement）、ReAct 风格的推理-行动轨迹以及自动提示优化等方法得以扩展 [1], [26]–[28], [36], [96]–[98]。这些方法使提示成为一种实用的机制，用于任务定义、推理激发、输出格式控制及行为引导。近期面向智体（agent）的推理研究将这一阶段从单一链条式的激发扩展到了结构化推理与规划。在软件任务领域，多智体优化和问题驱动的自问自答（self-QA）机制将提示的应用扩展到了协作式设计推理 [99], [100]。自演化和图结构化的多智体方法进一步探索了推理过程，将其视为一种自适应协作过程，而不仅仅是线性的执行轨迹 [101], [102]。其他研究工作则致力于使推理轨迹可用于故障管理 [103]，在网络智体推理中引入反思、分支和回滚机制 [104]，并利用“推理门”（reasoning gates）来决定智体应继续执行还是受到约束 [105]。异构模型组合与意图级技能抽象将提示层面的推理与规划及计算机操作技能的组织联系起来 [38], [106]；与此同时，关于智体软件架构的研究将这一演进过程描述为从“提示-响应”式交互向目标导向系统的转变 [107]。尽管这些方法对早期智体系统至关重要，但其局限性对于本综述的论点同样具有重要意义。提示工程主要解决的是表达与激发的问题：它优化了向模型提出任务的方式以及调用模型既有能力的方式。然而，它无法可靠地提供模型原本不具备的知识、维护动态变化的任务状态、验证外部操作，也无法在长周期的执行过程中从故障中恢复。这促成了下一阶段的转变：从关注如何措辞指令，转向关注每次模型调用时应构建何种信息环境。

2. 阶段 2：工作流与上下文工程

第二阶段将工程重心从提示词（prompt）设计转向了智体工作流编排与上下文管理。这一转变解决了提示词方法遗留的两个局限性：一是模型可能缺乏与任务相关的知识；二是执行过程中所需的信息可能会随环境反馈而发生变化。智体工作流通过对模型调用、信息检索、工具使用、记忆访问、中间产物生成以及围绕模型的分支逻辑进行排序与编排来应对这些挑战 [108]–[112]。近期的系统在软件开发与工具使用场景中将这一工作流视角具体化。例如，SGAgent 将代码库层面的修复任务分解为由建议引导的多智体协作过程 [113]；而针对智体编码工具配置的研究表明，系统性能不仅取决于基础模型，还取决于工作流与工具的设置 [114]。面向工具使用的研究进一步通过多智体角色扮演来综合生成工具使用轨迹 [115]，并探索了扩展的工具集成推理模式，旨在将智体工作流的能力从孤立的工具调用扩展到更复杂的场景 [116]。在这些工作流中，上下文工程构成了核心技术视角：上下文不再仅仅是静态的提示词字符串，而是一个动态构建的运行时对象。从形式上讲，上下文不再被简单视为 C = prompt，而是被定义为：

C = A(c_1, c_2, …, c_n),

其中 A 表示一个高层组装函数，负责将各类上下文组件 c_i（包括指令、检索的知识、工具描述与输出、记忆记录、任务状态、中间产物以及当前查询）组合成最终的上下文 C。基于这一视角 [117]，工程问题从优化提示词的措辞，转变为优化在执行过程中负责检索、选择、压缩、格式化及更新信息的各项函数。其目标是在构建好的上下文环境下最大化预期的任务质量，而非孤立地优化某一条指令。

因此，智体工作流重构了核心工程问题：从“如何编写更好的指令”转变为“如何在执行过程中构建、组织和更新可用信息及工具使用环境”。这一发展趋势可从三个密切相关的方向来解读。

第一个方向侧重于外部信息的获取。诸如 RAG [30]、[118] 等基于检索的方法引入了一种实用机制，使模型能够利用非参数化知识；而 Fusion-in-Decoder [119]、RETRO [120] 和 Atlas [121] 等检索增强架构则进一步强化了这一范式。随后出现的系统（如 RAPTOR [122]、GraphRAG [123] 和 HippoRAG [124]）将检索能力从简单的文本片段查找扩展为更丰富的流程，这些流程结合层级摘要、图构建以及具备关系感知能力的记忆组织方式。

第二个研究方向侧重于系统化的上下文管理。在此方向上，核心问题不仅在于检索什么内容，还在于何时注入信息、如何压缩信息、如何更新信息，以及如何在长周期的执行过程中保持与任务相关的状态。这种转变体现在多种方法中：例如 ACON [125] 将上下文压缩建模为优化问题；ARC [126] 将上下文视为一种动态管理的内部状态，并通过反思（reflection）机制进行更新；ContextBudget [127] 则在明确的上下文窗口限制下做出压缩决策。相关研究进一步探讨了软件开发及长周期任务场景下的上下文维护问题，包括将上下文维护提升为智体（agent）循环中可调用工具的 CAT [128]，以及研究如何在有限资源限制下提炼并保留任务相关代码上下文 [129]。

第三个研究方向将上下文本身视为评估与优化的明确对象。ContextBench [130]、SWE Context Bench [131]、LoCoBench-Agent [132] 和 AgentLongBench [133] 等基准测试，使上下文的检索、保留与利用成为可量化的研究目标。更近期的研究（如 ACE [134] 和 MCE [135]）进一步将上下文乃至上下文工程策略本身视为自适应优化的目标。综上所述，第二阶段的发展历程体现了从外部信息获取，到系统化上下文管理，再到明确的上下文评估与自适应上下文优化的演进过程。然而，即便拥有设计精良的工作流与上下文，也无法单凭这些确保智体（agent）运行的可靠性。它们虽围绕模型组织了信息、工具及中间步骤，却未能充分界定如何保持整体流程的稳定性、可验证性与可恢复性。随着任务日益依赖工具辅助、具备状态特性且容易发生故障，瓶颈已从管理信息与工作流环境，转移到了设计执行环境本身。上下文并未消失；它成为更广泛执行层中的一个核心组件，而该执行层还必须负责管理动作、状态持久化及验证。

3. 阶段 3：驾驭（Harness）工程

当核心瓶颈不再仅仅是工作流如何整合信息与工具调用，而是如何控制智体在多步执行轨迹中的行为时，这一阶段便随之开启。尽管智体工作流优化了进入上下文窗口的内容及工具调用选择，但许多长程任务中的失败并非仅仅源于信息缺失，而是属于执行层面的失败：例如智体丢失进度追踪、误用工具、偏离初始目标、重复无效步骤，或在出错后无法恢复。

驾驭（Harness）工程正是为了解决这一执行层面的瓶颈而产生的。驾驭是一个结构化的运行时层，负责组织并稳定智体的执行过程。它决定了智体能观察到什么、可采取何种行动、哪些状态得以保留、控制流程如何推进，以及如何检测、限制或修复故障。虽然工作流与上下文设计依然重要，但它们已成为更广泛的执行层中的组成部分；该执行层还负责管理观察、行动、持久化状态、验证及治理机制。

证明驾驭设计重要性的证据。支持驾驭设计的理由不再仅仅基于工程直觉或孤立的案例。SWE-agent [21] 的研究表明，仅通过重新设计智体与计算机之间的交互界面，就能在模型不变的情况下显著提升编程智体的性能。NLAH 将驾驭模块定义为可移植且可审查的组件，并通过受控消融实验证明了其贡献是可量化且可叠加的 [23]。Meta-Harness 更进一步，将驾驭本身的优化视为一个搜索问题，结果显示，自动优化的驾驭在 Terminal-Bench [20], [24] 上的表现优于人工设计的基准方案。近期的研究将这些证据的适用范围从编程智体界面扩展到运行时编排及形式化控制机制 [136]–[138]。其他系统则将记忆、协议互操作性、上下文问题增强以及企业级上下文生命周期管理视为驾驭层面的设计对象 [139]–[144]。这些结果表明，驾驭设计已成为一个核心优化维度，而不再仅仅是次要的实现细节。

工业界与生态系统的视角。在工业级系统中，同样可以看到这一转变趋势。 Anthropic 的公开指导方针强调工具的精简性与可读性，以及规范的运行时行为 [6], [64], [145]。OpenAI 的指导方针则侧重于环境设计、结构化产出物（artifacts）以及可复用的智体基础设施 [7], [39], [146]。微软的 Magentic-One 强调针对复杂网络和文件任务的多智体编排 [37]；而诸如 OpenHands 等开源系统 [10], [25] 则将“驾驭”（harness）本身作为可审查的代码呈现出来。

在生态系统层面，近期以协议为中心的基准测试进一步强化了这一趋势，它们评估智体在真实的工具路由条件下调用实际服务的能力。MCPWorld [147]、MCP-Atlas [148]、MCPAgent-Bench [149] 和 OSWorld-MCP [150] 将讨论重点从抽象的协议设计转向了可度量的运行时行为。综合来看，这些系统与基准测试表明，驾驭工程不仅是一种工程实践，更正在演变为涵盖基础设施、评估体系及设计理念的共享层。
设计原则。纵观各类论文与系统，若干高层原则反复出现：

• 可读性：运行时环境应在恰当的抽象层级上公开关键状态信息。
• 机制性强制：对于安全性、正确性或可复现性至关重要的约束，应尽可能由运行时环境强制执行，而非完全依赖于智能体对提示词（prompt）的遵循。
• 闭环验证：缺乏中间检查的长程自主运行在结构上是脆弱的。
• 显式产出物：计划、日志、差异（diffs）、摘要及其他中间产物应以可审查对象的形式存在，以便复用、审计或交接。

这些原则使“驾驭（harness）”从一个隐喻概念转变为具体的实体。作为一个耦合的运行时系统，它必须具备以下功能：公开观测信息、构建上下文、组织控制逻辑、协调动作执行、持久化状态，以及实施验证与治理机制。

多模型驾驭（Multi-model harnesses）。许多现代系统不再仅依赖单一模型作为各步骤的认知引擎，而是通过驾驭整合异构模型，分别处理规划、编码、工具使用、验证、检索及特定领域的子任务 [10], [37]–[39], [108]。这种设计将控制循环从“单一模型迭代直至完成”转变为“由运行时系统决定下一个由哪个模型执行操作，以及在何种上下文和约束条件下进行”。典型的模式包括“规划器-执行器-验证器”分解、专家模型路由、辩论或委员会式验证，以及子智体间的任务交接 [37], [113], [115], [151]。从驾驭架构视角来看，多模型设计 [65], [66], [147], [150] 主要侧重于控制循环 L，同时也重塑上下文管理器 C、动作接口 I_act 和验证层 V，因为不同模型在观察、行动和判断时可能处于不同的作用域和权限级别。

可学习的驾驭。与此同时，驾驭本身也正成为一个可优化的对象。例如，NLAH [23] 将驾驭逻辑视为可编辑且可移植的运行时构件；Meta-Harness [24] 探索各种驾驭配置；而 Agentic Harness Engineering (AHE) [40] 则在保持基础模型不变的前提下，利用基于可观测性的反馈来演化驾驭组件。尽管这些系统在机制上各不相同——涵盖手动编辑、搜索或基于轨迹的自适应——但它们传达了一个共同的启示：针对路由、工具暴露、记忆使用和验证的运行时策略，如今已能像早期的提示词（prompts）那样被直接优化。

多模型组合与可学习的运行时策略共同标志着智体系统定义的质变。虽然轻量级的提示词驱动循环在短周期任务中仍能表现出智体特征，但若要可靠地完成长周期任务，则越来越需要设计一种基于多模型的组合式运行时系统，并辅以明确的编排、验证和自适应策略。

4. 阶段 4：智体原生训练与协同演化

当“驾驭”（harness）不再仅仅被视为一种人工辅助稳定的运行时环境，而是被看作一个涵盖一个或多个模型、具备组合性且日益具备学习能力的系统时，阶段 4 便随之开启。因此，核心问题包含两个方面：哪些智体行为应被内化到模型参数中？以及在部署过程中，模型与驾驭应如何协同演化，同时不牺牲安全性或可审查性？

通过交互式训练实现内化。第一个方向致力于将智体行为内化到模型自身之中。模型不再仅仅依赖提示词（prompts）、工作流或运行时编排，而是越来越多地通过训练，学会在交互式环境中进行规划、使用工具、验证中间状态以及从错误中恢复 [42], [152]–[156]。

近期的研究反映两种密切相关的趋势。第一种趋势通过强化学习增强“从推理到动作”的行为模式。例如 DeepSeekMath [73]、DeepSeek-R1 [43] 和 DAPO [157]，这些研究将多步推理、动作选择和验证视为可训练的行为，而非仅仅由提示词诱导的行为。第二种趋势通过在更接近实际部署环境的场景中训练智体，来减少训练与测试之间的不匹配。相关案例包括 ProRL [158]、WebRL [41]、ComputerRL [42]、Environment Tuning [159]、daVinci-Dev [160] 和 Kimi-Dev [161]。综合来看，这些研究方向表明，最初在外部实现的行为（如规划、工具调用、反思和错误恢复）可能会逐渐转变为模型内部习得的行为。内化过程改变了分工模式，而非彻底废除驾驭：更多短程（short-horizon）行为可能会转移到模型参数中，而运行时环境则继续负责提供环境访问、状态管理和安全控制。

协同演化与自我改进。第二个方向将智体工程从一次性训练扩展为对整个技术栈的持续改进。在此过程中，模型、驾驭和更新策略均可在部署期间发生变化，并利用执行反馈来决定保留、修改还是回滚这些变更 [40], [44]–[46], [162]。其目标不仅是将行为纳入既定参数范围内，还要改进整个组合系统从经验中学习的方式。

近期的一些研究方向使这一区分变得具体。诸如 EvolveR [44] 和 AgentEvolver [45] 等经验驱动型系统，通过自我提问、导航和归因分析，将交互轨迹视为可复用的学习信号。Continual Harness [162] 和“无奖励自我进化”（reward-free self-evolution）[163] 探索了无需在推理阶段依赖密集外部奖励的在线适应机制。以 AHE [40] 为代表的“驾驭侧适应”（Harness-side adaptation）表明，即使基础模型保持不变，运行时组件也能发生进化。更具雄心的研究——如 SICA [164]、Darwin Gödel Machine [46] 和 Hyperagents [165] 等递归式自我改进系统——则提出改进机制本身也可能随时间推移而发生改变。

常被笼统归为“自我进化”概念下的三个层面，进行区分。多模型驾驭（Multi-model harnesses）定义了由谁来执行各项运行时角色；可学习驾驭（Learnable harnesses）定义了如何优化运行时策略；协同进化（Co-evolution）则定义了模型、驾驭及改进循环如何根据部署经验进行联合更新。这些层面互为补充，而非彼此替代：组合式运行时构建了实现专业化分工与任务委派的结构基础；可学习驾驭使运行时适应过程变得明确；协同进化则在验证、安全及成本约束下，主导着长期的改进过程。