AI Agent 能力评测：从 METR 方法论到最小可用系统

“距全面AI接管仅剩6个月”——如果你最近在技术社区刷到这句话，第一反应大概率是怀疑。怀疑是对的。但比怀疑更有价值的，是弄清楚这句话到底从哪来、METR 是谁、所谓“6个月”是怎么被推出来的，以及它和我们日常做的 AI 工程有没有关系。如果只看标题，你可能会以为某个机构刚刚发布了末日倒计时；而真实情况要复杂得多，也远比“倒计时”更有技术含量。

METR 的全称是 Model Evaluation and Threat Research，翻译过来是“模型评测与威胁研究”，是一家专注评估前沿 AI 系统真实能力的非营利研究机构，前身是 ARC Evals，源自 Paul Christiano 创立的 Alignment Research Center（对齐研究中心）。METR 的日常工作不是预测世界末日，而是像一家“AI 系统的质检实验室”：设计一组组需要远程完成的数字化任务，让 AI Agent 独立去执行，然后系统地记录完成率、耗时、成功标准，与人类基线做对比，并跟踪这些指标随时间的变化曲线。

把一份复杂的“能力质检报告”压缩成“6个月全面接管”，本质上是用 10 个字的标题强行翻译一条充满条件、假设和边界的长曲线。本文想做的，是把这条曲线重新摊开：METR 的评测到底在测什么？“接管”这个词在技术上到底意味着什么？一线工程师能从这套评测方法论里借鉴什么，来评估自己正在开发的 AI Agent？读完你会得到一个更清醒的判断：AI 能力的提升是真实且迅速的，但“全面接管”的叙事恰好掩盖了评测里最有价值的部分——能力边界在哪里、哪些任务可靠、哪些任务只是看似能做。

1. 这篇文章真正要解决的问题

先说一个观察：从 2024 年开始，关于“AI 能力即将超越人类”“AGI 多少个月后到来”的讨论，密度明显上升。过去这类话题只存在于 AI 安全学术圈，现在却频繁出现在产品发布、开源项目和招聘 JD 里。原因不是某个机构喊了口号，而是 AI Agent 的能力确实在以肉眼可见的速度提升：能自主写代码的编程助手、能调用工具完成多步任务的项目管理 Agent、能自己跑测试并修复错误的工程智能体，都从 demo 阶段走向了实际应用。能力提升是真的，但“多久会全面接管”这种问题，本质上是把一条充满噪声的能力曲线强行压缩成一个时间点。

本文要解决的核心问题有三个。第一，METR 是谁，它发布的评测报告为什么值得看，又为什么容易被误读。第二，“6个月”这种说法在方法论上错在哪里，我们该如何正确理解前沿模型的评测数据。第三，也是和 CSDN 读者关系最大的：METR 的评测思路如何迁移到自己的项目里，用来评估你正在开发的 AI Agent。读完这篇文章，你应该能区分“能力提升”和“全面接管”之间的巨大落差，也能搭建一个最小可用的评测系统，用数据而不是感觉来判断 Agent 到底行不行。

这篇文章最适合三类读者：正在做 AI Agent 应用开发的工程师，需要给团队制定模型选型和能力验收标准的算法负责人，以及被各种 AI 时间表搞得焦虑、想搞清楚背后逻辑的技术从业者。如果你只是想知道“六个月后我是不是要失业”，那本文的结论会比较扫兴：靠标题算不出失业时间，但靠评测能算出你手里的模型适合做什么、不适合做什么。

2. METR 是什么：专门度量 AI 能力边界的研究机构

METR 的历史可以追溯到 Alignment Research Center 内部的评测团队。ARC 由 Paul Christiano 创立，核心方向是对齐研究，也就是研究如何让 AI 系统的行为符合人类意图。评测 AI 能力这件事需要大量工程投入、持续运营并且要长期跟踪，评测团队后来独立出来，成为今天的 METR。从组织属性看，METR 是非营利机构，不靠卖模型赚钱，也不押注某一家厂商，这在一定程度上保证了评测工作的独立性。

METR 的核心使命可以概括为一句话：在 AI 能力快速上升的窗口期，为人类社会提供可靠的“测量数据”。它不负责把模型做得更强，而是持续回答几个看似简单、实际上极难回答的问题：AI 系统现在能独立完成哪些任务？完成这些任务需要多长时间？需要人类干预到什么程度？完成质量是否稳定？随着时间推移，这些指标在往哪个方向移动？这些问题的答案，直接影响 AI 安全政策、企业技术选型和研究者对技术路线的判断。

围绕这些使命，METR 的研究大致分三个方向。

第一是任务完成率评测。研究者准备一组对远程工作者有实际意义的任务，比如整理公开数据、编写脚本、分析文档、管理表单，然后让 AI Agent 独立完成。评测标准不是“模型给出的回答是否流畅”，而是“任务最终是否被正确交付”。这种评测方式和我们在真实项目里验收一个外包开发者的标准很接近：只看结果文件是否合格，不看你中间写了多少行代码。

第二是时间效率度量。同样的任务，人类完成需要多久，AI Agent 完成需要多久？两者的比值随时间如何变化？这个指标之所以重要，是因为它直接决定了 AI 在真实业务流程中能替代多少人力。如果 AI 完成一个任务需要人类十倍的时间，那即使它能做，经济上也不划算；如果接近甚至快于人类，那工作流改造就是必然趋势。

第三是自主性与可靠性评估。AI Agent 能在多大程度上独立完成长链路任务？是每一步都需要人类确认，还是可以连续执行几十个操作直到交付？中途出错时能否自行发现并纠正？这种评测比单轮问答复杂得多，因为它关注的是“长时间自治运行”的能力，而这恰恰是 Agent 从 demo 走向生产环境时最关键的瓶颈。

从公开的研究方向看，METR 这类机构的工作重点已经开始从“模型能不能回答这个问题”转向“Agent 能不能在真实环境里把任务完成”。这个转向本身就是行业风向标：大家真正关心的已经不是模型的知识储备，而是模型在复杂工作流中的工程化能力。

3. “6个月接管”是如何被推出来的，又错在哪里

现在我们可以正面拆解“距全面AI接管仅剩6个月”这个说法了。要理解这句话怎么来的，先要理解评测数据为什么容易被误读。METR 这类机构在评测中确实观察到一个趋势：对于中等复杂度的远程数字化任务，前沿模型已经能以接近人类的速度完成其中一部分，而且这类能力的进步速度在加快。如果只截取任务完成率上升的那一段曲线，再做一个简单的外推，很容易得到“再过一段时间 AI 就能在所有任务上超越人类”的结论。

问题就出在这个外推过程上。第一，评测任务集是有限的。METR 评测的是经过筛选的数字化任务，这些任务有明确的验收标准，适合远程执行，而且覆盖范围有限。现实世界里的任务分布远比评测集广泛，大量工作涉及线下物理操作、复杂人际协调、模糊需求定义和长期责任承担，这些都不在评测范围内。从“评测集中的任务完成率提升”推出“全面接管”，相当于用一份抽样调查的样本直接断言总体的全部特征。

第二，能力不等于可靠性。评测中一个任务完成，意味着在特定条件下拿到了一次成功的结果。但在生产环境中，我们要求的是稳定交付：同一个任务给 AI 做一百次，成功率是多少？遇到边缘输入时行为是否可预测？失败时能否安全降级？评测报告中的“完成率”通常反映的是能力上限，而生产系统需要的是一致性和鲁棒性。把能力上限当作平均表现来谈论，是很多 AI 焦虑叙事的共同逻辑错误。

第三，“接管”这个概念在技术上没有清晰定义。是指 AI 在多数远程白领任务上达到人类速度？是指某个领域里 AI 能自主完成端到端流程？是指企业在招聘时发现 AI 比人便宜？这三种“接管”对应完全不同的时间表和条件边界。标题把最极端、最模糊的解读拿出来，恰恰是因为越模糊越有传播力。真正做技术的人不应该被这种模糊性带着走，而应该把问题拆成可测量的指标：哪些任务、什么成功率、什么成本、什么监督条件。

第四，也是方法论上最致命的一点：时间外推的稳定性极差。AI 能力的提升不是匀速直线运动，而是分阶段、分领域、受数据、算力、算法创新和工程投入共同影响的复杂过程。任何一个变量出现瓶颈，都会让外推曲线彻底失效。2023 年很多人用同样的方法预测“GPT-5 马上会改变一切”，结果是模型迭代节奏、算力约束和数据的实际状况都远比线性外推复杂。对时间表的过度自信，本质上是对复杂系统缺乏敬畏。

4. METR 评测方法论：任务集、完成率、时间与自主程度

与其纠结“6个月”这个时间点，不如把注意力放在 METR 评测方法论本身。这套方法论对 AI 工程师有直接借鉴价值，因为它把“模型好不好”这个模糊问题转化成了几个可量化、可复现、可对比的指标。

第一个组件是任务集设计。评测的第一原则是任务必须可验收，也就是有明确的、客观的成功标准。比如“从给定网页中提取所有产品的价格，整理成 CSV 文件，包含产品名和价格两列，价格格式统一”，这个任务就有清晰的验收标准。相反，“写一段关于 AI 的评论文章”这种任务就难以客观验收。任务集还需要覆盖不同的难度层级，从 5 分钟能完成的简单操作，到需要连续执行 2 小时以上的复杂工作流，这样评测结果才能反映模型在不同复杂度下的表现差异。

第二个组件是完成率。对每个任务，AI Agent 要么成功交付，要么失败。把任务集中成功交付的比例算出来，就得到完成率。这个指标听着简单，但设计时有两个关键决策：一是失败的定义，超时算失败，格式错误算失败，中途人类介入算不算失败？二是多次尝试的处理，是只允许一次执行，还是允许 Agent 自我纠正后重试？这些决策直接决定完成率的含义。作为对比，传统的大模型评测（如 MMLU、GSM8K）考察的是单轮回答的正确率，而 Agent 评测考察的是端到端任务交付率，两者的工程含义完全不同。

第三个组件是时间指标。最常用的是“时间倍数”，也就是 AI 完成一个任务所用的时间除以人类完成同一任务的平均时间。时间倍数小于 1 意味着 AI 比人快，大于 1 意味着 AI 比人慢。这个指标对判断“是否值得用 Agent 替代某项人工流程”非常直观：如果一个任务的完成率是 80%，但时间倍数是 10，那这个 Agent 在成本上仍然没有优势；如果完成率 70%、时间倍数 0.8，那业务流程改造就变得非常现实。

第四个组件是自主程度分级。同一个任务，可以让人工在每一步确认，也可以让 Agent 连续执行完整链路。评测时通常会对任务执行过程中的交接次数和人工干预频率做记录。一个只能依靠人工频繁纠偏的 Agent，和一个能连续自主运行直到交付的 Agent，即使最终完成率相同，工程价值也完全不同。自主程度直接决定了 Agent 嵌入业务流程时需要的监督成本，而这恰恰是企业在落地 AI Agent 时最关注的问题。

最后一个关键是持续跟踪。单次评测只能反映某个时间点的能力快照。METR 这类机构的真正价值在于持续用同一套任务集反复评测，观察能力曲线的变化方向。同样的任务，三个月前完成率 20%，现在完成率 60%，这比任何口头宣称都更有说服力。做工程也是一样，把评测任务集沉淀下来，每次升级模型后重新跑一遍，你才能知道哪些能力真实提升了，哪些只是换了种说法。

5. 从评测到工程：时间跨度是 Agent 落地的核心瓶颈

METR 评测方法论中最值得工程师关注的，是任务时间跨度对完成率的显著影响。从大方向看，AI Agent 在短任务上的表现已经相当不错：写一段代码、整理一个表格、回答一个领域问题，这类 5 到 15 分钟能完成的任务，前沿模型的成功率已经很高。但随着任务时间跨度拉长到 30 分钟、1 小时、2 小时以上，完成率会出现明显的下降。这不是某个模型的偶然缺陷，而是当前 Agent 架构的系统性瓶颈。

为什么时间跨度对 Agent 这么难？原因可以从技术栈里找。第一是错误累积：长链路任务中，越长的执行序列意味着越多的潜在出错点，每一步的小错误都可能被后续步骤放大，最终导致整体失败。第二是上下文管理：长时间的自主运行会产生大量中间状态和工具调用记录，模型需要在长上下文中保持对目标的清晰理解，同时不被无关信息干扰，这是当前上下文窗口技术的薄弱环节。第三是状态跟踪：真实任务往往涉及外部系统的状态变化，Agent 需要持续判断“当前进行到哪一步了”“下一步的输入依赖什么”，一旦状态跟踪出错，后续所有操作都会建立在错误的前提上。

这个瓶颈对工程实践有直接启示。你在设计 AI Agent 应用时，不应该指望模型直接解决“两小时以上的长链路任务”，而应该主动把长任务拆成短任务。拆分的思路是：把任务切分成多个有明确中间产物的阶段，每个阶段由 Agent 独立完成，阶段之间用结构化的数据传递，并安排人工检查点。这样做虽然牺牲了一些自动化程度，但大幅提升了整体成功率，也更容易定位失败环节。换句话说，评测数据告诉你“长任务很难”，工程上就该把长任务变成短任务的串联。

另一个工程启示是：评测任务集要跟着业务走，不能只做通用能力测试。很多团队在选型时只跑几个公开 benchmark，得到一个总分就觉得自己了解了模型。但公开 benchmark 的任务分布和你的业务场景往往相差很大。更务实的做法是：从真实业务流程中抽取 20 到 30 个代表性任务，写出明确的验收标准，搭一套内部评测流水线，用统一的指标持续评估不同模型和不同版本。这就是把 METR 的方法论搬到自己的项目里，成本不高，收益却很直接：模型升级到底值不值得上线，不需要靠感觉，跑一遍数据就有答案。

6. 动手实践：搭建一个最小可用的 Agent 能力评测系统

说了一堆方法论，现在进入实操。这一节我会搭一个最小可用的 AI Agent 能力评测系统，核心目标是用一套脚本完成三件事：定义任务、执行任务、统计结果。这个系统不是玩具，它足够支撑小团队跑通内部评测流程，后续也可以扩展成更完整的评测平台。

6.1 环境准备与前置条件

本文示例使用 Python 3.10 以上版本，只需要标准库，不依赖第三方框架，便于直接复现。你的机器需要有 Python 环境，被评测的 Agent 可以是任意形式：一个命令行脚本、一个调用大模型 API 的 Python 程序、甚至是一个 Docker 容器。评测系统通过子进程方式调用 Agent，以“退出码 + 标准输出”作为最基本的成功判断。你可以在自己的项目里把这一层替换为更复杂的判定逻辑。

项目结构（示意）： agent-eval/ ├── eval_tasks.py # 任务集定义 ├── runner.py # 评测执行器 ├── report.py # 结果统计 ├── agent_worker.py # 示例 Agent（被评测对象） └── results/ # 评测结果输出目录

6.2 定义评测任务集

任务集是整个评测系统的基础。每个任务需要包含唯一 ID、任务名称、类别、人类基线耗时（用于计算时间倍数）、成功标准和运行约束。下面的示例定义了三个典型任务：信息检索、代码生成和数据处理。

# eval_tasks.py # 定义最小评测任务集。实际项目中建议把任务集放到 JSON/YAML 文件， # 方便产品和算法同学共同维护。 TASKS = [ { "id": "tsk_001", "name": "竞品价格调研", "category": "information_retrieval", "human_baseline_minutes": 30, "success_criteria": "输出包含至少5家竞品的定价明细，并标注信息来源链接", "allow_external_access": True, }, { "id": "tsk_002", "name": "CSV 数据清洗", "category": "data_processing", "human_baseline_minutes": 45, "success_criteria": "生成可运行的 Python 脚本，过滤无效行并输出清洗后的 CSV", "allow_external_access": False, }, { "id": "tsk_003", "name": "接口文档生成", "category": "documentation", "human_baseline_minutes": 20, "success_criteria": "根据给定接口定义生成 Markdown 格式的调用文档", "allow_external_access": False, }, ]

任务集设计有两个要点：一是验收标准必须客观，避免“写得不错”“质量还行”这类主观判断；二是基线耗时要有依据，最好从团队真实执行经验里统计，而不是拍脑袋。如果基线不准，后面的时间倍数指标就没有意义。

6.3 实现评测执行器

执行器负责把任务交给 Agent 运行，记录开始时间、结束时间、输出和错误信息。这里通过 subprocess 调用一个统一的 Agent 入口，单任务设置了超时保护，避免某个任务卡死整个评测流程。

# runner.py import json import time import subprocess from pathlib import Path from datetime import datetime from eval_tasks import TASKS AGENT_CMD = ["python", "agent_worker.py"] # 被评测 Agent 的入口命令 MAX_RUN_MINUTES = 120 # 单任务超时保护 OUTPUT_DIR = Path("results") OUTPUT_DIR.mkdir(exist_ok=True) def run_single(task: dict) -> dict: start = time.time() record = { "task_id": task["id"], "task_name": task["name"], "started_at": datetime.now().isoformat(), "completed": False, "duration_minutes": None, "stdout_tail": None, "error": None, } task_file = OUTPUT_DIR / f"{task['id']}.task.json" task_file.write_text(json.dumps(task, ensure_ascii=False, indent=2), encoding="utf-8") try: proc = subprocess.run( AGENT_CMD + [str(task_file)], capture_output=True, text=True, timeout=MAX_RUN_MINUTES * 60, ) record["duration_minutes"] = round((time.time() - start) / 60, 2) record["completed"] = proc.returncode == 0 record["stdout_tail"] = proc.stdout[-2000:] if proc.stdout else "" record["error"] = proc.stderr[:2000] if proc.stderr else None except subprocess.TimeoutExpired: record["duration_minutes"] = float(MAX_RUN_MINUTES) record["error"] = "timeout" return record if __name__ == "__main__": all_records = [run_single(t) for t in TASKS] (OUTPUT_DIR / "latest_run.json").write_text( json.dumps(all_records, ensure_ascii=False, indent=2), encoding="utf-8", ) for r in all_records: status = "PASS" if r["completed"] else "FAIL" duration = r["duration_minutes"] if r["duration_minutes"] is not None else "-" print(f"{status} {r['task_id']} {r['task_name']} {duration}min")

这段代码里最核心的设计是“以退出码判断成功”。这不是最好的方式，但它是成本最低、最不容易出错的方式。真实项目中，完成判断往往需要更复杂的逻辑：检查输出文件是否存在、解析输出内容、比对验收标准。这些都可以在 runner 里扩展，但不要把第一步做得太复杂，先跑通再完善。

6.4 实现一个最小可用的示例 Agent

为了让评测系统完整可运行，这里提供一个示例 Agent。它模拟真实 Agent 的行为：读取任务文件，根据任务类型返回成功或失败。在真实项目中，这个文件内部应该是对大模型 API 的调用、工具调用的编排和结果处理逻辑。

# agent_worker.py # 最小示例 Agent：真实项目中替换为对模型 API / Agent 框架的调用。 import sys import json from pathlib import Path def run_agent(task: dict) -> int: # 示例策略：tsk_002 和 tsk_003 直接模拟成功， # tsk_001 因示例环境不允许外部访问而模拟失败。 if task["id"] in ("tsk_002", "tsk_003"): print(json.dumps({"status": "ok", "task_id": task["id"]}, ensure_ascii=False)) return 0 print(f"task {task['id']} failed: external network not allowed", file=sys.stderr) return 1 if __name__ == "__main__": task = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8")) sys.exit(run_agent(task))

这里的重点是评测协议的设计：任务文件入参、退出码返回、标准输出和标准错误分离。只要你的 Agent 遵守这个协议，评测系统就不用关心 Agent 内部用了什么模型、什么框架。这种解耦让评测系统可以横向对比不同 Agent 实现。

6.5 实现结果统计脚本

最后一步是统计结果。我们需要计算三个核心指标：任务完成率、平均耗时、以及相对人类基线的时间倍数。这些指标汇总成一份 JSON 报告，方便后续对比不同模型版本。

# report.py import json from pathlib import Path from eval_tasks import TASKS def load_results(path="results/latest_run.json"): return json.loads(Path(path).read_text(encoding="utf-8")) def summarize(records): total = len(records) completed = sum(1 for r in records if r["completed"]) completion_rate = completed / total if total else 0 time_multipliers = [] for r in records: task = next((t for t in TASKS if t["id"] == r["task_id"]), None) if task and r["duration_minutes"]: human_min = task["human_baseline_minutes"] time_multipliers.append(r["duration_minutes"] / human_min) avg_time_multiplier = ( round(sum(time_multipliers) / len(time_multipliers), 2) if time_multipliers else None ) return { "total_tasks": total, "completed_tasks": completed, "completion_rate": round(completion_rate, 3), "avg_time_multiplier_to_human": avg_time_multiplier, "records": records, } if __name__ == "__main__": summary = summarize(load_results()) print(json.dumps(summary, ensure_ascii=False, indent=2))

到这里，一个最小评测系统就完成了。你不需要一开始就做复杂的评估平台，这套脚本已经能回答最基础的问题：Agent 能不能完成任务、要多久、成功率是多少。后面所有扩展——多模型对比、历史趋势、失败分析、回归测试——都可以在这个骨架上生长。

7. 运行验证与结果分析

评测系统写完后，按顺序执行两个命令就能看到结果。

# 第一步：运行评测 python runner.py # 第二步：查看统计报告 python report.py

按照示例代码，runner.py 的输出应该是：

FAIL tsk_001 竞品价格调研 0.02min PASS tsk_002 CSV 数据清洗 0.03min PASS tsk_003 接口文档生成 0.02min

report.py 的输出类似：

{ "total_tasks": 3, "completed_tasks": 2, "completion_rate": 0.667, "avg_time_multiplier_to_human": 0.001, "records": [...] }

如何判断这次评测是否有效？先看三个层面。第一，任务是否真的被执行了。示例 Agent 是模拟实现，所以记录里显示的是近似 0 分钟，真实项目中 agent_worker.py 会调用模型 API，耗时会有实际意义。第二，失败原因是否被记录。tsk_001 失败时，stderr 里写明了原因，后续排查时应该能看到完整错误日志。第三，结果文件是否完整。最新结果统一写在 results/latest_run.json 里，任何一次运行都会覆盖这个文件，建议在真实项目中加上时间戳归档。

如果运行失败，按下面顺序排查：首先确认 Python 版本是 3.10 以上，标准库程序一般不涉及依赖问题；其次检查 agent_worker.py 是否在项目根目录，因为 runner.py 里用的是相对路径；最后检查 results 目录是否有写入权限。如果 agent_worker.py 内部调用了大模型 API，还要确认 API Key 等环境变量是否配置正确。这里有一个容易踩坑的细节：subprocess.run 的 timeout 参数是按秒计算的，如果 MAX_RUN_MINUTES = 120，实际超时时间是 7200 秒，修改配置时要注意单位。

8. 常见误读与排查思路

围绕 AI 能力评测，“6个月接管”只是误读的冰山一角。下面这张表汇总了我在实际讨论和工程实践中经常遇到的误读，以及对应的排查思路。这些误读不只在媒体传播中出现，在团队内部的技术讨论里同样普遍，值得每个做 AI 应用的人警惕。

除了表格里的误读，还有一个工程上常见的排查场景：Agent 评测结果波动大。同一套任务集，不同时间跑出来的完成率差很多。这个问题通常有三个原因。第一是模型 API 的非确定性，温度参数设置、采样策略都会导致输出变化，排查时先确认评测时是否固定了采样参数。第二是外部依赖不稳定，比如任务涉及第三方网站或数据库，对方接口抖动会直接影响评测结果，排查时看失败任务的错误信息是否集中在外呼环节。第三是任务集本身设计不严谨，验收标准存在歧义，导致 Agent 每次交付的文件内容不同但都被判为成功。建议每次评测前先确认模型配置、外部依赖状态和验收标准的版本，保证对比有意义。

9. 最佳实践与工程建议

这套评测系统虽然简单，但把它用好，需要一些工程上的约束和习惯。以下是几个我建议在任何 AI Agent 项目中尽早落实的实践。

第一，把评测任务集当成一等公民来维护。任务集不是一次性的测试数据，而是团队对“AI 能力范围”的共同约定。任务集需要版本管理，每次新增任务要经过评审，验收标准要写清楚。建议把任务集放到 Git 仓库里，和代码一起变更、一起评审。模型升级、提示词修改、Agent 框架调整，都要跑一遍同一版本的任务集，用历史数据判断变化方向。

第二，评测环境要与生产环境隔离，但数据要有代表性。真实业务数据往往涉及用户隐私和商业机密，不能直接拿去评测。更稳妥的做法是构造一批脱敏的虚拟任务，任务结构尽量贴近真实场景，但可以公开测试。与此同时，评测运行时要注意权限边界：给 Agent 的评测环境应当是受限的，禁止访问生产数据库、禁止调用生产 API，尤其是涉及写操作的任务，一定要在测试环境验证。评测系统的权限设计要遵循最小权限原则，Agent 只能访问完成任务必需的最小资源集。

第三，不要只记录“成功/失败”这种二元结果。至少要记录失败阶段和错误类型：是任务理解失败、工具调用失败，还是结果验证失败？这些信息对定位问题至关重要。建议在 runner 里增加一个 stage 字段，或者在错误日志里统一格式，方便后续做统计分析。真实项目中，我见过太多团队只保留完成率，结果模型升级后完成率下降，却完全不知道降在哪一类任务上，排查成本极高。

第四，评测不是一次性的，要跑成常态化回归。AGI 能力的快速变化意味着你今天测出的完成率，三个月后可能完全不一样。模型厂商会更新版本，你的提示词会调整，Agent 框架会升级，这些变化都可能影响最终表现。最好的做法是配置定时任务，每周或每两周跑一次完整评测，把结果归档到带时间戳的文件里，形成能力趋势曲线。这个曲线对团队的技术决策价值极高：投资新功能之前，先用数据判断现有能力的基线在哪里。

第五，注意评测结果的安全使用。如果你的 Agent 评测涉及模型安全能力（比如拒绝有害指令、权限边界、数据隔离），这类结果不要随意公开，也不要在团队外传播。模型能力评测数据本身也是敏感信息，建议按最小范围共享。涉及权限、认证、数据库操作等安全相关任务的评测，尤其要提前确认操作是在合法的测试环境、且有完整的备份和回滚方案后执行。

回到最初的话题：METR 的评测报告值得关注，不是因为“6个月接管”这种耸动结论，而是因为它用一套清晰的方法论告诉我们如何测量 AI 的真实能力边界。把同样的方法论用在自己的项目里，定期测量、记录趋势、分析失败，这才是一个 AI 工程师面对各种技术叙事时最该有的姿态。下一次你看到“AI 多少个月内实现什么”的标题时，不妨问一句：这个结论是基于什么任务集、什么成功率、什么监督条件得出来的？问完这些问题，你大概率会发现，AI 能力的增长确实值得认真对待，但真正需要你紧张的，不是某个时间点，而是你自己有没有一套可靠的测量方法来跟上变化。