# Cloudflare 推出 Agent Development Lifecycle，让智能体接管更多软件开发生命周期

- 来源：Cloudflare Blog
- 作者：Brendan Irvine-Broque
- 发布时间：2026-08-04 21:00
- AIHOT 分数：61
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmseq167r12lxro2erzimnhk2
- 原文链接：https://blog.cloudflare.com/agent-development-lifecycle

## 精选理由

本公告把软件生命周期重新设计为代理可完全驱动的工厂，用 Workflows 编排 CI/CD 到可观测性，为评估平台自主开发能力提供了新基准。

## AI 摘要

Cloudflare 宣布推出 Agent Development Lifecycle（ADLC），以取代传统 SDLC，让 AI 智能体从仅生成代码扩展到承担更多开发流程。

## 正文

工程经理们过去几十年一直在想办法让众多程序员能在同一个共享代码库上协同工作。这项工作最早可以追溯到“系统开发生命周期”（RAND，1975年）——如今通常被称为“软件开发生命周期”（SDLC），它定义了以下几个阶段：

AI 让原本最慢、最昂贵的环节——实现——变成了最快、最便宜的环节。这反过来又对下游产生了影响：让负责 SDLC 中其他所有环节的人不堪重负。从被成千上万个拉取请求和 issue 淹没的开源维护者，到在软件交付速度提升数个数量级的情况下拼命保住生产环境不崩溃的生产工程师，无一幸免。

我们都在努力保护我们的系统、我们的客户和我们自己，免受“垃圾内容”（slop）的侵害。

答案——矛盾的是——是让智能体做更多的事。这才公平！你绝不会让你团队里的工程师写代码，却指望别人去验证、合并、部署，在生产环境里盯着告警，并分类处理新来的 bug。但这就是现在大多数公司在智能体上的做法。模型已经取得了显著进步，智能体运行的时间跨度更长，能够承担大得多的任务。但它们尚未被均匀地应用到 SDLC 的各个环节。

Cloudflare 把智能体当作我们的客户。它们可以购买域名、创建临时账户并使用整个 Cloudflare API。我们知道，智能体需要 API 和工具才能代表我们的客户管理完整的 SDLC——而不仅仅是它的起点。

因此，今天我们推出了一组新工具的开端，让智能体能够超越单纯的代码生成，承担更多 SDLC 的工作。我们正在分享我们为解决自身问题而构建和学到的东西：

@cloudflare/ci —— 一种在数百万个代码仓库中运行 CI/CD 的新方式，它可以自愈并派生出智能体来执行更复杂的任务，构建在 Cloudflare Workflows 之上。

本地开发中的 OpenTelemetry 追踪 —— 为智能体提供与生产环境相同的可观测性，内置于 Wrangler 和 Cloudflare Vite 插件中。

隆重推出：Cloudflare Agents 与 Agent Traces —— 一个以智能体 OpenTelemetry 追踪为核心，用于观测、维护和改进智能体的全新平台。

Cloudflare 如何利用 AI 强制执行工程标准 —— 我们自身在所有产品和系统的代码仓库及规范中强制执行最佳实践的经验。

我们如何打造一个软件工厂，将 Astro 的 GitHub issue 数量降至零 —— 我们自身为大型且不断增长的开源项目构建自动分类、复现、验证和修复问题系统的经验。

不过，这里还有更宏大的意义。当我们审视 SDLC（软件开发生命周期）时，即使拥有最好的自动化，其假设也无法适应智能体所能编写的代码量，以及软件团队为保持竞争力所必须达到的速度。我们认为，是时候用 ADLC —— 智能体开发生命周期（Agent Development Lifecycle）来取代 SDLC 了。

SDLC 是为软件团队而设。ADLC 是为软件工厂而设。

眼下，所有人都在谈论构建“软件工厂”—— 即由智能体驱动的系统，它们接收输入并自主构建、改进、部署和管理软件。无论是生产环境错误、客户提交的 bug 报告，还是新功能的想法，都可以作为输入，完全委托给一个智能体处理。

即使有了智能体，大多数软件项目仍受制于“人在环内”的步骤。人类向智能体发送提示词，告诉它们继续推进，指示智能体应用代码审查中的反馈，不断照看众多智能体并给予指令。在大多数软件团队中，人类仍然管理着 SDLC 模型中的每一步 —— 唯一的变化只是他们将每个步骤中的任务委托给了智能体。

因此，软件工厂背后的梦想是：如果你重新构想这种方法，为整个软件开发流程建造一座工厂，会怎样？我们如何才能将更多人类时间转移到那些真正需要人类灵感、品味和判断力的事情上？这将为我们留出更多时间去设计、与客户交流，并怀抱更远大的梦想。

软件工厂必须管理软件开发生命周期（SDLC）中的相同步骤，但它对自身所依托的平台提出了高得多的要求。因为当你交出钥匙、让智能体来驾驶时，每一个此前依赖人工的步骤都必须改造为：

可编程化——对人工而言，“点击操作”（ClickOps）本就是不良实践，对智能体来说更是行不通。每一个操作都必须有智能体能够调用、调试并依赖的 API。

可水平扩展——当人类在构建时盯着屏幕、或手动接管预发布服务器以在生产环境前发现问题时，预览部署只是锦上添花。要让智能体来驱动，每个智能体都必须拥有一个与生产环境一致的专属预览环境。

可复现——如果某个 bug 只有在 iPhone 15 上模拟 4G 网络时才能复现，或者只有从某个国家的 IP 访问时才能复现，该怎么办？常规的单元测试和集成测试工具在这里帮不上忙。

实时、基于推送——依赖人类盯着正确的仪表盘来判断系统是否正常，从来都不是好办法，而到了智能体时代这更是彻底行不通。你需要一个事件来触发智能体去执行工作。

原子性——每一项变更都必须可独立测试、可独立发布、可独立观测、可独立回滚，且不影响无关行为。

权限受控——你知道大概不该这么做，但如今你确实会给少数几位可信工程师 SSH 登录生产环境的权限，以备真的出大乱子时应急。你绝不可能让智能体也这么做——但如果它没有升级权限、获取更多权限的能力，它又怎么能完成自己的工作呢？

自我改进——人类从经验中学习。无论是第一周上线还是第一次值班轮换，人类一开始都很慢，需要跟着别人见习，但之后会变得更好、更快。智能体同样需要从经验中学习的方式。

如果我们想让软件工厂能够安全地用于真正的生产软件，就需要一些全新的东西。软件工厂面临着与其他自主系统（如自动驾驶汽车）相同的挑战——即从 80% 的时间成功运行，跨越到 99% 以上的若干个九（nines）的可靠性。

要把驾驶 SDLC 的钥匙交给智能体，你就不能给它们一辆为人类设计的车。

自动驾驶汽车搭载了普通汽车所没有的传感器和技术。激光雷达传感器、摄像头、用于运行推理的强大算力，以及与中央指挥系统的连接——后者可在必要时远程接管车辆。

要让自动驾驶汽车达到人类驾驶水平的80%，我们可能并不需要所有这些配置。自动驾驶在10年前就已经达到了人类驾驶水平的80%左右。但这不是我们要跨越的门槛——门槛是要比人类驾驶员表现更好、更安全。当我们把方向盘交给机器时，这正是我们的期望，这样我们才能在101号公路上以60英里时速行驶时安心打个盹。正因如此，自动驾驶汽车才配备了专为自动驾驶而设计的技术——正是这些技术建立了信任，并处理那些无法预先设计的边缘情况。

自动驾驶软件也是如此。问问自己——为什么你还没有让智能体自动批准并合并它自己提交到生产服务的PR？你构建的东西风险越高，你的理由清单几乎肯定就越长。

当你开始梳理不仅是在这个过程中可能灾难性出错的所有事情，还包括为客户构建正确产品所必需的一切时，你会发现这极其复杂。它无法被塞进GitHub Actions YAML文件里一组线性的步骤中，也远远超出了运行传统自动化测试的范畴。即使是对仪表盘的一个小改动，也可能跨越多个角色、专业领域和组织架构，而主观性的改动恰恰是最难测试、最难委派的。这些事项中的大多数，如今可能根本不在你的CI/CD流水线里。但如果你希望在把完全控制权交给运行软件工厂的智能体的同时，这些事项仍然能够发生，那么它们就必须被纳入其中。

要让智能体驱动整个流程，我们需要一种更好的方式来编排这些动态的步骤序列。我们认为这就是工作流（Workflow），它具备生成容器、智能体和浏览器的能力。一个工作流可以设置功能开关并为测试用户启用它们，调查日志和链路追踪，在变更逐步上线时观察生产环境指标，并完成安全交付所需的一切其他工作。

CI/CD 流水线本质上就是一个 Workflow。但 Workflow 的能力远不止于 CI/CD 流水线。

Cloudflare Workflows 让你可以把多个步骤串联起来，自动重试失败的任务，并将状态持久化保存几分钟、几小时甚至几周。它们的设计目标是用一种逻辑清晰、易于理解的程序来编码复杂且动态的业务流程。这篇博客文章将深入解析为什么 Workflows 与 Artifacts 配合使用，能让 CI/CD 流水线的定义和触发从根本上变得更简单。例如：

不过，Workflows 并不局限于一系列线性步骤。它们可以动态定义，还可以派生智能体或其他 Workflows。下面的示例展示了一个 Workflow，它负责审查过去一天产生的新数据。该 Workflow 对智能体何时被提示以及如何被提示拥有完全的控制权，并且可以在各个步骤之间传递上下文：

一旦你看到了这种模式，并且像 Cloudflare 一样“被 Workflow 深深吸引”，你就会开始思考：我还能让 Workflow 帮我处理哪些事情？还有哪些受制于人工瓶颈的步骤，可以交给 Workflow + Flue 智能体的组合来代劳？

完整的 ADLC，全部构建在 Cloudflare 技术栈之上

既然 Workflows 能够编排复杂的步骤，而 Artifacts 作为代码的存储层，那么当你审视 SDLC 的各个阶段时，会发现智能体要全权负责构建、交付和维护软件这一整个流程所需的全部要素，都已经在 Cloudflare 上就绪：

构建你的软件工厂所需的基础组件

目前，处于技术最前沿的人们正在构建未来的软件工厂。最终，软件工厂会像智能体和 AI 一样，成为人们构建软件的常规方式。但对大多数人和大多数组织来说，我们还没有走到那一步。

我们想要改变这一现状。

为了实现这一目标，我们向自己提出的问题是：我们怎样才能把事情变得简单易用，让互联网上的每个人都能从这样的范式转变中受益？以及，我们可以向所有人开放哪些底层基础组件——从最小的初创公司到全球最大的平台？

在这种情况下，我们认为基础构件已经就绪。要将它们连接起来、持续打造我们自己的软件工厂并从中学习，还有很多工作要做，但就在当下、今天，我们已经准备好让你在 Cloudflare 上构建那台“制造机器的机器”。从 @cloudflare/ci 开始，构建一个智能体，看看你能让软件开发生命周期（SDLC）中的多少环节实现自动化。