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-horizo​​n 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 Con​​text 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-horizo​​n行为可能会转移到模型参数中而运行时环境则继续负责提供环境访问、状态管理和安全控制。协同演化与自我改进。第二个方向将智体工程从一次性训练扩展为对整个技术栈的持续改进。在此过程中模型、驾驭和更新策略均可在部署期间发生变化并利用执行反馈来决定保留、修改还是回滚这些变更 [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则定义了模型、驾驭及改进循环如何根据部署经验进行联合更新​​。这些层面互为补充而非彼此替代组合式运行时构建了实现专业化分工与任务委派的结构基础可学习驾驭使运行时适应过程变得明确协同进化则在验证、安全及成本约束下主导着长期的改进过程。。。。。。。待续。。。。。。