为什么 AI Agent 一到长任务就掉链子

单步测出来会做事，不等于连续做十几步、几十步还不失手。把成功率按步骤连乘，很多看起来很聪明的系统会在闭环里迅速蒸发。

公开基准已经把这件事说得很直白：WebArena 里最好的 GPT-4 基础代理只做到 14.41%，人类是 78.24%；OSWorld 里最好的模型只做到 12.24%，人类超过 72.36%；Anthropic 公开写到，Claude computer use 在 OSWorld 上是 14.9%，但它仍然「slow and often error-prone」。123

如果把任务想成一串连续动作，难点就会变成「每一步都不出错」；这种要求会把微小优势一点点吃掉。

长任务的麻烦在于，结果不是一次性吐出来，而是要在环境里不断接收反馈、修正状态、记住上下文、处理工具输出，再继续往下走。每一步都可能出错，出错之后还未必能回滚。

这也是为什么「能答对一道题」和「能把一件事做完」之间，会隔着一条很宽的沟。前者看的是局部判断，后者看的是闭环稳定性。只要中间有 20 步，每步哪怕 95% 成功，整条路径的成功率也会掉到约 36%；如果每步只有 90%，整条路径就只剩约 12% 左右。这个算术很残酷，但它并不夸张。

WebArena 就是按这个方向设计的。论文把任务放进真实且可复现的网页环境里，覆盖电商、论坛、协作开发和内容管理四类站点，任务本身还强调长跨度和功能正确性。结果里，最好的 GPT-4 基础代理也只有 14.41% 的端到端成功率，而人类是 78.24%。这不是「差一点」；这是两个数量级不同的世界。1

OSWorld 把场景推进到真实电脑环境，任务不再只是网页点击，还包括桌面应用、文件 I/O 和跨应用工作流。论文里最好的模型只有 12.24%，人类超过 72.36%，作者直接把主要问题归到 GUI grounding 和 operational knowledge，也就是界面定位与操作经验。2

Mind2Web 更早就把这个方向铺开了。它收集了 2000 多个开放式任务，来自 137 个网站、31 个领域，并强调真实网页、真实交互模式和跨网站泛化。作者还特意提到，原始 HTML 太大时，先用小模型过滤再交给 LLM，效果会更好；但他们也承认，离真正可泛化的 web agent 还有很大距离。4

另一个更新的信号来自 Online-Mind2Web。那篇 2025 年的工作说得更直接：以前的 benchmark 给出的进展有「illusion of progress」，原因是测试条件本身不够像真实用户使用 agent 的方式。于是他们做了 300 个任务、136 个网站的在线评估，并把自动评估器做到了大约 85% 的人类判断一致度。5

AgentBench 的摘要把主要障碍列得很清楚：poor long-term reasoning、decision-making 和 instruction following。它评估了 8 个不同环境，结论是商业模型和不少开源模型之间确实拉开了差距，但真正卡住 usable agents 的，还是长程推理、决策和指令遵循这些执行性能力。6

更近的一篇工作把这个判断再往前推了一步。Sinha 等人在《The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs》里主张，很多长任务失败并不是因为模型不会推理，而是因为执行出错；当任务被拉长时，per-step accuracy 会下降，而且一旦前面的错误进入上下文，后面的步骤会更容易继续犯错。作者把这个现象叫作 self-conditioning。7

这类结果很重要，因为它把失败拆成了两层。第一层是「知道该怎么做」；第二层是「在真实环境里把它做完」。很多模型在第一层已经不算差，第二层却还是脆得厉害。更麻烦的是，第二层的错误会反过来污染第一层：一旦上下文里出现自己刚刚造成的偏差，后续判断就更容易沿着错误轨道滑下去。7

这也是为什么 Anthropic 在讲 computer use 时会特别强调，Claude 依然 slow and often error-prone，而且会漏掉短暂出现的动作和通知。它把屏幕理解成一帧一帧的截图，而不是连续的视频流；这意味着只要变化太快，模型就可能错过。3

自制概念图：前几步还对齐，后面开始偏移。

OpenAI 的 Operator system card 也把同一件事说得很明确。报告把「model mistakes」列为核心风险之一，说明了 confirmation prompts、watch mode 和 proactive refusals 这些缓解手段；它还写到，错误可能很难逆转，某些网站会通过 prompt injection 把模型带偏。换句话说，产品侧从一开始就默认 agent 会犯错，只是要把错误限制在可控范围内。8

表面上看，工具越多，agent 越强。实际上，工具越多，状态也越多，出错的边界就越大。

网页任务里，agent 不只是在「思考」，还要判断当前页面是哪一步、之前是否已经提交过、哪些输入已经写入、哪些按钮已经点过、页面是否被刷新、是否弹出确认框。只要有一项记错，后面的动作就可能建立在假状态上。真实世界里，这种误差很少是平滑退化，更多时候是突然掉线。

OpenAI 和 Anthropic 的官方材料都在反复强调这个问题：一边是网页可能带有恶意指令，另一边是模型会漏看短暂变化、会误读 OCR、会在拖拽和缩放上出错。Anthropic 甚至明确说，Claude 的 computer use 还是慢，而且常常出错；OpenAI 则把 confirmations 和 watch mode 直接做进了安全设计。38

自制概念图：一个早期偏差把后面的路径带歪。

这类问题很难靠一句「再想一遍」解决。原因很简单：长任务里最贵的不是思考本身，而是恢复真实状态的成本。一个按钮点错了，也许只是多走一步；一个订单提交错了、一个邮件发错了、一个文件删错了，就不是多想一次能补回来的。

从这些论文和官方系统卡里，能看出几种稳定有效的思路。

第一，别把一个大任务直接丢给单次闭环。任务越长，越该被切成可验证的小段。每段都要有清楚的输入、输出和验收点，而不是让模型在一条很长的链里靠记忆硬撑。

第二，把状态外置。只靠上下文窗口记住一切，最后通常会把自己拖进细小但致命的偏移。外部笔记、明确的中间结果、可回读的检查点，比让模型自我回忆可靠得多。2026 年那篇 long-horizon execution 论文提到，thinking 能缓解 self-conditioning，也能让模型在单次里执行更长的任务；这说明 test-time compute 不是装饰品，而是实打实的执行资源。7

第三，把不可逆动作放在确认之后。OpenAI 的 Operator system card 之所以把 confirmation prompts 和 watch mode 写进去，就是因为这类动作一旦错了，代价不是「模型评分低一点」，而是用户真实世界里的损失。8

第四，别把 demo 当稳定性证据。WebArena、OSWorld、Mind2Web 和 Online-Mind2Web 这些工作放在一起看，最一致的信号不是「agent 已经能独立工作」，而是「agent 在真实闭环里还很脆」。同样的模型，在短输入、局部判断、静态测试里看起来越来越强；一进长任务，就开始暴露执行层的脆弱。1245

长任务里，agent 的可靠性不是看它会不会在第一步说出正确答案，而是看它能不能在一串微小决策里一直守住状态。

如果闭环够短，模型看起来像一个很会干活的助手；如果闭环变长，它就更像一台会犯错、会漂移、会被环境反向塑形的机器。公开 benchmark 和官方系统卡给出的信号已经很一致：现在最该追的是执行稳定性，少漏看、少错点、少把前一步的偏差带到后一步。