1. 从标题到落地cloudflare-os 到底想解决什么问题第一次看到cloudflare-os这个标题我下意识以为又是一个把 Linux 塞进浏览器的玩具项目。真正翻完它的设计思路和代码结构之后才发现这东西的野心根本不在“模拟操作系统”上而是在回答一个更实际的问题当 AI agent 需要长期在线、需要记忆、需要多任务协作时它到底该跑在哪里传统做法是把 agent 跑在本地进程里或者丢到一台 VPS 上。本地进程的问题是关机就断VPS 的问题是运维成本高、冷启动慢、还要自己处理持久化和扩缩容。cloudflare-os给出的答案很直接——把 agent 的运行时、记忆层、任务调度全部压到 Cloudflare Workers 这套边缘计算体系上用 Durable Objects 做状态用 Workers 做无服务器执行用 R2 或 KV 做持久化存储。整个“操作系统”其实是一层抽象把边缘节点包装成一个 agent 可以常驻、可以互相通信、可以共享记忆的运行环境。这个定位决定了它的目标读者非常明确已经在写 agent、但被部署和状态管理折磨过的开发者。如果你只是想让 AI 帮你写个周报那完全用不上它但如果你在做多 agent 协作、需要 agent 7x24 在线、需要跨会话记忆、需要给 agent 分配“技能”和“工具”那这套东西值得认真看一遍。它解决的不是“AI 能不能思考”而是“AI 思考完之后状态存在哪、下次怎么接着用、多个 agent 怎么不打架”。我把它理解成一个面向 agent 的边缘运行时框架。核心关键词里出现的Cloudflare Workers、agent、pnpm、agent 架构、agent 记忆基本覆盖了它的技术栈全貌。下面我会按“设计思路 → 核心机制 → 实操落地 → 踩坑排查”的顺序把我在复现过程中摸清楚的东西完整讲一遍。2. 整体设计思路为什么是边缘 Durable Objects2.1 把 agent 当“有状态服务”而不是“函数”来设计大多数 serverless 思路是把一切当成无状态函数请求进来算完返回进程销毁。这个模型对普通 API 很友好但对 agent 是灾难。因为 agent 的核心价值恰恰在于它有记忆、有上下文、有持续的任务队列。你今天让它查的资料明天它还应该记得它正在执行的长任务不能因为一次请求结束就被清空。cloudflare-os的关键设计决策就是引入Durable Objects作为 agent 的“宿主”。每个 agent 实例对应一个 Durable Object这个对象有唯一 ID、有持久化存储、有单线程执行保证。这意味着agent 的状态天然持久不需要你额外接 Redis 或数据库同一个 agent 的请求会被串行处理不会出现两个请求同时改同一份记忆导致覆盖agent 可以主动发起定时任务通过 Alarms实现“每隔一段时间自己醒来干活”。这个选择背后的逻辑很清晰agent 本质是一个长期存活的有状态实体而不是一次性的计算任务。用 Durable Objects 来承载它比自己在 VPS 上维护进程要省心得多也比纯 KV 存储多了并发安全保证。2.2 边缘节点带来的延迟优势与“就近唤醒”把 agent 放在边缘节点上最直接的好处是延迟。用户在东京发起请求agent 就在东京附近的节点响应不用绕到某个中心机房。对于需要多轮对话、频繁工具调用的 agent 来说每一轮省几十毫秒累积起来体验差别很明显。但更关键的是就近唤醒这个特性。传统 VPS 上跑 agent你得考虑它部署在哪个区域用户离得远就慢。边缘运行时天然把 agent 的“入口”铺到全球用户从哪来就在哪唤醒。对于做多地区服务的团队这一点省掉了大量区域部署的麻烦。2.3 用 Workers 做“技能层”实现 agent 能力的模块化cloudflare-os里另一个我觉得很聪明的设计是把 agent 的“技能”拆成独立的 Workers。每个技能就是一个小的 Worker 函数负责一类具体能力比如查天气、读文档、调外部 API。agent 主逻辑通过绑定Bindings去调用这些技能 Worker。这样做的好处是技能可以独立部署和更新改一个技能不用动 agent 主体技能可以复用多个 agent 共享同一套技能 Worker权限边界清晰每个技能 Worker 能访问什么资源由绑定决定天然做了隔离。这其实呼应了热词里的agent skill 教程和agent 架构。很多人做 agent 时把所有工具函数塞在一个大文件里后期维护极其痛苦。拆成独立 Worker 之后架构一下子清爽了。2.4 为什么用 pnpm 而不是 npm项目用 pnpm 作为包管理器这不是随便选的。Cloudflare Workers 项目通常依赖较多且需要 monorepo 管理多个 Worker 和共享包。pnpm 的硬链接机制让node_modules体积小很多安装速度快而且对 monorepo 的 workspace 支持比 npm 成熟。热词里出现pnpm 下载失败、pnpm 不是内部或外部命令、pnpm 离线安装说明不少人在第一步就卡住了。这个我后面会专门讲怎么处理。3. 核心机制拆解记忆、调度与多 agent 协作3.1 agent 记忆是怎么存的cloudflare-os的记忆层分两部分短期上下文和长期记忆。短期上下文就是当前会话的消息历史存在 Durable Object 的内存里会话结束或超时后可以落盘。长期记忆则写进 Durable Object 的持久化存储底层是 SQLite按 key 组织。常见的做法是把对话摘要、用户偏好、任务结果按memory:{agentId}:{type}:{key}的格式存检索时按前缀扫描或者用向量检索如果接了 Vectorize。这里有个实操细节Durable Object 的存储有单次读写大小限制单条 value 不能太大。所以长文本记忆要分片存或者只存摘要 原文放 R2。我一开始把整篇文档塞进一条记录结果写入直接失败排查了半天才反应过来是大小限制。3.2 定时任务与“agent 自己醒来”Durable Objects 支持 Alarms可以设定某个时间点唤醒自己。cloudflare-os用它来实现 agent 的主动行为比如每隔一小时检查一次任务队列到点提醒用户定期整理和压缩记忆。这个机制让 agent 从“被动响应”变成“主动工作”。实现上就是在 Durable Object 里设置storage.setAlarm(timestamp)然后在alarm()方法里写唤醒逻辑。注意Alarms 不是精确定时边缘节点负载高时可能延迟几秒到几十秒做提醒类功能要留余量。3.3 多 agent 协作怎么不打架多 agent 协作是热词里多 ai 协作、agent 架构的核心关注点。cloudflare-os的做法是给每个 agent 一个唯一 IDagent 之间通过消息传递通信而不是共享内存。一个 agent 要调用另一个 agent就发一条消息到对方的 Durable Object对方处理完再回消息。这样做的好处是隔离性好一个 agent 崩了不会拖垮其他 agent。代价是通信有延迟且需要设计好消息协议。我建议消息格式至少包含发送方 ID、接收方 ID、消息类型、payload、时间戳、是否需要回复。少了这些字段后期调试会非常痛苦。3.4 工具调用与安全边界agent 调用外部工具时cloudflare-os通过 Workers 的绑定机制限制它能访问什么。比如一个只负责查天气的技能 Worker就不给它绑定数据库它想访问也访问不了。这是最小权限原则在 agent 架构里的落地。热词里有agent 安全这块确实值得重视。agent 一旦能自由调用外部 API就可能被提示注入攻击利用。我的经验是所有工具调用的参数都要做校验尤其是涉及写操作和外部请求的。不要让 agent 的输出直接拼进 SQL 或 shell 命令。4. 实操落地从零把 cloudflare-os 跑起来4.1 环境准备与 pnpm 安装避坑第一步就是装 pnpm。热词里大量pnpm 不是内部或命令、pnpm 下载失败的问题基本都是环境没配好。标准做法# 用 corepack 启用 pnpmNode 16.13 自带 corepack enable corepack prepare pnpmlatest --activate # 或者用 npm 全局装 npm install -g pnpm # 验证 pnpm -v如果提示pnpm 不是内部或外部命令八成是 npm 全局 bin 目录没加进 PATH。Windows 上执行npm config get prefix拿到路径手动加进系统环境变量。Ubuntu 上通常是/usr/local/bin或~/.local/share/pnpm检查~/.bashrc里有没有对应的 export。pnpm 离线安装的场景可以先用pnpm store path找到 store 目录把依赖缓存拷过去再pnpm install --offline。这个在隔离环境里很有用。4.2 项目初始化与依赖安装# 克隆项目 git clone repo-url cloudflare-os cd cloudflare-os # 安装依赖 pnpm install # 如果遇到 peer dependency 警告不要盲目 --force # 先看清楚是哪个包冲突多数情况是版本没对齐安装完成后检查wrangler.toml这是 Cloudflare Workers 的配置文件。重点看几个字段字段作用常见坑nameWorker 名称不能和已有 Worker 重名main入口文件路径写错会直接构建失败compatibility_date兼容日期太旧会导致新 API 不可用durable_objectsDO 绑定忘记配 migrations 会报错kv_namespacesKV 绑定id 要填真实的不能留空4.3 Durable Object 的迁移配置Durable Objects 需要 migrations 配置否则部署时会报“no migration found”。格式大致如下[[migrations]] tag v1 new_classes [AgentHost]每次新增或重命名 DO 类都要加一条新 migrationtag 不能重复。我踩过的坑是改了 DO 类名但没加 migration本地wrangler dev能跑一部署就失败。本地和线上行为不一致时优先检查 migrations。4.4 本地开发与调试# 启动本地开发服务器 pnpm wrangler dev # 指定端口 pnpm wrangler dev --port 8787 # 本地模式下 DO 和 KV 都是模拟的数据不持久 # 需要持久化本地数据用 --persist pnpm wrangler dev --persist调试 agent 逻辑时我习惯在关键路径打日志用wrangler tail看线上实时日志pnpm wrangler tail --format pretty这个命令能实时看到线上 Worker 的 console 输出排查线上问题时比翻日志平台快得多。4.5 部署与密钥管理# 登录 pnpm wrangler login # 部署 pnpm wrangler deploy # 设置密钥不要写进代码 pnpm wrangler secret put API_KEY密钥管理这块必须强调永远不要把 API key 硬编码进代码或提交到仓库。用wrangler secret管理代码里通过env.API_KEY读取。我见过有人把 key 写进wrangler.toml的vars里那个文件是会进 git 的等于公开泄露。5. 常见问题与排查技巧实录5.1 高频问题速查表问题现象可能原因解决方向pnpm 不是内部或外部命令PATH 未配置把 npm 全局 bin 加进 PATHpnpm install卡住网络或 registry 问题换 registry 或检查代理设置部署报 migration 错误DO 类变更未加 migration补一条新 tag 的 migrationDO 写入失败单条 value 超限分片存储或改用 R2本地能跑线上报错环境差异检查 compatibility_date 和绑定agent 无响应DO 被阻塞检查是否有同步长任务定时任务不触发Alarm 未设置或已过期重新 setAlarm 并检查时间戳单位5.2 独家避坑经验坑一Durable Object 单线程别在里面做重活。DO 是单线程执行的如果你在里面跑一个耗时几秒的同步计算所有请求都会排队。正确做法是把重活丢给普通 Worker 或队列DO 只负责状态管理和调度。坑二Alarms 的时间戳是毫秒。我一开始传了秒级时间戳结果 alarm 要么不触发要么立刻触发。Date.now()返回的就是毫秒直接用就行别自己除以 1000。坑三本地 dev 的 DO 数据默认不持久。每次重启wrangler dev数据就没了调试记忆功能时很容易误以为代码有问题。加--persist参数数据会存到.wrangler/state目录。坑四多 agent 通信要防死循环。A 调 BB 又调 A如果没有防重入机制会无限循环直到超时。我的做法是消息里带一个hop count超过阈值就拒绝转发。坑五pnpm 的 workspace 协议。monorepo 里引用本地包用workspace:*如果写成具体版本号pnpm 会去 registry 找找不到就报错。这个在pnpm 下载失败的案例里占比不低。5.3 性能调优的几个实操点agent 响应慢的时候先定位是网络、计算还是存储。我的排查顺序是看wrangler tail的日志时间戳确认哪一段耗时如果是 DO 存储慢检查是不是单次读了太多数据如果是工具调用慢看外部 API 的响应时间如果是冷启动慢考虑用 Cron 定时预热。DO 的存储读取是按 key 的批量读要用get的数组形式别在循环里一条条读那样延迟会累加。6. 这套架构还能怎么扩展cloudflare-os的骨架搭好之后扩展方向其实很多。我目前尝试过的几个接向量检索做长期记忆。用 Vectorize 存记忆的 embedding检索时先做相似度匹配再喂给模型比全量塞上下文省 token 也更准。用 Queues 做任务队列。把 agent 的长任务拆成消息丢进 QueueWorker 消费后回调 DO 更新状态。这样 DO 不会被长任务阻塞。多 agent 分工。一个 agent 做规划几个 agent 做执行通过消息传递协调。规划 agent 只负责拆任务执行 agent 各自有专属技能 Worker。接入可观测性。Workers 支持 Analytics Engine把 agent 的调用次数、延迟、错误率打进去做个简单看板比翻日志直观。我个人在实际操作中的体会是这套东西最大的价值不是省了服务器钱而是把 agent 的状态管理和并发安全这两件最烦的事交给了平台。你只需要专注写 agent 的逻辑和技能剩下的持久化、扩缩容、就近响应平台都替你兜住了。当然代价是要接受它的约束比如 DO 单线程、存储有大小限制、Alarms 不精确。摸清这些边界之后用起来是真的省心。最后分享一个小技巧调试多 agent 协作时给每个 agent 的日志加一个统一的前缀比如[agent-{id}]wrangler tail输出时一眼就能分清是哪个 agent 在说话排查消息传递问题效率能翻倍。
1. 从标题到落地cloudflare-os 到底想解决什么问题第一次看到cloudflare-os这个标题我下意识以为又是一个把 Linux 塞进浏览器的玩具项目。真正翻完它的设计思路和代码结构之后才发现这东西的野心根本不在“模拟操作系统”上而是在回答一个更实际的问题当 AI agent 需要长期在线、需要记忆、需要多任务协作时它到底该跑在哪里传统做法是把 agent 跑在本地进程里或者丢到一台 VPS 上。本地进程的问题是关机就断VPS 的问题是运维成本高、冷启动慢、还要自己处理持久化和扩缩容。cloudflare-os给出的答案很直接——把 agent 的运行时、记忆层、任务调度全部压到 Cloudflare Workers 这套边缘计算体系上用 Durable Objects 做状态用 Workers 做无服务器执行用 R2 或 KV 做持久化存储。整个“操作系统”其实是一层抽象把边缘节点包装成一个 agent 可以常驻、可以互相通信、可以共享记忆的运行环境。这个定位决定了它的目标读者非常明确已经在写 agent、但被部署和状态管理折磨过的开发者。如果你只是想让 AI 帮你写个周报那完全用不上它但如果你在做多 agent 协作、需要 agent 7x24 在线、需要跨会话记忆、需要给 agent 分配“技能”和“工具”那这套东西值得认真看一遍。它解决的不是“AI 能不能思考”而是“AI 思考完之后状态存在哪、下次怎么接着用、多个 agent 怎么不打架”。我把它理解成一个面向 agent 的边缘运行时框架。核心关键词里出现的Cloudflare Workers、agent、pnpm、agent 架构、agent 记忆基本覆盖了它的技术栈全貌。下面我会按“设计思路 → 核心机制 → 实操落地 → 踩坑排查”的顺序把我在复现过程中摸清楚的东西完整讲一遍。2. 整体设计思路为什么是边缘 Durable Objects2.1 把 agent 当“有状态服务”而不是“函数”来设计大多数 serverless 思路是把一切当成无状态函数请求进来算完返回进程销毁。这个模型对普通 API 很友好但对 agent 是灾难。因为 agent 的核心价值恰恰在于它有记忆、有上下文、有持续的任务队列。你今天让它查的资料明天它还应该记得它正在执行的长任务不能因为一次请求结束就被清空。cloudflare-os的关键设计决策就是引入Durable Objects作为 agent 的“宿主”。每个 agent 实例对应一个 Durable Object这个对象有唯一 ID、有持久化存储、有单线程执行保证。这意味着agent 的状态天然持久不需要你额外接 Redis 或数据库同一个 agent 的请求会被串行处理不会出现两个请求同时改同一份记忆导致覆盖agent 可以主动发起定时任务通过 Alarms实现“每隔一段时间自己醒来干活”。这个选择背后的逻辑很清晰agent 本质是一个长期存活的有状态实体而不是一次性的计算任务。用 Durable Objects 来承载它比自己在 VPS 上维护进程要省心得多也比纯 KV 存储多了并发安全保证。2.2 边缘节点带来的延迟优势与“就近唤醒”把 agent 放在边缘节点上最直接的好处是延迟。用户在东京发起请求agent 就在东京附近的节点响应不用绕到某个中心机房。对于需要多轮对话、频繁工具调用的 agent 来说每一轮省几十毫秒累积起来体验差别很明显。但更关键的是就近唤醒这个特性。传统 VPS 上跑 agent你得考虑它部署在哪个区域用户离得远就慢。边缘运行时天然把 agent 的“入口”铺到全球用户从哪来就在哪唤醒。对于做多地区服务的团队这一点省掉了大量区域部署的麻烦。2.3 用 Workers 做“技能层”实现 agent 能力的模块化cloudflare-os里另一个我觉得很聪明的设计是把 agent 的“技能”拆成独立的 Workers。每个技能就是一个小的 Worker 函数负责一类具体能力比如查天气、读文档、调外部 API。agent 主逻辑通过绑定Bindings去调用这些技能 Worker。这样做的好处是技能可以独立部署和更新改一个技能不用动 agent 主体技能可以复用多个 agent 共享同一套技能 Worker权限边界清晰每个技能 Worker 能访问什么资源由绑定决定天然做了隔离。这其实呼应了热词里的agent skill 教程和agent 架构。很多人做 agent 时把所有工具函数塞在一个大文件里后期维护极其痛苦。拆成独立 Worker 之后架构一下子清爽了。2.4 为什么用 pnpm 而不是 npm项目用 pnpm 作为包管理器这不是随便选的。Cloudflare Workers 项目通常依赖较多且需要 monorepo 管理多个 Worker 和共享包。pnpm 的硬链接机制让node_modules体积小很多安装速度快而且对 monorepo 的 workspace 支持比 npm 成熟。热词里出现pnpm 下载失败、pnpm 不是内部或外部命令、pnpm 离线安装说明不少人在第一步就卡住了。这个我后面会专门讲怎么处理。3. 核心机制拆解记忆、调度与多 agent 协作3.1 agent 记忆是怎么存的cloudflare-os的记忆层分两部分短期上下文和长期记忆。短期上下文就是当前会话的消息历史存在 Durable Object 的内存里会话结束或超时后可以落盘。长期记忆则写进 Durable Object 的持久化存储底层是 SQLite按 key 组织。常见的做法是把对话摘要、用户偏好、任务结果按memory:{agentId}:{type}:{key}的格式存检索时按前缀扫描或者用向量检索如果接了 Vectorize。这里有个实操细节Durable Object 的存储有单次读写大小限制单条 value 不能太大。所以长文本记忆要分片存或者只存摘要 原文放 R2。我一开始把整篇文档塞进一条记录结果写入直接失败排查了半天才反应过来是大小限制。3.2 定时任务与“agent 自己醒来”Durable Objects 支持 Alarms可以设定某个时间点唤醒自己。cloudflare-os用它来实现 agent 的主动行为比如每隔一小时检查一次任务队列到点提醒用户定期整理和压缩记忆。这个机制让 agent 从“被动响应”变成“主动工作”。实现上就是在 Durable Object 里设置storage.setAlarm(timestamp)然后在alarm()方法里写唤醒逻辑。注意Alarms 不是精确定时边缘节点负载高时可能延迟几秒到几十秒做提醒类功能要留余量。3.3 多 agent 协作怎么不打架多 agent 协作是热词里多 ai 协作、agent 架构的核心关注点。cloudflare-os的做法是给每个 agent 一个唯一 IDagent 之间通过消息传递通信而不是共享内存。一个 agent 要调用另一个 agent就发一条消息到对方的 Durable Object对方处理完再回消息。这样做的好处是隔离性好一个 agent 崩了不会拖垮其他 agent。代价是通信有延迟且需要设计好消息协议。我建议消息格式至少包含发送方 ID、接收方 ID、消息类型、payload、时间戳、是否需要回复。少了这些字段后期调试会非常痛苦。3.4 工具调用与安全边界agent 调用外部工具时cloudflare-os通过 Workers 的绑定机制限制它能访问什么。比如一个只负责查天气的技能 Worker就不给它绑定数据库它想访问也访问不了。这是最小权限原则在 agent 架构里的落地。热词里有agent 安全这块确实值得重视。agent 一旦能自由调用外部 API就可能被提示注入攻击利用。我的经验是所有工具调用的参数都要做校验尤其是涉及写操作和外部请求的。不要让 agent 的输出直接拼进 SQL 或 shell 命令。4. 实操落地从零把 cloudflare-os 跑起来4.1 环境准备与 pnpm 安装避坑第一步就是装 pnpm。热词里大量pnpm 不是内部或命令、pnpm 下载失败的问题基本都是环境没配好。标准做法# 用 corepack 启用 pnpmNode 16.13 自带 corepack enable corepack prepare pnpmlatest --activate # 或者用 npm 全局装 npm install -g pnpm # 验证 pnpm -v如果提示pnpm 不是内部或外部命令八成是 npm 全局 bin 目录没加进 PATH。Windows 上执行npm config get prefix拿到路径手动加进系统环境变量。Ubuntu 上通常是/usr/local/bin或~/.local/share/pnpm检查~/.bashrc里有没有对应的 export。pnpm 离线安装的场景可以先用pnpm store path找到 store 目录把依赖缓存拷过去再pnpm install --offline。这个在隔离环境里很有用。4.2 项目初始化与依赖安装# 克隆项目 git clone repo-url cloudflare-os cd cloudflare-os # 安装依赖 pnpm install # 如果遇到 peer dependency 警告不要盲目 --force # 先看清楚是哪个包冲突多数情况是版本没对齐安装完成后检查wrangler.toml这是 Cloudflare Workers 的配置文件。重点看几个字段字段作用常见坑nameWorker 名称不能和已有 Worker 重名main入口文件路径写错会直接构建失败compatibility_date兼容日期太旧会导致新 API 不可用durable_objectsDO 绑定忘记配 migrations 会报错kv_namespacesKV 绑定id 要填真实的不能留空4.3 Durable Object 的迁移配置Durable Objects 需要 migrations 配置否则部署时会报“no migration found”。格式大致如下[[migrations]] tag v1 new_classes [AgentHost]每次新增或重命名 DO 类都要加一条新 migrationtag 不能重复。我踩过的坑是改了 DO 类名但没加 migration本地wrangler dev能跑一部署就失败。本地和线上行为不一致时优先检查 migrations。4.4 本地开发与调试# 启动本地开发服务器 pnpm wrangler dev # 指定端口 pnpm wrangler dev --port 8787 # 本地模式下 DO 和 KV 都是模拟的数据不持久 # 需要持久化本地数据用 --persist pnpm wrangler dev --persist调试 agent 逻辑时我习惯在关键路径打日志用wrangler tail看线上实时日志pnpm wrangler tail --format pretty这个命令能实时看到线上 Worker 的 console 输出排查线上问题时比翻日志平台快得多。4.5 部署与密钥管理# 登录 pnpm wrangler login # 部署 pnpm wrangler deploy # 设置密钥不要写进代码 pnpm wrangler secret put API_KEY密钥管理这块必须强调永远不要把 API key 硬编码进代码或提交到仓库。用wrangler secret管理代码里通过env.API_KEY读取。我见过有人把 key 写进wrangler.toml的vars里那个文件是会进 git 的等于公开泄露。5. 常见问题与排查技巧实录5.1 高频问题速查表问题现象可能原因解决方向pnpm 不是内部或外部命令PATH 未配置把 npm 全局 bin 加进 PATHpnpm install卡住网络或 registry 问题换 registry 或检查代理设置部署报 migration 错误DO 类变更未加 migration补一条新 tag 的 migrationDO 写入失败单条 value 超限分片存储或改用 R2本地能跑线上报错环境差异检查 compatibility_date 和绑定agent 无响应DO 被阻塞检查是否有同步长任务定时任务不触发Alarm 未设置或已过期重新 setAlarm 并检查时间戳单位5.2 独家避坑经验坑一Durable Object 单线程别在里面做重活。DO 是单线程执行的如果你在里面跑一个耗时几秒的同步计算所有请求都会排队。正确做法是把重活丢给普通 Worker 或队列DO 只负责状态管理和调度。坑二Alarms 的时间戳是毫秒。我一开始传了秒级时间戳结果 alarm 要么不触发要么立刻触发。Date.now()返回的就是毫秒直接用就行别自己除以 1000。坑三本地 dev 的 DO 数据默认不持久。每次重启wrangler dev数据就没了调试记忆功能时很容易误以为代码有问题。加--persist参数数据会存到.wrangler/state目录。坑四多 agent 通信要防死循环。A 调 BB 又调 A如果没有防重入机制会无限循环直到超时。我的做法是消息里带一个hop count超过阈值就拒绝转发。坑五pnpm 的 workspace 协议。monorepo 里引用本地包用workspace:*如果写成具体版本号pnpm 会去 registry 找找不到就报错。这个在pnpm 下载失败的案例里占比不低。5.3 性能调优的几个实操点agent 响应慢的时候先定位是网络、计算还是存储。我的排查顺序是看wrangler tail的日志时间戳确认哪一段耗时如果是 DO 存储慢检查是不是单次读了太多数据如果是工具调用慢看外部 API 的响应时间如果是冷启动慢考虑用 Cron 定时预热。DO 的存储读取是按 key 的批量读要用get的数组形式别在循环里一条条读那样延迟会累加。6. 这套架构还能怎么扩展cloudflare-os的骨架搭好之后扩展方向其实很多。我目前尝试过的几个接向量检索做长期记忆。用 Vectorize 存记忆的 embedding检索时先做相似度匹配再喂给模型比全量塞上下文省 token 也更准。用 Queues 做任务队列。把 agent 的长任务拆成消息丢进 QueueWorker 消费后回调 DO 更新状态。这样 DO 不会被长任务阻塞。多 agent 分工。一个 agent 做规划几个 agent 做执行通过消息传递协调。规划 agent 只负责拆任务执行 agent 各自有专属技能 Worker。接入可观测性。Workers 支持 Analytics Engine把 agent 的调用次数、延迟、错误率打进去做个简单看板比翻日志直观。我个人在实际操作中的体会是这套东西最大的价值不是省了服务器钱而是把 agent 的状态管理和并发安全这两件最烦的事交给了平台。你只需要专注写 agent 的逻辑和技能剩下的持久化、扩缩容、就近响应平台都替你兜住了。当然代价是要接受它的约束比如 DO 单线程、存储有大小限制、Alarms 不精确。摸清这些边界之后用起来是真的省心。最后分享一个小技巧调试多 agent 协作时给每个 agent 的日志加一个统一的前缀比如[agent-{id}]wrangler tail输出时一眼就能分清是哪个 agent 在说话排查消息传递问题效率能翻倍。
