当 AI 智能体开始自主拆解任务、修改代码、运行测试并参与部署，传统软件开发生命周期（SDLC）中的线性阶段就会显得迟缓。Cloudflare 提出的 Agent Development Lifecycle（ADLC），试图把工程重点从“人如何逐步交付代码”转向“系统如何安全地编排、观察和约束自主智能体”。
这不只是给 CI/CD 加一个代码生成模型。它意味着测试、部署、维护和安全控制都要围绕智能体的非确定性行为重新设计。
生命周期不再是一条固定流水线
传统 SDLC 通常按需求、设计、开发、测试、部署和维护推进。即使采用敏捷开发和持续交付，这些环节大多仍由人推动，并且预期输入会产生相对确定的输出。
智能体改变了几个基础假设：
- 一个目标可能被动态拆成多个子任务；
- 不同模型或工具可以在运行时接管不同步骤；
- 同一个提示可能生成不同实现；
- 智能体可能调用外部 API、修改仓库或操作基础设施；
- 失败不一定表现为程序崩溃，也可能是结果合理但不符合业务约束。
因此，ADLC 更像一个持续运行的控制回路：接收目标，生成计划，执行动作，评估结果，再根据遥测数据修正策略。代码仍然重要，但不再是唯一需要管理的工件；提示词、工具权限、模型版本、评估数据和决策轨迹也要进入版本控制与审计体系。
四个支柱如何解决工程瓶颈
自动化软件工厂
自动化软件工厂负责把需求转换为可验证的变更。智能体可以生成代码、测试、配置和文档，但每一类产物都应经过确定性的质量门禁，例如静态检查、单元测试、依赖扫描和策略验证。
关键原则是：让模型负责提出候选方案，让可重复执行的工具负责判断最低质量标准。不要让另一个模型成为唯一的审批者。
动态编排
固定流水线预先规定全部步骤，而动态编排会根据任务风险、运行结果和可用工具选择下一步。例如，文档修订可以直接创建合并请求；数据库迁移则必须增加兼容性测试、预演环境和人工批准。
动态并不意味着无限自由。编排器仍然需要明确允许哪些工具、最大重试次数、预算、超时时间以及必须暂停等待人工确认的动作。
面向智能体的可观测性
CPU、内存和 HTTP 延迟无法完整解释智能体为何做出某个决定。ADLC 还需要记录：
- 接收到的任务和上下文版本；
- 使用的模型、提示模板与工具；
- 每次工具调用的参数、结果和耗时；
- token、调用次数与成本；
- 评估分数、策略拒绝和人工接管原因；
- 从目标到最终部署的完整关联 ID。
涉及凭据、个人信息和客户数据时，日志必须先脱敏，并设置保留周期。可观测性不能成为新的数据泄露通道。
自主智能体的安全模型
传统服务账号经常拥有长期、宽泛的权限，这对自主智能体尤其危险。更稳妥的模型包括短期身份、最小权限、工具白名单、环境隔离和高风险动作审批。
“允许读取仓库”与“允许向生产分支推送”应当是两个独立权限。“可以生成部署计划”也不应自动等于“可以执行生产部署”。
一个可以改造的最小 ADLC 门禁
下面不是 Cloudflare 产品接口，而是一个可直接运行并扩展的示例：智能体完成任务后写出 JSON 事件，门禁程序检查测试结果、风险级别、成本和人工批准状态。它展示的是 ADLC 中“自主执行，但由策略约束”的基本做法。
将以下内容保存为 gate.py：
#!/usr/bin/env python3
import json
import sys
from pathlib import Path
POLICY = {
"allowed_tools": {"git.read", "git.patch", "test.run"},
"max_cost_usd": 2.00,
"human_approval_for": {"production_deploy", "database_migration"},
}
def evaluate(event):
reasons = []
tools = set(event.get("tools_used", []))
forbidden = tools - POLICY["allowed_tools"]
if forbidden:
reasons.append(f"使用了未授权工具: {sorted(forbidden)}")
if not event.get("tests_passed", False):
reasons.append("测试未通过")
if event.get("cost_usd", 0) > POLICY["max_cost_usd"]:
reasons.append("执行成本超过上限")
action = event.get("requested_action")
if action in POLICY["human_approval_for"] and not event.get("approved_by"):
reasons.append(f"动作 {action} 需要人工批准")
return reasons
def main():
if len(sys.argv) != 2:
raise SystemExit("用法: python gate.py events.json")
event = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8"))
reasons = evaluate(event)
result = {
"task_id": event.get("task_id"),
"decision": "deny" if reasons else "allow",
"reasons": reasons,
}
print(json.dumps(result, ensure_ascii=False, indent=2))
raise SystemExit(1 if reasons else 0)
if __name__ == "__main__":
main()
再创建一份模拟事件 events.json：
{
"task_id": "task-2025-001",
"model": "example-model-v1",
"tools_used": ["git.read", "git.patch", "test.run"],
"tests_passed": true,
"cost_usd": 0.42,
"requested_action": "create_pull_request",
"approved_by": null
}
运行门禁：
python3 gate.py events.json
允许执行时，程序会输出 allow 并返回退出码 0，因此可以直接接到 CI 流水线中：
python3 gate.py events.json
# 只有门禁通过才继续
./create-pull-request.sh
实际接入时，可以把 allowed_tools 改成组织内部的工具标识，把成本上限改为任务预算，并将生产部署、密钥变更和数据库操作统一列为强制审批动作。事件还应写入集中式追踪系统，而不是只保存在 CI 临时目录中。
测试对象需要从代码扩大到行为
采用 ADLC 后，单元测试仍然必要，但覆盖范围需要继续扩大：
- 代码测试：验证生成的实现是否正确。
- 工具契约测试：验证智能体能否正确构造 API 参数并处理失败。
- 轨迹评估：检查智能体是否绕过流程、反复调用工具或读取无关数据。
- 安全测试：使用提示注入和恶意工件测试权限边界。
- 线上评估：跟踪任务成功率、回滚率、人工接管率和单位任务成本。
这些指标应按模型、提示版本和编排策略切分，否则升级后出现退化时，很难定位究竟是哪一层发生变化。
落地时不要一次性交出全部权限
ADLC 更适合渐进采用，而不是直接替换现有交付体系。可以从只读任务开始，例如分析失败日志、生成测试或提出补丁建议；随后允许智能体创建分支和合并请求，但保留人工审查；等评估数据稳定后，再开放低风险环境中的自动执行。
上线前至少确认以下事项：
- 智能体、提示、模型和工具定义都具有可追踪版本；
- 每个工具使用独立、短期且最小化的权限；
- 高风险动作存在不可绕过的人工门禁；
- 调用轨迹经过脱敏并可关联到具体任务；
- 预算、超时、重试和停止条件均有硬限制；
- 模型不可用或行为异常时，可以降级到传统流程；
- 团队能够回放一次决策，并解释它为何获得部署权限。
ADLC 的价值并不在于完全移除工程师，而在于把工程师从逐步执行者变成目标、策略和边界的设计者。自动化程度越高，确定性的门禁、清晰的权限和可回放的证据就越重要。