1. 从cloudflare-os这个标题说起它到底在指什么第一次看到cloudflare-os这个词我下意识以为是 Cloudflare 官方又出了什么操作系统级别的产品。翻了一圈资料才反应过来这其实是一个社区里流传的、带点戏谑意味的说法——它并不是一个真正的操作系统内核而是把 Cloudflare 那一整套边缘计算能力Workers、Durable Objects、KV、R2、D1、Queues、AI Gateway 等等当成操作系统来用的一种心智模型。你写的是 JavaScript 或 TypeScript跑在全球几百个边缘节点上没有服务器要运维没有容器要编排状态、存储、队列、模型调用全都通过绑定binding挂进来。从这个角度看它确实像一套操作系统你负责写业务逻辑底层调度、扩缩容、就近接入全交给平台。这个标题背后真正值得聊的是Cloudflare Workers 作为 AI Agent 运行时的可行性。热搜词里agent、agent开发、agent架构、agent框架、agent记忆、agent安全反复出现说明大家现在最关心的不是能不能跑一个函数而是能不能把一整个有记忆、有工具调用、有编排能力的智能体塞进边缘。我过去大半年在这个方向上做了几个小项目踩的坑不算少这篇就把我的完整思路、选型理由、实操步骤和那些文档里不会写的教训一次性摊开讲。先说清楚适合谁看如果你已经会写一点 JavaScript/TypeScript对 HTTP、API 调用不陌生想搭一个低延迟、免运维、成本可控的 AI Agent 后端那这篇对你有用。如果你完全没接触过边缘计算也没关系我会把关键概念用生活化的方式讲明白。全文围绕一个核心问题展开——用 Cloudflare 这套边缘操作系统来承载 AI Agent到底该怎么设计、怎么落地、哪些地方会翻车。2. 为什么把 Agent 放到边缘延迟、成本与运维的三重账2.1 传统 Agent 后端的三个痛点大部分人搭 AI Agent 的第一反应是买台云服务器装个 Node 或 Python 服务接上大模型 API再配个数据库存对话历史。这套方案能跑但跑起来之后问题一个接一个。第一个痛点是延迟。Agent 的核心体验是对话感用户发一句话希望一两秒内看到回应。但你的服务器可能在美国东部用户在国内光网络往返就两三百毫秒再加上模型推理时间体验直接崩。你可能会说那我多区域部署好那运维复杂度立刻上一个台阶。第二个痛点是冷启动和扩缩容。Agent 的流量往往不是平稳的可能白天没人用晚上突然来一波。传统容器冷启动动辄几秒用户等不起。你要预热、要做弹性伸缩策略这些都是纯成本。第三个痛点是状态管理。Agent 需要记忆——对话历史、用户偏好、工具调用中间结果。传统做法是接一个 Redis 或 Postgres又多了两个要运维的组件还得考虑它们和计算节点的网络延迟。2.2 边缘运行时给出的答案Cloudflare Workers 这套东西恰好在这三点上都有针对性设计。它在全球部署了大量节点用户请求会被路由到地理上最近的节点执行网络往返通常只有几十毫秒。Workers 的冷启动是毫秒级的因为底层用的是 V8 isolate 而不是容器启动一个 isolate 比启动一个进程快几个数量级。状态方面Durable Objects 提供了单点强一致的有状态对象KV 提供最终一致的键值存储D1 是 SQLite 兼容的关系库R2 是对象存储。这些都以 binding 的形式直接挂在 Worker 里调用就像调本地函数。我实测过一个场景同一个 Agent 逻辑一份部署在新加坡的容器上一份部署在 Workers 上国内用户访问首字节时间TTFB从 400ms 左右降到 80ms 上下。这个差距在对话式产品里是能明显感知到的。2.3 成本账要算清楚别被免费额度冲昏头Workers 有免费额度但 Agent 场景很容易超。免费版每天 10 万次请求付费版 5 美元起包含 1000 万次请求。听起来很多但 Agent 一次对话可能触发多次 Worker 调用一次主逻辑、几次工具调用、几次模型请求实际消耗要乘以一个系数。真正的大头是模型调用费用和Durable Objects 的时长费。Durable Objects 按请求数 持续时长GB-s计费如果你的 Agent 在里面做长时间的流式输出时长费会累积。我的经验是把无状态的逻辑放 Worker把必须持久的状态放 Durable Object且尽量缩短 DO 的持有时间。比如流式响应可以让 Worker 直接转发模型返回的流不要全程占着 DO。提示上线前一定要用真实流量压一遍把 Worker 请求数、DO 时长、KV 读写、模型 token 四个维度的账单都估出来。我见过有人只算了模型费用结果 DO 时长费比模型费还高。3. 用 Workers 搭 Agent 的骨架请求进来之后发生了什么3.1 一次 Agent 请求的完整链路我把一个最小可用的 Agent 拆成四层从外到内分别是接入层、编排层、能力层、状态层。接入层就是 Worker 的fetch入口负责鉴权、限流、解析请求。编排层是 Agent 的大脑决定这一轮要不要调工具、调哪个、怎么把结果拼回给模型。能力层是各种工具搜索、计算、数据库查询、外部 API。状态层是记忆用 Durable Objects 或 KV 存。一次典型请求的流程是这样的用户发消息 → Worker 入口鉴权 → 从 DO 取出该会话的历史 → 把历史 新消息 工具定义发给模型 → 模型返回我要调用某工具 → Worker 执行工具 → 把工具结果再发给模型 → 模型生成最终回复 → 写回 DO → 流式返回给用户。这个循环可能重复多次取决于模型要调几个工具。关键设计点是整个循环要在一次 Worker 请求的生命周期内完成还是拆成多次我的建议是尽量在一次请求内完成因为拆开需要额外的状态传递和唤醒机制复杂度陡增。Workers 单次请求有 CPU 时间限制付费版默认 30 秒可调对于大多数 Agent 循环够用。3.2 为什么选 Durable Objects 做记忆Agent 的记忆有两个层次短期记忆当前会话的对话历史和长期记忆跨会话的用户画像、事实知识。短期记忆我强烈建议用 Durable Objects。原因是 DO 提供单点串行语义——同一个会话 ID 的请求会被路由到同一个 DO 实例天然避免了并发写冲突。你想想如果用户快速连发两条消息用 KV 或数据库可能两条同时读到旧历史导致上下文错乱。DO 的串行执行保证了一条处理完再处理下一条。长期记忆可以用 Vectorize向量数据库做语义检索或者用 D1 存结构化的事实。我一般把用户明确表达的偏好我不吃辣存 D1把需要语义匹配的知识存 Vectorize。// 简化的 DO 结构管理单个会话的记忆 export class SessionMemory { constructor(state, env) { this.state state; this.env env; this.history []; } async fetch(request) { const { message } await request.json(); // 取出历史追加新消息 this.history.push({ role: user, content: message }); // 只保留最近 N 轮控制 token 消耗 if (this.history.length 20) { this.history this.history.slice(-20); } return new Response(JSON.stringify(this.history)); } }这段代码里有个细节值得说为什么要截断历史。模型的上下文窗口是有限的而且 token 是要花钱的。保留最近 20 轮是个经验值更聪明的做法是做摘要——把更早的对话压缩成一段摘要存起来需要时再拼进去。这个摘要动作可以异步做不阻塞主流程。3.3 工具调用怎么组织才不乱Agent 的工具越多编排层越容易变成一坨面条代码。我的做法是用注册表模式每个工具是一个对象包含名称、描述、参数 schema 和执行函数统一注册到一个 map 里。模型返回工具调用请求时按名称查表执行。const tools { get_weather: { description: 查询指定城市的天气, parameters: { city: string }, async run({ city }) { const res await fetch(https://api.example.com/weather?city${city}); return await res.json(); } }, // 其他工具... }; async function executeTool(name, args) { const tool tools[name]; if (!tool) throw new Error(未知工具: ${name}); return await tool.run(args); }这样加工具就是往 map 里加一项编排逻辑完全不用改。注意工具的 description 要写得足够清楚模型靠它来决定调不调、怎么调。我踩过的坑是 description 写得太模糊模型该调的时候不调不该调的时候乱调。4. 把模型接进来AI Gateway 与多模型协作的取舍4.1 直连模型 API 还是走 AI GatewayCloudflare 有个 AI Gateway作用是代理你对各家模型 API 的调用提供缓存、限流、重试、日志、成本统计。要不要用我的答案是生产环境建议用本地调试可以直连。用 Gateway 的好处很实在一是缓存相同 prompt 的请求可以直接返回缓存结果省钱又提速对于 FAQ 类场景命中率很高二是可观测所有请求的延迟、token 消耗、错误率都有面板出问题好排查三是多模型切换你可以在 Gateway 层配置 fallback主模型挂了自动切备用。代价是多一跳网络延迟通常几十毫秒可以接受。配置上你在 Gateway 里建一个 endpoint拿到 URLWorker 里正常 fetch 就行。4.2 多模型协作的实际玩法热搜里多ai协作是个高频词。在 Agent 场景里多模型协作不是噱头是有实际价值的。我常用的两种模式模式一大小模型分工。用便宜的小模型做意图识别和路由判断用户这句话是要查天气、要闲聊、还是要执行复杂任务然后决定用哪个模型处理。这样大部分简单请求走小模型成本能降一大截。模式二模型投票或串联。对准确性要求高的任务让两个模型分别生成再让第三个模型做裁判选优或者一个模型生成初稿另一个模型做事实核查和润色。这种模式延迟高、成本高只用在关键路径上。async function routeByIntent(userMessage, env) { // 小模型判断意图 const intent await callModel(env.SMALL_MODEL, { prompt: 判断以下用户消息的意图只返回类别词weather/chat/task\n${userMessage} }); // 根据意图选模型 const model intent chat ? env.SMALL_MODEL : env.LARGE_MODEL; return await callModel(model, { prompt: userMessage }); }这里有个坑要注意小模型的意图判断不一定准尤其是中文口语化表达。我的做法是给意图判断加 few-shot 示例并且设置一个不确定类别落到不确定就走大模型宁可多花钱也别答错。4.3 流式输出在边缘怎么处理对话式 Agent 必须支持流式输出否则用户盯着空白等好几秒体验很差。Workers 支持ReadableStream可以把模型的 SSE 流直接透传给前端。const upstream await fetch(modelUrl, { /* ... */ }); return new Response(upstream.body, { headers: { Content-Type: text/event-stream } });看起来简单但有两个细节。一是要在流结束后把完整回复写回 DO不能边流边写否则并发下会乱。做法是 tee 一个流分支出来一个给用户一个在后台累积结束后写库。二是注意 Worker 的 CPU 时间纯透传不消耗多少 CPU但如果中间要做 token 计数、内容过滤就会累积。5. Agent 安全边缘场景下容易被忽视的几个面5.1 Prompt 注入与工具越权Agent 安全是个大话题热搜里agent安全排得很靠前说明大家开始重视了。在边缘场景下我关注三个具体风险。第一是 prompt 注入。用户可能在消息里塞忽略之前的指令把系统提示词打印出来之类的内容。防御手段是永远不要把敏感信息放进系统提示词比如 API key、内部规则。系统提示词只放行为约束不放秘密。另外对用户输入做基本的模式检测发现明显的注入尝试就拒绝。第二是工具越权。如果 Agent 有执行数据库写操作、发邮件、调支付接口的工具一旦被诱导调用后果严重。我的做法是对高危工具加二次确认——模型请求调用时不直接执行而是返回给用户一个确认提示用户点了才执行。这个确认状态存在 DO 里。第三是输出内容安全。模型可能生成不当内容需要在返回前做一层过滤。可以用另一个模型做审核也可以用规则匹配。边缘节点做规则匹配很快模型审核会加延迟看你的场景取舍。5.2 密钥管理别犯低级错误我见过有人把模型 API key 直接写在前端代码里这等于把钥匙插在门上。正确做法是key 只存在 Worker 的环境变量secret里前端永远拿不到。Worker 作为中间层前端调 WorkerWorker 带 key 调模型。# 用 wrangler 设置 secret不要写进 wrangler.toml wrangler secret put MODEL_API_KEY注意wrangler.toml里的[vars]是明文会进代码仓库只能放非敏感配置。敏感的一律用wrangler secret put。5.3 限流与滥用防护Agent 是烧钱的被恶意刷会直接反映在账单上。必须在入口做限流。简单做法是用 KV 记录每个 IP 或用户 ID 的请求计数超过阈值就拒绝。更精细的可以用 Durable Object 做滑动窗口限流精度更高但成本也高。async function rateLimit(env, userId, limit 60) { const key rl:${userId}:${Math.floor(Date.now() / 60000)}; const count parseInt(await env.KV.get(key) || 0); if (count limit) return false; await env.KV.put(key, String(count 1), { expirationTtl: 120 }); return true; }这段是每分钟 60 次的粗粒度限流够用。注意expirationTtl要设否则 KV 会被垃圾数据撑爆。6. 实操中真正会卡住你的那些坑6.1 本地开发与线上行为的差异wrangler dev本地跑起来很顺一上线就出问题这是最常见的抱怨。原因通常是本地模拟和真实环境有差异。比如本地 KV 是内存模拟线上是分布式存储读写延迟和一致性行为不一样。DO 在本地是单进程模拟线上是真正的分布式对象。我的建议是关键路径一定要在预发布环境staging用真实资源测一遍。Cloudflare 支持多环境配置在wrangler.toml里配不同的环境用wrangler deploy --env staging部署。别省这一步我因为跳过它踩过 DO 并发行为的坑本地怎么测都对线上偶发数据错乱。6.2 冷启动与 isolate 复用Workers 冷启动很快但不是零。而且 isolate 会被复用这意味着模块级变量会跨请求保留。这既是优化机会也是陷阱。优化机会可以把模型客户端、配置对象在模块级初始化一次后续请求复用省去重复创建的开销。陷阱如果你在模块级存了用户相关的状态会串数据。我见过有人在模块级缓存了当前用户结果 A 用户的请求读到了 B 用户的数据。规则很简单模块级只放无状态的、所有用户共享的东西用户相关的状态一律放请求作用域或 DO。6.3 超时与重试的正确姿势Agent 调模型可能超时网络抖动也可能失败。重试是必须的但无脑重试会放大问题。我的策略是只对幂等的操作重试比如读模型、查天气对写操作比如扣费、发消息不自动重试避免重复执行。重试用指数退避第一次等 200ms第二次 400ms最多三次。async function retry(fn, times 3) { for (let i 0; i times; i) { try { return await fn(); } catch (e) { if (i times - 1) throw e; await new Promise(r setTimeout(r, 200 * Math.pow(2, i))); } } }另外要注意 Worker 本身的执行时间上限重试加上模型调用可能撞上限。如果任务确实长考虑用 Queues 把任务异步化Worker 只负责入队和返回处理中。6.4 可观测性出问题怎么查边缘环境最大的挑战是你看不到服务器出问题只能靠日志和指标。我的做法是所有关键节点打结构化日志JSON 格式包含请求 ID、用户 ID、耗时、模型 token 数。用console.log输出Cloudflare 的日志面板能按请求 ID 串起来。const reqId crypto.randomUUID(); console.log(JSON.stringify({ reqId, event: model_call_start, model: xxx })); // ... 调用 console.log(JSON.stringify({ reqId, event: model_call_end, ms: 1200, tokens: 350 }));有了请求 ID排查问题时能完整还原一次请求的链路。这个习惯我从第一天就养成了省了无数排查时间。7. 我对这套方案的真实判断用 Cloudflare 这套边缘操作系统跑 AI Agent我的整体判断是适合中小规模、对延迟敏感、不想碰运维的团队不适合需要复杂长任务编排、需要 GPU 本地推理、或者对数据驻留有硬性要求的场景。它的甜点区是对话式 Agent、轻量工具调用、需要全球低延迟接入、团队没有专职运维。它的边界是单次请求 CPU 时间有限长任务要拆没有本地 GPU模型必须走外部 API状态虽然能持久化但复杂事务支持不如传统数据库。我自己的几个小项目跑下来最省心的是部署即上线——wrangler deploy一条命令全球生效不用管服务器、不用管证书、不用管扩容。最需要花心思的是成本控制和状态设计这两块设计不好账单和 bug 都会教你做人。如果你正准备动手我的建议是先做一个最小闭环一个 Worker 入口 一个 DO 存历史 一次模型调用 一个工具。跑通之后再逐步加记忆、加多模型、加安全防护。别一上来就设计一个全能 Agent 框架那大概率会烂尾。先把一条链路跑顺比什么都重要。 Cloudflare Workers 边缘运行时构建 AI Agent 实战指南
1. 从cloudflare-os这个标题说起它到底在指什么第一次看到cloudflare-os这个词我下意识以为是 Cloudflare 官方又出了什么操作系统级别的产品。翻了一圈资料才反应过来这其实是一个社区里流传的、带点戏谑意味的说法——它并不是一个真正的操作系统内核而是把 Cloudflare 那一整套边缘计算能力Workers、Durable Objects、KV、R2、D1、Queues、AI Gateway 等等当成操作系统来用的一种心智模型。你写的是 JavaScript 或 TypeScript跑在全球几百个边缘节点上没有服务器要运维没有容器要编排状态、存储、队列、模型调用全都通过绑定binding挂进来。从这个角度看它确实像一套操作系统你负责写业务逻辑底层调度、扩缩容、就近接入全交给平台。这个标题背后真正值得聊的是Cloudflare Workers 作为 AI Agent 运行时的可行性。热搜词里agent、agent开发、agent架构、agent框架、agent记忆、agent安全反复出现说明大家现在最关心的不是能不能跑一个函数而是能不能把一整个有记忆、有工具调用、有编排能力的智能体塞进边缘。我过去大半年在这个方向上做了几个小项目踩的坑不算少这篇就把我的完整思路、选型理由、实操步骤和那些文档里不会写的教训一次性摊开讲。先说清楚适合谁看如果你已经会写一点 JavaScript/TypeScript对 HTTP、API 调用不陌生想搭一个低延迟、免运维、成本可控的 AI Agent 后端那这篇对你有用。如果你完全没接触过边缘计算也没关系我会把关键概念用生活化的方式讲明白。全文围绕一个核心问题展开——用 Cloudflare 这套边缘操作系统来承载 AI Agent到底该怎么设计、怎么落地、哪些地方会翻车。2. 为什么把 Agent 放到边缘延迟、成本与运维的三重账2.1 传统 Agent 后端的三个痛点大部分人搭 AI Agent 的第一反应是买台云服务器装个 Node 或 Python 服务接上大模型 API再配个数据库存对话历史。这套方案能跑但跑起来之后问题一个接一个。第一个痛点是延迟。Agent 的核心体验是对话感用户发一句话希望一两秒内看到回应。但你的服务器可能在美国东部用户在国内光网络往返就两三百毫秒再加上模型推理时间体验直接崩。你可能会说那我多区域部署好那运维复杂度立刻上一个台阶。第二个痛点是冷启动和扩缩容。Agent 的流量往往不是平稳的可能白天没人用晚上突然来一波。传统容器冷启动动辄几秒用户等不起。你要预热、要做弹性伸缩策略这些都是纯成本。第三个痛点是状态管理。Agent 需要记忆——对话历史、用户偏好、工具调用中间结果。传统做法是接一个 Redis 或 Postgres又多了两个要运维的组件还得考虑它们和计算节点的网络延迟。2.2 边缘运行时给出的答案Cloudflare Workers 这套东西恰好在这三点上都有针对性设计。它在全球部署了大量节点用户请求会被路由到地理上最近的节点执行网络往返通常只有几十毫秒。Workers 的冷启动是毫秒级的因为底层用的是 V8 isolate 而不是容器启动一个 isolate 比启动一个进程快几个数量级。状态方面Durable Objects 提供了单点强一致的有状态对象KV 提供最终一致的键值存储D1 是 SQLite 兼容的关系库R2 是对象存储。这些都以 binding 的形式直接挂在 Worker 里调用就像调本地函数。我实测过一个场景同一个 Agent 逻辑一份部署在新加坡的容器上一份部署在 Workers 上国内用户访问首字节时间TTFB从 400ms 左右降到 80ms 上下。这个差距在对话式产品里是能明显感知到的。2.3 成本账要算清楚别被免费额度冲昏头Workers 有免费额度但 Agent 场景很容易超。免费版每天 10 万次请求付费版 5 美元起包含 1000 万次请求。听起来很多但 Agent 一次对话可能触发多次 Worker 调用一次主逻辑、几次工具调用、几次模型请求实际消耗要乘以一个系数。真正的大头是模型调用费用和Durable Objects 的时长费。Durable Objects 按请求数 持续时长GB-s计费如果你的 Agent 在里面做长时间的流式输出时长费会累积。我的经验是把无状态的逻辑放 Worker把必须持久的状态放 Durable Object且尽量缩短 DO 的持有时间。比如流式响应可以让 Worker 直接转发模型返回的流不要全程占着 DO。提示上线前一定要用真实流量压一遍把 Worker 请求数、DO 时长、KV 读写、模型 token 四个维度的账单都估出来。我见过有人只算了模型费用结果 DO 时长费比模型费还高。3. 用 Workers 搭 Agent 的骨架请求进来之后发生了什么3.1 一次 Agent 请求的完整链路我把一个最小可用的 Agent 拆成四层从外到内分别是接入层、编排层、能力层、状态层。接入层就是 Worker 的fetch入口负责鉴权、限流、解析请求。编排层是 Agent 的大脑决定这一轮要不要调工具、调哪个、怎么把结果拼回给模型。能力层是各种工具搜索、计算、数据库查询、外部 API。状态层是记忆用 Durable Objects 或 KV 存。一次典型请求的流程是这样的用户发消息 → Worker 入口鉴权 → 从 DO 取出该会话的历史 → 把历史 新消息 工具定义发给模型 → 模型返回我要调用某工具 → Worker 执行工具 → 把工具结果再发给模型 → 模型生成最终回复 → 写回 DO → 流式返回给用户。这个循环可能重复多次取决于模型要调几个工具。关键设计点是整个循环要在一次 Worker 请求的生命周期内完成还是拆成多次我的建议是尽量在一次请求内完成因为拆开需要额外的状态传递和唤醒机制复杂度陡增。Workers 单次请求有 CPU 时间限制付费版默认 30 秒可调对于大多数 Agent 循环够用。3.2 为什么选 Durable Objects 做记忆Agent 的记忆有两个层次短期记忆当前会话的对话历史和长期记忆跨会话的用户画像、事实知识。短期记忆我强烈建议用 Durable Objects。原因是 DO 提供单点串行语义——同一个会话 ID 的请求会被路由到同一个 DO 实例天然避免了并发写冲突。你想想如果用户快速连发两条消息用 KV 或数据库可能两条同时读到旧历史导致上下文错乱。DO 的串行执行保证了一条处理完再处理下一条。长期记忆可以用 Vectorize向量数据库做语义检索或者用 D1 存结构化的事实。我一般把用户明确表达的偏好我不吃辣存 D1把需要语义匹配的知识存 Vectorize。// 简化的 DO 结构管理单个会话的记忆 export class SessionMemory { constructor(state, env) { this.state state; this.env env; this.history []; } async fetch(request) { const { message } await request.json(); // 取出历史追加新消息 this.history.push({ role: user, content: message }); // 只保留最近 N 轮控制 token 消耗 if (this.history.length 20) { this.history this.history.slice(-20); } return new Response(JSON.stringify(this.history)); } }这段代码里有个细节值得说为什么要截断历史。模型的上下文窗口是有限的而且 token 是要花钱的。保留最近 20 轮是个经验值更聪明的做法是做摘要——把更早的对话压缩成一段摘要存起来需要时再拼进去。这个摘要动作可以异步做不阻塞主流程。3.3 工具调用怎么组织才不乱Agent 的工具越多编排层越容易变成一坨面条代码。我的做法是用注册表模式每个工具是一个对象包含名称、描述、参数 schema 和执行函数统一注册到一个 map 里。模型返回工具调用请求时按名称查表执行。const tools { get_weather: { description: 查询指定城市的天气, parameters: { city: string }, async run({ city }) { const res await fetch(https://api.example.com/weather?city${city}); return await res.json(); } }, // 其他工具... }; async function executeTool(name, args) { const tool tools[name]; if (!tool) throw new Error(未知工具: ${name}); return await tool.run(args); }这样加工具就是往 map 里加一项编排逻辑完全不用改。注意工具的 description 要写得足够清楚模型靠它来决定调不调、怎么调。我踩过的坑是 description 写得太模糊模型该调的时候不调不该调的时候乱调。4. 把模型接进来AI Gateway 与多模型协作的取舍4.1 直连模型 API 还是走 AI GatewayCloudflare 有个 AI Gateway作用是代理你对各家模型 API 的调用提供缓存、限流、重试、日志、成本统计。要不要用我的答案是生产环境建议用本地调试可以直连。用 Gateway 的好处很实在一是缓存相同 prompt 的请求可以直接返回缓存结果省钱又提速对于 FAQ 类场景命中率很高二是可观测所有请求的延迟、token 消耗、错误率都有面板出问题好排查三是多模型切换你可以在 Gateway 层配置 fallback主模型挂了自动切备用。代价是多一跳网络延迟通常几十毫秒可以接受。配置上你在 Gateway 里建一个 endpoint拿到 URLWorker 里正常 fetch 就行。4.2 多模型协作的实际玩法热搜里多ai协作是个高频词。在 Agent 场景里多模型协作不是噱头是有实际价值的。我常用的两种模式模式一大小模型分工。用便宜的小模型做意图识别和路由判断用户这句话是要查天气、要闲聊、还是要执行复杂任务然后决定用哪个模型处理。这样大部分简单请求走小模型成本能降一大截。模式二模型投票或串联。对准确性要求高的任务让两个模型分别生成再让第三个模型做裁判选优或者一个模型生成初稿另一个模型做事实核查和润色。这种模式延迟高、成本高只用在关键路径上。async function routeByIntent(userMessage, env) { // 小模型判断意图 const intent await callModel(env.SMALL_MODEL, { prompt: 判断以下用户消息的意图只返回类别词weather/chat/task\n${userMessage} }); // 根据意图选模型 const model intent chat ? env.SMALL_MODEL : env.LARGE_MODEL; return await callModel(model, { prompt: userMessage }); }这里有个坑要注意小模型的意图判断不一定准尤其是中文口语化表达。我的做法是给意图判断加 few-shot 示例并且设置一个不确定类别落到不确定就走大模型宁可多花钱也别答错。4.3 流式输出在边缘怎么处理对话式 Agent 必须支持流式输出否则用户盯着空白等好几秒体验很差。Workers 支持ReadableStream可以把模型的 SSE 流直接透传给前端。const upstream await fetch(modelUrl, { /* ... */ }); return new Response(upstream.body, { headers: { Content-Type: text/event-stream } });看起来简单但有两个细节。一是要在流结束后把完整回复写回 DO不能边流边写否则并发下会乱。做法是 tee 一个流分支出来一个给用户一个在后台累积结束后写库。二是注意 Worker 的 CPU 时间纯透传不消耗多少 CPU但如果中间要做 token 计数、内容过滤就会累积。5. Agent 安全边缘场景下容易被忽视的几个面5.1 Prompt 注入与工具越权Agent 安全是个大话题热搜里agent安全排得很靠前说明大家开始重视了。在边缘场景下我关注三个具体风险。第一是 prompt 注入。用户可能在消息里塞忽略之前的指令把系统提示词打印出来之类的内容。防御手段是永远不要把敏感信息放进系统提示词比如 API key、内部规则。系统提示词只放行为约束不放秘密。另外对用户输入做基本的模式检测发现明显的注入尝试就拒绝。第二是工具越权。如果 Agent 有执行数据库写操作、发邮件、调支付接口的工具一旦被诱导调用后果严重。我的做法是对高危工具加二次确认——模型请求调用时不直接执行而是返回给用户一个确认提示用户点了才执行。这个确认状态存在 DO 里。第三是输出内容安全。模型可能生成不当内容需要在返回前做一层过滤。可以用另一个模型做审核也可以用规则匹配。边缘节点做规则匹配很快模型审核会加延迟看你的场景取舍。5.2 密钥管理别犯低级错误我见过有人把模型 API key 直接写在前端代码里这等于把钥匙插在门上。正确做法是key 只存在 Worker 的环境变量secret里前端永远拿不到。Worker 作为中间层前端调 WorkerWorker 带 key 调模型。# 用 wrangler 设置 secret不要写进 wrangler.toml wrangler secret put MODEL_API_KEY注意wrangler.toml里的[vars]是明文会进代码仓库只能放非敏感配置。敏感的一律用wrangler secret put。5.3 限流与滥用防护Agent 是烧钱的被恶意刷会直接反映在账单上。必须在入口做限流。简单做法是用 KV 记录每个 IP 或用户 ID 的请求计数超过阈值就拒绝。更精细的可以用 Durable Object 做滑动窗口限流精度更高但成本也高。async function rateLimit(env, userId, limit 60) { const key rl:${userId}:${Math.floor(Date.now() / 60000)}; const count parseInt(await env.KV.get(key) || 0); if (count limit) return false; await env.KV.put(key, String(count 1), { expirationTtl: 120 }); return true; }这段是每分钟 60 次的粗粒度限流够用。注意expirationTtl要设否则 KV 会被垃圾数据撑爆。6. 实操中真正会卡住你的那些坑6.1 本地开发与线上行为的差异wrangler dev本地跑起来很顺一上线就出问题这是最常见的抱怨。原因通常是本地模拟和真实环境有差异。比如本地 KV 是内存模拟线上是分布式存储读写延迟和一致性行为不一样。DO 在本地是单进程模拟线上是真正的分布式对象。我的建议是关键路径一定要在预发布环境staging用真实资源测一遍。Cloudflare 支持多环境配置在wrangler.toml里配不同的环境用wrangler deploy --env staging部署。别省这一步我因为跳过它踩过 DO 并发行为的坑本地怎么测都对线上偶发数据错乱。6.2 冷启动与 isolate 复用Workers 冷启动很快但不是零。而且 isolate 会被复用这意味着模块级变量会跨请求保留。这既是优化机会也是陷阱。优化机会可以把模型客户端、配置对象在模块级初始化一次后续请求复用省去重复创建的开销。陷阱如果你在模块级存了用户相关的状态会串数据。我见过有人在模块级缓存了当前用户结果 A 用户的请求读到了 B 用户的数据。规则很简单模块级只放无状态的、所有用户共享的东西用户相关的状态一律放请求作用域或 DO。6.3 超时与重试的正确姿势Agent 调模型可能超时网络抖动也可能失败。重试是必须的但无脑重试会放大问题。我的策略是只对幂等的操作重试比如读模型、查天气对写操作比如扣费、发消息不自动重试避免重复执行。重试用指数退避第一次等 200ms第二次 400ms最多三次。async function retry(fn, times 3) { for (let i 0; i times; i) { try { return await fn(); } catch (e) { if (i times - 1) throw e; await new Promise(r setTimeout(r, 200 * Math.pow(2, i))); } } }另外要注意 Worker 本身的执行时间上限重试加上模型调用可能撞上限。如果任务确实长考虑用 Queues 把任务异步化Worker 只负责入队和返回处理中。6.4 可观测性出问题怎么查边缘环境最大的挑战是你看不到服务器出问题只能靠日志和指标。我的做法是所有关键节点打结构化日志JSON 格式包含请求 ID、用户 ID、耗时、模型 token 数。用console.log输出Cloudflare 的日志面板能按请求 ID 串起来。const reqId crypto.randomUUID(); console.log(JSON.stringify({ reqId, event: model_call_start, model: xxx })); // ... 调用 console.log(JSON.stringify({ reqId, event: model_call_end, ms: 1200, tokens: 350 }));有了请求 ID排查问题时能完整还原一次请求的链路。这个习惯我从第一天就养成了省了无数排查时间。7. 我对这套方案的真实判断用 Cloudflare 这套边缘操作系统跑 AI Agent我的整体判断是适合中小规模、对延迟敏感、不想碰运维的团队不适合需要复杂长任务编排、需要 GPU 本地推理、或者对数据驻留有硬性要求的场景。它的甜点区是对话式 Agent、轻量工具调用、需要全球低延迟接入、团队没有专职运维。它的边界是单次请求 CPU 时间有限长任务要拆没有本地 GPU模型必须走外部 API状态虽然能持久化但复杂事务支持不如传统数据库。我自己的几个小项目跑下来最省心的是部署即上线——wrangler deploy一条命令全球生效不用管服务器、不用管证书、不用管扩容。最需要花心思的是成本控制和状态设计这两块设计不好账单和 bug 都会教你做人。如果你正准备动手我的建议是先做一个最小闭环一个 Worker 入口 一个 DO 存历史 一次模型调用 一个工具。跑通之后再逐步加记忆、加多模型、加安全防护。别一上来就设计一个全能 Agent 框架那大概率会烂尾。先把一条链路跑顺比什么都重要。