亚马逊AWS官方博客
评估企业级智能体：从原型验证到生产就绪
摘要：Agent 与传统软件有本质不同——非确定性、Prompt 即源代码、依赖会自己动——因此传统 QA 框架在它身上系统性失效，需要一套新的开发生命周期 ADLC。在那个六环节的飞轮里，“定义‘好’”排在动手构建之前，而 Evaluation 后续工程实践的重要基础：没有它，你不知道自己在哪里，也不知道改了之后有没有变好。上一篇结尾留下了三个问题：Agent Evaluation 究竟要评什么维度？有哪些方法？如何从零构建一套在企业规模下真正可用的评估体系？ 本篇就来回答它们。
一、引言
智能体的难点不在于“能不能做到”，而在于“能不能每次都做到”。本文是企业生产级智能体开发部署指南系列的第 2 篇，给出一套可落地的智能体评估方法论——评什么、怎么评、如何从零构建。
上一篇我们提出了一个判断：智能体与传统软件有本质不同——非确定性、Prompt 即源代码、依赖会自己动——因此传统 QA 框架在它身上系统性失效，需要一套新的开发生命周期 ADLC。在那个六环节的飞轮里，“定义‘好’”排在动手构建之前，而 Evaluation是后续工程实践的重要基础：没有它，团队不知道自己在哪里，也不知道改了之后有没有变好。上一篇结尾留下了三个问题：智能体评估究竟要评什么维度？有哪些方法？如何从零构建一套在企业规模下真正可用的评估体系？ 本篇就来回答它们。
进入方法论之前，先把“为什么评估这么难”再向前推一步。几乎每个构建过智能体的团队都遇到过同一个场景：demo时一气呵成，一旦开始接入真实流量，它却开始“间歇失效”——同一类请求，十次里有一两次走错工具或把一个本该拒绝的操作执行了。对于智能体来说，能力（capability）与一致性（reliability/consistency）并不是一回事。能力回答“它能不能做到”，一致性回答“它每次都能做到吗”；前者靠一两个亮眼样例就能展示，后者只能靠成规模、反复的评估去逼近。智能体把多步推理、工具调用、外部状态写入耦合在一起，任何一环的随机性都会被链式放大——这正是上一篇所说“Demo和生产之间的鸿沟”在评估视角下的样子：一边是 Gartner 预测 2028 年约 33% 的企业软件将内置 agentic AI 的汹涌需求，一边是 MIT 调研中仅约 5% 的组织报告生成式 AI 项目取得高回报的稀薄成功率。把两者连起来的，恰恰是能不能可信地判断“这个智能体是否真的交付了”。评估，就是把“the agent ran（它跑了）”翻译成“the agent delivered, here is the evidence（它交付了，这是证据）”的那道工序。
本文沉淀我们与企业客户合作中的实践经验，把智能体评估从临时跑分推进到一套可工程化的方法论。围绕开头那三个问题，本文分为五个部分。第一部分先点出三个最常见的评估误区，作为后文方法论的反向坐标。第二部分给出由“三种评估粒度”与“三层证据权重”构成的两支柱框架，回答“评什么”与“分数有多大分量”，并把企业场景下的八类测量维度落到这个框架上。第三部分讨论如何把评估嵌入研发流程——能力评估与回归评估的差异、生产漂移的监控、评估数据集与黄金集的构建，以及如何用约20个用例最小规模起步。第四部分审视LLM-as-a-Judge的价值与边界——它的偏见与缓解技术，以及在多步智能体场景下的根本局限。第五部分介绍Agent-based Evaluation（用智能体评智能体），并在结尾交代这套方法论与工程底座的关系，为下一篇工程化实践博客做铺垫。
二、三个常见的智能体评估误区
在给出框架之前，先点出三个最常见、也最容易让团队误判“已上线就绪”的坑。
- 误区一：仅关注智能体准确率指标。 把多步智能体压成一个“对/错”或一颗“质量星级”，会同时掩盖两类信息：质量很高但延迟/成本很差的情况，以及“答案对了但过程全错”的侥幸。对多步系统而言，最终输出的单一准确率远远不够。
- 误区二：严格比对工具调用序列。 直觉上“轨迹对了才算对”，于是有人用预期工具调用序列做精确匹配。但这种做法极其脆弱：智能体换一个等价路径、调换两个无依赖步骤的顺序，就会被判失败。它测的是“像不像我写的脚本”，而不是“有没有把事办成”。
- 误区三：先评估、后观测。 很多团队急着搭评分流程，却没有先把生产里的执行轨迹（trace）沉淀下来。结果是：分数掉了，却不知道掉在哪一步、为什么掉。上一篇把“从第一天就埋好可观测性”列为三类工程实践中的数据管道一环，原因正在于此——正确的顺序是先有可观测性，再谈打分，没有trace的评估是盲测。
三、评估方法论框架：两根支柱
在与企业客户合作的实践中，我们沉淀出一套两支柱 + 三类打分器的评估方法论，分别回答“用多粗的镜头看”与“一个分数有多大分量”两个问题。支柱一（三种评估粒度） 决定评估的粒度有多深——从只看最终响应（黑盒），到看完整执行轨迹（玻璃盒），再到看单步细节（白盒）。支柱二（三层证据权重） 决定每个分数有多大分量——从机械可验证（Layer 1）、到半客观（Layer 2）、再到默认拒评（Layer 3）。两根支柱互相正交：同一个粒度上的指标可以来自不同证据层级，反之亦然——它们不是一一对应的两套层，而更像一个 3 × 3 的矩阵，用同一组指标既要选粒度、又要选证据强度。三类打分器（代码规则、LLM-as-a-Judge、人工）是把这个矩阵填满的工具，它们与三层证据权重天然对齐。下面先拆解两根支柱各自的结构，再回到这个矩阵看它们如何交叉。
[图1] |
3.1 支柱一：三种评估粒度（黑盒、玻璃盒、白盒）
对多步智能体，我们建议在三个粒度上同时观察：
- 黑盒（Black-Box）——最终响应。 只需输入、输出、上下文即可判定：相关性、完整性、简洁性、语气、事实正确性、输出结构是否合规。它适合端到端验收，也最贴近用户感知。
- 玻璃盒（Glass-Box）——完整轨迹。 看整段消息序列与工具调用，精确定位推理在哪一步出错：目标是否达成、工具选择与参数是否正确、轨迹是否高效、是否产生幻觉。
- 白盒（White-Box）——单步。 评单个步骤或单次工具调用的正确性，是定位与归因的最细一层。
三个粒度互补：黑盒告诉你“结果好不好”，玻璃盒与白盒告诉你“为什么、在哪儿”。这里有一条经验：优先按结果（outcome）打分，而非死磕路径；对多组件任务设计部分得分（partial credit）；轨迹分析用来归因，而不是用来做工具序列的精确匹配。
3.2 支柱二：三层证据权重框架
第二根支柱常被忽视，却最为关键。它的出发点是一个朴素的事实：并非所有质量都同样可测，而一个分数会带来后果（决定是否上线、是否付款、是否放行），因此每个分数携带的“证据权重（evidentiary weight）”必须被显式标明。据此，我们把所有指标按“能被多严谨地验证”分到三层，每个指标只归一层：
- 第 1 层——机械可验证（Mechanically verifiable）。 纯代码、零歧义判定：schema、格式、延迟、成本。结果确定，任何一方都能复算——这是最强的证据，在审计与争议场景下可被辩护。
- 第 2 层——半客观（Semi-objective）。 由模型在受控条件下稳定打分：相关性、正确性、忠实度、一致性。它非确定、不可逐位复算；只有在固定评判器（pinned evaluator：锁定模型、prompt、temperature、seed） 下，其分数才作数。
- 第 3 层——主观（Subjective）。 没有任何评判器能稳定打分的维度（例如“这个够不够有创意？”）。默认拒评（refused by default）——在 rubric 协商阶段就把它标出来，而不是强行给一个假装客观的分。
这层框架给出一个清晰的心智模型：一个分数，只能在它所在层支持的严谨度上被当作证据使用。 由此也能推出一组该刻进团队习惯的反模式：不要把质量压成单一星级合成分；不要给用户展示裸小数（那是假精度，宜用字母档加命名置信度）；不要跨任务类型套用统一阈值（0.75 在创意题和严格 schema 上意义完全不同）；不要把延迟、成本藏起来，它们是一等的业务指标。
3.3 打分器的选择
支撑这两根支柱的，是三类 打分器（grader） 的组合使用：
| 打分器 | 优点 | 缺点 |
| 代码规则（Code-based） | 快、便宜、客观、可复现 | 脆，只覆盖可程序化判定的部分 |
| 模型 / LLM-as-a-Judge | 灵活、可扩展、能捕捉细微语义 | 非确定，需对照人工校准 |
| 人工（Human） | 金标准 | 昂贵、慢、难规模化 |
它们与三层框架天然对齐：第 1 层用代码规则，第 2 层用经校准的 LLM-as-a-Judge，人工则负责抽样校准与最终仲裁。
在企业落地时，这三类打分器有明确的优先级与分工：
- 程序化、可验证的检查优先执行。 低成本、客观、可信——凡是能写成代码断言的（schema、格式、敏感词、延迟、成本、关键参数），绝不交给 judge 模型。这既是省钱，更是把最强证据放在最前面。
- LLM-as-a-Judge 只管主观维度，且评分标准（rubric）必须由 SME 校准。 judge 模型人人可买，但“什么算好”的 rubric 要由懂业务的领域专家写出来、再对照人工标注验证一致率——否则你得到的是一个自信但不对齐业务的打分器。
- SME/人工审核是企业的核心优势，要用在刀刃上： 标注黄金集，以及每次发布前的抽检。外部模型与评估平台是人人可得的通用件，唯独“懂你业务的人的判断”买不到——这正是企业评估体系里最稀缺、也最该被制度化沉淀的资源。
把两支柱与打分器合起来看，就是下面这张矩阵：行是三种粒度、列是三层证据权重，每个格子放一个示例指标、由对应的打分器填充。它直观地说明了两支柱如何交叉、空格（如“白盒 × 主观”）为何通常不评估，以及人工评估如何横跨各层。
[图2] |
3.4 企业到底要测什么：八类测量维度
矩阵搭好了，往里填什么？这里先校准一个定位：企业评估是风险管理加质量保障（QA），而不是研究。它的目标不是刷benchmark或发论文，而是控制上线风险、守住质量底线；“好”由领域专家（SME，Subject Matter Expert）定义，基准由真实业务数据构成。在这个定位下，企业智能体通常需要覆盖八类测量维度——每一类都能在“粒度 × 证据权重”矩阵上找到自己的格子：
| 测量维度 | 它回答的问题 | 典型粒度 | 典型证据层 |
| 任务/目标完成率 | 用户的目标这次达成了吗？ | 黑盒 | 第 2 层（有 ground truth 时可升第 1 层） |
| 工具与动作正确性 | 选对工具了吗？参数填准了吗？ | 玻璃盒/白盒 | 第 1 层（有预期轨迹）或第 2 层 |
| 安全/PII/信息泄露 | 有没有泄露不该说的？ | 黑盒+玻璃盒 | 第 1 层规则扫描 + 第 2 层语义判定 |
| 成本与延迟 | 跑一次花多少钱、多少秒？ | 任意粒度 | 第 1 层（纯机械可验证） |
| 忠实性/事实依据 | 回答有出处吗？编造了吗？ | 黑盒 | 第 2 层（需固定评判器） |
| 策略与合规 | 守住业务规则与监管口径了吗？ | 玻璃盒 | 第 1 层规则 + 第 2 层判定 |
| 品牌语调与风格 | 说话像“我们公司的人”吗？ | 黑盒 | 第 2 层偏第 3 层（SME 校准 rubric，部分子维度拒评） |
| 升级处理的恰当性 | 该转人工的时候转了吗？ | 玻璃盒 | 第 2 层 |
这张表传达的方法论是：选指标，就是在矩阵上为业务挑格子，而不是把所有指标全开。一个纯问答智能体不需要盯工具正确性，一个不直接面客的内部智能体对品牌语调的要求也可以放低；但凡选中的格子，就要按它所在证据层的严谨度去执行——成本与延迟永远用第 1 层代码算，忠实性永远用固定评判器，品牌语调里那些连 SME 都说不清的子维度，明确拒评。
最后回到开头提到的“一致性”。智能体的随机性意味着“跑一次过了”不等于“可靠”，因此需要区分两个指标：pass@k 是 k 次里至少一次成功的概率（适合“一次成功就够”的场景）；pass^k 是 k 次全部成功的概率（适合一致性至关重要的智能体）。
四、评估的工程化落地：从流程嵌入到数据集积累
有了框架，还要让它在研发流程里“转起来”，而不是上线前临时跑一轮。下图展示了从手动追踪到离线/在线双轨的演进路径。
[图3] |
4.1 流程与漂移
能力评估与回归评估是两件不同的事。 能力评估起点分数低，是“给团队一座要爬的山”，用来衡量并推动能力提升；回归评估应维持接近 100% 的通过率，用来守住已有能力、防止退化。成熟的能力评估达标后，就 “毕业”沉淀为回归套件，进入 CI 持续运行。
警惕基线与生产之间的漂移（drift）。 上一篇提到的“静默漂移”——模型隐式更新、外部依赖变化让质量指标悄悄变差——在这里可以被精确表述为一个尤其值得显式管理的现象：开发期注册的基线 accuracy（在 dev benchmark 上声称的）不等于生产里 30 天的 reliability（实际可接受的交付比例）。两者会因 agent drift、依赖模型被弃用、prompt 随时间衰减而背离。“92% 的 reliability”意味着每跑 100 个任务约有 8 次失败——这正是 pass^k 论点在生产语境下的另一种表达。基线分数不是终点，它只是一个会漂移、需要被持续重测的量。
三阶段成熟度加 AgentOps。 上一篇把“从第一天就埋好可观测性”定为工程实践的起点，这里进一步给出它通向完整评估体系的成熟度路径：第一步，先做 tracing，不急于打分（“先追踪，后打分”）；第二步，接入在线反馈（如点赞/点踩等用户信号）；第三步，沉淀离线回归集（用自动化流水线防止回归）。在这之上挂一个 AgentOps 组件，在生产中持续监控智能体表现、捕捉异常与漂移。
离线与在线双轨并行。 开发期（离线）跑回归集回放、能力评估、CI 门禁；部署后（在线）做实时打分与采样、收集用户反馈、用 AgentOps 监控漂移。在线打分可用采样率控成本（例如只对一部分流量触发评判）。
4.2 数据集与起步
流程与漂移解决“什么时候评、谁来盯”，但评估真正能不能产生信号，取决于数据集质量与起步姿势——这两件常被低估的事。
如何构建评估数据集。 构建评估集要分清两个正交的维度：用例从哪来（覆盖度），以及哪些用例的标注够可信（可作基准）。
维度一 · 用例来源（覆盖度）:
- 生产 trace 沉淀（真实分布，最有价值）。 不要全量灌进来，要按 intent、工具、用户分群分层采样，保留完整 trace（不只是输入输出），并在入库前做 PII 脱敏。它的优势是反映真实分布，代价是会带着真实流量的偏斜——长尾不会自动出现。
- 合成增强（覆盖长尾与对抗 case）。 关键是以真实失败 trace 为种子做扰动与变异（改时态、加噪声、注入边界值、对抗 prompt 等），而不是凭空让 LLM “想象”用例。纯凭空合成最大的风险是看起来覆盖了边界 case，实际却生成了一套与生产无关的另一种分布——仪表盘绿光满满，真实问题却没碰到。
维度二 · 黄金集（golden set）：可信的标注基准。 从上述用例中筛出一个标注高度可信、正确的子集，作为校准与仲裁的基准。它的标注来源不限——既可以是人工精标，也可以是带明确 ground truth 的样本——重点在“可信与正确”，而非由谁标注。实践要点：多人标注并算出标注一致性（IAA）（不一致的样本本身就是 rubric 不清的信号）；给黄金集打版本号，任何修改可追溯；并留一份从不进入开发循环的 holdout，用来体检 LLM-as-a-Judge 的真实校准度。
值得把黄金集的地位再抬高一档：它是企业的评估知识产权（evaluation IP）。真实生产数据、SME 标注、覆盖常见+边缘+合规+升级四类场景、生产失败案例持续回流——模型会换代、框架会迁移，唯独这套资产沉淀下来不走，而且越滚越值钱。由此也引出一条工具选型原则：评估平台可以买，评估内容必须自主掌控。跑分流水线、dashboard、judge 托管这些是通用件，谁家的都能用；但黄金集与 rubric 是业务件，外包了它们，等于把“什么算好”的定义权交给了别人。
实战中比例不是死规矩，起手可以参考 约 50% 生产采样 + 30% 合成 + 20% 黄金，之后每月从生产增量补 10–20%。还要警惕三个常见失败模式：数据泄漏（黄金集被反复看见、渐渐被过拟合）、黄金集冻结（几个月不更新，生产分布已经漂走，而黄金集还守着旧世界）、合成掩盖真实（只跑合成数据时，生产里真正发生的失败模式可能根本没被覆盖）。
如何最小规模起步。 不必一开始就追求大而全。先从 约 20 个用例起步，但这 20 条不是随手抓 20 条，而是“小而有代表性”：覆盖主要 intent，已知好、已知坏、模糊三档都要有，happy path 之外至少塞 3–5 个 edge 或对抗 case。
拿到这 20 条之后，先看数据、再打分：开一张表，列固定为 输入 / trace / 预期 / 实际 / 失败模式标签，把 trace 逐条读一遍，先把失败聚成 2–3 个簇（例如“参数填错”“漏澄清”“提前终止”），再把聚出来的簇翻译成 rubric 条目和打分维度。这就是 error analysis 的核心动作——先观测、后度量，远比一上来就堆指标更快收敛。
之后的升级路径也大致可预期：20 → 100 条时，失败模式的簇会逐渐稳定，rubric 收敛；100 → 500 条时，你已经能做有统计意义的回归对比，并在黄金集上对照人工标签校准 LLM-as-a-Judge；500 条以上，就进入“按比例从生产分层采样、定期增量补”的稳态。两个早期最常见的反模式正好与之相反——rubric 先于数据（打分维度全是凭空想的，真实失败根本不在那几条上）、过早上 LLM-judge（连失败长什么样都没看过，校准的“基准”是空的）。
五、LLM-as-a-Judge 的价值与边界
上面多次提到用 LLM 当评判器（LLM-as-a-Judge）。它已是成熟范式，提供可扩展、低成本、相对一致的评估，是人工或专家评估的有力补充。但它有清晰的边界，裸用会出问题。
经校准后，LLM-as-a-Judge 与人类的一致性可以做得不错（在 MT-Bench 等设置下，大语言模型可以达到与人类之间相当的水平），但这强依赖评判模型强度与领域，不能泛化为“任意评判器都具备的属性”。更要紧的是，LLM 评判存在可测量的系统性偏见，例如：
- 位置偏见： 交换两个答案的顺序，大模型判决可能会翻转。
- 冗长偏见： 更长、更像“列清单”的回答容易被高估。
- 权威偏见： 对于“置信度”较高的内容，例如“伪造参考文献”，多数评判表现不优于随机。
对应的缓解技术也已成熟：双向打分（对 （A，B） 与 （B，A） 各判一次，不一致就记平局）可直接抵消位置偏见；多评判陪审团（Panel of LLM evaluators，PoLL）用不同模型家族的多个较小评判投票，既降低单一模型家族的内生偏见，成本还约为单个大评判的 1/7 到 1/8；以及对照人工标签做校准，以“评判与人类的一致率达到人类之间的一致率”为可用门槛。
LLM-as-a-Judge 必须做偏见缓解与人工校准，不能“直接”使用。 但即便缓解到位，单轮评判仍只是“看一眼最终答案打个分”——它看不到智能体是怎么一步步走到这里的。当被评对象是一个会推理、会调工具、会产出复杂中间制品的智能体时，我们需要一种能“陪着它走完全程”的评判者，因此我们更需要 Agent-based Evaluation。
六、Agent-based Evaluation：将专家级评审规模化
6.1 为什么需要 Agent-based Evaluation
单轮 LLM-as-a-Judge 不能进行完善的全局评测。但智能体的价值恰恰分布在过程里：多步推理是否自洽、每一次工具调用的选择与参数是否正确、中间产物（代码、检索结果、草稿）是否站得住。只看终态，会把这些信息全部丢掉；而要人工逐步审查整段轨迹，成本又高到无法规模化。
Agent-based Evaluation（用智能体评智能体）正是为此而生：让评估者本身也是一个具备 agentic 能力的系统——它能读取被评智能体的整个解题轨迹（文件、中间步骤、工具调用），必要时自己调用工具去验证（运行代码、检索核对、把 rubric 分解成可判定的子项），并在过程中给出过程级评判与中间反馈，而不只是末尾打一个分。它的本质，是把原本只能由专家完成的“逐步审阅”规模化：专家会读你的推理链、会去核对你引用的事实、会指出“第三步这里就错了”——Agent-based Evaluation 把这种深度审查自动化、批量化。
6.2 与单轮评判和人工评估互补
要把它放在正确的位置：它不是来取代单轮评判和人工评估的，而是与两者互补——单轮评判快而便宜，适合大批量黑盒打分；人工是金标准与最终仲裁；Agent-based Evaluation 补的是中间那段“需要过程级、可验证、可解释，但又请不起人工逐步标注”的深水区。
同样重要的是不要夸大它。这条工具链有三个必须正视的代价：
- 更贵、更慢。 评估智能体要读轨迹、调工具、做多轮推理，延迟与算力成本显著高于单轮评判。它适合开发与预生产阶段的深度评估，而不是每条生产流量的实时门禁。
- 它本身需要被验证。 评估智能体也是用 LLM 搭建的，它的判定同样需要一个“评判器的 benchmark”去校准——否则低成本的自动评分会悄悄引入系统性误差。
- 它不会自动消除偏见。 评估智能体同样继承位置、冗长、自我增强等偏见（见上一节），仍需对抗式校准。“用 Agent 评”不等于“客观”，只是把评判的粒度做深了。
6.3 参考架构与最佳实践
下图展示了一个 Agent-based Evaluation 的参考架构，以及它与单轮评判、人工评估的互补关系。
[图4] |
一个可用的 Agent-based Evaluation，大致由这几块构成：
- 轨迹输入： 把被评智能体的完整 run（输入、每一步、工具调用与返回、最终产物）结构化地喂进来。
- 带工具的评估智能体： 评估者本身配备工具——代码执行（验证产物能否跑通）、检索（核对事实与引用）、rubric 分解（把“好不好”拆成一组可独立判定的子标准）。
- 过程级评判加根因分析（RCA）加中间反馈： 不只给终评，而是定位“在哪一步、为什么失败”，并给出可操作的反馈。
- 面向多受众的报告： 同一个 0 到 1 的分数，对不同人意味着不同的东西。裸分数不是决策。 给选型者看朴素直白的质量、一致性、延迟、成本；给开发者看逐任务加运营指标（改什么）；给运营者看逐任务风险档（Safe、Marginal、Risky，决定提交、重试或放弃）。每份逐任务报告可固定为四段：一句话裁决、逐维度 scorecard（用整数百分比而非裸小数）、做对了什么与失败在哪、建议动作。
最佳实践上，把它叠在三层证据权重框架之上：机械可验证的部分（代码能否跑通、schema 是否合规）仍归第 1 层，用工具确定性判定；需要语义判断的部分归第 2 层，用固定评判器加 rubric 分解；真正主观的维度照旧拒评。这样，即便评判者是个智能体，每个分数的证据权重依然清晰。
6.4 从方法论到工程底座
方法论本身是客观、通用的，但这套复杂度大多属于“通用底座”：收 trace、跑离线/在线评估、保证可复现执行、武装评估智能体、运行时护栏——这些与具体业务无关、人人都要的部分，已经可以交给托管平台承接，不必团队从零搭建。以 Amazon Bedrock AgentCore 为例：它的 Observability 以 OpenTelemetry 兼容格式自动输出 trace 与 span，正是“先 tracing，不急打分”那一步的工程化实现；它的 Evaluations 在 sessions、traces、spans 三个层级上工作，恰好与本文的三种评估粒度一一对应——session 对应黑盒，trace 对应玻璃盒，span 对应白盒。方法论里的每个环节，在工程底座上都有成型的承接位。
底座既然可以托管，团队真正该集中投入的，是与业务强相关、无法外包的那部分：智能体在哪类请求上算“交付成功”、哪些是必须守住的领域特定 metrics（合规口径、行业术语准确性、关键工具的参数正确性……）、黄金集里那批最能代表业务的真实用例——也就是上文所说的评估知识产权。把通用复杂度交给底座、把精力留给业务判断——这正是把方法论落到生产、且能持续跑下去的关键。
七、最佳实践清单
把全文浓缩成一页，供要动手的团队参考：
- 先接入 tracing，再谈打分。 没有可观测性，一切评估都是盲测。
- 三个粒度都覆盖： 黑盒看结果，玻璃盒与白盒做归因。
- 按结果打分、给部分得分，避免死磕工具调用序列的精确匹配。
- 用三层证据权重框架管理每个分数： 第 1 层机械可验证、第 2 层固定评判器、第 3 层默认拒评，并据此显式标明分数的证据权重。
- 三类打分器混用： 代码规则加经校准的 LLM-as-a-Judge 加人工抽样仲裁。
- 区分能力评估（低起点、要爬坡）与回归评估（近 100%、守底线）； 能力评估达标后毕业进入 CI。
- 对一致性敏感的客服或交易类智能体，用
pass^k， 并显式监控基线 accuracy 与生产 reliability 之间的漂移。 - LLM-as-a-Judge 必做偏见缓解与人工校准： 双向打分、参考引导、PoLL 陪审团、人工金标准。
- 离线与在线双轨： 离线跑回归集做门禁，在线用 AgentOps 监控漂移、用采样率控成本。
- 深水区上 Agent-based Evaluation： 用带工具的评估智能体做过程级评判与 RCA，但记得它更贵更慢、本身需要被校准、不会自动消除偏见。
- 从约 20 个用例起步，先看数据再打分； 引用任何基准数字都带上模型与时间点标注。
- 裸分数不是决策： 给选型、开发、运营三类受众不同的报告视图。
- 把黄金集当作评估知识产权经营： 真实生产数据加 SME 标注，覆盖常见、边缘、合规、升级四类场景；评估平台可以买，评估内容必须自主掌控。
八、结论
本文回答了上一篇结尾留下的三个问题。评什么维度——三种评估粒度乘三层证据权重的矩阵，加上企业场景的八类测量维度，让“选指标”变成在矩阵上为业务挑格子。用什么方法——三类打分器按程序化优先、SME 校准 LLM-as-a-Judge、人工抽检守住黄金集的优先级分工；深水区用带工具的评估智能体做过程级评判与根因分析（Agent-based Evaluation），把专家逐步审阅的能力规模化。怎么从零构建——先 tracing 后打分，从约 20 个用例做 error analysis 起步，沿 20 → 100 → 500 的路径把能力评估毕业成回归套件，并把黄金集当作评估知识产权持续经营。
能力（capability）与一致性（reliability/consistency）是两件不同的事。 在模型能力被快速商品化的当下，真正构成长期差异化的，是一套贴合业务、沉淀真实生产 trace、校准过评判器、并显式管理证据权重与漂移的评估体系。它能持续回答一个问题：“这个智能体这次是否真的交付了，证据是什么？”
如果你希望将本文的方法论落到工程实践中，我们建议如下起步路径：
- 先建立可观测性。 用托管服务或基于 OpenTelemetry 自建，把智能体执行轨迹结构化沉淀下来，作为后续评估的数据基础。
- 按三层证据权重框架分配打分器。 第 1 层用代码规则，第 2 层用经校准的 LLM-as-a-Judge，第 3 层默认拒评。
- 从约 20 个有代表性的用例起步，做 error analysis。 先看数据、再确定 rubric 与打分维度，逐步从能力评估毕业为回归套件并接入 CI。
- 在深水区引入 Agent-based Evaluation。 用带工具的评估智能体做过程级评判与根因分析，并对其判定本身进行人工校准。
方法论到这里就完整了，但它还只是图纸。下一篇，我们看亚马逊云科技是怎么把这张图纸盖成楼的：Amazon 内部数千个生产级智能体沉淀出的三层评估库（Foundation Model /智能体 Components / End-to-End）、把评估自动化的 Trace-driven 四步工作流，以及购物助手、客服、卖家助手三个真实案例——从工具使用评估、意图检测评估到多智能体协作评估。
如需进一步了解 Evaluation-first 方法在实际场景中的落地方式，可参考本系列配套动手实验示例代码
进一步阅读：
相关产品：
- Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
- Amazon Bedrock AgentCore — 加快代理投入生产的速度
系列文章：
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心：云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
