从原型到生产：用 Agent DLC 工程化 AI 智能体

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

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

为了持续做出这一决策，团队需要一种可重复、成本可承受的方式，来评估智能体的当前行为，以及最新改动是否带来了改进。

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

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

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

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

表 1. 每个特性使什么失效，以及它转而要求什么。

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

以下示例展示了指标选择如何影响诊断。

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

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

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

• 有据性：将答案拆解为若干断言，并逐一对照检索到的来源进行检查。
• 块级来源精确率：每个检索到的块作为一个整体，对于该问题是否必要？
• 事实级来源精确率：将每个块拆解为单个事实，并检查每个事实是否必要。
• 检索覆盖率：对于每个子问题，是否有任何检索到的块能够回答它？
• 回答精确率：在答案的断言中，有多少是必要的？

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

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

事实级精确率则呈现出另一番景象：0.59、0.53、0.09。对于第三个问题，检索到的材料中大约十分之九的事实与所问内容无关。块级精确率只询问一段内容是否切题。它并不衡量该段内容中有多少是相关的。

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

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

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

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

我们对照实验中使用的源文档核验了该诊断。语料库缺少专门的病假政策文档，尽管休假管理政策中简要提及了病假。下一步是解决政策覆盖问题，然后检查检索，而不是继续修改提示词。

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

在本例中，评估帮助确定了在进一步修改之前需要调查的内容。

另一个结果说明了为什么需要在检查其他标准的同时检查有据性。福利登记的回答以 0.90 的有据性得分通过，其中包含这样一句话：“我还从你的资料中注意到，你偏好的联系方式是社交媒体。” 并不存在这样的资料。

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

这些得分在不同运行之间可能有所变化，处于临界值的通过可能变为失败。应结合重复运行和底层证据来解读得分差异。第 5 节讨论了如何检查评估器的可靠性。

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

3. Agent DLC：一个生命周期，两个循环

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

评估驱动开发已在先前的工作中有所描述，包括 Xia 等人的LLM 智能体的评估驱动开发：过程模型与参考架构。Agent DLC 通过六项活动将这一方法应用于交付，并具有明确的验收条件、发布权限和证据要求。

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

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

图1：Agent DLC 的六项活动均与位于中心的金标准相关联。Define 产出它，Build 遵循它，Evaluate 使用它。Release 对照它进行检查，Observe 复用它，Feed Back 迭代它。标准包含的五个维度列在下方

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

在这个外循环内部，运行着一个更快的内循环：评分 → 检查路径 → 改动一处 → 重新评估。它针对一个候选版本运行，回答两个问题：该改哪里，以及改动是否有帮助。

两个循环承担不同的职责，这一区别很重要。内循环让 agent 在固定标准下得到改进。外循环则让标准本身发生变化。开发过程中发现 agent 在推荐产品时未检查库存，这属于内循环问题。假设生产用户要求 agent 代家人查询信息，但没有任何标准覆盖这种情况。这就需要外循环：定义授权边界并补充示例。然后用内循环来满足更新后的标准。

混淆两者可能导致团队试图通过修改提示词来弥补缺失的标准。团队也可能在改进周期中放宽标准，导致无法判断究竟是哪项改动影响了评分。

两个循环都会积累可复用的资产：业务标准、已批准的示例、评估器，以及过往失败处理方式的记录。这些资产的生命周期长于模型和框架。更换模型时，应使用相同的标准和示例来评估替代模型。

接下来四节将说明如何定义好，使其可被检查（第4节），以及如何依据该标准改进 agent（第5节）。随后介绍如何通过生产反馈更新标准（第6节），以及如何设计架构以提供评估证据（第7节）。

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

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

表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 支持执行、工具集成、身份管理和记忆管理。

关于作者

Yuan Wei

Yuan 是 AWS GCR Service Specialist Org 的应用科学家，拥有多年算法开发经验。Yuan 在大型语言模型（LLM）、多模态模型、时间序列预测和 AI 生成内容（AIGC）方面拥有丰富的解决方案开发与部署实践经验。

Tianqin Cai

Tianqin 是 AWS GCR Service Specialist Org 的应用科学家。他的研究聚焦于生成式 AI、自然语言处理和多模态预训练。他在广告与推荐系统、搜索排序、基础模型预训练和多模态 AI 领域的算法开发与实际应用方面拥有丰富经验。

Jiade Wu

Jiade 是 Amazon Web Services (AWS) 的解决方案架构师经理，负责领导大中华区的合作伙伴解决方案架构团队。他的工作聚焦于将 AI agent 从原型推向生产，包括评估驱动开发和 agent 生命周期方法论。他也是一名开源贡献者，在 aws-samples 上有涉及 AWS 上 agent 基础设施和无服务器架构的项目。