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 内部发布的 RSIResearch 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 的 RSIResearch Software Intern项目能够跨越人类工作日核心突破之一就是建立了工具调用的容错机制超时重试、降级策略、错误恢复。这些机制不是锦上添花而是长任务的基础设施。长 Horizon Agent 崩溃机制因果图系统架构门禁、回放与状态归因理解崩溃机制后需要相应的架构来应对。主流方案围绕三个核心门禁、回放、状态归因。事前门禁防止错误扩散架构师点头认可门禁机制的核心思想是在关键节点设置检查点确保输出符合预期后再继续。这与软件测试中的「防御式编程」一脉相承。具体实现包括类型校验使用 JSON Schema 或 Pydantic 验证模型输出内容检查对关键信息进行事实核查或逻辑校验资源预算监控 token 消耗、调用次数、执行时间超限则提前终止OpenAI 内部的做法是在每个子任务完成后插入验证步骤只有通过的产物才进入下一阶段。这种做法增加了单次执行时间但大幅降低了端到端失败率。事中回放快速定位故障点查 bug 查到怀疑人生长任务失败时最耗时的是定位故障点。回放机制通过记录完整的执行轨迹允许开发者在失败时「倒带」逐步骤检查。关键设计要素结构化日志每次 LLM 调用、工具调用的输入输出都持久化存储Trace ID为每个任务分配唯一标识串联所有子操作时间戳对齐精确记录每个步骤的开始结束时间便于分析性能瓶颈这种能力在调试阶段价值巨大。没有回放长任务调试只能靠猜有了回放可以快速定位是模型幻觉、工具超时还是状态管理问题。事后归因建立因果链找到根因的那一刻归因机制的目标是在任务失败后自动分析失败原因给出可操作的修复建议。这比人工排查更高效也能积累团队的经验库。实现路径决策树分析基于历史失败案例建立「症状 → 原因」的映射因果链追踪从最终错误回溯到源头标记每个环节的贡献度自愈建议针对常见失败模式提供自动修复方案这一步的复杂度最高因为需要区分「相关」与「因果」。一个常见的陷阱是把工具超时归因于模型能力而实际原因是网络抖动。Agent 门禁系统架构工程落地的取舍边界理解了机制与架构后最关键的问题是什么情况下值得投入长 horizon agent 的工程成本何时值得投入长 horizon 架构算算投入产出比长 horizon agent 的工程成本显著高于短任务系统。门禁、回放、状态管理都需要额外的开发与维护投入。因此不是所有场景都值得。值得投入的条件任务耗时超过 15 分钟且当前成功率低于 80%任务有明确的业务价值失败成本高如金融交易、医疗诊断团队有持续迭代的能力能够不断优化成功率OpenAI 的 RSI 项目之所以可行是因为研究任务的业务价值极高——一个自动化研究员可以替代数周的专家工作。但对于一般的自动化办公场景这种投入可能不划算。成本控制与可靠性的平衡务实的选择工程实践中「全有或全无」的思维是危险的。更务实的做法是分阶段投入MVP 阶段先实现基础的门禁检查解决最明显的崩溃模式优化阶段根据失败分析针对性地增强状态管理和工具容错成熟阶段引入归因机制和自愈能力降低人工干预这种渐进式 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. https://x.com/rohanpaul_ai/status/2096720216466342334[1] Rohan Paul on X. https://x.com/rohanpaul_ai/status/2096665545190043737[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. https://x.com/rohanpaul_ai/status/2096720216466342334[3] rohan-paul (Rohan Paul) · GitHub. https://github.com/rohan-paul[4] Meta | Rohan Paul. https://www.linkedin.com/posts/rohan-paul-ai_meta-activity-7499817452025917440-pb9F[5] OpenAI首度公布“内部RSI进展”已实现“自动化研究实习生”. https://wallstreetcn.com/articles/3781192[6] Rohan Paul | Substack. https://substack.com/rohanpaul[7] Rohan Paul - Google Scholar. https://scholar.google.com/citations?userCgp-L2UAAAAJhlen[8] 智能体 AI 时代的科学计算 | OpenAI. https://openai.com/zh-Hans-CN/index/scientific-computing-agentic-ai 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 内部发布的 RSIResearch 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 的 RSIResearch Software Intern项目能够跨越人类工作日核心突破之一就是建立了工具调用的容错机制超时重试、降级策略、错误恢复。这些机制不是锦上添花而是长任务的基础设施。长 Horizon Agent 崩溃机制因果图系统架构门禁、回放与状态归因理解崩溃机制后需要相应的架构来应对。主流方案围绕三个核心门禁、回放、状态归因。事前门禁防止错误扩散架构师点头认可门禁机制的核心思想是在关键节点设置检查点确保输出符合预期后再继续。这与软件测试中的「防御式编程」一脉相承。具体实现包括类型校验使用 JSON Schema 或 Pydantic 验证模型输出内容检查对关键信息进行事实核查或逻辑校验资源预算监控 token 消耗、调用次数、执行时间超限则提前终止OpenAI 内部的做法是在每个子任务完成后插入验证步骤只有通过的产物才进入下一阶段。这种做法增加了单次执行时间但大幅降低了端到端失败率。事中回放快速定位故障点查 bug 查到怀疑人生长任务失败时最耗时的是定位故障点。回放机制通过记录完整的执行轨迹允许开发者在失败时「倒带」逐步骤检查。关键设计要素结构化日志每次 LLM 调用、工具调用的输入输出都持久化存储Trace ID为每个任务分配唯一标识串联所有子操作时间戳对齐精确记录每个步骤的开始结束时间便于分析性能瓶颈这种能力在调试阶段价值巨大。没有回放长任务调试只能靠猜有了回放可以快速定位是模型幻觉、工具超时还是状态管理问题。事后归因建立因果链找到根因的那一刻归因机制的目标是在任务失败后自动分析失败原因给出可操作的修复建议。这比人工排查更高效也能积累团队的经验库。实现路径决策树分析基于历史失败案例建立「症状 → 原因」的映射因果链追踪从最终错误回溯到源头标记每个环节的贡献度自愈建议针对常见失败模式提供自动修复方案这一步的复杂度最高因为需要区分「相关」与「因果」。一个常见的陷阱是把工具超时归因于模型能力而实际原因是网络抖动。Agent 门禁系统架构工程落地的取舍边界理解了机制与架构后最关键的问题是什么情况下值得投入长 horizon agent 的工程成本何时值得投入长 horizon 架构算算投入产出比长 horizon agent 的工程成本显著高于短任务系统。门禁、回放、状态管理都需要额外的开发与维护投入。因此不是所有场景都值得。值得投入的条件任务耗时超过 15 分钟且当前成功率低于 80%任务有明确的业务价值失败成本高如金融交易、医疗诊断团队有持续迭代的能力能够不断优化成功率OpenAI 的 RSI 项目之所以可行是因为研究任务的业务价值极高——一个自动化研究员可以替代数周的专家工作。但对于一般的自动化办公场景这种投入可能不划算。成本控制与可靠性的平衡务实的选择工程实践中「全有或全无」的思维是危险的。更务实的做法是分阶段投入MVP 阶段先实现基础的门禁检查解决最明显的崩溃模式优化阶段根据失败分析针对性地增强状态管理和工具容错成熟阶段引入归因机制和自愈能力降低人工干预这种渐进式 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. https://x.com/rohanpaul_ai/status/2096720216466342334[1] Rohan Paul on X. https://x.com/rohanpaul_ai/status/2096665545190043737[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. https://x.com/rohanpaul_ai/status/2096720216466342334[3] rohan-paul (Rohan Paul) · GitHub. https://github.com/rohan-paul[4] Meta | Rohan Paul. https://www.linkedin.com/posts/rohan-paul-ai_meta-activity-7499817452025917440-pb9F[5] OpenAI首度公布“内部RSI进展”已实现“自动化研究实习生”. https://wallstreetcn.com/articles/3781192[6] Rohan Paul | Substack. https://substack.com/rohanpaul[7] Rohan Paul - Google Scholar. https://scholar.google.com/citations?userCgp-L2UAAAAJhlen[8] 智能体 AI 时代的科学计算 | OpenAI. https://openai.com/zh-Hans-CN/index/scientific-computing-agentic-ai