返回 文章 apply CMS 文章

Cloudflare 推出 Agents SDK 与 Flue 框架:构建生产级 AI 智能体的三层架构

Cloudflare 发布 Agents SDK 和 Flue 框架,为生产级 AI 智能体提供持久化执行、沙箱代码执行等关键能力。

CloudflareAgents SDKFlueAI 智能体
成长分 / 100 84 综合收获、行动、留存与影响

Cloudflare 推出 Agents SDK 与 Flue 框架:构建生产级 AI 智能体的三层架构
为什么值得读了解 Cloudflare 如何将 Project Think 的生产经验抽象为通用 SDK,解决智能体在生产中的分布式系统问题。

学习 Flue 框架的声明式智能体模型及其与 Cloudflare 生态的深度集成。

关键洞察
  1. 生产级智能体面临中断恢复、安全代码执行、持久化文件系统等分布式系统挑战,需要平台层支持。
  2. Cloudflare Agents SDK 提供 runFiber、stash、onFiberRecovered 等原语实现持久化执行,确保智能体在崩溃后无缝恢复。
  3. Flue 框架采用声明式模型,开发者只需定义智能体的上下文(模型、技能、沙箱、指令),无需编写编排循环。
转成行动

深入阅读

正文与原文对照

原文保真覆盖:全文原文字符:14130

2026 年是智能体工具投入生产的一年。控制模型与外部世界交互的软件——如 Codex、Claude Code、OpenCode、Pi 和 Project Think 等工具——已经成熟到团队将智能体部署为真正的、承载负载的基础设施,而不仅仅是原型。

但构建能在生产中存活的智能体是困难的。

我们在构建 Project Think 作为第一方智能体工具时亲身学到了这一点。在与客户合作在生产环境中运行智能体的过程中,我们发现了一组每个智能体在云端运行时都会面临的常见分布式系统问题。当智能体被中断时,如何自动且优雅地从中断处恢复,而不丢失上下文或浪费令牌?智能体如何安全地运行不受信任的代码?智能体如何使用它们训练过的工具?

工具本身无法独自解决这些问题。它们与状态、存储和计算紧密相关——这意味着它们依赖于智能体运行的平台。这就是为什么我们将从 Project Think 生产环境加固中获得的经验,作为基础层引入 Cloudflare Agents SDK。持久化执行、动态代码执行、持久化文件系统和动态工作流,现在可供任何基于 Agents SDK 构建的工具使用。

与此同时,工具之上出现了一个新层次。像 Flue 这样的框架用项目结构、约定、集成和开发者体验来包装工具,使构建智能体更加高效。

为了解决这些扩展挑战,一个用于构建生产级 AI 的新三层架构正在形成。以下是各层如何组合在一起,从面向用户的开发者体验向下到底层平台原语:

框架(Flue)——用于构建智能体的项目结构、约定、集成、CLI 和开发者体验。

工具(Pi, Project Think)——调用工具、读取结果、管理上下文并持续执行直到任务完成的智能体循环。

运行时/平台(Cloudflare Agents SDK)——上述所有层依赖的计算、状态和存储原语。

Agents SDK 是底层:它使持久化执行等原语可供任何工具和任何框架使用。Flue,我们来自 Astro 团队的新开源框架,是第一个基于它构建的框架。以下是具体方式。

Flue 本周发布了 1.0 Beta 版,基于 Pi 工具构建,该工具也是 OpenClaw 的基础。它作为智能体框架的不同之处在于其方法:你不是编写智能体要执行的脚本,而是描述它知道什么。定义智能体所需的上下文——其模型、技能、沙箱和指令——它就会自主解决你交给它的任何任务。无需编写编排循环。

这种声明式模型使得编写智能体变得简单:以下是一个分诊智能体,它拦截错误报告,在沙箱中重现,并在不到 25 行代码内诊断问题。

Flue 开发者体验

Flue 的强大之处在于智能体并非孤立存在。它们被构建为存在于用户已经工作的地方,并与你偏好的工具集成:

无处不在的智能体:将你的智能体放入 Slack、GitHub、Linear 或 Discord,使用预配置的通道自动处理事件验证和分发样板代码。

无头但UI就绪:代理不应存在于黑盒中。Flue 代理可以完全无头运行以处理后台任务,但 @flue/react 提供了原生前端钩子,可将代理的状态、工具执行和实时消息直接流式传输到你的前端应用程序中,而无需从头构建自定义实时管道。

生态就绪:Flue 使得通过 flue add channel slack 等命令添加和升级集成变得容易,生成一个 Markdown 蓝图,你自己的编码代理可以读取、修改并干净地集成到你的代码库中。

为生产而设计,而不仅仅是原型

将代理从本地终端迁移到生产生态系统会引入传统的分布式系统故障。主机崩溃、来自 LLM 提供商的 API 超时以及意外重启可能会抹去正在运行的代理轮次的短期记忆。

Flue 通过持久流解决了这个问题。执行历史中的每个事件都被添加到一个仅追加的日志中。通过将每个提示、工具响应和模型选择作为不可更改的账本处理,代理的状态永远不会是易失的。如果某个进程崩溃,另一个进程只需获取日志并从它中断的确切步骤继续执行。

随处部署,包括 Cloudflare

Flue 是一个多云框架。在 Node.js 上,每个代理作为长期运行的进程运行。你可以将其部署到任何虚拟机或容器中,在 GitHub Actions 中运行,或嵌入到现有服务器上。但当目标为 Cloudflare 时,每个代理都成为一个持久对象。

通过将每个 Flue 代理运行在其自己的持久对象中,Cloudflare 可以自动扩展到你所需的任意数量的代理,每个代理都有自己独立的存储和计算。你无需配置服务器、管理粘性会话或担心噪声邻居。当 Flue 代理部署到 Cloudflare 时,它们使用 Agents SDK 的 runFiber()stash()onFiberRecovered() 方法获得持久执行。Flue 还使用 @cloudflare/codemode@cloudflare/shell 在持久工作区上进行沙盒代码执行。

Flue 的 Cloudflare 目标之所以如此有效,是因为它清晰地映射到我们在 Agents SDK 中构建的核心原语。你甚至可以 深入研究 Flue 源代码 以了解底层框架 Pi 如何适应在 Cloudflare Agents SDK 上工作。

以下是 Flue 如何在底层利用 Agents SDK,以及可靠地大规模运行任何现代代理框架所需的条件。

每个代理框架都需要持久执行

代理轮次不是单个请求。模型流式传输令牌、调用工具、等待结果、可能请求人工批准或将工作委托给子代理。这个序列可能需要几秒或几分钟,并且在任何时候进程都可能被中断或崩溃。当这种情况发生时,所有在内存中的代理状态都会丢失:流式连接、待处理的工具调用、代理在其轮次中的位置。当然,对话历史会持久化到磁盘,但用户会看到一个永远无法解析的旋转器。这是一个糟糕的用户体验。

纤程 通过在代理底层的 持久对象 内部提供原生的检查点机制来解决这个问题。runFiber() 在代理轮次中的工作开始之前将进度记录到持久对象的 SQLite 存储中,并在轮次推进时使用 stash() 进行检查点。当新的代理实例在中断后启动时,onFiberRecovered()

交付最后一个检查点,因此您的代理知道某个回合被中断、中断时进行到了哪里,并可以决定如何继续。

import { Agent } from "agents";
import type { FiberRecoveryContext } from "agents";
class MyAgent extends Agent {
async doWork() {
await this.runFiber("my-task", async (ctx) => {
const step1 = await expensiveOperation();
ctx.stash({ step1 });
const step2 = await anotherExpensiveOperation(step1);
this.setState({ ...this.state, result: step2 });
});
}
async onFiberRecovered(ctx: FiberRecoveryContext) {
if (ctx.name !== "my-task") return;
const { step1 } = (ctx.snapshot ?? {}) as { step1?: unknown };
if (step1) {
const step2 = await anotherExpensiveOperation(step1);
this.setState({ ...this.state, result: step2 });
}
}
}

Flue 在其 Cloudflare 目标上使用 runFiber() 来实现这一点。借助 onFiberRecovered() 钩子,你的 harness 可以决定如何恢复 turn 的执行,无论是像 Project Think 那样尝试完全重建模型以修复 turn 状态,还是重放 turn 的某些部分。

Agent harness 通过工具让模型访问外部世界。但工具表面增长迅速,随着列表变长和上下文窗口被工具定义填满,模型在选择正确工具方面的表现会变差。一个更好的模式:给模型一个执行代码的工具。模型编写一个 TypeScript 函数来调用它需要的 API,然后 harness 运行它。我们在引入 Code Mode 时写过这一点。

问题在于代码在哪里运行。为了安全地运行 LLM 生成的代码,你需要一个沙箱。但典型的沙箱运行每个工具调用会缓慢、成本高昂且效率低下。这就是为什么 Agents SDK 提供了 @cloudflare/codemode,它封装了 Dynamic Workers,在你提供的绑定下,在其自己的 Worker 隔离环境中执行 LLM 生成的代码。

Code Mode 为每个代码片段创建一个新的 Dynamic Worker,运行它,然后丢弃。隔离环境在 10ms 内启动,每次加载成本为 $0.002,相比每次 agent 需要执行一小段代码时启动一个容器,执行速度更快,成本更低。Flue 在其 Cloudflare 目标上使用 @cloudflare/codemode 来驱动其代码工具。agent 针对工作区编写 JavaScript,并使用 Code Mode 运行它。

大多数工作区任务不需要完整的容器

Agent harness 通常需要一个文件系统,无论是读取文件、写入输出、搜索代码还是理解差异。特别是编码 agent 生活在文件系统中。但如果 harness 在无服务器环境中运行,它如何获得一个跨执行持久化的耐用文件系统?

通常的答案是容器。这可行,但对于 agent 主要做的事情来说成本高昂。agent turn 中的大多数文件系统操作都是文本操作。考虑一个审查 agent,它读取文件、通过源代码 grep,或者可能写入补丁。你不需要为此启动完整的 Linux 系统。

@cloudflare/shell 为你的 agent 在其 Durable Object 内提供了一个持久的虚拟文件系统,由 SQLite 支持。它提供了类型化的文件操作——读取、写入、编辑、搜索、grep、diff——agent harness 可以将其用作工具。

在 Cloudflare 目标上运行的 Flue agent 不是调用单个工具,而是针对工作区虚拟文件状态 API 编写 JavaScript。通过在 Durable Object 内运行更多操作,agent 受益于隔离模型更高效的执行过程,完全避免了容器开销:

async () => {
const files = await state.glob("src/**/*.ts");
const results = [];
for (const file of files) {
const content = await state.readFile(file);
const todos = content.match(/\/\/ TODO:.*/g);
if (todos) results.push({ file, todos });
}
return results;
}

这意味着,对于需要运行 shell 和文件系统操作来完成工作的智能体,可以获得更快、更具成本效益的沙箱环境。而对于需要完整操作系统(如运行 npm install、git 或编译器)的智能体,Cloudflare Containers 提供了这样的环境。我们还在构建 @cloudflare/workspace,以保持给定 Durable Object 的虚拟文件系统与容器的文件系统同步,从而仅在需要时实现从轻量级 Workers 到 Linux 环境的无缝过渡。

动态工作流:让智能体编写自己的工作流以一致地重复任务

但是,当智能体需要做的不仅仅是读取文件或执行单个代码片段时,会发生什么?当它需要编排一个大规模、多步骤的管道,并且该管道必须随着时间的推移一致地重复,比如成功解决错误的代码审查或产生良好结果的研究工作流时,会发生什么?一个 harness 本身无法提供持久的多步骤执行。它需要平台来持久化每个步骤、重试失败并在中断后恢复。

这种模式正越来越受欢迎。Claude Code 最近推出了 动态工作流,其中 Claude 在运行时编写一个 JavaScript 脚本,将工作分派给数十个子智能体,并且运行时持久地执行该脚本。@cloudflare/dynamic-workflows 为在 Agents SDK 上运行的任何 harness 提供了这一功能。您的智能体在运行时生成一个工作流,Workflows 引擎持久化每个步骤、重试失败,并且可以休眠数小时或等待外部事件(如人工审批)。

从 Agent 类中,runWorkflow() 将您的智能体连接到 Workflows 引擎。智能体启动工作流后可以进入休眠状态。工作流通过 RPC 回调智能体以报告进度、更新状态或请求批准。当工作流完成时,智能体被唤醒并获取结果。

直接访问 Cloudflare 生态系统

除了计算和存储,智能体 harness 还需要访问外部能力:网页浏览、电子邮件、记忆、搜索、推理。一个 harness 不应单独集成每一项,为每一项管理 API 密钥,或担心凭据通过智能体生成的代码泄露。

Agent 类通过 绑定 让您的 harness 访问 Cloudflare 的其他部分:AI Gateway 用于按智能体跟踪支出和设置限制,Browser Run 用于网页自动化,Email Service 用于收件箱工作流,Agent Memory 用于持久记忆,AI Search 用于检索,Containers 用于需要完整操作系统的工作负载,以及跨 14 个以上模型提供商 的推理。绑定在不暴露凭据的情况下授予能力:您的智能体使用它们,但密钥永远不会进入智能体生成的代码。

将您的智能体带到智能体云

我们知道这种方法有效,因为它正是我们构建 Project Think(我们的第一方智能体 harness)所使用的确切架构基础。虽然 Project Think 仍然是我们为原生 Cloudflare 智能体体验提供的高度优化、开箱即用的解决方案,但 Agents SDK 确保更广泛的开源生态系统可以利用这些完全相同的经过实战检验的原语,包括 Flue。

如果您今天正在使用 Flue 构建智能体,只需点击几下即可部署到 Cloudflare。如果您正在构建自己的智能体 harness 或构建智能体框架,请以 Agents SDK 为目标,并免费获得平台集成。