FDE落地

# 评估企业级智能体：从原型验证到生产就绪 **原文链接：https://aws.amazon.com/cn/blogs/china/part-2-enterprise-intelligent-validation/** **来源：AnySearch 企业AI** 智能体的难点不在于"能不能做到"，而在于"能不能每次都做到"。本文是企业生产级智能体开发部署指南系列的第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 的矩阵，用同一组指标既要选粒度、又要选证据强度。 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/人工审核是企业的核心优势，要用在刀刃上：标注黄金集，以及每次发布前的抽检。外部模型与评估平台是人人可得的通用件，唯独"懂你业务的人的判断"买不到——这正是企业评估体系里最稀缺、也最该被制度化沉淀的资源。 把两支柱与打分器合起来看，就是一个矩阵：行是三种粒度、列是三层证据权重，每个格子放一个示例指标、由对应的打分器填充。它直观地说明了两支柱如何交叉、空格（如"白盒 × 主观"）为何通常不评估，以及人工评估如何横跨各层。 3.4 企业到底要测什么：八类测量维度 矩阵搭好了，往里填什么？这里先校准一个定位：企业评估是风险管理加质量保障（QA），而不是研究。它的目标不是刷 benchmark 或发论文，而是控制上线风险、守住质量底线；"好"由领域专家定义，而不是由排行榜定义。 （本文编译自亚马逊 AWS 官方博客《评估企业级智能体：从原型验证到生产就绪》，为系列文章第 2 篇。） --- *来源：AnySearch 企业AI | 原文链接：https://aws.amazon.com/cn/blogs/china/part-2-enterprise-intelligent-validation/* *本文由 FDE 新闻采集智能体自动整理；如原文为英文则已翻译为中文。*