做出来容易上线难：搞定企业级Agent要先学会“评估”？

《在数十亿个Agent运行之前，亚马逊先让Agent学会了管库存和招人》一文中，AWS CEO Matt Garman曾预言未来会有数十亿Agent在各行各业广泛运行。前景固然令人振奋，但有些冷水不得不泼——且不说Agent能否真正落地，单是眼下这关，就让不少企业头疼。

去年7月，MIT Project NANDA发布了一份报告，基于对300多个AI项目、52家组织的访谈和153位高管的调查，发现一个扎心的事实：尽管企业对生成式AI投入了300-400亿美元，但仅有5%的组织成功实现了规模化部署并获得了显著财务回报。这种现象被称为“GenAI鸿沟”——绝大多数组织被困在“高采用率、低转化率”的试点阶段，故事讲得热闹，钱却没赚到。

细分到Agent领域，鸿沟同样存在。Demo效果惊艳，一接入真实场景就失效。未来假如真有几十亿个Agent，其中多少能真正好用，其实不好说。问题的根源可能不在于模型不够强——Agent需要深入具体的业务场景，工程问题往往比模型能力问题更棘手。AWS刚刚发布的《企业生产级智能体开发部署指南》（以下简称“指南”）中，点出了传统软件工程方法对Agent失效的三个本质差异：

传统软件的逻辑是确定性的，有一套明确的对错标准。Agent基于大模型运行，输出具有概率性——同样输入不一定产生相同输出，昨天测试通过，今天可能就“翻车”。目前没有任何主流模型提供商承诺完全确定性的输出。

传统软件里改代码会留痕，有版本控制，有静态分析工具。但Prompt不会。自然语言提示词哪怕只是微调一个词，都可能引发Agent行为的剧烈波动，而当前行业没有成熟的工具来评估这种改动的影响范围。

Agent对底层大模型存在隐式依赖——模型提供商在后台悄悄升级，代码一行没动，Agent的服务质量可能已经变了。

三个差异叠加，导致传统软件的评估测试体系对Agent全面失效，企业Agent在进入生产环节上陷入停滞。那对想要靠Agent降本增效的企业来说，具体该怎么办？

01 从SDLC到ADLC：评估是核心

亚马逊全球副总裁储瑞松曾提过一个观点：企业在构建AI Agent时，底层技术平台可以通过采购获得，但评估标准必须由企业自主掌控。企业的核心竞争壁垒在于其自有的黄金数据集和评估标准。这一说法有些反常识——模型、基础设施、开发工具都可以靠买（对绝大多数企业来说自研的确也不现实），为什么评估标准如此重要？

回顾一下历史。上世纪60年代计算机科学快速发展，催生了最终演变为SDLC（软件开发生命周期）的生产框架的雏形。SDLC的核心是将开发工作划分为需求分析、设计、编码、测试、部署和维护等多个阶段。而随着AI智能体承担大量开发工作，ADLC（Agent Development Lifecycle）方法论随之出现。和SDLC最大的区别是：

ADLC不是走一遍就结束，而是不断旋转、持续迭代。六个环节——定标准、开发实现、效果评估、灰度上线、持续监控、改进循环——会从最后一个回流到第一个环节，更新评估标准和基准数据集。如果说传统软件是“开发→测试→上线”，Agent就是“定标准→开发→评估→上线→监控→挖失败→更新标准→再开发”。评估是起点，也是终点。

假如你是一家企业的管理者，想要启动Agent项目，找到了合适的场景，那么在启动开发之前，你需要先定义什么样的Agent是“好”的。比如智能体定义（它是什么和要做什么）、语气与个性（它怎么说话）、工具与参数定义（它能用什么、怎么用）、基准数据集（什么叫“做好了”）。

在Agent上线后，生产环境的数据必须能持续回流到评估体系中。这要求你建立完善的可观测性系统（指南里推荐使用OpenTelemetry）。没有可观测性，就没有持续评估，飞轮就转不起来。最后，是让系统架构可被评估——这是最工程化的一部分，也是评估能否落地的基础设施。指南里推荐三层设计：认证层（确认用户身份）、授权层即Gateway（控制Agent能做什么）、会话隔离层（不同用户之间互不干扰）。

Agent做出来了，怎么判断它行不行？这是最难回答的问题。从底层大模型到Agent的落地，就像一棵大树长出枝叶开花结果。大模型可能只需要一个或几个，但Agent却千千万万各不相同。对Agent的评估也是如此，每一个都应该有专门的评估方案，绝不能靠“感觉差不多”来上线。

02 评估方法论：两根支柱

构建过Agent的朋友对下面的场景可能不陌生：测试觉得没问题，但开始接入真实流量，却开始“间歇失效”——同一类请求，十次里有一两次出问题，烦人得很。

对于Agent来说，能力（capability）与一致性（reliability/consistency）并不是一回事。“能做到”不等于“每次都能做到”。Agent把多步推理、工具调用、外部状态写入耦合在一起，任何一环的随机性都会被链式放大。只能靠成规模、反复的评估去逼近“每次都能做到”。

指南中提出了评估方法论的“两根支柱”：支柱一决定评估的粒度有多深——从只看最终响应（黑盒），到看完整执行轨迹（玻璃盒），再到看单步细节（白盒）；支柱二决定每个分数有多大分量——从机械可验证（Layer 1），到半客观（Layer 2），再到默认拒评（Layer 3）。

黑盒评估看最终输出——用户问了一个问题，Agent给了一个回答，对不对？玻璃盒评估看完整轨迹——Agent做了哪些决策、调用了哪些工具、每一步推理是否合理？白盒评估则聚焦单步——某一个工具调用是否正确、某一段推理是否成立？三种粒度由粗到细分别回答“结果对不对”、“过程对不对”、“每一步对不对”。日常开发以玻璃盒为主，黑盒和白盒作为补充。

三层证据权重：第一层是机械验证，看格式对不对、JSON能不能解析等，完全自动化，零主观判断；第二层是半客观的pinned评判，用固定的评估器和明确的评分标准，对特定维度打分；第三层是主观默认评判，没有固定标准，靠人或LLM的判断力。它们也对应三类打分器，分别是代码规则、模型和人工。

两根支柱互相正交，同一个粒度上的指标可以来自不同证据层级，反之亦然，像一个3×3的矩阵——用同一组指标既要选粒度、又要选证据强度。这样一套组合下来，基本就能对Agent的输出结果进行全方位的评估了。用AWS开发的客服Agent来举例：客服场景最大的风险是意图识别出错，即用户说的和Agent理解的不是一回事。AWS通过“真实数据+虚拟客户模拟”的双轨评估方法，用较低成本把测试范围扩展到了各种边缘场景，既测了意图识别的准确度，也测了多轮对话的连贯性。

值得一提的是，由于评估中也会用到模型自动评估，所以评估数据集的质量决定了评估质量的上限。企业也需要建设经过人工标注、经过业务验证的高质量测试集，这个数据集将是企业的核心资产。

有关如何评估Agent还有很多细化的维度，而且不同形态的Agent关注不同的维度。比如客服Agent看重意图识别准确率和对话连贯性，工具使用Agent看重工具选择正确率和参数准确性，多Agent协作系统看重任务拆分合理性和执行稳定性。这里就不一一展开了。

AWS提供的思路和方法论也只是一家之言。如何做好Agent，可能还有其他的路径和实践案例。但有一件事情是确定的：Agent是生产力工具，能不能交付可衡量的业务结果，是判断它“好不好”的最终标准。

进入Agent时代，想让Agent真正走进生产，对企业是一场有关技术和商业的新挑战。即使有指南，走不走得通，还得看企业自己的决心和投入。