AWS 提出 Agent DLC：从原型到生产的智能体工程方法

在过去一年里，AI 智能体已从探索阶段进入工程化阶段。企业团队正在交付能够调用工具、编排 API，并基于内部知识回答问题的大语言模型（LLM）系统。

一次成功的演示可以展示智能体的能力。但在发布之前，团队还需要回答一个更深的问题：“这个智能体是否已准备好投入生产？”负责做出这一决定的人需要有证据证明智能体满足了既定的要求。

为了能始终如一地做出这一决定，团队需要一种可重复、低成本的方法来评估智能体当前的行为，以及最新的变更是否带来了改进。

在传统软件开发中，团队通过单元测试、持续集成和持续交付（CI/CD）以及通过构建来回答这些问题。这些机制对智能体来说是必要但不充分的，原因有三，每个都需要额外的检查。本文解释了这三个特性，并给出了一个经过实测的案例：一个聚合指标掩盖了覆盖面问题。随后，本文介绍智能体开发生命周期（Agent DLC）：一个生命周期、两个循环，以及一个用于评判每次变更的统一明确标准。

术语说明： 在本文中，黄金标准指的是一个特定的工件：可验证的准则及其阈值，以及用于校验的已批准示例的集合。业务负责人批准该标准，作为验收决定的依据。

1. 智能体需要额外工程实践的三个特性

传统的软件测试和 CI/CD 仍然适用于智能体，但有三个特性需要额外的检查。第一，智能体是非确定性的：相同的输入可能产生不同的输出和执行路径。第二，对提示词、工具描述、检索设置或内存配置的变更可能会以仅靠文本审查无法发现的方式改变行为。第三，模型端点、知识库和外部 API 可以独立于代码仓库发生变化，从而影响智能体的行为。表 1 总结了应对每个特性所需的工程实践。

表 1. 每个特性会使什么失效，以及需要用什么来替代。

2. 一个实测案例：高检索精度可能掩盖信息缺失

下面的例子展示了指标的选择如何影响诊断结果。

我们构建了一个参考实现来端到端地验证这一方法：一个内部政策助手，基于文档知识库回答 HR 政策问题。我们选择了一个范围狭窄、界定清晰的领域，以便评估和诊断易于跟随。以下结果均基于该参考实现测得。它不是客户成果，也不是基准测试结果。

随附的 AWS Samples 仓库包含基础设施部署、HR 智能体、自定义评估器，以及用于基线评估和提示词变更后重新评估的脚本（09-run-eval.sh 和 10-optimize-prompt.sh）。它还包含用于评估裁判可重复性、模型对比、成本和延迟的可选检查。这些脚本可复现该工作流程。分数可能因运行和仓库版本而异。

三个黄金问题，每个五项指标：

• 事实依据性（Groundedness）：将答案分解为多个论断，并逐条对照检索到的来源进行核查。
• 块级来源精确率：每个检索到的块作为一个整体，对这个问题是否必要？
• 事实级来源精确率：将每个块分解为单个事实，并检查每个事实是否必要。
• 检索覆盖率：对于每个子问题，是否有任何检索到的块能够回答它？
• 回答精确率：答案中的论断里，有多少是必要的？

表 2. 第一轮评估。基于参考实现测得。非客户成果。

三个问题的块级精确率均为 1.00。仅基于这一指标的发布门禁会接受全部三个答案。

事实级精确率讲述了不同的故事：0.59、0.53、0.09。对于第三个问题，检索到的材料中大约每十条事实就有九条与所问内容无关。块级精确率只问一个段落是否切题，并不衡量该段落的多少内容是相关的。

然后我们只改变了一件事：系统提示词。我们增加了三条约束：严格基于检索到的内容作答、忽略不相关的检索内容、保持答案聚焦。智能体、知识库、评估器和问题均未改动，因此前后对比只差一个变量。

表 3. 仅更改提示词之后。一次更改，两种相反的结果。

第一个问题有了显著改善。第三个问题则变得更差。

评估在我们做出更改之前就指出了应该调查的方向。再看一下表 2 的第三行：块级精确率 1.00，事实级精确率 0.09，检索覆盖率 0.00。这些分数共同表明存在知识覆盖问题：检索到的材料名义上切题，但并未回答问题。要求模型“严格基于检索到的内容作答”无法弥补缺失的信息。

我们将这一诊断结果与实验中使用的源文档进行了核对。语料库中缺少一份专门的病假政策文档，尽管请假管理政策中简要提到了病假。下一步应该是解决政策覆盖范围的问题，然后检查检索，而不是继续修改提示词。

在这个案例中，源材料缺乏回答该问题所需的信息，因此仅靠修改提示词无法解决这一失败。

在这个例子中，评估帮助在进一步修改之前确定了需要调查的问题。

另一个结果说明了为什么事实依据性需要与其他标准一起检查。福利注册问题的回答以 0.90 的事实依据性得分通过，其中包含这样一句话：“我还从您的个人资料中注意到，您偏好的联系方式是社交媒体。”但并不存在这样的个人资料。

政策文档将联系偏好列为流程步骤中的一个选项。公开的、众包的、嘈杂的 FAQ 语料库中包含一对以“社交媒体”回答该问题的问答。模型将政策中的一个选项与一条无关的 FAQ 答案组合起来，并将其作为关于用户的事实呈现。很高的事实依据性得分没有捕捉到这一虚假的个人声明。通过质量阈值并不意味着责任约束已得到满足。

这些得分在多次运行之间可能有所变化，一个边缘的通过可能变成不通过。应结合重复运行和底层证据来解读得分差异。第 5 节讨论如何检查评估器的可靠性。

这个小型的参考实现示例说明了评估如何指导诊断。它并不能确立一个通用的改进率，也不能验证生产发布。

3. 智能体 DLC：一个生命周期，两个循环

Agent DLC 围绕一个明确的黄金标准连接六项活动：定义、构建、评估、发布、观察和反馈。

评估驱动的开发在此前的工作中已有描述，包括 Xia 等人的 Evaluation-Driven Development of LLM Agents: A Process Model and Reference Architecture。Agent DLC 将这一方法应用于交付，通过六项活动明确验收条件、发布权限和证据要求。

验收优先的方法也出现在 Fotor 公布的 AWS 客户案例研究中。该团队在迁移到 AgentCore 运行时（Amazon Bedrock AgentCore 的一项能力）之前，定义了可扩展性、成本、隔离性和架构灵活性标准，然后根据运营数据验证变更。该案例报告称，工作流开销（不含模型推理）从数分钟降至数秒，并支持数千个并发活跃会话。它记录了 Agent DLC 指导下的架构交付。质量评估被确定为下一步工作。

定义将业务目标转化为标准、阈值和已批准的示例。构建设计必须满足这些标准的提示词、工具、上下文、记忆和运行时机制。评估产生证据，说明候选版本是否满足这些标准。当满足时，该版本进入受控发布。观察监控其在生产环境中的表现。反馈将生产环境所得的经验返回给定义环节。

图 1：Agent DLC 的六项活动各自与中心的黄金标准相关联。Define（定义）生成该标准，Build（构建）遵循该标准，Evaluate（评估）使用该标准。Release（发布）对照该标准进行核查，Observe（观察）复用该标准，Feed Back（反馈）对其进行迭代。标准的五个维度列于下方

图 1 展示了每项活动如何使用或更新该标准，从而明确了它在开发和发布中的作用。

在这个外层循环之内运行着一个更快的内层循环：打分 → 检查路径 → 改动一处 → 重新评估。它作用于一个候选版本，并回答两个问题：该在哪里改，以及改动是否有效。

这两个循环承担着不同的工作，而这一区别至关重要。内层循环依据固定的标准改进智能体。外层循环则允许标准本身发生变更。在开发过程中发现智能体在推荐产品时未核对库存，这是内层循环的问题。假设生产环境中的用户要求智能体代表家庭成员查找信息，但没有任何准则覆盖这一情形。这就需要外层循环：定义授权边界并补充示例。然后再用内层循环来达到更新后的标准。

混淆这两个循环可能导致团队试图用修改提示词来修复一个缺失的准则。团队也可能在改进周期中扩大标准范围，导致无法判断是哪项改动提升了分数。

这两个循环都会积累可复用的资产：业务准则、经批准的示例、评估器，以及过去失败案例的处理记录。这些资产的寿命超过模型和框架本身。当你更换模型时，用相同的准则和示例来评估新的模型。

接下来四节将解释如何定义可检验的好（第 4 节），以及如何依据该标准改进智能体（第 5 节）。随后介绍如何通过生产反馈更新标准（第 6 节），以及如何设计架构以提供评估证据（第 7 节）。

4. 定义好：五个维度，三个层级

从由其负责人定义的业务成果出发。对于一个推荐智能体，这可能是：“向回头客推荐合适的产品，同时保护他们的信息。”将该需求转化为五个维度上可验证的准则。

表 4. 定义准则时应考虑全部五个维度。

对于每条准则，应明确其如何验证以及由谁批准。“必须准确”是一个目标。“每一项事实性陈述都必须可追溯到检索到的来源”才是可验证的。业务专家应批准使预期行为具体化的示例。

表 5. 准则分为三个层级。决定一条准则是否阻断发布的，是层级而非维度。

为每条标准分配各自的层级，并在适用时设置阈值。绝不允许其他方面的高分抵消硬性约束的违规。

在推荐示例中，推荐质量是 Quality 维度下的发布门槛，而保护另一位客户的信息则是 Responsibility 维度下的硬性约束。一项业务需求会在不同维度和层级中产生标准，并按各自的验收条件逐一评估。

这些标准还决定了系统必须暴露哪些证据。下一节将利用这些证据来改进智能体并决定是否发布。第 7 节将说明证据需求如何影响架构。

5. 内循环：评估、诊断与改进

评分。让评估器与标准相匹配。对于明确无歧义的规则使用代码，对于成本和延迟使用运行时遥测，对于容量和可用性使用负载测试与运行数据。对于需要判断力的标准，使用基于模型的评审器，并以人工审核过的样本进行校准。在评估信息保护时，除检查禁止字段外，还应包含授权与跨用户隔离测试。对每个样本运行 k 次，以评估其可变行为。

对于基于模型的评审器，应重复评估以衡量打分的波动性，并将其判断与人工审核过的样本进行对比。小幅的分数提升需要证据支持，才能算作改进。

检查路径。在三个层级上定位故障：会话、轨迹和步骤。如果某次推荐暴露了电话号码，应顺着受影响的会话追踪到响应的生成过程，并检查个人资料字段是在何处进入草稿的。原因可能位于可见症状的上游，正如第 2 节所示。

一次只改一处，然后重新评估。修正已识别的原因，并在相同条件下、以未更改的标准重复评估。验证泄露已停止，且推荐质量仍达到其门槛。

针对每种任务类型（即意图）分别评估发布就绪度。只发布达到其标准的意图；未发布意图的任何回退方案也必须满足约定的发布条件。

表 6. 按维度、层级和意图做出的发布决策。

有限发布需要事先商定验收条件、保障措施和停止条件。不能在结果失败后覆盖硬性约束或降低阈值。

发布前，将被拦截和拒绝的请求纳入评估，检查每个请求是否按预期处理。记录标准、阈值、评估器版本和发布决策，以便团队追溯某个版本获批的原因。

通过这些检查，可以支持在测试范围内发布。随后，生产环境监控会检查智能体在用途和依赖关系发生变化时是否仍能持续达标。

6. 外循环：保持数据流动

从第一个测试请求开始记录执行轨迹，以便在开发和生产环境中诊断故障。对生产环境的交互进行抽样和评估以识别故障，然后与业务负责人共同评审，确认预期行为。将现有标准已覆盖的用例加入回归测试集。当某个用例暴露出缺失的需求时，更新标准并使用内循环来满足它。

定期运行评估，以捕捉外部依赖引起的行为变化。当标准发生变化时，在两个版本下对比结果，以区分智能体回归与测试覆盖面的扩大。将每项结果与其标准、测试集、评估器和智能体版本关联起来。

7. 设计架构以支持评估

评估和反馈循环需要架构必须提供的证据。从每条标准反向推导，确定验证它所需的系统行为和记录。

例如，为了区分工具选择错误和执行失败，需要定义工具的用途、可接受的输入、输出和错误条件。在轨迹中暴露实际的输入、结果和错误，以便评估器定位故障。

因此，验收标准同时塑造了评估和架构。在这些基础就绪后，从一个业务任务开始并建立基线。

8. 在 AWS 上入门

选择一个范围明确的业务任务，力争在一周内建立起初始评估基线。

• 第 1–2 天。让业务负责人和工程师就验收标准、层级和阈值达成一致。准备 20–30 个覆盖常见请求和重要边界情况的黄金样例，其预期行为须经业务负责人批准。
• 第 3–5 天。实现第 5 节所述的评估器，并反复运行黄金测试集。发布基线，包括失败情况以及调查它们所需的证据。
• 第 2 周。改变一件事，并在相同条件下重新评估。记录发布决策及其支持证据。

在评审基线之后，将评估集成到发布流程中，并定期运行以检测漂移。指定一名负责人来评审生产环境中的故障，并将确认的用例回馈到标准中。

在 AWS 上，使用通过 Amazon Bedrock 提供的模型来构建智能体。Amazon Bedrock AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项功能，可借助 内置评估器评估智能体行为，并支持针对业务特定标准的自定义评估器。AgentCore Observability 是 Amazon Bedrock AgentCore 的一项功能，提供执行可见性，并由 Amazon CloudWatch 补充用于运行时监控和诊断。AgentCore 的 runtime、Gateway、Identity 和 Memory 支持执行、工具集成、身份管理和内存管理。

关于作者