Cloudflare 提出智能体开发生命周期 ADLC

背景：AI 改变了软件开发的瓶颈

过去几十年，工程管理者一直在优化多人协作开发同一代码库的方法。这套方法通常被称为软件开发生命周期（SDLC），包含以下阶段：

• 规划
• 设计
• 实现
• 测试
• 部署
• 维护
• 退役

AI 让过去最慢、成本最高的“实现”环节变得更快、更便宜。但这也带来了下游压力：代码生成速度超过了团队在评审、部署、维护和线上保障方面的承载能力。

这种压力已经体现在多个场景中：开源维护者面对大量 Pull Request 和 issue，生产工程师则要应对软件交付速度大幅提升后带来的稳定性风险。

Cloudflare 的判断：不能只让智能体写代码

Cloudflare 认为，当前许多团队对智能体的使用并不均衡：智能体主要被用于生成代码，但验证、合并、部署、值班和问题分诊仍然主要由人类承担。

如果是一名工程师，团队通常不会允许他只写代码，然后把验证、上线、生产事故和缺陷处理全部交给别人。但很多公司目前正以这种方式使用智能体。

随着模型能力提升，智能体能够执行更长周期、更复杂的任务。Cloudflare 的观点是：要让智能体承担更多软件生命周期中的工作，而不仅仅是起始阶段的代码生成。

新工具：让智能体参与更多开发环节

Cloudflare 提出了一组围绕智能体开发生命周期的新工具和实践，包括：

• @cloudflare/ci：一种面向大规模代码仓库运行 CI/CD 的新方式，基于 Cloudflare Workflows，可自我修复，并可派生智能体处理更复杂任务。
• 本地开发中的 OpenTelemetry traces：将生产环境中的可观测能力带到本地开发，集成在 Wrangler 和 Cloudflare Vite 插件中。
• Cloudflare Agents 与 Agent Traces：用于观察、维护和改进智能体，核心是来自智能体的 OpenTelemetry traces。
• 使用 AI 执行工程标准：Cloudflare 分享了其在产品、系统代码仓库和规范中执行最佳实践的经验。
• 面向开源项目的问题处理系统：Cloudflare 介绍了其为 Astro 构建的软件工厂，用于自动分诊、复现、验证和修复 GitHub issue。

从 SDLC 到 ADLC：面向软件工厂的新生命周期

Cloudflare 将这种新模式称为 ADLC，即 Agent Development Lifecycle，智能体开发生命周期。

传统 SDLC 面向的是软件团队，而 ADLC 面向的是“软件工厂”：由智能体驱动的系统，可以接收输入并自主构建、改进、部署和管理软件。

这些输入可能是：

• 生产环境错误
• 用户提交的 bug 报告
• 新功能想法

理想状态下，团队可以将这些任务完整委托给智能体，而不仅仅是让智能体完成其中某个步骤。

当前限制：人仍然在管理每个步骤

即使使用智能体，大多数软件项目仍受制于人类参与环节。常见情况包括：

• 人类给智能体输入提示词
• 人类要求智能体继续执行
• 人类告诉智能体如何根据代码评审意见修改
• 人类同时看管多个智能体并持续下达指令

也就是说，在许多团队中，人仍然管理 SDLC 的每个阶段，只是把阶段内的具体任务交给智能体。

软件工厂的目标，是重新设计整个软件生产过程，让更多人类时间投入到真正需要灵感、品味和判断的工作中，例如产品设计、用户沟通和更大规模的创新。

软件工厂对平台提出的新要求

Cloudflare 认为，如果要让智能体接管更多开发流程，底层平台必须满足一系列要求：

1. 可编程

对人类来说，“ClickOps”已经不是理想实践；对智能体来说更不可接受。每项操作都需要可调用、可调试、可依赖的 API。

2. 可水平扩展

过去，预览部署可能只是锦上添花。但在智能体驱动的开发中，每个智能体都应拥有与生产环境匹配的独立预览环境。

3. 可复现

有些问题只会在特定条件下出现，例如使用 iPhone 15、模拟 4G 网络，或来自某个国家的 IP。传统单元测试和集成测试并不总能覆盖这些情况。

4. 实时、推送式

依赖人类查看仪表盘来发现问题，本来就不是可靠方式；在智能体场景下更难成立。系统需要通过事件触发智能体执行工作。

5. 原子化

每次变更都应能够独立测试、发布、观测和回滚，并且不影响无关行为。

6. 权限化

一些团队会给可信工程师较高权限，以便在生产环境出现严重问题时介入。但同样的权限不能直接交给智能体。平台需要支持权限升级和受控授权，否则智能体无法完成复杂任务。

7. 自我改进

人类会从经验中学习。刚开始发布或值班时，工程师通常较慢，需要他人带教，之后逐渐提升。Cloudflare 认为，智能体也需要从经验中学习和改进的机制。

为什么传统 CI/CD 不够

Cloudflare 用自动驾驶类比智能体开发：自动驾驶汽车并不是简单模仿人类开车，而是配备了激光雷达、摄像头、计算能力和远程接管系统等专门技术。

同样，如果要让智能体“自动驾驶”软件开发流程，也不能把它们放进只为人类设计的工具链中。

一个关键问题是：为什么团队还不敢让智能体自动批准并合并自己的 Pull Request 到生产服务？

原因通常包括测试覆盖不足、上下文缺失、权限风险、生产影响难以预测、主观体验难以评估等。越关键的系统，这个问题清单往往越长。

许多必要工作并不适合写成 GitHub Actions YAML 中的线性步骤，也远远超出传统自动化测试范围。即便是一个小的仪表盘修改，也可能涉及角色、专业分工、组织结构和主观判断。

Workflow：比 CI/CD 更通用的编排方式

Cloudflare 认为，要让智能体驱动整个过程，需要更强的动态编排能力。其设想是使用 Workflow 来组织这些步骤。

这样的 Workflow 不只是执行构建和测试，还可以：

• 启动容器
• 派生智能体
• 启动浏览器环境
• 设置功能开关
• 为测试用户启用特定功能
• 调查日志和 traces
• 在变更逐步发布时观察生产指标
• 执行安全发布所需的其他任务

Cloudflare Workflows 支持串联多个步骤、自动重试失败任务，并在数分钟、数小时甚至数周内持久化状态。它们可以表达复杂、动态的业务流程，也可以派生其他智能体或 Workflow。

Cloudflare 的核心观点是：CI/CD pipeline 本质上可以被视为一种 Workflow，但 Workflow 可以承担远超传统 CI/CD 的职责。

结论

Cloudflare 提出的 ADLC 并不是简单替换开发工具，而是试图重新定义智能体参与软件生产的方式。

在 AI 让代码实现速度大幅提升后，软件工程的瓶颈正在转向验证、部署、观测、权限、安全和维护。Cloudflare 认为，只有将这些环节也设计成适合智能体调用、扩展和学习的系统，软件工厂才可能安全地服务真实生产环境。