为什么 Cloudflare Agents 很适合 AI 产品

根据 Cloudflare 官方文档,每个 Agent 都运行在一个 Durable Object 之上。Durable Object 是一种带状态的微型服务器,自带 SQL 数据库、WebSocket 连接和调度能力。换句话说,AI Agent 所需要的基础构件——记忆、实时连接、长时间运行的任务、按实例保存的状态——已经内置在这个平台里了。

这套结构之所以吸引人,原因很简单。多数 AI 应用仍然停留在"处理一个请求就结束"的 stateless 模式上。但真正的 Agent 产品需要同时处理记忆、工具调用、审批流程、定时任务、与用户保持的实时连接。Cloudflare Agents 并不是把这些需求硬塞进一堆独立服务的组合里去解决,而是把 Agent 本身当作一个带状态的单元来部署。

Cloudflare 表示 Agents 运行在其全球网络上,可以扩展到数千万个实例的规模。这不只是在炫耀规模——它意味着可以把"每个用户一个 Agent""每个工单一个 Agent""每个任务一个 Agent"当作产品设计的基本单元。

什么是基于 Durable Object 的 Agent

与其把这种架构看作"serverless 函数",不如把它看作"带状态的独立服务器"更容易理解。两者的差异可以这样对比:

这个差异在用户体验上表现得尤其明显。比如只需用户批准一次的操作、执行过程中状态会多次变化的任务、需要保留长对话上下文的场景,带状态的 Agent 都远比 stateless 结构更自然。

Cloudflare 的 Agents API 文档也说明,Agents 需要依赖 Durable Objects,并且每个 Agent 可以拥有大量实例。这使它很适合用于多租户产品或按用户区分的助理型 Agent。

在 AI 应用中最好用的模式

Cloudflare 提供的 starter 模式相当实用。根据官方文档,具有代表性的出发点主要有以下四种:

1. 流式 AI 对话
2. 服务端与客户端的工具调用
3. human-in-the-loop 审批
4. 任务调度

这个组合几乎精准对应 AI 应用的典型需求。对话式界面需要流式输出,业务操作需要工具调用,有风险的动作需要人工审批,后台清理工作需要定时执行。

举个例子,想象一个客服 Agent。对话以流式方式回应,订单查询或退款审核交给工具处理,金额较大的操作先进入待审批状态,未处理完的事项在几分钟后再次确认。整个流程都可以自然地衔接在同一个 Agent 内部。

import { Agent } from "agents";

export class SupportAgent extends Agent {
  async onRequest(request) {
    const latestMessage = await request.json();
    // 把状态存进 SQL,再把模型回应和审批流程串联起来运行。
    return new Response(JSON.stringify({ ok: true, latestMessage }));
  }
}

模型选择更加灵活

Cloudflare Agents 并不绑定单一模型供应商。根据官方文档,Workers AI 是默认提供的,此外还可以使用 OpenAI、Anthropic、Google Gemini,以及其他提供 OpenAI 兼容 API 的服务。

这一点在产品设计上很重要,因为 Agent 的状态和执行由 Cloudflare 管理,而模型则可以根据任务性质自由更换。可以这样考虑:

• 简短快速的回应用轻量模型
• 结构化提取用指令遵循能力稳定的模型
• 长文本推理或高难度编码用能力更强的模型
• 对成本敏感的路径优先使用 Workers AI

也就是说,Agent 架构和模型架构可以分开处理。这种分离让上线和 A/B 测试都变得容易得多。

记忆与状态如何处理

AI 应用中最常崩溃的地方就是"记忆"。对话记录一旦变大,就得单独设计外部存储;会话一旦混乱,状态同步就会变得困难。Cloudflare Agents 把这一部分简化成了以 Agent 为单位的 SQL 与状态存储。

官方文档说明,每个 Agent 实例都拥有自己的 SQL 数据库,并且在同一个上下文中运行。实务上,以下这类设计会比较契合:

• 保存用户画像与偏好
• 保存最近的对话摘要
• 保存任务的进度状态
• 保存审批结果与过期时间
• 保存外部工具调用结果的短期缓存

这种方式的好处是,记忆不必只依附在模型的提示词里。因为应用本身拥有结构化的状态,所以更容易区分"必须记住的内容"和"可以摘要处理的内容"。

长时间运行的任务与 human-in-the-loop

Agent 产品往往不会立刻结束。文档审核、外部 API 确认、等待审批、定时重试,这类流程都需要时间。Cloudflare Agents 的设计让这类任务处理起来更自然。

human-in-the-loop 模式尤其重要,比如以下这些场景:

• 退款、支付、删除这类难以撤销的操作
• 会影响外部系统的变更操作
• 涉及敏感数据的动作
• 政策要求必须由人工审批的动作

好的模式是:Agent 先提出方案,人工确认后,只执行获批的范围。这样就能同时获得自动化和可控性。

Propose action:
- Summarize the request
- Show the side effects
- Ask for approval

After approval:
- Execute only the approved step
- Persist the decision in agent state
- Schedule a follow-up check if needed

可观测性默认就很安静

Cloudflare Agents 的可观测性在实务中做出了不错的平衡。根据官方文档,Agent 会针对重要操作发出结构化事件,如果没有人订阅,默认就保持安静,在 hot path 上几乎没有额外开销。

这一点从运维角度看非常实用。初期不需要过度插入日志,只需要在真正需要的时候订阅事件,就能筛选出 RPC 调用、状态变化、调度执行、workflow 转换、MCP 连接这类事件。

也就是说,可观测性不是附加功能,而是 Agent 产品的安全阀。带状态的系统本来就更容易难以调试,而有了结构化事件,排查问题的速度会快得多。

也很适合部署 MCP

Cloudflare 的 MCP 客户端文档说明,连接会持续保存在 Agent 的 SQL 存储中,一旦连接到某个 server,该 server 的所有工具就会自动可用。这一点在部署基于 MCP 的 Agent 时相当重要。

原因在于,MCP server 的连接本身就需要状态。连接过哪些 server、认证令牌、可用的工具列表、上一次同步的时间,这些信息都需要持续保存。把 Durable Object 的 SQL 和 Agent 状态结合起来用,就能不依赖单独的会话数据库,轻松处理这些连接信息。

实务上,能用一个"serve path"就完成部署是最方便的——也就是说,Agent 接收 HTTP 请求、维持状态、连接 MCP server、调用所需工具,这一整套流程都在同一条路径上运行。这种简单性会在后续大幅降低维护成本。

什么时候这套结构比 stateless 模式更合适

只要满足以下条件中较多的一项,Cloudflare Agents 这一侧就会更自然:

• 用户回来时需要记住此前的状态
• WebSocket 这类实时连接很重要
• 需要审批流程
• 需要定时执行或重试
• 单个用户或任务单元需要独立的状态
• MCP 或工具连接需要持续保持

反过来,一次性的文本转换,或完全没有外部状态的短任务,用一般的 Workers 或其他 stateless 函数就足够了。核心不在于"永远都该用 Agents",而是先判断状态和连接是否是产品的本质。

上线检查清单

实际部署时,按以下顺序推进比较安全。

1. 用一句话定义 Agent 的边界。先确定是按用户、按工单,还是按任务划分。
2. 拆分状态项。长期记忆、进度状态、审批状态、临时缓存不要混在一起。
3. 决定模型调用路径。确定 Workers AI、OpenAI、Anthropic、Gemini 中哪个作为默认。
4. 先识别需要审批流程的操作。
5. 列出需要调度的后台任务。
6. 决定在哪里订阅可观测性事件。
7. 如果涉及 MCP 连接,先设计好持久化存储和重连方式。
8. 确定失败时的重试与恢复路径。

结语

Cloudflare Agents 与 Durable Objects 的组合,让 AI 应用不再是"函数的连续",而是可以被设计成有状态的产品单元。这是这套架构最大的优势。记忆、实时连接、审批、调度、MCP 连接、结构化的可观测性,都不需要被分散到各处,而是可以直接附着在 Agent 本身上。

stateless serverless 依然有用,但在 Agent 产品中,一旦不断把状态和连接推到应用之外,复杂度就会上升。Cloudflare Agents 把这部分复杂度接管到平台一侧,让开发者能更专注于产品逻辑本身。

References

• Cloudflare Agents overview
• Agents API overview
• Agent class internals
• Store and sync state
• Using AI Models
• Observability
• Human-in-the-loop patterns
• McpClient
• Cloudflare Durable Objects overview