长程任务正在成为 AI 评测的新分水岭。很多开发者已经发现模型在单轮问答、代码补全、知识测验里表现惊艳但一旦让它独立完成一个多步骤、跨文件、需要持续跟踪状态的任务结果就变得不可控。最近一份关于长程任务基准的评测结果把这个感知变成了一个触目惊心的数字前沿模型的平均通过率只有 6.4%。这个数字值得每一个正在做 Agent 应用、自动化流程、智能编程助手的人认真看一遍。它不是又一个刷分的 benchmark而是把“模型能不能真正把事情办成”这个关键问题摆到了台面上。今天这篇文章我会拆解这个 6.4% 是怎么测出来的它到底反映了模型哪一层能力的缺失以及对我们日常开发 Agent 应用有什么直接影响。1. 6.4% 通过率到底意味着什么先说结论这不是模型“变笨了”而是我们过去对模型能力的度量方式出了问题。过去几年我们习惯了用各种单轮基准去衡量模型——你问一个问题模型给一个答案对了就得分。这种方式测的是“知识量”和“单步推理能力”。但在真实的生产环境里AI 要承担的任务几乎都是长程的从理解需求到拆解步骤从读取文件到修改代码从运行测试到根据报错迭代修复中间隔着几十个决策点。长程任务基准做的就是这件事给模型一个完整的目标让它自己去规划、执行、纠错最后看它能不能把结果交付出来。平均通过率 6.4% 意味着什么呢意味着哪怕是最顶尖的模型在跨越多步骤、需要持续跟踪上下文和中间状态的任务上成功率也低得惊人。每 100 个任务里能从头到尾完整交付的不到 7 个。这里要特别强调一个被很多人混淆的概念上下文长度不等于长程能力。现在不少模型支持 200K 甚至 1M token 的上下文窗口但这只代表模型“能读进去”多少信息不 represents 它“能处理好”多长的任务链条。长程任务的难点不在记忆量而在状态管理、错误恢复和规划稳定性。如果把单轮问答比作“回答一道题”长程任务就是“完成一个项目”。前者考察知识储备后者考察工程能力。6.4% 这个数字告诉我们当前模型的知识储备已经很惊人但工程能力还处在非常早期的阶段。这也解释了一个开发者的普遍困惑为什么我测试单个 Agent 功能时一切正常一旦把多个功能串成一个完整流程问题就层出不穷。不是你的代码写错了而是模型的长程任务能力本身就是当前最大的瓶颈。2. 长程任务基准的核心概念与评测逻辑要理解 6.4% 这个数字必须先搞清楚长程任务基准测的到底是什么。它不是把几个短任务简单拼接而是构建了一套完整的任务体系来模拟真实工作场景。2.1 什么才是真正的长程任务很多人以为多轮对话就是长程任务这是最常见的误解。用户在聊天窗口里连续问三五个问题模型依次回答这不是长程任务。真正的长程任务至少具备四个特征第一目标单一但路径复杂。任务有一个明确的最终交付物但中间没有预设好的执行路径模型需要自己决定先做什么、后做什么。第二步骤之间存在依赖关系。后一步的正确执行依赖前一步的输出中间任何一步出错都会向后续环节传导。这种错误累积特性是长程任务和短任务最本质的区别。第三需要持续追踪状态。模型必须记住自己做到哪一步、已经完成了什么、还缺什么。这种状态既包括任务进度也包括跨步骤的约束条件。第四存在中途纠错的可能。真实任务不可能一帆风顺模型需要能识别“当前路径走不通”然后回到正确的岔路口重新规划。2.2 任务类型的划分方式从当前评测趋势看长程任务基准的题目通常覆盖几大类任务类别典型场景核心考察点软件开发类从 issue 描述到代码实现、测试通过代码理解、多文件修改、错误修复数据分析类从原始数据到清洗、分析、出报告步骤编排、中间结果校验研究调研类从开放问题到信息收集、整理成文长文本理解、信息整合、结构规划自动化操作类从任务描述到调用多个工具完成操作工具选择、参数传递、状态管理内容生产类从选题到素材收集、多轮修改、终稿需求对齐、迭代反馈、一致性保持这些任务的特点是一致的都要求模型具备“从零到一做完一件事”的能力而不只是“回答一个问题”。2.3 通过率的判定标准这是评测里最关键的环节。长程任务的通过不是“模型生成了一大段看起来合理的内容”就算过而是有严格的交付判定。通常包含三个层面的检查最终交付物是否满足任务要求、中间过程是否合理、是否触碰了不该触碰的边界。以软件开发类任务为例判定标准不是模型写出来的代码风格好不好而是代码能否通过预置的测试用例、是否解决了 issue 中描述的 bug。这种判定标准下6.4% 的通过率就显得格外真实。它不是一个“接近及格”的分数而是一个“绝大多数任务无法完整交付”的残酷事实。2.4 和传统基准的对比传统基准和长程任务基准的本质区别可以这样理解传统基准是“闭卷考试”考察的是模型记住了多少知识长程任务基准是“项目答辩”考察的是模型能不能把一个项目从头做到尾。考试考得好不代表项目做得好。这中间的差距就是当前前沿模型表现出的核心短板。传统单轮评测的高分掩盖了模型在任务执行层面的不成熟。这也是为什么大家越来越意识到单轮评测的分数已经不能作为 Agent 能力的可靠参考指标了。3. 前沿模型为什么在长程任务上集体翻车6.4% 的通过率不是偶然的。从技术机制上看当前大模型在长程任务上有几个系统性的短板这些短板叠加在一起才造成了如此低的结果。3.1 信息遗忘与注意力稀释这是最基础但也最致命的问题。长程任务意味着模型要在很长的上下文里工作但 Transformer 架构的注意力机制对早期信息的保持能力是有限的。当任务进行到第 20 步时第 1 步的约束条件可能已经被后续的大量中间信息稀释掉了。更麻烦的是长程任务里的信息不是均匀分布的。一个关键的约束条件可能只出现在任务初始描述中的一句话里但后续所有步骤都要受它的约束。模型很容易在任务中途“忘记”这个早期约束导致最终交付物偏离需求。这种遗忘和人类的遗忘很不一样。人类可以用笔记、待办清单来对抗遗忘但模型必须完全依赖上下文中的信息。一旦超出有效注意力范围它不会主动去“翻看前面的记录”而是会基于当前已有的信息强行推理从而产生偏离。3.2 错误累积与缺乏自检机制短任务里模型的单步错误很快就能被发现因为最终结果很容易验证。但长任务里一个微小偏差会像一个滚雪球一样越滚越大。举个具体场景假设一个代码生成任务需要模型完成 5 个函数的实现。如果第 2 个函数的参数定义错了模型在第 4 个函数调用它时就会基于错误的接口继续写代码。如果没有主动的自检机制模型不会发现第 2 步的错误只会沿着错误的方向一路写下去。更麻烦的是模型本身缺少“我可能错了”的元认知能力。在生成每一段中间结果时它不会主动评估这段结果的正确性。这就导致一个现象长程任务的最终失败往往不是由于最后几步出了大问题而是早期的小错误被不断放大。3.3 规划能力与执行能力的脱节理想的长程任务执行者应该先有一个完整的全局规划再逐步执行。但当前的模型在规划时就已经暴露出问题。一方面模型生成规划时往往偏向于“看起来很合理”的通用步骤而不是针对具体任务定制的精确路径。这种通用规划在任务遇到实际情况偏离规划时缺乏足够的应变能力。另一方面模型的执行过程很容易“走一步看一步”缺乏对全局进度的掌控感。它可能在某一个子任务上耗费了大量上下文和步骤却没有意识到整个任务的剩余部分已经被挤压得没有空间了。这种规划和执行的脱节导致模型在长任务里经常出现“中期发力过猛、后期草草收尾”的现象。任务前半段质量不错后半段为了凑完结果而牺牲质量。3.4 工具调用链路的断裂在 Agent 类应用中长程任务几乎必然涉及多次工具调用。而每次工具调用的结果都会改变后续的执行环境这就引出了一个新的难点工具调用链路的连续性。模型在这次工具调用后返回的结果需要被正确地整合进全局上下文并在下一次工具调用时正确引用。这个链条只要断一次整个任务就废了。例如Agent 需要先创建一个文件然后往文件里写入代码然后运行测试最后读取测试结果。任何一个环节的返回值没有被正确传递后续环节都会基于错误的前提继续执行。从评测结果来看这种链路断裂是当前长程任务失败的高发原因之一。3.5 评判标准导致的高失败率最后还要考虑到长程任务基准的评判标准本身比传统基准严格得多。传统基准允许模型“部分正确”——只要最终答案接近就能得分。长程任务基准通常不允许这种模糊任务完成就是完成没完成就是没完成。一个需要 20 步的任务哪怕模型做对了前 19 步最后一步方向错了整个任务也是失败的。这种 is 判定方式符合真实工作的逻辑但同时也让模型的失败率显得更高。它反映的不是模型的狡辩空间而是真实任务中对交付质量的硬性要求。4. 长程任务评测环境搭建与测试思路如果你也想验证自己使用的模型在长程任务上的表现或者想对比不同模型的长程能力完全可以搭一个轻量级的评测环境。下面这套方案不需要复杂的平台用 Python 和主流模型 API 就能跑起来。4.1 环境准备建议的软件环境如下Python 3.10 或以上版本OpenAI SDK 或兼容 OpenAI 协议的各家 SDK一个支持长上下文的模型 API版本以实际项目为准Git 用于管理测试代码这里要特别说明不同模型的 API 兼容性不同但大多数主流模型服务商都提供 OpenAI 兼容接口。如果你的模型服务商支持这种协议可以直接复用下面的代码逻辑如果不支持只需要把消息构造和请求发送部分替换成对应 SDK 的写法即可。安装依赖pip install openai python-dotenv4.2 任务设计思路要测试长程任务能力不能拿简单的单轮问答来测。推荐的思路是设计一个需要多轮推理、多步骤执行、多文件操作的综合任务。这里给一个适合开发者自测的任务模板让模型基于一个需求描述完成一个完整的小型 Python 项目的开发包括项目结构设计、模块实现、单元测试编写最后要求运行测试并报告结果。这个任务天然具备长程特征设计阶段和编码阶段存在依赖关系代码实现需要跨多个文件测试结果会反过来要求修改代码模型需要自己决定技术栈和实现路径4.3 构造评测 Prompt下面是一段可以直接使用的评测 Prompt 模板你需要在 /tmp/longtask_demo 目录下完成一个 Python 项目。 项目需求 1. 实现一个处理日志文件的模块 log_parser.py支持读取文本日志、按级别过滤、输出统计信息。 2. 实现一个命令行入口 main.py接收日志文件路径和级别参数调用 log_parser 输出统计结果。 3. 编写 test_log_parser.py使用 pytest 覆盖正常输入、空文件和错误参数三类场景。 4. 运行所有测试并确保全部通过。 要求 - 使用标准库实现不引入第三方依赖。 - 每一步完成后先说明你做了什么、下一步要做什么。 - 遇到测试失败时分析原因后修复不要跳过。 - 最终需要给出测试运行结果。这个 Prompt 的特点是目标明确、步骤开放、强制要求过程说明和纠错反馈。模型在执行时会经过规划、编码、测试、修复的完整链路任何一环出问题都会导致最终失败。4.4 评测脚本的核心逻辑下面是一份精简但完整的评测脚本框架展示了如何自动构造任务、调用模型、校验结果import os import subprocess import json from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) TASK_PROMPT 你需要在 /tmp/longtask_demo 目录下完成一个 Python 项目。 ...此处粘贴上方完整 Prompt def run_long_task(model_name: str, max_steps: int 30) - dict: messages [ {role: system, content: 你是一个资深 Python 开发工程师擅长完成任务并主动检查结果。}, {role: user, content: TASK_PROMPT} ] for step in range(max_steps): response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0.2 ) assistant_msg response.choices[0].message.content messages.append({role: assistant, content: assistant_msg}) # 检查模型是否完成任务 if 测试全部通过 in assistant_msg or ALL TESTS PASSED in assistant_msg: return {status: completed, steps: step 1, messages: messages} # 将模型可能输出的命令或文件写入操作交给执行层处理 result execute_model_commands(assistant_msg) if result[needs_feedback]: messages.append({ role: user, content: f执行结果如下\n{result[feedback]}\n请继续。 }) return {status: timeout, steps: max_steps, messages: messages} def execute_model_commands(assistant_msg: str): # 解析模型输出中的命令执行后返回结果 # 实际项目中建议使用沙箱环境避免模型直接操作宿主机 feedback_parts [] # 这里省略具体命令解析逻辑 return {needs_feedback: True, feedback: \n.join(feedback_parts)} if __name__ __main__: result run_long_task(your-model-name) print(json.dumps(result, ensure_asciiFalse, indent2))这份脚本的核心思路是循环式执行模型生成内容后脚本解析其中的可执行操作将执行结果反馈给模型模型根据反馈决定下一步动作。这正是长程任务里“执行-反馈-修正”闭环的简化版。对于真实评测强烈建议把模型放进容器或沙箱环境运行避免模型生成的命令对宿主机产生不可控影响。5. 一个完整的长程任务评测示例下面用一个更完整的示例来说明整个评测流程。为了让示例可运行这里的任务缩小为“实现一个带测试的 Python 函数”但核心逻辑仍然覆盖了规划、编码、测试、修复的完整链路。5.1 任务定义文件首先定义一个任务配置 JSON方便批量扩展不同任务{ tasks: [ { id: task_001, name: 实现日期解析函数, description: 实现 parse_date 函数支持 YYYY-MM-DD、YYYY/MM/DD、YYYY年MM月DD日 三种格式并返回标准化的 datetime.date 对象。非法输入抛 ValueError。, test_file: tests/test_parse_date.py }, { id: task_002, name: 实现批量文件重命名, description: 实现 rename_files 函数接受目录路径和前缀参数将目录下所有 .txt 文件按序号重命名。需要考虑重名冲突。, test_file: tests/test_rename_files.py } ] }这种任务配置文件的好处是可以批量替换、批量评测适合做多模型对比实验。5.2 评测主程序import json import time from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) def evaluate_single_task(task: dict, model_name: str) - dict: start_time time.time() messages [ { role: system, content: 你是资深 Python 工程师。请根据任务描述先给出实现代码再给出测试代码最后运行测试并报告结果。 }, { role: user, content: ( f任务ID: {task[id]}\n f任务名称: {task[name]}\n f任务描述: {task[description]}\n f测试文件要求: {task[test_file]}\n\n 请严格按以下步骤执行\n 1. 分析任务需求列出实现要点。\n 2. 编写实现代码。\n 3. 编写测试代码。\n 4. 说明如何运行测试。\n 5. 预测可能出现的失败场景并给出应对策略。 ) } ] response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0.1 ) content response.choices[0].message.content elapsed time.time() - start_time # 交给测试执行器验证 result run_tests_from_content(task, content) return { task_id: task[id], model: model_name, elapsed: round(elapsed, 2), test_result: result } def run_tests_from_content(task: dict, content: str): # 真实评测时需要从模型输出中提取代码文件并写入沙箱执行 # 这里只做演示说明 has_implementation def in content has_test_code assert in content has_test_runner pytest in content or if __name__ in content passed all([has_implementation, has_test_code, has_test_runner]) return { passed: passed, checks: { has_implementation: has_implementation, has_test_code: has_test_code, has_test_runner: has_test_runner } } if __name__ __main__: with open(tasks.json, r, encodingutf-8) as f: tasks json.load(f)[tasks] model_name your-model-name for task in tasks: result evaluate_single_task(task, model_name) print(json.dumps(result, ensure_asciiFalse, indent2))5.3 运行命令export LLM_API_KEYyour-api-key export LLM_BASE_URLhttps://your-endpoint.example.com/v1 python evaluate_long_task.py运行结果会以 JSON 格式输出每个任务的测试判定。注意这里只是一个演示逻辑真实评测需要在沙箱环境里真正执行模型生成的代码并跑测试用例而不是只看字符串里有没有assert。6. 运行结果与判定标准在产品化评测中长程任务的结果判定远比上面演示的逻辑复杂。这里把判定链路拆开来看方便你做真实验证时参考。6.1 多阶段判定流程一个长程任务建议分三层判定第一层是过程完整性。检查模型是否完成了所有要求的步骤例如是否生成了实现文件、测试文件、是否执行了测试命令。这一步能过滤掉“只说不做”的模型输出。第二层是交付质量。运行模型生成的测试用例检查通过率检查代码是否满足任务描述中的功能要求检查是否存在明显的逻辑错误。如果测试全部通过再人工或自动抽查代码质量。第三层是过程合理性。检查模型是否在任务中途偏离了方向是否有不必要的绕路是否有大量无效尝试。这一步决定了一个任务是通过还是“勉强通过”。6.2 如何判定任务成功一个长程任务被判定为成功需要同时满足三个条件实现代码与任务描述完全匹配。注意“完全匹配”这个词长程任务不接受将就。任务要求支持三种日期格式模型只实现了两种就算失败。测试代码能真实评估实现。如果模型写了测试但测试根本没断言核心逻辑测试覆盖不到任务的正确性也不算通过。测试运行通过。这是硬指标测试失败就是任务失败不存在“代码看起来能跑但测试没过”的中间地带。6.3 失败排查的第一步原则如果某个模型在长程任务上失败了不要急着换模型或改 Prompt。先定位失败发生在哪个阶段如果模型生成的代码根本没法运行大概率是基础编码能力或对任务需求理解出了问题。如果代码能运行但测试失败重点是模型的调试和错误恢复能力。如果测试通过了但偏离了原始需求说明模型的长期目标跟踪能力不足。从评测趋势看长程任务失败往往集中在“测试失败后的修复环节”。很多模型在第一轮测试失败后会选择重写整个实现而不是定位具体错误点。这种“遇到错误就重来”的策略在短任务里可能有效但在长任务里会消耗大量上下文最终导致任务无法完成。7. 长程任务评测常见问题与排查方法问题现象可能原因排查方式解决方案模型中途忘记初始需求长上下文信息被稀释查看中间输出是否偏离原始任务描述要求模型在每步开始前复述当前目标和已完成步骤测试失败后反复重写代码缺乏定位错误的能力观察修复轮次是否在同一个错误点反复在 Prompt 中要求先分析错误信息再修改禁止直接重写任务步骤顺序混乱规划能力不足检查模型初始输出的步骤列表是否合理让模型先输出完整计划用户确认后再执行工具调用返回结果未被使用上下文整合能力弱检查工具返回值是否出现在后续消息中强制要求每轮工具调用后输出“根据返回结果下一步执行……”模型陷入无效循环缺乏终止条件判断统计同一操作的重复次数设置最大步数限制并在 Prompt 中声明“重复操作将被终止”最终交付物不完整长任务后期的上下文压缩导致信息丢失检查后半部分输出的代码是否明显变短建议任务拆分为多阶段每个阶段单独提需求在实际评测中你会发现模型的长程任务失败往往是多种原因叠加的结果。例如先是因为规划不合理导致步骤顺序混乱然后在执行过程中丢失了部分约束条件最后面对测试失败又选择了错误的修复策略。这提醒我们单点优化往往解决不了长程任务的全部问题需要多个环节同时改进。8. 从评测到落地长程 Agent 应用的工程建议6.4% 的通过率对一般开发者来说是一个预警信号如果要在生产环境里建设长任务 Agent不能指望模型一个人扛下所有事。评测暴露的短板需要在工程层面用设计去弥补。8.1 任务拆解优先不要盲目追求一次性完成评测结果已经表明模型在长任务上的失败率呈指数级增长。因此工程上最重要的一步是把长任务拆成多个短任务。拆解的原则是每个子任务有独立的输入和输出子任务之间有明确的状态传递接口每个子任务完成后都有验证步骤。比如一次 30 步的长任务拆成 5 个 6 步的子任务每完成一个子任务就做一次检查。这里要区分“任务长”和“上下文长”。拆解的目的不是缩短上下文而是引入检查点降低错误累积的风险。子任务之间建议通过结构化的中间产物传递状态——比如 JSON 文件、数据库记录——而不是只依赖对话历史。8.2 引入外部状态管理不要依赖模型记忆模型的长程任务能力弱核心原因之一是记忆不可靠。工程上不应该去苛求模型记住所有状态而是把状态管理从模型内部移到外部。推荐的做法是为任务维护一份独立的状态文件记录当前进度、已完成步骤、未完成事项、关键决策依据。模型每完成一步就把状态写入文件每开始一步先读取状态文件再继续。这种设计的好处是即使模型中途出现上下文漂移外部状态文件仍然保留着任务的正确轨迹。模型在下一轮可以根据状态文件重新校准自己的执行方向而不是基于模糊的记忆继续推进。8.3 关键节点强制验证长任务里最怕的是模型在错误的路径上越走越远。工程上应该在任务的关键节点加入强制验证。具体做法是在任务设计时定义每个阶段的验证条件和验收标准。比如“生成接口定义后验证字段完整性”“修改数据库表结构后执行迁移检查”“完成核心函数后先跑单测再继续开发”。模型必须通过当前节点的验证才能进入下一阶段。这相当于给任务的执行路径装上了“红绿灯”。模型可以在绿灯时自由驾驶但遇到红灯必须停下来修正。这种机制能有效阻断错误累积。8.4 为失败设计恢复路径评测显示当前模型在遇到失败后恢复能力明显不足。工程上不能假设模型永远不会出错而是要预设失败的恢复预案。针对不同失败类型设计不同的恢复策略如果是工具调用失败重试两次后仍然失败就切换备用工具如果是代码运行报错要求模型先解析错误日志再决定修改方案如果是任务需求理解偏差提供回到任务开始状态的快速通道。这些恢复策略在代码层面可以用异常处理、重试机制、备用路径来实现。核心思路是模型出错不可怕可怕的是没有定义出错后该怎么补救。8.5 评测度量要嵌入开发流程长程任务能力不是模型发布后才知道的而是在你选择模型、设计 Agent 架构时就应该评估的。建议把长程任务评测嵌入到技术选型和版本升级流程中。在你的 Agent 应用里维护一个标准长任务测试集每次更换模型版本时都跑一遍对比通过率。如果新版模型在短任务上分数提升但长任务通过率下降说明模型的能力分布发生了变化需要谨慎评估是否升级。这种评测成本不高但价值很大。它能避免你在生产环境中才发现新模型不擅长长任务从而减少不必要的线上事故。9. 总结与后续学习方向6.4% 这个数字应该被理解为行业对长程任务能力的一次体检报告。它说明当前前沿模型确实具备强大的单步能力但在持续多步的任务执行上距离“稳定的自动化和智能化”还有很长的路要走。对普通开发者这意味着现在做 Agent 类应用时必须在架构设计上多做一层思考不能直接把一个大任务丢给模型而是要设计好拆解、验证、状态管理和错误恢复机制。模型负责智能决策工程框架负责流程保障两者结合才能在真实任务中取得可用的成功率。如果你接下来想继续深入这一方向有几个值得关注的技术路径一是上下文工程。研究如何通过摘要、关键信息提取、结构化记忆等手段帮助模型在长任务中保持关键信息的可用性。二是评测方法论。学习如何构建更贴近真实场景的长程任务基准如何设计过程级和结果级相结合的评分体系如何避免评测中的伪成功。三是多智能体协作架构。把一个大任务分配给多个专家模型协作完成每个模型只负责自己擅长的步骤通过协议化接口互联减少单个模型承载长任务的负担。四是模型自身的训练目标优化。从数据层面增加长程任务样本从对齐层面优化模型的纠错和自省能力这需要更长远的投入但对整个行业意义重大。长程任务能力是 AI 从“回答者”走向“执行者”的必经门槛。6.4% 的通过率提醒我们这条路上还有大量的工程技术问题等待解决而这恰恰是开发者最大的机会所在。
长程任务基准揭示AI真实短板：前沿模型平均通过率仅6.4%
长程任务正在成为 AI 评测的新分水岭。很多开发者已经发现模型在单轮问答、代码补全、知识测验里表现惊艳但一旦让它独立完成一个多步骤、跨文件、需要持续跟踪状态的任务结果就变得不可控。最近一份关于长程任务基准的评测结果把这个感知变成了一个触目惊心的数字前沿模型的平均通过率只有 6.4%。这个数字值得每一个正在做 Agent 应用、自动化流程、智能编程助手的人认真看一遍。它不是又一个刷分的 benchmark而是把“模型能不能真正把事情办成”这个关键问题摆到了台面上。今天这篇文章我会拆解这个 6.4% 是怎么测出来的它到底反映了模型哪一层能力的缺失以及对我们日常开发 Agent 应用有什么直接影响。1. 6.4% 通过率到底意味着什么先说结论这不是模型“变笨了”而是我们过去对模型能力的度量方式出了问题。过去几年我们习惯了用各种单轮基准去衡量模型——你问一个问题模型给一个答案对了就得分。这种方式测的是“知识量”和“单步推理能力”。但在真实的生产环境里AI 要承担的任务几乎都是长程的从理解需求到拆解步骤从读取文件到修改代码从运行测试到根据报错迭代修复中间隔着几十个决策点。长程任务基准做的就是这件事给模型一个完整的目标让它自己去规划、执行、纠错最后看它能不能把结果交付出来。平均通过率 6.4% 意味着什么呢意味着哪怕是最顶尖的模型在跨越多步骤、需要持续跟踪上下文和中间状态的任务上成功率也低得惊人。每 100 个任务里能从头到尾完整交付的不到 7 个。这里要特别强调一个被很多人混淆的概念上下文长度不等于长程能力。现在不少模型支持 200K 甚至 1M token 的上下文窗口但这只代表模型“能读进去”多少信息不 represents 它“能处理好”多长的任务链条。长程任务的难点不在记忆量而在状态管理、错误恢复和规划稳定性。如果把单轮问答比作“回答一道题”长程任务就是“完成一个项目”。前者考察知识储备后者考察工程能力。6.4% 这个数字告诉我们当前模型的知识储备已经很惊人但工程能力还处在非常早期的阶段。这也解释了一个开发者的普遍困惑为什么我测试单个 Agent 功能时一切正常一旦把多个功能串成一个完整流程问题就层出不穷。不是你的代码写错了而是模型的长程任务能力本身就是当前最大的瓶颈。2. 长程任务基准的核心概念与评测逻辑要理解 6.4% 这个数字必须先搞清楚长程任务基准测的到底是什么。它不是把几个短任务简单拼接而是构建了一套完整的任务体系来模拟真实工作场景。2.1 什么才是真正的长程任务很多人以为多轮对话就是长程任务这是最常见的误解。用户在聊天窗口里连续问三五个问题模型依次回答这不是长程任务。真正的长程任务至少具备四个特征第一目标单一但路径复杂。任务有一个明确的最终交付物但中间没有预设好的执行路径模型需要自己决定先做什么、后做什么。第二步骤之间存在依赖关系。后一步的正确执行依赖前一步的输出中间任何一步出错都会向后续环节传导。这种错误累积特性是长程任务和短任务最本质的区别。第三需要持续追踪状态。模型必须记住自己做到哪一步、已经完成了什么、还缺什么。这种状态既包括任务进度也包括跨步骤的约束条件。第四存在中途纠错的可能。真实任务不可能一帆风顺模型需要能识别“当前路径走不通”然后回到正确的岔路口重新规划。2.2 任务类型的划分方式从当前评测趋势看长程任务基准的题目通常覆盖几大类任务类别典型场景核心考察点软件开发类从 issue 描述到代码实现、测试通过代码理解、多文件修改、错误修复数据分析类从原始数据到清洗、分析、出报告步骤编排、中间结果校验研究调研类从开放问题到信息收集、整理成文长文本理解、信息整合、结构规划自动化操作类从任务描述到调用多个工具完成操作工具选择、参数传递、状态管理内容生产类从选题到素材收集、多轮修改、终稿需求对齐、迭代反馈、一致性保持这些任务的特点是一致的都要求模型具备“从零到一做完一件事”的能力而不只是“回答一个问题”。2.3 通过率的判定标准这是评测里最关键的环节。长程任务的通过不是“模型生成了一大段看起来合理的内容”就算过而是有严格的交付判定。通常包含三个层面的检查最终交付物是否满足任务要求、中间过程是否合理、是否触碰了不该触碰的边界。以软件开发类任务为例判定标准不是模型写出来的代码风格好不好而是代码能否通过预置的测试用例、是否解决了 issue 中描述的 bug。这种判定标准下6.4% 的通过率就显得格外真实。它不是一个“接近及格”的分数而是一个“绝大多数任务无法完整交付”的残酷事实。2.4 和传统基准的对比传统基准和长程任务基准的本质区别可以这样理解传统基准是“闭卷考试”考察的是模型记住了多少知识长程任务基准是“项目答辩”考察的是模型能不能把一个项目从头做到尾。考试考得好不代表项目做得好。这中间的差距就是当前前沿模型表现出的核心短板。传统单轮评测的高分掩盖了模型在任务执行层面的不成熟。这也是为什么大家越来越意识到单轮评测的分数已经不能作为 Agent 能力的可靠参考指标了。3. 前沿模型为什么在长程任务上集体翻车6.4% 的通过率不是偶然的。从技术机制上看当前大模型在长程任务上有几个系统性的短板这些短板叠加在一起才造成了如此低的结果。3.1 信息遗忘与注意力稀释这是最基础但也最致命的问题。长程任务意味着模型要在很长的上下文里工作但 Transformer 架构的注意力机制对早期信息的保持能力是有限的。当任务进行到第 20 步时第 1 步的约束条件可能已经被后续的大量中间信息稀释掉了。更麻烦的是长程任务里的信息不是均匀分布的。一个关键的约束条件可能只出现在任务初始描述中的一句话里但后续所有步骤都要受它的约束。模型很容易在任务中途“忘记”这个早期约束导致最终交付物偏离需求。这种遗忘和人类的遗忘很不一样。人类可以用笔记、待办清单来对抗遗忘但模型必须完全依赖上下文中的信息。一旦超出有效注意力范围它不会主动去“翻看前面的记录”而是会基于当前已有的信息强行推理从而产生偏离。3.2 错误累积与缺乏自检机制短任务里模型的单步错误很快就能被发现因为最终结果很容易验证。但长任务里一个微小偏差会像一个滚雪球一样越滚越大。举个具体场景假设一个代码生成任务需要模型完成 5 个函数的实现。如果第 2 个函数的参数定义错了模型在第 4 个函数调用它时就会基于错误的接口继续写代码。如果没有主动的自检机制模型不会发现第 2 步的错误只会沿着错误的方向一路写下去。更麻烦的是模型本身缺少“我可能错了”的元认知能力。在生成每一段中间结果时它不会主动评估这段结果的正确性。这就导致一个现象长程任务的最终失败往往不是由于最后几步出了大问题而是早期的小错误被不断放大。3.3 规划能力与执行能力的脱节理想的长程任务执行者应该先有一个完整的全局规划再逐步执行。但当前的模型在规划时就已经暴露出问题。一方面模型生成规划时往往偏向于“看起来很合理”的通用步骤而不是针对具体任务定制的精确路径。这种通用规划在任务遇到实际情况偏离规划时缺乏足够的应变能力。另一方面模型的执行过程很容易“走一步看一步”缺乏对全局进度的掌控感。它可能在某一个子任务上耗费了大量上下文和步骤却没有意识到整个任务的剩余部分已经被挤压得没有空间了。这种规划和执行的脱节导致模型在长任务里经常出现“中期发力过猛、后期草草收尾”的现象。任务前半段质量不错后半段为了凑完结果而牺牲质量。3.4 工具调用链路的断裂在 Agent 类应用中长程任务几乎必然涉及多次工具调用。而每次工具调用的结果都会改变后续的执行环境这就引出了一个新的难点工具调用链路的连续性。模型在这次工具调用后返回的结果需要被正确地整合进全局上下文并在下一次工具调用时正确引用。这个链条只要断一次整个任务就废了。例如Agent 需要先创建一个文件然后往文件里写入代码然后运行测试最后读取测试结果。任何一个环节的返回值没有被正确传递后续环节都会基于错误的前提继续执行。从评测结果来看这种链路断裂是当前长程任务失败的高发原因之一。3.5 评判标准导致的高失败率最后还要考虑到长程任务基准的评判标准本身比传统基准严格得多。传统基准允许模型“部分正确”——只要最终答案接近就能得分。长程任务基准通常不允许这种模糊任务完成就是完成没完成就是没完成。一个需要 20 步的任务哪怕模型做对了前 19 步最后一步方向错了整个任务也是失败的。这种 is 判定方式符合真实工作的逻辑但同时也让模型的失败率显得更高。它反映的不是模型的狡辩空间而是真实任务中对交付质量的硬性要求。4. 长程任务评测环境搭建与测试思路如果你也想验证自己使用的模型在长程任务上的表现或者想对比不同模型的长程能力完全可以搭一个轻量级的评测环境。下面这套方案不需要复杂的平台用 Python 和主流模型 API 就能跑起来。4.1 环境准备建议的软件环境如下Python 3.10 或以上版本OpenAI SDK 或兼容 OpenAI 协议的各家 SDK一个支持长上下文的模型 API版本以实际项目为准Git 用于管理测试代码这里要特别说明不同模型的 API 兼容性不同但大多数主流模型服务商都提供 OpenAI 兼容接口。如果你的模型服务商支持这种协议可以直接复用下面的代码逻辑如果不支持只需要把消息构造和请求发送部分替换成对应 SDK 的写法即可。安装依赖pip install openai python-dotenv4.2 任务设计思路要测试长程任务能力不能拿简单的单轮问答来测。推荐的思路是设计一个需要多轮推理、多步骤执行、多文件操作的综合任务。这里给一个适合开发者自测的任务模板让模型基于一个需求描述完成一个完整的小型 Python 项目的开发包括项目结构设计、模块实现、单元测试编写最后要求运行测试并报告结果。这个任务天然具备长程特征设计阶段和编码阶段存在依赖关系代码实现需要跨多个文件测试结果会反过来要求修改代码模型需要自己决定技术栈和实现路径4.3 构造评测 Prompt下面是一段可以直接使用的评测 Prompt 模板你需要在 /tmp/longtask_demo 目录下完成一个 Python 项目。 项目需求 1. 实现一个处理日志文件的模块 log_parser.py支持读取文本日志、按级别过滤、输出统计信息。 2. 实现一个命令行入口 main.py接收日志文件路径和级别参数调用 log_parser 输出统计结果。 3. 编写 test_log_parser.py使用 pytest 覆盖正常输入、空文件和错误参数三类场景。 4. 运行所有测试并确保全部通过。 要求 - 使用标准库实现不引入第三方依赖。 - 每一步完成后先说明你做了什么、下一步要做什么。 - 遇到测试失败时分析原因后修复不要跳过。 - 最终需要给出测试运行结果。这个 Prompt 的特点是目标明确、步骤开放、强制要求过程说明和纠错反馈。模型在执行时会经过规划、编码、测试、修复的完整链路任何一环出问题都会导致最终失败。4.4 评测脚本的核心逻辑下面是一份精简但完整的评测脚本框架展示了如何自动构造任务、调用模型、校验结果import os import subprocess import json from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) TASK_PROMPT 你需要在 /tmp/longtask_demo 目录下完成一个 Python 项目。 ...此处粘贴上方完整 Prompt def run_long_task(model_name: str, max_steps: int 30) - dict: messages [ {role: system, content: 你是一个资深 Python 开发工程师擅长完成任务并主动检查结果。}, {role: user, content: TASK_PROMPT} ] for step in range(max_steps): response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0.2 ) assistant_msg response.choices[0].message.content messages.append({role: assistant, content: assistant_msg}) # 检查模型是否完成任务 if 测试全部通过 in assistant_msg or ALL TESTS PASSED in assistant_msg: return {status: completed, steps: step 1, messages: messages} # 将模型可能输出的命令或文件写入操作交给执行层处理 result execute_model_commands(assistant_msg) if result[needs_feedback]: messages.append({ role: user, content: f执行结果如下\n{result[feedback]}\n请继续。 }) return {status: timeout, steps: max_steps, messages: messages} def execute_model_commands(assistant_msg: str): # 解析模型输出中的命令执行后返回结果 # 实际项目中建议使用沙箱环境避免模型直接操作宿主机 feedback_parts [] # 这里省略具体命令解析逻辑 return {needs_feedback: True, feedback: \n.join(feedback_parts)} if __name__ __main__: result run_long_task(your-model-name) print(json.dumps(result, ensure_asciiFalse, indent2))这份脚本的核心思路是循环式执行模型生成内容后脚本解析其中的可执行操作将执行结果反馈给模型模型根据反馈决定下一步动作。这正是长程任务里“执行-反馈-修正”闭环的简化版。对于真实评测强烈建议把模型放进容器或沙箱环境运行避免模型生成的命令对宿主机产生不可控影响。5. 一个完整的长程任务评测示例下面用一个更完整的示例来说明整个评测流程。为了让示例可运行这里的任务缩小为“实现一个带测试的 Python 函数”但核心逻辑仍然覆盖了规划、编码、测试、修复的完整链路。5.1 任务定义文件首先定义一个任务配置 JSON方便批量扩展不同任务{ tasks: [ { id: task_001, name: 实现日期解析函数, description: 实现 parse_date 函数支持 YYYY-MM-DD、YYYY/MM/DD、YYYY年MM月DD日 三种格式并返回标准化的 datetime.date 对象。非法输入抛 ValueError。, test_file: tests/test_parse_date.py }, { id: task_002, name: 实现批量文件重命名, description: 实现 rename_files 函数接受目录路径和前缀参数将目录下所有 .txt 文件按序号重命名。需要考虑重名冲突。, test_file: tests/test_rename_files.py } ] }这种任务配置文件的好处是可以批量替换、批量评测适合做多模型对比实验。5.2 评测主程序import json import time from openai import OpenAI client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL) ) def evaluate_single_task(task: dict, model_name: str) - dict: start_time time.time() messages [ { role: system, content: 你是资深 Python 工程师。请根据任务描述先给出实现代码再给出测试代码最后运行测试并报告结果。 }, { role: user, content: ( f任务ID: {task[id]}\n f任务名称: {task[name]}\n f任务描述: {task[description]}\n f测试文件要求: {task[test_file]}\n\n 请严格按以下步骤执行\n 1. 分析任务需求列出实现要点。\n 2. 编写实现代码。\n 3. 编写测试代码。\n 4. 说明如何运行测试。\n 5. 预测可能出现的失败场景并给出应对策略。 ) } ] response client.chat.completions.create( modelmodel_name, messagesmessages, temperature0.1 ) content response.choices[0].message.content elapsed time.time() - start_time # 交给测试执行器验证 result run_tests_from_content(task, content) return { task_id: task[id], model: model_name, elapsed: round(elapsed, 2), test_result: result } def run_tests_from_content(task: dict, content: str): # 真实评测时需要从模型输出中提取代码文件并写入沙箱执行 # 这里只做演示说明 has_implementation def in content has_test_code assert in content has_test_runner pytest in content or if __name__ in content passed all([has_implementation, has_test_code, has_test_runner]) return { passed: passed, checks: { has_implementation: has_implementation, has_test_code: has_test_code, has_test_runner: has_test_runner } } if __name__ __main__: with open(tasks.json, r, encodingutf-8) as f: tasks json.load(f)[tasks] model_name your-model-name for task in tasks: result evaluate_single_task(task, model_name) print(json.dumps(result, ensure_asciiFalse, indent2))5.3 运行命令export LLM_API_KEYyour-api-key export LLM_BASE_URLhttps://your-endpoint.example.com/v1 python evaluate_long_task.py运行结果会以 JSON 格式输出每个任务的测试判定。注意这里只是一个演示逻辑真实评测需要在沙箱环境里真正执行模型生成的代码并跑测试用例而不是只看字符串里有没有assert。6. 运行结果与判定标准在产品化评测中长程任务的结果判定远比上面演示的逻辑复杂。这里把判定链路拆开来看方便你做真实验证时参考。6.1 多阶段判定流程一个长程任务建议分三层判定第一层是过程完整性。检查模型是否完成了所有要求的步骤例如是否生成了实现文件、测试文件、是否执行了测试命令。这一步能过滤掉“只说不做”的模型输出。第二层是交付质量。运行模型生成的测试用例检查通过率检查代码是否满足任务描述中的功能要求检查是否存在明显的逻辑错误。如果测试全部通过再人工或自动抽查代码质量。第三层是过程合理性。检查模型是否在任务中途偏离了方向是否有不必要的绕路是否有大量无效尝试。这一步决定了一个任务是通过还是“勉强通过”。6.2 如何判定任务成功一个长程任务被判定为成功需要同时满足三个条件实现代码与任务描述完全匹配。注意“完全匹配”这个词长程任务不接受将就。任务要求支持三种日期格式模型只实现了两种就算失败。测试代码能真实评估实现。如果模型写了测试但测试根本没断言核心逻辑测试覆盖不到任务的正确性也不算通过。测试运行通过。这是硬指标测试失败就是任务失败不存在“代码看起来能跑但测试没过”的中间地带。6.3 失败排查的第一步原则如果某个模型在长程任务上失败了不要急着换模型或改 Prompt。先定位失败发生在哪个阶段如果模型生成的代码根本没法运行大概率是基础编码能力或对任务需求理解出了问题。如果代码能运行但测试失败重点是模型的调试和错误恢复能力。如果测试通过了但偏离了原始需求说明模型的长期目标跟踪能力不足。从评测趋势看长程任务失败往往集中在“测试失败后的修复环节”。很多模型在第一轮测试失败后会选择重写整个实现而不是定位具体错误点。这种“遇到错误就重来”的策略在短任务里可能有效但在长任务里会消耗大量上下文最终导致任务无法完成。7. 长程任务评测常见问题与排查方法问题现象可能原因排查方式解决方案模型中途忘记初始需求长上下文信息被稀释查看中间输出是否偏离原始任务描述要求模型在每步开始前复述当前目标和已完成步骤测试失败后反复重写代码缺乏定位错误的能力观察修复轮次是否在同一个错误点反复在 Prompt 中要求先分析错误信息再修改禁止直接重写任务步骤顺序混乱规划能力不足检查模型初始输出的步骤列表是否合理让模型先输出完整计划用户确认后再执行工具调用返回结果未被使用上下文整合能力弱检查工具返回值是否出现在后续消息中强制要求每轮工具调用后输出“根据返回结果下一步执行……”模型陷入无效循环缺乏终止条件判断统计同一操作的重复次数设置最大步数限制并在 Prompt 中声明“重复操作将被终止”最终交付物不完整长任务后期的上下文压缩导致信息丢失检查后半部分输出的代码是否明显变短建议任务拆分为多阶段每个阶段单独提需求在实际评测中你会发现模型的长程任务失败往往是多种原因叠加的结果。例如先是因为规划不合理导致步骤顺序混乱然后在执行过程中丢失了部分约束条件最后面对测试失败又选择了错误的修复策略。这提醒我们单点优化往往解决不了长程任务的全部问题需要多个环节同时改进。8. 从评测到落地长程 Agent 应用的工程建议6.4% 的通过率对一般开发者来说是一个预警信号如果要在生产环境里建设长任务 Agent不能指望模型一个人扛下所有事。评测暴露的短板需要在工程层面用设计去弥补。8.1 任务拆解优先不要盲目追求一次性完成评测结果已经表明模型在长任务上的失败率呈指数级增长。因此工程上最重要的一步是把长任务拆成多个短任务。拆解的原则是每个子任务有独立的输入和输出子任务之间有明确的状态传递接口每个子任务完成后都有验证步骤。比如一次 30 步的长任务拆成 5 个 6 步的子任务每完成一个子任务就做一次检查。这里要区分“任务长”和“上下文长”。拆解的目的不是缩短上下文而是引入检查点降低错误累积的风险。子任务之间建议通过结构化的中间产物传递状态——比如 JSON 文件、数据库记录——而不是只依赖对话历史。8.2 引入外部状态管理不要依赖模型记忆模型的长程任务能力弱核心原因之一是记忆不可靠。工程上不应该去苛求模型记住所有状态而是把状态管理从模型内部移到外部。推荐的做法是为任务维护一份独立的状态文件记录当前进度、已完成步骤、未完成事项、关键决策依据。模型每完成一步就把状态写入文件每开始一步先读取状态文件再继续。这种设计的好处是即使模型中途出现上下文漂移外部状态文件仍然保留着任务的正确轨迹。模型在下一轮可以根据状态文件重新校准自己的执行方向而不是基于模糊的记忆继续推进。8.3 关键节点强制验证长任务里最怕的是模型在错误的路径上越走越远。工程上应该在任务的关键节点加入强制验证。具体做法是在任务设计时定义每个阶段的验证条件和验收标准。比如“生成接口定义后验证字段完整性”“修改数据库表结构后执行迁移检查”“完成核心函数后先跑单测再继续开发”。模型必须通过当前节点的验证才能进入下一阶段。这相当于给任务的执行路径装上了“红绿灯”。模型可以在绿灯时自由驾驶但遇到红灯必须停下来修正。这种机制能有效阻断错误累积。8.4 为失败设计恢复路径评测显示当前模型在遇到失败后恢复能力明显不足。工程上不能假设模型永远不会出错而是要预设失败的恢复预案。针对不同失败类型设计不同的恢复策略如果是工具调用失败重试两次后仍然失败就切换备用工具如果是代码运行报错要求模型先解析错误日志再决定修改方案如果是任务需求理解偏差提供回到任务开始状态的快速通道。这些恢复策略在代码层面可以用异常处理、重试机制、备用路径来实现。核心思路是模型出错不可怕可怕的是没有定义出错后该怎么补救。8.5 评测度量要嵌入开发流程长程任务能力不是模型发布后才知道的而是在你选择模型、设计 Agent 架构时就应该评估的。建议把长程任务评测嵌入到技术选型和版本升级流程中。在你的 Agent 应用里维护一个标准长任务测试集每次更换模型版本时都跑一遍对比通过率。如果新版模型在短任务上分数提升但长任务通过率下降说明模型的能力分布发生了变化需要谨慎评估是否升级。这种评测成本不高但价值很大。它能避免你在生产环境中才发现新模型不擅长长任务从而减少不必要的线上事故。9. 总结与后续学习方向6.4% 这个数字应该被理解为行业对长程任务能力的一次体检报告。它说明当前前沿模型确实具备强大的单步能力但在持续多步的任务执行上距离“稳定的自动化和智能化”还有很长的路要走。对普通开发者这意味着现在做 Agent 类应用时必须在架构设计上多做一层思考不能直接把一个大任务丢给模型而是要设计好拆解、验证、状态管理和错误恢复机制。模型负责智能决策工程框架负责流程保障两者结合才能在真实任务中取得可用的成功率。如果你接下来想继续深入这一方向有几个值得关注的技术路径一是上下文工程。研究如何通过摘要、关键信息提取、结构化记忆等手段帮助模型在长任务中保持关键信息的可用性。二是评测方法论。学习如何构建更贴近真实场景的长程任务基准如何设计过程级和结果级相结合的评分体系如何避免评测中的伪成功。三是多智能体协作架构。把一个大任务分配给多个专家模型协作完成每个模型只负责自己擅长的步骤通过协议化接口互联减少单个模型承载长任务的负担。四是模型自身的训练目标优化。从数据层面增加长程任务样本从对齐层面优化模型的纠错和自省能力这需要更长远的投入但对整个行业意义重大。长程任务能力是 AI 从“回答者”走向“执行者”的必经门槛。6.4% 的通过率提醒我们这条路上还有大量的工程技术问题等待解决而这恰恰是开发者最大的机会所在。