Cloudflare提出Agent开发生命周期概念,并发布支撑该流程的Cloudflare原语,强调AI写代码速度已超过人工Review和部署能力。
过去几十年,工程经理们一直在想办法让许多程序员在共享代码库上协同工作。这项工作可以追溯到"系统开发生命周期"(RAND,1975)——也就是今天常说的"软件开发生命周期"(SDLC),它定义了以下阶段:
AI 已经将此前最慢、最昂贵的阶段——实现——变成了最快、最便宜的阶段。这反过来影响了下游环节:让负责 SDLC 其他所有步骤的人员不堪重负。从被成千上万 Pull Request 和 Issue 淹没的开源维护者,到眼睁睁看着软件交付量级暴涨而拼命保住生产环境不宕机的运维工程师,所有人都在超负荷运转。
我们都在试图保护我们的系统、客户,以及我们自己不被垃圾信息淹没。

答案是——反直觉地——赋予 Agent 更多能力。这很公平!你绝不会让团队里的一个工程师写完代码后,期望别人去验证、合并、部署、值守生产告警,还要处理后续 Bug 分流。但大多数公司现在对 Agent 正是这样做的。模型已经显著提升,Agent 运行的 时间跨度越来越长,能够承担更大的任务。但 Agent 在 SDLC 中的使用并不均衡。
Cloudflare 将 Agent 视为我们的客户。它们可以购买域名、创建临时账户并使用整个 Cloudflare API。我们深知 Agent 需要 API 和工具来代表客户管理完整的 SDLC——而不是仅仅负责开头那一部分。
因此,今天我们推出一套新工具的起始部分,让 Agent 能够超越仅生成代码的范畴,承担更多 SDLC 环节。我们分享我们为自己解决这个问题时所构建和学习到的内容:
@cloudflare/ci —— 一种跨数百万仓库运行 CI/CD 的新方式,能够自我修复并启动 Agent 完成更复杂的任务,构建在 Cloudflare Workflows 之上。
OpenTelemetry traces 在本地开发环境——让 Agent 拥有与生产环境相同的可观测性,内置于 Wrangler 和 Cloudflare Vite 插件中。
发布:Cloudflare Agents 和 Agent Traces —— 观察、维护和改进 Agent 的新家,以来自 Agent 的 OpenTelemetry traces 为核心。
Cloudflare 如何使用 AI 强制执行工程标准——我们自己在所有产品和系统仓库及规范中执行最佳实践的经验。
我们如何构建了一个软件工厂,将 Astro 的 GitHub Issue 数量降至零——我们自己的经验,构建系统来自动分流、重现、验证和修复一个大型且不断增长的开源项目的问题。
不过这背后还有更大的东西。当我们审视 SDLC 时,即使有最好的自动化,它的假设也无法适应 Agent 能写的代码量和软件团队必须移动的速度。我们认为是时候用 ADLC——Agent 开发生命周期——来取代 SDLC 了。
SDLC 面向的是软件团队。ADLC 面向的是软件工厂。
现在所有人都在讨论构建"软件工厂"——一种接收输入并自主构建、改进、部署和管理软件的 Agent 驱动系统。接收一个输入,无论是生产错误、客户提交的 Bug 报告,还是新功能的创意,然后完全委托给一个 Agent 处理。
即使有 Agent,大多数软件项目仍然受制于人工介入步骤。人们在提示 Agent、告诉它们继续运行、指示 Agent 应用代码审查中的反馈、不断看守多个 Agent 并给它们指令。在大多数软件团队中,人类仍然管理着 SDLC 模型中的每个步骤——唯一的变化是他们在每个步骤内部将任务委托给 Agent。
所以软件工厂背后的梦想是:如果你重新思考这种方法,并为整个软件构建过程建造一个工厂会怎样?我们如何将更多人类时间转移到真正需要人类灵感、品味和判断的事情上?那将为我们留出更多时间来设计、与客户交流、以及做梦。
软件工厂必须管理 SDLC 中的相同步骤,但它对构建它的平台要求高得多。因为当你交出钥匙让 Agent 主导时,之前依赖人工的每个手动步骤都必须被改造为:
可编程的——"ClickOps" 对人类来说是糟糕的实践,但对 Agent 来说完全不可行。每个操作都需要有 Agent 可以调用、调试和依赖的 API。
水平可扩展的——当人类在构建时盯着屏幕,或手动接管预发布服务器来在发布前捕获问题时,预发布部署是锦上添花。对于 Agent 主导,每个 Agent 必须拥有自己的、与生产环境相匹配的预发布环境。
可重现的——如果有一个 Bug 只在模拟 iPhone 15 上的 4G 网络时才能重现怎么办?或者来自某个国家的 IP?典型的单元测试和集成测试工具在这里帮不上忙。
实时的、推送式的——依赖人类去看正确的仪表板来了解事情是否正常运作一直是个糟糕的方式,但对 Agent 来说这完全失效。你需要一个事件来触发 Agent 开始工作。
原子化的——每个变更都需要能够独立测试、发布、可观测,以及在不影响无关行为的情况下可回滚。
有权限的——你知道你可能不应该,但今天你还是会给几个受信任的工程师 SSH 到生产环境的密钥,以防事情真的失控。你绝不会让一个 Agent 那样做——但如果没有能力升级并获得更多权限,它怎么能完成工作?
自我改进的——人们从经验中学习。入职第一周或第一次值班,人类很慢、需要跟着别人学习,但之后会变得更好更快。Agent 同样需要从经验中学习的方式。
如果我们要让软件工厂能够安全地用于真正的生产软件,我们需要新的东西。软件工厂面临与其他自主系统(如自动驾驶汽车)相同的挑战——从成功运行 80% 的时间,到超过 99% 的若干个九的挑战。
要赋予 Agent 主导 SDLC 的钥匙,你不能给它们一辆为人设计的汽车
自动驾驶汽车配备了普通汽车所没有的传感器和技术。激光雷达传感器、摄像头、运行推理的强大计算力,以及与中央命令系统的连接——必要时可以远程接管。
要让自动驾驶汽车达到人类驾驶水平的 80%,我们可能不需要所有这些。自动驾驶在十年前就达到了人类水平的约 80%。但这不是要达到的基准线——基准是要比人类驾驶员更好、更安全。这才是我们交出钥匙给机器时的期望——在 101 号高速公路上以 60 英里时速行驶时,能够安心打个盹。这也是为什么自动驾驶汽车拥有专为自动驾驶打造的技术——这才是建立信任和处理无法提前设计的边缘情况的方式。
自动驾驶软件同样如此。问问你自己——为什么你还没有让 Agent 自动批准并合并自己发往生产服务的 PR?你所构建内容的风险越高,你的理由清单几乎肯定越长。
当你开始深入剖析这个过程中可能发生的灾难性错误,以及为客户构建正确事物所需的一切,你会发现它非常复杂。它不适合塞进 GitHub Actions YAML 文件的一系列线性步骤中,也远远超出了运行传统自动化测试的范围。即使对仪表板的微小更改也可能跨越角色、专业领域和组织结构,而主观性更改是最难测试和委托的。大多数这些事情今天可能根本不在你的 CI/CD 流水线中。但如果你想在给予运行软件工厂的 Agent 完全控制权的同时仍让它们发生,它们就需要在。
要让 Agent 主导整个过程,我们需要一种更好的方式来编排这些动态的步骤序列。我们认为这就是 Workflow,具备启动容器、Agent 和浏览器的能力。一个能够设置功能开关并为测试用户启用它、调查日志和 traces、观察生产指标(随着变更逐步推出)、以及完成安全发布所需的其他一切。
CI/CD 流水线只是一个 Workflow。但一个 Workflow 可以远不止是 CI/CD 流水线。
Cloudflare Workflows 让你将多个步骤串联起来,自动重试失败的任务,并持久化状态数分钟、数小时,甚至数周。它们旨在将复杂和动态的业务流程编码为逻辑清晰、易于理解的程序。这篇博文分解了为什么 Workflows 与 Artifacts 相结合,使定义和触发 CI/CD 流水线从根本上变得更简单。例如:
import { CIWorkflow } from `@cloudflare/ci`
const deps: CiRunnerResult = await ci.runner({
name: 'install',
command: 'bun install --frozen-lockfile',
cache: { inputs: ['package.json', 'bun.lock'] },
});
await Promise.all([
deps.runner({ name: 'lint', command: 'bun run lint' }),
deps.runner({ name: 'test', command: 'bun run test' }),
deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
deps.runner({ name: 'build', command: 'bun run build' }),
]);
await deps.runner({
name: 'deploy',
command: 'bun wrangler deploy',
cloudflareCredentials: {
accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
},
});
不过 Workflows 超越了线性步骤系列。它们可以动态定义,也可以启动 Agent 或其他 Workflow。这个例子展示了一个从过去一天收集新数据的 Workflow。Workflow 完全控制何时以及如何给 Agent 发送提示,并可以在步骤之间传递上下文:
import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';
type Params = { date: string };
export class NightlyReview extends WorkflowEntrypoint {
async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
const findings = await step.do('collect findings', () => collectFindings(event.payload.date));
const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });
const receipt = await step.do('dispatch review', () =>
agent.dispatch(`Review these findings:\n${findings}`),
);
const review = await step.do('read review', async () => {
const reply = await agent.read(receipt);
return { text: reply.text, data: reply.data };
});
// ...
}
}
一旦你看到这种模式,并且像 Cloudflare 一样"上了 Workflow 的瘾",你就会开始问:还有什么我可以交给 Workflow 处理?还有哪些人工瓶颈步骤我可以委托给这种 Workflow + Flue Agent 的组合?
完整的 ADLC,基于 Cloudflare 技术栈
凭借能够编排复杂步骤的 Workflows,以及作为代码存储层的 Artifacts,当你审视 SDLC 各个阶段时,Agent 拥有构建、发布和维护软件完整流程所需的一切都在 Cloudflare 上:
Vite、Rolldown 和 Oxc——为你的 Agent 提供最快的工具链
一切皆可本地开发——Agent 在本地看到的内容,与生产环境中运行的运行时和环境完全相同
Local Explorer、Local Traces——你的 Agent 拥有相同的 API 来在本地和生产环境调试
Remote bindings——让 Agent 在本地运行代码,同时使用 Cloudflare 上运行的真实生产资源
Preview URLs——为每个 Pull Request 提供预览,让 Agent 验证和使用
Browser Run——云端可编程的无头浏览器
Vitest——在 Workers 运行时中运行测试
Flagship——每个变更都有自己的功能开关
Gradual Deployments——将代码变更逐步推向一定比例的流量,随时间推移增加
Workers Logs——让 Agent 尾随实时日志或 adhoc 查询以识别需要自动修复的问题
Agent Traces——捕获每个 Agent 会话并用它来改进
Cloudflare MCP Server——由 Code Mode 和 Dynamic Workers 驱动
Analytics Engine——基于 Clickhouse 构建的高基数分析,让 Agent 查询谁在使用什么
构建软件工厂的底层原语
现在,处于前沿的人们正在构建未来的软件工厂。最终,软件工厂将变得像 Agent 和 AI 一样,成为人们构建软件的常规方式。但对大多数人和大多数组织来说,我们还没有到那一步。
我们想要改变这一点。
为此,我们问自己的问题是:我们如何才能让事情变得简单和人人可及,让互联网上的每个人都能从这样的范式转变中受益?我们可以向所有人开放的底层原语是什么,从最小的初创公司到世界上最大的平台?
在这种情况下,我们认为原语已经在这里了。将它们连接起来还有很多工作要做,继续构建我们自己的软件工厂并从中学习,但此时此刻,我们已经准备好让你在 Cloudflare 上构建制造机器的机器。从 @cloudflare/ci 开始,构建一个 Agent,看看你的 SDLC 有多少可以实现自主化。