Project Think: สร้าง AI เอเจนต์ยุคถัดไปบน Cloudflare

• Cloudflare ประกาศ Project Think ซึ่งเป็นเวอร์ชันถัดไปของ Agents SDK โดยมอบ primitive หลักชุดใหม่สำหรับเอเจนต์ที่ทำงานระยะยาว เช่น durable execution, sub-agent, การรันโค้ดแบบ sandbox และ persistent session
• เอเจนต์เขียนโค้ดในปัจจุบันมีข้อจำกัดคือมักรันได้แค่บนโน้ตบุ๊กในเครื่อง, มีค่าใช้จ่ายแม้ตอน idle และ ต้องติดตั้งตั้งค่าและดูแลเองแบบแมนนวล
• ต่างจากแอปพลิเคชันทั่วไป เอเจนต์ทำงานในโมเดลแบบ 1:1 (หนึ่งผู้ใช้·หนึ่งงานต่อหนึ่งอินสแตนซ์) ดังนั้นหากต้องรองรับเซสชันพร้อมกันระดับหลายสิบล้าน การใช้โครงสร้างต้นทุนแบบคอนเทนเนอร์จะไม่ยั่งยืน
• ใช้ actor model บน Durable Objects เพื่อให้เอเจนต์มีค่า compute เป็นศูนย์เมื่ออยู่ในโหมดพัก และตื่นอัตโนมัติเมื่อได้รับข้อความ จึงได้ ความคุ้มค่าด้านการสเกลในระดับใหญ่
• ในฐานะคลื่นลูกที่สามของ AI agent ระบบนี้มุ่งสู่ เอเจนต์ในฐานะโครงสร้างพื้นฐาน (ทนทาน, กระจายตัว, serverless, มีความปลอดภัยเชิงโครงสร้าง) โดยตั้งเป้าเป็นแพลตฟอร์มที่นักพัฒนาทุกคนใช้สร้างและดีพลอยเอเจนต์สำหรับผู้ใช้ระดับหลายพันล้านคนได้

---

ภาพรวมของ Project Think

• เป็นเวอร์ชันถัดไปของ Cloudflare Agents SDK ที่มีทั้งชุด primitive ใหม่สำหรับสร้างเอเจนต์ทำงานระยะยาว และ base class สำหรับรวมความสามารถเหล่านี้เข้าด้วยกัน
• primitive หลักได้แก่ durable execution (fibers), sub-agent, persistent session, การรันโค้ดแบบ sandbox, execution ladder และ self-authored extensions
• สามารถใช้ primitive แต่ละตัวแยกกันได้ หรือเริ่มต้นอย่างรวดเร็วผ่าน Think base class

ข้อจำกัดของ coding agent ในปัจจุบัน

• เครื่องมืออย่าง Pi, OpenClaw, Claude Code และ Codex พิสูจน์แล้วว่าเมื่อให้ LLM อ่านไฟล์·เขียนโค้ด·รันโค้ด·เรียนรู้ได้ ก็จะทำงานได้คล้าย ผู้ช่วยอเนกประสงค์
• เอเจนต์เขียนโค้ดเหล่านี้นำไปใช้ได้ไม่ใช่แค่กับโค้ด แต่ยังรวมถึงการจัดการปฏิทิน, วิเคราะห์ชุดข้อมูล, ต่อรองการซื้อ, ยื่นภาษี และทำเวิร์กโฟลว์ธุรกิจอัตโนมัติ
• รูปแบบการทำงานเหมือนกันเสมอ: เอเจนต์อ่านคอนเท็กซ์, ให้เหตุผล, เขียนโค้ดเพื่อกระทำ, สังเกตผลลัพธ์ แล้วทำซ้ำ → โค้ดคือสื่อกลางสากลของการลงมือทำ
• ข้อจำกัดในตอนนี้:
  • รันได้แค่บนโน้ตบุ๊กหรือ VPS ราคาแพง: แชร์, ทำงานร่วมกัน หรือสลับอุปกรณ์ไม่ได้
  • มีค่าใช้จ่ายแม้ตอน idle: ค่าใช้จ่ายรายเดือนแบบคงที่พุ่งสูงมากเมื่อขยายไปทั้งทีมหรือทั้งบริษัท
  • ต้องติดตั้งและดูแลเอง: ติดตั้ง dependency, จัดการอัปเดต, ตั้งค่าการยืนยันตัวตนและ secret

ปัญหาเชิงโครงสร้างของเอเจนต์: โมเดล 1:1

• แอปพลิเคชันแบบดั้งเดิมใช้อินสแตนซ์เดียวให้บริการผู้ใช้จำนวนมาก แต่ เอเจนต์เป็นแบบ 1:1 — เอเจนต์แต่ละตัวเป็นอินสแตนซ์เฉพาะสำหรับผู้ใช้หนึ่งคนและงานหนึ่งงาน
• หากแรงงานสายความรู้ 100 ล้านคนใช้ผู้ช่วยเอเจนต์กันคนละตัว จะต้องรองรับ เซสชันพร้อมกันระดับหลายสิบล้าน
• ด้วย โครงสร้างต้นทุนต่อคอนเทนเนอร์ แบบปัจจุบัน สิ่งนี้ไม่ยั่งยืน จึงต้องการรากฐานแบบใหม่

เอเจนต์ที่ทำงานระยะยาว

• เอเจนต์ปัจจุบันเป็นแบบ ชั่วคราว (ephemeral): หายไปเมื่อจบเซสชัน และหยุดทำงานเมื่อโน้ตบุ๊กเข้าสลีป
• Agents SDK สร้างบน Durable Objects เพื่อมอบ identity, state แบบคงอยู่ และการเริ่มทำงานอัตโนมัติเมื่อได้รับข้อความให้กับเอเจนต์ทุกตัว
• actor model: เอเจนต์แต่ละตัวเป็นเอนทิตีที่ระบุที่อยู่ได้ มี ฐานข้อมูล SQLite ของตัวเอง และมีค่า compute เป็นศูนย์เมื่ออยู่ในโหมดพัก
• เมื่อมีเหตุการณ์อย่าง HTTP request, ข้อความ WebSocket, scheduled alarm หรืออีเมลขาเข้า แพลตฟอร์มจะปลุกเอเจนต์ขึ้นมาและโหลดสถานะกลับมา
• เปรียบเทียบ Durable Objects กับ VM/คอนเทนเนอร์:
  • ค่าใช้จ่ายตอน idle: VM ต้องจ่ายค่า compute เต็มตลอดเวลา ส่วน DO เป็น ศูนย์ (ขณะพัก)
  • การสเกล: VM ต้อง provision เอง ส่วน DO สเกลอัตโนมัติต่อเอเจนต์
  • สถานะ: VM ต้องใช้ฐานข้อมูลภายนอก ส่วน DO มี SQLite ในตัว
  • การกู้คืน: VM ต้องสร้างเอง ส่วน DO รีสตาร์ตอัตโนมัติโดยแพลตฟอร์มและเก็บสถานะไว้
  • การ route: VM ต้องทำ load balancer และ sticky session เอง ส่วน DO มี การแมปชื่อ→เอเจนต์ในตัว
  • เอเจนต์ 10,000 ตัว (active ตัวละ 1%): VM ต้องมี 10,000 อินสแตนซ์ตลอดเวลา ส่วน DO มี active แค่ราว 100 ตัว
• ต้นทุนส่วนเพิ่มในการสร้างเอเจนต์ใหม่แทบจะเป็น ศูนย์ → ทำให้โมเดลเอเจนต์แบบ “หนึ่งตัวต่อผู้ใช้”, “หนึ่งตัวต่องาน”, “หนึ่งตัวต่ออีเมลเธรด” เป็นไปได้

Durable execution: Fibers

• การเรียก LLM อาจใช้เวลา 30 วินาที และลูปเอเจนต์หลายเทิร์นอาจนานกว่านั้นมาก ระหว่างทางสภาพแวดล้อมการรันอาจหายไปได้ (เช่น ดีพลอยใหม่, แพลตฟอร์มรีสตาร์ต, ข้อจำกัดทรัพยากร)
• runFiber() คือ การเรียกฟังก์ชันแบบ durable ที่ถูกลงทะเบียนใน SQLite ก่อนเริ่มรัน และสามารถสร้าง checkpoint ด้วย stash() พร้อมกู้คืนเมื่อรีสตาร์ตผ่าน onFiberRecovered
• SDK จะคอยทำให้เอเจนต์คงอยู่ระหว่างการรัน fiber โดยอัตโนมัติ ไม่ต้องตั้งค่าอะไรเป็นพิเศษ
• งานที่กินเวลาระดับนาทีสามารถป้องกันการถูกไล่ออกได้ด้วย keepAlive() / keepAliveWhile()
• สำหรับงานที่นานกว่านั้น เช่น CI pipeline, การรีวิวดีไซน์ หรือการสร้างวิดีโอ สามารถ เก็บ job ID แล้วเข้าสู่โหมดพัก หลังเริ่มงาน และค่อยตื่นขึ้นมาเมื่อมี callback

Sub-agent: Facets

• ไม่จำเป็นที่เอเจนต์ตัวเดียวต้องทำทุกอย่างเอง
• sub-agent คือ Durable Objects ลูกที่ถูกวางร่วมกับตัวแม่ โดยแต่ละตัวมี SQLite และ execution context ที่แยกกัน
• ใช้ Facets เพื่อให้วางอยู่ร่วมกับเอเจนต์แม่ และไม่มีการแชร์ข้อมูลกันโดยนัยระหว่าง sub-agent
• ความหน่วงของ RPC ระหว่าง sub-agent อยู่ในระดับการเรียกฟังก์ชัน และ TypeScript สามารถตรวจจับการใช้ผิดตั้งแต่ตอนคอมไพล์

Persistent session: Session API

• เอเจนต์ที่ทำงานเป็นวันหรือเป็นสัปดาห์ต้องการมากกว่า รายการข้อความแบบแบนทั่วไป
• Session API แบบ experimental โมเดลบทสนทนาเป็น โครงสร้างต้นไม้ โดยแต่ละข้อความมี parent_id
  • การแตกแขนง (forking): สำรวจทางเลือกอื่นได้โดยไม่สูญเสียเส้นทางเดิม
  • การบีบอัดแบบไม่ทำลาย: ไม่ลบข้อความเก่า แต่ สรุปย่อ แทน
  • การค้นหาแบบ full-text: ค้นหาทั้งประวัติการสนทนาด้วย FTS5
• ใช้ได้โดยตรงจาก Agent base class และทำหน้าที่เป็นชั้นเก็บข้อมูลของ Think base class

จากการเรียกเครื่องมือสู่การรันโค้ด

• แนวทางเรียกเครื่องมือแบบเดิม: โมเดลเรียกเครื่องมือ → รับผลกลับเข้าคอนเท็กซ์วินโดว์ → ทำซ้ำ ซึ่งยิ่งมีเครื่องมือมากก็ยิ่ง แพงและไม่มีประสิทธิภาพ
• ไฟล์ 100 ไฟล์ = ต้องไปกลับกับโมเดล 100 รอบ
• โมเดล เขียนโค้ดเพื่อใช้งานระบบเก่งกว่า การเล่นเกมเรียกเครื่องมือ — นี่คือแนวคิดหลักของ @cloudflare/codemode
• แทนที่จะเรียกเครื่องมือทีละขั้น LLM จะเขียน โปรแกรมเดียวที่จัดการทั้งงาน
• กรณีของ Cloudflare API MCP server: เปิดเผยเพียง 2 เครื่องมือ (search(), execute()) ใช้ประมาณ 1,000 โทเค็น เทียบกับแนวทางเครื่องมือต่อ endpoint ที่ใช้ราว 1.17 ล้านโทเค็น → ลดลง 99.9%

Sandbox ที่ปลอดภัย: Dynamic Workers

• ถ้าโมเดลจะเขียนโค้ดแทนผู้ใช้ คำถามสำคัญก็คือควรให้โค้ดนั้นรันที่ไหน
• Dynamic Workers: สภาพแวดล้อมแยกใหม่แบบ V8 isolate ที่สร้างขึ้นตอนรันได้ในระดับมิลลิวินาที ใช้หน่วยความจำเพียงไม่กี่เมกะไบต์
  • เมื่อเทียบกับคอนเทนเนอร์ เร็วขึ้นราว 100 เท่า และมีประสิทธิภาพด้านหน่วยความจำสูงสุด 100 เท่า
  • สร้างใหม่ต่อคำขอได้ และทิ้งได้ทันทีหลังรันโค้ดเสร็จ
• แกนหลักของการออกแบบคือ capability model — ไม่ใช่การจำกัดเครื่องจักรอเนกประสงค์ แต่เริ่มจากสถานะที่แทบ ไม่มีสิทธิ์ใดเลย (globalOutbound: null, ไม่มีสิทธิ์เข้าถึงเครือข่าย) แล้วให้นักพัฒนามอบ สิทธิ์แบบชัดเจนรายทรัพยากร ผ่าน binding
• เป็นการเปลี่ยนจากคำถามว่า “จะกันไม่ให้สิ่งนี้ทำมากเกินไปได้อย่างไร?” ไปเป็น “จะอนุญาตให้มันทำอะไรได้อย่างแม่นยำบ้าง?”

Execution Ladder

• สเปกตรัมของสภาพแวดล้อม compute ที่เอเจนต์สามารถไต่ระดับขึ้นได้ตามความจำเป็น:
  • Tier 0 — Workspace: ระบบไฟล์เสมือนแบบ durable บน SQLite + R2 รองรับ read·write·edit·search·grep·diff และรัน @cloudflare/shell
  • Tier 1 — Dynamic Worker: รัน JavaScript ที่ LLM สร้างขึ้นใน sandbox isolate ที่ไม่มีสิทธิ์เข้าถึงเครือข่าย พร้อม @cloudflare/codemode
  • Tier 2 — เพิ่ม npm: @cloudflare/worker-bundler ดึงแพ็กเกจจาก registry แล้ว bundle ด้วย esbuild เพื่อโหลดเข้า Dynamic Worker ทำให้ import { z } from "zod" ใช้งานได้ตรง ๆ
  • Tier 3 — Headless browser: ใช้ Cloudflare Browser Run เพื่อเปิดหน้าเว็บ, คลิก, ดึงข้อมูล, ถ่ายภาพหน้าจอ เหมาะกับบริการที่ไม่รองรับ MCP หรือ API
  • Tier 4 — Cloudflare Sandbox: รัน git clone, npm test, cargo build ฯลฯ ในสภาพแวดล้อมที่มี toolchain, repo และ dependency พร้อมใช้งาน และซิงก์กับ Workspace ได้สองทาง
• หลักการออกแบบสำคัญ: Tier 0 เพียงอย่างเดียวก็ต้องทำให้เอเจนต์มีประโยชน์ได้ และแต่ละ tier เป็นเพียงส่วนเสริม

เป็น building block ไม่ใช่เฟรมเวิร์ก

• primitive ทุกตัวถูกแยกเป็น แพ็กเกจอิสระ: Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• สามารถผูกเข้ากับ Agent base class โดยตรงเพื่อใช้ workspace, การรันโค้ด และการ resolve package ตอนรันได้ โดยไม่ต้องรับเฟรมเวิร์กใหม่ทั้งชุด

สแตกทั้งแพลตฟอร์ม

• การแยกต่อเอเจนต์: Durable Objects — เอเจนต์แต่ละตัวมีโลกของตัวเอง
• ค่าใช้จ่ายเป็นศูนย์เมื่อ idle: DO Hibernation — $0 จนกว่าเอเจนต์จะตื่น
• สถานะแบบคงอยู่: DO SQLite — ที่เก็บข้อมูลที่ query และทำ transaction ได้
• ระบบไฟล์แบบคงอยู่: Workspace (SQLite + R2)
• การรันโค้ดแบบ sandbox: Dynamic Workers + @cloudflare/codemode
• dependency ตอนรัน: @cloudflare/worker-bundler — ใช้ import * from react ได้ตรง ๆ
• เว็บอัตโนมัติ: Browser Run
• เข้าถึง OS เต็มรูปแบบ: Sandboxes — git, คอมไพเลอร์, test runner
• การรันตามตารางเวลา: DO Alarms + Fibers
• สตรีมมิงแบบเรียลไทม์: WebSockets
• เชื่อมต่อเครื่องมือภายนอก: MCP
• การประสานงานระหว่างเอเจนต์: sub-agent (Facets) — type RPC
• การเข้าถึงโมเดล: AI Gateway + Workers AI (หรือโมเดลของตนเอง)

Think base class

• เป็นฮาร์เนสรวมที่ดูแล วงจรชีวิตของแชตทั้งหมด ไม่ว่าจะเป็น agent loop, การเก็บข้อความแบบคงอยู่, สตรีมมิง, การรันเครื่องมือ, การ resume stream และส่วนขยาย
• subclass ขั้นต่ำ: แค่ implement เมธอด getModel() ก็จะได้แชตเอเจนต์ที่มีสตรีมมิง, persistence, การ interrupt/cancel, การจัดการข้อผิดพลาด, สตรีมที่ resume ได้ และระบบไฟล์ workspace ในตัว
• ดีพลอยด้วย npx wrangler deploy
• จุดที่ override ได้: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• ในแต่ละเทิร์นจะรัน agentic loop เต็มรูปแบบ: ประกอบคอนเท็กซ์ (คำสั่งพื้นฐาน + คำอธิบายเครื่องมือ + ทักษะ + ความทรงจำ + ประวัติการสนทนา) → เรียก streamText → รันการเรียกเครื่องมือ (ตัดทอนเอาต์พุตเพื่อไม่ให้คอนเท็กซ์บวม) → เพิ่มผลลัพธ์ → ทำซ้ำจนกว่าโมเดลจะเสร็จหรือถึงขีดจำกัดสเต็ป

Lifecycle hooks

• Think ไม่ได้ผูกขาดทั้ง pipeline แต่เปิด hook ในทุกขั้นของแชตเทิร์น:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• ทำสิ่งต่าง ๆ ได้โดยไม่ต้องแทนที่ onChatMessage เช่น สลับไปใช้โมเดลราคาถูกกว่าในเทิร์นถัดไป, จำกัดเครื่องมือ, ส่งคอนเท็กซ์จากไคลเอนต์, log วิเคราะห์การเรียกเครื่องมือทั้งหมด หรือ trigger เทิร์นถัดไปอัตโนมัติ

Persistent memory และบทสนทนายาว

• Think ถูกสร้างบน Session API จึงมีข้อความแบบโครงสร้างต้นไม้และการแตกแขนงในตัว
• ความจำแบบคงอยู่ผ่าน context blocks: ส่วนที่มีโครงสร้างใน system prompt ซึ่งโมเดลอ่านและอัปเดตได้ตามเวลา และยังคงอยู่ข้ามช่วงพัก
• โมเดลสามารถเห็นข้อความในรูปแบบ "MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]" และ จดจำเชิงรุก ได้
• เอเจนต์หนึ่งตัวสามารถรัน หลายบทสนทนา ได้ และใช้การแตกแขนงเพื่อสำรวจทิศทางอื่นโดยไม่สูญเสียบทสนทนาเดิม
• เมื่อคอนเท็กซ์โตขึ้นจะมี การบีบอัดแบบไม่ทำลาย: สรุปข้อความเก่าแทนการลบ และเก็บประวัติทั้งหมดไว้ใน SQLite
• การค้นหาด้วย FTS5: query ประวัติการสนทนาได้ทั้งภายในเซสชันเดียวหรือข้ามทุกเซสชัน และเอเจนต์เองก็ใช้เครื่องมือ search_context เพื่อค้นหาอดีตของตัวเองได้

รวม Execution Ladder ทั้งหมด

• Think รวม execution ladder ทั้งหมด ผ่านสิ่งที่ getTools() ส่งกลับเพียงชุดเดียว: ตั้งค่าเครื่องมือ workspace, execution, browser, sandbox และ extension ได้พร้อมกัน

Self-authored Extensions

• เอเจนต์สามารถ เขียนส่วนขยายของตัวเองได้โดยตรง: เป็นโปรแกรม TypeScript ที่รันใน Dynamic Workers และประกาศสิทธิ์เข้าถึงเครือข่ายกับสิทธิ์ทำงานบน workspace
• ExtensionManager ของ Think จะ bundle ส่วนขยาย (รวม dependency จาก npm ได้), โหลดเข้า Dynamic Worker และลงทะเบียนเป็นเครื่องมือใหม่
• ส่วนขยายจะถูก เก็บถาวรใน DO storage และอยู่รอดได้แม้ตอนพัก
• ตัวอย่าง: เมื่อผู้ใช้ถามเกี่ยวกับ PR ก็อาจมีเครื่องมือ github_create_pr ที่เพิ่งถูกสร้างขึ้นเมื่อ 30 วินาทีก่อนหน้า
• ไม่ใช่ fine-tuning หรือ RLHF แต่เป็น ลูปการพัฒนาตนเองผ่านโค้ด — เป็น TypeScript ที่ถูก sandbox, audit ได้ และเพิกถอนได้

Sub-agent RPC

• Think ยังทำงานเป็น sub-agent ที่ถูกเรียกจาก parent ผ่าน chat() over RPC ได้ พร้อมรองรับเหตุการณ์สตรีมมิงผ่าน callback
• child แต่ละตัวมีต้นไม้บทสนทนา, ความทรงจำ, เครื่องมือ และโมเดลของตัวเอง โดย parent ไม่จำเป็นต้องรู้รายละเอียด

เริ่มต้นใช้งาน

• Project Think ยังอยู่ในสถานะ experimental โดยพื้นผิว API มีเสถียรภาพ แต่จะยังพัฒนาต่อไปในอนาคต
• Cloudflare ใช้งานสิ่งนี้ภายในองค์กรแล้วเพื่อสร้างโครงสร้างพื้นฐานสำหรับ background agent ของตัวเอง
• Think ใช้โปรโตคอล WebSocket เดียวกับ @cloudflare/ai-chat ดังนั้นคอมโพเนนต์ UI เดิมจึงใช้งานต่อได้ทันที
• หากสร้างบน AIChatAgent อยู่แล้ว ก็ ไม่ต้องแก้โค้ดฝั่งไคลเอนต์

สามคลื่นของ AI agent

• คลื่นลูกแรก — แชตบอต: ไม่มีสถานะ, ตอบสนองอย่างเดียว, เปราะบาง, เริ่มใหม่ทุกบทสนทนา, ไม่มีความจำ·เครื่องมือ·ความสามารถในการลงมือทำ, มีประโยชน์แค่ตอบคำถาม
• คลื่นลูกที่สอง — coding agent: มีสถานะ, ใช้เครื่องมือได้, มีเครื่องมืออย่าง Pi·Claude Code·OpenClaw·Codex, อ่าน codebase·เขียนโค้ด·รันโค้ด·ทำซ้ำได้, พิสูจน์ว่า LLM ที่มีเครื่องมือเหมาะสมคือ เครื่องจักรอเนกประสงค์ แต่ยังรันบนโน้ตบุ๊กเพื่อผู้ใช้คนเดียวและ ไม่มีหลักประกันเรื่องความทนทาน
• คลื่นลูกที่สาม — เอเจนต์ในฐานะโครงสร้างพื้นฐาน: ทนทาน, กระจายตัว, ปลอดภัยเชิงโครงสร้าง, serverless, รันอยู่บนอินเทอร์เน็ต, อยู่รอดจากความล้มเหลวได้, ไม่มีค่าใช้จ่ายเมื่อ idle และ บังคับใช้ความปลอดภัยผ่านสถาปัตยกรรม ไม่ใช่ผ่านพฤติกรรม