文章从Why、What、How三维度剖析AI Agent评测体系，强调评测是与不确定性博弈的关键能力。详解了编程、对话、研究、GUI四类智能体的评测方法，包括任务定义、评分器设计和执行轨迹分析。提供了从构建评测数据集到设计评测系统，再到长期维护与使用的完整路线图，强调评测能让团队客观衡量质量变化，加速Agent规模化迭代，成为跨团队沟通的桥梁。
知行合一
Agent的开发，本质上是一场与不确定性博弈的过程。
而评测，正是这场博弈中最关键、也最容易被低估的能力。
本文我会从 why / what / how 三个维度，深度剖析Anthropic最新发布的万字评测方法论，包含多种类型和场景。
最后会提供一份从0到1打造优秀评测体系的路线图。
Why: 为什么要建立评测？
大多数团队都忽视了benchmark的重要性，甚至将严格的评测视为减缓交付不必要的开销。
临界点发生在“自我感觉良好”到“出现故障越改越糟”，在没有评测指标的情况下，调试是极其被动的。
盲目调试无法区分真正的退化与噪音，无法在发布前自动测试更改对数百种场景的影响，也无法衡量改进程度。
那么有评测（evals）呢，不限于如下3点优势：
- 让团队“看得见”质量变化，把主观感受变成客观指标，避免盲目迭代，清晰区分“真实回归”与“随机波动”。
- 评测是Agent规模化迭代的加速器，轻松获取质量基准与回归影响（延迟、令牌使用量、每项任务的成本和错误率），快速判断新模型是否值得切换、优势在哪、短板在哪。
- 评测也是产品团队、工程团队、算法团队之间的沟通利器，轻松对齐Agent成功标准、边界条件和期望行为。
What：评测是什么
既然评测这么重要，那么评测是什么呢？
评测（eval）简单来说，是给AI系统一个输入，然后对其输出打分衡量成功。
在实践中，是建立一套在开发过程中无需真实用户即可运行的自动化评测系统。
简单的AI系统单轮评估就可以，如下图Single-turn所示，一句prompt得到一个响应，设置一个评分逻辑。
Agent系统则更为复杂，多次调用工具、修改环境状态，并不断循环调整，这就可能导致错误蔓延和累积。
先来了解一下在构建Agent评测时，几个概念：
- 任务（Task）：用例case，明确定义输入和成功标准的单一测试；
- 试验（Trial）：对同一任务的一次完整执行。由于模型的随机性，需要多次试验以获得更一致的结果；
- 评分器（Grader）：用于评估Agent表现的评分逻辑。一个任务可以包含多个评分器，每个评分器由多个断言（Assertions）构成，检查不同维度表现。
- 运行轨迹（Transcript）：记录Agent一次试验的完整执行过程，包含模型输出、工具调研、推理步骤、中间结果及其他交互信息。
- 结果（Outcome）：试验结束时环境的最终状态。比如AI说已完成航班预订，在数据库中是否存在预定。
- 评测运行环境（Harness）：评测的基础设施，提供指令和工具、并行运行任务、记录执行过程、评分输出并汇总结果。
- 评测集（Evaluation Suite）：衡量特定功能或行为的任务集合，多个任务共享一个评测目标，用于系统性衡量Agent的整体表现。
How：如何评测AI Agents
Agent评测通常组合这三种类型的评分器：基于代码的、基于模型的，以及人工打分。
对于不同的任务，评分可以是加权的（组合评分器分数必须达到阈值）、二元的（所有评分器必须通过）或混合的。
当然，测评也离不开常规的能力评测和回归评测：
- 能力评测关注该Agent擅长做什么，设定一些有挑战性的任务。
- 回归评测是在每次修改后回归一下之前的任务，避免引起其他问题。
接下来我们依次看下目前常见类型的Agent如何评测，包括：编程智能体、对话智能体、研究智能体，以及使用计算机的Agents。
01
评测编程智能体
针对Coding Agent的评测依赖于明确指定的任务、稳定的测试环境，以及生成代码的全面测试。
因为代码是否运行、测试是否通过，都是明确的，所以需要确定性的评分器。
目前编程Agent广泛使用的两种基础测试，SWE-bench Verified和Terminal-Bench，都遵循这种方法。
- SWE-bench Verified：向Agent提供主流phthon仓库的github问题，通过运行测试任务组来评分，只有修复了bug且没有破坏现有功能，才算通过。一年内，这项评估表现已从40%提升至80%+。
- Terminal-Bench：测试端到端的技术任务，例如从源代码构建linux内核或训练机器学习模型。
在实践中，编程任务会从三个方向测评，优先做单元测试验证代码正确性，并使用LLM评分标准评估代码质量，在需要时添加额外的评分器和指标评测过程**。**
以“修复身份验证并绕过漏洞”任务为例，展示一个评分器的字段设计：
task: id: "fix-auth-bypass_1" desc: "Fix authentication bypass when password field is empty and ..." graders: - type: deterministic_tests required: [test_empty_pw_rejected.py, test_null_pw_rejected.py] - type: llm_rubric rubric: prompts/code_quality.md - type: static_analysis commands: [ruff, mypy, bandit] - type: state_check expect: security_logs: {event_type: "auth_blocked"} - type: tool_calls required: - {tool: read_file, params: {path: "src/auth/*"}} - {tool: edit_file} - {tool: run_tests} tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token02评测对话智能体 对话Agent与传统聊天机器人不同，Agent维护状态、使用工具，并在对话中途采取行动。 对话智能体有一个独特的挑战是：交互的质量也是要评测的部分。 因此对话智能体必须同时评测结果和交互过程，甚至需要用另一个 LLM 来扮演用户，通过长时间的对抗性对话来测试模型效果。 基准测试可以参考𝜏-Bench 及其后续版本τ2-Bench，模拟了跨零售支持、航空预订等领域的多轮交互。 评测维度参考如下： * 状态检查：比如是否订票成功 * 文本约束：是否在10轮内完成 * LLM评分：语气是否恰当 以“处理沮丧客户退款请求”为例，评分器设计如下：code-snippet__js graders: - type: llm_rubric rubric: prompts/support_quality.md assertions: - "Agent showed empathy for customer's frustration" - "Resolution was clearly explained" - "Agent's response grounded in fetch_policy tool results" - type: state_check expect: tickets: {status: resolved} refunds: {status: processed} - type: tool_calls required: - {tool: verify_identity} - {tool: process_refund, params: {amount: "<=100"}} - {tool: send_confirmation} - type: transcript max_turns: 10 tracked_metrics: - type: transcript metrics: - n_turns - n_toolcalls - n_total_tokens - type: latency metrics: - time_to_first_token - output_tokens_per_sec - time_to_last_token03评测研究智能体
Research Agent收集、综合和分析信息，然后产出答案或报告。
研究质量的评测无法像代码一样做二元判断，而需要通过任务评估：什么算是“全面的”、“有良好来源的”、“正确的”。
构建Research Agent评估的一种策略是结合不同类型的评分器。
三种关键检查维度：
- 有依据性检查：验证是否真的能在它引用/检索的资料中找到依据；
- 覆盖度检查：定义了一个优质答案必须哪些关键事实，避免漏掉核心信息；
- 来源质量检查：确认所参考的来源是否权威
如果是客观、有单一正确答案的问题，没必要复杂化，直接精确匹配即可。
LLM在这里扮演一个结构化质检员，用于标出没有证据支持的说法、该讲没讲的重点、评测综合性回答是否逻辑连贯、信息完整。
此外，由于研究质量的主体性，基于LLM的评分标准应该频繁与人类专家进行校准。
04
评测GUI智能体
GUI Agent通过模仿人类使用电脑软件——截图、键盘键入、鼠标点击和滚动…
评测需要在真实或沙盒环境中运行Agent，使其能够使用任何具有GUI的应用程序，并检查是否达到预期结果。
比如WebArena和OSWorld测试：
- WebArena：浏览器任务测试，基于 URL 和页面状态来验证前端执行，通过修改数据的后端状态验证任务是否完成任务。比如：确认订单实际提交，而不仅仅是确认页面出现。
- OSWorld：完整的操作系统控制，在执行完脚本完成任务后检查文件系统状态、应用程序配置、数据库内容和UI元素属性。
浏览器任务操作需要在token和延迟之间权衡：
- 基于DOM的交互执行速度快但消耗大量token（适合文本类任务，如总结维基百科信息）
- 基于截图的交互速度较慢但token消耗少（适合图片比如在亚马逊上寻找新手机壳）
所以评测时需要检查Agent是否选择了正确的工具。
05
非确定性测评
由于Agent每次运行都存在不确定性，想要测量Agent在某个任务上的成功频率，可以使用pass@k和pass^k两个指标：
随着试验次数的增加，两者的变化趋势如下图。
从0到1构建优秀评测路线图
接下来，我们看下构建一个评测驱动的Agent开发路线图：早期定义成功，清晰衡量，并持续迭代。
阶段一：构建评测数据集
Step 0 少量测试集启动
将产品需求转换为20-50个简单任务就是一个好开始。
因为早期Agent开发中，每次微小的变更都会系统有明确、显著的影响，前期小样本就足够了。
Step 1 人工深度评测
“Look at your data.”
打造AI产品就一定要亲自深度使用，分析Agent执行轨迹各个节点的信息，并将线上问题转换为测试用例。
Step 2 明确任务标准
评测任务需要有明确的标准。
如果一个任务让两个专家得出了不一致的答案，那不是Agent问题，而是任务问题。
评测的所有内容都应该在任务描述中显式说明，不能有默认路径、默认文件名、默认状态等。
一个小tips：为每个任务创建参考答案（reference solution），证明任务是可解的，并验证评分器设计正确。
Step 3 构建均衡的问题集
评测不能只奖励一种行为，否则模型会无限放大该行为。
比如测试“该搜索时有没有搜索？”，那么模型学到的最优策略是“那我干脆什么都搜索吧。”
所以，在设计测试case时，同一个能力必须同时覆盖“正例”和“反例”。
- “该搜索的时候一定搜索”
- “不该搜索的时候坚决不搜”
出现问题需要修改prompt与调整eval之间多轮迭代，Agent效果 = prompt ✖️ eval 共同塑形。
此外，评测数据集不是一次性设计，随着更多case出现，持续丰富eval suite提升覆盖范围。
阶段二：设计评测系统
Step 4 构建稳定的测评环境
测评环境要与生产环境一致，避免测试环境引入的噪声。
此外，每一次试验都必须是干净隔离的，避免不必要的共享状态（如遗留文件、缓存数据、资源耗尽等）引起不稳定性。
Step 5 精心设计评分器
如何判分呢？这是设计哲学，也是成本✖️稳定性✖️可信度的平衡。
Anthropic给出了三条大原则：
- 优先使用确定性规则，快、便宜、可复现；
- 必须有灵活性或主观判断时，才引入LLM评分；
- 人类只做校准、兜底和抽查；
在设计评分器时，有如下5条经验：
- Agent有灵活性，避免锁死路径，优先看结果；
- 针对多步骤任务，一定要设计「部分评分机制」，看中间步骤执行情况；
- LLM评判需要人类校验，避免幻觉式评分和硬判分数；
- 低分先怀疑eval，再怀疑Agent；
- Agent是个聪明对手，假设它会作弊，设计上要提防漏洞、边界等；
阶段三：长期维护与使用
Step 6 定期查看日志
当分数低时，问题出在agent? prompt? harness? grader?
这就需要定期查看Agent行为轨迹日志（transcript），从行为细节中获取低分真相：
- Agent奇怪但合理的解法
- Prompt中某句话被模型误解的方式
- Eval harness的隐含约束
- grader的边界bug
真正重要的改进点不会直接体现在分数上，而是在transcript中。
Step 7 监控能力评测“饱和”
当eval通过率接近100%时，就已经从「能力评测」退化到「回归测试」了。
随着评测接近饱和，分数变化不明显，剩下的要么是极端困难任务，要么是评测本身设计有问题。
以SWE-Bench为例，从30%优化到80%后，再往上每提升1%，需要巨大的工程、推理、规划能力跃迁，但在分数上几乎看不出来。
这时候就需要深入研究评测细节和行为日志，设计一个新的评测框架。
Step 8 开放贡献和长期维护
评测不是项目交付物，而是长期资产。
在Anthropic，建立了专门评测团队来负责基础设施，同时领域专家和产品团队负责贡献大部分评测任务并自行运行评测。
以评测驱动开发：在Agent能够实现这些功能之前，先构建评测来定义计划中的能力，然后不断迭代直到Agent表现良好。
比如基于对几个月后模型能做什么的预测，设计一些功能任务，当有新模型发布时，运行评测集可以快速揭示哪些赌注成功了。
此外，最接近产品需求和用户的人最适合定义任务，需要让更多的人参与评测集的构建。
阶段四：完备的优化
自动化评测，是 Agent 在上线前最重要的质量底座。
但要真正理解一个 Agent 的完整性能，还必须结合生产监控、用户反馈、A/B 测试、人工转录审查以及系统化的人类评估，形成多层次的评估体系。
这些方法，分别对应着智能体开发的不同阶段：
- 发布前 & CI/CD 阶段
自动化评测是防止质量问题的第一道防线。每一次 Agent 改动、Prompt 调整或模型升级，都会触发评测，确保问题在触达用户前被发现。 - 发布后运行阶段
生产监控用于捕捉分布漂移和真实环境中的异常行为，弥补离线评测无法覆盖的现实复杂性。 - 流量充足、验证重大改动时
通过 A/B 测试，在真实用户场景中比较不同方案的效果，用数据验证决策。 - 持续运营过程中
用户反馈和对话转录审查是长期机制：持续分流和分析用户反馈，每周抽样阅读对话记录，必要时深入追查潜在问题。 - 主观性强或高风险场景
系统化的人类评估作为“最后的校准器”，用于校准 LLM 评分器，或评估高度主观的输出质量，以人类共识作为最终参考标准。
如何系统的学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
一直在更新，更多的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇
01.大模型风口已至：月薪30K+的AI岗正在批量诞生
2025年大模型应用呈现爆发式增长，根据工信部最新数据：
国内大模型相关岗位缺口达47万
初级工程师平均薪资28K（数据来源：BOSS直聘报告）
70%企业存在"能用模型不会调优"的痛点
真实案例：某二本机械专业学员，通过4个月系统学习，成功拿到某AI医疗公司大模型优化岗offer，薪资直接翻3倍！
02.大模型 AI 学习和面试资料
1️⃣ 提示词工程：把ChatGPT从玩具变成生产工具
2️⃣ RAG系统：让大模型精准输出行业知识
3️⃣ 智能体开发：用AutoGPT打造24小时数字员工
📦熬了三个大夜整理的《AI进化工具包》送你：
✔️ 大厂内部LLM落地手册（含58个真实案例）
✔️ 提示词设计模板库（覆盖12大应用场景）
✔️ 私藏学习路径图（0基础到项目实战仅需90天）
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
