2024年AI评测的风向明显变了从“模型能答对多少道题”转向“模型能不能在一个真实工作流里连续干72小时不出错”。这篇文章要聊的就是一项面向长时程AI任务的评测。据评测材料统计顶尖商业模型在完成复杂长时任务时综合表现只达到人类基准的27.3%。这个数字不是模型智商不够而是任务设计维度完全不同模型需要自己拆解目标、调用工具、读取环境反馈、多轮修正并且连续运行数小时甚至数天。这次评测体系里最突出的参考框架有三个Archon、Humanity‘s Last Exam以及长时程任务评测。其中长时程任务评测把“真实世界交互”作为核心人类用户平均输入约600字的目标描述AI要在72小时内自主完成。最顶尖的商用模型跑了8000次训练级任务总计1000个任务样本单次完整评测成本超过5000美金。这个成本说明一件事长时程评测不是便宜的事但它能暴露出传统基准测试完全看不到的问题。本文会拆解这套评测体系的设计逻辑、28个任务、四个指标、六个现象并给出一套本地搭建长时程评测的最小参考链路和排查方法。1. 长时程AI任务评测核心能力速览先把这套评测体系和几类常见基准对齐方便后续对比。评测维度ArchonHumanity‘s Last Exam长时程任务评测任务形态多智能体框架评测极难静态问答真实世界多步任务是否与环境交互部分交互否是多轮决策较少否强依赖典型运行时长分钟级单轮数小时到72小时评估重点Agent协作能力知识边界稳定性、自主性、探索效率、任务完成度成本中等较低高单次可超5000美金代表性结论框架可能放大模型短板模型在极难题上仍弱于人类专家顶尖模型仅达到人类27.3%长时程AI任务评测的核心特点可以概括成几点任务不是“给一个提示词、得到一段回答”而是“给一个目标让模型自己折腾”。评测周期长材料中给出的上限是72小时连续推理。模型需要调用外部工具比如搜索、代码执行、数据库查询、浏览器点击而不是只靠内部参数。失败率会随任务步骤增长快速上升这是传统评测很难体现的指标。评测成本高所以需要严谨的任务编排、日志系统和失败重试机制。适合阅读这篇文章的人有三类做大模型评测的工程师、做Agent应用开发的技术人员、以及需要给领导或客户解释“模型在实际任务里到底能不能用”的决策支持人员。2. 为什么单轮问答基准已经不够用了过去两年主流评测集中在Chatbot Arena、MMLU、HumanEval、GSM8K这一类的静态基准上。它们的共同点是输入固定输出对比固定没有环境反馈没有多轮交互。模型只需要在给定上下文里做一次预测。这套模式在模型能力早期是有效的因为模型连“常识问答”都不太稳评测只需要衡量知识覆盖面。但2024年之后问题变得很明显大多数商用模型在单轮问答里已经能拿到很高分数甚至MMLU这类基准被部分训练集污染模型可能已经“背过题”。这就导致单轮分数很高但把任务真正放给模型去独立完成时它反而会卡在第一步。长时程评测解决的问题是“任务完成能力”模型能不能把目标翻译成行动计划能不能在失败后自我修正能不能在长时间运行中不崩溃、不跑偏、不重复死循环。这些能力恰好是AI Agent、RPA自动化、企业级工作流落地最关心的点。如果你的目标是让模型去每天自动处理报表、自动查资料、自动维护工单那单轮问答分数基本没有参考价值。另一个问题是“评测成本”与“评测质量”的平衡。单轮基准可以一次跑几千条数据成本可控长时程任务一次要跑几小时甚至几十小时还要配置稳定的运行环境。材料里提到“最顶尖的商业模型跑8000次训练级任务总计1000个任务样本72小时连续推理成本超过5000美金”说的是评测材料统计口径下的成本实际成本会根据API价格和任务数量浮动。但方向是明确的高质量评测正在从小样本人工验证走向大规模自动化采样评测本身也需要工程化。3. 长时程评测框架的设计思路3.1 28个任务的分层逻辑材料中提到的28个任务不是随机生成的而是覆盖了“基础能力复合能力长时程执行”三个维度。基础能力任务包括代码生成、文本总结、信息检索、图表解读复合能力任务要求模型同时完成规划、工具调用和自我校验长时程执行任务则要求模型连续处理多个子任务并且子任务之间存在依赖关系。这种分层逻辑非常重要。如果只测基础能力模型在短任务里可能表现不错一旦进入长时程执行模型的错误率会随着步骤数量快速增加。评测任务的难度不是看单个子任务而是看“链路长度”。链路越长模型需要保持的中间状态越多越容易累积错误。3.2 评测指标设计四个维度评测指标不是“一个最终分数”而是四个维度稳定性模型在长时间运行中是否频繁崩溃、卡死、重复输出。自主性模型是否能自主规划是否频繁需要人工干预。探索效率模型在搜索信息、尝试方案时是否高效还是盲目乱试。任务完成度最终是否完成了目标完成质量是否符合预期。这四个维度对应着实际部署中最容易出问题的点。稳定性对应服务可靠性自主性对应Agent的“省心程度”探索效率对应运行成本任务完成度对应业务结果。3.3 成本与效率的现实约束长时程评测的最大障碍是成本。模型需要多轮推理每次推理都可能调用外部API例如搜索、数据库查询、代码执行单次任务成本可能是普通单轮评测的几十倍。评测材料给出的“成本超5000美金”是包含了模型推理费用和外部工具调用成本的整体估算。实际做评测时建议按token用量、API单价、任务数量分步统计避免一次跑太多任务导致账单失控。降低成本的思路是分级评测先用小任务做筛选再对通过者跑长时程任务。这样既保留了长时程评测的深度又控制了总成本。4. 长时程任务评测中的关键现象4.1 从第一步开始模型错误率就高于人类评测材料提到在最顶尖的商业模型上第一步的错误率已经高于人类。这不是说模型不会做题而是模型在没有明确指示时容易误判“该做什么”。人类看到任务目标后通常会先确认任务边界、检查输入、找到一个相对稳的起点模型则倾向于直接调用工具或者直接生成代码缺少“先想清楚再动手”的环节。这个现象在Agent应用里很典型模型经常在第一步就把任务的执行方向带偏后续所有步骤都建立在错误方向上最终结果自然失真。4.2 多步骤任务的失败率随链路长度快速上升评测中有一个具体趋势从第二步到第三步任务失败率会上升到16.7%四步之后接近90%。这个数据说明模型的错误不是均匀分布的而是呈指数累积的。每多一个步骤模型就需要保持“之前的上下文”和“当前的目标”一致但当前的主流模型在长上下文下仍会出现遗忘、重复、逻辑跳跃。从工程角度看这意味着长流程Agent不能完全依赖模型“一步到位”必须在每个关键步骤设置校验点。比如让模型每完成一步输出一个结构化的中间结果再让上层程序判断这个结果是否合理。4.3 框架虽然强大但无法弥补基础模型短板评测材料指出即使加了更复杂的Agent框架模型的能力短板也无法被完全弥补。一个常见的误解是只要用上ReAct、Plan-and-Execute、多智能体协作框架基础模型的推理能力就会自动变强。但长时程评测证明框架能放大能力却不能替代基础模型。如果模型本身在长上下文理解、工具调用、错误恢复上存在缺陷框架只会把这些缺陷拆得更碎甚至让问题更难排查。合理判断是框架适合把“已经能用的模型”组织成“更可用的流程”而不是把“不能用的模型”变成“能用的模型”。4.4 人类用户平均600字输入模型交互量巨大评测材料提到人类用户平均输入600字来描述目标但模型在完成过程中需要与真实世界进行大量交互。一个看似简单的目标比如“帮我把这份数据整理成报告并发送到指定邮箱”模型可能需要几十次工具调用、多次失败重试和纠错。这说明任务描述本身并不复杂复杂的是从目标到可执行动作之间的决策链路。这个现象也提示我们用户在真实场景里不会把任务描述成“完美提示词”评测时如果只给模型精心构造的提示词会高估模型在真实场景中的表现。4.5 达到同样任务精度人类代码量远小于AI评测材料里有组对比达到同样任务精度人类只需要14行代码而AI需要40行代码。这说明模型在代码生成上往往偏向“铺开写”而不是“精炼写”。它会产生很多防御性代码、重复逻辑、无效分支。代码量本身不是问题问题是代码量增加意味着执行时间和出错点也会增加。从工程实践看让模型生成代码后建议增加一个“代码压缩与审查”环节先让模型自己解释每一段代码的作用再让另一个模型或人工判断哪些分支可以删掉。4.6 长时程任务得分远低于单轮基准最终评测材料给出的数字是顶尖模型只能达到人类基准的27.3%。这里需要说明的是27.3%是一个综合计算结果反映的是模型在长时程、多轮、高自主性任务上的表现不代表模型在所有任务上都不行。在单轮问答、代码补全、短文本处理上模型依然很能打。但这个数字指向一个结论当前模型离“长时间独立执行复杂任务”还有很大距离。5. 如何复现一次长时程评测长时程评测不是只能由大机构来做工程团队完全可以搭建一套轻量评测链路。下面给出一个最小可运行参考架构代码和命令需要按实际项目调整。5.1 最小评测链路设计基础组件如下任务定义文件JSON或YAML保存任务目标、输入数据、预期结果、步骤数、超时时间。任务执行器循环读取任务调用模型API记录每一步输入输出。日志系统记录每次工具调用、每次模型输出、每次失败原因。结果评估器将最终输出与预期结果对比计算任务完成度。资源监控记录推理耗时、token消耗、API费用。一个最简单的任务执行器伪代码如下import json import time import logging from datetime import datetime logging.basicConfig(levellogging.INFO, format%(asctime)s %(levelname)s %(message)s) def load_tasks(task_file): with open(task_file, r, encodingutf-8) as f: return json.load(f) def execute_task(task, model_api): task_id task[id] goal task[goal] max_steps task.get(max_steps, 20) start time.time() attempt 0 while attempt max_steps: attempt 1 try: result model_api.run_step(goal, attempt) logging.info(task%s step%s ok, task_id, attempt) if result.get(done): return {task_id: task_id, status: success, steps: attempt, elapsed: time.time() - start} except Exception as exc: logging.warning(task%s step%s error%s, task_id, attempt, exc) time.sleep(1) return {task_id: task_id, status: failed, steps: attempt, elapsed: time.time() - start} def main(): tasks load_tasks(tasks.json) for task in tasks: result execute_task(task, model_apiNone) # 实际需要按项目替换为真实API客户端 print(result) if __name__ __main__: main()5.2 评测任务表结构设计长时程评测需要把每次执行结果保存下来方便后续分析和复盘。这里给出一个简化版的表结构CREATE TABLE long_task_eval ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id VARCHAR(64) NOT NULL, model_name VARCHAR(128) NOT NULL, status VARCHAR(32) NOT NULL, steps INT NOT NULL DEFAULT 0, total_tokens INT NOT NULL DEFAULT 0, api_cost DECIMAL(10, 4) NOT NULL DEFAULT 0, error_message TEXT, log_path VARCHAR(512), created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, finished_at DATETIME NULL, INDEX idx_task_id (task_id), INDEX idx_model_name (model_name), INDEX idx_status (status) );5.3 批量跑任务与失败重试长时程评测跑一次很贵批量任务必须有失败重试和断点恢复。建议用类似下面的脚本控制重试次数和退出策略import time def run_with_retry(run_func, max_retries3, backoff5): last_exc None for retry in range(max_retries): try: return run_func() except Exception as exc: last_exc exc print(fretry{retry 1} error{exc}) time.sleep(backoff * (retry 1)) raise last_exc # 使用示例 # result run_with_retry(lambda: client.run_task(task_id))这里强调一下不要在一个脚本里同时跑几百个长时程任务建议每个任务单独进程或者使用任务队列。否则某个任务卡死会导致整批结果作废。6. 长时程评测的部署与硬件选型参考长时程评测对基础设施的要求比普通评测高很多。核心问题包括任务跑多久单个任务可能跑几十分钟到几小时网络波动、API限流、模型超时都要处理。外部工具依赖搜索、代码执行、数据库访问、浏览器操作每个工具都可能成为瓶颈。数据记录量多轮交互会产生大量中间日志需要提前规划存储。API费用模型推理次数远高于单轮评测必须设置预算上限。如果需要在本地搭建一套评测环境建议关注以下几个选型方向。6.1 数据库选择长时程评测会产生大量结构化日志建议用MySQL或PostgreSQL保存任务状态、执行记录、费用统计。如果评测量很大也可以把原始日志写到对象存储结构化字段只保留关键索引。不要把所有结果都塞进一个JSON文件排查问题时会非常痛苦。6.2 GPU和推理服务选择评测阶段如果使用开源模型需要准备GPU推理服务。显存需求取决于模型规模7B~14B模型通常需要12GB~24GB显存32B以上建议使用48GB或更大显存。实际操作时要根据推理框架的精度设置和并发数调整。评测阶段不建议用太低的量化精度因为评测反映的是模型能力而不是“量化后还能不能用”。6.3 向量数据库与知识检索很多长时程任务会用到检索增强。评测环境里可以选用Milvus、Chroma、Qdrant等近似的开源向量数据库但注意评测中的检索结果必须保存否则无法判断模型最后答错是因为“检索不到”还是“生成错误”。6.4 浏览器自动化与RPA如果任务包含网页操作就需要接入RPA工具或浏览器自动化框架。这里要特别强调合规性抓取、自动化操作网页时必须先确认目标网站的使用条款不应对未经授权的系统发起自动化访问。评测中涉及任何个人数据、账号登录、内容采集都需要遵守安全边界。7. 长时程AI任务评测的安全与合规边界把评测任务放到真实环境里跑风险比单纯跑一个问答评测高得多。以下是必须明确的边界素材版权如果评测任务里包含书籍、论文、图片、商业文档不要未经授权上传到第三方API避免版权风险和隐私泄露。个人信息不要使用真实姓名、手机号、身份证、定位、聊天记录等内容做评测。评测数据应脱敏处理。系统授权任何涉及账号登录、数据库查询、网页操作、文件下载的任务都必须先获得系统所有者的授权。禁止用AI对未授权系统做自动化探测。内容合规评测目标不应涉及绕过安全限制、攻击他人系统、生成违规内容。README里应该注明“本评测仅用于研究目的使用者需确保遵守当地法律法规和平台政策”。模型输出复核长时程评测中模型可能生成看似合理但错误的结论任何评测结论都要经过人工复核不能直接当作权威依据。合规不是一句口号而是评测设计里必须做的一环。建议在评测流程里增加“授权确认”和“数据脱敏”两道前置检查。8. 常见问题与排查方法问题现象可能原因排查方式解决方案评测任务卡住不结束模型循环生成、工具调用超时查看日志确认是不是同一个动作重复执行设置单步超时和最大步数限制API费用增长过快没有设置token上限、重试次数过高统计每次调用的token消耗增加预算阈值超过即停止任务模型第一步就跑偏提示词缺少任务边界说明打印模型第一步输出在提示词里增加“先列出计划再执行”长任务中上下文丢失上下文长度超限模型遗忘早期信息检查每次调用传入的上下文大小做关键信息摘要按需传递外部工具返回格式变化页面结构或API字段变化记录工具原始返回工具调用结果做标准化解析多模型对比结果不稳定采样温度过高、投票数不足固定随机种子多次重复采样对比评测统一温度为0增加复跑次数任务完成率计算口径不统一成功标准、部分完成、超时处理不一致复查结果评估器逻辑提前定义成功、部分完成、失败的标准评测环境与生产环境不一致依赖版本、网络权限、环境变量差异用Docker固化环境统一镜像和启动脚本9. 长时程评测的最佳实践结合长时程AI任务评测的特征给出一套可落地的工程化建议。9.1 先跑小任务再跑大任务第一次评测不要直接上72小时、1000个任务。建议先挑5~10个任务把执行链路跑通确认日志、数据库记录、API费用统计都正常再逐步扩容。这能避免大量无效消耗。9.2 把“任务描述”和“提示词模板”分开管理任务描述是目标层的提示词模板是执行层的。比如任务描述是“写一份产品竞品分析报告”提示词模板是“你是一名分析师请按照以下结构输出……”。分开管理后同一个任务可以快速切换不同提示词策略进行评测。9.3 每步都要落盘长时程评测的每一步都可能有价值。建议所有模型输出、工具调用、中间状态全部落盘哪怕是失败尝试。失败日志对后续优化模型和提示词同样重要。9.4 三种评测维度分开看不要看“最终分数”一个数字。把稳定性、自主性、探索效率、任务完成度分开统计。一个模型可能任务完成度高但探索效率低这说明它“能用但贵”也可能自主性高但完成度低这说明它“自信但错误多”。9.5 关注模型长上下文下的“漂移”长时程模型评测中最常见的问题是模型在任务开始时理解目标但执行到一半后开始“即兴发挥”生成内容逐渐偏离初始目标。建议每执行几步就进行一次类似“当前进度与目标对比”的校验让模型定期总结阶段性结果。9.6 不要轻易下“某模型最强”的结论评测结果受任务集、提示词、工具链路、外部环境的影响很大单次评测只能代表该条件下的表现。要评价模型能力至少跑3次以上不同配置的任务集观察指标稳定性。10. 总结与后续方向长时程AI任务评测给出一个值得反复琢磨的结论顶尖模型在长时任务里的表现只有人类基准的27.3%这不是模型单轮能力差而是“持续稳定完成复杂目标”的系统性能力还远没有成熟。对做Agent、做自动化、做企业级AI应用的团队来说这个数字意味着不能把关键业务流程完全交给模型自主跑必须在中间节点加入校验、人工审批、失败重试和成本控制。下一步建议先从三个方向验证把现有任务的链路拆开统计每一步的失败率找出模型最容易出错的环节。建立一套分级评测体系先跑基础能力筛选再跑短链路任务最后跑长时程任务。对评测结果做成本分析看看模型在“完成一个任务”上的平均推理成本是否在业务可承受范围内。长时程评测本身也是工程问题任务编排、日志、费用统计、断点恢复、合规审查任何一环缺失都可能导致评测结果不准。建议把这篇文章提到的排查表和最小代码样例保存下来搭建评测环境时直接作为起点。 长时程AI任务评测：从单轮问答到72小时真实工作流
2024年AI评测的风向明显变了从“模型能答对多少道题”转向“模型能不能在一个真实工作流里连续干72小时不出错”。这篇文章要聊的就是一项面向长时程AI任务的评测。据评测材料统计顶尖商业模型在完成复杂长时任务时综合表现只达到人类基准的27.3%。这个数字不是模型智商不够而是任务设计维度完全不同模型需要自己拆解目标、调用工具、读取环境反馈、多轮修正并且连续运行数小时甚至数天。这次评测体系里最突出的参考框架有三个Archon、Humanity‘s Last Exam以及长时程任务评测。其中长时程任务评测把“真实世界交互”作为核心人类用户平均输入约600字的目标描述AI要在72小时内自主完成。最顶尖的商用模型跑了8000次训练级任务总计1000个任务样本单次完整评测成本超过5000美金。这个成本说明一件事长时程评测不是便宜的事但它能暴露出传统基准测试完全看不到的问题。本文会拆解这套评测体系的设计逻辑、28个任务、四个指标、六个现象并给出一套本地搭建长时程评测的最小参考链路和排查方法。1. 长时程AI任务评测核心能力速览先把这套评测体系和几类常见基准对齐方便后续对比。评测维度ArchonHumanity‘s Last Exam长时程任务评测任务形态多智能体框架评测极难静态问答真实世界多步任务是否与环境交互部分交互否是多轮决策较少否强依赖典型运行时长分钟级单轮数小时到72小时评估重点Agent协作能力知识边界稳定性、自主性、探索效率、任务完成度成本中等较低高单次可超5000美金代表性结论框架可能放大模型短板模型在极难题上仍弱于人类专家顶尖模型仅达到人类27.3%长时程AI任务评测的核心特点可以概括成几点任务不是“给一个提示词、得到一段回答”而是“给一个目标让模型自己折腾”。评测周期长材料中给出的上限是72小时连续推理。模型需要调用外部工具比如搜索、代码执行、数据库查询、浏览器点击而不是只靠内部参数。失败率会随任务步骤增长快速上升这是传统评测很难体现的指标。评测成本高所以需要严谨的任务编排、日志系统和失败重试机制。适合阅读这篇文章的人有三类做大模型评测的工程师、做Agent应用开发的技术人员、以及需要给领导或客户解释“模型在实际任务里到底能不能用”的决策支持人员。2. 为什么单轮问答基准已经不够用了过去两年主流评测集中在Chatbot Arena、MMLU、HumanEval、GSM8K这一类的静态基准上。它们的共同点是输入固定输出对比固定没有环境反馈没有多轮交互。模型只需要在给定上下文里做一次预测。这套模式在模型能力早期是有效的因为模型连“常识问答”都不太稳评测只需要衡量知识覆盖面。但2024年之后问题变得很明显大多数商用模型在单轮问答里已经能拿到很高分数甚至MMLU这类基准被部分训练集污染模型可能已经“背过题”。这就导致单轮分数很高但把任务真正放给模型去独立完成时它反而会卡在第一步。长时程评测解决的问题是“任务完成能力”模型能不能把目标翻译成行动计划能不能在失败后自我修正能不能在长时间运行中不崩溃、不跑偏、不重复死循环。这些能力恰好是AI Agent、RPA自动化、企业级工作流落地最关心的点。如果你的目标是让模型去每天自动处理报表、自动查资料、自动维护工单那单轮问答分数基本没有参考价值。另一个问题是“评测成本”与“评测质量”的平衡。单轮基准可以一次跑几千条数据成本可控长时程任务一次要跑几小时甚至几十小时还要配置稳定的运行环境。材料里提到“最顶尖的商业模型跑8000次训练级任务总计1000个任务样本72小时连续推理成本超过5000美金”说的是评测材料统计口径下的成本实际成本会根据API价格和任务数量浮动。但方向是明确的高质量评测正在从小样本人工验证走向大规模自动化采样评测本身也需要工程化。3. 长时程评测框架的设计思路3.1 28个任务的分层逻辑材料中提到的28个任务不是随机生成的而是覆盖了“基础能力复合能力长时程执行”三个维度。基础能力任务包括代码生成、文本总结、信息检索、图表解读复合能力任务要求模型同时完成规划、工具调用和自我校验长时程执行任务则要求模型连续处理多个子任务并且子任务之间存在依赖关系。这种分层逻辑非常重要。如果只测基础能力模型在短任务里可能表现不错一旦进入长时程执行模型的错误率会随着步骤数量快速增加。评测任务的难度不是看单个子任务而是看“链路长度”。链路越长模型需要保持的中间状态越多越容易累积错误。3.2 评测指标设计四个维度评测指标不是“一个最终分数”而是四个维度稳定性模型在长时间运行中是否频繁崩溃、卡死、重复输出。自主性模型是否能自主规划是否频繁需要人工干预。探索效率模型在搜索信息、尝试方案时是否高效还是盲目乱试。任务完成度最终是否完成了目标完成质量是否符合预期。这四个维度对应着实际部署中最容易出问题的点。稳定性对应服务可靠性自主性对应Agent的“省心程度”探索效率对应运行成本任务完成度对应业务结果。3.3 成本与效率的现实约束长时程评测的最大障碍是成本。模型需要多轮推理每次推理都可能调用外部API例如搜索、数据库查询、代码执行单次任务成本可能是普通单轮评测的几十倍。评测材料给出的“成本超5000美金”是包含了模型推理费用和外部工具调用成本的整体估算。实际做评测时建议按token用量、API单价、任务数量分步统计避免一次跑太多任务导致账单失控。降低成本的思路是分级评测先用小任务做筛选再对通过者跑长时程任务。这样既保留了长时程评测的深度又控制了总成本。4. 长时程任务评测中的关键现象4.1 从第一步开始模型错误率就高于人类评测材料提到在最顶尖的商业模型上第一步的错误率已经高于人类。这不是说模型不会做题而是模型在没有明确指示时容易误判“该做什么”。人类看到任务目标后通常会先确认任务边界、检查输入、找到一个相对稳的起点模型则倾向于直接调用工具或者直接生成代码缺少“先想清楚再动手”的环节。这个现象在Agent应用里很典型模型经常在第一步就把任务的执行方向带偏后续所有步骤都建立在错误方向上最终结果自然失真。4.2 多步骤任务的失败率随链路长度快速上升评测中有一个具体趋势从第二步到第三步任务失败率会上升到16.7%四步之后接近90%。这个数据说明模型的错误不是均匀分布的而是呈指数累积的。每多一个步骤模型就需要保持“之前的上下文”和“当前的目标”一致但当前的主流模型在长上下文下仍会出现遗忘、重复、逻辑跳跃。从工程角度看这意味着长流程Agent不能完全依赖模型“一步到位”必须在每个关键步骤设置校验点。比如让模型每完成一步输出一个结构化的中间结果再让上层程序判断这个结果是否合理。4.3 框架虽然强大但无法弥补基础模型短板评测材料指出即使加了更复杂的Agent框架模型的能力短板也无法被完全弥补。一个常见的误解是只要用上ReAct、Plan-and-Execute、多智能体协作框架基础模型的推理能力就会自动变强。但长时程评测证明框架能放大能力却不能替代基础模型。如果模型本身在长上下文理解、工具调用、错误恢复上存在缺陷框架只会把这些缺陷拆得更碎甚至让问题更难排查。合理判断是框架适合把“已经能用的模型”组织成“更可用的流程”而不是把“不能用的模型”变成“能用的模型”。4.4 人类用户平均600字输入模型交互量巨大评测材料提到人类用户平均输入600字来描述目标但模型在完成过程中需要与真实世界进行大量交互。一个看似简单的目标比如“帮我把这份数据整理成报告并发送到指定邮箱”模型可能需要几十次工具调用、多次失败重试和纠错。这说明任务描述本身并不复杂复杂的是从目标到可执行动作之间的决策链路。这个现象也提示我们用户在真实场景里不会把任务描述成“完美提示词”评测时如果只给模型精心构造的提示词会高估模型在真实场景中的表现。4.5 达到同样任务精度人类代码量远小于AI评测材料里有组对比达到同样任务精度人类只需要14行代码而AI需要40行代码。这说明模型在代码生成上往往偏向“铺开写”而不是“精炼写”。它会产生很多防御性代码、重复逻辑、无效分支。代码量本身不是问题问题是代码量增加意味着执行时间和出错点也会增加。从工程实践看让模型生成代码后建议增加一个“代码压缩与审查”环节先让模型自己解释每一段代码的作用再让另一个模型或人工判断哪些分支可以删掉。4.6 长时程任务得分远低于单轮基准最终评测材料给出的数字是顶尖模型只能达到人类基准的27.3%。这里需要说明的是27.3%是一个综合计算结果反映的是模型在长时程、多轮、高自主性任务上的表现不代表模型在所有任务上都不行。在单轮问答、代码补全、短文本处理上模型依然很能打。但这个数字指向一个结论当前模型离“长时间独立执行复杂任务”还有很大距离。5. 如何复现一次长时程评测长时程评测不是只能由大机构来做工程团队完全可以搭建一套轻量评测链路。下面给出一个最小可运行参考架构代码和命令需要按实际项目调整。5.1 最小评测链路设计基础组件如下任务定义文件JSON或YAML保存任务目标、输入数据、预期结果、步骤数、超时时间。任务执行器循环读取任务调用模型API记录每一步输入输出。日志系统记录每次工具调用、每次模型输出、每次失败原因。结果评估器将最终输出与预期结果对比计算任务完成度。资源监控记录推理耗时、token消耗、API费用。一个最简单的任务执行器伪代码如下import json import time import logging from datetime import datetime logging.basicConfig(levellogging.INFO, format%(asctime)s %(levelname)s %(message)s) def load_tasks(task_file): with open(task_file, r, encodingutf-8) as f: return json.load(f) def execute_task(task, model_api): task_id task[id] goal task[goal] max_steps task.get(max_steps, 20) start time.time() attempt 0 while attempt max_steps: attempt 1 try: result model_api.run_step(goal, attempt) logging.info(task%s step%s ok, task_id, attempt) if result.get(done): return {task_id: task_id, status: success, steps: attempt, elapsed: time.time() - start} except Exception as exc: logging.warning(task%s step%s error%s, task_id, attempt, exc) time.sleep(1) return {task_id: task_id, status: failed, steps: attempt, elapsed: time.time() - start} def main(): tasks load_tasks(tasks.json) for task in tasks: result execute_task(task, model_apiNone) # 实际需要按项目替换为真实API客户端 print(result) if __name__ __main__: main()5.2 评测任务表结构设计长时程评测需要把每次执行结果保存下来方便后续分析和复盘。这里给出一个简化版的表结构CREATE TABLE long_task_eval ( id BIGINT PRIMARY KEY AUTO_INCREMENT, task_id VARCHAR(64) NOT NULL, model_name VARCHAR(128) NOT NULL, status VARCHAR(32) NOT NULL, steps INT NOT NULL DEFAULT 0, total_tokens INT NOT NULL DEFAULT 0, api_cost DECIMAL(10, 4) NOT NULL DEFAULT 0, error_message TEXT, log_path VARCHAR(512), created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, finished_at DATETIME NULL, INDEX idx_task_id (task_id), INDEX idx_model_name (model_name), INDEX idx_status (status) );5.3 批量跑任务与失败重试长时程评测跑一次很贵批量任务必须有失败重试和断点恢复。建议用类似下面的脚本控制重试次数和退出策略import time def run_with_retry(run_func, max_retries3, backoff5): last_exc None for retry in range(max_retries): try: return run_func() except Exception as exc: last_exc exc print(fretry{retry 1} error{exc}) time.sleep(backoff * (retry 1)) raise last_exc # 使用示例 # result run_with_retry(lambda: client.run_task(task_id))这里强调一下不要在一个脚本里同时跑几百个长时程任务建议每个任务单独进程或者使用任务队列。否则某个任务卡死会导致整批结果作废。6. 长时程评测的部署与硬件选型参考长时程评测对基础设施的要求比普通评测高很多。核心问题包括任务跑多久单个任务可能跑几十分钟到几小时网络波动、API限流、模型超时都要处理。外部工具依赖搜索、代码执行、数据库访问、浏览器操作每个工具都可能成为瓶颈。数据记录量多轮交互会产生大量中间日志需要提前规划存储。API费用模型推理次数远高于单轮评测必须设置预算上限。如果需要在本地搭建一套评测环境建议关注以下几个选型方向。6.1 数据库选择长时程评测会产生大量结构化日志建议用MySQL或PostgreSQL保存任务状态、执行记录、费用统计。如果评测量很大也可以把原始日志写到对象存储结构化字段只保留关键索引。不要把所有结果都塞进一个JSON文件排查问题时会非常痛苦。6.2 GPU和推理服务选择评测阶段如果使用开源模型需要准备GPU推理服务。显存需求取决于模型规模7B~14B模型通常需要12GB~24GB显存32B以上建议使用48GB或更大显存。实际操作时要根据推理框架的精度设置和并发数调整。评测阶段不建议用太低的量化精度因为评测反映的是模型能力而不是“量化后还能不能用”。6.3 向量数据库与知识检索很多长时程任务会用到检索增强。评测环境里可以选用Milvus、Chroma、Qdrant等近似的开源向量数据库但注意评测中的检索结果必须保存否则无法判断模型最后答错是因为“检索不到”还是“生成错误”。6.4 浏览器自动化与RPA如果任务包含网页操作就需要接入RPA工具或浏览器自动化框架。这里要特别强调合规性抓取、自动化操作网页时必须先确认目标网站的使用条款不应对未经授权的系统发起自动化访问。评测中涉及任何个人数据、账号登录、内容采集都需要遵守安全边界。7. 长时程AI任务评测的安全与合规边界把评测任务放到真实环境里跑风险比单纯跑一个问答评测高得多。以下是必须明确的边界素材版权如果评测任务里包含书籍、论文、图片、商业文档不要未经授权上传到第三方API避免版权风险和隐私泄露。个人信息不要使用真实姓名、手机号、身份证、定位、聊天记录等内容做评测。评测数据应脱敏处理。系统授权任何涉及账号登录、数据库查询、网页操作、文件下载的任务都必须先获得系统所有者的授权。禁止用AI对未授权系统做自动化探测。内容合规评测目标不应涉及绕过安全限制、攻击他人系统、生成违规内容。README里应该注明“本评测仅用于研究目的使用者需确保遵守当地法律法规和平台政策”。模型输出复核长时程评测中模型可能生成看似合理但错误的结论任何评测结论都要经过人工复核不能直接当作权威依据。合规不是一句口号而是评测设计里必须做的一环。建议在评测流程里增加“授权确认”和“数据脱敏”两道前置检查。8. 常见问题与排查方法问题现象可能原因排查方式解决方案评测任务卡住不结束模型循环生成、工具调用超时查看日志确认是不是同一个动作重复执行设置单步超时和最大步数限制API费用增长过快没有设置token上限、重试次数过高统计每次调用的token消耗增加预算阈值超过即停止任务模型第一步就跑偏提示词缺少任务边界说明打印模型第一步输出在提示词里增加“先列出计划再执行”长任务中上下文丢失上下文长度超限模型遗忘早期信息检查每次调用传入的上下文大小做关键信息摘要按需传递外部工具返回格式变化页面结构或API字段变化记录工具原始返回工具调用结果做标准化解析多模型对比结果不稳定采样温度过高、投票数不足固定随机种子多次重复采样对比评测统一温度为0增加复跑次数任务完成率计算口径不统一成功标准、部分完成、超时处理不一致复查结果评估器逻辑提前定义成功、部分完成、失败的标准评测环境与生产环境不一致依赖版本、网络权限、环境变量差异用Docker固化环境统一镜像和启动脚本9. 长时程评测的最佳实践结合长时程AI任务评测的特征给出一套可落地的工程化建议。9.1 先跑小任务再跑大任务第一次评测不要直接上72小时、1000个任务。建议先挑5~10个任务把执行链路跑通确认日志、数据库记录、API费用统计都正常再逐步扩容。这能避免大量无效消耗。9.2 把“任务描述”和“提示词模板”分开管理任务描述是目标层的提示词模板是执行层的。比如任务描述是“写一份产品竞品分析报告”提示词模板是“你是一名分析师请按照以下结构输出……”。分开管理后同一个任务可以快速切换不同提示词策略进行评测。9.3 每步都要落盘长时程评测的每一步都可能有价值。建议所有模型输出、工具调用、中间状态全部落盘哪怕是失败尝试。失败日志对后续优化模型和提示词同样重要。9.4 三种评测维度分开看不要看“最终分数”一个数字。把稳定性、自主性、探索效率、任务完成度分开统计。一个模型可能任务完成度高但探索效率低这说明它“能用但贵”也可能自主性高但完成度低这说明它“自信但错误多”。9.5 关注模型长上下文下的“漂移”长时程模型评测中最常见的问题是模型在任务开始时理解目标但执行到一半后开始“即兴发挥”生成内容逐渐偏离初始目标。建议每执行几步就进行一次类似“当前进度与目标对比”的校验让模型定期总结阶段性结果。9.6 不要轻易下“某模型最强”的结论评测结果受任务集、提示词、工具链路、外部环境的影响很大单次评测只能代表该条件下的表现。要评价模型能力至少跑3次以上不同配置的任务集观察指标稳定性。10. 总结与后续方向长时程AI任务评测给出一个值得反复琢磨的结论顶尖模型在长时任务里的表现只有人类基准的27.3%这不是模型单轮能力差而是“持续稳定完成复杂目标”的系统性能力还远没有成熟。对做Agent、做自动化、做企业级AI应用的团队来说这个数字意味着不能把关键业务流程完全交给模型自主跑必须在中间节点加入校验、人工审批、失败重试和成本控制。下一步建议先从三个方向验证把现有任务的链路拆开统计每一步的失败率找出模型最容易出错的环节。建立一套分级评测体系先跑基础能力筛选再跑短链路任务最后跑长时程任务。对评测结果做成本分析看看模型在“完成一个任务”上的平均推理成本是否在业务可承受范围内。长时程评测本身也是工程问题任务编排、日志、费用统计、断点恢复、合规审查任何一环缺失都可能导致评测结果不准。建议把这篇文章提到的排查表和最小代码样例保存下来搭建评测环境时直接作为起点。