“长时程AI任务评测”最近在AI社区里讨论不少核心结论是当前顶尖模型在执行多步骤、长时间任务时整体表现只达到人类水平的27.3%。这个数字初看有点刺眼但真正值得关注的不是百分比本身而是它把评价AI的方式从“单点能力”拉到了“连续工作能力”层面。对做Agent开发、流程自动化选型、AI能力评估的人来说这个方向值得认真拆一遍。先说明一下我的判断这类评测不是让模型做一道难题而是让它像人一样在带有环境反馈的任务里连续完成多个步骤。比如给定一个研究任务需要搜索资料、整理信息、比对选项、生成报告或者让Agent在网页里完成一次多步骤操作。评测关注的不只是最终答案还包括过程是否合理、中间步骤是否完整、出错后能不能恢复。下面我按实际落地会遇到的几个问题展开评测到底测的是什么、为什么头部模型分数不高、这类评测结果怎么用到自己的项目里、以及如何提升Agent在长时程任务上的成功率。1. 先弄清楚评测测的是“连续工作能力”不是“单点智商”1.1 单点任务和长时程任务到底差在哪单点任务很好理解给一段文本做摘要回答一个知识问题生成一段代码翻译一句话。这类任务模型已经非常擅长普通对话和单次生成场景里旗舰模型基本都能给出可用结果。长时程任务不一样。它要求模型在一个完整任务里连续做多个动作而且越往后越依赖前面步骤的产出。举个例子一个典型的调研任务可能包含“明确需求、搜索来源、筛选信息、交叉验证、按指定格式输出报告”五个阶段。模型要自己分配注意力记住用户最初的要求在大量检索结果里挑有用的最后还要保证输出格式正确。这里的关键不是某个阶段难而是“阶段之间的衔接”难。单点任务只考一次状态转换长时程任务考的是很多次状态转换之间的连续一致性。你可以把前者理解成“每次都能答好一道题”后者是“要独立完成一个项目中间没人帮你纠正”。1.2 评测通常关注哪些维度这类评测不会只看最终答案对不对因为长时程任务很多时候没有唯一答案。评测者更关注的是模型在整个执行轨迹里的表现常见维度有下面几个。评测维度具体说明人类表现常见特征AI模型的常见短板目标保持多步之后是否还记得最初任务基本稳定偶尔会短暂分心中途容易偏移或简化目标子任务完成度每个中间步骤是否都完整执行高基本不会漏步骤容易跳步或漏掉隐性要求纠错恢复出错后能否发现并修复人会主动回退检查经常将错就错继续往下走路径效率用最少的步骤完成任务有经验和直觉容易绕路或反复试探输出一致性最终结果是否符合格式与约束稳定后期容易忘记格式要求稳定性多次运行结果是否可靠波动较小相同任务成功与失败随机性大这些维度里最容易被忽视的是“纠错恢复”。很多长时程任务里模型不是不知道正确答案而是前面某一步已经做错后续所有动作都建立在这个错误之上而且模型几乎没有主动回头检查的习惯。1.3 27.3%这个数字该怎么读27.3%最合理的理解是把所有任务的人类平均表现作为100%然后按任务难度加权后模型综合得分只有人类的27.3%。它不是指“模型所有任务都只有人类四分之一能力”更合理的解释是任务越复杂、步骤越多模型相对人类的下滑越明显。我实测时也有类似体感。单步问答和短代码生成模型表现可以接近甚至超过多数普通人但只要任务超过一定长度需要依赖前面几步的结果成功率就快速下降。所以这个数字更准确的信息是长时程任务是目前AI能力曲线里掉得最快的一段。2. 为什么顶尖模型在长时程任务上只拿到这个水平2.1 记忆衰减与上下文利用不均很多人以为模型有几十万Token的上下文窗口就一定能记住前面所有内容。但从实际表现看长上下文里有大量信息模型对它们的利用程度并不均匀。窗口中间部分的内容、早期埋下的约束条件在后半段执行时经常被弱化。这和Transformer的注意力机制有关。注意力权重会偏向最近出现的Token和当前最相关的片段那些“很久以前出现过、但后续没有再被重复”的关键信息很容易在逐层计算中变得不突出。工程上可以靠滑动窗口、滚动摘要、外部记忆来缓解但模型原生推理路径里记忆衰减是绕不开的短板。2.2 目标漂移与子目标吞噬主线长时程任务经常出现一个现象模型做着做着就忘了最初的目标被当前子任务牵着走。例如任务要求“找到性价比最高的设备并输出推荐理由”模型可能在搜索环节投入太多精力不断细化参数对比最后给出的方案过于复杂甚至偏离了用户原本的预算约束。人类的做法是隔几步回看一遍原始需求模型默认缺少这种“主动回到主线”的机制。子目标吞噬主线还体现在模型容易把当前子任务当成全部任务。评测中常见的情况是Agent要在网页里先登录、再搜索、再筛选、最后提交表单结果模型把大量时间花在登录和搜索上到了筛选阶段已经不再遵循最初的筛选条件。2.3 错误累积与缺乏回退检查长时程任务里错误是会被复利的。第一步格式错了第二步基于这个格式解析数据就会拿到空值第三步可能直接输出一个看似完整但内容空洞的结果。每一步表现单看都不算离谱但连在一起最终结果的可用度会断崖式下降。人类遇到这种情况会做回退检查。写报告写了三页之后发现数据源选错会回到数据源重新核对。而模型默认的执行路径是线性推进缺少“定期检查中间产物是否合理”的机制。要让模型具备回退能力不能只靠提示词里写一句“请仔细检查”通常需要在工程链路里把校验作为一个独立步骤加进去。2.4 环境反馈利用不充分在真实Agent场景里模型不仅要推理还要面对工具返回结果、页面加载状态、接口错误码、权限提示等环境反馈。很多失败并不是“推理能力不行”而是模型对反馈的解读不够灵活。一种典型情况是接口返回了非预期格式模型没有意识到需要先修正调用参数而是继续顺着错误格式解析最终报错退出。另一种情况是页面状态变化导致点击目标消失模型没有根据当前页面内容重新规划而是重复尝试同一个动作。这类问题会让模型在长时程任务里的成功率明显下降因为真实环境几乎不可能每一步都按预期返回。3. 这种评测结果在自己的项目里怎么落地使用3.1 从评测到自测复现一个最简长程任务评测结论可以帮我们建立预期但真正落地时最好用自己的场景复现一遍。我建议不要一开始就上完整业务流而是先设计一个能反映“多步骤 状态衔接”的最小任务。一个常见的最小自测任务是准备一个模拟环境比如一个测试网页或一组工具接口。定义一个目标例如“在订单列表里找出最近一周超过1000元的订单汇总成表格并按金额降序输出”。记录模型的完整执行轨迹不只记最终结果。人工打分重点看子步骤完整度、目标保持、输出格式和恢复能力。重复运行5到10次看成功率的稳定性。很多团队第一次做这种自测时会发现模型在单次对话里表现很好但一旦把任务拆成多轮执行成功率会明显下降。这不是模型变笨了而是任务环境、工具协议和上下文管理共同作用的结果。3.2 用“完成度 恢复能力”替代单一成功率只看最终成功或失败会丢失大量信息。长时程任务里一次“失败”可能已经完成了80%的子步骤只是最后输出格式不对。这类结果不应该和“只完成10%就卡死”的情况混在一起。更稳妥的评估方式是用两个指标完成度模型完成了多少核心子步骤可以用0到100%之间的分数表示。恢复能力模型在执行出错后是能自主恢复还是需要人工介入。下面是一个简单示例用来说明如何把过程信息纳入评分。# 长时程任务评估示例伪代码 def evaluate_task(trajectory, sub_task_list): completed 0 for sub in sub_task_list: if sub.finished(trajectory): completed 1 finish_rate completed / len(sub_task_list) recover_events 0 for event in trajectory.error_events: if event.recovered: recover_events 1 recover_rate recover_events / max(len(trajectory.error_events), 1) return { finish_rate: finish_rate, recover_rate: recover_rate, pure_success: trajectory.final_result.is_valid, }实际项目里可以把这三个结果分开记录。只有三个都看才能判断问题出在规划、执行还是恢复环节。3.3 先分清是模型问题还是工程链路问题长时程任务跑不通时不要急着把原因归给模型。很多现象看起来是模型能力不足实际上是工程链路里的某个小问题。现象容易被误判为更可能的真实原因工具调用总是失败模型不会用工具工具接口定义不清晰参数格式要求没写清楚长任务后期输出混乱模型记忆差上下文太长前面结果没有被结构化写回经常绕路、重复尝试模型规划能力差环境反馈不完整模型看不到关键状态变化输出格式不稳定模型不听话提示词缺少强约束或没有独立的格式校验环节任务到一半卡死模型推理超时单步执行时间过长缺少超时重试机制判断顺序应该是先看输入和接口协议再看上下文长度和记忆设计然后看失败时日志里的环境反馈最后才能判断是不是模型推理本身的问题。4. 想让Agent在长时程任务里更靠谱优先优化这四个环节4.1 任务分解把大目标改成显式子目标长时程任务成功率低很多时候是因为模型把一个大目标当成一个黑盒来处理。让Agent显式写出子目标列表再按顺序执行是一种简单但有效的做法。任务分解的好处有三个一是模型在每一步都更容易判断当前状态二是子目标之间可以插入校验节点三是失败后可以定位到具体环节不用整个任务推倒重来。建议把子目标写得可验证。比如不要只写“整理资料”而是写“从搜索结果中提取至少五条与预算相关的信息并标注来源”。可验证的目标更容易让模型判断自己是否完成也方便程序自动检查。4.2 记忆设计给模型一个外部草稿纸很多长时程任务失败不是模型没能力而是中间状态没有保存。人类做项目时会把结论写在笔记里模型也需要一个外部记忆机制。常见的做法是把每个子任务的输出写到一个结构化文件或变量里下一步从文件读取而不是依赖上下文里的历史消息。对长对话采用滚动摘要把早期内容压缩成关键结论减轻上下文压力。对需要检索的场景把已经确认的信息作为检索增强材料而不是每次重新从原始文本里找。这里的关键是“显式写回”。只靠模型自己记住前面说了什么在长任务里不可靠。外部记忆相当于给模型一张草稿纸让它把重要产出固定下来。4.3 反馈回路每步校验失败重试让Agent在执行完每一步之后停下来检查结果再进入下一步。这个回退机制看起来会减慢速度但对长时程任务的稳定性提升非常大。校验可以用规则也可以用模型。格式类校验用规则更可靠比如JSON字段是否完整、文件是否存在、数字格式是否正确。语义类校验可以用模型比如“摘要是否覆盖了用户指定的三个要点”。校验发现问题后不要让Agent直接继续而是把错误信息拼接回提示词让它基于反馈修复。这个过程中要控制重试次数一般2到3次比较合理超过次数就停止并记录日志避免进入死循环。注意不要一上来就开最大并发。长时程任务一旦进入并发日志、重试、资源占用都会成倍放大先单任务跑稳再考虑批量。4.4 工程兜底日志、断点、可复现性工程化落地时模型推理只是其中一环。长时间运行的任务还需要考虑日志、断点和可复现性。日志需要记录每一次模型调用的输入输出、耗时、Token消耗、错误类型。断点续跑也很关键如果任务执行到一半因为网络问题失败最好能从失败的子目标重新开始而不是从头执行整个任务。可复现性同样重要。相同输入、相同模型版本、相同参数结果要尽量稳定。如果模型输出随机性太大任务稍微变长就会变得不可控。这时可以适当降低温度参数或通过模型蒸馏、模型融合等方式固定一部分推理行为让整个流程更可控。5. 评测结论的边界以及最容易出现的误读5.1 评测场景不同27.3%未必代表你的业务场景长时程任务评测的结论依赖任务设计和环境设定。如果任务主要是网页操作模型对网页DOM的理解能力就会显著影响成绩如果任务主要是代码仓库级改动那么上下文长度和工具调用能力就更关键。所以不要看到27.3%就直接得出结论AI在长时程任务上完全不能用。更合理的做法是把你的业务场景拆成类似的最小任务自己跑一遍看模型在你的领域、你的工具链、你的输入输出格式下能拿到多少分。评测结论更适合用来理解趋势和定位瓶颈而不是直接照搬成自己项目的判断标准。5.2 模型不好用可能只是交互协议不合适有时候模型在评测里表现差不是模型本身不行而是任务给模型的交互协议太差。比如工具参数里混入了大量无关字段或者提示词没有说明环境里有哪些可用操作或者反馈信息里全是错误码而没有可读描述。这类问题在工程上完全可以通过优化协议来解决。给模型更清晰的工具使用说明把错误信息翻译成人能读懂的语句在调用前先对输入做格式校验这些做法不会提升模型的推理上限但会显著提高任务成功率。5.3 低分不等于不可用而是使用方式需要调整长时程任务分数低不意味着“AI不能用于复杂工作”。它更直接的含义是不能把一个完整长任务直接扔给模型期待它像人一样全权负责。真实项目里更稳妥的做法是“人机协同”或“分段接管”。把任务拆成多个相对独立的阶段阶段之间由人类或规则做校验模型只负责其中一部分。也可以让模型生成候选方案再由另一层校验逻辑筛选而不是让模型一次性输出最终结果。5.4 下一步关注什么从能力提升角度看长时程任务的下一个突破点大概率不在单模型规模上而在两个方向一是记忆和规划的结合。模型需要更稳定的外部记忆机制而不是把所有信息都压在上下文里。二是世界模型和真实环境的对齐。所谓“世界模型”通俗理解就是模型对任务环境、工具效果和后果的预期。如果模型能更好地理解环境变化规划和执行的成功率都会提升。模型蒸馏和模型融合在长任务场景里的意义也在于此它们可以让一个更小的模型从强模型中学习到稳定的任务执行习惯减少推理过程中的不确定性不过落地时仍然要针对具体任务做评测避免只看单点指标。6. 几个给团队的实际建议6.1 先跑最小可复现任务再决定要不要上Agent很多团队上来就希望Agent直接处理完整业务流这不是不行但风险高排障也困难。我更建议先跑一个最小可复现任务用10到20个步骤以内的规模确认模型能稳定完成核心路径再做扩展。这个最小任务要能反映你的业务特点。如果你的业务主要是信息整合就做“搜索加整理加汇总”任务如果主要是操作流程就做“读取状态加调用接口加返回结果”任务。跑通之后再逐步增加边界条件和异常场景。6.2 记录失败点不只看最终成功或失败跑长时程任务时我习惯把所有失败点记录下来按类型归类。格式错误、工具调用错误、上下文遗漏、目标漂移、超时每种问题的处理方式完全不同。记录失败点还有一个好处能发现模型在哪些子目标上稳定失败。如果同样的场景和工具模型连续多次在同一个环节出错那大概率不是运气问题而是这个环节的提示词、参数定义或环境反馈设计有缺陷。这时优先优化环节而不是换模型重跑。6.3 建立自己的评测集跟随任务难度迭代通用评测结果只能作为参考长期使用还是要建立自己的评测集。评测集不需要太大但要有代表性。阶段评测任务特点建议规模起步验证单点能力、基础工具调用10到20条核心流程多步骤任务、格式约束、错误恢复50条左右对比选型批量运行、稳定性对比、并发验证100条以上评测集要跟随任务难度迭代。新发现一个容易出错的场景就把它加入评测集。换模型、调参数、改提示词之后先跑一遍评测集用数据判断是变好还是变差。最后留几个我自己排查时会优先看的点输入格式和路径是否干净上下文里的关键约束有没有被后续内容冲淡失败时的环境反馈是否可读以及工具接口的参数定义是否符合模型的理解习惯。很多时候长时程任务跑不好不是模型不够聪明而是整个执行链路里还缺校准器和检查点。先把这些补上再谈模型能力上限会更有意义。