Rohan Paul 谈用时间跨度衡量智能体能力，并引用 OpenAI 自动化研究实习生里程碑

Rohan Paul 谈用时间跨度衡量智能体能力，并引用 OpenAI 自动化研究实习生里程碑

为什么时间跨度比 benchmark 更接近真实能力

SWE-bench、HumanEval 这类基准题的共同特征：任务范围在几十分钟到几小时内可完成，状态空间有限，验证函数明确。模型在这些题目上拿高分，只能证明它在「局部可见、短期反馈」场景下可靠。但真实工程里，一个持续运行 64 小时的研究任务，需要模型在数十次工具调用、多次环境变化、若干中间失败后仍然回到正确轨道。这已经不是单步推理问题，而是轨迹可靠性问题。

Agent 运行时过载

时间跨度 vs 成功率衰减曲线（示意）

OpenAI 工程师 Rohan Paul 最近在 X 上分享的内部数据给出了直观的刻度：15 分钟以内的任务，无干预成功率 86%；而拉到 64-128 小时档位，成功率只剩约 16%。同一个模型，能力没有变，变的只是任务跨越的时间尺度。这也解释了为什么「模型在 benchmark 上很强，上线后长任务总出问题」------因为 benchmark 测的是局部能力，长任务测的是轨迹稳定性。

OpenAI 数据的含义：成功率随任务时长呈指数塌陷

METR 在 2026 年 2 月发表的论文《Measuring AI Ability to Complete Long Software Tasks》提出了一个可量化的指标：50%-task-completion time horizon，即 AI 能以 50% 成功率完成任务时对应的「人类通常需要多久完成该任务」。该研究显示，当前前沿模型的 50% 任务完成时间跨度约为 50 分钟，且近六年大约每七个月翻倍。这个趋势主要来自于可靠性提升和错误恢复能力的增强，而非单次推理质量的跃迁。

OpenAI 内部数据与 METR 结论互相印证：智能体能力的真正瓶颈不在单次生成的质量，而在长时间执行中积累的状态漂移。每一次工具调用、每一个环境变量的变化、每一轮对话历史的累积，都在增加「下一步出错」的概率。这就是所谓的 error compounding（误差累积）------单次错误的概率不大，但经过 N 步放大后，系统整体崩溃概率接近必然。

长 horizon agent 的三类崩溃机制

面试官：为什么你的 agent 跑到第 37 步就崩了？

从工程视角，长任务成功率崩塌可以归到三类机制：

第一类是状态漂移。agent 在运行过程中维护的内部状态（变量、文件、环境变量、数据库记录）会随时间发生变化，而模型无法感知这些变化。当第 50 步的决策依赖第 3 步建立的状态，而该状态已被后续操作覆盖，模型就会基于过时信息做出错误选择。

第二类是错误传播。单步出错后，如果没有有效的回滚或修复机制，错误会被后续步骤放大。一个典型的例子：agent 在第 10 步写入了错误配置，第 20 步基于该配置启动服务，第 30 步检测到服务异常后尝试修复，但修复逻辑本身也依赖了已被污染的配置上下文，最终陷入死循环。

第三类是上下文窗口压力。随着任务延长，历史对话、工具输出、日志碎片不断累积，当上下文接近模型窗口上限时，模型会开始「遗忘」早期关键信息。这不是能力退化，而是输入被截断导致的语义丢失。

长 horizon agent 崩溃机制

系统架构怎么缓解：门禁、回放与状态归因

针对这三类机制，成熟的 agent 系统通常引入三层架构级补偿：

首先是执行门禁（execution guardrails）。在每个关键步骤前后插入校验节点，例如：每次文件写入后执行 diff 校验、每次服务重启后执行 health check、每个子任务完成后执行断言验证。这相当于在长轨迹上设置检查点，将「一路跑到崩溃」改为「每段跑完确认再通过」。

其次是状态快照与回放（snapshot and replay）。系统在关键节点保存完整状态快照，当后续步骤失败时，不是从错误点继续尝试修复，而是回退到最近的健康快照后重新规划。这解决了错误传播问题，代价是需要额外的存储和回溯开销。

最后是状态归因（state attribution）。通过结构化日志和依赖追踪，将每一步决策的输入状态显式记录，当出现异常时能快速定位是哪个早期状态发生了变化导致当前错误。这解决了状态漂移的根因诊断问题。

这套架构设计能过评审

OpenAI 内部发布的 RSI（Research Superworker Intern）里程碑正是这套思路的产物：一个人类监督的系统能够完成原本需要研究人员数天才能完成的明确任务。关键在于「监督」------系统不是完全自主运行，而是在关键节点接受人类确认，从而将长任务的失败率约束在可控范围内。

工程落地的取舍边界

在以下条件下，值得投入架构建设：

• 任务时间跨度超过 4 小时，或
• 任务涉及多步工具调用（>20 步），或
• 单次失败成本较高（如生产环境变更）

在以下条件下，采用简化方案即可：

• 任务时间跨度小于 30 分钟，或
• 失败可快速重试且无副作用，或
• 验证逻辑足够简单（单步校验即可） 时间跨度作为智能体能力的衡量指标，核心意义在于它迫使团队从「模型单步推理质量」转向「系统级轨迹可靠性」思考。benchmark 分数可以继续刷，但时间跨度的提升需要扎实的架构投入。这也是为什么 Rohan Paul 认为，未来讨论智能体能力时，时间跨度会比 token 数和 benchmark 排名更有区分度。

可执行建议：如果你的 agent 项目即将进入长任务场景（>1小时），今天就做三件事------接入执行门禁、实现关键节点快照、建立失败归因日志。这三项投入不会立刻提升 benchmark 分数，但会在你的 agent 从 15 分钟任务迁移到 4 小时任务时，决定它是崩溃还是稳定运行。

Agent 长时间运行时频繁出错

Rohan Paul 谈用时间跨度衡量智能体能力

数据切入：OpenAI 的长任务成功率塌陷

Rohan Paul 在 X 上转发的 OpenAI 内部数据显示了一个清晰的趋势：随着任务时长增加，智能体无人类干预的成功率快速下滑。

sub-15 分钟任务的成功率约为 86%。这是当前大模型工具调用能力的上限区间。当任务延长到 64-128 小时区间时，成功率跌至约 16%。

这一数据与 METR 去年发表的《Measuring AI Ability to Complete Long Software Tasks》论文结论相互印证。该论文提出了「50%-task-completion time horizon」指标，即智能体以 50% 成功率完成任务时对应的典型人类完成时长。当前前沿模型在该指标上约 50 分钟，且自 2019 年以来每约七个月翻倍。

benchmark 分数无法解释这个衰减曲线。一个在 HumanEval 上达到 90 分以上的模型，在执行跨天的代码重构任务时仍可能失败。问题不在于模型不够聪明，而在于执行轨迹的长度放大了任何环节的微小失误。

机制拆解：为什么时间跨度比 benchmark 更接近真实能力

系统需要分层治理错误累积

长任务的崩溃可以归纳为三类机制：

第一类：错误累积。每次工具调用都存在约 1-5% 的失败概率。假设一个任务需要连续执行 20 步，每步成功率 95%，整体成功率是 0.95 的 20 次方，约 35.8%。一旦某步失败触发错误恢复机制，而恢复策略本身有 30% 的成功率，整体链路将进一步恶化。

第二类：状态漂移。长任务执行过程中，环境状态持续变化。文件系统、数据库、API 依赖项都可能被其他进程修改。智能体基于初始状态制定的计划在执行中途可能已经失效，但模型缺乏感知这种漂移的机制。

第三类：上下文溢出。当前主流模型的上下文窗口虽然达到 20 万 token，但长任务执行日志会快速消耗这个预算。当上下文接近上限时，模型被迫丢弃早期规划信息，导致行为偏离初始意图。

这三类机制的叠加效应是非线性的。单个机制可能可控，但当它们同时作用时，系统会在某个临界点突然崩溃，表现为任务执行到一半时无故卡住或输出不相关结果。

长任务失败机制叠加效应

找到崩溃的根本原因才能修复

系统架构：三门设计

工程上缓解长任务失败的路径不是提升单步准确率，而是构建三层门禁系统。

第一门：计划确认。在执行任何工具调用之前，要求模型输出可验证的执行计划。计划必须包含预期输入、预期输出、失败回滚路径。这一步的过滤成本很低，但能拦截大量基于错误假设的后续执行。

第二门：中间校验。每完成一个子任务，对产出进行结构化校验。校验规则可以是静态的（如 JSON Schema 验证）或动态的（如运行最小化测试用例）。通过校验才能进入下一步，未通过则触发修复循环。

第三门：状态归因。当任务失败时，系统需要区分三种失败类型：是初始计划错误、中间执行错误、还是环境变化导致的无效执行。不同错误类型对应不同修复策略，错误归因不准确会导致修复循环陷入死胡同。

Agent 门禁系统状态流转

工程落地的取舍边界

先确认自己的任务边界再动手

三门设计并非万能。工程实践中需要在三个维度做取舍。

延迟与准确率的权衡。每增加一道校验门，任务执行延迟增加约 20-50%。对于实时性要求高的场景（如客服对话、交易处理），过度校验会导致用户体验下降。建议在关键路径上只保留状态归因门，对非关键路径增加计划确认和中间校验。

人工介入的成本。OpenAI 的数据显示，成功执行长任务的运行中，人工介入频率远高于短任务。当任务超过 4 小时时，几乎每步都需要人类确认。工程落地时需要明确哪些环节必须由人类介入，哪些可以通过自动化修复替代。

错误容忍度的业务边界。金融、医疗等高风险场景要求接近零错误容忍，门禁系统必须接近完整；内部工具或实验性项目可以接受较高失败率，通过快速迭代替代严格校验。

当前行业的一个共识是：时间跨度指标将在未来 12-18 个月内成为评估智能体能力的核心指标之一。benchmark 分数仍然重要，但不再足够。工程团队需要从现在开始构建长任务执行的基础设施，而不是等到 benchmark 天花板出现后再补课。

评审时最容易发现遗漏的边界条件

三类崩溃机制：为什么长任务必然失败

OpenAI 的数据揭示了一个残酷事实：任务时间越长，无干预成功率越低。这背后有三类典型的崩溃机制，理解它们比调参更重要。

类型错误累积：局部正确不等于全局正确

每修一个 bug 冒出两个新 bug

单个 LLM 调用在短上下文中准确率可达 90% 以上，但当 10 个调用串联时，整体成功率降至 35%。这不是线性衰减，而是指数塌陷。关键原因在于「类型错误」------模型输出的字段类型、格式规范出现细微偏差，下游环节无法解析，但错误被静默传播，直到最终结果完全偏离预期。

这类错误的隐蔽性极强。开发者测试单步调用时一切正常，只有端到端跑完整流程才会暴露。Rohan Paul 提到的「模型局部能力强但长轨迹不可靠」，本质上就是类型错误的累积效应。

状态漂移：上下文窗口之外的信息丢失

系统架构的生死线

当任务跨越多小时，中间产物不断膨胀，上下文窗口成为硬约束。即使使用 RAG 或外部存储，检索的准确性也会随时间衰减。更致命的是，LLM 的注意力机制对早期信息的权重天然低于近期信息，导致「遗忘」------这不是 bug，是架构特性。

解决方案不是无限扩大上下文，而是建立显式状态管理：将关键中间结果序列化存储，在需要时精确召回，而非依赖模型的隐式记忆。

工具调用链断裂：外部依赖的不可控性

等接口超时等到天荒地老

长 horizon agent 往往需要调用多个外部工具：数据库、API、文件系统。任何一个依赖失效都会导致链路中断。更复杂的是，工具返回的错误信息可能不符合预期格式，需要额外处理。

OpenAI 的 RSI（Research Software Intern）项目能够跨越人类工作日，核心突破之一就是建立了工具调用的容错机制：超时重试、降级策略、错误恢复。这些机制不是锦上添花，而是长任务的基础设施。

长 Horizon Agent 崩溃机制因果图

系统架构：门禁、回放与状态归因

理解崩溃机制后，需要相应的架构来应对。主流方案围绕三个核心：门禁、回放、状态归因。

事前门禁：防止错误扩散

架构师点头认可

门禁机制的核心思想是：在关键节点设置检查点，确保输出符合预期后再继续。这与软件测试中的「防御式编程」一脉相承。

具体实现包括：

• 类型校验：使用 JSON Schema 或 Pydantic 验证模型输出
• 内容检查：对关键信息进行事实核查或逻辑校验
• 资源预算：监控 token 消耗、调用次数、执行时间，超限则提前终止

OpenAI 内部的做法是在每个子任务完成后插入验证步骤，只有通过的产物才进入下一阶段。这种做法增加了单次执行时间，但大幅降低了端到端失败率。

事中回放：快速定位故障点

查 bug 查到怀疑人生

长任务失败时，最耗时的是定位故障点。回放机制通过记录完整的执行轨迹，允许开发者在失败时「倒带」，逐步骤检查。

关键设计要素：

• 结构化日志：每次 LLM 调用、工具调用的输入输出都持久化存储
• Trace ID：为每个任务分配唯一标识，串联所有子操作
• 时间戳对齐：精确记录每个步骤的开始结束时间，便于分析性能瓶颈

这种能力在调试阶段价值巨大。没有回放，长任务调试只能靠猜；有了回放，可以快速定位是模型幻觉、工具超时还是状态管理问题。

事后归因：建立因果链

找到根因的那一刻

归因机制的目标是在任务失败后，自动分析失败原因，给出可操作的修复建议。这比人工排查更高效，也能积累团队的经验库。

实现路径：

• 决策树分析：基于历史失败案例，建立「症状 → 原因」的映射
• 因果链追踪：从最终错误回溯到源头，标记每个环节的贡献度
• 自愈建议：针对常见失败模式，提供自动修复方案

这一步的复杂度最高，因为需要区分「相关」与「因果」。一个常见的陷阱是把工具超时归因于模型能力，而实际原因是网络抖动。

Agent 门禁系统架构

工程落地的取舍边界

理解了机制与架构后，最关键的问题是：什么情况下值得投入长 horizon agent 的工程成本？

何时值得投入长 horizon 架构

算算投入产出比

长 horizon agent 的工程成本显著高于短任务系统。门禁、回放、状态管理都需要额外的开发与维护投入。因此，不是所有场景都值得。

值得投入的条件：

• 任务耗时超过 15 分钟，且当前成功率低于 80%
• 任务有明确的业务价值，失败成本高（如金融交易、医疗诊断）
• 团队有持续迭代的能力，能够不断优化成功率

OpenAI 的 RSI 项目之所以可行，是因为研究任务的业务价值极高------一个自动化研究员可以替代数周的专家工作。但对于一般的自动化办公场景，这种投入可能不划算。

成本控制与可靠性的平衡

务实的选择

工程实践中，「全有或全无」的思维是危险的。更务实的做法是分阶段投入：

1. MVP 阶段：先实现基础的门禁检查，解决最明显的崩溃模式
2. 优化阶段：根据失败分析，针对性地增强状态管理和工具容错
3. 成熟阶段：引入归因机制和自愈能力，降低人工干预

这种渐进式 approach 既控制了初期成本，又保留了扩展空间。OpenAI 的做法也是类似的------RSI 不是一蹴而就的，而是在内部工具链成熟后才逐步推进的。

未来趋势：自动化研究实习生的启示

拐点已至

Rohan Paul 提到的 OpenAI RSI 里程碑，标志着长 horizon agent 从「学术演示」走向「生产可用」。这背后的驱动因素有三：

一是模型能力的持续提升，使得单步调用的可靠性逼近人类水平； 二是工具生态的成熟，API、SDK、沙箱环境的标准化降低了集成成本； 三是工程框架的完善，LangGraph、AutoGen 等开源方案提供了可复用的基础架构。

对于开发者而言，这意味着现在就可以开始构建长 horizon agent 系统，而不需要等待「完美时机」。关键是明确边界：知道什么场景值得投入，什么场景应该用传统自动化替代。

时间跨度是一个诚实的指标------它不会撒谎，也不会被刷分。当行业还在争论 benchmark 排名时，真正在做产品的人已经在关注任务完成率随时间的变化曲线。这条曲线的斜率，才是智能体能力的真实度量衡。

长轨迹崩溃的三类根因

类型错误累积

局部正确不等于全局正确。Agent 在每一步执行时都可能做出逻辑上合理的决策，但错误会在路径中累积。METR 的研究指出，当前前沿模型（如 Claude 3.7 Sonnet）在 50% 成功率下的任务完成时间跨度约 50 分钟 \[13]。这意味着，超过这个时长后，类型错误的概率呈指数上升。

一个典型的场景是：Agent 在前三步的工具调用完全正确，但第四步的参数类型判断出现偏差，导致后续所有依赖该参数的操作全部错位。这种错误不是模型能力的缺陷，而是长链路中置信度衰减的必然结果。

状态漂移

上下文窗口之外的信息丢失是另一个系统性问题。当任务跨度达到数小时甚至数天，中间状态需要持久化到外部存储。但持久化本身会引入一致性问题：快照是否完整？恢复时状态是否可逆？

OpenAI 内部数据的另一个关键细节是：成功运行的 agent 往往伴随着大量人工干预。这意味着模型的「本地能力」足够强，但缺乏跨状态的追踪与修正机制。\[18]

长轨迹状态管理

工具调用链断裂

外部依赖的不可控性在长任务中被放大。数据库超时、API 限流、第三方服务变更------这些在短任务中可以被快速重试掩盖，但在 64 小时以上的执行窗口中，任何一个环节的失败都会导致整个任务路径失效。

工程门禁与归因架构

事前门禁

防止错误扩散的第一道防线是计划确认。在执行任何工具调用前，要求模型输出可验证的步骤清单，并通过规则引擎或二级模型校验其合理性。这一步的关键是「延迟执行」：先判断再行动，而不是边做边改。

事中回放

快速定位故障点需要完整的执行轨迹记录。每个工具调用的输入、输出、耗时、错误码都必须落盘。当任务失败时，回放机制能够精确还原失败发生的具体节点，而不是给出笼统的「任务失败」反馈。

事后归因

建立因果链是持续改进的核心。失败案例需要经过归因分析，区分是模型判断错误、工具使用不当，还是外部环境变化。这种归因不能依赖人工逐条审查，而需要自动化工具辅助生成初步诊断报告。

Agent 工程门禁状态

下一步行动建议

可以今天就做的三件事：

第一，建立执行轨迹日志规范。无论你当前是否使用 agent 框架，都应在工具调用层增加结构化日志，记录输入输出与耗时。

第二，定义任务分级标准。将任务按时间跨度划分为短（<15分钟）、中（15分钟-4小时）、长（4小时+）三档，并为每档设定不同的成功率目标与干预阈值。

第三，设计前置门禁检查点。在关键工具调用前增加一次快速校验，即使只花 30 秒确认参数类型和依赖状态，也能显著降低长轨迹失败率。

参考文献

\[13] Ziegler, D. M., & Barnes, E. (2026). Measuring AI Ability to Complete Long Software Tasks. arXiv:2503.14499v3 \[18] Rohan Paul. X/Twitter post on OpenAI agent time horizon data. x.com/rohanpaul_a... 1 Rohan Paul on X. x.com/rohanpaul_a... 2 Rohan Paul on X: "I think "time horizon" is becoming one of the more useful ways to talk about agent capability. At OpenAI, as tasks get longer, success without human intervention collapses, from 86% on sub-15-minute tasks to only around 16% on the longest 64-128-hour bucket, while successful runs... / X. x.com/rohanpaul_a... 3 rohan-paul (Rohan Paul) · GitHub. github.com/rohan-paul 4 Meta | Rohan Paul. www.linkedin.com/posts/rohan... 5 OpenAI首度公布"内部RSI进展"：已实现"自动化研究实习生". wallstreetcn.com/articles/37... 6 Rohan Paul | Substack. substack.com/@rohanpaul 7 ‪Rohan Paul‬ - ‪Google Scholar‬. scholar.google.com/citations?u... 8 智能体 AI 时代的科学计算 | OpenAI. openai.com/zh-Hans-CN/...