6份值得参考的Agent评测白皮书

Agent 项目最容易卡住的地方，通常是能不能说清楚它到底行不行，搭建本身反而没那么难。美团技术团队在 2026 年 9 月发布的《Agent 评测白皮书》系列里提到一个观察，过去三年绝大部分 Agent 项目没有走完冷启动、扩量和全量，常见结局是停在 Demo、卡在扩量、说不清业务价值。中国信通院在 2026 年 4 月发布可信 AI 智能体评估体系 2.0，累计为 50 余家单位提供智能体专项评估服务。两件事放在一起看，评测正在从项目尾声的验收动作，变成 Agent 立项时就要准备的基础设施。ThinkingAI 在服务全球 1500 家企业、接入产品超 8000 款的过程中，也反复遇到同一个问题，团队有演示，也有真实场景，缺的是一套能解释好与不好的判断标准。

这份清单挑了 6 份公开资料，覆盖评测方法、质量框架、生产运维、安全失败模式、企业评估体系和开发实践。它们解决的问题不同，不需要每份都从头读到尾。先看分工，再决定从哪份开始。

一、先看结论，6 份资料怎么分工

如果时间有限，先读三份。美团的白皮书给你完整流程，Google 的《Agent Quality》给你质量维度，Microsoft 的分类给你失败清单。要做选型或验收，再加中国信通院；要从零开发，再加 OpenAI。

下面按从方法到落地的顺序，逐份说明内容、值得读的地方和适用团队。

二、美团《Agent 评测白皮书》系列，把评测从理念拆到执行

美团技术团队在 2026 年 9 月发布《Agent 评测白皮书》系列，计划分四篇，分别是评测全览、冷启动、扩量、自进化。第一篇已经把整套框架讲清楚，核心可以记成一句话，四个模块、三种能力、两条 Loop、一套资产。

1. 它把评测拆成四个模块

四个模块分别是离线评测、在线评测与监控、Case 挖掘与归因、观测基建。离线评测负责版本变更后的回测，重点是固定评测集和固定执行环境，同一个 Task 要跑多次，用 Pass@k 或通过率看稳定结论，再把回测接进 CI/CD，门禁才有约束力。在线评测与监控负责真实环境的反馈，AB、影子模式、巡检看质量，Skill 成功率、Token 消耗、耗时看运行状态。在线评测回答系统工作得好不好，监控回答系统有没有在正常工作，两件事不能互相替代。

Case 挖掘与归因是整套体系的枢纽。线上反馈、监控异常、规则筛选和随机采样把样本收进 Case 池，再通过 Trace 定位问题发生在哪一层。Good Case 沉淀成黄金集，Bad Case 沉淀成错题集。归因之后有两条路径，一条修 Agent，一条校验评测标准本身是否判错了。很多团队只走第一条，结果把 Agent 优化成迎合评测标准，离用户问题越来越远。

两条 Loop 让体系持续运转。Agent 迭代 Loop 负责提升能力，评测体系迭代 Loop 负责校准量具，二者在 Case 挖掘与归因处共享入口，在评测集处共享资产。三种能力是发现问题、定位问题、驱动演进。一套资产指端到端和过程两类评测集，它们是评测体系的长期价值。端到端评测回答事情有没有办成，过程评测回答中间哪一步出了问题。离线守已知，在线发现未知。

图 1，评测体系的四个模块与两条 Loop

2. 三个失败场景都能对上

停在 Demo 的项目，演示往往不差，问题出在评测集覆盖不住真实流量里的问法、脏数据和场景边界。卡在扩量的项目，通常说不清问题出在哪一层，改完也不知道会不会把原来对的地方弄坏。说不清业务价值的项目，通常没有基线，模型换了几轮、Prompt 改了几十版，拿不出证据。美团白皮书里的三个失败场景，和很多团队的Agent 落地失败模式能一一对上。

这份白皮书的可信度来自实践。它来自美团评测团队在多个业务里的打磨，文中用商家经营分析 Agent 做贯穿案例，多步骤、多 Skill 调用、有中间产物、没有唯一答案，接近真实的长程 Agent。作者也明确说，评测是一门实践科学，做法迁移到新场景时仍要结合业务调整，不要照搬步骤。

3. 先用它做一次成熟度自查

这份系列适合评测负责人、Agent 产品、研发、算法和运营负责人。最实用的读法是先看第一篇的成熟度自查表，找出自己业务最短的那块板。冷启动阶段，观测 L1、评测集 L1、回测门禁 L1 就足以支撑最小闭环；扩量阶段再把评测标准和在线评测推到 L2；全量运营阶段才需要考虑 L3 的自动化与规模化。

不要一上来照着全景图搭全套，那样投入产出不划算。先读评测全览，再读冷启动篇，手里有项目时再对照扩量篇和自进化篇。如果项目正卡在扩量，优先看过程评测和 Case 归因两节。

三、Google《Agent Quality》白皮书，把质量拆成四个支柱

Google 在 2025 年 11 月发布《Agent Quality》白皮书，属于 Google 5-Day AI Agents 系列的第 4 篇。它讨论的问题很直接，传统软件测试假设输入固定、路径唯一、输出可预测，Agent 不满足这三个假设，质量保障需要换一套方法。

1. 四个质量支柱和两层评估

四个质量支柱分别是有效性、效率、鲁棒性、安全性与对齐。有效性看 Agent 有没有完成用户目标，不只看它生成了什么，还要看结果能不能用。效率看完成一个任务用了多少 Token、多少步骤、多少时间。鲁棒性看遇到 API 故障、模糊指令、脏数据时，系统能不能优雅降级。安全性与对齐看有没有偏见、隐私泄露、有害指令执行和越权操作。

评估分两层。黑盒评估由外而内，看最终输出，常见指标是任务成功率、用户满意度、整体质量。白盒评估由内而外，看执行轨迹，检查规划是否合理、工具选择是否正确、参数是否准确、RAG 检索是否相关、多 Agent 协作有没有死循环。两层都需要，只有黑盒会知道坏了但不知道哪坏了，只有白盒会出现每个模块都达标但用户就是不满意。

支撑评估的是可观测性三支柱，日志、追踪、指标。白皮书把三者整合成 Agent 质量飞轮，先定义质量，再评估，再观测，再把洞察送回改进。飞轮转起来，评测才能变成持续动作。

2. 它把轨迹放到了评估中心

白皮书里有一句很关键的判断，轨迹即真相。最终答案只是最后一句，Agent 的规划、工具调用、中间结果和环境交互，才是质量的主要来源。多步 Agent 的错误会传播，一步错可能步步错，只看最终输出会漏掉工具误用、冗余步骤和看起来合理的幻觉。

在评判方法上，它没有把希望全押在自动化指标上。自动化指标适合回归测试，LLM-as-judge 适合规模化评分，Agent-as-judge 适合看完整推理轨迹，人在回路适合处理领域细节、语气、伦理和复杂意图。白皮书强调，人工判断负责校准自动化评估，是整套评判体系的基准。

3. 适合质量、产品和架构团队

这份白皮书适合产品经理、QA、数据科学家、架构师和 SRE。产品和质量团队可以用四支柱做质量看板，架构团队可以用两层评估设计指标，SRE 可以用三支柱补观测数据。它也很适合用来向管理层解释，为什么 Agent 上线前要投入可观测和评测，验收测试只是其中一环。

和美团白皮书对照读，分工很清楚。美团的四个模块管评测怎么跑，Google 的四支柱管评测看什么。一个偏工程流程，一个偏质量框架，放在一起能补上彼此的空缺。

四、Google《Agents Companion》白皮书，把评测放进 AgentOps

Google 在 2025 年 2 月发布《Agents Companion》，76 页。它把 Agent 从原型到生产的全过程拆成 AgentOps，评测被放进 AgentOps 的整条链路里。

1. 评测被放进 AgentOps

AgentOps 在 DevOps 和 MLOps 的基础上，增加了工具管理、核心提示、记忆、任务分解等组件。白皮书把评估分成几层，公开基准测试看核心能力，例如 BFCL、AgentBench；轨迹评估看动作序列，用精确匹配、有序匹配、任意顺序匹配等指标；最终响应可以用 LLM-as-judge 自动评分；人工评估负责校准自动化评估的偏差。业务侧还要看北极星指标、任务完成率和应用遥测，延迟、错误率、Token 消耗都算。

多 Agent 系统有额外的评估维度，协作是否顺畅、协调是否有效、规划是否合理、资源利用是否高效。Agentic RAG 也有专门的讨论，检索从静态查询变成迭代推理、查询扩展、多步验证和来源选择。评估要覆盖检索质量、引用准确性和最终答案的完整性。

2. 它补上了上线后的那段

很多团队有离线评测，没有上线后的持续评估。这份白皮书把版本控制、CI/CD、测试、日志、安全、指标串成一条运维链路，让评测在发布前出现，也在每次变更、每次模型升级、每次工具调整后跑一遍。

它对多 Agent 和 Agentic RAG 的评估讨论，也比一般白皮书更具体。团队如果正在从单 Agent 走向多 Agent，或者把 RAG 从静态检索升级成 Agentic RAG，这份资料能帮你提前设计评估维度。

3. 适合平台和运维团队

这份白皮书适合平台、基础设施、运维和架构团队。最实用的读法是对照美团白皮书的在线评测与监控章节，一边看一边检查自己的上线流程，版本怎么管、变更怎么回测、线上异常怎么归因、指标怎么串起来。

76 页不需要逐页读。先读评估框架和 AgentOps 两部分，再按需看多 Agent 和 Agentic RAG。它和《Agent Quality》不重复，一份讲质量怎么评，一份讲评测怎么接进生产运维。

五、Microsoft《Taxonomy of Failure Mode in Agentic AI Systems》，先把失败模式列全

Microsoft AI Red Team 在 2025 年 4 月发布《Taxonomy of Failure Mode in Agentic AI Systems》，2026 年更新到 2.0。它解决的是另一个问题，Agent 会在哪里失败，尤其是 AI 安全和信息安全上的失败。

1. 失败模式怎么分类

这份白皮书用两个维度搭分类框架，一个维度区分 AI 安全与信息安全，另一个维度区分新型失败与既有失败。新型失败是 Agent 特有的，例如多 Agent 通信流程里的问题；既有失败是在其他 AI 系统里出现过、但在 Agent 场景里影响更大的问题，例如偏见和幻觉。

分类覆盖记忆投毒、目标劫持、工具滥用、MCP 与插件滥用、Agentic 供应链污染、权限越界和多 Agent 通信问题。文中用记忆投毒做案例，攻击者先污染 Agent 的记忆，再借记忆把数据外泄。对应的缓解措施包括限制记忆写入、要求外部验证、隔离权限、控制记忆的结构和格式。

2026 年的 2.0 版本新增了 7 类失败模式，包括 Agentic 供应链污染、目标劫持和 MCP 与插件滥用。更新本身说明一件事，Agent 的攻击面还在变化，评测集和红队测试也要持续更新。

2. 它把安全评测前置

Agent 评测不能只看任务完成率，还要看失败和攻击面。这份白皮书适合做威胁建模清单，也适合做发布门禁。高风险工具调用、跨系统写入、权限提升、记忆更新，都应该有对应的测试用例和人工确认。

它把 Agent 特有的失败模式和通用 AI 风险分开处理，这一点对评测设计很有用。通用 AI 风险告诉你可能会产生偏见、出现幻觉，Agent 失败模式告诉你这些风险会通过工具、记忆、权限和多 Agent 协作放大成什么后果。

3. 适合安全、风控和合规团队

这份白皮书适合安全团队、风控、合规、架构师和 AI Red Team。用法可以很直接，把分类表当成威胁建模清单，把每一类失败对应的缓解措施转成测试用例，再把高风险用例放进发布门禁。

企业如果正在建设Agent 安全与治理体系，这份资料可以作为安全评测的底稿。它的范围集中在安全和失败模式，业务指标和质量评分需要配合其他资料使用。

六、中国信通院《可信 AI 智能体评估体系 2.0》，把企业级评估做成验收表

中国信通院在 2026 年 4 月发布可信 AI 智能体评估体系 2.0。它面向企业级智能体，覆盖基础设施、数据资源、核心组件、平台支撑、关键能力、典型应用、运维管理、价值评价八个维度。

1. 八个评估维度

基础设施看运行环境、硬件资源适配、异构兼容和弹性扩展。数据资源看面向智能体的数据开发、数据工程和 DataOps。核心组件看协作协议、RAG、Skills 和编排。平台支撑看开发、测试、运营、优化的全生命周期平台能力。关键能力看感知、决策、生成、交互、多 Agent 协同和多模态。典型应用看智能助手等场景的落地效果。运维管理看全生命周期管理和运营价值。价值评价看业务结果和投入产出。

这套体系强调全生命周期、多层次、可量化，用途写得很明确，技术选型、项目验收、行业监管和规模化落地。中国信通院在发布时提到，已累计为 50 余家单位提供智能体专项评估服务，并研制了 1 项国际标准、10 余项行业标准和 20 余项联盟规范。

2. 它适合做选型和验收的上位框架

国内企业做 Agent 选型，最容易犯的错是只看 Demo 和跑分。Demo 能展示能力上限，跑分能反映特定基准上的表现，二者都不能直接回答业务场景能不能用、成本能不能接受、权限能不能管住、出问题能不能追溯。信通院的八维度更适合做上位框架，把技术、数据、平台、应用、运维和价值放在一张表里。

和厂商自评相比，第三方评估还能提供外部校准。ThinkingAI 旗下 Tiki 智能助手依据中国信通院《智能体技术要求与评估方法 第 9 部分：数据分析智能体》获得 4+ 级评级，这类第三方结果可以作为企业内部评测的参照点。

3. 适合采购、架构和合规团队

这份评估体系适合采购、数字化、架构和合规团队。用法是把八个维度拆成评分项，给每个评分项定义证据要求和权重，再把高风险场景的第三方报告作为准入条件。价值评价要和业务指标绑定，不能只写提升了效率，要写清基线、样本、时间范围和归因方法。

企业如果正在做Agent 平台选型，可以先把这份体系当成验收表的骨架，再用具体业务场景补充细节。

七、OpenAI《A Practical Guide to Building Agents》，把评测写进开发流程

OpenAI 在 2025 年 4 月发布《A Practical Guide to Building Agents》，34 页。它面向准备把第一个 Agent 推上线的产品和工程团队。

1. 从要不要建 Agent 讲到怎么评测

指南先回答什么时候该建 Agent。复杂判断、规则已经难以维护、大量依赖非结构化数据，这三类场景适合 Agent。如果任务可以用确定性规则解决，确定性方案可能更便宜、更稳定。

Agent 的最小结构是三个组件，模型、工具、指令。模型负责推理和决策，工具负责查数据和采取行动，指令负责说明目标、步骤和边界。编排上有单 Agent、管理器模式和去中心化模式，复杂度上来之后再拆多 Agent。护栏覆盖相关性分类、安全分类、PII 过滤和工具安全，高风险动作要有拦截和人工确认。评测贯穿其中，原型阶段用强模型建立性能基线，再用 eval 驱动模型降级、工具调整和指令优化。

2. 它把评测写进了开发流程

这份指南对从 0 到 1 的团队最友好。它强调先定义成功标准，再选模型和工具，不要等上线后再补评测。工具要清晰、经过测试、可复用，指令要明确写出目标、步骤、边界和异常处理。评测和模型选择、工具定义、护栏设计一起，决定 Agent 能不能稳定上线。

和美团、Google 的白皮书相比，它更偏开发实践，理论深度不算最深，但适合作为团队入门的第一份材料。读完它，再读美团的全流程和 Google 的质量框架，会更容易把概念落到工程动作上。

3. 适合从 0 到 1 的产品和工程团队

这份指南适合产品经理、工程团队和初创团队。用法是在写第一行 Agent 代码前定义 eval，用 guardrails 处理高风险动作，用编排模式控制复杂度。团队如果还没有评测集，可以先从核心场景的真实任务开始，不要一开始追求大而全。

企业如果正在规划Agent 落地路线图，可以把这份指南当成开发侧的检查表，和信通院的验收框架配合使用。

八、6 份资料怎么组合成一套可执行方案

把 6 份资料放在一起，可以拼成一条从框架到上线的路径。

第一步，定框架。用美团《Agent 评测白皮书》的四个模块搭流程，用 Google《Agent Quality》的四个支柱定质量维度。一个回答评测怎么跑，一个回答评测看什么。

第二步，建指标。用信通院的八个维度做企业级验收表，用 Google 的两层评估区分结果指标和过程指标。业务结果、任务完成率、轨迹质量、成本延迟、安全合规，放在同一张表里，不要让评测只停留在准确率。

第三步，补安全和运维。用 Microsoft 的失败模式做威胁建模和红队测试，用 Google《Agents Companion》的 AgentOps 框架把评测接进版本、CI/CD、日志和线上监控。安全评测和运行评测都要有，前者防止坏事发生，后者保证好事持续发生。

第四步，进开发流程。用 OpenAI 的指南把 eval 写进模型选择、工具定义、护栏设计和发布门禁。每次模型升级、Prompt 调整、知识库更新、Skill 新增，都跑一遍回测，再上线看 AB。

图 2，从读到用的四步落地路径

如果只做一件事，从 20 到 50 条真实失败案例开始，建一个最小评测集。这个量级足以覆盖核心场景，又不会把团队拖进长期建设。先让评测飞轮转起来，再逐步补过程指标、安全用例和自动化门禁。

白皮书读完能变成一张检查表、一组用例和一道发布门禁，才算用上。选一份框架，建一组真实案例，接进流程，比读完十份资料更有用。

九、常见问题

先读哪一份？

先读美团《Agent 评测白皮书》系列 01，建立从离线、在线、归因到观测的全流程。再读 Google《Agent Quality》，建立质量维度和轨迹评估的意识。需要安全清单时，再读 Microsoft 的失败模式分类。

白皮书里的跑分能直接当选型依据吗？

不能直接。跑分反映特定基准、特定配置下的表现，不能回答业务场景能不能用、成本能不能接受、权限能不能管住。选型要把跑分、业务任务完成率、成本延迟、安全合规和第三方评估放在一起看。

没有评测团队，怎么开始？

从 20 到 50 条真实失败案例开始，先建端到端评测集和核心过程指标，再把回测接进发布流程。不要一开始搭全套系统，先让最小闭环跑起来，再根据暴露的问题补能力。

Agent 评测和传统软件测试最大的区别是什么？

传统软件测试的路径相对确定，输出可以预期。Agent 是非确定性系统，同一任务多次运行结果可能不同，评测要看轨迹和环境状态，用 Pass@k 或通过率看稳定性，不能只看一次运行的结果。

企业级 Agent 评测要覆盖哪些维度？

至少覆盖结果、过程、成本、安全和组织价值五类。结果看任务完成率和业务指标，过程看规划、工具调用和轨迹，成本看 Token、延迟和步骤数，安全看权限、隐私和攻击面，组织价值看使用率、协作方式和投入产出。可以把这些维度映射到 Google 的四支柱和信通院的八维度。

这些资料有中文版吗？

美团和信通院的资料是中文。Google、Microsoft 和 OpenAI 的资料以英文为主，国内有一些解读文章，建议以原文为准，解读文章可以用来快速了解框架，不能替代原文中的定义和限制条件。