AIBrowser RunCloudflare WorkersMCPWorkflows产品新闻开发人员平台智能体

Cloudflare 现已推出 Agent Development Lifecycle（智能体开发生命周期）

Brendan Irvine-Broque

阅读时间：8 分钟

本文另有 English、Deutsch、Español、Français、Italiano、日本語、한국어和繁體中文.

过去几十年里，工程经理一直致力于解决一个问题：如何让许多程序员在同一共享代码库中协同工作。这项工作最早追溯到“系统开发生命周期” (RAND, 1975)——今天通常称为“软件开发生命周期” （SDLC），其中定义了以下阶段：

  • 计划
  • 设计
  • 实现
  • 测试
  • 部署
  • 维护
  • 停用

AI 将之前最慢且成本最高的环节—实现——变得最快且最便宜。这进一步影响了后续环节：负责 SDLC 中其他所有步骤的人员不堪重负。例如，开源维护者受到成千上万的拉取请求和问题轰炸，生产工程师需要竭力避免生产环境在软件交付速度提升多个数量级的情况下崩溃。

我们都在努力让我们的系统、客户以及自己脱离混乱、低质量的困境。

image1.png

矛盾的是，解决办法在于赋予智能体更大的能力。这样才合情合理！您绝不会让团队某位工程师编写代码，却期待别人负责验证、合并、部署、在生产环境中值守，并对传入的缺陷进行分类处理。但目前，大多数公司在使用智能体时都是这么做的。模型的性能已显著提升，且智能体能够在更长的时间跨度内运行，从而承担更大规模的任务。但它们尚未在整个软件开发生命周期中均衡使用。

Cloudflare 将智能体视为我们的客户。它们可以购买域名，创建临时账户并使用完整的 Cloudflare API。我们知道，智能体需要 API 和工具来代表客户管理完整的软件开发生命周期，而不仅仅是开始阶段。

因此，今天我们推出一套新工具，让智能体不仅能生成代码，还能在软件开发生命周期中承担更多工作。我们将分享我们的成果、以及在试图为自己解决这个问题时获得的经验：

不过，这里还有更重要的事。对于 SDLC 而言，即使拥有最佳自动化，它的前提/假设也无法随着智能体所能编写代码的规模以及软件团队为保持竞争所必须达到的推进速度而扩展。我们认为是时候用 ADLC —— 智能体开发生命周期——来取代 SDLC 了。

SDLC 是为软件团队准备的。ADLC 适用于软件工厂。

现在，所有人都在谈论构建“软件工厂”——这是一种由智能体驱动的系统，它们接收输入，并能够自主地构建、改进、部署以及管理软件。它们会接收输入，无论是生产错误、客户提交的错误报告还是关于新功能的想法，然后将其完全委派给一个智能体。

即使使用了智能体，大多数软件项目依然受到人类参与步骤的约束。人类对智能体发出提示，告诉它们继续推进，指示智能体将来自代码审查的反馈应用到代码中；持续照顾多个智能体并下达指令。在大多数软件团队中，人类仍然管理 SDLC 模型的每个步骤——唯一的变化是，他们在每个步骤中将任务委派给一个智能体。

因此，软件工厂背后的想法是：如果我们重新想象这种方法，并为构建软件的整个过程打造一座“工厂”，结果会如何？我们该如何把更多的人类时间投入到那些真正需要人类灵感、品味与判断的事情上呢？这样我们就会有更多时间投入到设计、客户交流以及更大胆的憧憬之中。

软件工厂必须管理 SDLC 中的相同步骤，但它对其所依赖的平台提出了更高要求。因为当您交出控制权并让智能体接管工作时，先前每一个依赖人类的手动步骤都必须调整为：

  • 程序化——“ClickOps” 对人类来说是不好的做法，而对智能体则完全不可行。每一个操作都需要可供智能体调用、调试和依赖的 API。
  • 可横向扩展—— 预览部署只是一个锦上添花的选项，由人类在构建过程中盯着屏幕，或在上线前手动接管预发服务器以捕捉问题。要让智能体驱动这个过程，每个智能体都必须拥有与生产环境一致的预览。
  • 可重现——如果出现一个在 iPhone 15 上模拟 4G 或在某个国家的 IP 下才能重现的错误会如何？普通的单元测试和集成测试工具这些情况下派不上用场。
  • 实时推送 ——依赖人去盯着合适的仪表板来判断系统是否正常工作，一直都不是好办法，对智能体而言则完全失效。您需要一个事件来触发智能体去执行任务。
  • 原子性 ——每一项变更都需要能够独立测试、独立发布，并且可观测，可在不影响无关行为的前提下回滚。
  • 授权 —— 您知道您也许不应该这么做，但今天您会把通过 SSH 连接生产环境的特权交给少数几位受信任的工程师，以防系统发生灾难性事故时及时处理。您当然不会允许智能体那样做；然而，如果它没有升级并获得更多权限的能力，它怎能完成工作呢？
  • 自我改进 ——人们会从经验中学习。在首周交付上线或首次值班轮换时，人们反应缓慢，需要跟随他人学习，但随后会变得更好、更快。智能体也需要从经验中学习的方法。

如果我们打算让软件工厂安全可靠地用于实际生产软件，我们就需要一些新的措施。软件工厂面临与其他自治系统（如自动驾驶汽车）相同的挑战——即从 80% 时间成功运行提升到超过 99% 的可用性。

要让智能体自主掌控 SDLC，我们不能给它们一辆为人类设计的车

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

对于一辆自动驾驶汽车来说，要达到人类驾驶能力的 80%，我们可能并不需要所有这些。自动驾驶在 10 年前就已经达到了接近人类 80% 的水平。但这并不是我们达到的标准——标准是要比人类驾驶员更好、更安全。这就是我们把钥匙交给机器时的期望，以便在以每小时 60 英里的速度沿 101 公路行驶时，可以安心小憩。这就是为什么自动驾驶汽车会配备专门为自主驾驶设计的技术——正是这些技术建立起信任，并处理那些无法预先设计应对的边界情况。

自动驾驶软件也是如此。问下自己——您为什么还没有让您的智能体自动批准并把它自己的 PR 合并到您的生产服务中？您构建的东西越重要，所列出的理由几乎肯定就越多。

当你开始解构不仅是这一过程中可能出现的所有灾难性错误，还包括为客户构建合适产品所需的内容时，会发现这是极其复杂的。这套流程无法简单地写入 GitHub Actions YAML 配置的线性步骤中，并远远超越常规自动化测试的范畴。即便是仪表板的微小改动，也可能涉及多个角色、专业领域和组织结构，而主观性的变更最难测试和授权委派。这些工作中的大部分，现在可能根本没有纳入您的 CI/CD 流水线。不过，如果您想让这些工作持续进行，同时赋予智能体完全控制以运行软件工厂，那么这些工作就必须被纳入流水线。

为了让智能体驱动整个流程，我们需要一个更好的方式来协调这些动态的步骤序列。我们认为这是一个能够生成容器、智能体和浏览器的 Workflow。一个能够设置功能开关并支持为测试用户启用、调查日志和追踪数据、观察生产指标随着变更逐步推出而变化，以及执行安全发布所需的所有其他操作的工作流。

CI/CD 管道只是一个工作流。但工作流可以实现远超 CI/CD 管道的功能。

Cloudflare Workflows 使您可以将多个步骤串联在一起，自动重试失败的任务，还可以在几分钟、几小时甚至几周内保持状态。它们被设计用来将复杂且动态的业务流程编码为逻辑清晰、易于理解的程序。这篇博客文章详细解析了为什么与 Artifacts 结合使用，Workflows 能从根本上简化 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 那样对工作流“深度认可”，您就会开始思考：还有哪些事务可以由工作流为我处理？我还能将哪些存在人类操作瓶颈的步骤委派给此 Workflow + Flue 智能体组合执行？

基于 Cloudflare 堆栈的完整 ADLC

鉴于 Workflows 能够编排复杂步骤，Artifacts 作为代码的存储层，纵观 SDLC 的各个阶段，Cloudflare 已具备智能体构建、发布和维护软件全过程所需的所有工具：

SDLC 阶段 Cloudflare
计划
设计
实现		 Vite, Rolldown 和 Oxc — 最快的智能体工具链
全栈本地开发 — 智能体在本地拥有与生产完全一致的运行时和环境
Local Explorer，Local Traces — 智能体调用与生产一致的 API 在本地进行调试
远程绑定 — 让智能体在本地运行代码，同时使用 Cloudflare 上运行的真实生产资源
预览 URL — 为每个拉取请求提供预览环境，供智能体验证和使用
测试 Browser Run — 云端运行的可编程无头浏览器
Vitest — 在 Workers 运行时中运行测试
部署 Flagship — 每项变更都有自己的功能开关
渐进式部署 — 将代码变更灰度发布到部分流量，逐步扩大范围
维护
停用		 Workers Logs — 让智能体实时跟踪日志或进行临时查询，以识别问题并自动修复
Agent Traces — 捕获每个智能体会话，用于持续改进
Cloudflare MCP Server - 由 Code Mode 和 Dynamic Workers 驱动
Analytics Engine — 基于 Clickhouse 构建的高基数分析，让智能体查询谁在使用什么资源

构建软件工厂的原语

当下，走在最前沿的人正在构建未来的软件工厂。最终，软件工厂将与智能体和 AI 一样，成为人们构建软件的常规方式。但对于大多数人和组织来说，我们还没有达到那个阶段。

我们希望改变这一现状。

为此，我们问自己：如何简化和提高可访问性，以便互联网上的每个人都能从这样的范式转变中受益？我们应该开放哪些基础层原语，使得从小型创业公司到全球最大的平台都能够使用？

就此而言，我们认为这些原语已经到位。连接这些原语、持续迭代我们的软件工厂并不断优化仍需时日，但现在，我们已准备就绪，欢迎您在 Cloudflare 上构建能够构建机器的机器。开始使用 @cloudflare/ci，构建一个智能体，看看您能够将 SDLC 中的多少实现自主运行。