Cloudflare OS คืออะไร? เมื่อ AI Agent ทำงานในบริษัท

ถ้าเห็นชื่อ Cloudflare OS แล้วนึกว่า Cloudflare กำลังทำระบบปฏิบัติการมาแข่งกับ Windows หรือ Linux คำตอบคือไม่ใช่

Cloudflare OS คือ AI Workspace ที่เปิดผ่านเว็บ พนักงานใช้คุยกับ Agent สร้างเอกสาร ทำ Workflow หรือสร้างแอปเล็ก ๆ สำหรับงานของตัวเองได้ โดยบริษัทเป็นคนกำหนดความรู้ เครื่องมือ สิทธิ์ และกฎที่ Agent ต้องปฏิบัติตาม

Cloudflare เปิดซอร์สเวอร์ชันปัจจุบันเมื่อวันที่ 5 สิงหาคม 2026 หลังนำเวอร์ชันแรกไปใช้ภายในบริษัท และเขียนระบบใหม่เป็น v2 จากบทเรียนที่ได้ แต่ใน README ยังระบุว่าเป็น Early Access มีหลายส่วนที่อยู่ระหว่างพัฒนา และยังไม่มี GitHub Release หรือ Tag ให้เลือกใช้แบบเป็นเวอร์ชันนิ่ง

ประเด็นที่น่าสนใจจึงไม่ใช่ว่า Cloudflare ทำแชต AI ได้อีกหนึ่งตัว แต่คือการพยายามตอบคำถามที่องค์กรหลีกเลี่ยงไม่ได้: ถ้า Agent เข้าถึงข้อมูลภายใน เขียนโค้ด สร้างแอป และลงมือเปลี่ยนข้อมูลได้ เราจะควบคุมสิทธิ์ของมันอย่างไรโดยไม่แจก API key กว้าง ๆ ให้ทุกคน

Cloudflare OS มีอะไรอยู่ข้างใน

Cloudflare แบ่งแพลตฟอร์มออกเป็นสามส่วนหลัก ได้แก่ Agent Workspace, Gadgets และ Gatekeepers แต่ละส่วนแก้ปัญหาคนละด้าน

1. Agent Workspace ที่รู้บริบทของบริษัท

Workspace เป็นพื้นที่ทำงานผ่านเบราว์เซอร์ รวมบทสนทนากับ Agent, ไฟล์, ผลลัพธ์, สถานะที่เก็บต่อเนื่อง และ Runtime แยกสำหรับรันโค้ด

องค์กรสามารถเตรียม Context และ Skills ที่อธิบายคำศัพท์ กระบวนการ มาตรฐาน และวิธีทำงานของทีมไว้ล่วงหน้า พนักงานจึงไม่ต้องอธิบายกฎเดิมใหม่ทุกครั้งที่เปิดแชต เช่น รูปแบบข้อเสนอขาย ขั้นตอนรับพนักงาน หรือมาตรฐานรีวิวโค้ดของบริษัท

Agent ยังเขียนโค้ดเพื่อค้น กรอง หรือเชื่อมข้อมูลก่อนส่งผลกลับเข้าโมเดลได้ วิธีนี้เหมาะกับงานที่ต้องประมวลผลข้อมูลจำนวนมากกว่าการยัดข้อมูลทั้งหมดไว้ใน Context Window

2. Gadgets แอปเฉพาะงานที่แก้ต่อได้

เมื่อเอกสารหรือ Spreadsheet ไม่พอ ผู้ใช้สามารถบอก Agent ให้สร้าง Gadget ซึ่งเป็นแอป Full-stack ขนาดเล็ก มี UI, Server, API และ State ของตัวเอง

Gadget แต่ละตัวรันแยกจากกัน Server ทำงานใน Dynamic Worker ส่วน State ใช้ Durable Object Facet พร้อมฐานข้อมูล SQLite แยกจาก Runtime หลัก Client และ Server ติดต่อกันผ่าน Cap'n Web RPC

แนวคิดนี้ต่างจาก SaaS ทั่วไปตรงที่ผู้ใช้แต่ละคนสามารถมีสำเนาแอปของตัวเองและสั่ง AI ให้แก้ความสามารถต่อได้ หากอยากแชร์ มีสองทาง

• แชร์ Gadget ตัวเดิม เพื่อให้ทีมใช้ State เดียวกันและทำงานร่วมกันแบบ Real-time
• แชร์ Blueprint ซึ่งเป็นสำเนาโค้ด เพื่อให้คนอื่นสร้าง Gadget ใหม่ที่มี State และทรัพยากรของตัวเอง

Blueprint ไม่พ่วงข้อมูลใน SQLite, ประวัติการสนทนา, Credential หรือ Resource ที่ต้นฉบับเชื่อมไว้ จึงลดปัญหาการคัดลอกแอปแล้วลากข้อมูลของเจ้าของเดิมติดไปด้วย

3. Gatekeepers ชั้นควบคุมระหว่าง Agent กับระบบจริง

การเชื่อม Agent เข้ากับ GitHub, Google Drive, Notion หรือระบบภายในมักเริ่มจาก API key แต่ Credential แบบนี้มักมีอายุยาวและให้สิทธิ์กว้างเกินงาน

Cloudflare OS ใช้ Gatekeeper เป็น Worker เฉพาะบริการ คั่นระหว่าง Agent หรือ Gadget กับระบบปลายทาง หน้าที่ของมันคือถือ Credential, จัดการ OAuth, จำกัด Resource, กรอง Field, ใส่ Rate Limit, บันทึกการกระทำ และขออนุมัติจากคนก่อน Action ที่มีผลภายนอก

ตัวอย่างเช่น แทนที่จะให้ Agent เข้าถึง GitHub ทั้งองค์กร Gatekeeper อาจอนุญาตให้ดูเฉพาะ Issue ของ Repository หนึ่ง แต่ห้ามอ่าน Source Code และต้องให้คนกดยืนยันก่อน Merge Pull Request

Agent ไม่เห็น Credential โดยตรง โค้ดที่สร้างขึ้นได้รับ Resource เป็น Typed Binding เช่น env.PROJECT ภายใต้ Policy ที่กำหนดไว้ Server ของ Gadget ปิดการเชื่อมต่อออก Internet เป็นค่าเริ่มต้น ส่วน Client รันใน Sandboxed Frame และเข้าถึงปลายทางได้ผ่าน Capability ที่อนุญาตเท่านั้น

นี่เป็นส่วนที่ทำให้ Cloudflare OS ต่างจากการนำ Chat UI มาต่อ MCP Server หลายตัว เพราะการรู้ว่า Agent เรียก Tool ใดได้ยังไม่พอ องค์กรต้องรู้ด้วยว่ามันอ่าน Resource ไหนไปแล้ว และผลลัพธ์ที่สร้างขึ้นควรแชร์ต่อให้ใครได้

Policy ต้องตามข้อมูลไปถึง Output

สมมติว่า Agent อ่านตารางข้อมูลลูกค้าที่เป็นความลับ แล้วนำข้อมูลไปสร้าง Dashboard หากระบบตรวจสิทธิ์เฉพาะตอนอ่านครั้งแรก คนที่ไม่มีสิทธิ์อาจเปิด Dashboard ที่แชร์มาและเห็นข้อมูลทางอ้อมได้

Cloudflare OS จึงบันทึก Resource ที่ Agent เคยอ่านเป็น Observation และผูกข้อมูลนี้ไว้กับ Workspace, Agent และ Output เมื่อมีคนอื่นเข้ามาดูหรือทำงานต่อ Gatekeeper จะตรวจว่าคนนั้นมีสิทธิ์เข้าถึง Resource ต้นทางหรือไม่

Observation เดียวกันยังนำไปประกอบ Policy สำหรับการเขียนข้อมูลออก การเชิญผู้ร่วมงาน การส่งงานให้ Agent ตัวอื่น หรือการเรียกปลายทางภายนอกได้

วิธีนี้ยังต้องผ่านการพิสูจน์กับระบบจริงที่ซับซ้อน แต่ทิศทางถูกจุด เพราะปัญหาของ AI ในองค์กรไม่ได้จบที่ “ใครเปิดไฟล์ได้” มันรวมถึงข้อมูลที่ Agent จำ ผสม และสร้างต่อจากไฟล์นั้นด้วย

ทำไมงานซ้ำไม่ควรรัน Agent ใหม่ทุกครั้ง

Cloudflare เล่าว่า v1 เน้นการเปิด Skill เพื่อให้ Agent ทำงาน แม้งานหลายอย่างมีขั้นตอนตายตัว ส่งผลให้ต้องใช้ Token ซ้ำทุกครั้ง

v2 เปลี่ยนแนวคิดให้ AI เป็น Toolmaker มากขึ้น ผู้ใช้บอก Workflow เป็นภาษาธรรมชาติ แล้ว Agent เขียนแอปหรือโค้ดสำหรับขั้นตอนที่แน่นอน หลังจากนั้นระบบเรียกโมเดลเฉพาะจุดที่ต้องใช้การตัดสินใจ

รายงาน Ticket รายวันที่ใช้ Query และกราฟแบบเดิมทุกเช้าไม่จำเป็นต้องให้โมเดลสร้างรายงานใหม่ทั้งชุด ระบบสามารถรันโค้ดเพื่อดึงข้อมูลและวาดกราฟ แล้วเรียก AI เฉพาะตอนร่างคำตอบให้ Ticket ที่ต้องวิเคราะห์

Workflow สามารถรันเมื่อผู้ใช้สั่ง ตามเวลา หรือจาก Event ของระบบที่เชื่อมต่อ วิธีนี้ลดทั้งค่าใช้จ่ายและความแปรปรวนของผลลัพธ์ แต่ทีมยังต้องเขียน Test และกำหนดว่าจุดใดต้องให้คนตรวจ เพราะคนยังเป็นเจ้าของคุณภาพของ Output

เลือกโมเดลได้ แต่ยังอยู่ใต้ AI Gateway

Cloudflare OS ไม่ได้บังคับให้ใช้โมเดลเจ้าเดียว การเรียก Inference ผ่าน Cloudflare AI Gateway ทำให้องค์กรเลือก Provider และ Model ตามงาน ดูค่าใช้จ่ายแยกตามผู้ใช้ ทีม หรือ Workspace รวมถึงตั้ง Budget และ Rate Limit ได้

งานสรุปอีเมลอาจใช้โมเดลขนาดเล็ก ส่วนงานวิเคราะห์ที่ยากค่อยส่งไปโมเดลราคาแพงกว่า แต่การ “รองรับหลายโมเดล” ไม่ได้แปลว่าเปิดใช้ได้ทันทีทุกตัว ผู้ดูแลยังต้องตั้งค่า Provider, Credential, Routing และนโยบายข้อมูลให้ตรงกับข้อกำหนดขององค์กร

สถาปัตยกรรมที่ใช้ Cloudflare Workers เป็นฐาน

Cloudflare OS v2 ใช้บริการหลายส่วนของ Workers Platform

• Workspace แต่ละตัวเป็น Durable Object
• Gadget แต่ละตัวรันใน Dynamic Worker Facet และมี SQLite แยก
• Gatekeeper เป็น Worker ที่เชื่อมกับ Service ภายนอก
• Cloudflare Access ตรวจ Identity ก่อนเข้าใช้งาน
• AI Gateway คุม Routing, Logging, Budget และ Rate Limit ของโมเดล
• Cap'n Web ทำหน้าที่เป็น RPC ระหว่าง Client, Server และ Agent

ตัวโครงการใช้สัญญาอนุญาต Apache License 2.0 และ Cloudflare ระบุว่าสามารถรันบน workerd ซึ่งเป็น Runtime แบบโอเพนซอร์สได้ แต่คู่มือและเครื่องมือสำหรับ Production Self-host บน Server ของตัวเองยังขึ้นว่า Coming Soon

ดังนั้นคำว่า Open Source ในตอนนี้ควรตีความว่าเปิดให้ดู แก้ และนำไป Deploy ใน Cloudflare Account ของตัวเองได้จริง ไม่ได้หมายความว่าเส้นทาง Self-host แบบ Production นอก Cloudflare พร้อมใช้งานแล้ว

อยากลอง เริ่มตรงไหน

มีสามเส้นทางตามระดับความจริงจัง

ทดลองบนเครื่อง

ติดตั้ง pnpm แล้วรันคำสั่งจาก Repository

pnpm run-local

จากนั้นเปิด http://localhost:8787 ระบบจะรันผ่าน Wrangler และ workerd โดยเก็บข้อมูลไว้ใต้โฟลเดอร์ .wrangler

โหมดนี้เหมาะกับการดูหน้าตาและลองแนวคิด ไม่ใช่วิธี Deploy Production

Deploy แบบ Hosted Flow

Cloudflare มีหน้าสำหรับ Deploy เข้า Account โดยตรง เหมาะกับทีมที่ต้องการทดลองระบบพื้นฐานและปรับ Branding ผ่านหน้า Admin

ใช้ Starter Repository

ทีมที่ต้องการ Custom Domain, Cloudflare Access, Storage, Observability, AI Configuration หรือ Gatekeeper ของตัวเองควรเริ่มจาก cloudflare-os-starter

Starter ระบุว่าต้องใช้ Node.js 24, pnpm 11 และบริการอย่าง Workers, KV, R2, Browser Rendering กับ Dynamic Worker Loaders ก่อน Deploy ต้องกำหนด Account, Hostname, Access Audience และ Admin Email แล้วรัน

pnpm check
pnpm deploy

การเชื่อมบริการภายนอกยังต้องสร้าง OAuth Client และตั้งค่า Gatekeeper ของแต่ละบริการ ไม่ใช่กด Deploy ครั้งเดียวแล้วเข้าถึงทุกระบบได้ทันที

ใครควรลองตอนนี้

Cloudflare OS เหมาะกับทีมที่มี Use Case ภายในชัดเจน เช่น สรุปข้อมูลจากหลายระบบ สร้าง Dashboard เฉพาะทีม ทำเอกสารจากข้อมูลสด หรือเปลี่ยนงานซ้ำให้เป็น Workflow และมีคนดูแล Cloudflare Workers, Access, OAuth และ Policy อยู่แล้ว

ควรเริ่มจาก Pilot ขนาดเล็ก เลือกข้อมูลที่ไม่อ่อนไหวมาก กำหนด Resource ให้แคบ และทดสอบการแชร์ Output ข้ามสิทธิ์ก่อนเชื่อมระบบสำคัญ

ทีมที่ต้องการ Software พร้อมใช้ทันที ไม่มีคนดูแล Integration หรือจำเป็นต้อง Self-host Production นอก Cloudflare ควรรอดูพัฒนาการก่อน เพราะ v2 ยังเป็น Early Access, ไม่มี Release Tag และเอกสาร Self-host Production ยังไม่พร้อม

Checklist ก่อนทดลองใช้

• เลือกงานหนึ่งอย่างที่มี Input, Output และเจ้าของงานชัดเจน
• ระบุว่าขั้นตอนไหนใช้โค้ดตายตัว ขั้นตอนไหนใช้โมเดล และขั้นตอนไหนต้องให้คนอนุมัติ
• ให้ Agent เข้าถึงเฉพาะ Resource ที่จำเป็น แทนการเปิดสิทธิ์ระดับ Account
• ทดสอบว่าผู้ใช้ที่ไม่มีสิทธิ์ต้นทางเปิด Workspace, Gadget และ Output ที่แชร์มาได้หรือไม่
• ตรวจ Log, ค่าใช้จ่าย และการส่งข้อมูลไปยัง Model Provider
• Pin Commit หรือ Upstream Version ที่ตรวจแล้วก่อนใช้กับ Production
• วางขั้นตอน Rollback และ Review ทุกครั้งที่อัปเกรด

สรุป

Cloudflare OS เป็นภาพของ AI ในองค์กรที่ไปไกลกว่า Chatbot พนักงานสามารถสร้าง Agent, Workflow และแอปเฉพาะงานได้ แต่ทุกชิ้นเริ่มจากไม่มีสิทธิ์ และต้องเข้าถึงระบบจริงผ่าน Capability กับ Gatekeeper ที่องค์กรควบคุม

แนวคิดนี้ตอบโจทย์สำคัญกว่าการเลือกโมเดลว่าเก่งแค่ไหน เพราะ Agent ที่ทำงานได้จริงต้องถือ Context และเข้าถึงข้อมูลของบริษัท การกำกับสิทธิ์จึงต้องตามไปถึงสิ่งที่ Agent อ่าน แอปที่มันสร้าง และ Output ที่คนแชร์ต่อ

ตอนนี้ Cloudflare OS v2 เหมาะสำหรับการศึกษาและ Pilot มากกว่าการย้ายงานสำคัญทั้งองค์กรเข้าไปทันที หากจะลอง ให้เริ่มจาก Workflow เล็ก ๆ ทดสอบ Trust Boundary ให้ครบ แล้วค่อยขยายสิทธิ์ตามหลักฐานที่เห็นจากการใช้งานจริง