ADLC 是什么？和传统软件开发生命周期 SDLC 有什么区别？一套为生产级 AI Agent 设计的开发飞轮

ADLC 是Agent Development Lifecycle，即智能体开发生命周期。

亚马逊云科技在《企业生产级智能体开发部署指南》中提出，企业不能简单照搬传统软件开发生命周期 SDLC 来开发 AI Agent。原因在于，智能体具有非确定性，Prompt、模型、工具和外部依赖的变化都可能改变系统行为，因此需要一套以持续评估和生产反馈为核心的新方法。

ADLC 不是在 SDLC 上增加一个“模型测试”步骤，也不是对传统流程的小修小补，而是针对 AI Agent 特征进行的一次完整重构。最直观的区别是：

ADLC 包含哪些环节？

白皮书将 ADLC 归纳为六个首尾相连的环节。

1.定义什么叫“好”

在开发 Agent 之前，团队先定义成功标准，而不是先问“它能做什么”。

这一步通常需要明确：

• Agent 要解决什么业务问题；

• 哪些任务属于职责范围；

• 哪些请求必须拒绝或升级人工；

• 采用哪些技术指标和业务指标；

• 用什么基准数据集验证效果。

例如，一个财务分析 Agent 不应模糊地定义为“回答财务问题”，而要明确它可以查询哪些区域和时间段的数据、可以调用哪些工具、不能访问哪些敏感信息，以及什么样的准确率、延迟和成本才算合格。

2.构建 Agent

目标和验收标准明确后，再开始选择模型、编写 Prompt、配置工具、连接知识库和设计多轮交互。

在这一阶段，Prompt、工具名称、参数、返回格式、异常处理方式和使用边界都属于需要治理的工程资产，而不只是临时配置。

3.系统评估

Agent 构建完成后，需要按照第一步定义的标准，对任务完成、工具使用、安全性、忠实度、延迟和成本等维度进行评估。

评估不能只看最终答案，还要检查完整 Trace、工具选择、参数填写和中间步骤，判断 Agent 为什么成功或为什么失败。

4.质量门控发布

评估结果达到预设门槛，版本才可以进入生产。

例如，企业可以为工具选择准确率、拒答准确率、任务完成率、P50/P95 延迟和 Token 用量设定上线标准。关键指标不达标时，不能仅凭演示效果发布。

5.生产环境观测

Agent 上线后，需要持续观察真实流量中的表现，包括延迟、错误率、工具调用模式、用户反馈和质量变化。

真实用户的表达方式往往比测试集更复杂，模型、知识源或外部 API 也可能发生变化，因此上线并不意味着评估结束。

6.挖掘失败案例

生产环境中的错误、异常 Trace 和边界请求，应持续回流到评估数据集中。

这些真实失败案例可以成为下一轮回归测试的输入，帮助团队改进 Prompt、工具定义、检索策略或系统架构。随后重新评估、重新发布，再继续观察，形成持续循环。

ADLC 和 SDLC 的核心区别是什么？

区别一：SDLC 假设软件行为相对确定，ADLC 面对概率性系统

传统软件通常可以定义固定输入与固定输出，通过断言判断结果是否正确。

AI Agent 的输出存在概率性。同一个请求多次运行，回答、工具选择或调用路径可能不完全一致。因此，ADLC 更关注：

• 多次运行的成功概率；

• Agent 的稳定性和一致性；

• 不同表达方式下的表现；

• 失败场景的分布；

• 系统是否发生质量漂移。

传统的单次“通过或失败”测试，很难覆盖这些问题。

区别二：SDLC 通常先开发再测试，ADLC 强调先定义评估

在传统项目中，团队往往先完成需求、设计和开发，再进入测试阶段。

ADLC 则要求将“定义什么叫好”放在构建之前。基准数据集、指标和上线门槛不是开发完成后的验收材料，而是开发过程的起点。

这也是 Evaluation-first 方法的核心：没有评估标准，团队无法判断系统当前在哪里，也无法判断一次修改是否真正带来了改进。

区别三：SDLC 把生产视为流程终点，ADLC 把生产视为重要输入

传统开发流程通常是：

需求 → 设计 → 开发 → 测试 → 上线

上线后进入维护阶段，下一个版本再重新开始。

在 ADLC 中，生产环境会产生最有价值的真实数据。用户交互、失败 Trace、新边界场景和外部依赖变化，都会成为下一轮评估与优化的输入。

因此，ADLC 的逻辑是：

定义“好” → 构建 → 评估 → 门控上线 → 生产观测 → 挖掘失败案例 → 重新评估

生产不是终点，而是飞轮继续转动的燃料。

区别四：SDLC 侧重代码版本，ADLC 需要同时治理多种依赖

传统软件的核心变更通常来自代码和配置。

AI Agent 的行为还受到以下因素影响：

• System Prompt 和业务 Prompt；

• 使用的基础模型及模型版本；

• 工具描述和参数结构；

• 知识库与检索策略；

• 第三方 API；

• 记忆与多轮对话上下文；

• 多智能体的任务分配和交接逻辑。

即使代码没有修改，这些依赖发生变化，也可能引发 Agent 的静默漂移。因此，ADLC 要求每次换 Prompt、加工具或换模型后重新评估。

ADLC 为什么特别适合生产级 Agent？

Demo 阶段通常只需要证明 Agent 能完成几个预设任务。生产阶段则要证明它能够在真实环境中持续、稳定、可控地交付。

ADLC 通过持续评估，把四项能力贯穿整个生命周期：

• 规格说明：定义什么叫“好”；

• 质量门控：决定版本能否上线；

• 生产监控：发现质量衰退与静默漂移；

• 改进驱动力：把失败案例转化为下一轮优化依据。

这套方法的目标不是让 Agent 永远不出错，而是让企业能够发现错误、定位原因、验证修复，并持续提高系统可靠性。

企业应该如何开始采用 ADLC？

企业不必一次搭建完整的平台，可以先从一个边界清晰、价值明确的 Agent 场景开始：

1.先定义任务目标、禁止事项和人工升级条件；

2.建立一组代表性基准用例；

3.从开发第一天记录完整 Trace；

4.设置任务、工具、安全、延迟和成本指标；

5.把评估嵌入每次 Prompt、模型和工具变更；

6.上线后持续回收失败案例，扩充评估集。

从这个角度看，ADLC 与 SDLC 并不是简单的替代关系。传统的软件工程能力仍然重要，但企业需要在其基础上增加一套适应概率性、可变性和隐式依赖的智能体工程纪律。

如需完整了解 ADLC 六个环节、Evaluation-first 方法和生产评估闭环，您可以通过亚马逊云科技官网首页 Banner，进入《企业生产级智能体开发部署指南》专题页面，填写信息后免费下载完整白皮书。