本文目录
Toggle当一亿个知识工作者各需要一个常驻 AI 助理，传统的容器架构有一个无聊但致命的问题：不管那个容器里有没有东西在跑，它都在烧钱。
10,000 个代理、各自只有 1% 的时间处于活跃状态，用容器部署就得维持 10,000 个常态例项。为了节省资源，Cloudflare 本月发布 Project Think，定位为 Agents SDK 的下一代版本，并开源于 GitHub。
该公司宣称 Agents SDK 已在生产环境中驱动「数千个」代理，Project Think 是在此基础上引入六项新的底层构件（Primitives），解决的不是 AI 的认知能力问题，而是「永续性、安全性、成本」三个基础设施问题。
Project Think 是什么？六项新 Primitives 拆解
一、持久执行（Durable Execution via Fibers）
传统无状态函式执行一半崩溃，前面的进度就消失了。Fibers 的设计是：runFiber() 在执行前先将状态写入 SQLite，代理随时可透过 stash() 储存当前状态，崩溃后从 onFiberRecovered 回呼继续执行。这是让长时间执行任务（例如跑几小时的研究代理）能够在现实环境中存活的基本条件。
二、子代理（Sub-agents）
子代理以共置的 Durable Objects 形式存在，各自拥有独立的 SQLite 资料库和执行环境，透过 Facets 机制与父代理保持同位。TypeScript 在编译期即可侦测误用，而非在 runtime 才爆错。
三、持久会话（Persistent Sessions）
每条讯息带有 parent_id，形成树状结构，支援 fork（在不破坏原有对话路径的情况下分支探索）和非破坏性 compaction（摘要旧讯息而非删除），并内建 FTS5 全文搜寻。这解决的是「AI 助理在多次对话后失忆」的问题。
四、沙盒程式码执行（Sandboxed Code Execution）
使用 Dynamic Workers（基于 V8 isolate），启动时间以毫秒计，对比传统容器速度快 100 倍、记忆体效率高 100 倍。能力模型采显式授权：预设 globalOutbound: null，开发者必须明确授予每个资源的存取许可权，而非预设开放。
五、执行阶梯（The Execution Ladder）
五个层级由轻至重排列——Tier 0 是 SQLite + R2 虚拟档案系统（纯资料存取），Tier 1 是沙盒 JS 执行，Tier 2 加入 npm 解析与 esbuild 打包，Tier 3 是 Headless Browser（Browser Run），Tier 4 是完整的 Cloudflare Sandbox（支援 git clone、npm test、cargo build）。代理根据任务复杂度选择进入哪一层，而非预设拿最重的锤子。
六、自我撰写扩充套件工具（Self-authored Extensions）
代理可在 runtime 自行撰写 TypeScript 扩充套件工具，由 ExtensionManager 打包进 Dynamic Worker。新工具一旦建立即永久存在——不需要 fine-tuning，不需要 RLHF，工具知识不存在模型里，存在基础设施里。
Think Base Class：统一生命周期
Project Think 提供一个 Think base class，封装了聊天代理的完整生命周期：loop、persistence、streaming、工具执行、中断后的 resumption。子类继承只需最少 5 行程式码。
内建功能包含上下文块式 memory、树状结构会话、FTS5 全文搜寻和非破坏性 compaction。
设计意图很明确：把重复造轮子的成本从每个开发者身上移除，让基础设施承担状态管理的复杂度。
Cloudflare 的三波浪潮论
Cloudflare 在档案中提出了 AI Agent 的三波演进观点：第一波是无状态聊天机器人，第二波是有工具但被困在本地笔电上的程式码代理（Claude Code、Codex 等），第三波则是「代理即基础设施」：持久、serverless、零闲置成本、结构性安全隔离。
Project Think 是第三波的基础设施押注。Cloudflare 的论点是：让 Claude Code 这类工具从笔电上搬到云端、让它在崩溃后能自行恢复、让十万个代理的成本等于实际使用量而非最大并行数。
值得注意的是，Cloudflare 自己的 AI Gateway 和 Workers AI 也是这个生态系的一部分。Project Think 的成功，同时也是 Cloudflare 平台的流量与收入。这个三波论述，本质上是一份市场定位说明书。
