长时程 AI 任务评测在一轮新测试里反复出现同一个结果让当前顶尖模型连续完成一个需要多步骤、多工具、多决策的“长时程任务”最终任务完成度只相当于人类参与者的 27.3%。这个数字对应的不是单轮问答的准确率也不是代码通过率而是模型像实习生一样连续工作几十分钟甚至更长时间后的整体产出质量。它说明模型处理“一段话”的能力很强处理“一个完整工作过程”的能力仍然有巨大缺口。这篇文章围绕长时程 AI 任务评测展开先说明这类评测和普通对话评测有什么不同再解释为什么传统指标会失真然后给出一套可落地的最小评分框架。读过之后可以回答三个问题长时程任务到底评什么怎么设计评分规则当模型得分很低时如何从轨迹文件里定位真正原因。文中所有代码和配置都是演示结构落地时建议根据自己的模型、任务集和工具环境调整。1. 长时程 AI 任务评测为什么不能套用普通问答评测1.1 什么是长时程任务“长时程”最关键的特征是时间尺度和步数而不是输入文字的篇幅。它的任务边界通常是一个明确的工作目标而不是一条 prompt。常见任务类型包括给定一份产品需求让模型完成市场资料收集、需求拆解、原型文案生成和验收清单整理整个过程可能涉及几十次工具交互。给定一个目标网站让模型完成信息收集、页面抓取、内容清洗、结构化入库和最终报告输出。给定一份开源项目让模型先阅读代码、定位缺陷、修改文件、运行测试并生成提交说明。让模型模拟一个运营角色在连续多天的数据变化中完成分析、通知、调整策略和总结。这些任务有一个共同模式多步骤、依赖工具、环节之间有信息传递、前面步骤的错误会往后累积。评测对象不是模型的一次输出而是模型在一段时间内的连续行为序列。需要注意“长时程”不等于“长上下文”。长时程任务里模型收到的初始指令可能只有几百字但执行过程会产生上万字的工具返回、中间结果和自己生成的记录。评测系统要把这两类维度分开否则容易把一些上下文很大的单轮测试错误地算成长时程任务。1.2 为什么传统指标会失真普通对话评测通常测量答案正确率、精确匹配、BLEU 或人工打分。这些问题在单次输入输出中完成评测对象是模型的一次推理结果。长时程任务评测额外关注三个能力维度规划能力模型是否在第一步就给出合理目标分解而不是走一步看一步。状态保持能力模型是否记得自己已经完成了哪些步骤、拿到了哪些数据、还有哪些没做。恢复能力当工具报错或返回空数据时模型是换一种方式重试还是直接放弃或反复尝试同一错误参数。如果把单轮指标直接迁移过来会出现两个典型问题。第一结果对但过程无效。模型没有真正调用工具却根据训练数据猜到一个字段名被评分规则误判为正确。第二过程有效但最终结果不完整。模型正确执行了前三个步骤却在最后一步没有落盘文件如果只在最终文件上检查就会漏掉中间大部分有效进展。因此长时程评测需要拆成多个评分传感器最终结果检查、里程碑检查、轨迹质量检查和效率检查。1.3 27.3% 这个数据应该如何理解27.3% 不能直接理解为“模型能力只有人类的二成七”。这个数值是特定任务集、特定时间预算、特定评分规则共同作用的结果。任务集只覆盖了某几类办公和研究类任务模型运行有超时限制人类参与者也在相同的任务说明和可用工具范围内操作。在这组条件下人类平均水平按 100% 归一化后顶尖模型的任务完成度约为 27.3%。这个数据更重要的价值在于说明当前智能体的“工作能力”和“对话能力”之间存在断层。模型在标准考试和代码竞赛里可以拿到高分但放在一个需要连续决策、连续使用工具的现场环境中大量分数会消耗在路径错误、重复操作和失败恢复上。引用或发布这类评测结果时报告至少要交代如下条件否则数据无法跨团队复用。条件需要确认的问题任务集边界任务类型是什么步骤数范围工具环境是否一致人类基线设置参与者是否受过训练是否允许查文档是否有时间上限评分方式最终结果占比多少过程步骤占比多少是否有 LLM 主观评分统计口径绝对完成率还是相对人类完成度是否计算置信区间2. 一套长时程评测体系需要哪些核心组件2.1 任务定义从自然语言到结构化配置评测的第一步是把任务从一段自然语言描述变成结构化定义。建议每个任务独立拆成一份 YAML 文件包含任务描述、初始状态、可用工具、验收条件和时间预算。示例结构如下task_id: research_report_001 name: 竞品信息整理 description: | 收集 ABC 公司官网与公开新闻中的产品功能信息 整理为一份包含时间、信息来源、原始描述的三列清单 输出到 output/report.md。 initial_files: - docs/background.docx allowed_tools: - web_search - fetch_url - write_file - read_file timeout_minutes: 60 milestones: - step: 1 name: 列出信息源 check: 至少产出 3 个有效 URL - step: 2 name: 提取结构化字段 check: 输出表中包含时间、来源、描述三列 - step: 3 name: 落盘报告 check: output/report.md 存在且行数大于 10任务定义的关键点是把验收条件写成机器可判断的规则而不是一句模糊的“内容完整”。机器规则可以先做存在性检查、行数检查和字段格式检查剩余的语义完整性交给 LLM 评分器。任务定义越明确模型和评分器的方差越小。但也不能把任务简化成只有三五步的小问题那就失去了“长时程”这个评测维度。2.2 轨迹记录没有过程的评测无法定位问题评测系统不能只记录最终输出必须保留一份完整的执行轨迹。建议使用 JSONL 格式每一行是一个事件。演示轨迹如下{event: agent_start, ts: 1710000000.123, task_id: research_report_001, model: agent-v1} {event: tool_call, ts: 1710000012.500, step: 1, tool: web_search, input: {query: ABC 公司 产品功能}, output: {urls: [https://example.com/abc]}} {event: agent_message, ts: 1710000050.100, step: 2, text: 已找到官网准备抓取产品页} {event: tool_call, ts: 1710000051.300, step: 2, tool: fetch_url, input: {url: https://example.com/abc}, output: {status: error, reason: 403}} {event: agent_message, ts: 1710000060.400, step: 3, text: 抓取失败改用搜索结果摘要}轨迹至少要包含四类信息agent 自己说了什么、调用了什么工具、工具返回了什么、agent 是否进入最终动作。这四类信息是误差分析的原材料。很多评测平台过早丢弃工具返回的完整内容只保留截断文本等发现问题时已经无法复盘。轨迹文件还要支持重放。给定同样的任务定义和轨迹历史每一步的输入输出都能还原评审人员才能离线判断模型在步骤之间的推理是否合理。2.3 里程碑把长任务切成可打分的中段一个六十分钟的任务如果只在最后检查一次中间任何一步出错都会导致最终结果失败系统无法判断是规划问题还是执行问题。里程碑的作用是把长期任务切分成中段检查点。设计里程碑时注意三个原则每个里程碑可以独立验证不依赖后续步骤的结果。里程碑按顺序编号后一个依赖前一个便于计算模型断在哪里。一个长时程任务建议设置 3 到 10 个里程碑太少没有过程价值太多会明显增加评分成本。误差分析时如果多个任务都在同一个里程碑失败说明模型在这个能力区域存在系统性问题。如果失败点分散在各处则更可能是个别任务陷阱或工具交互问题。2.4 评分模式规则检查加 LLM 评分再加人工抽检长时程任务的最终结果形态难以穷举纯规则无法覆盖语义。常见做法是三层评分。第一层是规则检查器负责文件是否存在、字段是否齐全、数值范围、URL 是否可访问等客观项。第二层是 LLM 评分器使用独立评分提示词让评分模型对照任务定义和里程碑判断完成质量。第三层是人工抽检随机抽取一定比例的轨迹由人来纠正规则和 LLM 评分器的误判抽检结果回写规则形成评测集迭代闭环。一个错误做法是直接让评分模型看 agent 最终给自己写的“已完成”总结然后打分。模型很容易在语言表达上显得很自信即使最终报告内容缺失总结也写得完整。评分输入必须优先使用工具调用记录和最终产物本身agent 的自我总结只能作为参考。3. 搭建一个最小可运行的长时程评分框架3.1 环境准备与依赖下面示例使用 Python 3.10 以上版本核心依赖是 PyYAML、requests 和 OpenAI 兼容 SDK。实际版本要根据项目环境确认不要直接照抄最新版本号。python -m venv .venv source .venv/bin/activate pip install pyyaml requests openaiOpenAI 兼容接口的地址和模型名建议通过环境变量传入避免把密钥和模型参数写进代码仓库。export LLM_API_URLhttps://api.example.com/v1 export LLM_MODEL_NAMEscoring-model export LLM_API_KEYyour-key这一步完成后的检查点在命令行执行python -c import yaml, openai没有报错说明依赖已经就绪。3.2 最小评分脚本最小框架只需要四个模块读取任务配置、读取轨迹、执行可检查规则、调用 LLM 评分器。先看规则检查部分。import json import yaml import argparse from pathlib import Path def load_task(task_path): with open(task_path, r, encodingutf-8) as f: return yaml.safe_load(f) def load_traces(trace_path): events [] with open(trace_path, r, encodingutf-8) as f: for line in f: line line.strip() if line: events.append(json.loads(line)) return events def check_milestone(task, output_dir.): milestone_results [] for milestone in task.get(milestones, []): ok False check_expr milestone.get(check, ) if report.md 存在 in check_expr: report Path(output_dir) / output / report.md ok report.exists() milestone_results.append({ step: milestone[step], name: milestone[name], ok: ok, }) return milestone_results def main(): parser argparse.ArgumentParser() parser.add_argument(--task, requiredTrue) parser.add_argument(--trace, requiredTrue) parser.add_argument(--output-dir, default.) args parser.parse_args() task load_task(args.task) traces load_traces(args.trace) print(轨迹事件数量:, len(traces)) for r in check_milestone(task, args.output_dir): print(r) if __name__ __main__: main()这段代码只演示结构化流程实际项目中不需要把 check 字段写死在 if 判断里。推荐把验收规则定义成一个小的规则表达式例如file_exists: output/report.md、file_lines_gt: 10然后由规则解析器动态执行。运行命令python evaluator/evaluate.py --task tasks/research_report_001.yaml --trace runs/agent_001.jsonl --output-dir runs/agent_001_workdir预期输出示例轨迹事件数量: 86 {step: 1, name: 列出信息源, ok: True} {step: 2, name: 提取结构化字段, ok: False} {step: 3, name: 落盘报告, ok: False}第一个里程碑通过后两个失败说明模型在信息收集阶段完成得不错但在结构化输出和落盘阶段出现问题。这一步只能定位到阶段要判断是“模型没做”还是“格式错了”还需要结合轨迹继续看工具输出。3.3 LLM 评分器的最小提示词LLM 评分器的作用不是给一个主观总分而是判断某个里程碑的完成质量。最小提示词可以这样设计你是一个评测员。任务定义如下 {task_definition} Agent 的关键工具调用记录如下 {trace_snippet} 请判断以下验收条件是否完成只回答 PASS、PARTIAL 或 FAIL 并给出一句不超过 30 字的理由 {check}为了让结果稳定可以要求评分模型只输出 JSON{verdict: FAIL, reason: 报告缺少时间字段}评分时注意两点。第一温度参数要调低推荐 0 到 0.2避免评分模型自己产生随机变化。第二不要在一个任务里把所有轨迹片段都传给评分器否则 token 成本会非常高。可以先抽取各里程碑附近的工具调用和 agent 消息再交给 LLM 评分。3.4 完成度计算与统计口径整体完成度需要先定义清楚。常见方式是把每个里程碑分值化里程碑通过得 1 分然后对所有任务求平均值再与人类基线做归一化。def compute_model_score(task_results): total sum(task_results.values()) max_score len(task_results) return total / max_score model_absolute_score 0.273 human_absolute_score 1.0 relative model_absolute_score / human_absolute_score print(f相对人类完成度: {relative:.1%})报告中不能把“相对人类完成度”和“绝对完成率”混用。如果 27.3% 是相对值那说明任务本身的绝对完成率可能更低或更高取决于人类基线。若缺少任务数、任务难度分布和时间预算这个数字就不能用来做精确的模型排名判断。4. 从 27.3% 的结果倒推模型失败在哪里4.1 长任务中模型丢失前文长时程评测中第一个高频问题不是模型不会做而是做了一半忘了上文。具体表现是agent 在第五步还在使用第一步已经确认错误的旧 URL或者重复调用已经完成过的接口。排查方式很简单把轨迹中出现的 URL、文件路径、查询条件按顺序整理检查重复元素。如果同一输入出现多次优先判断为记忆或上下文压缩问题。缓解手段包括让 agent 定期写工作笔记把关键状态写入文件以及使用显式的“已完成清单”而不是完全依赖模型内部记忆。评测系统要避免把“模型忘记”误判成“模型不想做”。如果评测环境不允许模型写中间笔记模型保持状态的难度会更高。这也是为什么评测环境中的可用工具列表必须公开并在评测报告里写明。4.2 工具错误累积导致后段失败第二类失败是工具调用链中的错误像滚雪球一样累积。例如第一步搜索返回的是旧页面地址第二步抓取返回 404模型不换关键词而是反复用接近的参数请求同一目标。轨迹中可以看到同一个工具的调用参数相似度很高但输出始终异常。这种问题不是单轮推理错误而是缺少失败反馈机制。评分框架里建议增加“工具错误分类”字段方便统计各类错误占比。工具错误类型轨迹表现常见处理建议网络状态错误fetch_url 返回 404 后仍然重试同一 URL换搜索词或换链接再试解析错误HTML 转 Markdown 后字段为空检查选择器或读取原文权限错误写入目标目录返回 Permission denied检查评测环境目录权限输出格式错误模型输出表格但少了一列要求 agent 在输出前自检字段如果同类错误在多个任务中占比相似说明是系统性问题需要修改 agent 提示词或工具层而不是简单换一个模型版本。4.3 规划不足与提前终止第三种失败是 agent 认为任务已经完成实际上没有通过最终验收。轨迹中会出现一条“我的任务已完成”的总结但最终产物缺失或字段不全。评测系统要把这种情况记为“虚假完成”。处理虚假完成有三个办法。在任务定义里显式写出必须生成的产物路径和必须包含的字段。评分时把最终产物作为第一优先级agent 的自我总结排除在评分依据之外。在 agent 提示词里要求它最后执行一次验收自查输出 checklist。提前终止比超时失败更容易被误判。若两个 agent 最终分数相同一个因为超时被迫终止另一个因为虚假完成提前终止这两个问题的修复策略完全不同。轨迹里必须记录终止原因是“模型主动结束”还是“超时强制结束”。4.4 评测环境对得分的影响在跑评测之前要确认环境是否具备模型完成任务所需的条件。常见的环境问题有允许的可用工具列表和任务描述里声明的不一致。目标网站访问超时或返回验证码。数据库或文件系统没有预置初始状态。模型运行环境的网络策略无法访问目标外部资源。这些问题都会直接压低完成度。如果评测报告没有写明环境限制27.3% 很难跨团队复用。生产环境评估建议保留一份“环境说明快照”包括依赖版本、网络策略、初始文件哈希和 LLM 接口版本。5. 长时程评测的工程落地问题5.1 评测集建设的两个极端评测集建设常见的坑有两个。一个是任务太简单所有模型都能接近完成区分度不足。另一个是任务太难所有模型都拿到接近零分看不到能力排序。正确做法是先做小范围试跑用 20 到 50 个任务观察完成度分布。理想分布是平均完成度落在 30% 到 70% 之间而且不同模型的方差足够大。如果分布两端堆积就要调整任务难度或评分粒度。任务集还要包含负例。负例是指任务本身存在陷阱比如某些信息源已经失效、某些数据字段在页面中不存在。这类任务能考察模型在信息不足时是主动说明还是直接编造。如果评测集全是“顺利任务”得分会虚高也无法暴露稳定性问题。5.2 评分成本控制长时程评测的 LLM 评分成本远高于普通问答评测因为每个任务的轨迹可能长达几千个 token。评分时要选择关键片段而不是把整个轨迹全部传给评分器。常用做法有三种。第一只抽取工具调用事件和里程碑节点附近的 agent 消息。第二对工具返回内容做截断或摘要评分器只看结构化结果。第三先跑规则检查只有规则检查无法判定时才调用 LLM 评分。成本控制还有一个原则不要在每次运行时都让 LLM 重新读整段轨迹。同一任务的多条轨迹可以先生成摘要缓存评分器基于摘要做对比能明显降低 token 消耗。评分一致性方面同一个批次要固定评分模型版本不要中途切换。评测报告要记录评分模型名称、温度、最大 token 数这些超参数会影响最终分数长期积累后缺少记录会很难追溯。5.3 人工抽检的比例建议人工抽检不是可选项。长时程任务的语义判断存在天然灰度LLM 评分器会出现稳定偏差。例如有些评分模型对长文本有偏好给更长的报告打高分而任务实际只需要三行摘要。抽检比例建议是每个任务至少覆盖 3 条轨迹或者总数量的 10% 到 20%。抽检时重点看评分不一致的样本而不是只看高分或低分样本。不一致样本是评测集质量提升的主要来源。抽检结果要回写进任务定义。如果大量样本因为“输出过短”被误判就把验收条件改成“报告必须包含时间、来源、描述三列且每列至少有 10 个非空条目”。5.4 学习环境与生产环境的差异学习环境跑评测时重点是快速验证流程。任务数量可以降到个位数工具环境只用 mock 数据轨迹文件不需要长期保留。生产环境评测则要做额外保障轨迹落在独立存储任务配置和评分脚本进入版本库环境快照固定评分模型版本锁定异常任务单独标记。生产环境还需要考虑回滚当评测平台自身版本升级后历史任务是否还能用相同配置重跑。如果不能重跑历史分数就不具备可比性。6. 提升长时程任务完成度的工程方向6.1 给 agent 加外部工作清单当前模型在长时程任务上只达到人类 27.3% 的完成度很大一部分改进可以从工程机制入手而不仅是换更大的模型。最小改动是要求 agent 在每次行动前先维护一份工作清单待办: - [x] 访问官网产品页 - [ ] 提取价格字段 - [ ] 写入 report.md这份清单可以写入独立的progress.md。它在两个层面起作用一方面让评测者看到计划另一方面让模型在上下文过长时能通过读取笔记重建状态。即便模型自身记忆能力没有提升外部化的工作清单也能显著降低遗忘概率。6.2 记忆与检索分层长时程任务里模型上下文窗口再大也会被工具返回内容填满。工程上可以把记忆分成三层短期记忆最近 5 到 10 条工具调用记录直接放在上下文中。工作记忆agent 自己写的笔记通过检索器在需要时读取。长期记忆历史任务中可复用的结论存储在外部向量数据库。评测框架本身应该把“是否使用外部记忆”作为参数记录方便比较不同机制在同一任务集上的贡献。6.3 工具调用前做参数校验很多失败发生在工具调用参数不合法。agent 输出一个缺失字段的 JSON工具层直接报错。最小校验方案是在工具层加入参数结构校验。TOOL_SCHEMAS { web_search: {required: [query]}, fetch_url: {required: [url]}, write_file: {required: [path, content]}, } def validate_tool_input(tool_name, arguments): required TOOL_SCHEMAS.get(tool_name, {}).get(required, []) missing [field for field in required if field not in arguments] if missing: return {valid: False, missing: missing} return {valid: True, missing: []}工具层校验可以提前拦截错误避免模型进入“幻觉成功”。评测框架在轨迹中记录本次工具调用是否通过校验统计失败率时就能区分“模型参数错误”和“环境执行错误”。6.4 子代理与任务分工当任务步骤超过一定数量单个 agent 越到后面越容易混乱。常见做法是在外层调度器里做任务切分让不同子代理负责不同阶段例如“调研子代理”和“写作子代理”。子代理模式并不是越多越好。每个子代理的职责边界必须清楚否则任务交接会引入新的信息丢失。评测时建议准备两种配置单代理版本和两代理版本对比同一任务集看分数提升是否值得额外复杂度。6.5 强制产出验收证据最后一项改进是让 agent 在最终输出时提供证据链而不是只给结论。例如任务要求输出竞品报告agent 应在报告末尾列出信息来源、抓取时间和字段判断理由。评测器可以检查证据链字段信息源是否真实存在于任务允许范围内。抓取时间是否在任务时间窗口内。页面字段与报告字段是否来自同一条记录。证据链要求会让 agent 更克制地编造。虽然不能完全杜绝幻觉但能显著提高可审计性。对长时程任务来说可审计性经常比创造性更重要。7. 发布评测结果时的最低要求与下一步7.1 可复现评测报告至少包含的字段团队如果后续要发布自己的长时程评测结果建议报告里包含这些字段字段说明任务集版本任务 YAML 配置哈希或 git commit模型与推理参数模型名、温度、最大步数、超时时间工具环境快照依赖版本、初始文件、网络限制评分规则版本规则检查器版本、评分提示词版本、评分模型版本人类基线采集说明参与者是否受过训练、是否允许联网、时间预算统计口径绝对完成率还是相对人类完成度是否计算置信区间异常样本虚假完成、超时终止、环境故障分别占比缺少这些字段的评测结果只能说明“某次运行情况如此”不能支撑跨模型比较或选型决策。7.2 长时程评测集上线前检查清单确认每个任务都有机器可判断的至少一个里程碑。确认轨迹文件每行都可重放不会因为上下文截断丢失关键工具返回。确认评分模型版本固定且温度低于 0.2。确认抽检比例和抽检结果回填流程已定义。确认报告中同时给出绝对完成率和相对人类完成度避免口径混淆。确认环境故障时段被标记而不是直接算作 agent 失败。确认任务集内包含 10% 到 30% 的负例或陷阱任务。确认可用工具列表完整记录不允许隐藏工具。确认 agent 自我总结不能作为评分依据。确认评测脚本和任务配置一起提交版本库而不是只留存分数表。7.3 下一步可以从哪里入手长时程 AI 任务评测还在快速变化。当前最值得关注的扩展方向包括多智能体协作场景下的评分责任划分、任务执行中的实时干预机制、以及如何把评测结果转化为 agent 提示词和工具层的可操作修复项。对准备自己搭评测体系的团队第一步不必追求大而全。建议先选 5 到 10 个能覆盖“工具调用、长上下文、失败恢复”的任务跑通轨迹记录、规则评分、LLM 评分、人工抽检四个环节再逐步扩大任务数和模型数。对个人开发者最有价值的练习是把自己常用工具链里的一个重复性工作流程做成任务定义比如自动整理项目依赖、定时抓取网页监控变化、批量生成测试数据用单一模型跑一次完整轨迹然后按里程碑逐段复盘。通过这个过程比单纯看排行榜更能理解 27.3% 背后的真实原因模型不是不会说话而是还不会连续工作。