「Cloudflare 边缘智能体」 在当前的语境下就是把一个具备以下特征的 Agent 跑在 Cloudflare 全球 + 若干 PoP 节点上：

• 带状态能记住对话历史、任务进度、使用者偏好，跨多次请求保持上下文。
• 能调工具可以读写数据库、调外部 API、执行浏览器操作、调用其他 Agent。
• 可恢复单次任务可能跑几分钟到几小时中途宕机/超时后能从上一个 checkpoint 继续。
• 多模型路由、OpenAI、Anthropic、DeepSeek 之间分发。
• 边缘就近请求落在离使用者最近的节点，冷启动 <5 ms。

Cloudflare 在 2023 年底到 2024 年中陆续补齐了这一套几乎所有零件。2024 年 6 月正式开源 Agents SDK把「带状态的 Agent」做成了 Workers 环境里的一等公民——这是它和 Vercel AI SDK / LangChain JS 最本质的区别：后两者是纯客户端框架状态自己想办法存；Agents SDK 直接绑定 Durable Objects 当 actor 容器。

二、为什么关键

边缘跑 Agent 已经卷了两年，但真正能凑齐「带状态 + 全球分布 + 模型路由 + 持久执行」四件套的玩家寥寥无几。

网站	状态管理	全球分布	持久执行	模型路由	评价
Cloudflare	✓ Durable Objects + PoP	✓ 全局	✓ Workflows	✓ AI Gateway	唯一全栈方案
Vercel	K/V	✗ 部分 Edge	✗ 需外接 Inngest/Temporal	✗ 前端转发
AWS Lambda	DynamoDB✗	✗ 区域级	✓ Step Functions	✗ 高成本高延迟
Deno Deploy

Pain Point：COLD START 与 STATE 同步是大多数使用者抱怨的根源；跨区调用导致数百毫秒延迟；说起来，传统云函数缺乏持久化检查点，使长任务频繁失效。

The sweet spot：Clo​udflare 是目前唯一一个不需要拼多家厂商就能跑起来的网站，这也是 Anthropic Claude Skills Marketplace、Block 、Stripe Apps 等把 MCP server 默认部署在 Workers 上的原因。老实说，

三、关键玩家与环境

Cloudflare 官方零件清单

Agent 实例 = 一个 DO，承载对话状态、工具调用上下文 单 DO 全球只在一个 region 物化，跨区访问有延迟 长任务持久执行，自动 checkpoint，宕机可恢复 2025‑Q4 才 GA。单步仍受 Worker 限制 本地推理 Llama/Qwen2/Stable Diffusion 等模型 大模型走 AI Gateway

产品	SaaS 中扮演角色	关键限制
Workers 请求入口、无状态计算 单请求 CPU 30 s/10 ms，内存 128 MB
Durable Objects
Workflows
Workers AI
AI Gateway 模型路由、缓存、限流、可观测，多家上游统一接入 / tr>

Vectorize 向量数据库 单索引 万向量

D1 SQLite 边缘数据库 单库 10 GB，读写分离

。

---