第 19 章：从 SDLC 到 ADLC¶

1. 为什么这里要先回到经典 SDLC¶

当团队开始构建智能体系统时，常常会很快得出一个结论：“旧流程已经不适用了，我们需要一个全新的生命周期。”

这不是一个好的起点。

经典的软件开发生命周期依然重要，因为它提供了最基础的工程纪律：

需求；
设计；
实现；
测试；
发布；
运维；
退役。

NIST 在面向生成式 AI 的 SSDF 配置文件里采取的也是同样的思路：不是从零发明一套安全开发实践，而是在已有的软件安全纪律之上做扩展。¹

也就是说，智能体系统并没有取代 SDLC。它只是让默认形态的 SDLC 变得不够用。

这正是本章真正的承诺。它不是为了把软件生命周期换一个新缩写，而是为了说明：在第七部分已经搭好的那套受治理系统之上，现在需要一个足够宽的生命周期框架，去容纳模型行为、策略变化、检索漂移、工具副作用、证据，以及随时间推进的退役决策。

2. 哪些东西并没有变¶

如果把炒作拿掉，很多基础工作依然完全熟悉：

需求仍然要写清楚；
架构仍然需要设计评审；
集成仍然需要负责人和契约；
高风险变更仍然需要受控发布；
事故仍然需要复盘和纠正行动。

这点对团队的心理预期很重要。ADLC 不应该被理解成“超越工程的魔法”，而应该被理解成经典工程纪律的成熟扩展。

3. 智能体系统到底改变了什么¶

真正的差异从这里开始。

在普通系统里，行为主要由代码和相对确定性的逻辑决定。到了智能体系统，额外的可变表面出现了：

模型行为具有概率性；
提示和例程对结果的影响并不亚于代码；
检索和记忆会在不改业务逻辑的情况下改变输入；
工具会产生真实的副作用；
策略变更会重塑整类任务的行为；
即使“发布没坏”，在线漂移也可能慢慢出现。

这也是为什么 NIST 的 GenAI Profile 特别强调：可信性考量不能只在发布时出现，而要贯穿设计、开发、使用和评估的全生命周期。²

4. 最好把 ADLC 理解成 SDLC 加上新的变更表面¶

最实用的工程表达其实很简单：

ADLC = SDLC + 模型行为 + 提示/例程 + 策略 + 检索/记忆 + 工具 + 评测 + 受治理自主性

也就是说，新的生命周期不是因为“智能体很神秘”，而是因为现在有更多可变部件需要被发布、评估和治理。本章的主要工件是 ADLC state model：一张状态与转换地图，而不是又一个泛泛的治理清单。

最稳妥的理解方式，是把 ADLC 看成 SDLC 的扩展，而不是替代品

flowchart LR
    A["经典 SDLC"] --> B["需求"]
    A --> C["设计"]
    A --> D["实现"]
    A --> E["测试"]
    A --> F["发布"]
    A --> G["运营"]
    A --> H["退役"]

    H --> I["ADLC 增加"]
    I --> J["模型行为"]
    I --> K["提示与例程"]
    I --> L["策略与审批"]
    I --> M["检索与记忆"]
    I --> N["工具副作用"]
    I --> O["评测与受控自主性"]

5. 哪些东西现在也成了发布承载工件¶

在传统 SDLC 里，团队最常围绕代码、基础设施和数据模式讨论发布。但在 ADLC 里，发布承载工件更宽：

模型选择与路由；
系统指令与例程；
策略配置；
能力契约；
检索语料；
记忆写入规则；
评测数据集；
审批策略；
发布门禁。

贯穿案例：把重复工单当作 ADLC 变更

在支持分诊系统里，修复重复工单事故并不会随着重试代码补丁结束。现在的发布承载工件还包括新的评测数据集、面向 side_effect_unknown 的策略包、create_support_ticket 的能力契约、金丝雀发布门，以及后续调查结果所需的 trace schema。在 ADLC 里，这些变化应该作为一个可审阅的变更集一起移动；否则团队只是发布了代码，却把生命周期继续留在坏掉的状态。

这是最关键的运行转变之一。如果团队只把代码改动当成发布，它几乎一定会漏掉真正高风险的智能体变更。

6. 为什么测试已经不够了¶

测试依然重要，但已经不够。

智能体系统需要更宽的保证轮廓：

针对代码和契约的确定性测试；
面向已知场景的离线评测；
面向多步行为的模拟器或场景化检查；
面向漂移和涌现失败的在线监控；
针对高风险路径的策略检查；
用来控制影响半径的审批与发布门禁。

OpenAI 和 Anthropic 从不同角度都落到了相似的实践结论：先建立基线行为，再在受控条件下迭代，而不是一开始就追求自主性。³⁴

7. 安全保障也需要自己的生命周期¶

在普通服务里，安全审查常常聚焦于代码、依赖、基础设施和访问控制。但对智能体系统来说，这还不够。

Google Research 很清楚地指出，安全保障更应该作为持续循环存在，而不是一次性安全审查：红队测试、漏洞管理、检测与响应、威胁情报和修复必须紧贴发布流程，而不是等问题发生后再补。⁵

这对本书很重要：智能体安全不能被简化成提示注入检查清单，它本质上是一个持续运行的能力。

8. 智能体的供应链不只是包依赖¶

Google 还有一个很有价值的修正：AI 软件供应链不只包含库和容器，还包括模型、数据、配置、流水线以及评测工件的来源证明。⁶

对智能体系统来说，这很关键，因为否则你就回答不了这些问题：

这个模型从哪里来；
这个发布是用什么数据集验证的；
生产环境里到底是哪一个策略包；
当时用的是哪一版检索语料；
两次发布波次之间到底变了哪个提示或例程。

换句话说，ADLC 里的来源证明不是“锦上添花”，而是变更管理和事故调查的基础设施，其中也包括在发布路径退化时恢复像 failure_reason 这样的失败运行导出证据。

9. 好的 ADLC 应该从立项和设计评审开始¶

如果一个智能体项目只有在“已经做出点东西”之后才进入工程流程，那么架构和治理问题往往会暴露得太晚。

有价值的早期问题包括：

这里真的需要智能体，还是工作流就够了；
自主性预算是多少；
哪些副作用是允许的；
信任边界在哪里；
哪些能力属于高风险；
是否真的需要记忆层；
在试点前必须具备哪些评测。

这些其实已经是 ADLC 的第一阶段了。

10. 一个实用的 ADLC 框架¶

对于生产级智能体系统，我建议至少有这些阶段：

立项与适用性评审
架构与安全设计评审
构建与集成
评测基线
分阶段 rollout
稳态运营
事故响应与纠正行动
退役或替换

把 ADLC 看成持续循环，而不是“第一次上线之前的流程”，会更接近真实世界

flowchart LR
    A["立项"] --> B["设计评审"]
    B --> C["构建与集成"]
    C --> D["评测基线"]
    D --> E["分阶段 rollout"]
    E --> F["运营"]
    F --> G["事故与纠正行动"]
    G --> H["退役或替换"]
    H --> A

11. 为什么这会对团队产生真正帮助¶

如果这些内容只被叫做“最佳实践”，团队往往会把它当成可选建议。

但一旦它被组织成生命周期模型，问题就会变得更成熟：

我们现在在哪个阶段；
下一阶段还缺什么；
过下一道门禁前必须产出什么工件；
下一步由谁负责；
如果跳过某个阶段，我们究竟在承担什么风险。

这正是 ADLC 的实际价值所在：它把关于智能体的讨论，从炒作讨论变成可管理的工程计划。

12. 不该怎么做¶

这里有几种非常常见的错误：

直接宣布“普通工程方法对智能体无效”；
把 ADLC 误解成提示迭代的新名字；
以为 rollout 检查清单就等于整个生命周期；
不把提示、策略和检索视为承载发布意义的变更；
不把评测和变更管理连起来；
在最后时刻才想起退役纪律。

如果这样做，ADLC 最终就只会变成一个好听但没运营价值的词。

13. 实用检查清单¶

如果你想快速判断自己是否已经需要完整的 ADLC，可以问：

你们除了代码，还会持续发布提示、策略或模型变更吗？
系统会产生高风险副作用吗？
系统使用检索、记忆或其他可变知识表面吗？
发布决策是否依赖评测？
是否已经需要分阶段 rollout、审批门禁和事故审查？
在发生事故时，你们是否需要解释“当时生产环境里到底是哪一个精确工件”？

如果连续几个问题的答案都是“是”，那你们其实已经活在 ADLC 里了，只是还没有把它明确说出来。

14. 接下来读什么¶

这章之后最自然的延伸，是变更管理、保证回路和供应链纪律。但它现在已经可以和书里已有的内容连起来：