Kitesurf เบราว์เซอร์ที่ Cloudflare เขียนใหม่เพื่อ agent

Cloudflare ประกาศ Kitesurf เมื่อ 6 ส.ค. 2026 เป็นเบราว์เซอร์ที่สร้างขึ้นเพื่อให้ AI agent ใช้ ไม่ใช่ให้คนใช้ บริษัทอธิบายตัวมันว่าเป็นเบราว์เซอร์ที่ไม่เก็บสถานะ ขยายตัวได้สูง และคุ้มต้นทุน ซึ่งรันอยู่บนแพลตฟอร์ม Workers ทั้งหมด (Cloudflare · changelog) เรื่องขึ้นหน้าแรก Hacker News เมื่อ 7 ส.ค. 2026 (HN)

ปัญหาที่มันพยายามแก้

เมื่อ agent ต้องเปิดเว็บเพื่ออ่านข้อมูล วิธีที่ใช้กันคือรัน Chromium แบบไม่มีหน้าจอ ซึ่งเป็นเบราว์เซอร์ที่ถูก ออกแบบมาเพื่อคนนั่งใช้ จึงแบกงานจำนวนมากที่ agent ไม่ได้ใช้เลย เหตุผลที่ Cloudflare ให้ไว้คือ AI ไม่สนใจแท็บ ธีม ส่วนขยาย หรือการซิงก์ข้ามอุปกรณ์ แต่สนใจจำนวนโทเคน ขนาดหน้าต่างบริบท ความสามารถ ในการขยายตัว ประสิทธิภาพ และต้นทุน (Cloudflare)

ตัวมันประกอบจากโค้ด Rust ที่คอมไพล์เป็น WebAssembly โดยหยิบบางส่วนของเอนจินเรนเดอร์แบบแยกโมดูล ชื่อ Blitz มาใช้ ร่วมกับ Stylo ซึ่งเป็นตัวอ่าน CSS ของ Firefox และ Boa ซึ่งเป็นตัวรัน JavaScript พาดหัวที่ระบุว่ามันรันอยู่ใน V8 isolate เป็นถ้อยคำของ Cloudflare เอง ไม่ใช่การตีความของคนที่เอาไปโพสต์ต่อ (Cloudflare)

ตัวเลขที่บริษัทรายงาน และตัวเลขที่ต้องอ่านคู่กัน

Cloudflare รายงานผลเทียบกับ Chromium แยกตามประเภทงาน สำหรับการดึงข้อมูล HTML ใช้ซีพียูน้อยกว่า 3.8 เท่าและใช้หน่วยความจำน้อยกว่า 7.0 เท่า ส่วนการจับภาพหน้าจอใช้ซีพียูน้อยกว่า 3.1 เท่าและหน่วยความจำ น้อยกว่า 4.7 เท่า ตัวเลขซีพียูดิบคือ 229 มิลลิวินาทีเทียบกับ 877 สำหรับการดึง HTML และ 380 มิลลิวินาที เทียบกับ 1,173 สำหรับการจับภาพ (Cloudflare)

ตัวเลขที่ต้องอ่านคู่กันเสมอคือเวลาที่ใช้จริง เพราะ Cloudflare เปิดเผยเองว่า Kitesurf ทำงานเสร็จช้ากว่า Chromium ราว 1.7 เท่าในงานดึง HTML และราว 1.8 เท่าในงานจับภาพหน้าจอ พร้อมระบุสาเหตุว่า "Most of that gap comes from rasterization and JPEG/PNG encoding, which we will keep optimizing" (Cloudflare) ข้อสรุปที่ตามมาจากตัวเลขสองชุดนี้คือของชิ้นนี้ขาย เรื่องต้นทุน ไม่ได้ขายเรื่องความเร็ว ซึ่งเป็นการตีความจากตัวเลข ไม่ใช่คำที่บริษัทเขียนไว้ตรงๆ

วิธีวัดที่บริษัทระบุคือค่ามัธยฐานจากการรันห้าครั้งบนชุดตัวอย่าง 14 URL เทียบ Chromium กับ Kitesurf ซึ่งไม่เปิดเผยว่าเป็นเว็บใด ไม่มีโค้ดให้ทำซ้ำ และยังไม่มีการวัดซ้ำโดยฝ่ายที่สาม ตัวเลขทุกตัวจึงควรอ่านในรูป Cloudflare รายงานว่า ไม่ใช่ในรูปข้อเท็จจริงที่ผ่านการตรวจสอบแล้ว

ความเข้ากันได้

บริษัทระบุว่า Kitesurf ผ่านชุดทดสอบมาตรฐานเว็บมากกว่า 215,000 รายการและยังเพิ่มขึ้นเรื่อยๆ แต่ไม่ได้บอกว่าคิดเป็นสัดส่วนเท่าไรของชุดทดสอบทั้งหมด ตัวเลขนี้จึงแปลงเป็นเปอร์เซ็นต์ความเข้ากันได้ไม่ได้ (Cloudflare)

ฝั่งการเชื่อมต่อ มันทำงานร่วมกับ Puppeteer, Playwright, chrome-remote-interface และหน้าเครื่องมือ นักพัฒนาของ Chrome ตัวจริง ผ่านโปรโตคอลเดียวกับที่ Chrome ใช้ แปลว่าโค้ดอัตโนมัติที่ทีมเขียนไว้แล้ว ส่วนใหญ่ย้ายมาใช้ได้โดยไม่ต้องเขียนใหม่ (Cloudflare)

ข้อจำกัดตามที่ Cloudflare ระบุ

บริษัทเขียนไว้ว่า Kitesurf ยังไม่ใช่ตัวเลือกที่เหมาะถ้างานของคุณต้องเล่นวิดีโอ ต้องแสดงผลผ่าน WebGL ต้องผ่านด่านตรวจจับบอตที่ใช้ลายนิ้วมือ TLS จริง หรือต้องเปิด session ที่ล็อกอินค้างยาวซึ่งต้องจำสถานะ โดยแนะนำเองว่างานกลุ่มนั้นให้ใช้ค่าตั้งต้นของ Browser Run ซึ่งขับด้วย Chromium ตามเดิม (Cloudflare)

บริษัทยังระบุด้วยว่ายอมแลกความเที่ยงตรงของการแสดงผลไป โดยมองว่า agent จะยังทำงานได้ดีแม้การอ่าน CSS จะคลาดเคลื่อนเล็กน้อยหรือภาพจะไม่ตรงทุกพิกเซล

สถานะการใช้งานวันนี้

Kitesurf อยู่ใน Browser Run ซึ่งเป็นชื่อใหม่ของบริการที่เดิมเรียกว่า Browser Rendering หลัง Cloudflare เปลี่ยนชื่อเมื่อ 15 เม.ย. 2026 ตอนนี้เปิดให้ใช้ฟรีระหว่างช่วงทดสอบโดยมีเพดานการใช้งานต่อบัญชี ราคาของ Kitesurf หลังพ้นช่วงทดสอบยังไม่ประกาศ ส่วนตัว Browser Run เองเป็นบริการที่มีราคาอยู่แล้ว (Browser Run docs)

ตัวโปรแกรมยังไม่ได้เปิดซอร์ส บริษัทระบุเพียงว่าตั้งใจจะเปิดเมื่อพร้อม จึงยังนำไปรันบนเครื่องตัวเองไม่ได้ และมีสนามทดลองสาธารณะที่ https://kitesurf.cloudflare.app/ ให้ทดสอบว่าเว็บที่ต้องการใช้ได้จริงไหม โดยมีเพดานต่อการเปิดหนึ่งหน้าที่ 20 วินาทีของเวลาซีพียูและ 60 วินาทีของเวลาจริง

เรื่องที่คนเข้าใจผิดบ่อย

หนึ่ง ตัวเลข 3 ถึง 7 เท่าทำให้หลายคนอ่านว่า Kitesurf เร็วกว่า Chromium หลายเท่า ความจริงคือมันช้ากว่า ในเวลาที่ใช้จริง สิ่งที่น้อยกว่าคือทรัพยากรที่กิน ซึ่งแปลงเป็นเงินได้ ไม่ใช่เวลาที่ผู้ใช้ต้องรอ

สอง คนมักคิดว่านี่คือเบราว์เซอร์ที่จะมาแทน Chrome ความจริงคือมันเป็นบริการหลังบ้านที่ไม่มีหน้าจอ สำหรับให้โปรแกรมเรียกใช้ ไม่ได้ออกแบบมาให้คนนั่งเปิดเว็บ

สาม คำว่าฟรีในตอนนี้ผูกกับช่วงทดสอบและมีเพดานต่อบัญชี การวางแผนต้นทุนระยะยาวบนคำว่าฟรีจึงยังทำไม่ได้

สิ่งที่องค์กรไทยหยิบไปใช้ได้

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

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

คำถามที่ยังไม่มีคำตอบ

ราคาหลังพ้นช่วงทดสอบยังไม่ประกาศ ซึ่งเป็นตัวแปรที่ตัดสินว่าการประหยัดทรัพยากรจะแปลงเป็นการประหยัดเงินจริง หรือไม่

ยังไม่มีการวัดโดยฝ่ายที่สามที่ยืนยันตัวเลขทั้งชุด และยังไม่มีกำหนดว่าจะเปิดซอร์สเมื่อไร