1. 从标题说起cloudflare-os 到底是个什么东西第一次看到 cloudflare-os 这个词我下意识以为是 Cloudflare 出了个操作系统镜像能刷到服务器或者树莓派上跑。翻了翻社区讨论和仓库结构才反应过来它其实是一个跑在 Cloudflare Workers 之上的 Agent 运行时环境——你可以把它理解成给 AI Agent 准备的一套云端操作系统抽象层。名字里带 os不是因为它真的是操作系统内核而是因为它把 Agent 运行需要的几件核心事情——会话状态、工具调用、记忆存储、任务编排——都封装成了一套统一的接口让开发者写 Agent 的时候不用再自己从零搭脚手架。这个定位其实挺聪明的。现在做 Agent 的人都知道最烦的不是调模型而是模型外面那一圈脏活上下文怎么存、工具怎么注册、多轮对话状态放哪、并发任务怎么调度、失败怎么重试。cloudflare-os 想干的事就是把这些脏活收进一个基于 Workers 的运行时里你只管写业务逻辑和工具函数剩下的交给它。它适合谁我觉得三类人值得看一是已经在用 Cloudflare Workers 做后端、想顺手加个 Agent 能力的开发者二是被各种 Agent 框架的依赖地狱折磨过、想要一个轻量运行时的人三是对Agent 架构这个概念还比较模糊、想找个具体项目对照着理解的新手。如果你属于这三类往下看应该不亏。需要先说明一点下面涉及的具体实现细节有一部分是基于 Cloudflare Workers 生态的常见实践做的合理推演因为这类项目的文档往往更新快、细节散我会把哪些是通用原理、哪些是项目特定选择分清楚讲避免你照着抄的时候踩坑。2. 为什么是 Workers运行时选型背后的逻辑2.1 边缘运行时的天然优势Agent 这个东西有个特点它的请求是突发性、长尾、状态分散的。用户问一句话Agent 可能要调三四个工具、跑两轮模型推理、中间还要读写记忆整个链路可能几百毫秒也可能几秒。传统做法是起一台常驻服务器但问题是大部分时间它在空转流量来了又扛不住。Workers 的模型正好对上这个场景。它是按请求计费、冷启动极快、全球边缘分布的。Agent 的一次会话可以拆成多个 Worker 调用每个调用只在自己那几百毫秒里消耗资源没有请求的时候成本几乎为零。对于个人开发者和小团队来说这个成本结构比养一台 VPS 友好太多。注意Workers 有 CPU 时间限制免费版单次请求 CPU 时间很短付费版宽松很多Agent 如果做重推理或者长循环要特别注意把重活拆出去别在一个 Worker 里死磕。2.2 状态管理Durable Objects 是关键拼图光有 Workers 还不够因为 Workers 本身是无状态的——每次请求都是全新的执行环境你上一轮对话存的东西下一轮就没了。Agent 最需要的恰恰是状态。cloudflare-os 这类项目能成立核心依赖是Durable ObjectsDO。DO 可以理解成有唯一 ID 的、单线程执行的、自带持久化存储的对象。一个会话对应一个 DO 实例这个实例里可以维护对话历史、工具调用记录、临时变量而且它保证同一时刻只有一个请求在处理天然避免了并发写冲突。这比你自己用 Redis 加锁要省心得多。我实测下来的体会是把会话映射到 DO 的 ID 上是整个架构里最关键的一个设计决策。会话 ID 怎么生成、怎么和用户身份绑定、DO 里存多少历史、什么时候做摘要压缩这几个问题想清楚了Agent 的骨架就立住了。2.3 和传统 Agent 框架的取舍市面上主流的 Agent 框架比如 LangChain 那一系特点是功能全、抽象多、依赖重。好处是开箱即用坏处是出问题的时候你经常要翻好几层源码才能定位。cloudflare-os 走的是另一条路薄运行时 显式接口。它不帮你决定用什么模型、不帮你封装 prompt 模板只提供工具注册、状态存取、任务调度这几样基础设施。这个取舍的代价是上手时要自己写更多胶水代码收益是可控性和可调试性。我个人更偏好后者因为 Agent 这东西调试起来本来就玄学抽象层越少出问题时你越容易知道是哪一环崩的。3. 核心架构拆解一个 Agent 请求到底经历了什么3.1 请求生命周期全景把一次完整的 Agent 交互拆开看大致是这么一条链路入口 Worker 接收请求拿到用户输入和会话标识做基础校验和限流。路由到对应 Durable Object根据会话 ID 找到或创建那个会话的 DO 实例。DO 内加载上下文从 DO 的存储里取出历史消息、记忆片段、当前任务状态。调用模型推理把上下文和可用工具列表一起发给大模型拿到模型的决策是直接回答还是要调工具。执行工具调用如果模型要求调工具运行时负责找到对应工具函数、执行、把结果塞回上下文。循环直到收敛重复 4-5直到模型给出最终回答或达到最大轮数。持久化并返回把这一轮的完整记录写回 DO返回结果给用户。这条链路里第 4 到第 6 步的循环是 Agent 和普通聊天机器人的本质区别。普通聊天是一问一答Agent 是一问、想、调工具、再想、再调、最后答。cloudflare-os 的价值就在于把这个循环标准化了你不用每写一个 Agent 就重新实现一遍。3.2 工具注册机制的设计考量工具Tool是 Agent 的手脚。在 cloudflare-os 这类运行时里工具通常以声明式的方式注册你提供一个名字、一段描述、一个参数 schema、一个执行函数。描述和 schema 会被塞进给模型的 prompt 里模型据此决定调不调、怎么调。这里有个很多人忽略的细节工具描述的质量直接决定 Agent 的智商。我见过太多人工具函数写得没问题但描述写得含糊结果模型要么不调、要么乱调。比如一个查天气的工具描述写获取天气信息就太弱写成根据城市名查询该城市当前实时天气参数 city 为中文城市名如北京就清楚得多。参数 schema 建议用 JSON Schema 严格定义把必填项、类型、枚举值都写清楚。模型看到明确的约束瞎编参数的概率会明显下降。3.3 记忆分层短期、长期、工作记忆Agent 的记忆不是一块而是分层的这点在架构设计时必须想明白记忆类型存放位置生命周期典型内容短期记忆DO 内存/存储单次会话最近几轮对话原文长期记忆外部存储如 D1、向量库跨会话用户偏好、历史事实工作记忆DO 内存单次任务中间推理结果、工具返回短期记忆直接放 DO 里最省事但要注意上下文窗口是有上限的。对话轮数一多全塞进去既贵又慢还容易让模型分心。常见做法是保留最近 N 轮原文更早的做摘要压缩。摘要什么时候触发、压缩到什么粒度这个阈值需要根据你的模型上下文长度和业务特点调。长期记忆我一般用 D1Cloudflare 的关系型数据库存结构化的事实用向量库存语义检索的片段。什么时候写长期记忆、什么时候读这个策略要设计好否则要么记了一堆没用的要么该记的没记住。4. 动手搭一个最小可用 Agent4.1 环境准备与项目初始化假设你已经有一个 Cloudflare 账号本地装了 Node.js 和 wrangler CLI。初始化一个 Workers 项目npm create cloudflarelatest my-agent -- --typehello-world cd my-agent npm install然后在wrangler.toml里配置 Durable Objects 绑定和必要的环境变量name my-agent main src/index.js compatibility_date 2024-01-01 [durable_objects] bindings [ { name AGENT_SESSION, class_name AgentSession } ] [[migrations]] tag v1 new_classes [AgentSession] [vars] MODEL_NAME your-model-name提示模型 API 的密钥千万不要写进wrangler.toml的 vars 里那是明文。用wrangler secret put MODEL_API_KEY存成 secret代码里通过env.MODEL_API_KEY读取。4.2 会话对象的最小实现Durable Object 的骨架大概长这样export class AgentSession { constructor(state, env) { this.state state; this.env env; this.history []; } async fetch(request) { const { input } await request.json(); // 加载历史 this.history (await this.state.storage.get(history)) || []; this.history.push({ role: user, content: input }); // 进入 Agent 循环 const reply await this.runAgentLoop(); // 持久化 await this.state.storage.put(history, this.history); return new Response(JSON.stringify({ reply }), { headers: { Content-Type: application/json } }); } async runAgentLoop() { // 这里实现推理-调工具-再推理的循环 // 见下一节 } }这个骨架里state.storage就是 DO 自带的持久化存储读写都是异步的。注意每次 fetch 都要重新从 storage 加载历史因为 DO 实例可能被回收内存里的this.history不保证一直在。4.3 Agent 循环的实现要点循环的核心逻辑是把历史 工具定义发给模型看模型返回什么。如果返回的是工具调用就执行工具、把结果追加到历史、再发一次如果返回的是普通文本就结束。async runAgentLoop(maxRounds 5) { for (let i 0; i maxRounds; i) { const response await callModel({ messages: this.history, tools: TOOL_DEFINITIONS, apiKey: this.env.MODEL_API_KEY }); if (response.type text) { this.history.push({ role: assistant, content: response.text }); return response.text; } if (response.type tool_call) { this.history.push({ role: assistant, tool_calls: response.calls }); for (const call of response.calls) { const result await executeTool(call.name, call.arguments); this.history.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(result) }); } } } return 抱歉任务处理轮数超限请换个说法再试。; }几个关键点maxRounds 一定要设否则模型可能陷入死循环既烧钱又卡住用户工具执行要包 try-catch工具报错不能让整个会话崩掉要把错误信息作为工具结果返回给模型让它自己决定怎么处理每轮都要检查是否收敛别傻等。4.4 工具函数的编写规范一个合格的工具体大概是这样export const tools { get_weather: { description: 根据中文城市名查询该城市当前实时天气, parameters: { type: object, properties: { city: { type: string, description: 中文城市名如北京 } }, required: [city] }, async execute({ city }) { // 实际调用天气 API const data await fetchWeather(city); return { city, temp: data.temp, condition: data.condition }; } } };写工具时有几条经验返回值尽量结构化别返回一大段自然语言模型解析结构化数据更准工具粒度要适中太细会导致调用轮数爆炸太粗又失去灵活性幂等的工具可以放心重试有副作用的工具比如发邮件、下单一定要加确认机制别让模型自己决定就执行了。5. 踩坑实录那些文档里不会写的问题5.1 上下文膨胀导致成本失控这是我最开始踩的最大的坑。Agent 跑着跑着历史越来越长每轮都全量发给模型token 消耗指数级上涨。有一次测试跑了一晚上第二天看账单差点没坐住。解决办法是主动做上下文管理。我的做法是保留最近 6 轮原文更早的每 10 轮做一次摘要摘要结果作为一条 system 消息插在历史开头。摘要用便宜的小模型做成本可以忽略。另外工具返回的结果如果很长比如查了一大段文档也要先截断或摘要再塞回上下文。5.2 工具调用参数格式错误模型有时候会把参数写成字符串化的 JSON比如{\city\: \北京\}而不是{city: 北京}。这时候直接JSON.parse可能失败或者解析出来类型不对。我的处理是在工具执行前做一层参数规范化如果是字符串且看起来像 JSON尝试解析解析失败就返回明确的错误信息给模型让它重试。5.3 DO 冷启动与状态丢失Durable Object 不是永远活着的长时间没请求会被回收。如果你的代码依赖内存里的变量比如this.history而忘了从 storage 重新加载就会出现聊着聊着失忆的现象。铁律任何需要跨请求保留的状态必须写进 storage每次 fetch 开头重新读。5.4 常见问题速查表现象可能原因排查方向Agent 不调工具直接瞎答工具描述太弱 / 模型能力不足优化 description换更强的模型工具调用死循环工具返回结果模型看不懂检查返回格式加 maxRounds会话失忆状态没持久化检查 storage 读写逻辑响应特别慢上下文太长 / 工具串行执行做摘要压缩无依赖工具并行调成本异常高上下文膨胀 / 循环轮数多加 token 监控限制历史长度独家技巧在开发阶段把每一轮的完整 prompt 和模型返回都打到日志里注意脱敏出问题时对照着看比盲猜快十倍。上线后再关掉详细日志只留关键指标。6. 扩展方向这个骨架还能怎么长把最小可用版本跑通之后能扩展的地方其实很多。多 Agent 协作是一个方向让一个调度 Agent负责拆任务把子任务分给不同的专家 Agent各自有独立的工具集和记忆。这在 Workers 上实现起来天然合适因为每个 Agent 可以是一个独立的 DO调度层只负责转发和汇总。记忆的语义检索是另一个值得投入的点。纯靠最近 N 轮原文Agent 记不住太久远的事。接一个向量库把历史对话和事实做 embedding 存起来需要的时候按语义相似度召回Agent 的长期记忆就立起来了。还有就是可观测性。Agent 的行为比普通接口难预测得多上线后一定要有 trace每次会话的轮数、每轮的工具调用、token 消耗、失败率。这些数据攒起来你才知道该优化哪里。我自己用下来最大的感受是Agent 这东西架构的清晰度比功能的丰富度重要得多。一个能跑通、能调试、成本可控的简单 Agent价值远大于一个功能堆满但一出问题就抓瞎的复杂系统。cloudflare-os 这类运行时的意义就是帮你把架构的地基打稳剩下的楼怎么盖看你的业务需要。 
长河君 · 2026/10/28 13:41:22 · 阅读 1.2k cloudflare-os 深度解析：基于 Workers 的 AI Agent 运行时架构与实战
1. 从标题说起cloudflare-os 到底是个什么东西第一次看到 cloudflare-os 这个词我下意识以为是 Cloudflare 出了个操作系统镜像能刷到服务器或者树莓派上跑。翻了翻社区讨论和仓库结构才反应过来它其实是一个跑在 Cloudflare Workers 之上的 Agent 运行时环境——你可以把它理解成给 AI Agent 准备的一套云端操作系统抽象层。名字里带 os不是因为它真的是操作系统内核而是因为它把 Agent 运行需要的几件核心事情——会话状态、工具调用、记忆存储、任务编排——都封装成了一套统一的接口让开发者写 Agent 的时候不用再自己从零搭脚手架。这个定位其实挺聪明的。现在做 Agent 的人都知道最烦的不是调模型而是模型外面那一圈脏活上下文怎么存、工具怎么注册、多轮对话状态放哪、并发任务怎么调度、失败怎么重试。cloudflare-os 想干的事就是把这些脏活收进一个基于 Workers 的运行时里你只管写业务逻辑和工具函数剩下的交给它。它适合谁我觉得三类人值得看一是已经在用 Cloudflare Workers 做后端、想顺手加个 Agent 能力的开发者二是被各种 Agent 框架的依赖地狱折磨过、想要一个轻量运行时的人三是对Agent 架构这个概念还比较模糊、想找个具体项目对照着理解的新手。如果你属于这三类往下看应该不亏。需要先说明一点下面涉及的具体实现细节有一部分是基于 Cloudflare Workers 生态的常见实践做的合理推演因为这类项目的文档往往更新快、细节散我会把哪些是通用原理、哪些是项目特定选择分清楚讲避免你照着抄的时候踩坑。2. 为什么是 Workers运行时选型背后的逻辑2.1 边缘运行时的天然优势Agent 这个东西有个特点它的请求是突发性、长尾、状态分散的。用户问一句话Agent 可能要调三四个工具、跑两轮模型推理、中间还要读写记忆整个链路可能几百毫秒也可能几秒。传统做法是起一台常驻服务器但问题是大部分时间它在空转流量来了又扛不住。Workers 的模型正好对上这个场景。它是按请求计费、冷启动极快、全球边缘分布的。Agent 的一次会话可以拆成多个 Worker 调用每个调用只在自己那几百毫秒里消耗资源没有请求的时候成本几乎为零。对于个人开发者和小团队来说这个成本结构比养一台 VPS 友好太多。注意Workers 有 CPU 时间限制免费版单次请求 CPU 时间很短付费版宽松很多Agent 如果做重推理或者长循环要特别注意把重活拆出去别在一个 Worker 里死磕。2.2 状态管理Durable Objects 是关键拼图光有 Workers 还不够因为 Workers 本身是无状态的——每次请求都是全新的执行环境你上一轮对话存的东西下一轮就没了。Agent 最需要的恰恰是状态。cloudflare-os 这类项目能成立核心依赖是Durable ObjectsDO。DO 可以理解成有唯一 ID 的、单线程执行的、自带持久化存储的对象。一个会话对应一个 DO 实例这个实例里可以维护对话历史、工具调用记录、临时变量而且它保证同一时刻只有一个请求在处理天然避免了并发写冲突。这比你自己用 Redis 加锁要省心得多。我实测下来的体会是把会话映射到 DO 的 ID 上是整个架构里最关键的一个设计决策。会话 ID 怎么生成、怎么和用户身份绑定、DO 里存多少历史、什么时候做摘要压缩这几个问题想清楚了Agent 的骨架就立住了。2.3 和传统 Agent 框架的取舍市面上主流的 Agent 框架比如 LangChain 那一系特点是功能全、抽象多、依赖重。好处是开箱即用坏处是出问题的时候你经常要翻好几层源码才能定位。cloudflare-os 走的是另一条路薄运行时 显式接口。它不帮你决定用什么模型、不帮你封装 prompt 模板只提供工具注册、状态存取、任务调度这几样基础设施。这个取舍的代价是上手时要自己写更多胶水代码收益是可控性和可调试性。我个人更偏好后者因为 Agent 这东西调试起来本来就玄学抽象层越少出问题时你越容易知道是哪一环崩的。3. 核心架构拆解一个 Agent 请求到底经历了什么3.1 请求生命周期全景把一次完整的 Agent 交互拆开看大致是这么一条链路入口 Worker 接收请求拿到用户输入和会话标识做基础校验和限流。路由到对应 Durable Object根据会话 ID 找到或创建那个会话的 DO 实例。DO 内加载上下文从 DO 的存储里取出历史消息、记忆片段、当前任务状态。调用模型推理把上下文和可用工具列表一起发给大模型拿到模型的决策是直接回答还是要调工具。执行工具调用如果模型要求调工具运行时负责找到对应工具函数、执行、把结果塞回上下文。循环直到收敛重复 4-5直到模型给出最终回答或达到最大轮数。持久化并返回把这一轮的完整记录写回 DO返回结果给用户。这条链路里第 4 到第 6 步的循环是 Agent 和普通聊天机器人的本质区别。普通聊天是一问一答Agent 是一问、想、调工具、再想、再调、最后答。cloudflare-os 的价值就在于把这个循环标准化了你不用每写一个 Agent 就重新实现一遍。3.2 工具注册机制的设计考量工具Tool是 Agent 的手脚。在 cloudflare-os 这类运行时里工具通常以声明式的方式注册你提供一个名字、一段描述、一个参数 schema、一个执行函数。描述和 schema 会被塞进给模型的 prompt 里模型据此决定调不调、怎么调。这里有个很多人忽略的细节工具描述的质量直接决定 Agent 的智商。我见过太多人工具函数写得没问题但描述写得含糊结果模型要么不调、要么乱调。比如一个查天气的工具描述写获取天气信息就太弱写成根据城市名查询该城市当前实时天气参数 city 为中文城市名如北京就清楚得多。参数 schema 建议用 JSON Schema 严格定义把必填项、类型、枚举值都写清楚。模型看到明确的约束瞎编参数的概率会明显下降。3.3 记忆分层短期、长期、工作记忆Agent 的记忆不是一块而是分层的这点在架构设计时必须想明白记忆类型存放位置生命周期典型内容短期记忆DO 内存/存储单次会话最近几轮对话原文长期记忆外部存储如 D1、向量库跨会话用户偏好、历史事实工作记忆DO 内存单次任务中间推理结果、工具返回短期记忆直接放 DO 里最省事但要注意上下文窗口是有上限的。对话轮数一多全塞进去既贵又慢还容易让模型分心。常见做法是保留最近 N 轮原文更早的做摘要压缩。摘要什么时候触发、压缩到什么粒度这个阈值需要根据你的模型上下文长度和业务特点调。长期记忆我一般用 D1Cloudflare 的关系型数据库存结构化的事实用向量库存语义检索的片段。什么时候写长期记忆、什么时候读这个策略要设计好否则要么记了一堆没用的要么该记的没记住。4. 动手搭一个最小可用 Agent4.1 环境准备与项目初始化假设你已经有一个 Cloudflare 账号本地装了 Node.js 和 wrangler CLI。初始化一个 Workers 项目npm create cloudflarelatest my-agent -- --typehello-world cd my-agent npm install然后在wrangler.toml里配置 Durable Objects 绑定和必要的环境变量name my-agent main src/index.js compatibility_date 2024-01-01 [durable_objects] bindings [ { name AGENT_SESSION, class_name AgentSession } ] [[migrations]] tag v1 new_classes [AgentSession] [vars] MODEL_NAME your-model-name提示模型 API 的密钥千万不要写进wrangler.toml的 vars 里那是明文。用wrangler secret put MODEL_API_KEY存成 secret代码里通过env.MODEL_API_KEY读取。4.2 会话对象的最小实现Durable Object 的骨架大概长这样export class AgentSession { constructor(state, env) { this.state state; this.env env; this.history []; } async fetch(request) { const { input } await request.json(); // 加载历史 this.history (await this.state.storage.get(history)) || []; this.history.push({ role: user, content: input }); // 进入 Agent 循环 const reply await this.runAgentLoop(); // 持久化 await this.state.storage.put(history, this.history); return new Response(JSON.stringify({ reply }), { headers: { Content-Type: application/json } }); } async runAgentLoop() { // 这里实现推理-调工具-再推理的循环 // 见下一节 } }这个骨架里state.storage就是 DO 自带的持久化存储读写都是异步的。注意每次 fetch 都要重新从 storage 加载历史因为 DO 实例可能被回收内存里的this.history不保证一直在。4.3 Agent 循环的实现要点循环的核心逻辑是把历史 工具定义发给模型看模型返回什么。如果返回的是工具调用就执行工具、把结果追加到历史、再发一次如果返回的是普通文本就结束。async runAgentLoop(maxRounds 5) { for (let i 0; i maxRounds; i) { const response await callModel({ messages: this.history, tools: TOOL_DEFINITIONS, apiKey: this.env.MODEL_API_KEY }); if (response.type text) { this.history.push({ role: assistant, content: response.text }); return response.text; } if (response.type tool_call) { this.history.push({ role: assistant, tool_calls: response.calls }); for (const call of response.calls) { const result await executeTool(call.name, call.arguments); this.history.push({ role: tool, tool_call_id: call.id, content: JSON.stringify(result) }); } } } return 抱歉任务处理轮数超限请换个说法再试。; }几个关键点maxRounds 一定要设否则模型可能陷入死循环既烧钱又卡住用户工具执行要包 try-catch工具报错不能让整个会话崩掉要把错误信息作为工具结果返回给模型让它自己决定怎么处理每轮都要检查是否收敛别傻等。4.4 工具函数的编写规范一个合格的工具体大概是这样export const tools { get_weather: { description: 根据中文城市名查询该城市当前实时天气, parameters: { type: object, properties: { city: { type: string, description: 中文城市名如北京 } }, required: [city] }, async execute({ city }) { // 实际调用天气 API const data await fetchWeather(city); return { city, temp: data.temp, condition: data.condition }; } } };写工具时有几条经验返回值尽量结构化别返回一大段自然语言模型解析结构化数据更准工具粒度要适中太细会导致调用轮数爆炸太粗又失去灵活性幂等的工具可以放心重试有副作用的工具比如发邮件、下单一定要加确认机制别让模型自己决定就执行了。5. 踩坑实录那些文档里不会写的问题5.1 上下文膨胀导致成本失控这是我最开始踩的最大的坑。Agent 跑着跑着历史越来越长每轮都全量发给模型token 消耗指数级上涨。有一次测试跑了一晚上第二天看账单差点没坐住。解决办法是主动做上下文管理。我的做法是保留最近 6 轮原文更早的每 10 轮做一次摘要摘要结果作为一条 system 消息插在历史开头。摘要用便宜的小模型做成本可以忽略。另外工具返回的结果如果很长比如查了一大段文档也要先截断或摘要再塞回上下文。5.2 工具调用参数格式错误模型有时候会把参数写成字符串化的 JSON比如{\city\: \北京\}而不是{city: 北京}。这时候直接JSON.parse可能失败或者解析出来类型不对。我的处理是在工具执行前做一层参数规范化如果是字符串且看起来像 JSON尝试解析解析失败就返回明确的错误信息给模型让它重试。5.3 DO 冷启动与状态丢失Durable Object 不是永远活着的长时间没请求会被回收。如果你的代码依赖内存里的变量比如this.history而忘了从 storage 重新加载就会出现聊着聊着失忆的现象。铁律任何需要跨请求保留的状态必须写进 storage每次 fetch 开头重新读。5.4 常见问题速查表现象可能原因排查方向Agent 不调工具直接瞎答工具描述太弱 / 模型能力不足优化 description换更强的模型工具调用死循环工具返回结果模型看不懂检查返回格式加 maxRounds会话失忆状态没持久化检查 storage 读写逻辑响应特别慢上下文太长 / 工具串行执行做摘要压缩无依赖工具并行调成本异常高上下文膨胀 / 循环轮数多加 token 监控限制历史长度独家技巧在开发阶段把每一轮的完整 prompt 和模型返回都打到日志里注意脱敏出问题时对照着看比盲猜快十倍。上线后再关掉详细日志只留关键指标。6. 扩展方向这个骨架还能怎么长把最小可用版本跑通之后能扩展的地方其实很多。多 Agent 协作是一个方向让一个调度 Agent负责拆任务把子任务分给不同的专家 Agent各自有独立的工具集和记忆。这在 Workers 上实现起来天然合适因为每个 Agent 可以是一个独立的 DO调度层只负责转发和汇总。记忆的语义检索是另一个值得投入的点。纯靠最近 N 轮原文Agent 记不住太久远的事。接一个向量库把历史对话和事实做 embedding 存起来需要的时候按语义相似度召回Agent 的长期记忆就立起来了。还有就是可观测性。Agent 的行为比普通接口难预测得多上线后一定要有 trace每次会话的轮数、每轮的工具调用、token 消耗、失败率。这些数据攒起来你才知道该优化哪里。我自己用下来最大的感受是Agent 这东西架构的清晰度比功能的丰富度重要得多。一个能跑通、能调试、成本可控的简单 Agent价值远大于一个功能堆满但一出问题就抓瞎的复杂系统。cloudflare-os 这类运行时的意义就是帮你把架构的地基打稳剩下的楼怎么盖看你的业务需要。