🤖 AI

From Question Answering to Task Completion: A Survey on Agent System and Harness Design

本综述提出了一个针对基于大语言模型智能体的模型护栏框架，该框架通过分析基础模型与执行运行时之间的耦合（包含六项关键职责）如何决定系统的性能、可靠性和泛化能力，将关注点从被动问答转向主动任务完成。

原作者： Jianyuan Guo, Zhiwei Hao, Chengcheng Wang, Cheng Fan, Tingzhang Luo, Hongguang Li, Ying Gao, Hefei Mei, Jiankun Peng, Rongjian Xu, Minjing Dong, Han Wu, Mengyu Zheng, Kai Han, Shiqi Wang, Chang Xu, Yu

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jianyuan Guo, Zhiwei Hao, Chengcheng Wang, Cheng Fan, Tingzhang Luo, Hongguang Li, Ying Gao, Hefei Mei, Jiankun Peng, Rongjian Xu, Minjing Dong, Han Wu, Mengyu Zheng, Kai Han, Shiqi Wang, Chang Xu, Yunhe Wang

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

核心思想：不仅仅是关于大脑

想象一下，你雇佣了一位世界顶级的名厨（AI 模型）来为一场晚宴烹饪一道复杂的、多道菜式的盛宴。在过去，人们认为唯一重要的事情就是这位厨师有多聪明。如果厨师掌握了所有的食谱，那么这顿饭就会很完美。

但本文认为，厨师仅仅是故事的一半。

如果你给这位厨师一个坏掉的炉灶、没有食材、一份混乱的菜单，而且没有人告诉他汤快烧焦了，那么即使这位厨师是个天才，这顿饭也会失败。这个“炉灶”、“食材”和“厨房经理”就是作者所说的**“护套”（Harness）**。

本文的核心观点是：智能体的性能不仅取决于 AI 有多聪明，还取决于 AI 与其工作的“厨房”（护套）如何匹配。

成长的四个阶段

作者将我们构建这些 AI“智能体”的过程描述为四个不同的阶段，就像一个孩子的成长过程：

第一阶段：提示词工程师（“请对我好一点”阶段）
- 类比： 你试图让一个聪明但害羞的学生回答问题。你尝试不同的提问方式：“请解释一下这个”、“这里有一个例子”，或者“请一步步思考”。
- 局限性： 你能礼貌地提问的次数是有限的。如果学生不知道答案，或者问题需要他们去图书馆、翻开一本书并写一份报告，仅仅靠礼貌地提问是没用的。
第二阶段：上下文工程师（“图书管理员”阶段）
- 类比： 现在你意识到学生需要帮助寻找合适的书籍。你建立了一个系统，负责抓取正确的页面、总结它们，并在学生回答之前把它们递给学生。
- 局限性： 你仍然只是在向他们传递信息。如果学生开始写错内容，或者分心了，你并没有一个系统来阻止他们、检查他们的工作或纠正他们的错误。
第三阶段：护套工程师（“项目经理”阶段）
- 类比： 这是一个巨大的转变。你不再仅仅是给出指令，而是围绕着这个学生构建一个完整的操作系统。
  - 观察（Observation）： 你给了他们一个摄像头，让他们看到正在发生什么。
  - 控制（Control）： 你拥有一个计时器和一个停止按钮。
  - 行动（Action）： 你给了他们键盘和鼠标。
  - 验证（Verification）： 你有一位老师来检查每一步。如果学生写的代码崩溃了，系统会自动回滚并说：“再试一次。”
- 结果： 本文表明，通过仅仅重新设计这个“厨房”（护套），你可以让一个平庸的厨师做出五星级大餐，或者让一个天才厨师做得更好。
第四阶段：协同进化阶段（“自我改进团队”阶段）
- 类比： 现在，学生和厨房经理互相学习。学生通过在这个特定的厨房里练习，变得更擅长烹饪；而厨房经理通过观察学生的烹饪过程，变得更擅长管理。他们共同进化。

“厨房”的六个组成部分（护套解剖学）

本文将这个“护套”分解为六个具体的职责，就像一个组织有序的厨房团队：

观察（眼睛）： AI 如何看待世界？它是在看一张模糊的截图，还是在看一份清晰、有序的数据列表？
上下文（记忆）： AI 记得哪些信息？我们是把整个对话历史都喂给它，还是只喂给它最重要的笔记？
控制（指挥家）： 谁来决定下一步做什么？是让 AI 一直运行直到它疲劳为止，还是由一名经理告诉它何时停止、何时寻求帮助或何时切换任务？
行动（双手）： AI 实际上是如何做事的？它是只能说“我点击了它”，还是真的能点击一个按钮？护套将 AI 的语言转化为真实的动作。
状态（档案柜）： AI 将它的工作存储在哪里？如果它写了一份草稿，这份草稿是保存在文件中，还是会在屏幕刷新时丢失？
验证（安全检查员）： 这至关重要。在 AI 向客户发送文件之前，是否进行了安全检查？如果 AI 采取了危险的操作，系统是否会拦截它？

为什么这很重要：瓶颈的转移

本文研究了许多测试（基准测试），在这些测试中，AI 尝试完成真实的工作，比如修复计算机代码或浏览网页。

旧观点： 我们曾认为，只要把 AI 的大脑做得更大、更聪明，就能解决一切问题。
新观点： 本文发现，“大脑”已经遇到了极限。 仅仅扩大大脑规模带来的提升微乎其微。现在的真正瓶颈在于护套。

证据：

在编程测试中，同一个 AI 模型在使用简单护套时成功率为 23%，但在使用设计良好的护套时，成功率达到了 72%。
这就像是把法拉利引擎（AI）装进了一辆自行车架子（糟糕的护套）里。它跑不快。把同样的引擎装进赛车底盘（好的护套）里，它就能赢得比赛。

总结

我们正在从“仅仅是一个回答问题的聊天机器人”转向构建自主工作的员工。

要构建一个可靠的员工，你不能只挑选最聪明的大脑。你必须设计他们工作的整个环境：

他们看到了什么？
他们拥有哪些工具？
谁来检查他们的工作？
当他们犯错时，他们如何恢复？

本文的结论是，AI 的未来不仅仅在于更大的模型，而在于对围绕这些模型的系统的更好工程设计。智能体的质量来自于模型与护套之间的伙伴关系。

技术总结：从问答到任务完成：智能体系统与执行框架综述

1. 问题陈述

基于大语言模型（LLM）的智能体领域已从被动的问答（QA）转向主动的多步任务完成。虽然前沿模型在静态基准测试（如 MMLU、GPQA）上已达到饱和，但在交互式、长程（long-horizon）智能体任务（如 SWE-bench、WebArena）中表现出显著的可靠性差距。本综述旨在解决的核心问题是识别智能体系统的性能瓶颈所在。作者认为，瓶颈不再仅仅是基础模型的推理能力，而越来越多地在于执行框架（execution harness）——即介导模型与环境之间交互的运行时基础设施。论文指出，智能体的质量（成功率、效率、安全性、泛化性）是模型与其框架耦合后的涌现属性，而非仅由模型本身决定的函数。

2. 方法论与框架

本综述采用**模型-框架视角（model–harness lens）**来分析智能体工程的演进。它并非提出一种新算法，而是通过一个特定的概念框架对现有文献、基准测试和工业报告进行了综合分析：

功能视角与实现视角： 论文区分了智能体的功能定义（一个执行感知、推理、行动和适应的定向闭环系统）与实现视角（一个与执行框架耦合的 LLM）。
形式化分解： 执行框架 ( $H$ $H$ ) 被形式化为一个由六个耦合的运行时职责组成的元组：
1. 观察接口 ( $I_{obs}$ )：将原始环境信号（日志、DOM、差异/diffs）转化为模型可用的观测值。
2. 上下文管理器 ( $C$ )：对进入模型上下文窗口的信息进行策展、压缩和刷新。
3. 控制循环 ( $L$ )：编排“观察-推理-行动-反馈”循环，包括步骤调度、委托和停止准则。
4. 行动接口 ( $I_{act}$ )：将模型输出映射为可执行操作（API、Shell 命令、工具调用）。
5. 状态与制品库 ( $S$ )：在活跃上下文窗口之外持久化执行状态、计划、检查点和生成的制品。
6. 验证与治理 ( $V$ )：检查结果、强制执行安全约束、管理权限并处理恢复/回滚。
演进分析： 文献被组织为四个连续的智能体工程范式，分析了主要的性能杠杆是如何随阶段转移的：
1. 提示词工程（Prompt Engineering）：优化单轮指令（解决“表达”问题）。
2. 工作流与上下文工程（Workflows and Context Engineering）：策展信息生命周期和工具定义（解决“信息”问题）。
3. 框架工程（Harness Engineering）：设计用于反馈驱动执行、状态持久化和错误恢复的运行时基础设施（解决“执行”问题）。
4. 智能体原生训练与协同演进（Agent-Native Training and Co-Evolution）：将智能行为（规划、验证）内化到模型参数中，并联合演进模型与框架对。

3. 主要贡献

本综述与以往工作相比有三个主要区别：

演进优先的综合分析： 它没有采用静态组件分类法，而是追踪了工程瓶颈从提示词优化向运行时系统设计及未来协同演进的迁移。
以框架为中心的视角： 它将执行框架视为一个一等公民的技术对象，并将其分解为上述六个运行时组件。它认为，即使底层模型固定，框架设计也决定了可靠性和效率。
经验证据集成： 它将学术基准测试与工业实践相结合，利用经验数据展示了运行时设计选择（如观察塑造、上下文管理）如何直接影响智能体性能。

具体贡献包括：

以模型为中心扩展的局限性： 论文分析了随着模型规模扩大，由于资源-性能边界以及静态基准测试的测量饱和，模型在智能体任务上的收益如何递减。
任务-框架映射： 它将任务属性（时程、环境类型、自主程度）映射到特定的框架配置。例如，软件工程任务侧重于验证，而 Web/GUI 任务则侧重于观察和行动接口。
基准测试分析： 综述对 SWE-bench、Terminal-Bench 和 WebArena 进行了详细的经验分析，证明了：
- 即使是相同的骨干模型，其表现也会因框架的不同而产生两位数的准确率差异。
- 如果接口设计最优，极简的脚手架（如 mini-SWE-agent）有时可以达到甚至接近复杂、功能齐全的运行时的性能。
- 由于专有框架优化的存在，厂商报告的分数往往高于开源结果，这凸显了“脚手架”的重要性。

4. 结果与发现

框架的影响： 来自 SWE-bench Verified 的经验证据显示，对于固定的模型（如 Claude 3.5 Sonnet），解决率根据框架的不同在 ~33% 到 ~53% 之间波动。同样，在 Terminal-Bench 2.0 上，同一模型（如 GPT-5.3-Codex）在不同框架下的表现从 64.7% 变化到 78.4%。
瓶颈迁移： 随着任务变得更加复杂（从 L2 短程向 L4 开放式转变），瓶颈从模型的推理能力转向了框架管理状态、验证结果和从错误中恢复的能力。
成本与效率： 更高的准确率通常与更高的资源成本（Token 使用量、延迟、超时）相关联。论文指出，“成功”取决于运行时配置，包括重试预算和上下文策略。
多模型与可学习框架： 近期趋势显示出向组合式运行时（为规划、编码和验证路由不同的模型）以及可学习框架（将运行时策略作为制品进行优化）转变。

5. 意义与主张

论文声称该领域已超越了“提示词技巧（prompt craft）”，进入了全系统研究阶段。其意义在于重新定义了智能体开发：

智能体质量是涌现的： 成功、效率和安全性并非模型固有的，而是源于模型能力、运行时基础设施、任务结构和评估设计之间的相互作用。
价值感知评估的必要性： 作者主张从以分数为中心的排行榜转向价值感知评估（value-aware evaluation），即同时优化任务成功率、成本、延迟、安全性及过程质量。他们提出了一个正式的目标函数，用于平衡效用与成本、延迟及风险的约束。
未来方向： 综述指出了通往智能体原生训练（将验证和恢复行为内化到模型参数中）以及协同演进（通过执行轨迹联合更新模型与框架）的路径。然而，作者也谦逊地指出，模型设计与系统设计之间的界限仍在重新界定中，且在现实环境中的可靠性仍低于部署需求。

总之，本综述认为理解执行框架现在是智能体工程的核心挑战，因为它决定了模型能力如何转化为可靠的长程任务完成。