Agent 做长任务为什么会崩：从时间跨度到失败归因

这篇是对一组 Agent 长任务论文和 benchmark 的消化笔记，主要包括：

• Voyager
• Measuring AI Ability to Complete Long Tasks
• TheAgentCompany
• SWE-Bench Pro
• WildClawBench
• Odysseys
• The Long-Horizon Task Mirage?

我读完后的核心判断是：长任务不是短任务重复很多次。

短任务失败，通常是某一步做错。长任务失败，常常是系统状态慢慢偏掉：早期一个小误解没有被纠正，后续步骤都建立在错误前提上，最后 agent 看起来忙了很久，但产物已经偏离目标。

所以评估长任务 Agent，不能只看最后成功率。还要看：

任务到底有多长
中间检查点完成了多少
用了多少步和多少钱
失败发生在哪个阶段
错误有没有被发现和恢复
工具脚手架是否拖累了能力

1. Voyager 说明长任务需要沉淀技能

Voyager 是早期很重要的长任务 Agent 论文。它让 GPT-4 在 Minecraft 里持续探索，目标不是完成一个固定任务，而是不断发现新物品、学习新技能、解锁 tech tree。

它的架构有三件事：

automatic curriculum: 自动提出下一个探索目标
skill library: 把成功代码保存成可复用技能
iterative prompting: 根据环境反馈和执行错误迭代修正

这篇的关键不在 Minecraft，而在“长任务如何积累能力”。

如果每次都从零开始规划，agent 很快会卡在重复劳动里。Voyager 把成功经验沉淀成 executable skill，下次遇到类似目标时可以检索和复用。它不是靠更长 prompt 走得更远，而是靠“把过去成功的行动变成工具”。

这对所有长任务 Agent 都有启发：

计划只能让 agent 往前走一步
技能库才能让 agent 不必每次从第一步开始

2. METR 把“长”变成可度量指标

Measuring AI Ability to Complete Long Tasks 提出一个很有用的概念：task-completion time horizon。

直觉上，它问的是：

一个 AI agent 能以某个成功率，完成需要人类专家花多长时间的任务？

论文重点使用 50% time horizon，也就是模型能以 50% 成功率完成的人类耗时任务长度。它不是按 token 数、工具调用数或 step 数定义长短，而是用“人类完成这个任务通常要多久”来标定任务跨度。

这比“最多跑 100 步”更贴近现实。因为不同领域的一步含义差异很大。一次 shell 命令、一次浏览器点击、一次代码 patch、一次数据库迁移计划，不能直接等价。

论文估计 2019 到 2025 年 frontier agent 的 time horizon 呈指数增长，近期模型已经能覆盖小时级别的一部分软件任务。但这不等于“长任务解决了”。作者也强调，time horizon 始终依赖任务分布、领域和成功率阈值。

我对这篇的 takeaway 是：

长任务能力应该画成曲线，而不是报一个单点分数。

一个模型在 10 分钟任务上 80% 成功，在 2 小时任务上 30% 成功，这比“总体成功率 55%”有用得多。

3. TheAgentCompany 把任务放回工作环境

TheAgentCompany 很适合理解“真实工作为什么难”。它搭了一个模拟软件公司环境，让 agent 使用浏览器、终端、代码仓库、内部网站、文件系统和模拟同事沟通。

任务不是单一网页点击，而是类似公司里的真实工作：

查内部资料
联系同事
处理表格
改代码
整理报告
在多个系统之间搬运信息

论文里最强 baseline Gemini 2.5 Pro 完整完成约 30.3% 的任务，按部分完成计分约 39.3%。这已经不是“模型不会说话”或“模型不会写代码”的问题，而是工作流整体还不稳。

它暴露了几个很实际的失败点：

• agent 不会自然地继续社交沟通。
• 专业 Web UI 的小弹窗、小按钮、小流程会卡住 agent。
• 看似简单的行政和财务任务，对模型反而很难。
• 软件工程任务因为训练和 benchmark 更集中，反而相对表现更好。

这篇提醒我：真实长任务不是只有“推理难”，还有“操作难、沟通难、界面难、流程难”。

4. SWE-Bench Pro 把代码任务推向专业工程

如果说 SWE-bench 把代码评测从刷题推向真实 issue，那么 SWE-Bench Pro 是继续加压：更复杂、更长周期、更接近专业软件工程。

它构造了 1865 个经过人工验证和增强的问题，分为 public、held-out、commercial 三类。任务来自 11 个公开仓库、12 个保留仓库和 18 个商业仓库。论文强调这些任务可能需要专业工程师数小时到数天。

它和普通代码 benchmark 的差别在于：

不是补一个函数
不是只改一两行
不是天然有完整 issue 描述
不是只面对公开训练中常见仓库

论文报告 public set 上顶级模型低于 45% Pass@1，commercial set 上最佳模型低于 20%。这说明当任务走向企业代码库、复杂需求和多文件修改时，当前 coding agent 仍然很不稳定。

更有价值的是失败归因。论文把失败分成错解、工具误用、语法错误、找错文件、无限读文件、误解问题、上下文溢出等。

这类失败听起来琐碎，但正是长任务的核心：agent 不是不会生成代码，而是经常不能稳定地完成“定位、理解、修改、验证、收敛”整条链路。

5. Odysseys 说明 Web 长任务不能只看 pass/fail

Odysseys 关注真实 Web 长任务。它构造了 200 个多站点任务，来自真实浏览行为，每个任务平均有 6.1 个 rubric。

这篇最重要的贡献不是又做了一个榜单，而是把评价从单一 pass/fail 改成 rubric-based evaluation。

原因很简单：长任务里“部分成功”很常见。

一个 agent 可能查对了 6 个信息中的 5 个，但没有生成最终文档。另一个 agent 可能最后写了文档，但里面关键字段错了。只用 pass/fail 会丢掉大量诊断信息。

论文里最佳模型 Claude Opus 4.6 在 100 步预算下 perfect task success 约 44.5%。当步数放宽到 200，perfect rate 可以提升到 76.5%，但仍有约 14% 的任务即使用乐观假设也不是单纯加步数能解决。

这很关键：

有些失败是预算不够
有些失败是能力结构不对

Odysseys 还提出 Trajectory Efficiency，用 rubric score 除以 step count。这个指标提醒我们：长任务 agent 不能只是“最后终于做完”，还要看是不是高效完成。

6. WildClawBench 把脚手架也纳入评估对象

WildClawBench 更贴近 CLI agent 的真实运行方式。它有 60 个任务，放在 Docker 容器中，使用真实 CLI agent harness，例如 OpenClaw、Claude Code、Codex、Hermes Agent，并提供 shell、浏览器、文件系统、邮件等真实工具。

论文报告任务平均约 8.5 分钟、26 次工具调用。OpenClaw 下最强模型 Claude Opus 4.7 总分约 62.2%，其他模型低于 60%。更有意思的是，同一个模型换 harness，分数可以明显变化，最大可有 18 分差异。

这说明一件经常被忽略的事：

Agent 能力 = 模型能力 + harness 能力 + 工具设计 + 控制循环 + 预算策略

把模型接进不同的脚手架，不是换了一个外壳那么简单。工具 schema、观察格式、上下文管理、循环控制、错误恢复，都会改变最终能力。

所以评估 agent 时，不应该只写“某模型得分多少”。更准确的说法是“某模型在某个 harness、某组工具、某个预算和某套评分器下得分多少”。

7. HORIZON 把失败机制讲清楚

The Long-Horizon Task Mirage? 试图回答更底层的问题：长任务到底在哪里坏掉。

它构造 HORIZON 诊断框架，收集 3100+ 条轨迹，覆盖 Web、OS、Embodied、Database 四类领域，并用 trajectory-grounded LLM-as-a-Judge 做失败归因。

论文提出的关键观点是：长任务失败不是成功率慢慢线性下降，而是会进入一个“断裂区”。任务深度增加后，失败结构会变化，planning、memory、history error accumulation 变得越来越主导。

它的失败分类很适合拿来做工程排查：

环境检测失败：没看懂当前环境状态
指令理解失败：漏掉约束或误解目标
规划错误：子目标拆错或顺序错
历史错误累积：早期小错被后续步骤反复使用
记忆限制：上下文装不下或取不回关键信息
灾难性遗忘：前面明确知道的约束后来不再遵守
错误假设：基于未经验证的前提持续行动

这比“模型不够聪明”更有用。因为每种失败对应不同修法。

规划错，需要更好的任务分解和检查点。记忆限制，需要状态账本和外部记忆。历史错误累积，需要阶段性验证和回滚。错误假设，需要显式证据检查。环境检测失败，需要更可靠的观察和工具反馈。

8. 长任务 Agent 的工程原则

读完这些论文后，我会用下面几条原则设计长任务 Agent。

第一，必须有阶段性 checkpoint。

不要让 agent 跑 100 步后才知道失败。长任务应该拆成可验证的中间产物，每个阶段都有明确通过条件。

第二，必须维护状态账本。

长任务里最危险的是“以为自己记得”。Agent 应该显式记录：

目标是什么
已完成什么
证据在哪里
未解决什么
哪些假设尚未验证
下一步依赖哪个前提

第三，计划要可回滚。

计划不是写一次就固定。每个阶段结束后，都应该重新检查目标、环境和中间产物。如果发现前提错了，要能回退，而不是继续沿着错路加速。

第四，评估要看轨迹。

最终答案只能说明有没有成。轨迹才能说明为什么成、为什么败、失败是否可恢复、agent 是否在浪费步数。

第五，工具脚手架要当成产品能力。

不要把 harness 当成透明壳。观察格式、编辑工具、浏览器控制、命令输出截断、文件搜索、测试运行器，都会直接影响长任务成功率。

第六，成功率要和效率一起看。

一个 agent 200 步完成任务，另一个 40 步完成任务，用户体验和成本完全不同。长任务尤其需要报告 step、wall-clock time、token、cost 和 partial score。

9. 我的 takeaway

长任务 Agent 不是“更强模型 + 更多上下文 + 更多步数”就能自然解决。

Voyager 告诉我们，长期探索需要技能沉淀。METR 告诉我们，长任务能力应该用时间跨度曲线衡量。TheAgentCompany 和 SWE-Bench Pro 告诉我们，真实工作和专业工程会暴露工具、沟通、环境和验证问题。Odysseys 和 WildClawBench 告诉我们，评价必须细到 rubric、效率和 harness。HORIZON 则把失败从“没做完”拆成可诊断的机制。

所以我会用一句话总结：

长任务的难点不是走很多步，而是在很多步之后仍然知道自己在哪里、为什么在这里、下一步依赖什么。

真正可靠的长任务 Agent，需要的不只是会推理，还要会记账、会检查、会回滚、会利用技能、会承认不确定，并且在工具环境里稳定执行。

自检

读完这篇，可以用三个问题检查自己是否真的理解了：

1. 为什么 task-completion time horizon 比单纯 step count 更适合描述长任务能力？
2. Odysseys 为什么要用 rubric-based evaluation，而不是只用 pass/fail？
3. HORIZON 里的“历史错误累积”和“记忆限制”有什么区别？