让一个AI模型去写一段短文案它通常表现很好但如果你让它负责一个需要连续执行好几个小时、甚至跨天协作的完整工作流——比如收集一批竞品信息、阅读和筛选原始资料、整理成结构化文档、给出结论、生成图表还要在过程中根据中间反馈调整方向——事情往往就开始失控。我最近在看长时程AI任务评测时这种感受特别明显。相关评测显示当前顶尖模型在长时程任务上的表现只有人类水平的 27.3%。这个数字要放在单项问答、代码生成或短文本概括里很容易被当成一次糟糕的测试结果但如果把它放回“长时程任务”这个场景里它说的其实是另一件事我们一直在用“短跑标准”训练和评价模型却在越来越多的地方指望它们去跑“马拉松”。这篇文章不做纯科普也不只复述一个数字。我想从“为什么顶尖模型只有人类 27.3%”这个问题出发聊一聊长时程任务评测到底是什么、为什么会测出这么低的分数以及普通开发者和技术团队能从中得到哪些真正可用的改进思路。1. 长时程任务评测的不是“会不会”而是“撑不撑得住”1.1 从单轮问答到多步闭环任务性质变了传统的大模型评测大多数是“给一个输入看一个输出”。比如问模型一个常识问题看回答对不对给一段代码需求看生成代码能不能编译通过给一篇文章让模型写摘要再和参考答案对比得分。这类任务里模型只需要一次推理上下文是完整的问题边界是清晰的标准答案是确定的。这种评测能很好地反映模型的“单点智能”但很难反映模型在真实工作流中的价值。长时程任务不一样。它要求模型在一个相对宏大的目标下连续完成多个不同环节的操作。这些环节之间往往还有依赖关系第一步的输出是第二步的输入第二步的结果会影响第三步的决策。整个任务跨度可能是几十分钟、几个小时甚至需要跨天执行。模型必须在执行过程中记住早期的目标、约束和关键信息在后续步骤中持续使用它们同时还要处理新出现的信息、异常和干扰。换句话说长时程任务评测的并不是“模型懂不懂某个知识点”而是“模型能不能像一个靠谱的项目执行者一样从头到尾把一个多环节任务稳定地推进下来”。单点能力可以通过堆参数、堆数据快速提升但“稳定地推进一个长流程”考验的是规划、记忆、自我监控、错误恢复和状态管理这些恰恰是当前模型最薄弱的环节。1.2 长时程任务里的三类典型场景如果要把长时程任务具体化常见的场景大致可以分为三类。第一类是信息收集与综合。比如让AI去为一个行业话题收集近一个月的动态要求来源不少于十个输出包括摘要、趋势判断和来源列表。这个任务看上去不难但模型需要多次搜索、打开网页、判断内容相关性、去重、筛选并在一段时间后把零散信息汇总成逻辑一致的报告。问题很容易出现在中间环节搜索到结果后没有保存来源阅读了几个页面后忘了最初的目标或者被大量无关信息带偏方向。第二类是多工具调用与状态管理。比如让AI操作一个自动化流程需要调用搜索、数据库查询、文件读写、内容生成等多种工具且每一步都要更新某个状态变量。这类任务里模型不仅要理解每一步操作还要维护一个不断变化的外部状态。常见的问题是工具返回格式不一致时模型不会恢复直接卡死或重复调用或者更新了状态但在后续步骤中使用旧状态。第三类是长篇幅内容生产。比如一口气写一份完整的产品方案或者修改一个开源项目的多个文件。任务过程中需要保持整体风格一致、逻辑不矛盾并且对前期已经写过的内容保持记忆。这里的难点不在于第一段怎么写而在于写到第三部分时模型是否还记得第一部分里的关键设定。这些场景的共性是完成度不只依赖“某一次生成能力”而是依赖一整套连续决策和自我管理能力。所以评测长时程任务本质上是在考验模型有没有“长期工作素养”。2. 为什么顶尖模型只能拿到人类 27.3% 的水平2.1 四个瓶颈记忆衰减、错误累积、规划失效、状态恢复困难如果只看单点能力顶尖模型在绝大多数基准测试里都已经接近甚至超过人类平均水平。那为什么一到长时程任务分数会掉到人类水平的 27.3%从评测轨迹和工程经验看问题主要出在四个地方。记忆衰减是第一道坎。即使模型的上下文窗口足够大在实际长任务中早期信息也很容易被大量中间内容稀释。模型不是真的“忘记”了而是在处理后续步骤时没有把早期关键信息当作当前决策的约束条件。比如任务要求“只统计最近三个月的新闻”模型可能在第五轮检索时开始关注半年以前的文章然后把它们也写进报告。这类错误不是由于模型不懂时间过滤而是因为长序列里对早期约束的注意力权重被分摊了。错误累积更加致命。长时程任务通常有链路依赖早期一个小错误不会立刻引起注意但会被后续步骤当作既成事实继续加工。比如模型在第一步把某公司的名称理解错了之后所有检索和总结都围绕这个错误名称展开最终报告的核心结论也随之偏离。单步错误率可能只有几个百分点但经过二十步、五十步的链路传递最终出错的概率会迅速放大。规划失效是另一个典型问题。模型在任务开头通常会列出一个看起来合理的步骤计划但执行中一旦遇到计划外情况比如某个检索接口返回超时某个页面被验证码拦截某个文件格式不符合预期它就很难重新规划出替代路线。更常见的是模型会尝试一遍遍重复同样失败的调用而不是停下来反思“当前方式可能不对需要换一条路”。这种缺乏弹性的行为在短任务里很难暴露在长任务里会严重浪费时间和资源。状态恢复困难则是工程化落地的关键痛点。短任务中断后重跑一次没多大成本但长时程任务如果执行到一半中断理想情况应该能从断点恢复。模型在这方面的能力普遍偏弱往往需要从头开始或者只能恢复到很粗粒度的状态。评测中一旦加入“中途注入外部变化”或“强制中断后继续”这类操作很多模型都会明显失分。2.2 上下文窗口不是万能药面对长时程任务很多人第一反应是把模型上下文窗口加大把所有历史记录都塞进去模型不就能记住一切了吗这个思路在方向上是合理的但远没有想象中那么简单。上下文窗口扩大只解决“装得下”的问题没有解决“用得上”的问题。当上下文里包含几十页对话记录、工具调用日志、网页摘要和中间结果时模型需要在海量信息中定位真正关键的条目。注意力机制在处理这类长序列时依然容易被近期内容或显著性内容影响导致早期关键约束被忽略。同时更长的上下文意味着更高的推理成本和更长的首字延迟如果在任务中频繁调用模型开销会很快膨胀。从工程实践看依赖外部记忆和结构化状态管理往往比单纯扩大上下文窗口更有效。比如在Agent系统中增加一个专门的状态存储让模型定期把关键决策写入结构化文件或者使用独立检索模块在需要时把最相关的历史记录拉回上下文。这些手段是把长任务从“一口气记住所有事”变成“在需要时快速找到正确的事”本质上是在补模型的记忆短板。所以27.3% 这个低分并不能通过“换一个更大上下文窗口的模型”就自动解决。它反映的是一个系统性问题模型自身在长流程中的信息管理能力还不够。2.3 27.3% 不意味着模型“笨”而是评测维度变了看到 27.3% 这个数字时不要马上得出结论说“顶尖模型不行”。要理解这个数字需要分清评测维度变化。传统AI评测衡量的是“知识密度”和“单步推理能力”模型可以在几秒内完成一次高质量推理而长时程任务评测更像是在考“项目管理能力”。人类做长任务时会做规划、写备忘、定期检查进度、遇到问题主动调整策略甚至会在关键节点停下来向同事确认。这些行为看似简单背后是元认知能力——时刻意识到“我现在在哪里、我离目标还有多远、我该优先做什么”。当前模型在元认知层面还很弱。它可以在单步内回答正确但缺少一个稳定的“自我监控器”来评估当前状态是否有偏离目标的迹象。因此模型在短任务里可以表现得像一个聪明的专家到了长任务里却像一个容易分心、不会复盘、也不擅长从失败中学习的初级实习助理。这不是说模型没有价值而是说我们应该换个角度去看模型的能力边界。如果只做短时任务短时基准就够了如果部署到真实业务流里长时程能力就必须单独评测、单独优化。3. 长时程AI任务评测是怎么做出来的3.1 评测任务设计从提交到验收要覆盖完整闭环要设计一个好的长时程任务评测核心不是“选一个很难的问题”而是“把任务设计成一个需要多步执行、多步验证、最终交付完整结果的闭环”。一个合格的长时程任务至少要包含四个要素明确的任务目标模型要交付什么比如“生成一份XX行业近30天动态分析报告”。初始状态任务开始时提供什么资源、限制哪些条件比如“只能使用给定的搜索接口访问外部网站不能超过30次”。过程约束任务执行中必须经过哪些环节比如“至少检索10个不同来源保存每个来源的标题、链接、访问时间和摘要”。验收标准最终结果怎么判分比如“信息覆盖度是否完整、来源是否有效、结论是否与数据一致、格式是否满足要求”。评测任务不能设计成模型靠一次回答就能完成。如果任务太短、太直接评测结果依然会退化成单点能力测试失去长时程评测的意义。我见过一些早期评测任务名义上叫“长时程”实际只是把一个长问题丢给模型让模型一次性生成答案。这种任务只能偶尔暴露模型对长输入的记忆问题却测不出一个完整工作流的稳定性。设计任务时还需要注意难度梯度。建议一组任务里同时包含“中等长度、多个依赖步骤”和“超长周期、跨天执行、外部状态变化频繁”两种难度。这样既能测出模型在正常长流程里的表现也能测出它在极端压力下的退化速度。3.2 过程追踪与评分结果正确不等于过程可靠长时程任务评测最容易犯的错误是只给最终结果打分。如果模型最终输出的报告看起来完整但过程中忽略了很多关键步骤或者多次绕弯路、大量无效调用之后才“蒙对”结果这种表现不能在真实业务中被认可。所以评测要同时关注两个维度最终交付质量以及执行过程质量。最终交付质量相对好打分比如覆盖度、准确性、格式规范性执行过程质量则需要记录完整轨迹并统计多个指标。一个可参考的评分维度表如下评分维度考察内容示例说明任务完成度最终结果是否满足验收标准报告是否覆盖所有要求主题来源是否真实可达单步环节成功率每个关键步骤的完成质量检索步骤是否有效返回读取页面是否成功路径效率是否用较少的步骤完成任务一些模型需要 50 次调用另一些只需要 15 次目标保持能力中途是否偏离初始目标是否出现收集到无关主题内容的情况错误恢复能力遇到异常后能否自主恢复工具返回超时后是重试、换方案还是直接卡死状态一致性中间状态与最终输出是否一致开头统计的数据和结尾引用的是否是同一批过程追踪需要依托评测平台。评测系统要记录模型每一次动作的输入输出、耗时、调用状态、重试次数以及模型在每个时间节点的内部状态摘要。缺少过程记录任何对模型“为什么失败”的分析都会变成猜测。3.3 一个最小评测流程示例如果只是个人或小团队想先尝试长时程评测不需要一开始就搭一个大型平台可以先做一个最小流程。第一步定义一个任务描述文件包含目标、初始状态和验收标准。第二步准备一个隔离的评测环境尽量屏蔽外部不稳定因素比如固定搜索接口的超时时间、设置权限范围。第三步让模型以 Agent 方式运行通过工具调用完成任务。第四步用脚本记录每一步的轨迹和状态。第五步人工或半自动方式对结果打分。轨迹记录可以采用简单的 JSON 结构例如{ task_id: research-report-001, goal: 生成行业动态周报, start_time: 2025-01-01T09:00:00Z, steps: [ { step: 1, action: search, query: AI agent trends 2025, status: success, duration: 2.3, result_summary: 返回10条结果 }, { step: 2, action: open_url, url: https://example.com/report, status: failed, error: timeout, duration: 8.1 } ], final_output: ..., score: { completeness: 0.8, efficiency: 0.6, recovery: 0.4 } }这只是一个通用示例结构具体字段需要结合任务类型调整。跑评测前有几件事要先确认模型版本、依赖包版本、可访问的API列表、网络权限、超时设置。否则很容易出现“昨天能跑通今天全部失败”的情况而且很难定位是模型的问题还是环境的问题。注意不要一上来就设计超长周期的任务。先让模型在一个小时内能跑完的任务上反复评测确认评测环境稳定后再逐步拉长时间和复杂度。评测框架本身也需要被评测否则数据不可信。4. 普通开发者怎么把长时程评测用起来4.1 不要只看最终分数要拆解“在哪个阶段丢分”长时程任务评测的价值不在于一个最终百分比而在于它能帮助我们发现模型到底在哪个环节掉链子。所以拿到评测结果后不要只盯着 27.3% 这个数字叹气应该把任务拆成阶段统计每个阶段的完成率。一个比较通用的拆法是把长任务分成六个阶段理解需求、制定计划、执行步骤、检查结果、修正反馈、最终交付。可以先统计模型在六个阶段里的表现看它是在计划阶段就偏离了目标还是在执行阶段频繁出错又或者是在最终交付前没有做质量检查。从很多早期评测轨迹来看模型通常在“执行步骤”和“修正反馈”两个阶段丢分最多。执行步骤阶段容易因为工具调用失败和单步错误累积而崩溃修正反馈阶段则经常出现“模型已经知道结果有问题但不知道怎么改”的情况。如果你在用长时程评测自己的Agent可以按这个链路排查先看轨迹判断任务在哪一步断掉再看输入状态确认当时模型可用的上下文里是否包含关键信息再看工具调用确认是超时、格式错误、权限不足还是工具返回了不可解析的数据再看模型决策检查它是否沿用了错误的中间结果最后看任务设计确认是不是验收标准不清晰或目标约束遗漏。这条链路可以帮助你避免一上来就换模型或调参数。很多时候问题根本不在模型推理能力而在于缺失状态管理或工具调用过于脆弱。4.2 用评测结果反推 Agent 设计先控错误累积再优化单步能力长时程任务评测结果最直接的价值是指导 Agent 系统设计。如果评测显示“模型在第三步之后开始出现明显偏离”那么第一步要做的不是换更大的模型而是减少错误累积的机会。具体可以这么做让每个工具调用都输出结构化结果并且对结果做校验。比如要求返回 JSON如果解析失败则重试或标记为失败而不是继续往下走。在关键步骤之间加入摘要节点让模型每隔几步写一个“当前状态已完成X待办Y不确定项Z”这样即使早期信息被稀释后续步骤也能从明确摘要中恢复。还可以在关键位置设置人工确认点。比如在模型准备生成最终报告之前要求它先列出报告大纲和数据来源由人工确认后再继续。对于长时程任务人工审核不是降低效率而是防止模型把错误一路滚到最后。强调一个原则先控错误累积再优化单步能力。很多团队会在模型单步准确率上花大量精力但忽视了长任务中的状态管理。单步准确率从 99% 提到 99.5%看起来很好但如果每一步都允许少量误差传递经过四十步后最终结果可能仍然不可用。相反通过结构化的中间状态和校验机制即使单步能力一般整体稳定性也会明显提升。4.3 适合与不适合用长时程评测的场景长时程任务评测不是万能的它适合解决某些问题但不适合作为所有场景的通用标准。适合用长时程评测的场景至少包括客服 Agent需要多轮对话并持续跟踪用户问题文档处理工作流需要读取多个文件、生成报告、并多次更新代码仓库级任务需要理解多个文件并修改后跑测试市场调研自动化需要持续搜索、阅读、筛选并输出结论。这类场景的共同特点是有明确的长期目标、需要多步工具调用、中间状态会影响最终结果。不适合用长时程评测的场景则包括单轮问答、单文件代码生成、短文本分类、简单内容续写。这些任务用常规基准测试更直接、更快、更便宜。另外长时程评测成本较高每次任务可能要执行几十次甚至上百次模型调用不适合在开发调试阶段频繁跑。建议先在小规模手动任务上验证思路再进入正式评测。适用场景不适用场景多轮客服对话单轮问答多文件代码修改单函数代码生成调研报告自动生成短文本摘要跨天数据分析流程分类和情感分析需要工具调用和状态管理的Agent一次性内容创作5. 从 27.3% 到可用的工程化路径5.1 先跑通单次闭环再扩展到跨天任务看到“顶尖模型只有人类 27.3%”这个数字很容易产生两种极端反应要么认为长时程AI不可用要么觉得只要继续堆算力就能解决。这两种反应都过于简单。实际落地时更应该先接受一个现实当前模型在长时程任务上并不成熟所以不能一上来就部署一个无人值守的完整工作流。推荐路径是先选一个最小任务闭环人工控制每一步让模型在短时间内跑通一次。这里的“跑通”不是指模型独立完美完成而是指整个流程节点是通的模型和工具之间的调用是顺畅的中间状态是可记录的。跑通之后再逐步增加任务步骤、引入更多不确定性、拉长执行时间。举个例子如果要做一个“自动竞品信息整理”Agent可以先不要一上来让它自己从零规划而是把任务流程拆成固定步骤搜索指定关键词、读取前五条结果、提取摘要、保存到表格、生成简报。每一步单独测试确认稳定后再串成完整流程。然后才允许模型在遇到异常时做小范围调整。只有在单次闭环已经稳定的情况下才应该去挑战跨天任务。这样做的好处是可以把评测数据和问题定位精确到具体环节而不是面对一个 27.3% 的模糊分数无从下手。5.2 建立检查点、重试和人工审核机制长时程任务要真正进入生产环境不能只靠模型自身能力工程机制必须补位。第一状态快照与断点续跑。每完成一个关键步骤就把中间状态保存下来。如果后续步骤失败可以回到最近一个检查点重新执行而不是整个任务重来。这在评测中也要模拟因为真实业务不允许因为一次网络抖动就丢弃所有进度。第二失败重试策略。工具调用失败时不要立刻让模型做开放式思考而是先用固定策略重试几次如果仍然失败再上报异常。重试可以带退避策略比如第一次等 1 秒第二次等 2 秒第三次等 4 秒。对不同类型的工具错误码含义不一样需要单独配置。第三关键节点人工审核。在信息输出、资金操作、对外发布等高风险节点人工确认仍然不可缺少。这不只是安全要求也是长流程可控性的保障。评测时也应该记录“需要人工介入的次数”作为一个重要指标次数越少越好但不能认为零介入才是最优。如果评测给出模型只有人类 27.3% 的分数那么这些工程机制就是把你从“不可用”拉到“部分可用”的关键杠杆。即使模型单点能力再提升没有这些机制长任务依然不稳。建议每次跑完长时程评测至少留出半小时复盘轨迹。不要只看分数。看模型在哪个环节花了最多时间哪个错误被重复多次哪一步需要人工修正。这些数据比 27.3% 这个数字更有参考价值。5.3 长时程能力的未来还需要什么最后聊一点更长期的判断。27.3% 这个数字既是当前模型的短板也是评测方法早期阶段的反映。长时程任务评测本身还很年轻任务设计、评分标准、过程追踪都还没有形成统一范式。现在看到的低分不一定是“模型性能上限”更可能是“评测维度比以往严格得多”。未来要真正提升模型的长时程能力需要两个方向同时推进。一个是模型侧需要更好的记忆管理、自我评估和错误恢复机制。模型不能只是在推理时更聪明还需要知道自己做了多久、做对了什么、接下来该干什么。另一个是工程侧需要更成熟的任务编排和评测基础设施让长时程任务可以被稳定地构建、运行、监控和复盘。这两者之间会形成正循环评测基础设施越好我们越能看清模型在哪些环节失败模型能力提升后又会让更多复杂任务变成可自动化的常规操作。现在投入去做长时程评测不管是用现成工具还是自己搭一套小流程都不是浪费时间。如果你也想从 27.3% 这个数字开始做点什么不要急着搭一个大型评测平台。先选一个自己最熟悉的任务把它定义成长时程任务跑一轮完整轨迹拆出失败最多的一环改掉它再跑一轮。这样持续迭代你会比模型更快地理解“长时程”这件事的真正难点。而模型的短板也会在被评测、被记录、被优化的循环里一点点缩短。