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

工程经理们过去几十年一直在想办法让众多程序员能在同一个共享代码库上协同工作。这项工作最早可以追溯到“系统开发生命周期”（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 —— 智能体开发生命周期 —— 来取代 SDLC 了。

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

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

即使有了智能体，大多数软件项目仍然受到人在环路（human-in-the-loop）步骤的制约。人类需要提示智能体、告诉它们继续前进、指示它们应用代码审查中的反馈，并不断照看众多智能体并给予指示。在大多数软件团队中，人类仍然管理着 SDLC 模型中的每一步 —— 唯一的变化是他们将每个步骤中的任务委托给了智能体。

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

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

• 可编程化——对人工而言，“点击操作”（ClickOps）已是糟糕的实践，对智能体来说更是根本行不通。每一个操作都必须提供智能体可以调用、调试并依赖的 API。
• 可水平扩展——当人类在构建时盯着屏幕，或手动接管预发布服务器以在生产环境前发现问题时，预览部署是锦上添花的功能。而要让智能体来驱动，每个智能体都必须拥有一个与生产环境一致的专属预览环境。
• 可复现——如果某个 bug 只有在 iPhone 15 上模拟 4G 网络时才能复现，或者只有从某个国家的 IP 访问时才能复现，该怎么办？典型的单元测试和集成测试工具在这里帮不上忙。
• 实时、基于推送——依赖人类去查看正确的仪表盘，从来都不是判断系统是否正常运转的好办法，但在智能体场景下这完全行不通。你需要一个事件来触发智能体去执行工作。
• 原子性——每一项变更都必须能够独立测试、独立发布、独立观测、独立回滚，且不影响无关行为。
• 权限受控——你知道大概不该这么做，但如今你确实会给少数几位受信任的工程师 SSH 进入生产环境的权限，以备系统真的出大乱子时应急。你绝不可能让智能体也拥有这种权限——但如果它没有升级权限、获取更多权限的能力，又怎么能完成自己的工作呢？
• 自我改进——人类会从经验中学习。无论是第一周上线还是第一次值班轮换，人类起初都很慢，需要跟着别人学习，但之后会变得更好、更快。智能体同样需要从经验中学习的方式。

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

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

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

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

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

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

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

CI/CD 流水线本质上就是一个工作流。但工作流的能力远不止于 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 并不局限于一系列线性步骤。它们可以动态定义，并且可以派生智能体或其他工作流。下面的示例展示了一个工作流，它负责审查过去一天的新数据。该工作流完全控制智能体何时以及如何被提示，并且可以在步骤之间传递上下文：

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 一样“被工作流洗脑”，你就会开始思考：我还能让工作流为我处理哪些事情？还有哪些受人工瓶颈限制的步骤，可以委托给这种“工作流 + Flue 智能体”的组合？

完整的 ADLC，基于 Cloudflare 技术栈

借助 Workflows 编排复杂步骤的能力，以及 Artifacts 作为代码存储层，当你审视 SDLC 的各个阶段时，智能体在 Cloudflare 上拥有构建、交付和维护软件全流程所需的一切：

构建你的软件工厂所需的原语

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

我们想改变这一点。

为此，我们向自己提出的问题是：我们怎样才能把事情变得简单易用，让互联网上的每个人都能从这样的范式转变中受益？又有哪些底层原语，是我们能够向所有人开放的——从最小的初创公司到全球最大的平台？

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