Cloudflare 推出代理开发生命周期（ADLC）：从 SDLC 到软件工厂的范式转变

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

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

AI 让原本最慢、最昂贵的一步——实现——变成了最快、最便宜的一步。这反过来又对下游产生了影响：负责 SDLC 其他各个环节的人不堪重负。从被成千上万个拉取请求和问题淹没的开源维护者，到努力不让生产环境在软件交付速度提升若干个数量级时垮掉的生产工程师，无一例外。

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

答案——说来矛盾——是让智能体做得更多。这才公平！你绝不会让团队里的一位工程师写完代码，却指望别人来验证、合并、部署，在生产环境里值班待命，还要分流收到的缺陷。但这正是目前大多数公司对智能体的做法。模型已经显著进步，智能体运行的时间跨度更长，能够承担大得多的任务。但它们在整个 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 是为软件工厂准备的。

眼下，所有人都在谈论如何构建“软件工厂”——由智能体驱动的系统，接收输入后自主构建、改进、部署和管理软件。无论输入是一个生产错误、客户的一份缺陷报告，还是一个新功能的想法，都完全委托给智能体处理。

即便有了智能体，大多数软件项目仍受限于需要人参与的环节：人给智能体下提示，叫它们继续干，指示智能体采纳代码评审的反馈，不停地看护许多智能体并给它们下指令。在大多数软件团队中，人仍然在管理 SDLC 模型中的每一步，唯一的变化是把每一步里的任务委托给了智能体。

所以软件工厂背后的梦想是：如果重新设想这种做法，为构建软件的整个过程建一座工厂会怎样？我们如何把更多人的时间转向那些真正需要人的灵感、品味和判断的事情？这会让我们有更多时间去设计、与客户交谈、做更大的梦。

软件工厂必须管理 SDLC 中的同样步骤，但它对所基于的平台提出了高得多的要求。因为当你交出钥匙、让智能体来驾驶时，以前依赖人的每一个手工步骤都必须被改造成：

• 可编程——“ClickOps”（点点点式运维）对人来说就是不良实践，对智能体更是行不通。每一项操作都需要智能体能够调用、调试和依赖的 API。
• 可水平扩展——当人在构建时盯着屏幕，或手动接管预发布服务器以便在上线前抓出问题时，预览部署只是锦上添花。要让智能体来驾驶，每个智能体都必须有一个与生产环境一致的专属预览。
• 可复现——如果有一个缺陷只能在 iPhone 15 上模拟 4G 网络时复现，或只能从某个国家的 IP 复现，会怎样？典型的单元测试和集成测试工具在这里帮不上忙。
• 实时、推送式——依靠人去看正确的仪表盘，来判断一切是否正常，向来就是个糟糕的办法，到了智能体这里更是彻底失效。你需要一个事件来触发智能体去干活。
• 原子化——每一项变更都需要能独立测试、发布、观测和回滚，且不影响无关的行为。
• 有权限边界——你知道大概不该这么做，但如今你还是会给少数受信任的工程师 SSH 进入生产环境的钥匙，以防真的出大乱子。你绝不可能让智能体这么做，但如果它没有能力升级权限、获取更多权限，又怎么完成工作？
• 自我改进——人从经验中学习。第一周发布，或者第一次轮值待命时，人很慢，需要跟着别人观摩，但之后会越来越好、越来越快。智能体同样需要从经验中学习的办法。

如果要让软件工厂能安全地用于真正的生产软件，我们需要一些新东西。软件工厂面临的挑战，与自动驾驶汽车等其他自主系统相同：从 80% 的时间成功运行，提升到 99% 之后的若干个“9”。

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

自动驾驶汽车装载着普通汽车没有的传感器和技术：激光雷达、摄像头、运行推理的强大算力，以及连接到中央指挥系统的通道，必要时可由其远程接管。

要让自动驾驶汽车达到人类驾驶水平的 80%，我们大概并不需要这一切。自动驾驶 10 年前就达到了人类约 80% 的水平。但那不是要跨越的门槛，门槛是要比人类司机好得多、安全得多。当我们把钥匙交给机器、好让自己安心地在 101 号公路上以每小时 60 英里的速度打个盹时，期待的正是这一点。这也是自动驾驶汽车配备专为自动驾驶打造的技术的原因：它建立信任，并应对无法预先设计的边缘情况。

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

当你开始拆解这个过程中不仅所有可能发生灾难性错误的地方，还有为客户做出正确东西所必需的一切时，会发现它复杂得惊人。它无法放进 GitHub Actions YAML 文件里那样的线性步骤序列，也远远超出了运行传统自动化测试的范畴。哪怕是对仪表盘的一个小改动，也可能横跨多个角色、专业和组织结构，而主观性的变更是最难测试、最难委托的。这些事情大多数大概根本不在你今天的 CI/CD 流水线里。但如果你想让它们继续发生，同时把完全的控制权交给运行软件工厂的智能体，它们就必须进入流水线。

要让智能体驱动整个过程，我们需要更好的方式来编排这些动态的步骤序列。我们认为答案是 Workflow，它能够派生容器、智能体和浏览器。这样的 Workflow 可以设置功能开关（feature flag）并为测试用户启用，调查日志和追踪，在变更逐步推出时观察生产指标，并完成安全发布所需的其他一切。

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 不止于一连串线性步骤。它们可以动态定义，也可以派生智能体或其他 Workflow。这个示例展示了一个审查过去一天新数据的 Workflow。该 Workflow 完全掌控何时、如何向智能体发出提示，并能在各步骤之间传递上下文：

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-pilled）之后，你就会开始问：还有什么可以交给 Workflow 替我处理？还有哪些卡在人身上的步骤，可以委托给 Workflow 加 Flue 智能体这个组合？

完整的 ADLC，尽在 Cloudflare 技术栈

有了能够编排复杂步骤的 Workflows，以及作为代码存储层的 Artifacts，对照 SDLC 的各个阶段来看，智能体拥有构建、发布和维护软件的整个过程所需的一切，都在 Cloudflare 上：

构建你的软件工厂的原语

眼下，走在最前沿的人正在构建未来的软件工厂。最终，软件工厂会像智能体和 AI 一样，成为人们构建软件的常态。但对大多数人和大多数组织来说，我们还没到那一步。

我们想改变这一点。

为此，我们问自己的问题是：如何让事情变得简单、易于上手，让互联网上的每个人都能从这样的范式转变中受益？我们可以向所有人开放的底层原语是什么，从最小的初创公司到全球最大的平台？

就此而言，我们认为这些原语已经就位。要把它们连接起来，要继续构建我们自己的软件工厂并从中学习，还有更多工作要做，但此时此刻，我们已准备好让你在 Cloudflare 上构建属于你的“制造机器的机器”。从 @cloudflare/ci 开始，构建一个智能体，看看你能让多少 SDLC 环节实现自主。