Cloudflare 押注 Flue：智能体需要的不是框架，而是运行时

快速说明： 有趣的地方不在于又多了一个智能体框架。有趣的地方在于，Cloudflare 试图把智能体变成持久化、可恢复、边缘原生的基础设施。

有趣的地方#

Cloudflare 关于 Flue 的新文章，乍看之下像是本已拥挤的智能体市场里又一份框架公告。但我认为更重要的故事在技术栈更深处：Cloudflare 正试图标准化生产环境智能体的运行时层。

大多数关于智能体的讨论仍然从框架层开始。我们比较 LangChain、CrewAI、AutoGPT、OpenAI Agents SDK，以及越来越多的编排工具。对原型来说这很合理。但一旦智能体成为生产基础设施，难题就往下沉：它如何在重启后存活？如何恢复长任务？如何安全地执行生成的代码？如何存储文件？如何等待审批？如何控制凭据？如何保持可观测？

Flue 是什么#

Flue 是 Astro 团队打造的一个开源 TypeScript 框架。它的 1.0 Beta 构建在 Pi harness 之上，是 Cloudflare 重点推介的首个面向 Cloudflare Agents SDK 的框架。在实践中，Flue 是开发者体验层：项目结构、CLI、集成、前端钩子，以及一种声明式的方式，用来描述智能体知道什么、能做什么。

Cloudflare 把生产智能体技术栈分为三层。顶层是框架，比如 Flue。中间层是 harness，比如 Pi 或 Project Think，负责运行智能体循环：读取上下文、调用工具、管理状态、继续任务。底层是运行时/平台，Cloudflare 希望 Agents SDK 落在这里：计算、状态、存储、持久化执行、工作流和绑定。

这个分层很重要。它意味着智能体生态可能会从「哪个框架最流行」转向「哪个运行时平台能承载最多的框架和 harness」。Cloudflare 的目标不只是构建 Flue——而是为更多 harness 运行在 Cloudflare 底层能力之上腾出空间。

为什么运行时很重要#

一个有用的智能体很少只是一次请求-响应的交易。它可能要读取一个 GitHub issue、复现一个 bug、创建分支、修改代码、运行测试、等待 CI、请求审批，然后发起 pull request。它可能常驻在 Slack 或 Linear 里，只在事件到来时被唤醒。它可能 99% 的生命都在等待。

这就是为什么生产智能体需要不同的底层基质。Cloudflare 的模式把智能体视为持久化的身份（durable identities），而不是常驻进程。状态、SQL 数据、调度和 fibre 检查点可以在休眠和重启后存活。智能体可以在空闲时睡觉、被事件唤醒、从保存的检查点恢复工作，而不是丢掉整轮对话。

传统 Web 应用的每一个问题在这里都会被放大：进程崩溃怎么办？模型调用超时怎么办？工具执行中途失败怎么办？文件状态存在哪里？生成的代码在哪里安全运行？一个 99% 时间都在等待的智能体，需要一台永远运行的服务器吗？

Cloudflare 的答案是：把智能体视为「带有状态的身份，可以休眠，也可以被事件唤醒」。这正是 Durable Objects、Fibres、Workflows 和 Bindings 所提供的东西。它们不是为演示而建的，而是为生产故障、长任务、等待和恢复而建的。

核心能力#

持久化执行。 智能体可以在任务过程中通过 Fibres 检查点保存进度。当进程被回收或重启时，它从最新检查点恢复，而不是让用户盯着一个转圈的加载器。

沙盒代码执行。 Cloudflare 倾向于一种模式：不让模型面对一大堆工具，而是让模型写一个小型 TypeScript 或 JavaScript 函数，调用它需要的 API。平台在隔离的 Dynamic Worker 中运行这段生成的代码，只提供开发者给出的绑定。

轻量持久化工作区。 许多智能体任务是面向文件的，但不需要完整的 Linux 容器。读取文件、grep 代码、写补丁、生成 diff，都可以在由 Durable Objects 和 SQLite 支撑的虚拟文件系统中完成。当智能体需要完整操作系统时，容器仍然可用。

动态工作流。 当智能体需要一个可重复的多步管道时，工作流本身可以在运行时生成并交给平台。平台持久化步骤、重试失败、休眠数小时、等待外部事件或人工审批。

平台绑定。 智能体可以访问 AI Gateway、Browser Run、Email、Agent Memory、AI Search、Containers 等能力，而无需向模型生成的代码直接暴露原始凭据。Cloudflare 的绑定系统给智能体能力，但不交出密钥。

如何比较#

我不会把 Flue 说成 LangGraph、CrewAI、AutoGPT 或 OpenAI Agents SDK 的直接替代品。它们处于技术栈的不同位置，为不同的用户优化。

LangGraph 是一个面向长时运行、有状态智能体的底层编排框架和运行时，尤其适合需要显式图控制、持久化执行、流式输出和人机协同工作流的场景。

CrewAI 强调智能体、团队（crews）、流程（flows）、护栏（guardrails）、记忆、知识、可观测性和企业自动化。它的学习曲线相对直观。

AutoGPT 已经更接近一个面向用户的自动化平台：描述任务、可视化构建、后台运行、从仪表盘监控。

OpenAI Agents SDK 适合那些由服务器拥有编排、工具执行、状态、审批，并且需要 Python 或 TypeScript 控制、工具、MCP、交接（handoffs）、护栏和可观测性的场景。

Flue 加 Cloudflare 之所以不同，是因为重心在运行时。它的主张是：带上你的 harness，带上你的框架，但请运行在一个已经拥有 Durable Objects、事件驱动计算、工作流持久化、沙盒执行和全球部署的平台上。

值得关注什么#

如果你在构建一个简单的问答机器人，Flue 可能不是你的首要考虑。普通的 API 加数据库加模型调用就足够了。

但如果你在构建后台智能体——自动化的 GitHub issue 分流、每日研究聚合、Slack 或 Discord 事件处理、长时研究任务、自动化报告生成或人工审批工作流——Cloudflare 这条路值得关注。它把那些痛苦的部分——部署、状态恢复、事件唤醒、沙盒化、凭据隔离、成本控制——尽可能推入平台层。

注意事项也很明显。Flue 还处于早期。API 稳定性需要时间沉淀。你越深入依赖 Cloudflare 的原语，就越继承它的平台假设。而且不是每个工作负载都适合边缘优先的运行时：重型构建、复杂的操作系统依赖和 GPU 密集型任务，可能仍然需要容器或专门的基础设施。

尽管如此，方向是对的。过去的竞争是关于谁编排得更优雅。Flue 表明下一阶段会更低层：谁能让智能体保持存活，让它安全地调用工具和代码，让它可观测、可计费、可恢复、可扩展。

Flue 本身可能成为、也可能不会成为最流行的智能体框架。但 Cloudflare 瞄准的那一层——智能体的生产运行时——才是接下来重要的那一层。