亚马逊云科技企业生产级智能体开发部署指南

目录 第一篇:企业智能体之旅:为什么评估(Evaluation)是一切的起点 从原型到生产：一道被低估的鸿沟5为什么传统软件工程方法对智能体失效67企业智能体开发：三类工程实践8 ■第一类：把评估跑起来8■第二类：让数据持续流入评估14■第三类：让系统架构可被评估15 结语：评估是规格说明、是质量门控、是生产监控、也是改进的驱动力20 第二篇:评估企业级智能体：从原型验证到生产就绪 三个常见的智能体评估误区23评估方法论框架：两根支柱(评估粒度+证据权重)23打分器的选择与八类测量维度25评估的工程化落地：从流程嵌入到数据集积累27LLM-as-a-Judge 的价值与边界30Agent-based Evaluation:将专家级评审规模化30最佳实践清单与结论33 第三篇：如何在亚马逊云科技上构建企业级智能体 评估框架全景：自动化工作流+三层评估库37关键指标体系：按智能体形态选指标，而不是堆指标38Trace-driven评估工作流:四步把评估自动化41评估数据集与HITL：评估质量的上限由它们决定42工程纪律：把评估嵌入开发流程，而不是上线前跑一次43工具支持:AgentCore Evaluations44 实战案例：从工具使用到多智能体协作 案例一:Amazon 购物助手一一工具使用评估47案例二：Amazon客服智能体一一意图检测评估48案例三:Amazon卖家助手一一多智能体协作评估49 结语：评估是循环，不是终点 50 |全系列摘要(Summary) 本系列共四篇文章，目标是为企业团队提供一套从原型到生产的智能体工程纪律路线图。整套内容围绕一个核心命题展开：AI智能体的工程化落地，瓶颈不在模型能力，而在缺少一套可持续衡量"好不好"的工程体系。 第一篇·为什么评估是一切的起点： 从"为什么传统软件工程方法对智能体失效"切入，剖析非确定性、Prompt即源代码、依赖会自己漂移这三大根因；进而提出ADLc(AgentDevelopmentLifecycle)一一为智能体量身设计的开发生命周期，并把企业Agentic开发归纳为三类工程实践：把评估跑起来／让数据持续流入评估／让系统架构可被评估。 第二篇·评估方法论： 澄清三个常见的评估误区，建立两根支柱的评估框架一一三种评估粒度（黑盒/玻璃盒／白盒)和三层证据权重；明确企业要测的八类维度（质量、性能、责任、成本......）；讨论LLM-as-a-Judge的价值与边界，并引入Agent-based Evaluation将专家级评审规模化。 第三篇·在亚马逊云科技上构建企业级智能体： 给出工程实现层面的全景图一一自动化评估工作流+三层评估库；按智能体形态（单Agent／工具调用/多Agent)匹配关键指标；讲清Trace-driven评估工作流的四个步骤；并把评估嵌入到开发流程中，配合AgentCore Evaluations形成Observability→Evaluation→Optimization的闭环。 第四篇·实战案例： 用三个Amazon内部生产级案例对应不同的评估侧重-一购物助手（工具使用）、客服智能体（意图检测）、卖家助手(多智能体协作)，覆盖智能体从简单到复杂的演进路径，最终收束到一个可亲手跑通的评估闭环。 如需进一步了解Evaluation-first方法在实际场景中的落地方式，可参考本系列配套动手实验示例代码：https://github.com/aws-samples/sample-eval-first-building-enterprise-agents-with-agentcore 第一章： 企业智能体之旅：为什么评估（Evaluation是一切的起点 从原型到生产：一道被低估的鸿沟 过去一年，AI智能体已经从技术探索进入工程落地阶段。越来越多的企业团队开始构建能够调用工具的LLM系统、串联多个API的编排流程，以及基于内部知识库的对话助手。 原型验证阶段通常进展顺利一一Demo效果令人满意，业务方反馈积极。然而，当团队尝试将这些系统推向生产时，一个关键问题浮现：它真的准备好上生产了吗？ 大多数团队正是在这里遭遇瓶颈。制约因素并非模型能力本身，而是缺少一套工程化的质量评判体系套能持续回答"它到底好不好"的方法。 这道鸿沟并非偶然。传统软件拥有单元测试、CI/CD流水线和明确的通过/失败（pass/fail)标准。AI智能体没用一行assert语句来验证一个多步推理的过程是否正确。 这本质上是一个工程纪律问题，而非模型能力问题。 本系列共四篇文章，目标是提供一套完整的智能体工程纪律路线图。我们从首先要解决的一件事开始一一评估（Evaluation），它是一切其他工程实践的地基：没有评估，团队既不知道自已在哪里，也不知道改了之后有没有变好。 为什么传统软件工程方法对智能体失效 智能体身上会系统性地失效。原因有三。 1.非确定性：你的测试用例今天通过,明天可能失败 传统软件的测试逻辑很简单：给定输入A，断言输出是B。这在智能体身上不成立。 LLM本质上是概率模型。同样的输入，每次调用的输出在统计分布上是不同的。更反直觉的是，即使把temperature设为0（通常被理解为"最确定性的模式"），输出仍然不能保证完全一致：GPU浮点运算的非结合性、Mixture-of-Experts 的路由机制、批处理的顺序依赖，都会引入微小但真实的差异。目前没有任何主流模型提供商承诺完全确定性的输出。 由此可见，传统的通过/失败测试框架在这里根本不适用。我们需要的不是断言，而是评估一一在一个分布上衡量行为，而不是验证一个确定的结果。 2.自然语言就是"源代码":改了Prompt 就是改了代码 在传统软件里，改代码会留下Gitdiff，有代码评审（CodeReview），有版本历史，有回滚路径。Prompt没有这一切。 修改一段系统 Prompt,可能只是在末尾加了一句话,但智能体的行为已经发生了根本性的变化-它可能开始拒绝某类请求，可能改变了工具的调用顺序，可能输出格式悄悄变了。没有任何静态分析工具能提前告诉我们这次修改的影响范围。 因此,每一次Prompt变更,都必须有配套的评估来量化影响。没有评估,Prompt工程就是在黑箱里射击。 3.依赖会自己动:没有部署任何东西,但智能体的行为变了 传统软件的依赖是锁定的:package.json里有版本号，升级会发生什么是可预期的。模型是隐式依赖，而且它会自己更新。 模型提供商会定期对模型进行安全微调、能力升级或系统提示调整,通常不会发布详细的Changelog。结果是：代码库没有任何变动，但某天早上智能体开始对某类问题产生不同的响应一一更保守了，或者格式变了，或者工具调用的倾向改变了。如果没有持续的评估基线，这种漂移几乎不可能被及时发现。 以上三点共同指向同一个结论：传统的CI/CD和QA框架不是为这种系统设计的。我们需要一套新的方法论一一一套能在概率性、可变性、隐式依赖这三个条件下持续衡量系统质量的工程体系。这就是接下来要谈的ADLC。 ADLC (Agent Development Lifecycle) :为智能体量身设计的开发生命周期 既然传统SDLC对智能体失效，我们需要一套为它量身设计的方法论。业界正在形成共识的框架叫做ADLC(AgentDevelopmentLifecycle)一一它不是对SDLC的修补，而是一次完整的重构。 ADLC是飞轮，不是流水线 传统软件开发是线性的：需求→设计→开发→测试→上线。上线是终点，下一个版本从头开始。这套逻辑对智能体不成立，因为智能体在生产环境里运行的每一次对话，都是关于它真实行为的最宝贵数据。 ADLC是一个持续运转的飞轮，六个环节首尾相连： 2.构建 1.定义"好" 3.评估 基于清晰的定义，搭建智能体系统。 用第一步定义的标准，系统性地衡量智能体的行为。 在动手构建之前，先确定什么叫成功。这不是一句愿景，而是具体的评估标准、基准数据集。 5.生产观测 6.挖掘失败案例 4.门控上线 智能体上线后，持续追踪它在真实流量下的表现一一延迟、成功率、工具调用模式、用户反馈。 评估不只是用来看的，它是上线的通行证。评估指标未达阈值，不部署。 从生产Trace中找到智能体失败或表现异常的样本，将它们加入评估集，持续选代。 AgentDLC一评估驱动的开发+生产环境反哺的飞轮 核心主线：评估即规范、即gate、即监控、即奖励函数。谁掌握了评估，谁就掌握了整个生命周期， 与传统CI/CD 最关键的区别 在传统流水线里，"生产"是流程的终点。在ADLC里，生产是飞轮最富价值的输入。 这个转变意义深远。它意味着评估集不是在项目初期一次性定义的静态资产，而是随着生产数据持续生长的动态系统。每一个在生产中暴露的真实失败案例，都比在会议室里预设的测试用例更有价值一一因为它来自真实用户，在真实上下文下触发了真实的问题。 还有一条长期价值链值得关注：生产Trace可以变成评估数据，评估数据在积累到足够规模后，可以变成微调或蒸馏的训练数据。今天投入可观测性和评估体系的成本，会在未来以模型优化的形式产生复利回报。 定义"好"是第一步,不是上线后的复盘 这个排序看起来显而易见，但在实践中经常被颠倒。很多团队的顺序是：先把Demo做出来，上线后用户反馈来了再想怎么衡量好坏。 这往往意味着显著的返工成本。如果上线时没有评估基线，就无法判断下一次改动是变好了还是变坏了。失去的不只是某一次Prompt改进的验证能力，而是整个系统迭代的方向感。 ADLC强制要求把"定义好"放在第一位，本质上是在要求团队在开始建造之前，先想清楚验收标准是什么一一就像盖楼之前要先出图纸，而不是等楼盖完了再画。 企业Agentic 开发：三类工程实践 理解了ADLC这套方法论之后，落地就需要具体的工程实践。亚马逊云科技在大量企业智能体项目中积累的经验，看起来分散，但有一条主线贯穿始终：要么在直接做评估，要么在为评估奠基。 仔细看，这些实践分别回答三个问题：如何把评估本身跑起来、如何让数据持续流入评估系统、以及如何让系统架构上可被评估。三者缺一不可一评估流程是出口，数据是管道，架构是地基。我们按这个逻辑,分三类展开。 第一类：把评估跑起来 从小做起，先定义"成功"长什么样 很多团队启动智能体项目时，第一个问题是"这个智能体能做什么"。这是个错误的起点。 正确的第一个问题是：我们要解决什么问题？ 从问题出发，倒推智能体的边界：它应该处理什么，不应该处理什么。如果在建一个财务分析助手，先只做查季度收入、计算增长率、生成摘要"这三件事，把它们做可靠了，再扩展。不要从一开始就想把所有场景都覆盖一一那只会让Prompt越来越复杂，工具选择越来越混乱，性能越来越难归因。 启动一个智能体项目，应该产出四个具体交付物，而不仅仅是代码： 智能体应该做什么和不应该做什么的清晰定义。把它写下来，与利益相关者分享，用它来拒绝功能蔓延。智能体的语气和个性。决定它是正式还是对话风格的，如何问候用户，以及遇到范围外的问题时如何处理。每个工具、参数和知识源的明确定义。模糊的描述会导致智能体做出错误选择。4期望交互的基准数据集，覆盖常见查询和边缘情况。 最后这一项是关键。基准数据集是整个评估体系的燃料"一没有它，评估系统无从运转，连"智能体有没有进步"都无法回答。它不是上线后再补的东西，而是启动前就要准备好的基础设施。 用这个有限范围构建PoC，然后用真实用户测试。他们会立即发现没有预料到的问题智能体可能在日期解析上出错，可能不能很好地处理缩写，或者在问题换一种表达方式时就调用了错误的工具。在PoC阶段学到这些，代价是几周时间；在生产阶段学到，代价是信誉和用户信任。 从第一天开始自动化评估 有了基准数据集，下一步是建立自动化评估机制一一让它成为开发流程的一部分，而不是上线前临时跑