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

撰文 | 李信马

题图 | AI 生图

了不起的智能体：发现和介绍那些正在改变世界的 Agent，这里有现场、有对话，还有没被写进新闻的细节。

《在数十亿个 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 就通过 " 真实数据 + 虚拟客户模拟 " 的双轨评估方法，用较低成本把测试范围扩展到了各种边缘场景，既测了意图识别的准确度，也测了多轮对话的连贯性。