---
name: adlc-lifecycle
version: 2.0
framework: 智能体管理学 · 模块四 · 框架F24
type: 决策型
description: >
  当用户提到Agent开发流程、开发生命周期、ADLC、SDLC对比、
  版本管理、发布流程、迭代管理、开发规范时触发本SKILL。
governance_nerves: [意图管理, 边界与升级]
upstream_frameworks: [F20_TripleE工程方法, F23_AEA架构评估]
downstream_frameworks: [F25_评测矩阵, F26_PRT质量门禁]
---

# F24 智能体开发生命周期（ADLC）

## SKILL定位

专为Agent系统设计的开发流程，从线性流程重构为适应非确定性特征的迭代闭环。

**核心判断：ADLC与SDLC的本质差异在于三点——**
1. 非确定性输出需概率评估，不能用确定性断言
2. 质量门禁看eval分布，而非单次通过/失败
3. 五条版本线（模型/Prompt/Skill/Tool/Context）并行管理

传统SDLC的"需求→设计→开发→测试→上线"线性流程在Agent开发中必然失败。

---

## 信息采集（INPUT模板）

```
【开发现状】
- 当前开发流程：____
- 团队规模与分工：____
- 已有工具链：____
- 发布频率：____

【Agent项目信息】
- Agent类型：____
- 复杂度：（简单/中等/复杂）
- 用户规模：____
- 质量要求：____

【痛点与需求】
- 最大痛点：____
- 期望改进：____
- 时间约束：____

【版本管理现状】
- 是否有版本管理：（有/无/部分）
- 管理的维度：____
- 冲突频率：____
```

---

## 执行分析引擎（S1-S4四步法）

### S1：ADLC六阶段评估

**目标**：评估当前开发流程与ADLC的匹配度

**ADLC六阶段**：

| 阶段 | 核心活动 | 交付物 | 质量门禁 |
|------|---------|--------|---------|
| 发现定义 | 需求分析、用户画像、场景梳理 | 需求文档、场景清单 | 需求评审通过 |
| 上下文设计 | Prompt设计、知识架构、上下文策略 | 上下文设计方案 | 设计评审通过 |
| 能力构建 | Skill开发、工具集成、脚手架搭建 | 可运行Agent | 单元测试通过 |
| 评估驱动迭代 | Golden Task测试、实验、优化 | 优化后Agent | Eval分布达标 |
| 治理上线 | 安全审查、权限配置、监控部署 | 上线Agent | 全量Eval通过 |
| 运营优化 | 数据分析、用户反馈、持续改进 | 优化报告 | 运营指标达标 |

**诊断评分锚点**：

| 维度 | 1分 | 3分 | 5分 |
|------|-----|-----|-----|
| 流程完整性 | 无流程 | 有但不完整 | 六阶段全覆盖 |
| 评估驱动 | 上线前一次性测试 | 关键节点有评估 | 每个迭代都有评估 |
| 版本管理 | 无版本概念 | 部分版本管理 | 五条版本线并行 |
| 自动化程度 | 全手动 | 部分自动化 | CI/CD全流程 |
| 反馈闭环 | 无反馈机制 | 有但不及时 | 实时反馈+自动优化 |

**输出模板**：
```
S1评估结果：
- 当前阶段覆盖：____/6
- 最成熟阶段：____
- 最薄弱阶段：____
- 与ADLC差距：____
- 总体评分：__/5
```

### S2：五条版本线设计

**目标**：设计Agent系统的多维版本管理方案

**五条版本线**：

| 版本线 | 管理对象 | 变更频率 | 管理方式 |
|--------|---------|---------|---------|
| 模型版本 | 基础模型、模型参数 | 低（月级） | 模型registry + A/B测试 |
| Prompt版本 | System prompt、Few-shot | 中（周级） | Git版本控制 + Eval验证 |
| Skill版本 | 技能定义、工具链 | 中（周级） | Skill Hub版本管理 |
| Tool版本 | API接口、数据源 | 低（月级） | 接口版本 + 兼容性测试 |
| Context版本 | 知识库、上下文模板 | 高（日级） | 数据版本 + 增量更新 |

**版本兼容性矩阵**：

```
当模型版本升级时：
  → 检查Prompt兼容性
  → 检查Skill兼容性
  → 检查Tool兼容性
  → 运行全量回归测试

当Prompt版本变更时：
  → 检查与当前模型的兼容性
  → 运行相关Golden Task
  → 验证Skill调用链路
```

**输出模板**：
```
S2版本方案：
- 当前管理的版本线：____条
- 需要新增的版本线：____
- 版本兼容性策略：____
- 版本冲突解决机制：____
- 版本回滚方案：____
```

### S3：质量门禁设计

**目标**：为ADLC各阶段设计概率性质量门禁

**门禁设计原则**：
- 不看单次通过/失败，看Eval分布
- 门禁阈值基于统计置信度
- 允许合理的波动范围

**各阶段门禁**：

| 阶段 | 门禁指标 | 阈值 | 通过条件 |
|------|---------|------|---------|
| 能力构建 | 单元测试通过率 | >90% | 核心功能覆盖 |
| 评估迭代 | Golden Task通过率 | >85% | 三层均有覆盖 |
| 治理上线 | 全量Eval通过率 | >90% | 无P0级失败 |
| 运营优化 | 用户满意度 | >4.0/5.0 | 持续7天达标 |

**输出模板**：
```
S3门禁方案：
- 各阶段门禁指标：____
- 阈值设置依据：____
- 门禁触发后的处理流程：____
- 例外审批机制：____
```

### S4：CI/CD集成设计

**目标**：设计Agent开发的持续集成/持续部署方案

**CI/CD流程**：

```
代码提交
  → 触发CI
    → 代码检查（Lint、格式）
    → 单元测试
    → 集成测试
    → Golden Task子集测试
  → CI通过
    → 触发CD
      → Staging部署
      → 全量Eval测试
      → 人工审核（如需要）
      → Production部署
      → 监控验证
```

**输出模板**：
```
S4 CI/CD方案：
- CI触发条件：____
- CI检查项：____
- CD部署策略：____
- 回滚机制：____
- 监控验证：____
```

---

## 输出格式

```
# ADLC实施方案

## 一、现状评估
- 当前流程覆盖度：____
- 与ADLC差距：____

## 二、六阶段流程设计
- 各阶段活动与交付物：____
- 质量门禁：____

## 三、五条版本线
- 版本管理方案：____
- 兼容性策略：____

## 四、质量门禁
- 各阶段阈值：____
- 门禁流程：____

## 五、CI/CD集成
- 自动化流程：____
- 部署策略：____

## 六、实施路线图
- 第1-2周：____
- 第3-4周：____
- 第2-3月：____
```

---

## 治理神经检查

### 意图管理检查
- [ ] 用户是要"建立流程"还是要"提升开发效率"？
- [ ] 是否存在流程过度复杂化的倾向？
- [ ] 团队是否具备执行ADLC的能力基础？

### 边界与升级检查
- [ ] 开发流程问题是否涉及组织协作（需升级到F07-F12）？
- [ ] 是否需要调整团队结构以匹配ADLC？
- [ ] 技术债务是否需要先清理再建流程？

---

## 质量自检

- [ ] 六阶段是否都有明确的活动、交付物和质量门禁？
- [ ] 五条版本线是否有具体的管理方式？
- [ ] 质量门禁是否基于概率分布而非确定性断言？
- [ ] CI/CD设计是否考虑了Agent的非确定性特征？
- [ ] 是否有版本冲突解决和回滚机制？
- [ ] 是否区分了"流程规范"和"过度流程"？

---

## 典型误区

| 误区 | 正确理解 |
|------|---------|
| "ADLC就是SDLC加个AI" | ADLC需要根本性重构，不是增量修改 |
| "测试通过就能发布" | Agent需要看Eval分布，不是单次通过 |
| "版本管理就是Git" | Agent有五条版本线，Git只管代码 |
| "流程越规范越好" | 过度流程降低迭代速度，需要平衡 |
| "CI/CD对Agent不适用" | 适用但需要改造，加入概率性门禁 |

---

## 框架衔接

### 向上衔接
- **F20 TripleE工程方法**：Triple-E是ADLC的核心工程方法论
- **F23 AEA架构评估**：架构决定了ADLC的技术约束

### 向下衔接
- **F25 评测矩阵**：评测矩阵是质量门禁的数据基础
- **F26 PRT质量门禁**：PRT是CI/CD中回归检测的实现

### 横向关联
- **F21 Skill资产治理**：Skill版本线需要Skill Hub支持
- **F22 执行链路诊断**：链路诊断是评估迭代阶段的核心活动