AWS发布Agent DLC方法：用六项活动、两条循环判断Agent能否上线
AWS机器学习博客提出一套面向生产发布的Agent评估流程，并给出一个HR政策助手的实测案例：分块检索精确率三项问题均为 1.00，但事实级精确率分别为 0.59、0.53、0.09，说明单一汇总指标会掩盖覆盖缺口。
AI解读：来源用HR政策助手的参考实现说明指标选择如何影响诊断：三个问题在分块级检索精确率上都是 1.00，只看这一项会全部放行；事实级精确率分别是 0.59、0.53、0.09，第三个问题的检索覆盖率为 0.00，指向知识库缺少专门的病假政策文档，而不是提示词问题。
只改系统提示词后，第一个问题的接地性从 0.83 升到 0.87、事实级精确率从 0.59 升到 0.85；第三个问题接地性从 0.39 降到 0.31、事实级精确率从 0.09 降到 0.04。作者据此说明，同一处修改可能让不同问题朝相反方向变化，提示词无法补上来源材料缺失的信息。
Agent DLC把Define、Build、Evaluate、Release、Observe、Feed Back六项活动围绕一份“金标准”组织，标准包含可验证准则、阈值和经业务负责人批准的示例。文中的判断是：内层循环在固定标准下改进Agent，外层循环才允许修改标准；把缺少准则的问题当成提示词问题会造成混乱。
标准分五个维度（领域理解、质量、责任、成本、性能）和三个层级：硬约束按每次运行做布尔判定，违反即不得发布；发布门槛按k次运行的通过率阈值判定；监控项暂不阻塞发布。作者强调，其他维度的高分不能抵消硬约束违规。
作者称这套流程来自AWS的实践总结，并引用Fotor的AWS客户案例：迁移前先定义可扩展性、成本、隔离和架构灵活性标准，案例报告工作流开销从分钟级降到秒级（不含模型推理），支持数千个并发活跃会话，并把质量评估列为下一步。作者同时注明，HR助手结果是参考实现上的测量，不是客户成果或基准测试结果，分数会随运行和仓库版本变化。
AWS机器学习博客发布文章《From prototype to production: Engineering agents with Agent DLC》，作者Yuan Wei，介绍一套名为Agent Development Lifecycle（Agent DLC）的Agent开发与发布方法，并用一个内部HR政策助手的参考实现展示评估指标如何影响诊断。
文章的前提是：Agent能通过演示，不代表可以进入生产。负责发布决策的人需要可重复、成本可接受的证据，用来说明Agent当前表现如何、最近一次改动是否带来改善。作者认为，传统软件开发的单元测试与CI/CD仍然适用，但Agent有三项特性需要额外检查。
三项特性让传统CI/CD不够用
作者列出三项特性。第一，Agent是非确定性的：相同输入可能产生不同输出和执行路径，因此每个用例只做一次断言，实际只测了分布中的一个样本。第二，提示词就是源代码：对提示词、工具描述、检索设置或记忆配置的修改，可能以文本审阅无法发现的方式改变行为。第三，模型端点、知识库和外部API会独立于代码仓库发生变化，仓库没有改动也会导致Agent行为变化。
对应的做法是：每个示例运行k次，按通过率和失败分布判断；每次提示词、工具、检索和记忆改动都附带评估并保留版本沿革；按计划重跑标准，并在偏离基线时告警。
参考实现：汇总指标掩盖覆盖问题
作者构建了一个HR政策助手作为参考实现，在文档知识库上回答HR政策问题，并用三个“金标准问题”各测五项指标：接地性、分块级来源精确率、事实级来源精确率、检索覆盖率、回答精确率。
第一轮结果中，分块级来源精确率三个问题都是 1.00。只按这一项设置发布门槛，三个回答都会被接受。事实级来源精确率分别是 0.59、0.53、0.09；“病假证明”问题的检索覆盖率为 0.00，接地性为 0.39，被判定为失败。作者解释，分块级精确率只问一段内容是否切题，不问其中多少内容与问题相关。
随后团队只改了一个变量：在系统提示词中加入三条约束——严格基于检索内容作答、忽略无关检索内容、保持回答聚焦。结果第一个问题（绩效评估）接地性从 0.83 升到 0.87，事实级精确率从 0.59 升到 0.85；第三个问题（病假证明）接地性从 0.39 降到 0.31，事实级精确率从 0.09 降到 0.04，仍然失败。
评估结果把调查方向指向知识库：对照源文档检查后发现，语料库缺少专门的病假政策文档，只有请假管理政策中的简短提及。作者据此指出，当来源材料缺少回答所需信息时，只改提示词无法解决失败；下一步应是补齐政策覆盖，再检查检索。
文章还报告了另一处问题：福利登记问题的回答接地性为 0.90 并通过，但其中出现“我从你的资料中注意到你偏好的联系方式是社交媒体”。作者说明，并不存在这样的用户资料；模型把政策流程中的选项与公共FAQ语料中的无关答案组合，当作关于用户的事实陈述，较高的接地性分数没有捕捉到这个错误的个人声明。作者由此认为，通过某项质量阈值不等于满足责任约束。
作者注明，上述结果在参考实现上测得，不是客户成果，也不是基准测试结果；分数会随运行和仓库版本变化，接近临界值的通过可能变为失败，应结合重复运行和底层证据解读分数差异。
Agent DLC：一份标准、两条循环
Agent DLC围绕一份“金标准”组织六项活动：Define（定义）、Build（构建）、Evaluate（评估）、Release（发布）、Observe（观察）、Feed Back（反馈）。文章把金标准定义为一个具体产物：可验证准则、对应阈值，以及经业务负责人批准、用于检验的示例。Define产出它，Build遵循它，Evaluate使用它，Release对照它检查，Observe重用它在生产中发现偏离，Feed Back把生产中学到的东西带回Define。
外层循环之内还有一个更快的循环：评分、检查执行路径、只改一个变量、重新评估。它针对单个候选版本回答两个问题：该改哪里，改动是否有帮助。作者强调两条循环分工不同：内层在固定标准下改进Agent，外层才允许标准本身变化。开发中发现Agent推荐商品却不检查库存，属于内层问题；生产用户要求Agent代家人查询、而现有准则未覆盖这类情况，则属于外层问题，需要先定义授权边界并补充示例，再用内层循环去满足更新后的标准。
文章指出，把两者混淆会让团队试图用提示词修改去弥补缺失的准则，或者在改进周期中扩大标准，导致无法判断是哪一处改动影响了分数。两条循环也积累可复用资产：业务准则、批准的示例、评估器，以及过去失败如何处理。作者称这些资产比模型和框架更持久，更换模型时应使用同一套准则和示例评估替代模型。
五维度、三层级的发布判定
文章建议从业务负责人定义的业务结果出发，把要求翻译成五个维度的可验证准则：领域理解（术语、别名、多跳关系、企业内部知识）、质量（正确性、完整性、一致性、引用支持）、责任（未授权访问、信息泄露、合规硬约束、可追溯性）、成本（Token消耗、评估器成本、冗余步骤）、性能（延迟、吞吐、稳定性、可用性）。每条准则要写明如何验证、由谁批准。
准则分三个层级，由层级而非维度决定是否阻塞发布：硬约束按每次运行做布尔判定，违反即不发布；发布门槛按k次运行的通过率阈值判定，达标前不发布；监控项暂不阻塞发布，先跟踪并在评估器校准后再升级。作者强调，不能让其他维度的高分抵消硬约束违规：在推荐Agent的例子中，推荐质量是质量维度的发布门槛，保护其他客户信息是责任维度的硬约束，同一业务要求会落在不同维度和层级。
发布决定按任务类型分别作出：只要有硬约束失败就不发布；硬约束全部通过但某一发布门槛未达，受影响的任务类型不发布，除非事先批准了带明确保障措施和停止条件的有限上线，否则转人工处理；全部达标才完整发布。作者称，有限上线不能覆盖硬约束，也不能在失败后下调阈值；评估应包含被阻止和拒绝的请求，并记录准则、阈值、评估器版本和发布决定。
从生产回灌与外层循环
文章建议从第一次测试请求起就记录执行轨迹，便于在开发和生产中定位失败。生产交互应抽样评估，找出失败后与业务负责人确认预期行为；已有准则覆盖的案例加入回归集，暴露缺失要求的案例则更新标准，再用内层循环去满足它。评估要定期运行，以捕捉外部依赖引起的行为变化；标准变更时，应在两个版本下比较结果，以区分为Agent回归还是测试覆盖变化，并把每项结果关联到对应的标准、测试集、评估器和Agent版本。
文章还称，评估和反馈循环需要架构提供证据，因此要从每条准则反推所需记录的系统行为和证据。例如，要区分工具选择错误和执行失败，就需要定义工具用途、可接受输入、输出和错误条件，并在轨迹中暴露实际输入、结果和错误。
AWS上的起步方式与引用案例
文章给出起步安排：选一个范围清晰的业务任务，目标是在一周内建立初始评估基线。前两天由业务负责人和工程师商定验收准则、层级和阈值，准备 20 到 30 个金标准示例，覆盖常见请求和重要边界情况，预期行为由业务负责人批准；第 3 至 5 天实现文章所述的评估器（来源内容在此处截断，后续步骤未给出）。配套的AWS Samples仓库包含基础设施部署、HR Agent、自定义评估器，以及基线和提示词修改后的重评估脚本（09-run-eval.sh和 10-optimize-prompt.sh），还包含评估器可重复性、模型对比、成本和延迟的可选检查；作者注明分数会随运行和仓库版本变化。
文章引用Fotor已发布的AWS客户案例作为先定义验收标准再迁移的实践：团队在迁移到Amazon Bedrock AgentCore的AgentCore runtime之前，定义了可扩展性、成本、隔离和架构灵活性准则，然后用运行数据验证改动。案例报告工作流开销从分钟级降到秒级（不含模型推理），支持数千个并发活跃会话，并把质量评估列为下一步。