Webwright ของ Microsoft: ให้ AI เขียนโค้ดท่องเว็บ แทนที่จะนั่งคลิกทีละครั้ง

โดย Nokka (นก-กา) | 3 ตุลาคม 2569

ถ้าคุณเคยปล่อยให้ AI agent ทำงานบนเว็บยาว ๆ แล้วเห็นมันเริ่มสับสนตอนคลิกที่สี่สิบ คุณไม่ได้คิดไปเอง และงานวิจัยชิ้นหนึ่งจาก Microsoft Research อธิบายว่าปัญหาไม่ได้อยู่ที่การคลิกผิดครั้งใดครั้งหนึ่ง

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

Webwright แก้ที่รากของวิธีคิดนั้น ด้วยข้อเสนอที่ฟังดูเรียบง่ายจนน่าตกใจ คือ ให้โมเดลมี terminal แล้วให้มันเขียนโปรแกรมท่องเว็บเอง [1]

ผลลัพธ์ที่ได้คือบนงานยาว ๆ โมเดล GPT-5.4 ตัวเดียวกัน กระโดดจาก 33.5% ไปเป็น 60.1% และสิ่งที่มันทิ้งไว้ให้คุณไม่ใช่รอยคลิก แต่เป็นเครื่องมือที่เอาไปรันซ้ำได้ [2]

ภาพแนวคิด คือเครื่องมือที่ทำครั้งเดียวแล้วหยิบมาใช้ซ้ำได้ เทียบกับรอยคลิกที่จางหายไปพร้อมกับ session

ปัญหาที่ทุกคนที่สร้าง agent เจอ แต่ไม่ค่อยมีใครตั้งชื่อให้มัน

Web agent ทุกวันนี้ใช้รูปแบบเดียวกัน คือให้ browser session เป็นพื้นที่ทำงานของ agent ตัวมันเอง ในแต่ละก้าว โมเดลรับสภาพหน้าปัจจุบัน แล้วทำนายการกระทำถัดไปหนึ่งอย่าง

การกระทำนั้นอาจเป็นคลิก พิมพ์ เลื่อนหน้า เลือก element ผ่าน DOM หรือเรียกเครื่องมือสั้น ๆ แต่ทั้งหมดมีข้อจำกัดร่วมกันคือ agent ถูกบังคับให้ทำนายการกระทำทีละก้าว ภายในลูปที่กำหนดไว้ล่วงหน้า [1]

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

แต่พอโมเดลเก่งขึ้น โดยเฉพาะเรื่องเขียนและแก้โค้ด harness แบบเดิมก็กลายเป็นคอขวดเสียเอง เพราะมันล็อก agent ไว้ในลูปแคบ ๆ ที่โมเดลไม่จำเป็นต้องอยู่ในนั้นอีกแล้ว [1]

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

แนวคิด: แยก agent ออกจาก browser

จุดที่ผมคิดว่าเฉียบที่สุดของงานนี้คือการย้าย "สถานะ" ของงานไปไว้ที่อื่น

Webwright เสนอว่า ให้แยก agent ออกจาก browser แล้วมอง browser เป็นเครื่องมือที่ agent สั่งเปิด ตรวจสอบ และทิ้งได้ตามใจ ระหว่างที่มันกำลังพัฒนาโปรแกรมชิ้นหนึ่ง [1]

สิ่งที่คงอยู่ไม่ใช่ session ของ browser แต่คือ โค้ดกับบันทึกในพื้นที่ทำงานบนเครื่อง

พูดเป็นภาษาคนก็คือ คลิกทำให้งานเสร็จหนึ่งครั้ง แต่โค้ดทำให้งานเสร็จและเก็บวิธีแก้ไว้ด้วย [3]

ข้างในมีแค่สามชิ้น

ความเรียบง่ายของสถาปัตยกรรมเป็นจุดที่ผมประทับใจรองลงมา ไม่มีระบบ multi-agent ไม่มี graph engine ไม่มีชั้นปลั๊กอิน ไม่มี orchestration ที่ซ่อนอยู่

มีแค่ terminal, browser และโมเดล [3]

ระบบแกนกลางมีสามส่วน [2]

• Runner เก็บว่างานคืออะไร ตอนนี้ทำถึงไหน และผลของคำสั่งก่อน ๆ เป็นอย่างไร
• Model Endpoint เชื่อม Webwright เข้ากับโมเดล รองรับ OpenAI, Anthropic และ OpenRouter
• Environment ให้ terminal ที่ต่อกับ Playwright บน Chromium เป็นที่ที่คำสั่งรันจริง ไฟล์ถูกเก็บจริง และ screenshot ถูกบันทึกจริง

ลูปการทำงานสั้นมาก คือเข้าใจสถานะปัจจุบัน เลือกคำสั่ง รันมัน ดูว่าเกิดอะไร จากนั้นวนใหม่ จนโมเดลคิดว่าเสร็จ และมีขั้นตรวจตัวเองอีกชั้นคอยยืนยัน [3]

ตัวเลขที่ทำให้ต้องหยุดอ่าน

บนชุดทดสอบ Online-Mind2Web ซึ่งมี 300 งานจริงจากเว็บจริง GPT-5.4 ร่วมกับ Webwright ทำได้ 86.7% สูงที่สุดในกลุ่ม harness โอเพนซอร์สที่วัดด้วย AutoEval ส่วน Claude Opus 4.7 ทำได้ 84.7% แต่แข็งกว่าบนชุดงานยากที่ 80.5% เทียบกับ 76.6% ของ GPT-5.4 [3]

แต่ตัวเลขที่ผมว่าสำคัญกว่าคือชุด Odysseys ซึ่งเป็นงานยาว 200 งาน

• โมเดล GPT-5.4 ที่ควบคุม browser ด้วยพิกัดบนหน้าจอ ทำได้ 33.5% [3]
• โมเดลตัวเดียวกันเมื่อเขียนโค้ดผ่าน Webwright ทำได้ 60.1% โดยใช้เวลาเฉลี่ย 76.1 ก้าว [3]
• คิดเป็นการเพิ่มขึ้น 26.6 จุด จากการเปลี่ยน harness ไม่ใช่จากการเปลี่ยนโมเดล [1][3]

และมีผลพลอยได้ที่ผมว่าเป็นสัญญาณเชิงกลยุทธ์ คือเมื่อ Webwright สร้างเครื่องมือที่ใช้ซ้ำได้ไว้แล้ว โมเดลเล็กลงก็ทำงานได้ นั่นหมายความว่าเครื่องมือที่ดีลดความต้องการโมเดลใหญ่ในครั้งต่อไป [3]

อะไรที่ยังต้องระวัง

งานนี้ไม่ได้ฟรี และตัวบทความต้นทางเองก็เขียนข้อจำกัดไว้ตรงไปตรงมา ผมว่าคนอ่านควรรู้ก่อนเอาไปใช้

หนึ่ง ตัวเลขทั้งหมดเป็นการตัดสินโดย LLM คือ AutoEval ไม่ใช่การวัดด้วย unit test ทุกงาน และผลหัวข่าวของ Mind2Web ใช้เพียง 100 จาก 300 งาน [2]

สอง ต้นทุนต่องานยังสูง ประมาณ 2.37 ดอลลาร์ต่องานเมื่อใช้ GPT-5.4 และ 6.09 ดอลลาร์เมื่อใช้ Claude Opus 4.7 เพราะ Webwright ลงทุนคำนวณช่วงต้นเพื่อสร้างเครื่องมือที่ทนกว่า แล้วค่อยใช้ซ้ำ [2]

สาม ต้นทุนไม่ได้หายไป มันย้ายที่ ในตัวอย่างของ Microsoft การใช้เป็น skill บน Codex ใช้โทเคนราว 3.3 ล้าน เทียบกับ 424,000 เมื่อรันเป็น harness เดี่ยว ซึ่งมากกว่าประมาณแปดเท่า เพราะบริบทถูกแคชไว้ใน session ของโฮสต์ [2]

สี่ จุดที่ต้นทางเองรายงานไม่ตรงกัน ผมเจอสองจุดที่ต้องบอกตามจริง จุดแรกคือขนาดของระบบ บล็อกของทีมผู้พัฒนาเองบอกว่าแกนกลางประมาณ 1,000 บรรทัด แบ่งเป็น Runner ราว 150 บรรทัด Model Endpoint ราว 550 บรรทัด และ Environment ราว 300 บรรทัด [1] ขณะที่ README ของ repo นับเป็นระดับไฟล์ คือลูปหลักของ agent ราว 450 บรรทัด สภาพแวดล้อม Playwright ราว 570 บรรทัด และ CLI อีก 150 บรรทัด [3] สองชุดนี้รวมแล้วใกล้กัน แต่เป็นการนับคนละหน่วย คือชุดแรกนับตามโมดูล ชุดหลังนับตามไฟล์

จุดที่สองคือคะแนน Odysseys หน้าโครงการเขียนว่า 60.8% ขณะที่การเทียบใน repo และบทวิเคราะห์ใช้ 60.1% [3] ซึ่งบทวิเคราะห์นั้นระบุเหตุผลไว้เองว่าเลือกใช้ตัวเลขจาก repo เพื่อความสม่ำเสมอ

ผมเห็นว่าเป็นความต่างระดับการปัดเศษมากกว่าจะเป็นข้อขัดแย้ง และการรายงานทั้งสองค่าไว้จะช่วยให้คุณตรวจเองได้ ดีกว่าให้ผมเลือกข้างแทนคุณ

จุดที่งานนี้ไปไกลกว่าที่คิด

ส่วนที่ผมไม่ได้คาดไว้ตอนเริ่มอ่าน คือ Webwright ไม่ได้หยุดแค่ทำภารกิจให้เสร็จ แต่มันต่อยอดไปถึงสิ่งที่ผมเรียกว่าโรงงานเครื่องมือ

ในเวอร์ชัน 21 กรกฎาคม 2026 มีฟีเจอร์ชื่อ Skill Factory ซึ่งทุกครั้งที่แก้ปัญหาสำเร็จ มันจะกลั่นสคริปต์ที่ได้ออกมาเป็นเครื่องมือที่ผ่านการตรวจสอบ มีพารามิเตอร์ และรันได้เองโดยไม่ต้องมีโมเดล ใช้เวลาราว 40 วินาที และไม่ใช้โทเคนเลย บนชุด WebArena การเอาเครื่องมือเก่ากลับมาใช้ยกความแม่นยำบนชุดที่กันไว้จาก 55% เป็น 70% หรือเพิ่ม 15 จุด [3]

และตั้งแต่ 6 พฤษภาคม 2026 มีปลั๊กอินสำหรับ Claude Code, Codex, OpenClaw รวมทั้ง Hermes Agent โดยใช้โฟลเดอร์ skill ชุดเดียวกันโหลดข้ามเครื่องมือได้ [3] ซึ่งสำหรับคนที่ทำงานกับ agent อยู่แล้ว นี่คือจุดที่ทำให้ลองได้ทันทีโดยไม่ต้องรื้อระบบเดิม

อะไรที่คนไทยเอาไปใช้ได้จริง

สี่ข้อที่ผมว่าคุ้มที่สุดสำหรับทีมเล็ก

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

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

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

สาม ถ้าคุณใช้ agent อยู่แล้ว ลองเพิ่ม skill ก่อนเปลี่ยนโมเดล เพราะการทดลองของงานนี้ชี้ว่าการเปลี่ยน harness ให้ผลมากกว่าการเปลี่ยนโมเดลในงานยาว และค่าใช้จ่ายในการลองถูกกว่าการอัปเกรดโมเดลมาก

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

คำถามที่ต้องถามก่อนเชื่อ

ผมคิดว่าคนอ่านควรถามสามข้อนี้ก่อนตัดสินใจลงมือ

หนึ่ง ตัวเลข 60.1% วัดจากการตัดสินของ LLM หรือวัดจากความสำเร็จที่เป็นรูปธรรม ถ้าเป็นอย่างแรก คุณควรเผื่อความคลาดเคลื่อนไว้ และอ่านผลแบบเทียบสัดส่วนมากกว่าเทียบตัวเลขเดี่ยว [2]

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

สาม ต้นทุนแปดเท่าที่โผล่มาในโหมด skill เกิดจากบริบทของโฮสต์ ไม่ได้แปลว่า Webwright แพง แต่หมายความว่าคุณต้องวัดค่าใช้จ่ายที่ระดับ session ไม่ใช่ที่ระดับงาน

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

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

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

ที่ควรไปอ่านต่อ

โค้ดทั้งหมดเปิดที่ GitHub ของ Microsoft [4] และหน้าโครงการมีภาพรวมของงานพร้อมผลทดสอบแยกตามชุด [3] ส่วนบทวิเคราะห์ภาษาเข้าใจง่ายที่ผมใช้เป็นแหล่งหลักของบทความนี้อยู่ที่ Towards Data Science ซึ่งลงลึกเรื่องจุดที่วิธีนี้ยังแก้ไม่ครบบางกรณี [2]

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

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

บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

เอกสารอ้างอิง

[1] Webwright: A Terminal Is All You Need For Web Agents โดย Microsoft Research (4 พฤษภาคม 2026 · เข้าถึง 3 ตุลาคม 2026) · https://www.microsoft.com/en-us/research/articles/webwright-a-terminal-is-all-you-need-for-web-agents/

[2] Webwright: Why AI Web Agents Should Write Code, Not Click โดย Chien Vu Minh, Towards Data Science (17 สิงหาคม 2026) · https://towardsdatascience.com/webwright-why-ai-web-agents-should-write-code-not-click/

[3] Webwright ซึ่งเป็นหน้าโครงการ เอกสารและ README ของ repo (2026 · เข้าถึง 3 ตุลาคม 2026) · https://microsoft.github.io/Webwright/ · https://github.com/microsoft/Webwright/blob/main/README.md

[4] โค้ด Webwright บน GitHub ของ Microsoft (2026 · เข้าถึง 3 ตุลาคม 2026) · https://github.com/microsoft/Webwright