1. 从标题到落地cloudflare-os 到底想解决什么问题第一次看到cloudflare-os这个标题我脑子里冒出来的第一个念头是这大概率不是又一个把 Linux 塞进浏览器的玩具项目。因为标题里同时挂着 Cloudflare Workers、AI、agent、pnpm 这几个词组合起来指向的方向非常明确——在边缘运行时上跑一套面向 AI agent 的操作系统式抽象层。换句话说它想做的事情是把一个 agent 从被唤醒、加载技能、调用工具、维护记忆、到最终产出结果这一整套生命周期收敛到一个部署在边缘节点上的统一运行时里。我先把结论摆在前面这类项目的核心价值不在于操作系统这四个字有多唬人而在于它试图解决一个真实存在的痛点——agent 的部署和状态管理目前太碎了。你可能用 Python 写了一个 agent用 Node 写了工具层记忆存在某个向量数据库技能散落在各个 prompt 文件里最后还要自己搭一套调度。cloudflare-os 这类思路的本质是提供一个骨架让 agent 的注册、路由、技能加载、会话状态、工具调用都有一套统一的约定而底层跑在 Cloudflare Workers 这种无服务器边缘环境上天然具备全球分布、冷启动快、按需计费的特点。那它适合谁我的判断是三类人第一类是已经在做 agent 开发、但被部署和状态管理折磨过的工程师第二类是想理解agent 运行时到底该怎么设计的架构爱好者第三类是手里有一堆零散 AI 能力、想把它们组织成一个可复用系统的独立开发者。如果你只是想让 ChatGPT 帮你写个周报那这个项目跟你没关系但如果你想搞清楚agent 框架和agent 运行时的区别那往下看。这里必须先厘清一个高频混淆点因为热搜词里同时出现了harness和agent区别、agent架构、agent框架、agent项目。我的理解是agent 是干活的实体harness 是约束和驱动这个实体的外壳。打个比方agent 是司机harness 是方向盘加仪表盘加安全带。cloudflare-os 更偏向 harness 这一层——它不负责你的 agent 有多聪明它负责让 agent 跑得稳、管得住、可观测。这个定位想清楚了后面所有的技术选型就都顺了。2. 核心架构拆解为什么是 Workers pnpm 技能化设计2.1 为什么把运行时放在边缘而不是传统服务器传统 agent 部署一般是这么干的一台云主机跑一个 FastAPI 或者 Express 服务agent 逻辑全在里面状态存 Redis 或 Postgres。这套方案我用了很久问题也很明显——冷启动和扩缩容是两座大山。用户量一上来你得手动扩容没人用的时候机器还在烧钱跨地域访问延迟高因为你的服务可能只在一个区域。Cloudflare Workers 这类边缘运行时的逻辑完全不同。它把你的代码分发到全球几百个节点请求打到离用户最近的那个节点执行冷启动通常在毫秒级。对于 agent 这种请求-响应特征明显、单次执行时间不长的场景简直是量身定做。但代价也很明确运行环境受限。Workers 不是完整的 Node.js没有文件系统没有原生 TCPCPU 执行时间有上限内存也有限制。所以 cloudflare-os 这类项目在设计时必须把什么放在边缘、什么放在外部这条线划得非常清楚。我的经验是边缘层适合放这些东西请求路由、会话状态用 KV 或 Durable Objects、技能注册表、轻量级的 prompt 组装、工具调用的编排。而重计算、大模型推理、向量检索这些必须外置。这个边界一旦模糊项目就会变成一个什么都想塞进边缘的四不像。2.2 pnpm 在这里扮演的角色以及那些安装报错热搜词里 pnpm 相关的词条特别多pnpm下载失败、pnpm : 无法将pnpm项识别为 cmdlet、pnpm 不是内部或外部命令、删除pnpm、pnpm离线安装、ubuntu安装pnpm……这说明大量人在第一步就卡住了。我先把这个说透因为它直接影响你能不能跑起来 cloudflare-os 这类项目。pnpm 相比 npm 和 yarn 的核心优势是硬链接 内容寻址存储。简单说同一个依赖包在你机器上只存一份所有项目通过硬链接引用它。这带来的直接好处是磁盘占用小、安装快、依赖树严格不会出现幽灵依赖。对于 monorepo 结构的 agent 项目——通常会有packages/core、packages/skills、apps/worker这种划分——pnpm 的 workspace 支持几乎是刚需。安装报错的根因九成是环境变量 PATH 没配好。Windows 上用 npm 全局装了 pnpm 之后如果 npm 的全局 bin 目录不在 PATH 里就会出现无法识别为 cmdlet。解决办法是找到 npm 全局路径npm config get prefix把它加进系统环境变量。Ubuntu 上更推荐用 corepack因为 Node 16.13 之后自带corepack enable corepack prepare pnpmlatest --activate离线安装的场景我也踩过。如果你在内网环境需要先在能联网的机器上执行pnpm fetch把依赖缓存下来再把整个 store 目录拷过去配合pnpm install --offline。这里有个坑pnpm 的 store 路径和项目里的.npmrc配置必须一致否则离线安装会找不到包。我一般会在项目根目录固定一个.npmrc写明store-dir避免不同机器行为不一致。2.3 技能化skill设计背后的逻辑热搜里agent skill教程、claude agent skills: a first principles deep dive这些词说明技能这个概念正在成为 agent 开发的主流抽象。cloudflare-os 这类项目大概率也采用了类似思路把 agent 的能力拆成一个个独立的 skill每个 skill 是一个自包含的模块声明自己的输入、输出、依赖和触发条件。为什么这么设计因为单体式 agent 的 prompt 会随着功能增加而爆炸。你想想一个 agent 既要会查天气、又要会发邮件、又要会做数据分析如果全塞进一个 system prompt那 prompt 会长到离谱模型注意力被稀释效果反而下降。技能化的本质是按需加载——agent 先看用户意图判断需要哪个技能再把这个技能的描述和工具定义注入上下文。这样每次调用的上下文都是精简的、聚焦的。从工程角度看技能化还带来一个隐性好处可测试性。每个 skill 可以单独写单元测试mock 掉外部依赖验证输入输出。这在 agent 开发里太重要了因为 agent 的行为本来就难测如果连技能都是黑盒那整个系统就没法维护。3. 实操落地从零搭一个最小可用的 agent 运行时3.1 环境准备与项目初始化我按最常见的 monorepo 结构来演示这套结构我在多个 agent 项目里复用实测很稳。先确认 Node 版本在 18 以上然后corepack enable mkdir cloudflare-os-demo cd cloudflare-os-demo pnpm init接着建 workspace 配置。在根目录新建pnpm-workspace.yamlpackages: - packages/* - apps/*然后建三个包packages/core核心运行时抽象、packages/skills技能集合、apps/worker边缘入口。每个包自己的package.json里跨包引用用workspace:*协议这样 pnpm 会自动软链到本地改代码即时生效不用反复发包。提示如果你在 Windows 上遇到pnpm命令找不到先别急着重装执行where pnpm看看路径再对照npm config get prefix八成是 PATH 的问题。3.2 核心运行时的最小实现packages/core里我一般放三样东西agent 注册表、技能加载器、会话管理器。先看技能加载器的核心逻辑这是整个系统的地基// packages/core/src/skill-registry.ts export interface Skill { name: string; description: string; triggers: string[]; execute: (input: unknown, ctx: SkillContext) Promiseunknown; } export class SkillRegistry { private skills new Mapstring, Skill(); register(skill: Skill) { if (this.skills.has(skill.name)) { throw new Error(Skill ${skill.name} already registered); } this.skills.set(skill.name, skill); } match(intent: string): Skill[] { return [...this.skills.values()].filter((s) s.triggers.some((t) intent.toLowerCase().includes(t.toLowerCase())) ); } get(name: string): Skill | undefined { return this.skills.get(name); } }这段代码看着简单但有几个设计决策值得说。第一register里做了重名检查因为技能冲突是 agent 系统里非常隐蔽的 bug——两个技能触发词重叠agent 随机选一个行为就不稳定了。第二match用的是简单的关键词包含而不是向量相似度。为什么因为在边缘环境里每次请求都做一次 embedding 调用成本太高、延迟太大。先用轻量规则做粗筛再用模型做精排这是我在生产环境验证过的性价比最高的方案。3.3 会话状态管理Durable Objects 的正确用法agent 和普通 API 最大的区别是它是有状态的。用户说帮我改一下刚才那封邮件你得知道刚才那封是什么。在 Workers 环境里管理这种状态的标准答案是 Durable Objects。// apps/worker/src/session.ts export class AgentSession { private state: DurableObjectState; private history: Array{ role: string; content: string } []; 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 }); // 这里调用 agent 编排逻辑 const reply await this.runAgent(message); this.history.push({ role: assistant, content: reply }); await this.state.storage.put(history, this.history); return new Response(JSON.stringify({ reply })); } }这里的关键点是blockConcurrencyWhile。Durable Objects 是单线程的但如果你在构造函数里异步加载状态而请求已经进来了就会读到空状态。这个 API 保证在状态加载完成前所有请求都被阻塞。我见过太多人在这里翻车表现为第一次请求正常第二次就丢历史。注意Durable Objects 的存储有大小限制历史记录不能无限增长。我的做法是保留最近 N 轮对话更早的做摘要压缩后存 KV需要时再取回。3.4 技能的具体实现示例光有框架不够得有个真实技能才能跑通。我拿天气查询举例因为它足够简单又能体现完整链路// packages/skills/src/weather.ts import type { Skill } from cloudflare-os/core; export const weatherSkill: Skill { name: weather, description: 查询指定城市的当前天气, triggers: [天气, 气温, 下雨, weather], async execute(input: { city: string }, ctx) { const res await fetch( https://api.example.com/weather?city${encodeURIComponent(input.city)}, { headers: { Authorization: Bearer ${ctx.env.WEATHER_KEY} } } ); if (!res.ok) throw new Error(Weather API failed: ${res.status}); const data await res.json(); return { city: input.city, temp: data.temp, desc: data.desc }; }, };注意execute的签名里带了ctx这是把环境变量、日志、其他技能引用都透传进来的通道。技能之间不应该直接 import 彼此而应该通过 ctx 提供的接口调用否则依赖关系会变成一团乱麻。4. 踩坑实录agent 运行时最常见的六类问题4.1 依赖与构建类问题速查现象根因解决pnpm不是内部或外部命令PATH 未包含 npm 全局 bin把npm config get prefix加入 PATHpnpm install卡住不动registry 不可达或缓存损坏换 registry或pnpm store prune后重试离线安装报找不到包store-dir 配置不一致统一.npmrc里的store-dirworkspace 包引用失效未用workspace:*协议改 package.json 依赖声明构建产物过大把重依赖打进了 worker用动态 import 拆分重逻辑外置这张表里的每一条我都在真实项目里遇到过。尤其是最后一条Workers 的包体积有硬限制如果你不小心把某个大 SDK 打进去部署直接失败。我的习惯是在 CI 里加一步wrangler deploy --dry-run提前看体积。4.2 agent 行为不稳定的排查思路agent 最让人头疼的不是报错而是有时候对有时候错。我的排查顺序是这样的先看上下文再看技能匹配最后看模型。上下文问题占七成——要么是历史记录太长把关键信息挤掉了要么是技能描述写得含糊导致模型选错。技能匹配问题占两成——触发词设计得太宽泛多个技能抢同一个意图。真正是模型能力问题的其实不到一成。有个具体技巧给每次 agent 调用打上 trace id把注入的 prompt、匹配到的技能、模型返回全部落日志。这样出问题时能完整回放。我一开始嫌麻烦没做后来被一个偶发 bug 折腾了两天从此每个项目第一件事就是搭这套可观测性。4.3 关于agent 安全的几点务实建议热搜里agent安全是个高频词但很多讨论停留在概念层面。我说几个能落地的第一技能执行要有超时和熔断一个技能卡住不能拖垮整个会话第二外部输入永远不要直接拼进 prompt要做转义和长度限制防止提示注入第三敏感操作发邮件、转账、删数据必须走二次确认不能让 agent 自主决定。这三点做到了能挡掉绝大多数现实风险。5. 多 agent 协作与后续扩展方向5.1 什么时候需要多 agent什么时候不需要多ai协作、agent架构这些词很热但我得泼盆冷水大部分场景单 agent 加多技能就够了。多 agent 的价值在于职责隔离——比如一个负责规划、一个负责执行、一个负责审查它们的目标函数不同互相制衡。如果你只是功能多那加技能就行别上多 agent否则通信开销和状态同步的复杂度会让你怀疑人生。真要用多 agent我的建议是从两个开始一个 planner一个 executor。planner 只输出结构化计划executor 只负责执行单步。两者通过一个共享的任务队列通信而不是直接对话。这样调试起来清晰得多。5.2 记忆系统的分层设计agent记忆是另一个绕不开的话题。我的实践是分三层工作记忆当前会话放 Durable Object、短期记忆最近几天放 KV、长期记忆沉淀的知识放向量库。查询时从近到远逐层检索命中就停。这样既保证了响应速度又不会丢失重要信息。全塞进向量库的做法我试过检索延迟高而且很多临时信息根本不该进长期库。5.3 这套架构还能怎么扩展cloudflare-os 这类项目的想象空间其实挺大。往小了说你可以把它当成一个个人 AI 助手后端接上自己的各种工具。往大了说它可以变成一个技能市场——大家写技能、发布技能、组合技能。我最近在尝试的方向是把技能用声明式配置描述让非程序员也能通过改 YAML 来组装 agent。这条路走通了agent 开发的门槛会降一大截。最后分享一个我踩过的小坑别在项目初期就追求架构完美。我第一个 agent 项目花了三周设计完美的技能抽象层结果真正跑起来发现需求完全不是那样全部推倒重来。后来我改成先跑通一个最丑但能用的版本再逐步重构效率反而高得多。技能注册表、会话管理这些核心抽象可以早点定但具体的技能接口一定要等有了两三个真实技能之后再抽象否则就是拍脑袋。
1. 从标题到落地cloudflare-os 到底想解决什么问题第一次看到cloudflare-os这个标题我脑子里冒出来的第一个念头是这大概率不是又一个把 Linux 塞进浏览器的玩具项目。因为标题里同时挂着 Cloudflare Workers、AI、agent、pnpm 这几个词组合起来指向的方向非常明确——在边缘运行时上跑一套面向 AI agent 的操作系统式抽象层。换句话说它想做的事情是把一个 agent 从被唤醒、加载技能、调用工具、维护记忆、到最终产出结果这一整套生命周期收敛到一个部署在边缘节点上的统一运行时里。我先把结论摆在前面这类项目的核心价值不在于操作系统这四个字有多唬人而在于它试图解决一个真实存在的痛点——agent 的部署和状态管理目前太碎了。你可能用 Python 写了一个 agent用 Node 写了工具层记忆存在某个向量数据库技能散落在各个 prompt 文件里最后还要自己搭一套调度。cloudflare-os 这类思路的本质是提供一个骨架让 agent 的注册、路由、技能加载、会话状态、工具调用都有一套统一的约定而底层跑在 Cloudflare Workers 这种无服务器边缘环境上天然具备全球分布、冷启动快、按需计费的特点。那它适合谁我的判断是三类人第一类是已经在做 agent 开发、但被部署和状态管理折磨过的工程师第二类是想理解agent 运行时到底该怎么设计的架构爱好者第三类是手里有一堆零散 AI 能力、想把它们组织成一个可复用系统的独立开发者。如果你只是想让 ChatGPT 帮你写个周报那这个项目跟你没关系但如果你想搞清楚agent 框架和agent 运行时的区别那往下看。这里必须先厘清一个高频混淆点因为热搜词里同时出现了harness和agent区别、agent架构、agent框架、agent项目。我的理解是agent 是干活的实体harness 是约束和驱动这个实体的外壳。打个比方agent 是司机harness 是方向盘加仪表盘加安全带。cloudflare-os 更偏向 harness 这一层——它不负责你的 agent 有多聪明它负责让 agent 跑得稳、管得住、可观测。这个定位想清楚了后面所有的技术选型就都顺了。2. 核心架构拆解为什么是 Workers pnpm 技能化设计2.1 为什么把运行时放在边缘而不是传统服务器传统 agent 部署一般是这么干的一台云主机跑一个 FastAPI 或者 Express 服务agent 逻辑全在里面状态存 Redis 或 Postgres。这套方案我用了很久问题也很明显——冷启动和扩缩容是两座大山。用户量一上来你得手动扩容没人用的时候机器还在烧钱跨地域访问延迟高因为你的服务可能只在一个区域。Cloudflare Workers 这类边缘运行时的逻辑完全不同。它把你的代码分发到全球几百个节点请求打到离用户最近的那个节点执行冷启动通常在毫秒级。对于 agent 这种请求-响应特征明显、单次执行时间不长的场景简直是量身定做。但代价也很明确运行环境受限。Workers 不是完整的 Node.js没有文件系统没有原生 TCPCPU 执行时间有上限内存也有限制。所以 cloudflare-os 这类项目在设计时必须把什么放在边缘、什么放在外部这条线划得非常清楚。我的经验是边缘层适合放这些东西请求路由、会话状态用 KV 或 Durable Objects、技能注册表、轻量级的 prompt 组装、工具调用的编排。而重计算、大模型推理、向量检索这些必须外置。这个边界一旦模糊项目就会变成一个什么都想塞进边缘的四不像。2.2 pnpm 在这里扮演的角色以及那些安装报错热搜词里 pnpm 相关的词条特别多pnpm下载失败、pnpm : 无法将pnpm项识别为 cmdlet、pnpm 不是内部或外部命令、删除pnpm、pnpm离线安装、ubuntu安装pnpm……这说明大量人在第一步就卡住了。我先把这个说透因为它直接影响你能不能跑起来 cloudflare-os 这类项目。pnpm 相比 npm 和 yarn 的核心优势是硬链接 内容寻址存储。简单说同一个依赖包在你机器上只存一份所有项目通过硬链接引用它。这带来的直接好处是磁盘占用小、安装快、依赖树严格不会出现幽灵依赖。对于 monorepo 结构的 agent 项目——通常会有packages/core、packages/skills、apps/worker这种划分——pnpm 的 workspace 支持几乎是刚需。安装报错的根因九成是环境变量 PATH 没配好。Windows 上用 npm 全局装了 pnpm 之后如果 npm 的全局 bin 目录不在 PATH 里就会出现无法识别为 cmdlet。解决办法是找到 npm 全局路径npm config get prefix把它加进系统环境变量。Ubuntu 上更推荐用 corepack因为 Node 16.13 之后自带corepack enable corepack prepare pnpmlatest --activate离线安装的场景我也踩过。如果你在内网环境需要先在能联网的机器上执行pnpm fetch把依赖缓存下来再把整个 store 目录拷过去配合pnpm install --offline。这里有个坑pnpm 的 store 路径和项目里的.npmrc配置必须一致否则离线安装会找不到包。我一般会在项目根目录固定一个.npmrc写明store-dir避免不同机器行为不一致。2.3 技能化skill设计背后的逻辑热搜里agent skill教程、claude agent skills: a first principles deep dive这些词说明技能这个概念正在成为 agent 开发的主流抽象。cloudflare-os 这类项目大概率也采用了类似思路把 agent 的能力拆成一个个独立的 skill每个 skill 是一个自包含的模块声明自己的输入、输出、依赖和触发条件。为什么这么设计因为单体式 agent 的 prompt 会随着功能增加而爆炸。你想想一个 agent 既要会查天气、又要会发邮件、又要会做数据分析如果全塞进一个 system prompt那 prompt 会长到离谱模型注意力被稀释效果反而下降。技能化的本质是按需加载——agent 先看用户意图判断需要哪个技能再把这个技能的描述和工具定义注入上下文。这样每次调用的上下文都是精简的、聚焦的。从工程角度看技能化还带来一个隐性好处可测试性。每个 skill 可以单独写单元测试mock 掉外部依赖验证输入输出。这在 agent 开发里太重要了因为 agent 的行为本来就难测如果连技能都是黑盒那整个系统就没法维护。3. 实操落地从零搭一个最小可用的 agent 运行时3.1 环境准备与项目初始化我按最常见的 monorepo 结构来演示这套结构我在多个 agent 项目里复用实测很稳。先确认 Node 版本在 18 以上然后corepack enable mkdir cloudflare-os-demo cd cloudflare-os-demo pnpm init接着建 workspace 配置。在根目录新建pnpm-workspace.yamlpackages: - packages/* - apps/*然后建三个包packages/core核心运行时抽象、packages/skills技能集合、apps/worker边缘入口。每个包自己的package.json里跨包引用用workspace:*协议这样 pnpm 会自动软链到本地改代码即时生效不用反复发包。提示如果你在 Windows 上遇到pnpm命令找不到先别急着重装执行where pnpm看看路径再对照npm config get prefix八成是 PATH 的问题。3.2 核心运行时的最小实现packages/core里我一般放三样东西agent 注册表、技能加载器、会话管理器。先看技能加载器的核心逻辑这是整个系统的地基// packages/core/src/skill-registry.ts export interface Skill { name: string; description: string; triggers: string[]; execute: (input: unknown, ctx: SkillContext) Promiseunknown; } export class SkillRegistry { private skills new Mapstring, Skill(); register(skill: Skill) { if (this.skills.has(skill.name)) { throw new Error(Skill ${skill.name} already registered); } this.skills.set(skill.name, skill); } match(intent: string): Skill[] { return [...this.skills.values()].filter((s) s.triggers.some((t) intent.toLowerCase().includes(t.toLowerCase())) ); } get(name: string): Skill | undefined { return this.skills.get(name); } }这段代码看着简单但有几个设计决策值得说。第一register里做了重名检查因为技能冲突是 agent 系统里非常隐蔽的 bug——两个技能触发词重叠agent 随机选一个行为就不稳定了。第二match用的是简单的关键词包含而不是向量相似度。为什么因为在边缘环境里每次请求都做一次 embedding 调用成本太高、延迟太大。先用轻量规则做粗筛再用模型做精排这是我在生产环境验证过的性价比最高的方案。3.3 会话状态管理Durable Objects 的正确用法agent 和普通 API 最大的区别是它是有状态的。用户说帮我改一下刚才那封邮件你得知道刚才那封是什么。在 Workers 环境里管理这种状态的标准答案是 Durable Objects。// apps/worker/src/session.ts export class AgentSession { private state: DurableObjectState; private history: Array{ role: string; content: string } []; 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 }); // 这里调用 agent 编排逻辑 const reply await this.runAgent(message); this.history.push({ role: assistant, content: reply }); await this.state.storage.put(history, this.history); return new Response(JSON.stringify({ reply })); } }这里的关键点是blockConcurrencyWhile。Durable Objects 是单线程的但如果你在构造函数里异步加载状态而请求已经进来了就会读到空状态。这个 API 保证在状态加载完成前所有请求都被阻塞。我见过太多人在这里翻车表现为第一次请求正常第二次就丢历史。注意Durable Objects 的存储有大小限制历史记录不能无限增长。我的做法是保留最近 N 轮对话更早的做摘要压缩后存 KV需要时再取回。3.4 技能的具体实现示例光有框架不够得有个真实技能才能跑通。我拿天气查询举例因为它足够简单又能体现完整链路// packages/skills/src/weather.ts import type { Skill } from cloudflare-os/core; export const weatherSkill: Skill { name: weather, description: 查询指定城市的当前天气, triggers: [天气, 气温, 下雨, weather], async execute(input: { city: string }, ctx) { const res await fetch( https://api.example.com/weather?city${encodeURIComponent(input.city)}, { headers: { Authorization: Bearer ${ctx.env.WEATHER_KEY} } } ); if (!res.ok) throw new Error(Weather API failed: ${res.status}); const data await res.json(); return { city: input.city, temp: data.temp, desc: data.desc }; }, };注意execute的签名里带了ctx这是把环境变量、日志、其他技能引用都透传进来的通道。技能之间不应该直接 import 彼此而应该通过 ctx 提供的接口调用否则依赖关系会变成一团乱麻。4. 踩坑实录agent 运行时最常见的六类问题4.1 依赖与构建类问题速查现象根因解决pnpm不是内部或外部命令PATH 未包含 npm 全局 bin把npm config get prefix加入 PATHpnpm install卡住不动registry 不可达或缓存损坏换 registry或pnpm store prune后重试离线安装报找不到包store-dir 配置不一致统一.npmrc里的store-dirworkspace 包引用失效未用workspace:*协议改 package.json 依赖声明构建产物过大把重依赖打进了 worker用动态 import 拆分重逻辑外置这张表里的每一条我都在真实项目里遇到过。尤其是最后一条Workers 的包体积有硬限制如果你不小心把某个大 SDK 打进去部署直接失败。我的习惯是在 CI 里加一步wrangler deploy --dry-run提前看体积。4.2 agent 行为不稳定的排查思路agent 最让人头疼的不是报错而是有时候对有时候错。我的排查顺序是这样的先看上下文再看技能匹配最后看模型。上下文问题占七成——要么是历史记录太长把关键信息挤掉了要么是技能描述写得含糊导致模型选错。技能匹配问题占两成——触发词设计得太宽泛多个技能抢同一个意图。真正是模型能力问题的其实不到一成。有个具体技巧给每次 agent 调用打上 trace id把注入的 prompt、匹配到的技能、模型返回全部落日志。这样出问题时能完整回放。我一开始嫌麻烦没做后来被一个偶发 bug 折腾了两天从此每个项目第一件事就是搭这套可观测性。4.3 关于agent 安全的几点务实建议热搜里agent安全是个高频词但很多讨论停留在概念层面。我说几个能落地的第一技能执行要有超时和熔断一个技能卡住不能拖垮整个会话第二外部输入永远不要直接拼进 prompt要做转义和长度限制防止提示注入第三敏感操作发邮件、转账、删数据必须走二次确认不能让 agent 自主决定。这三点做到了能挡掉绝大多数现实风险。5. 多 agent 协作与后续扩展方向5.1 什么时候需要多 agent什么时候不需要多ai协作、agent架构这些词很热但我得泼盆冷水大部分场景单 agent 加多技能就够了。多 agent 的价值在于职责隔离——比如一个负责规划、一个负责执行、一个负责审查它们的目标函数不同互相制衡。如果你只是功能多那加技能就行别上多 agent否则通信开销和状态同步的复杂度会让你怀疑人生。真要用多 agent我的建议是从两个开始一个 planner一个 executor。planner 只输出结构化计划executor 只负责执行单步。两者通过一个共享的任务队列通信而不是直接对话。这样调试起来清晰得多。5.2 记忆系统的分层设计agent记忆是另一个绕不开的话题。我的实践是分三层工作记忆当前会话放 Durable Object、短期记忆最近几天放 KV、长期记忆沉淀的知识放向量库。查询时从近到远逐层检索命中就停。这样既保证了响应速度又不会丢失重要信息。全塞进向量库的做法我试过检索延迟高而且很多临时信息根本不该进长期库。5.3 这套架构还能怎么扩展cloudflare-os 这类项目的想象空间其实挺大。往小了说你可以把它当成一个个人 AI 助手后端接上自己的各种工具。往大了说它可以变成一个技能市场——大家写技能、发布技能、组合技能。我最近在尝试的方向是把技能用声明式配置描述让非程序员也能通过改 YAML 来组装 agent。这条路走通了agent 开发的门槛会降一大截。最后分享一个我踩过的小坑别在项目初期就追求架构完美。我第一个 agent 项目花了三周设计完美的技能抽象层结果真正跑起来发现需求完全不是那样全部推倒重来。后来我改成先跑通一个最丑但能用的版本再逐步重构效率反而高得多。技能注册表、会话管理这些核心抽象可以早点定但具体的技能接口一定要等有了两三个真实技能之后再抽象否则就是拍脑袋。
