《在数十亿个智能体投入运行之前，亚马逊率先让智能体掌握了库存管理与人才招聘》一文中，亚马逊云科技（以下简称“aws”）首席执行官matt garman曾展望：未来将有数十亿智能体（agent）在各行各业深度运转。这一图景令人振奋，但现实的冷水也不容回避。

去年7月，麻省理工学院Project NANDA发布了一份研究报告。该报告基于对300多个AI项目、52家组织的深度访谈，以及面向153位企业高管的问卷调研指出：尽管企业在生成式AI（GenAI）上的投入已达300–400亿美元，却仅有5%的组织成功实现规模化落地，并收获可观的财务回报。这种“投入高、产出低”的落差被称作 “GenAI鸿沟”（The GenAI Divide）——绝大多数企业仍滞留在“试点热闹、落地艰难”的阶段。

聚焦至智能体（Agent）领域，同样存在类似断层：Demo演示惊艳夺目，一旦接入真实业务流程，便频频失准甚至失效。倘若未来真有数十亿智能体上线运行，其中真正稳定、可靠、可用的比例究竟几何？答案尚不明朗。而问题的症结，未必在于大模型能力不足；更深层的原因在于，Agent必须扎根于具体业务场景，其成败往往取决于工程化能力，而非单纯依赖模型性能。AWS最新发布的《企业生产级智能体开发部署指南》（后文简称“指南”）明确指出：传统软件工程方法在Agent开发中已全面失灵，根源在于三类根本性差异：

非确定性。
传统软件遵循确定性逻辑，行为可预测、结果可验证，具备清晰的是非边界。而Agent依托大语言模型运行，输出天然具备概率性——相同输入未必产生一致响应，昨日通过的测试，今日可能悄然失效。目前尚无主流模型厂商承诺提供完全确定性的输出保障。

Prompt即源码。
在传统开发中，代码修改留有完整痕迹，支持版本控制与静态分析；而自然语言提示词（Prompt）却缺乏此类工程支撑。哪怕仅调整一个介词或语气词，都可能引发Agent行为的剧烈偏移。当前行业尚未形成成熟工具链，用以量化评估Prompt微调带来的连锁影响。

隐式依赖。
Agent对底层大模型存在高度隐式耦合——模型服务商后台悄然升级，代码未动分毫，Agent的服务质量却可能已悄然滑坡。

这三大特性叠加，致使传统软件的测试、验证与质量保障体系在Agent面前彻底失效，也成为阻碍其迈入生产环境的关键瓶颈。那么，对于渴望借力Agent实现降本增效的企业而言，究竟该如何破局？

01 从SDLC迈向ADLC：评估成为中枢引擎

亚马逊全球副总裁储瑞松曾提出一个颇具颠覆性的观点：企业在构建AI智能体时，底层技术平台可通过采购快速获取，但评估标准必须由企业自主定义并持续演进。企业的真正护城河，不在于模型或算力，而在于独有的黄金数据集与经过业务锤炼的评估体系。

这看似反直觉——模型、基础设施、开发框架均可外购（对绝大多数企业而言，自研既不经济也不现实），为何评估标准反而成为核心壁垒？

回溯历史，上世纪60年代计算机科学蓬勃发展，催生了后来演化为SDLC（Software Development Life Cycle，软件开发生命周期）的方法论雏形。SDLC将开发拆解为需求分析、设计、编码、测试、部署与维护等线性阶段。而当AI智能体开始承担大量任务决策与执行职能，一种全新范式——ADLC（Agent Development Life Cycle，智能体开发生命周期）应运而生。它与SDLC最本质的区别在于：ADLC不是单向流水线，而是一个自我驱动的飞轮系统。

ADLC并非一次性闭环，而是持续旋转、动态迭代的循环：六大环节——确立评估标准、开发实现、效果评估、灰度发布、持续监控、优化迭代——彼此首尾相衔。最后一个环节的反馈会直接回流至起点，驱动评估标准与基准数据集的更新。如果说传统软件是“开发→测试→上线”，那么智能体则是“定标→开发→评估→上线→监控→归因失败→更新标准→再开发”。评估既是起点，亦是终点；既是校准器，也是发动机。

☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜

假设你是一家企业的负责人，正计划启动一项Agent项目，并已锁定典型业务场景。那么在敲下第一行代码前，你必须先回答一个问题：什么样的Agent才算“好”？ 这包括：智能体的角色定义（它是谁、要解决什么问题）、交互风格与人格设定（如何说话、是否带情感）、工具权限与参数约束（能调用哪些能力、如何调用）、以及最关键的——基准数据集（怎样才算“做对了”）。

智能体上线后，真实生产环境产生的数据必须实时、结构化地回流至评估体系。这就要求企业构建完善的可观测性基础设施（指南推荐采用OpenTelemetry标准）。没有可观测性，就无法持续评估；没有持续评估，飞轮便无法转动。最后，系统架构本身需“可评估”——这是最硬核的工程实践，也是评估能否真正落地的底座。指南建议采用三层架构设计：认证层（识别用户身份）、授权层（即Gateway网关，管控Agent行为边界）、会话隔离层（确保不同用户会话互不干扰）。

智能体做出来了，如何判断它是否真正可用？这是最难回答的问题。从基础大模型到千差万别的业务Agent，恰如一棵大树长出万千枝叶、结出各异果实。大模型或许只需几个通用基座，而每个Agent却需匹配专属评估方案——绝不能凭“感觉差不多”就推向生产。

02 评估方法论：双轴驱动，立体衡量

有过Agent开发经验的工程师，大概率经历过这样的窘境：测试环境一切正常，一接入真实流量，就开始“间歇性掉线”——同类请求十次中总有一两次响应异常，令人抓狂。

对Agent而言，“能力”（capability）与“一致性”（reliability/consistency）并非同一维度。“能做到”不等于“每次都能做到”。当多步推理、工具调用、状态写入被串联成一条执行链，任一环节的随机性都会被逐级放大。唯有依靠大规模、高频次、多维度的评估，才能逼近“稳定可靠”的目标。

指南提出评估方法论的“双轴支柱”：
支柱一：评估粒度——决定看得有多深
从仅关注最终输出（黑盒），到追踪完整执行轨迹（玻璃盒），再到拆解单步逻辑（白盒）；
支柱二：证据强度——决定判分有多稳
从机械可验证（Layer 1），到半客观评分（Layer 2），再到默认依赖主观判断（Layer 3）。

黑盒评估聚焦终端结果——用户提问，Agent作答，是否正确？
玻璃盒评估还原全过程——Agent做了哪些决策？调用了哪些工具？每一步推理是否合理？
白盒评估则深入原子操作——某次API调用参数是否准确？某段推理链是否存在逻辑漏洞？
三种粒度由粗至细，分别回应“结果对不对”、“过程对不对”、“每一步对不对”。日常开发以玻璃盒为主干，黑盒与白盒作为必要补充。

三层证据权重中，第一层为机械验证：检查JSON格式是否合规、字段是否存在、响应是否超时等，全程自动化，零主观介入；第二层为半客观的pinned评判：使用固定评估器与明确定义的评分细则，对特定维度打分；第三层为主观默认评判：无统一标准，依赖人工或LLM综合判断。它们分别对应三类评估主体：代码规则、模型、人类专家。

两根支柱相互正交——同一粒度下的指标可来自不同证据层级，同一证据层级也可覆盖多种粒度。二者构成一个3×3评估矩阵，同一组指标需同时选定粒度与证据强度。如此组合，方能实现对Agent输出的全维度、可量化的精准评估。

以AWS自研的客服Agent为例：客服场景最大风险在于意图识别偏差——用户表达与Agent理解出现错位。AWS采用“真实对话数据+虚拟客户模拟”的双轨评估机制，在可控成本下大幅拓展测试覆盖范围，既检验了意图识别准确率，也验证了多轮对话的上下文连贯性。

值得强调的是，由于评估过程本身也常引入模型自动打分，因此评估数据集的质量直接决定了整体评估效能的上限。企业必须构建经过人工精标、且经业务反复验证的高质量测试集——这套数据资产，将成为企业智能体能力演进的核心基石。

关于Agent评估的细化维度还有很多，且因智能体类型而异：客服Agent侧重意图识别准确率与对话连贯性；工具型Agent关注工具选择正确率与参数精度；多Agent协同系统则更看重任务分解合理性与执行稳定性。此处不再一一展开。

AWS所提出的路径与方法论，仅为行业探索中的一种视角。如何真正建好、管好、用好Agent，仍有诸多可能性等待验证。但有一点毋庸置疑：Agent本质是生产力工具，能否交付可量化、可追踪、可归因的业务价值，才是判定其优劣的终极标尺。

步入Agent时代，推动其真正融入生产体系，对企业而言是一场横跨技术纵深与商业逻辑的双重考验。纵有指南在手，能否走通这条路，最终仍取决于企业的战略定力与资源投入。

本文来自微信公众号 “DoNews”（ID：ilovedonews），作者：李信马，36氪经授权发布。