1. 从cloudflare-os这个名字说起它到底想解决什么问题第一次看到cloudflare-os这个项目名我下意识以为 Cloudflare 官方又放出了什么操作系统级别的大招。翻了一圈资料才反应过来这更像是社区里有人把 Cloudflare 的边缘计算能力包装成了一套类操作系统的开发范式——用 Workers 当内核用 Durable Objects 当进程状态用 AI 绑定当系统调用把散落在各个边缘节点的算力、存储、模型能力抽象成一套可以像写本地程序一样去调用的运行时。这个思路其实挺有意思。传统做 AI Agent你要么在本地跑一套 Python 环境要么租一台云服务器常驻进程要么用 Serverless 函数拼拼凑凑。前两种方案有运维成本第三种方案有冷启动和状态管理的坑。而 Cloudflare 这套东西的独特之处在于它天生就是分布式的天生就是事件驱动的而且现在把 AI 推理能力直接绑到了 Worker 上你写一个 Agent 的门槛被压到了一个 JS 文件 一个配置文件。所以这篇东西我想聊的不是cloudflare-os 是什么这种百科式问题而是如果你是一个想搭 AI Agent 的开发者这套边缘原生的思路值不值得投入它的核心构件怎么组合踩过哪些坑以及那些热搜词里反复出现的 agent 架构、agent 记忆、agent 安全在这套体系里分别对应什么实现。适合读这篇的人有基本 JS/TS 基础想搞明白边缘计算和 AI Agent 怎么结合或者你已经在用 Workers但还没想清楚怎么把它变成一个真正的 Agent 运行时。纯小白也能看我会把每个概念用生活化的方式讲清楚。2. 拆解 cloudflare-os 的内核Workers、Durable Objects 与 AI 绑定2.1 Workers 为什么能当内核用Cloudflare Workers 本质上是一个跑在边缘节点上的 V8 Isolate 运行时。你可以把它理解成一个随叫随到、用完就走的函数容器但它比传统 Serverless 强的地方在于冷启动几乎可以忽略——官方给的数据是 0ms 级别的启动开销实测下来首次请求的延迟通常在个位数毫秒。这个特性对 Agent 来说太关键了因为 Agent 的交互往往是用户说一句、Agent 想一下、调个工具、回一句如果每次思考都要等容器冷启动几百毫秒体验直接崩掉。把 Workers 当内核意味着你的 Agent 逻辑是以请求为生命周期单位的。每个 HTTP 请求进来Worker 被唤醒执行你的 Agent 逻辑返回结果然后休眠。这种模型天然适合无状态的推理编排但问题来了Agent 需要记忆啊多轮对话的上下文往哪放2.2 Durable Objects给 Agent 一个有状态的进程这就是 Durable Objects 出场的地方。你可以把它想象成操作系统里的进程——每个 Durable Object 实例有唯一 ID有独立的内存状态而且 Cloudflare 保证同一个 ID 的请求永远路由到同一个实例上。这意味着你可以给每个用户会话分配一个 Durable Object把对话历史、工具调用记录、临时变量全塞进去下次这个用户再来还是同一个实例接着聊。我实测过一个简单的多轮对话 Agent用 Durable Object 存上下文连续 20 轮对话下来状态一致性没有任何问题。对比之下如果你用纯 Workers 外部 KV 存储每次读写都要走网络延迟会明显上去而且并发写还有竞态问题。Durable Objects 的单线程执行模型天然避免了竞态这点在 Agent 场景里非常省心。2.3 AI 绑定把模型调用变成系统调用Cloudflare 现在提供了 Workers AI 绑定你可以在 Worker 里直接env.AI.run()调用托管在边缘的模型比如 Llama 系列、Mistral 系列。这相当于把调用大模型这件事从发 HTTP 请求到某个 API 端点降级成了调用一个本地函数。虽然底层还是网络调用但省掉了你自己管理 API Key、处理重试、拼接请求体这些琐事。不过要注意Workers AI 上的模型能力和 GPT-4 级别还有差距适合做轻量推理、分类、摘要、embedding 这类任务。如果你要跑复杂的 Agent 规划可能还是得外接更强的模型 API。我的做法是混合轻量任务走 Workers AI 省钱省延迟重任务走外部 API。构件类比核心作用注意事项WorkersCPU/内核执行 Agent 逻辑无状态单次请求生命周期Durable Objects进程保存会话状态与记忆有唯一 ID单线程Workers AI系统调用边缘模型推理模型能力有限适合轻量任务KV / R2 / D1文件系统/磁盘持久化存储KV 最终一致D1 是 SQLite3. 用这套体系搭一个 Agent从零到跑通的完整链路3.1 项目初始化与目录结构设计先说环境准备。你需要一个 Cloudflare 账号然后装wrangler这个 CLI 工具它是整个开发流程的中枢。npm install -g wrangler之后wrangler login走一遍授权本地就能直接部署了。目录结构我建议这样组织这是踩过几次坑之后稳定下来的方案my-agent/ ├── src/ │ ├── index.ts # Worker 入口路由分发 │ ├── agent.ts # Agent 核心逻辑 │ ├── tools/ # 工具函数集合 │ │ ├── search.ts │ │ └── calc.ts │ └── memory.ts # Durable Object 定义 ├── wrangler.toml # 配置文件 └── package.json为什么要把工具单独放一个目录因为 Agent 的工具会越加越多混在主逻辑里很快就乱成一团。而且工具函数最好是纯函数方便单独测试。3.2 wrangler.toml 里那几个必须配对的字段配置文件是新手最容易翻车的地方。一个能跑通 AI Agent 的最小配置大概长这样name my-agent main src/index.ts compatibility_date 2024-09-23 [ai] binding AI [[durable_objects.bindings]] name AGENT_MEMORY class_name AgentMemory [[migrations]] tag v1 new_classes [AgentMemory]这里有几个坑我必须提醒。第一compatibility_date不要随便写个未来日期某些新特性在旧日期下不生效某些旧行为在新日期下被移除写一个你确认过的稳定日期。第二Durable Objects 的migrations字段是必须的哪怕你是第一次部署没有这个字段会直接报错。第三class_name必须和你在代码里export的类名完全一致大小写敏感。3.3 Agent 主循环的写法别把它写成一个大函数很多人第一次写 Agent会把接收输入 → 调模型 → 解析工具调用 → 执行工具 → 再调模型这一整套塞进一个函数里。这样写能跑但没法维护。我的做法是拆成几个职责清晰的模块export default { async fetch(request: Request, env: Env) { const { message, sessionId } await request.json(); const id env.AGENT_MEMORY.idFromName(sessionId); const stub env.AGENT_MEMORY.get(id); return stub.fetch(request); } }Worker 入口只做一件事根据 sessionId 把请求路由到对应的 Durable Object。真正的 Agent 逻辑写在 Durable Object 里因为那里才有状态。export class AgentMemory { state: DurableObjectState; history: Message[] []; constructor(state: DurableObjectState) { this.state state; this.state.blockConcurrencyWhile(async () { this.history (await this.state.storage.get(history)) || []; }); } async fetch(request: Request) { const { message } await request.json(); this.history.push({ role: user, content: message }); const reply await this.runAgentLoop(); this.history.push({ role: assistant, content: reply }); await this.state.storage.put(history, this.history); return new Response(JSON.stringify({ reply })); } }blockConcurrencyWhile这个方法是关键它保证在状态加载完成之前不会有新的请求进来处理避免了读到空历史的竞态。这个细节官方文档里提得不多但实际项目里不加会偶发诡异 bug。3.4 工具调用的实现让模型能动手Agent 和普通聊天机器人的区别就在于它能调工具。在 Workers 环境里实现工具调用核心是把工具定义成 JSON Schema 喂给模型然后解析模型返回的 tool_calls 字段。const tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: { type: string, description: 城市名 } }, required: [city] } } } ];模型返回工具调用请求后你在代码里做一次 dispatchasync function executeTool(name: string, args: any) { switch (name) { case get_weather: return await fetchWeather(args.city); default: return { error: 未知工具: ${name} }; } }这里有个经验工具的描述文字要写得像给一个新员工交代任务一样具体。我试过把描述写得很简略模型经常选错工具或者传错参数。把 description 写详细之后工具选择的准确率明显提升。4. Agent 记忆、多 Agent 协作与安全热搜词背后的真实实现4.1 Agent 记忆的三层结构热搜里agent记忆这个词出现频率很高但很多人对它的理解停留在把对话历史存起来。实际上一个能用的 Agent 记忆应该分三层第一层是短期记忆就是当前会话的对话历史存在 Durable Object 的内存里会话结束可以丢弃。第二层是长期记忆把重要的用户偏好、事实性信息抽取出来存到 KV 或 D1 里跨会话保留。第三层是语义记忆把历史对话做 embedding 存进向量数据库需要时做相似度检索召回。Cloudflare 现在有 Vectorize 这个向量数据库产品可以和 Workers 配合做语义检索。我的做法是对话结束后异步触发一个 Worker把本轮对话做 embedding 存进 Vectorize下次用户提问时先检索相关历史拼进 prompt 里。这样 Agent 就能记得几周前聊过的事情。4.2 多 AI 协作在边缘环境怎么落地多ai协作和agent框架与编排也是高频词。在 Cloudflare 这套体系里做多 Agent 协作我推荐用编排者-执行者模式一个主 Agent 负责拆解任务把子任务分发给多个专职 Agent每个专职 Agent 是一个独立的 Worker 或者 Durable Object。比如做一个帮我规划旅行的 Agent主 Agent 拆出查航班查酒店排行程三个子任务分别调用三个专职 Agent。这些子 Agent 之间不直接通信全部通过主 Agent 中转。这样做的好处是职责清晰坏处是主 Agent 容易成为瓶颈。如果子任务之间需要频繁交互可以考虑让它们共享一个 Durable Object 作为黑板各自读写。4.3 Agent 安全那些不能省的校验agent安全这个词值得单独拎出来说。Agent 能调工具就意味着它能产生副作用安全边界必须划清楚。第一工具白名单。不要让模型自由决定调用什么函数所有可调用的工具必须预先注册dispatch 时严格匹配。第二参数校验。模型生成的参数不可信尤其是涉及文件路径、SQL、URL 的参数必须做严格校验和转义。第三权限隔离。不同用户会话的 Durable Object 之间不能互相访问靠 ID 隔离。第四速率限制。Agent 可能陷入循环调用要有最大迭代次数限制我一般设 10 次超过就强制返回。提示Agent 的工具函数里绝对不要直接拼接用户输入去执行系统命令或数据库查询这是最容易被忽视的安全漏洞。5. 实测中那些文档没写的坑5.1 本地开发与线上行为的差异wrangler dev本地跑起来很顺部署上去却报错这种情况我遇到过好几次。最常见的原因是本地开发时某些绑定是模拟的线上是真实的。比如 Workers AI 在本地是 mock 的返回的是假数据你本地测试工具调用逻辑没问题线上一跑发现模型返回格式不一样。我的建议是涉及 AI 调用的逻辑一定要用wrangler dev --remote连到真实环境测一遍。虽然慢一点但能提前暴露问题。5.2 Durable Object 的存储配额与清理Durable Object 的存储不是无限的而且它按存储量和请求数计费。如果你的 Agent 把每一轮对话都往 storage 里塞时间长了会积累大量数据。我的做法是只保留最近 N 轮对话在 storage 里更早的归档到 R2 或者直接丢弃。另外state.storage.put是异步的别忘了 await否则可能出现数据没写完就返回的情况。5.3 模型返回格式的健壮性处理不同模型返回 tool_calls 的格式有细微差异有的用function.arguments是字符串有的直接是对象。解析的时候一定要做兼容处理function parseArgs(raw: any) { if (typeof raw string) { try { return JSON.parse(raw); } catch { return {}; } } return raw || {}; }不加这层保护线上偶尔就会因为某个模型返回格式变化而整个 Agent 崩掉。5.4 冷启动之外的延迟来源Workers 本身冷启动可以忽略但 Agent 的整体延迟往往卡在两个地方一是模型推理本身的时间二是工具调用的网络往返。前者没法优化后者可以通过并行调用多个独立工具来压缩。我试过把三个互不依赖的工具调用改成Promise.all并行整体响应时间从 2.3 秒降到了 1.1 秒效果很明显。6. 这套方案适合谁以及我踩坑后的几点体会如果你要做的是一个轻量级、低运维、面向全球用户的 AI AgentCloudflare 这套边缘原生的方案确实值得一试。它的优势在于部署简单、全球分布、按量计费特别适合个人开发者和小团队快速验证想法。但如果你需要跑很重的模型推理或者需要复杂的事务性状态管理这套体系会有明显的天花板。我自己在实际项目里最大的体会是别把 Agent 想得太复杂先跑通一个能调一个工具的最小闭环比一上来就设计五层架构有用得多。我最初花了两周设计完美的 Agent 框架结果发现真正跑起来之后80% 的复杂度都用不上。后来砍到只剩 Worker Durable Object 一个工具反而稳定运行了好几个月。另外一个小技巧给 Agent 加一个调试模式把每一轮的 prompt、模型返回、工具调用结果都打到日志里。线上出问题时这些日志比任何监控都管用。我现在的做法是调试模式下把完整链路写进 Durable Object 的 storage出问题直接拉出来看定位效率高很多。这套东西还在快速演进Workers AI 的模型在更新Durable Objects 的能力也在扩展。保持关注官方 changelog比追任何教程都实在。 
长河君 · 2026/10/28 20:09:52 · 阅读 1.2k 边缘计算与AI Agent实战：用Cloudflare Workers构建智能体
1. 从cloudflare-os这个名字说起它到底想解决什么问题第一次看到cloudflare-os这个项目名我下意识以为 Cloudflare 官方又放出了什么操作系统级别的大招。翻了一圈资料才反应过来这更像是社区里有人把 Cloudflare 的边缘计算能力包装成了一套类操作系统的开发范式——用 Workers 当内核用 Durable Objects 当进程状态用 AI 绑定当系统调用把散落在各个边缘节点的算力、存储、模型能力抽象成一套可以像写本地程序一样去调用的运行时。这个思路其实挺有意思。传统做 AI Agent你要么在本地跑一套 Python 环境要么租一台云服务器常驻进程要么用 Serverless 函数拼拼凑凑。前两种方案有运维成本第三种方案有冷启动和状态管理的坑。而 Cloudflare 这套东西的独特之处在于它天生就是分布式的天生就是事件驱动的而且现在把 AI 推理能力直接绑到了 Worker 上你写一个 Agent 的门槛被压到了一个 JS 文件 一个配置文件。所以这篇东西我想聊的不是cloudflare-os 是什么这种百科式问题而是如果你是一个想搭 AI Agent 的开发者这套边缘原生的思路值不值得投入它的核心构件怎么组合踩过哪些坑以及那些热搜词里反复出现的 agent 架构、agent 记忆、agent 安全在这套体系里分别对应什么实现。适合读这篇的人有基本 JS/TS 基础想搞明白边缘计算和 AI Agent 怎么结合或者你已经在用 Workers但还没想清楚怎么把它变成一个真正的 Agent 运行时。纯小白也能看我会把每个概念用生活化的方式讲清楚。2. 拆解 cloudflare-os 的内核Workers、Durable Objects 与 AI 绑定2.1 Workers 为什么能当内核用Cloudflare Workers 本质上是一个跑在边缘节点上的 V8 Isolate 运行时。你可以把它理解成一个随叫随到、用完就走的函数容器但它比传统 Serverless 强的地方在于冷启动几乎可以忽略——官方给的数据是 0ms 级别的启动开销实测下来首次请求的延迟通常在个位数毫秒。这个特性对 Agent 来说太关键了因为 Agent 的交互往往是用户说一句、Agent 想一下、调个工具、回一句如果每次思考都要等容器冷启动几百毫秒体验直接崩掉。把 Workers 当内核意味着你的 Agent 逻辑是以请求为生命周期单位的。每个 HTTP 请求进来Worker 被唤醒执行你的 Agent 逻辑返回结果然后休眠。这种模型天然适合无状态的推理编排但问题来了Agent 需要记忆啊多轮对话的上下文往哪放2.2 Durable Objects给 Agent 一个有状态的进程这就是 Durable Objects 出场的地方。你可以把它想象成操作系统里的进程——每个 Durable Object 实例有唯一 ID有独立的内存状态而且 Cloudflare 保证同一个 ID 的请求永远路由到同一个实例上。这意味着你可以给每个用户会话分配一个 Durable Object把对话历史、工具调用记录、临时变量全塞进去下次这个用户再来还是同一个实例接着聊。我实测过一个简单的多轮对话 Agent用 Durable Object 存上下文连续 20 轮对话下来状态一致性没有任何问题。对比之下如果你用纯 Workers 外部 KV 存储每次读写都要走网络延迟会明显上去而且并发写还有竞态问题。Durable Objects 的单线程执行模型天然避免了竞态这点在 Agent 场景里非常省心。2.3 AI 绑定把模型调用变成系统调用Cloudflare 现在提供了 Workers AI 绑定你可以在 Worker 里直接env.AI.run()调用托管在边缘的模型比如 Llama 系列、Mistral 系列。这相当于把调用大模型这件事从发 HTTP 请求到某个 API 端点降级成了调用一个本地函数。虽然底层还是网络调用但省掉了你自己管理 API Key、处理重试、拼接请求体这些琐事。不过要注意Workers AI 上的模型能力和 GPT-4 级别还有差距适合做轻量推理、分类、摘要、embedding 这类任务。如果你要跑复杂的 Agent 规划可能还是得外接更强的模型 API。我的做法是混合轻量任务走 Workers AI 省钱省延迟重任务走外部 API。构件类比核心作用注意事项WorkersCPU/内核执行 Agent 逻辑无状态单次请求生命周期Durable Objects进程保存会话状态与记忆有唯一 ID单线程Workers AI系统调用边缘模型推理模型能力有限适合轻量任务KV / R2 / D1文件系统/磁盘持久化存储KV 最终一致D1 是 SQLite3. 用这套体系搭一个 Agent从零到跑通的完整链路3.1 项目初始化与目录结构设计先说环境准备。你需要一个 Cloudflare 账号然后装wrangler这个 CLI 工具它是整个开发流程的中枢。npm install -g wrangler之后wrangler login走一遍授权本地就能直接部署了。目录结构我建议这样组织这是踩过几次坑之后稳定下来的方案my-agent/ ├── src/ │ ├── index.ts # Worker 入口路由分发 │ ├── agent.ts # Agent 核心逻辑 │ ├── tools/ # 工具函数集合 │ │ ├── search.ts │ │ └── calc.ts │ └── memory.ts # Durable Object 定义 ├── wrangler.toml # 配置文件 └── package.json为什么要把工具单独放一个目录因为 Agent 的工具会越加越多混在主逻辑里很快就乱成一团。而且工具函数最好是纯函数方便单独测试。3.2 wrangler.toml 里那几个必须配对的字段配置文件是新手最容易翻车的地方。一个能跑通 AI Agent 的最小配置大概长这样name my-agent main src/index.ts compatibility_date 2024-09-23 [ai] binding AI [[durable_objects.bindings]] name AGENT_MEMORY class_name AgentMemory [[migrations]] tag v1 new_classes [AgentMemory]这里有几个坑我必须提醒。第一compatibility_date不要随便写个未来日期某些新特性在旧日期下不生效某些旧行为在新日期下被移除写一个你确认过的稳定日期。第二Durable Objects 的migrations字段是必须的哪怕你是第一次部署没有这个字段会直接报错。第三class_name必须和你在代码里export的类名完全一致大小写敏感。3.3 Agent 主循环的写法别把它写成一个大函数很多人第一次写 Agent会把接收输入 → 调模型 → 解析工具调用 → 执行工具 → 再调模型这一整套塞进一个函数里。这样写能跑但没法维护。我的做法是拆成几个职责清晰的模块export default { async fetch(request: Request, env: Env) { const { message, sessionId } await request.json(); const id env.AGENT_MEMORY.idFromName(sessionId); const stub env.AGENT_MEMORY.get(id); return stub.fetch(request); } }Worker 入口只做一件事根据 sessionId 把请求路由到对应的 Durable Object。真正的 Agent 逻辑写在 Durable Object 里因为那里才有状态。export class AgentMemory { state: DurableObjectState; history: Message[] []; constructor(state: DurableObjectState) { this.state state; this.state.blockConcurrencyWhile(async () { this.history (await this.state.storage.get(history)) || []; }); } async fetch(request: Request) { const { message } await request.json(); this.history.push({ role: user, content: message }); const reply await this.runAgentLoop(); this.history.push({ role: assistant, content: reply }); await this.state.storage.put(history, this.history); return new Response(JSON.stringify({ reply })); } }blockConcurrencyWhile这个方法是关键它保证在状态加载完成之前不会有新的请求进来处理避免了读到空历史的竞态。这个细节官方文档里提得不多但实际项目里不加会偶发诡异 bug。3.4 工具调用的实现让模型能动手Agent 和普通聊天机器人的区别就在于它能调工具。在 Workers 环境里实现工具调用核心是把工具定义成 JSON Schema 喂给模型然后解析模型返回的 tool_calls 字段。const tools [ { type: function, function: { name: get_weather, description: 查询指定城市的天气, parameters: { type: object, properties: { city: { type: string, description: 城市名 } }, required: [city] } } } ];模型返回工具调用请求后你在代码里做一次 dispatchasync function executeTool(name: string, args: any) { switch (name) { case get_weather: return await fetchWeather(args.city); default: return { error: 未知工具: ${name} }; } }这里有个经验工具的描述文字要写得像给一个新员工交代任务一样具体。我试过把描述写得很简略模型经常选错工具或者传错参数。把 description 写详细之后工具选择的准确率明显提升。4. Agent 记忆、多 Agent 协作与安全热搜词背后的真实实现4.1 Agent 记忆的三层结构热搜里agent记忆这个词出现频率很高但很多人对它的理解停留在把对话历史存起来。实际上一个能用的 Agent 记忆应该分三层第一层是短期记忆就是当前会话的对话历史存在 Durable Object 的内存里会话结束可以丢弃。第二层是长期记忆把重要的用户偏好、事实性信息抽取出来存到 KV 或 D1 里跨会话保留。第三层是语义记忆把历史对话做 embedding 存进向量数据库需要时做相似度检索召回。Cloudflare 现在有 Vectorize 这个向量数据库产品可以和 Workers 配合做语义检索。我的做法是对话结束后异步触发一个 Worker把本轮对话做 embedding 存进 Vectorize下次用户提问时先检索相关历史拼进 prompt 里。这样 Agent 就能记得几周前聊过的事情。4.2 多 AI 协作在边缘环境怎么落地多ai协作和agent框架与编排也是高频词。在 Cloudflare 这套体系里做多 Agent 协作我推荐用编排者-执行者模式一个主 Agent 负责拆解任务把子任务分发给多个专职 Agent每个专职 Agent 是一个独立的 Worker 或者 Durable Object。比如做一个帮我规划旅行的 Agent主 Agent 拆出查航班查酒店排行程三个子任务分别调用三个专职 Agent。这些子 Agent 之间不直接通信全部通过主 Agent 中转。这样做的好处是职责清晰坏处是主 Agent 容易成为瓶颈。如果子任务之间需要频繁交互可以考虑让它们共享一个 Durable Object 作为黑板各自读写。4.3 Agent 安全那些不能省的校验agent安全这个词值得单独拎出来说。Agent 能调工具就意味着它能产生副作用安全边界必须划清楚。第一工具白名单。不要让模型自由决定调用什么函数所有可调用的工具必须预先注册dispatch 时严格匹配。第二参数校验。模型生成的参数不可信尤其是涉及文件路径、SQL、URL 的参数必须做严格校验和转义。第三权限隔离。不同用户会话的 Durable Object 之间不能互相访问靠 ID 隔离。第四速率限制。Agent 可能陷入循环调用要有最大迭代次数限制我一般设 10 次超过就强制返回。提示Agent 的工具函数里绝对不要直接拼接用户输入去执行系统命令或数据库查询这是最容易被忽视的安全漏洞。5. 实测中那些文档没写的坑5.1 本地开发与线上行为的差异wrangler dev本地跑起来很顺部署上去却报错这种情况我遇到过好几次。最常见的原因是本地开发时某些绑定是模拟的线上是真实的。比如 Workers AI 在本地是 mock 的返回的是假数据你本地测试工具调用逻辑没问题线上一跑发现模型返回格式不一样。我的建议是涉及 AI 调用的逻辑一定要用wrangler dev --remote连到真实环境测一遍。虽然慢一点但能提前暴露问题。5.2 Durable Object 的存储配额与清理Durable Object 的存储不是无限的而且它按存储量和请求数计费。如果你的 Agent 把每一轮对话都往 storage 里塞时间长了会积累大量数据。我的做法是只保留最近 N 轮对话在 storage 里更早的归档到 R2 或者直接丢弃。另外state.storage.put是异步的别忘了 await否则可能出现数据没写完就返回的情况。5.3 模型返回格式的健壮性处理不同模型返回 tool_calls 的格式有细微差异有的用function.arguments是字符串有的直接是对象。解析的时候一定要做兼容处理function parseArgs(raw: any) { if (typeof raw string) { try { return JSON.parse(raw); } catch { return {}; } } return raw || {}; }不加这层保护线上偶尔就会因为某个模型返回格式变化而整个 Agent 崩掉。5.4 冷启动之外的延迟来源Workers 本身冷启动可以忽略但 Agent 的整体延迟往往卡在两个地方一是模型推理本身的时间二是工具调用的网络往返。前者没法优化后者可以通过并行调用多个独立工具来压缩。我试过把三个互不依赖的工具调用改成Promise.all并行整体响应时间从 2.3 秒降到了 1.1 秒效果很明显。6. 这套方案适合谁以及我踩坑后的几点体会如果你要做的是一个轻量级、低运维、面向全球用户的 AI AgentCloudflare 这套边缘原生的方案确实值得一试。它的优势在于部署简单、全球分布、按量计费特别适合个人开发者和小团队快速验证想法。但如果你需要跑很重的模型推理或者需要复杂的事务性状态管理这套体系会有明显的天花板。我自己在实际项目里最大的体会是别把 Agent 想得太复杂先跑通一个能调一个工具的最小闭环比一上来就设计五层架构有用得多。我最初花了两周设计完美的 Agent 框架结果发现真正跑起来之后80% 的复杂度都用不上。后来砍到只剩 Worker Durable Object 一个工具反而稳定运行了好几个月。另外一个小技巧给 Agent 加一个调试模式把每一轮的 prompt、模型返回、工具调用结果都打到日志里。线上出问题时这些日志比任何监控都管用。我现在的做法是调试模式下把完整链路写进 Durable Object 的 storage出问题直接拉出来看定位效率高很多。这套东西还在快速演进Workers AI 的模型在更新Durable Objects 的能力也在扩展。保持关注官方 changelog比追任何教程都实在。