长程任务基准揭示前沿模型平均通过率仅6.4%这个数据在 AI 产品和技术圈里引发了不少讨论。如果你正在用大模型做 Agent 开发、自动化流程或多步骤任务处理这个数字值得认真看一看。它间接解释了很多开发者在实际项目中遇到的困惑模型在单轮问答里表现优秀为什么一放到真实业务里就频频出错为什么看起来简单的自动化流程一旦执行到第 5 步、第 8 步就开始离谱这篇文章不打算只做一个数据的搬运工而是想从技术角度拆解三件事第一长程任务基准到底测的是什么为什么它比传统评测更能反映模型的真实工程价值第二前沿模型在长程任务上只有 6.4% 通过率背后暴露了模型哪些结构性问题第三对正在做 Agent 应用、自动化脚本和复杂任务编排的开发者来说如何理解和应对这个短板。读完这篇文章你会对长程任务评估有一个相对完整的认知也能知道自己正在跑的 Agent 项目大概率会栽在哪些环节。1. 长程任务基准从“答题能力”到“做事能力”的评测转向先理解一个基本判断传统的大模型评测比如 MMLU、GSM8K、HumanEval 这类基准本质上是“答题能力测试”。模型拿到一道题、一段上下文然后给出答案。题目再难它也只有一个回合模型不需要自己规划步骤不需要维护长期状态更不需要在中间某一步出错后自我纠偏。但真实工程任务不是这样。以一个电商订单自动处理流程为例模型要完成的事情包括读取用户投诉邮件、调取订单信息、判断是否符合退款策略、生成退款指令、发送通知邮件、记录工单状态。这些步骤之间是有依赖关系的第 3 步的判断结果会直接影响第 4 步的指令内容。更关键的是在实际执行过程中每一步都可能遇到异常接口超时、数据格式异常、中间结果不完整。模型必须在这些干扰下仍然保持原始目标继续完成任务。这就是长程任务与短程任务最本质的区别。一个长程任务基准需要的不是让模型回答“哪一个是正确答案”而是让模型在多个连续步骤中完成一件完整的事情并且每一步的结果都会影响后续路径。整个过程结束后才判定这个任务是否真正成功。6.4% 的通过率意味着什么简单说100 个长程任务中前沿模型平均只能完整交付大概 6 到 7 个中间不允许人类修正、不允许重新给提示词从开始到结束全自动跑完。这个数据放在任何工程领域都很难接受但它恰恰反映了当前技术的真实水平。与其纠结这个数字是不是耸人听闻不如把它当作一束更真实的光照进了模型在工程化场景中表现的那个暗面。2. 为什么长程任务这么难先看评测设计长程任务的评测设计与传统基准有一个很大的不同它把“完成一项端到端工作”作为基本的评分单元而不是把“回答一个问题的正确率”作为评分单元。一个典型的长程任务评测通常包含这些要素任务目标一项完整的工作例如“在给定网站环境中完成一次无条件退款的流程”。初始状态包括初始文件、数据库状态、可操作的工具集等。操作空间模型可以调用工具、执行代码、修改文件、访问网络等。判定器Evaluator在任务结束后校验最终状态是否符合预期。不检查过程只看结果。举个例子假设评测任务是“修改某个函数后运行全部测试”模型的执行轨迹可能是这样读取源码文件定位目标函数。修改函数逻辑。运行相关的单元测试。如果测试失败分析报错信息调整代码。再运行测试直到通过或者达到最大步数。这个流程里模型要做的不只是一个动作而是持续产生中间产物并不断根据中间结果调整后续计划。每一步都有可能出错而且一旦前一步出错后续所有步骤都会跟着偏离。这些误差是逐级放大的10 步任务中平均第 4 步就产生了不可逆漂移这是长程任务失败的核心原因之一。评测视角相对复杂它不仅要覆盖不同难度的任务还要设计得分反馈、任务中断、结果校验等机制。每一次评测过程本身都需要消耗大量的模型调用次数和计算资源这也是长程评测难以做大规模的原因之一。所以6.4% 并不是一个故意压低的数字而是在严肃评测条件下得出的结果。它更像是一面放大镜把模型在真实工作时产生的累积错误和状态幻觉放大了。3. 短程强、长程弱模型能力评测的盲区如果只看短程评测会得出一个乐观的结论前沿模型的综合能力已经很接近人类专家水准。MMLU 之类基准中头部模型可以拿到 85% 以上的准确率代码能力在 HumanEval 这类单函数任务上也非常亮眼。这种高分开局很容易让团队在产品选型时对模型能力产生过高的预期。然而一旦工作复杂度提高模型表现并不均衡。这种“短程强、长程弱”的现象几乎横跨所有主流模型。短程任务有这几个特点任务边界清晰输入输出已经定义好不需要维护多步状态一次推理就能完成中间结果不做持久化。因此模型无需规划只需要把学到的模式匹配能力运用好就能做得不错。长程任务则完全不同。模型的“记忆池”不仅包含原始任务描述还包括每一步产生的中间状态、执行过的操作、读取过的内容。模型必须有持续的注意力动态更新机制把重要信息保持住把无关信息丢出去。但到底什么是“重要信息”这并不是每个任务开始时都能预先确定更多时候要结合后续任务来决定。这恰恰是当前模型架构中最难做好的地方。于是在实际执行中你通常会看到这样的场景模型在前 3 步的状态基本正确第 4、5 步开始出现小偏差到了第 7、8 步它已经不再为一个目标服务而是顺着自己的输出续写目标从“退款”漂移到了“解释退款规则”最后几步模型完成了一个步骤但它完成的是自己生成出来的假想目标和原始任务没有关系。从评测角度看如果一项基准只包含短程任务模型的通过率可能高达 80% 以上。但如果把难度拉升到真正需要多步协调的长程任务同一批模型的通过率就会迅速跌到个位数。这意味着目前大量厂商引用的“评测高分离线”往往只描述了模型的浅层能力真实能力需要更落地的评测才能暴露出来。4. 长程任务失败的背后是几个结构性问题观测到“通过率低”只是第一步更重要的是理解模型为什么会失败。从技术角度看几个因素叠加导致了长程任务的困难局面。第一误差累积。模型每一步的采纳概率即使在单步精度很高的前提下多步串联后整体成功率也会被明显压低。一个 10 步的任务如果每步的精确执行概率是 0.85理论整体通过率只有约 20%。如果每步是 0.8整体就只有约 10%。如果任务扩展到 20 步即使每步正确率达到 0.9总通过率也只有约 12%。这个数学现实决定了只要中间某几步不稳定长程任务的“灾难性失败”就是必然的。第二目标漂移。模型在长时间执行中很容易把“原始任务”和“当前动作”之间的关联逐渐弱化。它更像是在续写一段越来越偏的文本而不是在执行一个受约束的计划。一旦上下文窗口中的中间步骤增多原始目标被大量中间状态稀释模型就会“忘记初心”。第三错误恢复能力不足。人类在完成任务时发现错误后会回退、修正、再尝试。但语言模型默认的生成模式是单向的它不太容易识别“自己已经偏离”更不会主动回退到某个失败点重新规划。如果评测环境中没有设计自我纠错机制模型会沿着错误路径一路走到黑。第四自我评估不准确。哪怕给模型一个机会让它停下来检查结果模型也很少能准确判断自己是否真的完成了任务。它常常会因为“输出看起来很合理”而产生自信的幻觉。这也是为什么许多 Agent 框架引入反思Reflection模块后效果提升非常有限——问题不在于它愿不愿反思而在于它缺乏一个可靠的内部反馈信号来判断对错。理解了这几个原因再去看 6.4% 这个数字就不会觉得意外。这个结果不是某一个模型的问题而是当前大模型范式在长程任务上的系统性短板。5. 以长程任务为尺子如何构建自己的评估体系如果你正在做 Agent 开发或复杂的自动化流程评估以 6.4% 为参考你会发现仅靠几个现成的高分开源基准做选型和验收很容易出现“评测通过、上线翻车”的情况因此建议建立一套自己的长程验证方案。构建一个最小可用的长程评测环境不需要特别复杂的基建核心包括三块任务定义器定义任务目标、初始状态、成功条件。执行器把模型接进来让它在环境中执行动作。判定器根据最终状态判断任务是否成功并输出中间状态供分析。这里给出一份 Python 风格的长程任务评估框架设计核心代码包含三个部分任务基类、执行器、判定逻辑。# 文件路径evaluation/framework.py from dataclasses import dataclass, field from typing import Any, Callable dataclass class Task: name: str goal: str initial_state: dict evaluator: Callable[[dict], bool] max_steps: int 15 dataclass class AgentResult: task_name: str success: bool steps: int trace: list field(default_factorylist)# 文件路径evaluation/runner.py from dataclasses import dataclass, field from typing import Any, Callable dataclass class Task: name: str goal: str initial_state: dict evaluator: Callable[[dict], bool] max_steps: int 15 dataclass class AgentResult: task_name: str success: bool steps: int trace: list field(default_factorylist) def run_task(agent, task: Task) - AgentResult: state dict(task.initial_state) trace [] for step in range(task.max_steps): action agent.decide(task.goal, state) state agent.execute(action, state) trace.append({step: step, action: action, state: state}) if task.evaluator(state): return AgentResult(task.name, True, step 1, trace) # 达到最大步数后仍未成功 return AgentResult(task.name, False, task.max_steps, trace)任务定义示例模拟一个“修改配置文件后重启服务并验证端口”的任务# 文件路径evaluation/tasks/config_task.py from evaluation.framework import Task def check_config_updated(state): return ( state.get(config_updated) is True and state.get(service_restarted) is True and state.get(port_healthy) is True ) config_update_task Task( nameupdate_config_and_restart, goal将配置文件中 timeout 从 10 改为 30重启服务并确认 8080 端口健康, initial_state{ config: {timeout: 10}, service: stopped, port_healthy: False, }, evaluatorcheck_config_updated, max_steps10, )这个示例中判定器只看最终状态不检查模型是否按最优路径执行。只要最终配置更新、服务重启、端口健康就算成功。这才符合真实工作的验收方式用户不关心你怎么做到的只关心一件事是否被完成。如果你有任务追踪系统也可以把长程任务的状态存到 Redis 或数据库中避免上下文过长带来的信息稀释。这里给出一个简单的状态管理接入思路# 文件路径state_manager.py import json import redis class StateManager: def __init__(self, redis_client: redis.Redis, ttl: int 3600): self.client redis_client self.ttl ttl def save(self, session_id: str, step: int, state: dict) - None: key fagent:{session_id}:step:{step} self.client.set(key, json.dumps(state), exself.ttl) def load(self, session_id: str, step: int) - dict | None: key fagent:{session_id}:step:{step} raw self.client.get(key) if raw is None: return None return json.loads(raw)这样设计的好处是模型每执行一步就把完整状态持久化一次。即使上下文过长导致注意力丢失也能在外部存储中找回真实状态供下一步使用。长程评测和长程 Agent 应用都可以采用这个思路。6. 把长程成功率拉上去工程侧的几个有效动作面对只靠模型自省循环的局限工程侧仍然有很多事可以做而且其中不少已经经过了实践验证。把长程成功率从个位数往上提核心思路是“减少模型需要独自负责的环节”。第一尽量把任务拆到可判定粒度。不要让模型一次性完成“处理订单并完成所有售后闭环”而是要拆成多个子任务每个子任务的输入输出都有明确校验。模型出错后能将影响面控制在单个子任务内而不会污染全局。第二引入外部状态管理器。不要依赖模型的内部记忆保存关键数据而是把中间状态写到数据库或缓存中在下一步任务开始时动态注入当前所需信息。把长程依赖变成“短程读取”本质上是在减小模型的上下文负担。第三设置过程校验点。每完成一个可判定的里程碑调用一个校验函数或外部工具确认状态正确再继续下一步确认失败时可以选择重试当前子任务或回滚到上一个稳定状态。第四为模型提供工具而不是让模型凭记忆操作。比如获取当前文件内容的操作应该封装成 read_file 工具执行测试的操作应该封装成 run_test 工具。模型只负责规划和选择工具不负责在脑子里推算文件内容。第五保留人类介入接口。在真实业务系统中长程任务并不会要求“全自动 100% 成功”。更经济的方案是模型做到 80% 的路径在关键决策点停下来等待人工确认。这比强行追求自动通过率更安全也更符合工程实际。这里展示一个带校验的 Agent 循环比裸模型直跑要有明显改善# 文件路径agent/checkpoint_agent.py from agent.llm import decide_next_action import json # 全局状态存储 state {order: PO-1024, step: start, refund_issued: False} checkpoints { order_verified: lambda s: order_found in s and s[order_found] is True, refund_confirmed: lambda s: refund_amount in s and s[refund_amount] 0, task_done: lambda s: s.get(refund_issued) is True, } for step in range(15): action decide_next_action(json.dumps(state)) if action[type] check_order: state[order_found] True elif action[type] cal_refund: state[refund_amount] 128.5 elif action[type] issue_refund: state[refund_issued] True elif action[type] end: break if checkpoints.get(step): if not step(state): print(fstep {step} 校验失败中止或回滚) break这只是校验循环的简化示意但原理很清楚把“一次性跑完”改成“每步产出一个可观察状态通过校验后进入下一步”。长程任务的核心不是模型有多聪明而是每一步有没有被约束在一个可验证的闭环里。7. 给开发者的 4 条选型与实践建议看完 6.4% 的通过率有些团队可能会走向两个极端一个是“大模型太弱了长程任务根本不能用”另一个是“这个基准不科学不代表实际业务”。实际上更稳妥的判断是在中间这既不是全盘否定也不是盲目乐观而是对当前模型能力边界做一个冷静校准。基于长程任务的实际表现这里有 4 条建议。第一用长程任务而不是短程评测来选模型。如果你要做的应用涉及多步骤、多工具调用那么模型的 MMLU 分数再高也没有太多参考价值。更合理的方式是构造 20 个贴近业务场景的长程任务跑一遍完整的通过率和失败模式分布再决定用哪个模型。宁可多花几天做评测也不要省掉这一步直接上线。第二为长程失败模式设计兜底策略。在 Agent 框架中不要使用极端模式切换上下文而是同时保留短程工具和长程状态存储。一旦模型输出出现异常比如连续重复动作、关键字段缺失及时触发降级逻辑让人工接手。这样即使长程通过率只有 6.4%业务系统也不会出大事故。第三关注“带检查点的通过率”而不是“纯自动通过率”。在不做任何工程干预时6.4% 是模型裸跑的结果。但加上工具、状态管理、校验循环和人工审批点后同一个模型的完成率可以大幅提高。这个“工程化提升后的通过率”才是你真正应该关注和优化的指标。第四用评测数据持续反哺 prompt 与流程设计。长程评测的价值不只是给一个分数它还能输出执行轨迹。你可以观察失败集中在哪一步、模型在哪一步发生了目标漂移然后在对应环节加入更明确的提示词、规则约束或工具提示。这里没有银弹只有持续迭代。8. 常见问题与讨论针对这个数据下面整理了一些比较有代表性的问题并给出个人理解。问题常见理解更谨慎的理解与建议6.4% 是否说明模型不能用于自动化模型太弱长程任务这条路走不通它说明纯靠模型裸跑可靠性不足需要工程化补偿比如状态管理、校验点、人工兜底换个更强的新模型通过率会不会接近 50%新一代模型可能大幅提升长程能力从数据和经验看模型提升主要集中在短程与中等任务长程能力仍是全局短板工程化依然是刚需这个基准是不是故意设置难题任务太难不代表真实业务真实业务中的长程任务往往更复杂约束更多接口更多材料中的任务设置反而相对简单长程任务失败后重跑一次会成功吗可能只是随机性导致重试即可重试在少数情况下有效但如果失败原因是目标漂移或状态丢失重试只会重复同样错误应该做失败原因分析Agent 框架能否解决这个问题有了框架就能达到高通过率框架解决的是工程流程问题不能根治模型的规划与记忆短板但确实能缩小模型的负担是一个正确的实践方向从这些讨论中可以看出一个共性问题出在把“更强的模型”当作唯一答案。实际工程中更适合的组合是“中等偏上模型 较强的工程约束 合理的流程设计 人工兜底点”。9. 长程能力的下一步技术方向还是工程方向如果针对这个短板做改进其中有些属于技术方向有些属于工程方向两者的实现路径和迭代周期差异不小。模型侧可能出现的变化包括更强的规划能力模型能在执行前先拆分小任务并保持全局视角更可靠的自我校验模型能判断中间结果是否偏离目标更长的有效推理能力让模型在上下文范围内维持目标一致性甚至出现专门面向长程执行优化的强化学习训练方案。工程侧的变化可能会更先到来Agent 框架将内部状态外置不再依赖模型记忆环境提供的工具粒度更细一个动作对应一个可校验的结果流程编排层引入更多“模式识别”能力一旦发现模型出现重复动作、目标漂移等特征主动踩刹车加上人工审批点被进一步标准化关键环节由人机协作把关。对于普通开发者而言可以两条线并行观察。模型侧的进展会改变长程通过率的天花板工程侧的进展则决定这个天花板在实际系统中到底能达到多高。当前阶段与其等待更强的模型不如先把手上的长程任务拆得更细、状态管得更严、校验做得更足。如果未来某天长程任务的基准通过率从 6.4% 提升到了 20% 甚至 30%这当然值得高兴但在那之前每个正在做 Agent 应用的团队都值得建立一套自己的长程评测集把每一轮失败的模式记录下来这比追逐任何新模型发布都更有确定性的回报。
大模型长程任务平均通过率仅6.4%：Agent开发如何破局
长程任务基准揭示前沿模型平均通过率仅6.4%这个数据在 AI 产品和技术圈里引发了不少讨论。如果你正在用大模型做 Agent 开发、自动化流程或多步骤任务处理这个数字值得认真看一看。它间接解释了很多开发者在实际项目中遇到的困惑模型在单轮问答里表现优秀为什么一放到真实业务里就频频出错为什么看起来简单的自动化流程一旦执行到第 5 步、第 8 步就开始离谱这篇文章不打算只做一个数据的搬运工而是想从技术角度拆解三件事第一长程任务基准到底测的是什么为什么它比传统评测更能反映模型的真实工程价值第二前沿模型在长程任务上只有 6.4% 通过率背后暴露了模型哪些结构性问题第三对正在做 Agent 应用、自动化脚本和复杂任务编排的开发者来说如何理解和应对这个短板。读完这篇文章你会对长程任务评估有一个相对完整的认知也能知道自己正在跑的 Agent 项目大概率会栽在哪些环节。1. 长程任务基准从“答题能力”到“做事能力”的评测转向先理解一个基本判断传统的大模型评测比如 MMLU、GSM8K、HumanEval 这类基准本质上是“答题能力测试”。模型拿到一道题、一段上下文然后给出答案。题目再难它也只有一个回合模型不需要自己规划步骤不需要维护长期状态更不需要在中间某一步出错后自我纠偏。但真实工程任务不是这样。以一个电商订单自动处理流程为例模型要完成的事情包括读取用户投诉邮件、调取订单信息、判断是否符合退款策略、生成退款指令、发送通知邮件、记录工单状态。这些步骤之间是有依赖关系的第 3 步的判断结果会直接影响第 4 步的指令内容。更关键的是在实际执行过程中每一步都可能遇到异常接口超时、数据格式异常、中间结果不完整。模型必须在这些干扰下仍然保持原始目标继续完成任务。这就是长程任务与短程任务最本质的区别。一个长程任务基准需要的不是让模型回答“哪一个是正确答案”而是让模型在多个连续步骤中完成一件完整的事情并且每一步的结果都会影响后续路径。整个过程结束后才判定这个任务是否真正成功。6.4% 的通过率意味着什么简单说100 个长程任务中前沿模型平均只能完整交付大概 6 到 7 个中间不允许人类修正、不允许重新给提示词从开始到结束全自动跑完。这个数据放在任何工程领域都很难接受但它恰恰反映了当前技术的真实水平。与其纠结这个数字是不是耸人听闻不如把它当作一束更真实的光照进了模型在工程化场景中表现的那个暗面。2. 为什么长程任务这么难先看评测设计长程任务的评测设计与传统基准有一个很大的不同它把“完成一项端到端工作”作为基本的评分单元而不是把“回答一个问题的正确率”作为评分单元。一个典型的长程任务评测通常包含这些要素任务目标一项完整的工作例如“在给定网站环境中完成一次无条件退款的流程”。初始状态包括初始文件、数据库状态、可操作的工具集等。操作空间模型可以调用工具、执行代码、修改文件、访问网络等。判定器Evaluator在任务结束后校验最终状态是否符合预期。不检查过程只看结果。举个例子假设评测任务是“修改某个函数后运行全部测试”模型的执行轨迹可能是这样读取源码文件定位目标函数。修改函数逻辑。运行相关的单元测试。如果测试失败分析报错信息调整代码。再运行测试直到通过或者达到最大步数。这个流程里模型要做的不只是一个动作而是持续产生中间产物并不断根据中间结果调整后续计划。每一步都有可能出错而且一旦前一步出错后续所有步骤都会跟着偏离。这些误差是逐级放大的10 步任务中平均第 4 步就产生了不可逆漂移这是长程任务失败的核心原因之一。评测视角相对复杂它不仅要覆盖不同难度的任务还要设计得分反馈、任务中断、结果校验等机制。每一次评测过程本身都需要消耗大量的模型调用次数和计算资源这也是长程评测难以做大规模的原因之一。所以6.4% 并不是一个故意压低的数字而是在严肃评测条件下得出的结果。它更像是一面放大镜把模型在真实工作时产生的累积错误和状态幻觉放大了。3. 短程强、长程弱模型能力评测的盲区如果只看短程评测会得出一个乐观的结论前沿模型的综合能力已经很接近人类专家水准。MMLU 之类基准中头部模型可以拿到 85% 以上的准确率代码能力在 HumanEval 这类单函数任务上也非常亮眼。这种高分开局很容易让团队在产品选型时对模型能力产生过高的预期。然而一旦工作复杂度提高模型表现并不均衡。这种“短程强、长程弱”的现象几乎横跨所有主流模型。短程任务有这几个特点任务边界清晰输入输出已经定义好不需要维护多步状态一次推理就能完成中间结果不做持久化。因此模型无需规划只需要把学到的模式匹配能力运用好就能做得不错。长程任务则完全不同。模型的“记忆池”不仅包含原始任务描述还包括每一步产生的中间状态、执行过的操作、读取过的内容。模型必须有持续的注意力动态更新机制把重要信息保持住把无关信息丢出去。但到底什么是“重要信息”这并不是每个任务开始时都能预先确定更多时候要结合后续任务来决定。这恰恰是当前模型架构中最难做好的地方。于是在实际执行中你通常会看到这样的场景模型在前 3 步的状态基本正确第 4、5 步开始出现小偏差到了第 7、8 步它已经不再为一个目标服务而是顺着自己的输出续写目标从“退款”漂移到了“解释退款规则”最后几步模型完成了一个步骤但它完成的是自己生成出来的假想目标和原始任务没有关系。从评测角度看如果一项基准只包含短程任务模型的通过率可能高达 80% 以上。但如果把难度拉升到真正需要多步协调的长程任务同一批模型的通过率就会迅速跌到个位数。这意味着目前大量厂商引用的“评测高分离线”往往只描述了模型的浅层能力真实能力需要更落地的评测才能暴露出来。4. 长程任务失败的背后是几个结构性问题观测到“通过率低”只是第一步更重要的是理解模型为什么会失败。从技术角度看几个因素叠加导致了长程任务的困难局面。第一误差累积。模型每一步的采纳概率即使在单步精度很高的前提下多步串联后整体成功率也会被明显压低。一个 10 步的任务如果每步的精确执行概率是 0.85理论整体通过率只有约 20%。如果每步是 0.8整体就只有约 10%。如果任务扩展到 20 步即使每步正确率达到 0.9总通过率也只有约 12%。这个数学现实决定了只要中间某几步不稳定长程任务的“灾难性失败”就是必然的。第二目标漂移。模型在长时间执行中很容易把“原始任务”和“当前动作”之间的关联逐渐弱化。它更像是在续写一段越来越偏的文本而不是在执行一个受约束的计划。一旦上下文窗口中的中间步骤增多原始目标被大量中间状态稀释模型就会“忘记初心”。第三错误恢复能力不足。人类在完成任务时发现错误后会回退、修正、再尝试。但语言模型默认的生成模式是单向的它不太容易识别“自己已经偏离”更不会主动回退到某个失败点重新规划。如果评测环境中没有设计自我纠错机制模型会沿着错误路径一路走到黑。第四自我评估不准确。哪怕给模型一个机会让它停下来检查结果模型也很少能准确判断自己是否真的完成了任务。它常常会因为“输出看起来很合理”而产生自信的幻觉。这也是为什么许多 Agent 框架引入反思Reflection模块后效果提升非常有限——问题不在于它愿不愿反思而在于它缺乏一个可靠的内部反馈信号来判断对错。理解了这几个原因再去看 6.4% 这个数字就不会觉得意外。这个结果不是某一个模型的问题而是当前大模型范式在长程任务上的系统性短板。5. 以长程任务为尺子如何构建自己的评估体系如果你正在做 Agent 开发或复杂的自动化流程评估以 6.4% 为参考你会发现仅靠几个现成的高分开源基准做选型和验收很容易出现“评测通过、上线翻车”的情况因此建议建立一套自己的长程验证方案。构建一个最小可用的长程评测环境不需要特别复杂的基建核心包括三块任务定义器定义任务目标、初始状态、成功条件。执行器把模型接进来让它在环境中执行动作。判定器根据最终状态判断任务是否成功并输出中间状态供分析。这里给出一份 Python 风格的长程任务评估框架设计核心代码包含三个部分任务基类、执行器、判定逻辑。# 文件路径evaluation/framework.py from dataclasses import dataclass, field from typing import Any, Callable dataclass class Task: name: str goal: str initial_state: dict evaluator: Callable[[dict], bool] max_steps: int 15 dataclass class AgentResult: task_name: str success: bool steps: int trace: list field(default_factorylist)# 文件路径evaluation/runner.py from dataclasses import dataclass, field from typing import Any, Callable dataclass class Task: name: str goal: str initial_state: dict evaluator: Callable[[dict], bool] max_steps: int 15 dataclass class AgentResult: task_name: str success: bool steps: int trace: list field(default_factorylist) def run_task(agent, task: Task) - AgentResult: state dict(task.initial_state) trace [] for step in range(task.max_steps): action agent.decide(task.goal, state) state agent.execute(action, state) trace.append({step: step, action: action, state: state}) if task.evaluator(state): return AgentResult(task.name, True, step 1, trace) # 达到最大步数后仍未成功 return AgentResult(task.name, False, task.max_steps, trace)任务定义示例模拟一个“修改配置文件后重启服务并验证端口”的任务# 文件路径evaluation/tasks/config_task.py from evaluation.framework import Task def check_config_updated(state): return ( state.get(config_updated) is True and state.get(service_restarted) is True and state.get(port_healthy) is True ) config_update_task Task( nameupdate_config_and_restart, goal将配置文件中 timeout 从 10 改为 30重启服务并确认 8080 端口健康, initial_state{ config: {timeout: 10}, service: stopped, port_healthy: False, }, evaluatorcheck_config_updated, max_steps10, )这个示例中判定器只看最终状态不检查模型是否按最优路径执行。只要最终配置更新、服务重启、端口健康就算成功。这才符合真实工作的验收方式用户不关心你怎么做到的只关心一件事是否被完成。如果你有任务追踪系统也可以把长程任务的状态存到 Redis 或数据库中避免上下文过长带来的信息稀释。这里给出一个简单的状态管理接入思路# 文件路径state_manager.py import json import redis class StateManager: def __init__(self, redis_client: redis.Redis, ttl: int 3600): self.client redis_client self.ttl ttl def save(self, session_id: str, step: int, state: dict) - None: key fagent:{session_id}:step:{step} self.client.set(key, json.dumps(state), exself.ttl) def load(self, session_id: str, step: int) - dict | None: key fagent:{session_id}:step:{step} raw self.client.get(key) if raw is None: return None return json.loads(raw)这样设计的好处是模型每执行一步就把完整状态持久化一次。即使上下文过长导致注意力丢失也能在外部存储中找回真实状态供下一步使用。长程评测和长程 Agent 应用都可以采用这个思路。6. 把长程成功率拉上去工程侧的几个有效动作面对只靠模型自省循环的局限工程侧仍然有很多事可以做而且其中不少已经经过了实践验证。把长程成功率从个位数往上提核心思路是“减少模型需要独自负责的环节”。第一尽量把任务拆到可判定粒度。不要让模型一次性完成“处理订单并完成所有售后闭环”而是要拆成多个子任务每个子任务的输入输出都有明确校验。模型出错后能将影响面控制在单个子任务内而不会污染全局。第二引入外部状态管理器。不要依赖模型的内部记忆保存关键数据而是把中间状态写到数据库或缓存中在下一步任务开始时动态注入当前所需信息。把长程依赖变成“短程读取”本质上是在减小模型的上下文负担。第三设置过程校验点。每完成一个可判定的里程碑调用一个校验函数或外部工具确认状态正确再继续下一步确认失败时可以选择重试当前子任务或回滚到上一个稳定状态。第四为模型提供工具而不是让模型凭记忆操作。比如获取当前文件内容的操作应该封装成 read_file 工具执行测试的操作应该封装成 run_test 工具。模型只负责规划和选择工具不负责在脑子里推算文件内容。第五保留人类介入接口。在真实业务系统中长程任务并不会要求“全自动 100% 成功”。更经济的方案是模型做到 80% 的路径在关键决策点停下来等待人工确认。这比强行追求自动通过率更安全也更符合工程实际。这里展示一个带校验的 Agent 循环比裸模型直跑要有明显改善# 文件路径agent/checkpoint_agent.py from agent.llm import decide_next_action import json # 全局状态存储 state {order: PO-1024, step: start, refund_issued: False} checkpoints { order_verified: lambda s: order_found in s and s[order_found] is True, refund_confirmed: lambda s: refund_amount in s and s[refund_amount] 0, task_done: lambda s: s.get(refund_issued) is True, } for step in range(15): action decide_next_action(json.dumps(state)) if action[type] check_order: state[order_found] True elif action[type] cal_refund: state[refund_amount] 128.5 elif action[type] issue_refund: state[refund_issued] True elif action[type] end: break if checkpoints.get(step): if not step(state): print(fstep {step} 校验失败中止或回滚) break这只是校验循环的简化示意但原理很清楚把“一次性跑完”改成“每步产出一个可观察状态通过校验后进入下一步”。长程任务的核心不是模型有多聪明而是每一步有没有被约束在一个可验证的闭环里。7. 给开发者的 4 条选型与实践建议看完 6.4% 的通过率有些团队可能会走向两个极端一个是“大模型太弱了长程任务根本不能用”另一个是“这个基准不科学不代表实际业务”。实际上更稳妥的判断是在中间这既不是全盘否定也不是盲目乐观而是对当前模型能力边界做一个冷静校准。基于长程任务的实际表现这里有 4 条建议。第一用长程任务而不是短程评测来选模型。如果你要做的应用涉及多步骤、多工具调用那么模型的 MMLU 分数再高也没有太多参考价值。更合理的方式是构造 20 个贴近业务场景的长程任务跑一遍完整的通过率和失败模式分布再决定用哪个模型。宁可多花几天做评测也不要省掉这一步直接上线。第二为长程失败模式设计兜底策略。在 Agent 框架中不要使用极端模式切换上下文而是同时保留短程工具和长程状态存储。一旦模型输出出现异常比如连续重复动作、关键字段缺失及时触发降级逻辑让人工接手。这样即使长程通过率只有 6.4%业务系统也不会出大事故。第三关注“带检查点的通过率”而不是“纯自动通过率”。在不做任何工程干预时6.4% 是模型裸跑的结果。但加上工具、状态管理、校验循环和人工审批点后同一个模型的完成率可以大幅提高。这个“工程化提升后的通过率”才是你真正应该关注和优化的指标。第四用评测数据持续反哺 prompt 与流程设计。长程评测的价值不只是给一个分数它还能输出执行轨迹。你可以观察失败集中在哪一步、模型在哪一步发生了目标漂移然后在对应环节加入更明确的提示词、规则约束或工具提示。这里没有银弹只有持续迭代。8. 常见问题与讨论针对这个数据下面整理了一些比较有代表性的问题并给出个人理解。问题常见理解更谨慎的理解与建议6.4% 是否说明模型不能用于自动化模型太弱长程任务这条路走不通它说明纯靠模型裸跑可靠性不足需要工程化补偿比如状态管理、校验点、人工兜底换个更强的新模型通过率会不会接近 50%新一代模型可能大幅提升长程能力从数据和经验看模型提升主要集中在短程与中等任务长程能力仍是全局短板工程化依然是刚需这个基准是不是故意设置难题任务太难不代表真实业务真实业务中的长程任务往往更复杂约束更多接口更多材料中的任务设置反而相对简单长程任务失败后重跑一次会成功吗可能只是随机性导致重试即可重试在少数情况下有效但如果失败原因是目标漂移或状态丢失重试只会重复同样错误应该做失败原因分析Agent 框架能否解决这个问题有了框架就能达到高通过率框架解决的是工程流程问题不能根治模型的规划与记忆短板但确实能缩小模型的负担是一个正确的实践方向从这些讨论中可以看出一个共性问题出在把“更强的模型”当作唯一答案。实际工程中更适合的组合是“中等偏上模型 较强的工程约束 合理的流程设计 人工兜底点”。9. 长程能力的下一步技术方向还是工程方向如果针对这个短板做改进其中有些属于技术方向有些属于工程方向两者的实现路径和迭代周期差异不小。模型侧可能出现的变化包括更强的规划能力模型能在执行前先拆分小任务并保持全局视角更可靠的自我校验模型能判断中间结果是否偏离目标更长的有效推理能力让模型在上下文范围内维持目标一致性甚至出现专门面向长程执行优化的强化学习训练方案。工程侧的变化可能会更先到来Agent 框架将内部状态外置不再依赖模型记忆环境提供的工具粒度更细一个动作对应一个可校验的结果流程编排层引入更多“模式识别”能力一旦发现模型出现重复动作、目标漂移等特征主动踩刹车加上人工审批点被进一步标准化关键环节由人机协作把关。对于普通开发者而言可以两条线并行观察。模型侧的进展会改变长程通过率的天花板工程侧的进展则决定这个天花板在实际系统中到底能达到多高。当前阶段与其等待更强的模型不如先把手上的长程任务拆得更细、状态管得更严、校验做得更足。如果未来某天长程任务的基准通过率从 6.4% 提升到了 20% 甚至 30%这当然值得高兴但在那之前每个正在做 Agent 应用的团队都值得建立一套自己的长程评测集把每一轮失败的模式记录下来这比追逐任何新模型发布都更有确定性的回报。
