精读：Agent Harness for Large Language Model Agents — A Survey

精读系列说明：本文面向零基础大模型学习新手，采用"原文→翻译→讲解"三段式精译核心段落，力求把"Agent Harness"这个重要概念讲透。

一、论文基本信息

阅读地图

本文建议按如下顺序阅读：

核心概念 → 形式化定义 → 关键证据 → 系统分类 → 9大挑战 → 串联已学知识

1. 先读第二节（术语速查）——扫清语言障碍
2. 再读第三节（什么是 Harness）——建立核心直觉
3. 再读第五节（六元组拆解）——掌握架构骨架
4. 再读第六节（震撼证据）——理解为何重要
5. 最后读第七-九节（分类、挑战、串联）——全景理解

二、零基础术语速查表

遇到不懂的词，先来这里查，再去读正文。

三、什么是"Agent Harness（智能体执行外壳）"

3.1 最通俗的类比

想象你雇了一位天才厨师（这就是 LLM），但只有厨师是不够的：

• 他需要一个厨房（执行环境）
• 需要菜谱和食材清单（工具注册表）
• 需要工作台来摆放正在做的菜（上下文管理）
• 需要冰箱来存放没做完的菜（状态存储）
• 需要操作规程和卫生检查（生命周期钩子）
• 需要试吃评分标准（评估接口）

这整套"厨房基础设施"，就是 Agent Harness（执行外壳）。

换一个更精准的类比：

模型 = 引擎；Harness = 车身底盘 + 整套传动系统 + 仪表盘 + 安全带 + 制动系统

再好的引擎，如果没有车身底盘，它只是一堆金属零件，无法上路行驶。

这正是本论文的核心论点：

"Agent Harness 是底盘；模型是引擎。"（业界 2026 年共识）

3.2 为什么以前没人重视 Harness？

过去大家发论文都在研究"怎么让 LLM 本身更聪明"，比如：
- 更大的模型参数
- 更好的训练数据
- 更强的推理能力

但现实中，很多 Agent 系统失败不是因为模型不够聪明，而是因为：

• 工具调用崩溃了，没有恢复机制（缺少 E 执行循环）
• 上下文窗口装不下历史记录（缺少 C 上下文管理）
• 任务执行到一半程序退出，下次无法续上（缺少 S 状态存储）
• Agent 执行了危险操作却没有任何拦截（缺少 L 生命周期钩子）

本论文的贡献，就是第一次把这套"围绕模型的工程外壳"当作正式的学术研究对象来系统研究。

3.3 Harness 的形式化定义

本综述将 Agent Harness 形式化为一个六元组：

$$H = (E, T, C, S, L, V)$$

四、Abstract 精译

4.1 原文（摘要核心句）

原文

"Dominant narratives attribute agent performance to underlying model capabilities. This survey challenges that assumption. We propose a formal definition of the Agent Harness as the tuple H = (E, T, C, S, L, V), systematically survey 110+ papers covering 23 systems, and document nine open technical challenges. We argue that Agent Harness design — not model capability — is the binding constraint on deployed agent reliability."

4.2 翻译

翻译

"主流观点将智能体的性能归因于底层模型的能力。本综述挑战了这一假设。 我们提出了 Agent Harness 的形式化定义，将其定义为六元组 H = (E, T, C, S, L, V)，系统综述了涵盖 23 个系统的 110 余篇论文，并记录了九项开放性技术挑战。我们认为，限制已部署智能体可靠性的约束瓶颈是 Agent Harness 设计，而非模型能力。"

4.3 讲解

这段摘要只有几句话，但每句都很有分量：

1. "挑战主流假设"：这是学术勇气。大部分论文说"我们改进了模型"，这篇说"你们都搞错了方向，关键不是模型"。

2. 形式化定义：把原本模糊的"工程外壳"概念，用数学化的六元组表达，这是这篇论文最大的理论贡献。

3. "约束瓶颈"（binding constraint）：工程中的"约束瓶颈"指系统中最薄弱、限制整体能力的那个环节。论文认为：不是模型太笨，而是 Harness 太差，才导致 Agent 在实际部署中不可靠。

五、核心贡献与核心论点精译

5.1 核心论点

原文

"Agent Harness — not the model itself — is the primary determinant of agent reliability at scale."

翻译

"Agent Harness——而非模型本身——是智能体大规模部署可靠性的首要决定因素。"

讲解

这句话是整篇综述的灵魂。注意两个关键词：
- "首要决定因素"（primary determinant）：不是说模型不重要，而是在实际部署中，Harness 的质量比模型本身更能决定成败。
- "大规模部署"（at scale）：在实验室做个 demo，也许模型智慧就够了；但要在生产环境中稳定处理成千上万个任务，没有好的 Harness 必然崩溃。

5.2 震撼的经验证据（四个案例逐条讲解）

论文提供了四个来自真实部署的案例，每一个都让人印象深刻：

案例 1：Grok Code Fast 的 SWE-bench 奇迹

"Pi Research：Grok Code Fast 1 模型在 SWE-bench 上从 6.7% → 68.3%，仅通过修改 Agent Harness 的编辑工具格式——模型不变。"

讲解：

SWE-bench 是让 AI 修复真实 GitHub bug 的权威测试。6.7% 意味着几乎所有 bug 都修不好，68.3% 意味着超过三分之二的 bug 都能修好。

关键：模型一行代码没改，只是改了"Agent 调用编辑工具时的数据格式"，成绩提升了 10 倍。

这就像：同一个厨师，换了一套更顺手的厨具，做菜水平从普通直接飙升到米其林三星——厨师的技术根本没变，是厨房设备（Harness）决定了上限。

案例 2：OpenAI Codex 的 100 万行代码失败

"OpenAI Codex：5 个月内生成 100 万行代码，0 行手写——失败归因于'环境规范不足'而非模型能力。"

讲解：

Codex 作为代码生成模型，能力极强。但在一个实际项目里，Codex 生成了 100 万行代码，结果项目失败了。失败原因不是模型写出的代码质量差，而是"执行环境设计得太差了"——没有好的 Harness 来：
- 管理代码的上下文和依赖关系
- 检查每次代码修改的影响范围
- 保存阶段性工作进度

这说明：光有聪明的模型，没有支撑它运行的基础设施，照样失败。

案例 3：Stripe Minions 的每周 1300 个 PR

"Stripe Minions：每周 1300 个 PR，0 行人工代码——Agent Harness 优先策略的成功案例。"

讲解：

这是正面案例。Stripe（著名支付公司）的工程团队构建了一套以 Harness 为核心的 Agent 系统，每周自动提交 1300 个代码改动，全程无需人工编写代码。

这不是模型有多厉害的故事，而是"把执行外壳做对了"的成功。Stripe 明确表示他们的策略是"Agent Harness 优先"。

案例 4：METR 发现的评估危机

"METR：通过基准测试的 PR 人工合并率低 24.2 个百分点，差距以 9.6pp/年速度扩大。"

讲解：

这是最让人警醒的数据。METR（AI 安全评估机构）发现：

• AI Agent 在基准测试（如 SWE-bench）上"通过"了的 PR（代码修改），如果交给真实的人类工程师审查，有 24.2% 会被拒绝合并。
• 而且这个差距每年还在扩大（9.6 个百分点/年）。

这说明：我们评估 Agent 好不好的工具本身就有问题。这对应的正是 Harness 的 V 组件（评估接口）的挑战——我们的评估基础设施还不够成熟。

六、H=(E,T,C,S,L,V) 六元组逐个拆解

这是本综述最核心的理论贡献，我们逐一拆解每个组件。

6.1 E——执行循环（Execution Loop）

原文定义

"Observation-Think-Act loop, termination conditions, error recovery."

翻译

"观察-思考-行动循环，终止条件，错误恢复机制。"

新手讲解

执行循环是 Agent 的"心跳"。

想象一个 Agent 在帮你修 bug：

第1轮：
  观察 → "当前代码报错 NullPointerException"
  思考 → "可能是第42行没判断空值"
  行动 → "修改第42行，添加空值检查"

第2轮：
  观察 → "修改后新报错：TypeError"
  思考 → "空值检查改对了，但类型不匹配"
  行动 → "继续修改..."

...（直到测试全通过，或达到最大轮次）

这个循环就是 E 组件。它需要解决三个关键问题：

1. 循环什么时候停？（终止条件）
   - 任务完成？最大轮次？出现某种错误？
   - 没有好的终止条件，Agent 可能无限循环

2. 出错了怎么办？（错误恢复）
   - 工具调用失败？网络超时？
   - 好的 Harness 会自动重试、切换策略

3. 循环的节奏和深度？
   - 每轮思考要多深？什么时候该并行执行？

对应已学论文：ReAct（Yao et al., ICLR 2023）就是专门研究"如何设计 观察-思考-行动 循环"的经典论文，是 E 组件的理论基础之一。

6.2 T——工具注册表（Tool Registry）

原文定义

"Typed tool catalog, routing, monitoring, schema validation."

翻译

"类型化工具目录，请求路由，调用监控，模式校验。"

新手讲解

工具注册表是 Agent 的"能力菜单"。

Agent 能做什么，取决于它有什么工具。常见工具包括：
- 执行代码（run_python）
- 读写文件（read_file, write_file）
- 搜索网络（web_search）
- 调用外部 API（call_api）

T 组件要管理这些工具：

1. 类型化目录：每个工具要有清晰的"输入什么、输出什么"说明（schema），就像乐高积木的规格说明书，不合规格不能拼

2. 路由：Agent 说"我要搜索"时，系统自动选择合适的搜索工具（本地缓存？Bing？Google？）

3. 监控：记录哪个工具被调用了几次、耗时多少、出错率多高

4. Schema 校验：工具调用参数格式不对，在执行前就拒绝，避免事后才发现错误

关键证据：Vercel 工程团队发现，把工具数量削减 80%，比换更强的模型效果还好。工具太多，Agent 反而搞不清楚该用哪个（就像菜单太长反而不知道点什么）。

6.3 C——上下文管理器（Context Manager）

原文定义

"What enters the context window, compression, retrieval."

翻译

"决定什么内容进入上下文窗口，内容压缩，按需检索。"

新手讲解

上下文管理器是 Agent 的"工作记忆调度员"。

LLM 有一个严重限制：它的"上下文窗口"是有限的，就像一块白板，写满了就要擦掉旧的才能写新的。

假设你的白板只能写 2000 个字，但你要处理的任务涉及 10000 个字的材料，C 组件要决定：

• 把哪 2000 个字放到白板上？（选择）
• 超过的部分能不能压缩成摘要？（压缩）
• 需要某个已经"擦掉"的内容时怎么找回来？（检索）

这三个问题决定了 Agent 能不能"记住"任务的关键信息。

对应已学论文：
- Lost in the Middle（Liu et al., 2024）：研究了 LLM 对上下文不同位置信息的利用差异——中间的信息容易被"遗忘"，即使信息还在上下文里。这说明"把什么内容放进上下文"的位置也很关键。
- RAG（检索增强生成）：从外部知识库检索相关内容放入上下文，是 C 组件"检索"功能的核心技术。
- MemGPT（Packer et al.）：专门解决"如何管理超长上下文"，把操作系统的内存管理理念（虚拟内存、分页）引入 LLM，是 C 组件的典型实现。

6.4 S——状态存储（State Store）

原文定义

"Cross-turn/session persistence, crash recovery."

翻译

"跨轮次/跨会话的状态持久化，崩溃恢复。"

新手讲解

状态存储是 Agent 的"游戏存档系统"。

玩游戏时，如果没有存档功能，每次死亡都要从头开始。Agent 也一样：

• 跨轮次持久化：这轮循环的结果，下轮循环能用上
• 跨会话持久化：今天下班了，明天继续，上次做到哪里还记得
• 崩溃恢复：程序突然报错了，不要从头开始，从最近的"存档点"恢复

对于长时间运行的任务（比如"帮我重构整个代码库"），S 组件至关重要。没有 S 组件的 Agent，一次意外就让所有工作白费。

对应已学论文：
- MemGPT 的 S 组件设计：除了管理上下文（C），MemGPT 也实现了层次化的记忆存储，包括工作记忆（当前任务）→外部存储（长期知识）。
- Voyager（Wang et al., 2023）：在 Minecraft 游戏中，Voyager 把获得的"技能代码"存储起来，下次遇到类似任务可以直接调用——这就是 S 组件的技能持久化。

6.5 L——生命周期钩子（Lifecycle Hooks）

原文定义

"Authentication, logging, policy enforcement, instrumentation."

翻译

"鉴权认证，日志记录，策略执行，监测埋点。"

新手讲解

生命周期钩子是 Agent 的"规章制度执行者"。

想象餐厅的食品安全检查员：厨师（模型）每做一道菜前后，检查员都要确认食材新鲜（鉴权）、记录食谱（日志）、确保符合卫生规范（策略执行）、监测厨房温度（埋点监控）。

L 组件在 Agent 执行的关键时刻"插入"检查：

Agent 准备调用工具 "delete_file"
  ↓
[L 钩子触发] → 检查：这个操作被允许吗？→ 不允许 → 拒绝并记录日志
  ↓
Agent 收到拒绝，换一种方式处理

L 组件的关键特性：Agent 本身不需要知道这些检查的存在，检查逻辑在外部注入。

为什么重要：
- 缺少 L 组件，Agent 可能删除重要文件、泄露敏感数据、无限消耗资源
- SandboxEscapeBench 发现：前沿 LLM 有 15-35% 的概率会逃逸容器沙箱
- PRISM 系统用 10 个钩子实现了零分叉运行时，把逃逸率降至接近零，且额外开销不到 5ms

6.6 V——评估接口（Evaluation Interface）

原文定义

"Action traces, intermediate states, success signals."

翻译

"动作轨迹记录，中间状态快照，成功信号定义。"

新手讲解

评估接口是 Agent 的"飞行数据记录仪"。

飞机的黑匣子记录每一秒的飞行数据，出了事故能追查原因。V 组件为 Agent 提供同样的能力：

1. 动作轨迹：Agent 每一步做了什么，完整记录（"第3步调用了 write_file，参数是...，返回了..."）

2. 中间状态：每轮循环结束时，当前任务完成了多少、还剩什么

3. 成功信号：明确定义什么算"完成"——不能只是"Agent 说完成了"，要有客观可验证的标准

为什么很多系统缺少 V：V 组件不影响 Agent 功能，只影响可观测性和可调试性。但没有 V，出了问题完全不知道哪里错了。

关键问题：OSWorld 发现自动评估有 28% 的假阴性率，即 28% 实际完成的任务被判为"未完成"。评估工具本身不准确，严重影响我们判断 Agent 到底有多好。

七、历史时间线：从测试框架到 Agent Harness

了解 Harness 概念是如何演化来的，帮助理解为什么今天我们需要系统研究它。

关键洞察：从上表可以看到，每隔几年就有一个核心组件被学术界"发现"并深入研究，但直到 2026 年，才有人把 E/T/C/S/L/V 六个组件放在一起，作为一个统一框架来系统研究。

八、系统分类全景：5大类 23 个系统

论文根据"Harness 完备性"（实现了六个组件中的哪些）对 23 个系统进行分类。

分类依据的重要性：以前大家按"应用领域"（编程/浏览器/游戏）分类，没法解释"为什么同样用 GPT-4，A 系统比 B 系统可靠得多"。按 Harness 完备性分类，直接揭示了可靠性差异的根源。

8.1 Harness 完备性矩阵（核心图表）

图例：✓ 完全支持 · ≈ 部分支持 · ✗ 缺失

8.2 五大类系统点评

第一类：全栈式 Agent Harness

这类系统实现了全部或接近全部的 ETCSLV 组件，可以直接用于生产环境。

• Claude Code（Anthropic）：你正在使用的这个工具。完整的代码执行环境，强工具注册表（读写文件、执行命令、搜索代码），会话级状态持久化，完整生命周期钩子（权限检查、沙箱限制）。
• OpenHands：开源的全栈代码 Agent，设计目标是"通用软件工程师"，可以完成从阅读代码到提交 PR 的全流程。
• SWE-agent：专攻 GitHub bug 修复，通过精心设计的"Agent-Computer Interface (ACI)"大幅提升代码编辑效果，是 SWE-bench 排行榜的常客。

第二类：多智能体执行器

让多个 Agent 分工合作，擅长复杂协作任务，但单个 Agent 的 Harness 完备性不如全栈系统。

• MetaGPT：模拟软件公司（产品经理、架构师、程序员分别是不同的 Agent），有完整的工具调用和执行循环。
• AutoGen（微软）：灵活的多 Agent 对话框架，支持人类和 AI 混合参与，适合构建自定义多 Agent 工作流。
• CAMEL：首个通过"角色扮演"实现多 Agent 协作的系统，奠定了多 Agent 研究的基础，但缺少状态持久化（S）。

第三类：通用框架

提供构建 Agent 的基础组件，开发者自己拼装，而非开箱即用的完整系统。

• LangChain：最流行的 LLM 应用框架，E/T/C 强大，但缺少 V（评估接口），不适合大规模测试对比。
• LangGraph：LangChain 的升级版，专注于状态图驱动的工作流，但同样缺少 V。
• LlamaIndex：专长是 RAG 和数据管道（C/T 很强），但缺少 L 和 V。

第四类：能力模块

只实现了六个组件中的 2-3 个，专注于解决某个特定问题，而非提供完整 Harness。

• MemGPT：只关注 C 和 S（上下文管理 + 状态存储），没有 E/T/L/V。是研究"如何管理超长上下文"的重要工作，但不是完整系统。
• Voyager：在 Minecraft 里学会新技能并存储（T + S 很强），是技能积累的典型方案。
• Reflexion：专注于让 Agent"从失败中反思学习"（S 很强，保存反思记忆），但缺工具和生命周期控制。
• Generative Agents：模拟 25 个有个性、有记忆的虚拟人，专为社会行为仿真设计，缺工具调用（T/L 为空）。

第五类：评估基础设施

这些系统的目标是评估其他 Agent，而非让 Agent 完成任务，因此 V 组件很强，L 组件普遍缺失。

• HAL：统一了 21,730 次评估，用小时代替了数周的评估时间，是目前最全面的 Agent 评估基础设施。
• AgentBench：首个多任务 Agent 综合评测平台，覆盖 8 种任务类型。
• OSWorld：在真实计算机界面（桌面软件、文件管理器等）测试 Agent，最贴近真实使用。
• BrowserGym：专注于浏览器操作任务的评估环境。

核心发现：

"没有任何智能体框架能够在不实现全部六个治理组件的情况下达到生产可靠性。缺少 L 组件的系统无法执行安全策略。缺少 V 组件的系统无法调试故障。缺少 S 组件的系统无法从崩溃中恢复。"

九、9大开放挑战逐条精译与讲解

这九大挑战是当前学术界和工业界都没有完全解决的难题，代表了 Agent Harness 工程的前沿战场。

挑战 1：安全与沙箱（Security & Sandboxing）

是什么问题：

Agent 需要真正操作文件系统、执行命令、调用网络 API——这些都是危险操作。传统的应用程序沙箱（如手机 App 权限管理）是针对"不会主动学坏的代码"设计的，但 Agent 是有智能的，它可能主动"找到"沙箱的漏洞。

为什么难：

• 如果沙箱太严格，Agent 什么也做不了（没用）
• 如果沙箱太宽松，Agent 可能删除重要文件、泄露密钥、访问不该访问的系统
• Agent 的操作是动态的、不可预测的，很难事先列出"允许做什么"

现状与数据：

• SandboxEscapeBench 测试了前沿 LLM 逃逸容器沙箱的能力：逃逸率 15-35%。也就是说，3 到 7 次里就有 1 次，主流 AI 能突破容器边界。
• PRISM 系统通过 10 个生命周期钩子（零分叉设计），把逃逸率降至接近零，额外性能开销 <5ms。
• 当前防御是反应式的（检测到逃逸才处理），没有预防式的（从数学上证明逃逸不可能发生）。
• 间接提示注入（Indirect Prompt Injection）是新型攻击手段：攻击者在网页或文档里藏入"指令"，Agent 读取后被操控执行恶意操作。

挑战 2：评估与基准测试（Evaluation & Benchmarking）

是什么问题：

我们如何知道一个 Agent 到底有多好？基准测试（benchmark）是标准答案，但这些测试本身有根本性缺陷。

为什么难：

• 假阴性：OSWorld 发现自动评估有 28% 的假阴性率（完成了任务但被判为失败）。这意味着我们低估了 Agent 的能力。
• 假阳性更危险：METR 发现通过 SWE-bench 的 PR 有 24.2% 不会被真实工程师合并（格式通过但工程质量不达标）。这意味着我们高估了 Agent 的实际部署价值。
• 测试泄露：Agent 可能在训练时"见过"基准测试的答案，成绩虚高。
• 任务设计过于简化：真实工程任务往往需要跨会话、跨天执行，但大多数基准只测单次短任务。
• HAL 统一了 20,000+ 次评估，把"数周的评估"压缩到"数小时"，是目前最系统的解决方案，但无法消除上述根本性问题。

现状：

差距以 9.6 个百分点/年 的速度扩大——基准分数提升的速度，比真实部署价值提升的速度快得多。这是 2026 年 Agent 领域最严峻的危机之一。

挑战 3：协议标准化（Protocol Standardization）

是什么问题：

目前 Agent、工具、其他 Agent 之间用什么"语言"通信，没有统一标准。就像早期互联网每家公司用自己的网络协议，Agent 生态碎片化严重。

为什么难：

不同层次的通信需要不同的协议设计权衡：
- 工具调用：要快（毫秒级），要类型安全
- Agent 间通信：需要携带上下文、意图、权限信息，结构更复杂

现状：

目前有三个协议并存：

这三个协议并不互斥，服务于互补的场景，但尚未形成统一生态。大量 Agent 框架仍使用自定义格式，系统之间无法直接互操作。

挑战 4：运行时上下文管理（Runtime Context Management）

是什么问题：

随着任务越来越复杂，Agent 需要处理的信息量爆炸性增长，但上下文窗口是有限的（即使是 100 万 token 的长上下文模型）。

为什么难：

• "装得下"≠"用得好"：Liu et al. 的《Lost in the Middle》研究证明，LLM 对上下文中不同位置的信息利用程度差异极大——开头和结尾的信息被利用得多，中间的信息经常被"忽视"，即使物理上在上下文里。
• 长上下文模型把问题从"能否保留信息"转变为"能否有效使用信息"——后者更难解决。
• 每个任务消耗 平均 100 万 tokens（AgencyBench 数据），按 2026 年的 API 价格，这是巨大的成本。

现状与数据：

• SkillsBench 发现：精心挑选技能注入上下文，可以带来 +16.2 个百分点 的任务成功率提升。这说明"放什么"比"放多少"更重要。
• Mem0 实现了相比"全量上下文"方案高达 90% 的 token 减少，同时保持相近的任务成功率。
• 最佳实践尚未统一：不同任务需要不同的上下文策略，没有"一招鲜吃遍天"的方案。

挑战 5：工具使用与注册（Tool Use & Registration）

是什么问题：

Agent 需要学会"什么时候用什么工具，怎么用对"。工具太多、描述不清、接口不统一，导致 Agent 频繁出错。

为什么难：

• 工具爆炸：ToolLLM 研究了 16,000+ 个真实 API 工具，Agent 从这么多工具中选对一个本身就是难题
• 格式误用：Agent 可能理解工具的"用途"，但调用时参数格式不对（Schema 层面的错误）
• 语义误用：Agent 调用了正确的工具，参数格式也对，但用错了场合（语义层面的错误）
• Schema First 研究（Sigdel & Baral, 2026）发现一个令人担忧的事实：即使有完整的 schema 约束，仍然无法防止语义误用，且所有实验条件下的端到端任务成功率均为零——说明光靠接口设计是不够的

现状与数据：

• Vercel 案例：删除 80% 的工具，Agent 表现反而更好——工具少了，Agent 选择更准确了
• CodeAct（Wang et al., ICML 2024）：让 Agent 直接写代码来"自定义工具"，在 MINT 基准 17/17 项任务上表现优异，比调用预定义 API 减少 20% 的交互轮次
• AutoTool 提出自动选择工具的方法，减少因工具过多导致的"选择困难"

挑战 6：记忆架构（Memory Architecture）

是什么问题：

Agent 需要"记住"各种不同性质的信息：当前任务的细节（短期）、跨任务积累的经验（长期）、与用户的历史对话（情节式）、学到的技能（程序式）……不同类型的信息需要不同的存储和检索策略。

六种记忆架构模式（从简单到复杂）：

关键数据：

• Mem0：相比把所有历史都塞进上下文，token 消耗减少 90%，且任务性能相当
• Zep 时序知识图谱：通过记录知识的时效性，QA 准确率提升 +18.5%
• Agent Workflow Memory (AWM)：把成功完成的任务工作流存为"程序式记忆"，在 Mind2Web 上提升 +14.9%

为什么难：

• 不同任务需要不同记忆模式，没有统一接口
• 记忆写入时机和淘汰策略影响极大，尚无公认最佳实践
• 跨平台的记忆 API 标准化几乎为零（换一个 Agent 框架，记忆全部丢失）

挑战 7：规划与推理（Planning & Reasoning）

是什么问题：

对于需要多步骤、长时间推理的复杂任务，Agent 的规划能力严重不足。Agent 常常"走一步看一步"，缺乏前瞻性，导致无效行动和循环往复。

为什么难：

• 规划需要模拟未来可能性，这在计算上代价极高
• 规划和实际执行之间存在巨大鸿沟——计划很好，执行崩溃
• 需要在"快速行动"和"深思熟虑"之间找到平衡

现状：

• Tree of Thoughts（Yao et al., NeurIPS 2023）：让 LLM 像"思维树"一样探索多个思路分支，选最优路径
• LATS：把蒙特卡洛树搜索（MCTS，围棋 AI 的经典算法）与语言模型反馈结合，是目前规划研究的最强方案之一
• Reflexion（Shinn et al., NeurIPS 2023）：让 Agent 从失败中"口头反思"，把经验写成记忆，下次避免同类错误
• 关键发现：SWE-agent 的接口设计研究表明，Harness 的接口设计对规划表现的影响，超过了模型本身的能力——又回到 Harness 优先的核心论点

挑战 8：多智能体协调（Multi-Agent Coordination）

是什么问题：

当多个 Agent 协作完成一个复杂任务时，如何确保它们之间的协调是可靠的？一个 Agent 出错，会不会拖垮整个系统？

为什么难：

• 拜占庭容错：分布式系统经典难题。在多 Agent 场景中，如果某个 Agent"撒谎"（输出错误信息）或崩溃，其他 Agent 如何识别并继续工作？目前没有成熟的 LLM-Agent 拜占庭容错方案。
• 任务分配：多 Agent 如何有效分工？谁来协调谁？
• 紧密耦合问题：AgencyBench 发现，在"原生 SDK 的 Harness"上运行的 Agent 成功率 48.4%，而在"独立 Harness"上显著更低——说明 Agent 和它的 Harness 高度耦合，不能随意替换。
• 多 Agent 基线悖论：一项研究发现，在很多任务上，一个强大的单 Agent 比多个协作的弱 Agent 效果更好——多 Agent 的复杂性不是免费的。

现状：

• MetaGPT：通过"标准化工作流"（类似公司的流程手册）来协调多 Agent，减少沟通混乱
• AutoGen：灵活的多 Agent 对话，支持多种协调模式
• SAGA（NDSS 2026）：专门研究多 Agent 系统的安全治理架构
• 拜占庭容错问题仍然完全开放，没有生产级方案

挑战 9：算力经济学（Computational Economics）

是什么问题：

Agent 执行任务需要大量计算资源，成本极高，可持续性存疑。

为什么难：

• 成本爆炸：AgencyBench 测量到平均每个任务消耗 100 万 tokens，按 2026 年 API 价格，一个复杂任务就要几美元
• 规模增长：OpenRouter 报告 2026 年 2 月每周消耗 13 万亿 tokens，且每 4 周翻倍——2027 年预计增长 1000 倍
• 成本与质量权衡：用更便宜的小模型，质量下降；用更贵的大模型，成本不可承受

数据：

• AIOS 通过智能 Agent 调度（类似操作系统的进程调度），实现了 2.1 倍的吞吐量加速，在不增加成本的情况下处理更多任务
• H100 GPU 算力价格在 2026 年 1 月出现 10% 的价格飙升，算力稀缺性加剧
• NVIDIA GTC 2026 预测：未来的 Agent 算力需求将需要全新的基础设施架构

为什么 Harness 在这里很重要：

好的 Harness 设计可以大幅降低算力成本：
- 上下文压缩（C 组件）：减少 90% token 消耗
- 工具缓存（T 组件）：避免重复调用相同工具
- 状态检查点（S 组件）：崩溃恢复而非从头重来
- 精准评估（V 组件）：早发现失败，不浪费计算

十、串联已学知识：Harness 视角下的经典论文地图

帮助新手把"Agent Harness"和此前已经精读过的论文连成知识网络。

以下是本系列已覆盖的经典论文，在 Harness 框架下各自对应哪个组件：

10.1 E 组件（执行循环）——ReAct

ReAct: Synergizing Reasoning and Acting in Language Models（Yao et al., ICLR 2023）

ReAct 是 E 组件的理论基础。它解决了执行循环中最核心的问题：Agent 应该如何交替"思考"（Reasoning）和"行动"（Acting）？

ReAct 的核心设计：

想法：我需要搜索"苹果公司总部在哪里"
行动：搜索("苹果公司总部")
观察：结果显示"库比蒂诺，加利福尼亚州"
想法：已经找到答案了
行动：输出答案

这个"想法-行动-观察"三元组，构成了今天几乎所有 Agent 执行循环的模板。

Harness 连接：ReAct 只定义了"循环的内部逻辑"，但没有解决循环的终止条件、错误恢复、并发控制——这些都是 Harness 的 E 组件需要补充的工程部分。

10.2 C 组件（上下文）——Lost in the Middle + RAG

Lost in the Middle: How Language Models Use Long Contexts（Liu et al., TACL 2024）

这篇论文发现了上下文利用的"位置偏差"：放在上下文中间的信息，LLM 容易忽视。即使 Agent 把所有相关信息都放进了上下文，如果放错了位置，效果也会差。

Harness 连接：这直接影响 C 组件（上下文管理器）的设计——不仅要决定"放什么"，还要决定"放哪里"。重要信息要放在开头或结尾，而非中间。

RAG（检索增强生成）

RAG 是 C 组件"按需检索"功能的核心技术：
- 把知识库向量化存储
- 根据当前任务，检索最相关的片段
- 把检索结果注入上下文

Harness 连接：C 组件需要决定何时触发 RAG 检索、检索多少内容、如何将检索结果与当前上下文融合。

10.3 S 组件（状态存储）——MemGPT

MemGPT: Towards LLMs as Operating Systems（Packer et al., NeurIPS 2023）

MemGPT 把操作系统的内存管理理念引入 LLM：
- 工作记忆（上下文窗口）= RAM
- 外部存储（向量数据库、文件）= 硬盘
- 分页机制：自动把"不常用但重要"的记忆"换出"到外部存储，需要时"换入"

Harness 连接：MemGPT 专注于 C + S 两个组件的深度实现，是理解这两个组件的最佳参考论文。但注意：MemGPT 本身不是完整 Harness（缺少 E/T/L/V），它是"能力模块"类别。

10.4 E+S 组件——Voyager（开放式技能积累）

Voyager: An Open-Ended Embodied Agent with Large Language Models（Wang et al., 2023）

Voyager 在 Minecraft 里不断探索、学习新技能、并把技能代码存储起来供后续使用。

Harness 连接：
- E 组件：每次探索的执行循环（看到新资源→想想能做什么→尝试行动）
- S 组件：把成功的技能代码存入"技能库"（程序式记忆）
- T 组件：技能库本身就是一个"工具注册表"——积累的技能就是新工具

Voyager 展示了一个令人兴奋的可能性：Agent 可以通过执行来拓展自己的工具库。

10.5 S 组件——Reflexion（从失败中学习）

Reflexion: Language Agents with Verbal Reinforcement Learning（Shinn et al., NeurIPS 2023）

Reflexion 让 Agent 在任务失败后，用自然语言写下"反思日记"，存储为长期记忆，下次遇到类似情况时先读一遍，避免同类错误。

Harness 连接：这是 S 组件的一种有趣实现——把"失败经验"作为状态持久化下来。与 Voyager 的"成功技能存储"互补，两者共同说明了 S 组件对 Agent 长期学习的重要性。

10.6 C+S 组件——Generative Agents（社会仿真中的记忆）

Generative Agents: Interactive Simulacra of Human Behavior（Park et al., UIST 2023）

25 个有个性的虚拟人，每人都有记忆流（Memory Stream）、反思能力、规划能力。记忆流记录每次经历，通过"重要性+最近性+相关性"三维打分来决定哪些记忆被检索出来使用。

Harness 连接：Generative Agents 的记忆流是情节式记忆（按时间记录事件）的典型实现，属于 S 组件的高级形态，同时也深度影响 C 组件（上下文中放什么记忆）。

10.7 知识网络全图

ReAct ──────────────────────→ E（执行循环的思考-行动模式）
Lost in the Middle ──────────→ C（上下文利用的位置偏差）
RAG ─────────────────────────→ C（按需检索注入上下文）
MemGPT ──────────────────────→ C + S（上下文管理 + 长期记忆）
Voyager ─────────────────────→ E + S + T（探索执行 + 技能存储 + 技能即工具）
Reflexion ───────────────────→ S（失败经验持久化）
Generative Agents ───────────→ S + C（情节记忆流 + 记忆检索）
                                         ↓
                            Agent Harness H=(E,T,C,S,L,V)
                            把这些零散研究统一在同一框架下

重要启示：这些经典论文都在研究 Harness 的某个组件，但各自"解决一个局部问题"。Agent Harness 综述的贡献，正是把这些碎片化研究统一在一个框架下，揭示了为什么"零件都有了，但整体仍然不可靠"的根本原因——组件的组合涌现出新的故障模式，需要整体化的 Harness 设计视角。

十一、写作风格与图表亮点

11.1 写作风格特点

本综述有几个鲜明的写作特点：

1. 学术与工业并重：既引用同行评审论文，也引用 Stripe、OpenAI、Cursor、METR 的工程博客和报告。这是大多数学术综述不会做的，但恰恰捕捉了 2025-2026 年 Agent 工程爆发的时代精神。

2. 挑战假设：开篇即"挑战主流叙事"，这在综述论文中比较少见，通常综述是总结现状而非提出争议性观点。

3. 数据驱动：每个论点都有具体的数字支撑（6.7% → 68.3%，28% 假阴性率，24.2 个百分点差距），不空谈原则。

4. 明确识别空白：清楚指出哪些挑战"当前仅有部分解决方案，缺乏生产级基础设施"，而不是过度美化现有工作。

11.2 图表亮点

Harness 完备性矩阵（最核心的图表）

这张 23×6 的表格是本论文最重要的方法论贡献。它使得原本无法直接对比的异构系统（游戏 Agent vs. 代码 Agent vs. 多 Agent 框架）可以在同一维度上比较：

• 看一眼就能知道某个系统"哪里缺"
• 一目了然地解释为什么某些系统生产可靠性高，某些仅适合原型研究
• 为"选择 Agent 框架"提供了决策矩阵

历史时间线图

从 JUnit（1999）到 2026 年，跨越 27 年，展示了 Harness 概念从"测试脚手架"到"智能体核心架构"的演化路径。帮助读者理解这个概念的深厚技术渊源，而不是突然从天而降的新词。

十二、新手阅读建议与对 Agent 工程师的价值

12.1 新手阅读建议

如果你是 AI 学习新手，建议路径：

1. 先读本精读：建立整体框架，特别是六元组概念
2. 再读 ReAct 原论文：理解执行循环的思想来源
3. 再读 MemGPT 原论文：理解上下文管理和状态存储的深度设计
4. 跟踪 SWE-bench 排行榜：实时感受 Harness 设计对 Agent 能力的影响
5. 尝试使用 OpenHands 或 Claude Code：亲身体验一个完整的 Agent Harness 是什么感觉

关于这篇论文的局限性（应知道的诚实评价）：

• 这是预印本，尚未经同行评审，部分数据和论点可能在正式发表时调整
• 部分引用的工作（标注 †）也是预印本，需要持续关注同行评审结果
• 综述覆盖到 2026 年 Q1，Agent 领域迭代极快，六个月后可能有重要新进展
• "Harness 比模型更重要"的论点在某些任务上非常成立，但并非对所有任务成立；两者是相辅相成的

12.2 对"想做 Agent 工程"的人的实用价值

这篇综述对工程实践者的价值，体现在五个维度：

1. 选型决策

用 Harness 完备性矩阵来选择框架：
- 需要生产可靠性？→ 选全栈式（Claude Code, OpenHands）
- 需要快速原型？→ LangChain/LangGraph 够用，但别指望它处理生产事故
- 需要评估基础设施？→ HAL 或 BrowserGym

2. 故障诊断

Agent 出问题时，按六元组排查：
- 无限循环 → E 组件（终止条件设计有问题）
- 工具调用失败后崩溃 → E 组件（缺少错误恢复）
- 上下文窗口溢出 → C 组件
- 程序崩溃无法续上 → S 组件
- 执行了危险操作 → L 组件
- 不知道 Agent 哪里出了问题 → V 组件

3. 工具数量控制

Vercel 案例的教训：不要把所有可能用到的工具都给 Agent。从最少的工具集开始，按需增加。每增加一个工具，要测试它是否真的提升了任务成功率。

4. 评估方法

不要只看基准分数。METR 的案例说明：
- 建立自己领域的评估数据集
- 人工抽样验证，不要完全依赖自动评估
- 跟踪评估的假阴性率和假阳性率

5. 安全优先

在设计 Harness 时，L 组件（生命周期钩子）要最先设计：
- 明确 Agent 不能做什么（白名单 or 黑名单）
- 每次高风险操作前要有审查钩子
- 沙箱隔离是必须的，不是可选的（记住：15-35% 的容器逃逸率）

十三、总结：这篇综述为什么重要

本综述在 Agent 研究史上的意义，可以用一句话概括：

它第一次把工程界早已知道但学术界系统忽视的东西——"执行外壳比模型更重要"——用严格的框架和大量实证证据，升格为一级学术研究命题。

就像 1999 年 Martin Fowler 写《重构》，把程序员凭直觉做的"代码整理"提炼为系统的工程学一样；这篇综述把 Agent 工程师凭直觉搭建的"周边基础设施"，提炼为有名称、有边界、可测量的六元组架构，让整个领域可以在同一语言体系下讨论、比较和改进。

对于正在学习 LLM 和 Agent 技术的你：

• 了解 Harness 概念，就是了解"为什么很多 demo 看起来很好，但真正部署后问题百出"的根本原因
• 理解六元组，就是掌握了评估和改进任何 Agent 系统的分析框架
• 知道这九大挑战，就是知道了这个领域未来五年最值得投入研究的方向

本精读文档依据官方中文 README（v3，2026年4月）撰写，数字与事实以官方文档为准。

撰写时间：2026年5月