今天，我們正式推出 Project Think：新一代 Agents SDK。Project Think 是一套用來建置長時間執行智慧體的全新基元（包含持久化執行、子智慧體、沙箱化程式碼執行、持續性工作階段），以及一個整合了所有功能的框架性基礎類別。您可以使用這些基元精確打造您所需的東西，也可以直接使用基礎類別快速上手。
今年早些時候發生了一些事，改變了我們思考 AI 的方式。像 Pi、OpenClaw、Claude Code 和 Codex 這樣的工具證實了一個簡單而強大的概念：只要賦予大型語言模型 LLM 讀取檔案、撰寫程式碼、執行程式碼以及記憶所學內容的能力，您得到的將不僅僅是一個開發工具，更像是一個通用型助理。
這些編碼智慧體已不再只是撰寫程式碼。人們正用它們來管理行事曆、分析資料集、協商採購、申報稅務，以及自動化整個業務流程。其運作模式總是相同：智慧體讀取上下文、進行推理、撰寫程式碼來採取行動、觀察結果，並不斷迭代。程式碼已成為行動的通用媒介。
我們的團隊每天都在使用這些編碼智慧體，並不斷碰到同樣的瓶頸：
它們只能在您的筆記型電腦或昂貴的 VPS 上執行：無法共用、無法協作，也無法在不同裝置間交接任務。
閒置時成本昂貴：無論智慧體是否在工作，您都需支付固定的月費。如果擴展到整個團隊或公司，成本將迅速飆升。
它們需要手動管理和設定：安裝依賴關係、管理更新、設定身分識別和金鑰。
而且，這背後存在一個更深層次的結構性問題。傳統應用程式是一對多的，一個執行個體服務許多使用者。正如我們在《歡迎來到 Agents Week》文章中所提到的，智慧體是一對一的。每個智慧體都是一個獨特的執行個體，服務一位使用者，執行一項任務。餐廳有菜單和廚房，可以有效率地大量出菜。而智慧體更像是私人廚師：每次使用不同的食材、不同的烹飪技巧和不同的工具。
這從根本上改變了擴展的計算方式。如果一億知識工作者每人以適中的並發量使用智慧助手，就需要支援數千萬個並發工作階段的容量。按照目前的容器成本，這是不可持續的。我們需要一個不同的基礎架構。
而這正是我們一直在努力建構的。
Project Think 為 Agents SDK 帶來一套全新的基元：
基於 Fiber 的持久化執行：崩潰復原、檢查點、自動保持連線
子智慧體：具備獨立 SQLite 與型別化 RPC 的隔離子智慧體
持久性工作階段：樹狀結構訊息、分支、壓縮、全文搜尋
沙箱化程式碼執行：Dynamic Workers、codemode、執行時期 npm 解析
執行階梯：工作區、隔離區、npm、瀏覽器、沙箱
自我編寫的擴充功能：可在執行時期撰寫自身工具的智慧體
每個元件都可以直接與 Agent 基底類別搭配使用。您可以用這些基元精確建置所需功能，或是使用 Think 基底類別來快速上手。讓我們看看每個元件的作用。
現今的智慧體通常是短暫的。它們在一個工作階段中執行，與單一處理序或裝置綁定，然後就消失了。一個當筆記型電腦休眠時就會中斷的編碼智慧體，那只是一個工具。一個能夠持久存在、可按需喚醒、在任務中斷後可繼續工作，並且不依賴本地執行環境就能保持狀態的智慧體，才開始像基礎架構。這完全改變了智慧體的擴展模型。
Agents SDK 建置在 Durable Objects 之上，為每個智慧體提供身分識別、持久性狀態，以及收到訊息時喚醒的能力。這就是 Actor 模型：每個智慧體都是一個可定址的實體，擁有自己的 SQLite 資料庫。在休眠時，它不消耗任何運算資源。當有事件發生時（例如 HTTP 請求、WebSocket 訊息、排程的鬧鐘、傳入的電子郵件），平台會喚醒智慧體、載入其狀態，並將事件交給它處理。智慧體完成工作後，便再次進入休眠。
| VM/容器 | Durable Objects |
|---|
閒置成本 | 永遠需要支付完整運算成本 | 零成本（休眠） |
擴展 | 需佈建與管理容量 | 自動，每個智慧體獨立擴展 |
狀態 | 需要外部資料庫 | 內建 SQLite |
復原 | 需自行建構（處理序管理器、健康檢查） | 平台重新啟動，狀態保留 |
身分識別/路由 | 需自行建構（負載平衡器、黏性工作階段） | 內建（名稱 → 智慧體） |
10000 個智慧體，每個活躍時間 1% | 1,000 個永遠開啟的執行個體 | 任何時刻只有約 100 個活躍執行個體 |
這改變了大規模執行智慧體的經濟效益。您可以從「每個高階使用者一個昂貴的智慧體」的模式，轉變為建構「每位客戶一個智慧體」、「每項任務一個智慧體」或「每個電子郵件處理序一個智慧體」的模式。建立新智慧體的邊際成本實際上為零。
一個 LLM 呼叫可能需要 30 秒。一個多輪智慧體迴圈則可能執行更久。在此期間的任何時間點，執行環境都可能消失：部署更新、平台重啟、觸及資源限制。到模型提供者的上游連線會永久斷開，記憶體中的狀態會遺失，已連線的用戶端會看到串流無故中斷。
runFiber() 解決了這個問題。一個 fiber 就是一個持久化的函式呼叫：在執行開始前於 SQLite 中註冊，可以在任何時間點透過 stash() 設定檢查點，並能在重啟時透過 onFiberRecovered 復原。
import { Agent } from "agents";
export class ResearchAgent extends Agent {
async startResearch(topic: string) {
void this.runFiber("research", async (ctx) => {
const findings = [];
for (let i = 0; i < 10; i++) {
const result = await this.callLLM(`Research step ${i}: ${topic}`);
findings.push(result);
// Checkpoint: if evicted, we resume from here
ctx.stash({ findings, step: i, topic });
this.broadcast({ type: "progress", step: i });
}
return { findings };
});
}
async onFiberRecovered(ctx) {
if (ctx.name === "research" && ctx.snapshot) {
const { topic } = ctx.snapshot;
await this.startResearch(topic);
}
}
}
SDK 會在 fiber 執行期間自動保持智慧體活躍，無需特殊設定。對於持續數分鐘的工作，keepAlive()/keepAliveWhile() 可防止在工作進行中被驅逐。對於較長時間的操作（例如 CI 管道、設計審查、影片產生），智慧體可以啟動工作，將工作 ID 持久化儲存，進入休眠，並在回呼時喚醒。
單一智慧體不應該獨自承擔所有工作。子智慧體是與父智慧體位於相同位置的子 Durable Objects，它們透過 Facets 進行設定，每個子智慧體都有自己獨立的 SQLite 資料庫和執行脈絡：
import { Agent } from "agents";
export class ResearchAgent extends Agent {
async search(query: string) { /* ... */ }
}
export class ReviewAgent extends Agent {
async analyze(query: string) { /* ... */ }
}
export class Orchestrator extends Agent {
async handleTask(task: string) {
const researcher = await this.subAgent(ResearchAgent, "research");
const reviewer = await this.subAgent(ReviewAgent, "review");
const [research, review] = await Promise.all([
researcher.search(task),
reviewer.analyze(task)
]);
return this.synthesize(research, review);
}
}
子智慧體在儲存層面是隔離的。每個子智慧體都有自己的 SQLite 資料庫，彼此之間沒有隱含的資料共用。執行環境會強制這種隔離，而子智慧體的 RPC 延遲被視為一次函式呼叫。TypeScript 能在編譯時期捕捉錯誤的使用。
對於執行數天或數週的智慧體，傳統的扁平訊息清單已經不夠用了。實驗性的 Session API 明確地建模了對話結構。這個 API 可在 Agent 基底類別上使用，對話會以樹狀結構儲存，每則訊息都有一個 parent_id。這支援分叉能力（探索替代方案而不丟失原始路徑）、非破壞性壓縮（摘要舊訊息而不是刪除它們）以及透過 FTS5 對對話歷程記錄進行全文搜尋。
import { Agent } from "agents";
import { Session, SessionManager } from "agents/experimental/memory/session";
export class MyAgent extends Agent {
sessions = SessionManager.create(this);
async onStart() {
const session = this.sessions.create("main");
const history = session.getHistory();
const forked = this.sessions.fork(session.id, messageId, "alternative-approach");
}
}
Session 可以直接與 Agent 一起使用，同時也是 Think 基底類別所依賴的儲存層。
傳統的工具呼叫方式比較繁瑣。模型呼叫一個工具，透過上下文視窗將結果拉取回來，再呼叫另一個工具，再次拉取結果，如此往復。隨著工具數量的增加，這種方式既耗時又笨拙。一百個檔案意味著模型需要進行一百次往返。
但模型更擅長撰寫程式碼來使用系統，而不是玩工具呼叫的遊戲。這就是 @cloudflare/codemode 背後的洞見：LLM 不進行連續的工具呼叫，而是撰寫一個處理整個任務的單一程式。
// The LLM writes this. It runs in a sandboxed Dynamic Worker.
const files = await tools.find({ pattern: "**/*.ts" });
const results = [];
for (const file of files) {
const content = await tools.read({ path: file });
if (content.includes("TODO")) {
results.push({ file, todos: content.match(/\/\/ TODO:.*/g) });
}
}
return results;
這樣就不再需要往返於模型 100 次，您只需執行一個單一程式。這意味著使用的詞元 (Token) 更少、執行速度更快，結果也更好。Cloudflare API MCP 伺服器展示了這個方法的大規模效益。我們只公開了兩個工具（search() 和 execute()），消耗約 1000 個詞元，而對應的傳統做法（為每個端點提供一個工具）則需要約 117 萬個詞元。這減少了 99.9% 的消耗。
一旦您接受了「模型應該代表使用者撰寫程式碼」這個前提，問題就變成：那段程式碼要在哪裡執行？不是「以後再說」，也不是「等產品團隊把它排進開發時程」。而是現在，為這位使用者，針對這個系統，在嚴格定義的權限下執行。
Dynamic Workers 就是那個沙箱。一個全新的 V8 隔離區，在執行期以毫秒級的速度啟動，只佔用幾 MB 的記憶體。這大約比容器快 100 倍，且記憶體效率高出 100 倍。您可以為每一個請求啟動一個新的 Dynamic Worker，執行一段程式碼片段，然後就將它丟棄。
關鍵的設計選擇是能力模型。Dynamic Workers 並非從一個通用機器開始並試圖限制它，而是從幾乎沒有任何環境權限開始（globalOutbound: null，無網路存取），開發人員透過繫結明確地、逐項資源地授予權限。我們從思考「如何阻止它做太多事？」轉變為「我們到底希望它能做什麼？」
這對於智慧體基礎架構來說才是正確的問題。
這個能力模型自然會衍生出一個運算環境的光譜，也就是一條執行階梯，智慧體可以根據需求逐步升級：
Tier 0 是 Workspace，是一個由 SQLite 和 R2 支援的持久化虛擬檔案系統。支援讀取、寫入、編輯、搜尋、grep、diff 等操作。由 @cloudflare/shell 提供支援。
Tier 1 是 Dynamic Worker：LLM 產生的 JavaScript，在沒有網路存取的沙箱化隔離區中執行。由 @cloudflare/codemode 提供支援。
Tier 2 新增了 npm。@cloudflare/worker-bundler 會從 registry 擷取套件、使用 esbuild 打包，然後將結果載入 Dynamic Worker。智慧體只要寫下 import { z } from "zod"，就能直接運作。
Tier 3 是透過 Cloudflare Browser Run 實現的無頭瀏覽器。導航、點擊、擷取、截取螢幕圖片。當服務尚不支援透過 MCP 或 API 使用智慧體時，此功能非常有用。
Tier 4 是一個 Cloudflare Sandbox，已設定您的工具鏈、程式碼庫和相依性：git clone、npm test、cargo build，並與 Workspace 雙向同步。
關鍵設計原則：智慧體在 Tier 0 就應該已經有用處，每一層都是額外疊加的功能。使用者可以隨著需求逐步增加能力。
所有這些基元都以獨立套件的形式提供。Dynamic Workers、@cloudflare/codemode、@cloudflare/worker-bundler 和 @cloudflare/shell（一個包含工具的持久性檔案系統）都可以直接與 Agent 基底類別搭配使用。您可以將它們組合起來，為任何智慧體提供工作區、程式碼執行和執行時期套件解析功能，而無需採用任何預設框架。
以下是在 Cloudflare 上建置智慧體的完整技術堆疊：
以上每一項都是獨立的建置區塊。把它們組合在一起，就形成了一個全新的平台：任何人都可以在這個平台上建置、部署、執行與本機電腦上同樣強大的 AI 智慧體——但在架構上具備無伺服器、持久化且安全的特性。
現在，您已瞭解了基元，現在我們來看看將它們全部整合在一起會發生什麼。
Think 是一個預設框架，它處理完整的聊天生命週期：智慧體迴圈、訊息持久化、串流、工具執行、串流恢復以及擴充功能。您可以專注於打造您智慧體的獨特之處。
最簡單的子類別如下所示：
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
export class MyAgent extends Think<Env> {
getModel() {
return createWorkersAI({ binding: this.env.AI })(
"@cf/moonshotai/kimi-k2.5"
);
}
}
實際上，您只需要這些就能擁有一個具備串流、持久化、中止/取消、錯誤處理、可還原串流以及內建工作區檔案系統的正常運作聊天智慧體。使用 npx wrangler deploy 進行部署。
Think 會為您做出許多決策。當您需要更多控制權時，可以覆寫您關心的部分：
覆寫 | 用途 |
getModel()
| 傳回要使用的 LanguageModel |
getSystemPrompt()
| 系統提示 |
getTools()
| 供智慧體迴圈使用的 AI SDK 相容 ToolSet |
maxSteps
| 每輪對話的最大工具呼叫次數 |
configureSession()
| 上下文區塊、壓縮、搜尋、技能 |
在底層，Think 在每一輪對話中都執行完整的智慧體迴圈：它組裝上下文（基礎指令 + 工具描述 + 技能 + 記憶 + 對話歷程記錄）、呼叫 streamText、執行工具呼叫（並截斷輸出以防止上下文爆炸）、附加結果，然後迴圈直到模型完成或達到步驟限制。所有訊息在每一輪後都會被持久化儲存。
Think 在聊天回合的每個階段都為您提供鉤子，而無需您自行管理整個管線：
beforeTurn()
→ streamText()
→ beforeToolCall()
→ afterToolCall()
→ onStepFinish()
→ onChatResponse()
您可以在後續對話輪次中切換到成本更低的模型、限制其可使用的工具，並在每一輪傳入用戶端上下文。還可以記錄每次工具呼叫以進行分析，並在模型完成後自動觸發一次後續輪次，所有這些都無需替換 onChatMessage。
Think 以 Session API 作為其儲存層，為您提供內建分支功能的樹狀結構訊息。
在此基礎上，它透過上下文區塊增加了持久性記憶。這些是系統提示詞中的結構化部分，模型可以隨時間讀取和更新，並且這些資訊在休眠期間也會持續存在。模型會看到「MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]」這樣的提示，並能主動記住事情。
configureSession(session: Session) {
return session
.withContext("soul", {
provider: { get: async () => "You are a helpful coding assistant." }
})
.withContext("memory", {
description: "Important facts learned during conversation.",
maxTokens: 2000
})
.withCachedPrompt();
}
工作階段非常靈活。您可以讓每個智慧體執行多個對話，並對其進行分支以嘗試不同的方向，而不會遺失原始對話。
隨著上下文增長，Think 使用非破壞性壓縮來處理限制。舊的訊息會被總結而非刪除，而完整的歷程記錄仍保留在 SQLite 中。
搜尋功能也是內建的。使用 FTS5，您可以在一個工作階段內或跨所有工作階段查詢對話歷程記錄。智慧體也能使用 search_context 工具搜尋自己的過往記錄。
Think 將整個執行階梯整合到單一的 getTools() 回傳值中：
import { Think } from "@cloudflare/think";
import { createWorkspaceTools } from "@cloudflare/think/tools/workspace";
import { createExecuteTool } from "@cloudflare/think/tools/execute";
import { createBrowserTools } from "@cloudflare/think/tools/browser";
import { createSandboxTools } from "@cloudflare/think/tools/sandbox";
import { createExtensionTools } from "@cloudflare/think/tools/extensions";
export class MyAgent extends Think<Env> {
extensionLoader = this.env.LOADER;
getModel() {
/* ... */
}
getTools() {
return {
execute: createExecuteTool({
tools: createWorkspaceTools(this.workspace),
loader: this.env.LOADER
}),
...createBrowserTools(this.env.BROWSER),
...createSandboxTools(this.env.SANDBOX), // configured per-agent: toolchains, repos, snapshots
...createExtensionTools({ manager: this.extensionManager! }),
...this.extensionManager!.getTools()
};
}
}
Think 將程式碼執行再向前推進一步。智慧體可以為自己撰寫擴充功能：這些是以 TypeScript 撰寫、在 Dynamic Workers 中執行的程式，並會宣告網路存取和工作區操作的權限。
{
"name": "github",
"description": "GitHub integration: PRs, issues, repos",
"tools": ["create_pr", "list_issues", "review_pr"],
"permissions": {
"network": ["api.github.com"],
"workspace": "read-write"
}
}
Think 的 ExtensionManager 會打包擴充功能（可選擇透過 @cloudflare/worker-bundler 加入 npm 依賴項），將其載入到一個 Dynamic Worker 中，並註冊新工具。擴充功能在 Durable Object 儲存中持久存在，並能在休眠後恢復。下次當使用者詢問關於拉取請求 (pull request) 時，智慧體就擁有了一個 30 秒前還不存在的 github_create_pr 工具。
這是一種能讓智慧體隨時間推移真正變得更有用的自我改進迴圈。不是透過微調或 RLHF，而是透過程式碼。智慧體能夠為自己撰寫新的功能，而且全部都是以沙箱化、可稽核、可撤銷的 TypeScript 來完成。
Think 也可以作為子智慧體，透過 RPC 從父智慧體透過 chat() 呼叫，並透過回呼實現串流事件：
const researcher = await this.subAgent(ResearchSession, "research");
const result = await researcher.chat(`Research this: ${task}`, streamRelay);
每個子智慧體都有自己的對話樹、記憶、工具和模型。父智慧體無需瞭解細節。
Project Think 目前處於實驗階段。其 API 介面是穩定的，但在未來幾天和幾週內將持續演進。我們已在內部使用它來建置我們自己的背景智慧體基礎架構，並提早分享，以便您可以與我們一起建構。
npm install @cloudflare/think agents ai @cloudflare/shell zod workers-ai-provider
// src/server.ts
import { Think } from "@cloudflare/think";
import { createWorkersAI } from "workers-ai-provider";
import { routeAgentRequest } from "agents";
export class MyAgent extends Think<Env> {
getModel() {
return createWorkersAI({ binding: this.env.AI })(
"@cf/moonshotai/kimi-k2.5"
);
}
}
export default {
async fetch(request: Request, env: Env) {
return (
(await routeAgentRequest(request, env)) ||
new Response("Not found", { status: 404 })
);
}
} satisfies ExportedHandler<Env>;
// src/client.tsx
import { useAgent } from "agents/react";
import { useAgentChat } from "@cloudflare/ai-chat/react";
function Chat() {
const agent = useAgent({ agent: "MyAgent" });
const { messages, sendMessage, status } = useAgentChat({ agent });
// Render your chat UI
}
Think 使用與 @cloudflare/ai-chat 相同的 WebSocket 通訊協定，因此現有的 UI 元件可以立即使用。如果您是基於 AIChatAgent 進行開發，您的用戶端程式碼無需變更。
我們見證了三波 AI 智慧體浪潮：
第一波是聊天機器人。它們是無狀態、被動且脆弱的。每次對話都從頭開始，沒有記憶、沒有工具，也沒有行動能力。這使它們僅限於回答問題。
第二波是編碼智慧體。這些是有狀態、使用工具、能力強大得多的工具，如 Pi、Claude Code、OpenClaw 和 Codex。這些智慧體可以讀取程式碼庫、撰寫程式碼、執行程式碼並反覆迭代。它們證明了配備適當工具的 LLM 是一種通用機器，但它們在個人筆記型電腦上執行，只服務一個使用者，且沒有任何持久性保證。
現在我們正在進入第三波：智慧體即基礎架構。持久、分散、結構安全且無伺服器。這些智慧體在網際網路上執行，能從故障中復原，閒置時無需成本，並透過架構而非行為來強制執行安全性。任何開發人員都能為任何數量的使用者建構和部署這些智慧體。
這正是我們努力的方向。
Agents SDK 已經在為數千個生產環境中的智慧體提供支援。透過 Project Think 及其所引入的基元，我們正在補足那些缺失的元件，讓這些智慧體變得更加強大：持久化工作區、沙箱化程式碼執行、持久化的長時間執行任務、結構化安全性、子智慧體協調，以及自我撰寫的擴充功能。
該產品現已推出預覽版。我們與您攜手共進，並真誠地期待看到您（以及您的編碼智慧體）使用它創造出的成果。
Think 是 Cloudflare Agents SDK 的一部分，作為 @cloudflare/think 套件提供。本文中描述的功能目前處於預覽階段。API 可能會在我們納入回饋後發生變更。請查閱文件和範例以開始使用。