Project Think: Xây dựng thế hệ AI agent tiếp theo trên Cloudflare

• Cloudflare công bố Project Think, phiên bản thế hệ tiếp theo của Agents SDK, cung cấp các primitive cốt lõi mới cho agent chạy dài hạn như thực thi bền vững, sub-agent, thực thi mã trong sandbox và session bền vững
• Các coding agent hiện nay có hạn chế là chỉ chạy trên laptop cục bộ, vẫn phát sinh chi phí khi nhàn rỗi và cần thiết lập cũng như quản lý thủ công
• Không giống ứng dụng truyền thống, agent hoạt động theo mô hình 1:1 (một instance cho mỗi người dùng và mỗi tác vụ), nên để hỗ trợ hàng chục triệu session đồng thời thì cấu trúc chi phí dựa trên container là không bền vững
• Tận dụng mô hình actor dựa trên Durable Objects, agent có chi phí tính toán bằng 0 khi ngủ, tự động thức dậy khi nhận thông điệp, từ đó đạt được hiệu quả kinh tế để mở rộng quy mô lớn
• Là làn sóng thứ ba của AI agent, dự án hướng tới agent như hạ tầng (bền vững, phân tán, serverless, bảo mật theo cấu trúc), với mục tiêu trở thành nền tảng để mọi nhà phát triển có thể xây dựng và triển khai agent cho hàng tỷ người dùng

---

Tổng quan về Project Think

• Đây là phiên bản thế hệ tiếp theo của Cloudflare Agents SDK, cung cấp một bộ primitive mới để xây dựng agent chạy dài hạn cùng lớp cơ sở tích hợp chúng lại
• Các primitive chính gồm: thực thi bền vững (fibers), sub-agent, session bền vững, thực thi mã trong sandbox, execution ladder, và self-authored extensions
• Có thể dùng từng primitive riêng lẻ hoặc bắt đầu nhanh thông qua lớp cơ sở Think

Những giới hạn hiện tại của coding agent

• Các công cụ như Pi, OpenClaw, Claude Code và Codex đã chứng minh rằng khi trao cho LLM khả năng đọc file, viết mã, chạy và học hỏi thì nó có thể hoạt động như một trợ lý đa năng
• Những coding agent này không chỉ dùng cho code mà còn có thể quản lý lịch, phân tích dataset, đàm phán mua hàng, khai thuế và tự động hóa quy trình nghiệp vụ
• Mô thức luôn giống nhau: agent đọc ngữ cảnh, suy luận, viết mã để hành động, quan sát kết quả rồi lặp lại → mã là phương tiện phổ quát của hành động
• Các giới hạn hiện tại:
  • Chỉ chạy trên laptop hoặc VPS đắt tiền: không thể chia sẻ, cộng tác hay chuyển đổi giữa các thiết bị
  • Vẫn phát sinh chi phí khi nhàn rỗi: chi phí cố định hàng tháng tăng vọt khi mở rộng theo nhóm hoặc công ty
  • Cần cài đặt và quản lý thủ công: cài dependency, quản lý cập nhật, thiết lập xác thực và secret

Vấn đề cấu trúc của agent: mô hình 1:1

• Ứng dụng truyền thống có một instance phục vụ nhiều người dùng, nhưng agent là 1:1 — mỗi agent là một instance riêng cho một người dùng và một tác vụ
• Nếu 100 triệu lao động tri thức đều dùng trợ lý agent, hệ thống sẽ cần hàng chục triệu session đồng thời
• Với cấu trúc chi phí theo từng container hiện nay thì điều này không bền vững, nên cần một nền tảng khác

Agent chạy dài hạn

• Các agent hiện tại mang tính tạm thời (ephemeral): biến mất khi session kết thúc và dừng lại khi laptop chuyển sang chế độ ngủ
• Agents SDK, dựa trên Durable Objects, cung cấp cho mọi agent danh tính, trạng thái bền vững và khả năng tự khởi động khi nhận thông điệp
• Với mô hình actor, mỗi agent là một thực thể có thể định địa chỉ, sở hữu cơ sở dữ liệu SQLite riêng, và có chi phí tính toán bằng 0 khi ngủ
• Khi xảy ra các sự kiện như HTTP request, thông điệp WebSocket, lịch báo thức hoặc email đến, nền tảng sẽ đánh thức agent và nạp lại trạng thái
• So sánh Durable Objects với VM/container:
  • Chi phí khi nhàn rỗi: VM luôn chịu toàn bộ chi phí tính toán, còn DO là 0 (ngủ)
  • Mở rộng quy mô: VM cần provisioning thủ công, còn DO tự động mở rộng theo từng agent
  • Trạng thái: VM cần DB bên ngoài, còn DO có SQLite tích hợp
  • Khôi phục: VM phải tự xây dựng, còn DO được nền tảng tự khởi động lại và giữ nguyên trạng thái
  • Định tuyến: VM phải tự dựng load balancer và sticky session, còn DO có ánh xạ tên → agent tích hợp sẵn
  • Với 10.000 agent (mỗi agent chỉ hoạt động 1% thời gian): VM cần 10.000 instance chạy liên tục, còn DO chỉ khoảng 100 agent đang hoạt động
• Chi phí biên để tạo một agent mới gần như bằng 0 → có thể áp dụng mô hình agent “một cho mỗi người dùng”, “một cho mỗi tác vụ”, hoặc “một cho mỗi luồng email”

Thực thi bền vững: Fibers

• Một lần gọi LLM có thể kéo dài 30 giây, còn vòng lặp agent nhiều lượt có thể chạy lâu hơn; trong thời gian đó môi trường thực thi có thể biến mất do deploy, nền tảng khởi động lại hoặc giới hạn tài nguyên
• runFiber() là một lần gọi hàm bền vững được đăng ký vào SQLite trước khi bắt đầu thực thi; có thể tạo checkpoint bằng stash() và khôi phục sau khi khởi động lại qua onFiberRecovered
• SDK sẽ tự động giữ agent hoạt động trong lúc fiber đang chạy, không cần cấu hình đặc biệt
• Với các tác vụ kéo dài vài phút, có thể dùng keepAlive() / keepAliveWhile() để tránh bị loại bỏ
• Với các công việc dài hơn như pipeline CI, review thiết kế hay tạo video, hệ thống sẽ lưu job ID rồi chuyển sang ngủ sau khi khởi chạy tác vụ và thức dậy khi có callback

Sub-agent: Facets

• Không nhất thiết một agent duy nhất phải làm mọi việc
• Sub-agent là các Durable Object con được colocate với agent cha, mỗi cái có SQLite và ngữ cảnh thực thi riêng biệt
• Dựa trên Facets, chúng được đặt cùng vị trí với agent cha, và không có chuyện chia sẻ dữ liệu ngầm giữa các sub-agent
• Độ trễ RPC tới sub-agent ở mức như gọi hàm, và TypeScript có thể phát hiện sai cách dùng ngay từ lúc biên dịch

Session bền vững: Session API

• Những agent chạy theo ngày hoặc theo tuần cần nhiều hơn một danh sách tin nhắn phẳng thông thường
• Session API thử nghiệm mô hình hóa hội thoại dưới dạng cấu trúc cây, với mỗi tin nhắn có parent_id
  • Forking: khám phá các phương án thay thế mà không làm mất nhánh gốc
  • Nén không phá hủy: tóm tắt thay vì xóa các tin nhắn cũ
  • Tìm kiếm toàn văn: tìm kiếm full-text trên toàn bộ lịch sử hội thoại dựa trên FTS5
• Có thể dùng trực tiếp trong lớp cơ sở Agent và cũng đóng vai trò là lớp lưu trữ cho lớp cơ sở Think

Từ gọi công cụ sang thực thi mã

• Cách gọi công cụ truyền thống là: model gọi tool → thu kết quả về context window → lặp lại; khi số tool tăng lên thì chi phí và độ kém hiệu quả cũng tăng theo
• 100 file = 100 lần qua lại với model
• Model giỏi viết mã để sử dụng hệ thống hơn là chơi trò gọi tool — đây là insight cốt lõi của @cloudflare/codemode
• Thay vì gọi tool tuần tự, LLM sẽ viết một chương trình duy nhất xử lý toàn bộ tác vụ
• Ví dụ về máy chủ MCP cho Cloudflare API: chỉ cần lộ ra 2 tool (search(), execute()) thì tiêu tốn khoảng 1.000 token, so với khoảng 1,17 triệu token nếu mỗi endpoint là một tool → giảm 99,9%

Sandbox an toàn: Dynamic Workers

• Nếu model viết mã thay mặt người dùng, thì môi trường thực thi cho đoạn mã đó trở thành câu hỏi cốt lõi
• Dynamic Workers là các môi trường cô lập V8 mới được tạo ở runtime trong vài mili giây, với bộ nhớ cỡ vài MB
  • So với container, chúng nhanh hơn khoảng 100 lần và có thể hiệu quả bộ nhớ hơn tới 100 lần
  • Có thể tạo mới cho mỗi request rồi hủy đi sau khi chạy mã xong
• Thiết kế cốt lõi là mô hình capability — không phải giới hạn một cỗ máy đa năng, mà gần như bắt đầu từ trạng thái không có quyền (globalOutbound: null, không có quyền truy cập mạng), sau đó nhà phát triển cấp quyền tường minh theo từng tài nguyên thông qua binding
• Tư duy chuyển từ “làm sao ngăn nó làm quá nhiều?” sang “cho phép chính xác những gì nó có thể làm?”

Execution ladder

• Đây là phổ môi trường tính toán mà agent có thể leo thang dần theo nhu cầu:
  • Tier 0 — Workspace: hệ thống file ảo bền vững dựa trên SQLite + R2, hỗ trợ đọc, ghi, sửa, tìm kiếm, grep, diff và chạy @cloudflare/shell
  • Tier 1 — Dynamic Worker: chạy JavaScript do LLM tạo ra trong môi trường cô lập sandbox không có truy cập mạng, chạy @cloudflare/codemode
  • Tier 2 — thêm npm: @cloudflare/worker-bundler lấy package từ registry, bundle bằng esbuild rồi nạp vào Dynamic Worker, nên import { z } from "zod" hoạt động nguyên trạng
  • Tier 3 — trình duyệt headless: dùng Cloudflare Browser Run để điều hướng, click, trích xuất, chụp ảnh màn hình; hữu ích với các dịch vụ không hỗ trợ MCP hoặc API
  • Tier 4 — Cloudflare Sandbox: chạy git clone, npm test, cargo build... trong môi trường đã cấu hình toolchain, repo và dependency, đồng bộ hai chiều với Workspace
• Nguyên tắc thiết kế cốt lõi: chỉ riêng Tier 0 cũng phải đủ hữu ích cho agent, còn mỗi tier phía trên đều là bổ sung

Các khối xây dựng, không phải framework

• Tất cả primitive đều được cung cấp dưới dạng package độc lập: Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• Có thể kết hợp trực tiếp với lớp cơ sở Agent để dùng workspace, thực thi mã và phân giải package ở runtime mà không cần đưa vào một framework riêng

Toàn bộ stack nền tảng

• Cô lập theo từng agent: Durable Objects — mỗi agent là một thế giới riêng
• Chi phí bằng 0 khi nhàn rỗi: DO Hibernation — $0 cho tới khi agent thức dậy
• Trạng thái bền vững: DO SQLite — kho lưu trữ có thể query và transaction
• Hệ thống file bền vững: Workspace(SQLite + R2)
• Thực thi mã trong sandbox: Dynamic Workers + @cloudflare/codemode
• Dependency runtime: @cloudflare/worker-bundler — import * from react hoạt động nguyên trạng
• Tự động hóa web: Browser Run
• Truy cập OS đầy đủ: Sandboxes — git, compiler, test runner
• Lập lịch chạy: DO Alarms + Fibers
• Streaming thời gian thực: WebSockets
• Kết nối công cụ bên ngoài: MCP
• Điều phối giữa các agent: sub-agent (Facets) — RPC có kiểu
• Truy cập model: AI Gateway + Workers AI (hoặc model riêng)

Lớp cơ sở Think

• Đây là bộ khung tích hợp xử lý toàn bộ vòng đời chat gồm vòng lặp agent, lưu bền vững tin nhắn, streaming, thực thi tool, nối lại stream và extension
• Chỉ cần subclass tối thiểu: triển khai phương thức getModel() là đã có thể vận hành một chat agent với streaming, lưu bền vững, tạm dừng/hủy, xử lý lỗi, stream có thể nối lại, và hệ thống file workspace tích hợp sẵn
• Triển khai bằng npx wrangler deploy
• Các mục có thể override: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• Mỗi lượt sẽ chạy toàn bộ vòng lặp agentic: lắp ráp ngữ cảnh (lệnh cơ bản + mô tả tool + skill + memory + lịch sử hội thoại) → gọi streamText → thực thi các lệnh gọi tool (cắt ngắn output để tránh bùng nổ context) → thêm kết quả → lặp lại cho đến khi model hoàn tất hoặc chạm giới hạn số bước

Lifecycle hook

• Think cung cấp hook ở mọi giai đoạn của lượt chat mà không cần chiếm toàn quyền pipeline:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• Có thể chuyển sang model rẻ hơn cho các lượt sau, giới hạn tool, truyền context từ client, ghi log phân tích mọi lệnh gọi tool hoặc tự động kích hoạt lượt tiếp theo mà không cần thay thế onChatMessage

Bộ nhớ bền vững và hội thoại dài

• Think được xây dựng trên Session API, nên tích hợp sẵn cấu trúc tin nhắn dạng cây và phân nhánh
• Bộ nhớ bền vững thông qua context block: các phần có cấu trúc trong system prompt mà model có thể đọc và cập nhật theo thời gian, vẫn được giữ nguyên cả khi agent ngủ
• Model có thể nhìn thấy dạng như MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens] và chủ động ghi nhớ
• Mỗi agent có thể chạy nhiều cuộc hội thoại, và việc forking cho phép khám phá hướng khác mà không làm mất cuộc hội thoại gốc
• Khi context tăng lên sẽ có nén không phá hủy: tóm tắt thay vì xóa tin nhắn cũ, còn toàn bộ lịch sử vẫn được giữ trong SQLite
• Tìm kiếm dựa trên FTS5: có thể query lịch sử hội thoại trong một session hoặc trên toàn bộ session; agent cũng có thể tự tìm lại quá khứ của mình bằng tool search_context

Tích hợp toàn bộ execution ladder

• Think hợp nhất toàn bộ execution ladder chỉ bằng giá trị trả về của getTools(): công cụ workspace, công cụ thực thi, công cụ trình duyệt, công cụ sandbox và công cụ extension đều có thể cấu hình cùng lúc

Self-authored Extensions

• Agent có thể tự viết extension cho chính mình: đó là các chương trình TypeScript chạy trong Dynamic Workers, khai báo quyền truy cập mạng và quyền thao tác workspace
• ExtensionManager của Think sẽ bundle extension (có thể kèm dependency npm), nạp vào Dynamic Worker và đăng ký tool mới
• Extension được lưu bền vững trong kho DO, nên vẫn tồn tại cả khi agent ngủ
• Ví dụ: khi người dùng hỏi về PR, hệ thống có thể tạo ra tool github_create_pr dù nó chưa hề tồn tại cách đó 30 giây
• Đây là vòng lặp tự cải thiện thông qua mã, không phải qua fine-tuning hay RLHF — TypeScript được sandbox, có thể audit và có thể thu hồi

RPC cho sub-agent

• Think cũng có thể hoạt động như sub-agent được gọi từ agent cha bằng chat() qua RPC, hỗ trợ streaming event thông qua callback
• Mỗi agent con có cây hội thoại, memory, tool và model riêng; agent cha không cần biết các chi tiết bên trong

Bắt đầu

• Project Think hiện ở trạng thái experimental, bề mặt API tương đối ổn định nhưng sẽ còn tiếp tục phát triển
• Cloudflare đã dùng nó nội bộ để xây dựng hạ tầng background agent của riêng mình
• Think dùng cùng giao thức WebSocket với @cloudflare/ai-chat, nên các component UI hiện có có thể dùng nguyên trạng
• Nếu đã xây dựng trên AIChatAgent thì không cần thay đổi mã phía client

Ba làn sóng của AI agent

• Làn sóng thứ nhất — chatbot: không có trạng thái, phản ứng thụ động, mong manh, mỗi cuộc trò chuyện đều bắt đầu lại từ đầu, không có memory, tool hay khả năng hành động, chỉ hữu ích cho việc trả lời câu hỏi
• Làn sóng thứ hai — coding agent: giữ trạng thái, dùng tool, như Pi, Claude Code, OpenClaw và Codex; có thể đọc codebase, viết mã, chạy và lặp lại; chứng minh rằng LLM với đúng công cụ là một cỗ máy đa năng, nhưng vẫn chỉ chạy cho một người dùng trên laptop và không có đảm bảo về độ bền vững
• Làn sóng thứ ba — agent như hạ tầng: bền vững, phân tán, an toàn theo cấu trúc, serverless, chạy trên Internet, sống sót qua sự cố, có chi phí bằng 0 khi nhàn rỗi và thực thi bảo mật thông qua kiến trúc chứ không chỉ hành vi