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

撰文 | 李信马

题图 | AI生图

《在数十亿个Agent运行之前，亚马逊先让Agent学会了管库存和招人》一文中，亚马逊云科技（以下简称“AWS”）CEO Matt Garman曾预测未来会有数十亿Agents在各行各业广泛运行，这样的前景固然让人欣喜，但有些冷水也不得不泼。

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

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

• 非确定性。传统软件的运行逻辑是确定性的，有一套明确的对错标准。Agent基于大模型运行，输出具有概率性——同样输入不一定产生相同输出，昨天测试通过，不意味着今天依然稳定。目前没有任何主流模型提供商承诺完全确定性的输出。
• Prompt即源代码。在传统软件里，改代码会留痕，有版本控制，有静态分析工具，但Prompt不会。自然语言提示词哪怕只是微调一个词，都可能引发Agent行为的剧烈波动，而当前行业没有成熟的工具来评估这种改动的影响范围。
• 隐式依赖。Agent对底层大模型存在隐式依赖——模型提供商在后台悄悄升级，代码一行没动，Agent的服务质量可能已经变了。

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

01、从SDLC到ADLC：评估是核心

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

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

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真正走进生产，对企业是一场有关技术和商业的新挑战，即使有指南，走不走得通，还得看企业自己的决心和投入。