การใช้คอมพิวเตอร์คืออะไร และเหตุใดจึงสำคัญ การใช้คอมพิวเตอร์เป็นแนวคิดเรียบง่ายที่มีนัยกว้างไกล แทนที่จะขอให้โมเดลตอบคำถาม เราขอให้โมเดลใช้งานซอฟต์แวร์ เช่น ไปยังส่วนต่าง ๆ ของเว็บไซต์ กรอกแบบฟอร์ม คลิกผ่านขั้นตอนการทำงาน และทำงานตั้งแต่ต้นจนจบได้โดยอัตโนมัติ
แนวทางนี้ปลดล็อกงานจริงได้อีกมาก ซึ่งปัจจุบันกระจัดกระจายอยู่ตามอินเทอร์เฟซต่าง ๆ เช่น การจองตั้งแต่ต้นจนจบ การชำระเงินบนอีคอมเมิร์ซ การวางแผนเดินทางหลายขั้นตอน และกระบวนการหลังบ้านที่ไม่มี API เทียบเท่าอย่างลงตัว ปัญหาเหล่านี้ไม่ใช่เรื่องใหม่ สิ่งใหม่คือ ตอนนี้เราสามารถใช้โมเดลอเนกประสงค์แก้ปัญหาเหล่านี้ได้จริง
ระบบล่าสุดจาก Anthropic และ OpenAI แสดงให้เห็นว่าเอเจนต์ไม่ได้เพียงลงมือทำ แต่ยังให้เหตุผลเกี่ยวกับสถานะ ฟื้นตัวจากข้อผิดพลาด และสร้างวิธีแก้ปัญหาสำหรับงานเฉพาะได้ทันที สิ่งนี้ทำให้เบราว์เซอร์กลายเป็นสภาพแวดล้อมการทำงานอเนกประสงค์สำหรับเอเจนต์ แต่ก็ทำให้เกิดคำถามด้านการออกแบบทันทีว่า เราควรเปิดเผยสภาพแวดล้อมนั้นให้โมเดลเห็นมากเพียงใด
ระบบยุคแรกตอบโจทย์นี้ด้วยการครอบเบราว์เซอร์ไว้ในชุดการกระทำที่ปลอดภัยและกำหนดไว้ล่วงหน้า บทความนี้จะอธิบายว่าเหตุใดแนวทางดังกล่าวจึงกำลังมาถึงขีดจำกัด
เมื่อสร้างเอเจนต์สำหรับเบราว์เซอร์ เรามักมีสัญชาตญาณที่คุ้นเคยว่า อย่าไว้ใจโมเดลมากเกินไป
เราจึงครอบเบราว์เซอร์ด้วย wrapper เราเปิดให้ใช้เครื่องมือที่กำหนดไว้ล่วงหน้า เช่น click, type, scroll, select และ read_text เราลดความซับซ้อนของ Document Object Model (DOM) เราลดขอบเขตของการกระทำที่เป็นไปได้ เราพยายามทำให้พฤติกรรมเข้าใจและควบคุมได้ผ่านชั้นนามธรรมที่เราออกแบบ
นี่เป็นจุดเริ่มต้นที่สมเหตุสมผล แต่ยิ่งนานไปก็ยิ่งเห็นชัดว่า นี่คือสถาปัตยกรรมระยะยาวที่ไม่เหมาะสม
เมื่อโมเดลระดับแนวหน้าพัฒนาขึ้น ข้อจำกัดไม่ได้มีเพียงการที่โมเดลขาดเครื่องมืออีกต่อไป แต่เป็นเพราะเราบังคับให้โมเดลทำงานผ่านชั้นนามธรรมที่ตัดทอนระบบเบื้องล่างออกไปมากเกินไป เราบีบอัดสภาพแวดล้อมที่ยุ่งเหยิงและเปลี่ยนแปลงตลอดเวลาให้เป็นอินเทอร์เฟซการกระทำแบบตายตัว แล้วขอให้โมเดลทำงานได้ดีท่ามกลางข้อมูลที่สูญหายไปนั้น
ข้อแลกเปลี่ยนนี้กำลังน่าสนใจน้อยลงเรื่อย ๆ
การเปลี่ยนแปลงที่เรากำลังสำรวจอธิบายได้ง่าย แต่ส่งผลอย่างมาก แทนที่จะมองเอเจนต์เป็นตัวเลือกการกระทำที่กำหนดไว้ล่วงหน้า เรามองมันเป็นตัวสังเคราะห์โปรแกรมที่ทำงานภายในรันไทม์แบบมีข้อจำกัด
โมเดลเก่งขึ้นมากจนไม่ต้องการรั้วกั้นเชิงนามธรรมที่คุณสร้างไว้อีกต่อไป แต่ต้องการขอบเขตการกระทำที่ครบถ้วน เพื่อออกแบบ ดำเนินการ และปรับปรุงงานซ้ำไปจนบรรลุเป้าหมาย
บทความนี้กล่าวถึงการเปลี่ยนผ่านจากระบบอัตโนมัติบนเบราว์เซอร์ที่พึ่งพาชั้นนามธรรมอย่างมาก ไปสู่การใช้คอมพิวเตอร์แบบมีข้อจำกัด รวมถึงสิ่งที่เปลี่ยนไปเมื่อออกแบบระบบด้วยแนวทางนี้
ปัญหาไม่ใช่ว่าแนวคิดของอินเทอร์เฟซการกระทำแบบตายตัวนั้นผิด แต่เป็นเพราะเว็บไม่ทำงานตามกรอบเหล่านั้น
อินเทอร์เฟซสมัยใหม่สร้างด้วย React, Vue และ Angular พร้อมการอัปเดตสถานะแบบอะซิงโครนัส ระบบเหตุการณ์สังเคราะห์ และวิดเจ็ตจากบุคคลที่สามซึ่งฝังอยู่ใน iframe แบบข้ามต้นทางและมีวงจรชีวิตของตนเอง wrapper ที่สั่งว่า “พิมพ์ลงในช่องป้อนข้อมูลนี้” จะถูกต้องก็ต่อเมื่อหน้าเว็บนิยามการพิมพ์เหมือนกับคุณ แต่หลายหน้าไม่ได้เป็นเช่นนั้น การกำหนดค่าโดยตรงมักข้ามระบบตรวจจับการเปลี่ยนแปลงของเฟรมเวิร์กไปโดยสิ้นเชิง ช่องป้อนข้อมูลดูเหมือนถูกกรอกแล้ว แต่การตรวจสอบความถูกต้องไม่เคยทำงาน แบบฟอร์มจึงยังใช้งานไม่ได้
คุณแก้ปัญหานี้เฉพาะหน้าได้ คุณอาจเพิ่มกรณีพิเศษสำหรับช่องป้อนข้อมูลของ React ส่งเหตุการณ์ blur หลัง focus หรือรอจนเครือข่ายนิ่งก่อนอ่านสถานะ วิธีแก้แต่ละจุดถูกต้องสำหรับกรณีนั้น แต่เมื่อรวมกัน วิธีแก้เหล่านี้จะสะสมจนกลายเป็นระบบที่ดูแลรักษายากขึ้นเรื่อย ๆ และเจาะจงกับเว็บไซต์ที่คุณเคยพบมากขึ้นเรื่อย ๆ
ปัญหาที่ลึกกว่านั้นคือ คุณกำลังฝังสมมติฐานว่าการโต้ตอบควรทำงานอย่างไรไว้ในชั้นนามธรรม ก่อนจะพบว่าเว็บมีสมมติฐานอีกแบบหนึ่ง
ลองพิจารณาแบบฟอร์มชำระเงินของ Stripe หรือ Adyen ที่ฝังอยู่ใน iframe แบบข้ามต้นทาง wrapper ของคุณเข้าถึงแบบฟอร์มนี้โดยตรงไม่ได้ เพราะอยู่บนต้นทางที่แยกต่างหาก เครื่องมือ read_text ไม่สามารถสังเกตสถานะภายในของแบบฟอร์มได้ เครื่องมือ type ไม่สามารถระบุช่องป้อนข้อมูลของแบบฟอร์มได้ เอเจนต์ที่ใช้ wrapper จะไปต่อไม่ได้เมื่อเจอสถานการณ์นี้ ชั้นนามธรรมถูกออกแบบมาสำหรับเอกสารหลัก แต่งานจริงอยู่ในจุดที่ชั้นนามธรรมมองไม่เห็น
ความไม่สอดคล้องคล้ายกันนี้ยังพบได้ในขั้นตอนที่สังเกตเห็นยากกว่า เมนูดรอปดาวน์ที่ควบคุมโดยเฟรมเวิร์กอาจไม่ตอบสนองต่อการคลิกโดยตรงเลย เพราะองค์ประกอบที่มองเห็นไม่ใช่ตัวควบคุมจริง อาจต้องใช้ลำดับเหตุการณ์จากแป้นพิมพ์เพื่อกระตุ้นการเปลี่ยนสถานะเบื้องหลัง เมื่อมองจากภายนอก UI ดูเหมือนคลิกได้ ชั้นนามธรรมสั่งว่า “คลิก” แต่ไม่มีอะไรเกิดขึ้น
หรือลองพิจารณาขั้นตอนแบบโมดัลหลายลำดับ ซึ่ง DOM ที่มองเห็นอัปเดตช้ากว่าการเปลี่ยนแปลงสถานะภายใน การกระทำถัดไปที่ถูกต้องขึ้นอยู่กับการเปลี่ยนสถานะซึ่งยังไม่ปรากฏในองค์ประกอบที่ wrapper มองเห็น เอเจนต์ที่ใช้ wrapper จึงลงมือเร็วเกินไปหรืออ่านสถานะเก่า เพราะกำลังทำงานจากภาพของระบบที่ไม่ครบถ้วน
ในทุกกรณี ชั้นนามธรรมซ่อนสัญญาณที่เอเจนต์จำเป็นต้องใช้จริง ๆ
โมเดลที่ทำงานในระดับล่างกว่า ซึ่งตรวจสอบ DOM แบบสด ให้เหตุผลเกี่ยวกับขอบเขตของเฟรม และสร้างลำดับการโต้ตอบสำหรับพื้นผิวนั้นโดยเฉพาะ สามารถรับมือกับสถานการณ์เหล่านี้ได้ ไม่ใช่ว่าโมเดลฉลาดกว่าโดยเนื้อแท้ แต่เป็นเพราะโมเดลเข้าถึงข้อมูลที่เคยถูกตัดทิ้งได้
การเปลี่ยนแปลงที่เรากำลังพัฒนาอธิบายได้ง่าย แทนที่จะขอให้โมเดลเลือกจากการกระทำที่กำหนดไว้ล่วงหน้า เรามอบพื้นผิวการทำงานระดับล่างให้โมเดล และจำกัดพื้นผิวนั้นด้วยนโยบายรันไทม์แทนการออกแบบชั้นนามธรรม
ทางเลือกในการออกแบบนี้มาจากการเปลี่ยนแปลงในอุตสาหกรรมวงกว้าง ซึ่งเริ่มให้น้ำหนักกับเครื่องมือ primitive ระดับล่างมากขึ้น เครื่องมือเหล่านี้ใช้ประโยชน์จากความสามารถโดยธรรมชาติของเอเจนต์ในการแก้ไขขณะรันไทม์และสร้างโค้ดคุณภาพสูง แทนเครื่องมือเฉพาะแบบฝังตายตัวที่แม้จะแข็งแกร่ง แต่ลดความสามารถของโมเดลในการปรับตัวเข้ากับสภาพแวดล้อมต่าง ๆ
ลองดูความสำเร็จของ Claude Code ที่กลายเป็นตัวเลือกหลักในชุดเครื่องมือของนักพัฒนาจำนวนมาก รวมถึงทิศทางของอุตสาหกรรมที่หันไปหาเอเจนต์บนเทอร์มินัลมากขึ้น ข้อได้เปรียบสำคัญที่สุดของ Claude Code ไม่ใช่ตัวโมเดล แต่คือ harness ระดับล่าง การให้เครื่องมือระดับล่างที่มีจำนวนน้อยลงและเป็นโมดูลมากขึ้นแก่โมเดล กล่าวคือ เทอร์มินัล ทำให้การเรียกใช้เครื่องมือมีประสิทธิภาพดีขึ้น สาเหตุหลักคือเอเจนต์สามารถให้เหตุผลและสร้างสคริปต์เฉพาะสำหรับงานตรงหน้า แทนที่จะพยายามใช้เครื่องมือทั่วไปที่ทำให้หน้าต่างบริบทเต็มไปด้วยข้อมูลรบกวน
สำหรับกรณีการทำงานอัตโนมัติบนเบราว์เซอร์ ในทางปฏิบัติหมายความว่าโมเดลสามารถตรวจสอบสถานะปัจจุบันของหน้าเว็บ ไปยังเฟรมต่าง ๆ และสร้างโค้ดการโต้ตอบเฉพาะสำหรับอินเทอร์เฟซปัจจุบันได้โดยตรง แทนที่จะจับคู่ทุกอย่างเข้ากับชุดการกระทำสำเร็จรูปแบบตายตัว
โมเดลทำหน้าที่คล้ายผู้เขียนโปรแกรมขณะรันไทม์ มากกว่าตัวเลือกคำสั่ง โมเดลตรวจสอบสถานะปัจจุบัน ให้เหตุผลเกี่ยวกับอินเทอร์เฟซ และสร้างตรรกะการโต้ตอบสำหรับสถานการณ์นั้นโดยเฉพาะ โมเดลสร้างลำดับการทำงานหลายขั้นตอน ปรับตัวเข้ากับขั้นตอนที่ผิดไปจากปกติ และตรวจสอบผลลัพธ์ก่อนดำเนินการต่อได้ เมื่อการกระทำล้มเหลว โมเดลจะเห็นข้อผิดพลาดเบื้องหลังและแก้ไขตัวเอง แนวทางนี้ทรงพลังกว่าและเสี่ยงกว่า แต่สอดคล้องกับลักษณะของปัญหาจริงมากกว่ามาก
สิ่งสำคัญคือ การนำชั้นนามธรรมออกไม่ได้ทำให้ระบบขาดระเบียบวินัยลง แต่เป็นการย้ายระเบียบวินัยไปไว้ที่อื่น
งานที่เคยอยู่ในการออกแบบ wrapper และการจัดการกรณีเฉพาะขอบเขตจะย้ายไปอยู่สามส่วน ได้แก่ พรอมต์ ซึ่งกลายเป็นการฝึกปฏิบัติงานรูปแบบหนึ่ง รันไทม์ ซึ่งบังคับใช้ขอบเขตต่าง ๆ เช่น พื้นที่การนำทาง การกระทำที่ละเอียดอ่อน และพฤติกรรมการลองใหม่ และชั้นการประเมิน ซึ่งไม่ได้ประเมินเพียงว่างานสำเร็จหรือไม่ แต่ยังประเมินด้วยว่าขั้นตอนระหว่างทางถูกต้องหรือไม่ ชั้นนามธรรมที่เปราะบางน้อยลง ระบบโดยรอบที่แข็งแกร่งขึ้น
ผลอย่างหนึ่งของการเปลี่ยนแปลงนี้คือ โค้ดผลิตภัณฑ์มักเรียบง่ายขึ้น แม้ว่าระบบโดยรวมจะทำงานได้เก่งขึ้นก็ตาม แทนที่จะเข้ารหัสรูปแบบการโต้ตอบไว้ใน wrapper ที่นำกลับมาใช้ซ้ำได้ เอเจนต์จะสร้างพฤติกรรมขึ้นขณะรันไทม์ คุณดูแลเพียงชุด primitive ที่ทรงพลังขนาดเล็กและสภาพแวดล้อมการทำงานที่มีข้อจำกัด แทนที่จะเพิ่มเครื่องมือเฉพาะทางและตรรกะสำหรับกรณีเฉพาะขอบเขตต่าง ๆ อย่างไม่สิ้นสุด
แนวทางนี้ยังเปลี่ยนวิธีที่ระบบนำความสามารถไปใช้กับงานอื่นด้วย เอเจนต์ที่ใช้ wrapper สามารถนำความสามารถไปใช้ได้ดีกับงานที่คล้ายกับ wrapper ที่คุณสร้างไว้แล้ว เอเจนต์ที่ทำงานในรันไทม์แบบมีข้อจำกัดสามารถนำความสามารถไปใช้กับงานที่มีพื้นฐานการทำงานร่วมกัน แม้อินเทอร์เฟซที่มองเห็นจะแตกต่างกันก็ตาม
ตัวอย่างเช่น การโต้ตอบกับแบบฟอร์มค้นหา ขั้นตอนการจอง หรือหน้าการตั้งค่า อาจดูแตกต่างกันโดยสิ้นเชิงในระดับ UI แต่กลไกเบื้องล่างมีรูปแบบร่วมกัน ได้แก่ การอ่านสถานะ การเรียกเหตุการณ์ การตรวจสอบผลลัพธ์ และการจัดการการอัปเดตแบบอะซิงโครนัส ระบบที่ทำงานในระดับนั้นจะถ่ายทอดความสามารถไปยังงานต่าง ๆ ได้อย่างเป็นธรรมชาติกว่า
องค์ประกอบที่นำกลับมาใช้ซ้ำได้ไม่ใช่รายการการกระทำ แต่คือความสามารถของโมเดลในการตรวจสอบสถานะ ดำเนินการอย่างปลอดภัย และยืนยันผลลัพธ์
บทเรียนที่ชัดเจนที่สุดจากงานนี้คือ ความน่าเชื่อถือไม่ได้เกิดจากการเพิ่มฟังก์ชันตัวช่วยให้โมเดล แต่มักเกิดจากการมอบ primitive ที่น้อยลงแต่ทรงพลังขึ้น พร้อมกำหนดข้อจำกัดอย่างเหมาะสม การช่วยมากเกินไปเป็นการฝังสมมติฐานตายตัวว่างานควรดำเนินการอย่างไร ข้อจำกัดกำหนดขอบเขตการทำงานที่ปลอดภัย และเปิดทางให้โมเดลค้นพบวิธีแก้ปัญหาเฉพาะหน้าที่ดีกว่า
พื้นผิวการทำงานที่ทรงพลังขึ้นยังต้องอาศัยโมเดลด้านความปลอดภัยที่รัดกุมขึ้นด้วย เมื่อเอเจนต์ไม่ได้ถูกจำกัดไว้เพียงการกระทำที่กำหนดล่วงหน้าชุดเล็ก ๆ อีกต่อไป เท่ากับว่ามันกำลังทำงานกับซอฟต์แวร์จริงโดยตรง สิ่งนี้เปลี่ยนลักษณะความเสี่ยงในทันที
มีประเด็นสี่ด้านที่ต้องคำนึงถึงในการออกแบบ:
การเปิดเผยข้อมูล หากเอเจนต์โต้ตอบกับอินเทอร์เฟซจริง ก็มักจะพบข้อมูลละเอียดอ่อน จึงต้องมีแนวทางที่เข้มงวดในการปกปิดข้อมูลและควบคุมการเข้าถึง ควรเปิดเผยข้อมูลเฉพาะเมื่อจำเป็นต่อการทำงานเท่านั้น และต้องจัดการบันทึกกับร่องรอยการทำงานอย่างระมัดระวัง เพื่อไม่ให้ระบบสังเกตการณ์กลายเป็นส่วนที่ละเอียดอ่อนที่สุดของระบบ
ขอบเขตการทำงาน เอเจนต์ที่ทรงพลังไม่ควรทำงานได้ตามอำเภอใจ ในทางปฏิบัติหมายถึงการจำกัดพื้นที่ที่นำทางไปได้ โดเมนที่เข้าถึงได้ และระบบที่ได้รับอนุญาตให้โต้ตอบด้วย ข้อจำกัดเหล่านี้ควรบังคับใช้ในระดับรันไทม์ ไม่ใช่ปล่อยให้เป็นเพียงแนวปฏิบัติในพรอมต์
ความน่าเชื่อถือของสภาพแวดล้อม อินเทอร์เฟซสมัยใหม่อาจมีคำสั่ง เนื้อหา หรือขั้นตอนที่ทำให้เข้าใจผิดหรือมุ่งโจมตีโดยตรง การแทรกคำสั่งผ่านเนื้อหาบนหน้าเว็บเป็นช่องทางโจมตีที่เกิดขึ้นจริง ระบบจำเป็นต้องมีลำดับชั้นของคำสั่ง การตรวจสอบความถูกต้อง และเงื่อนไขการยุติที่ชัดเจน เพื่อป้องกันไม่ให้เอเจนต์ทำตามคำชี้นำที่ไม่ได้ตั้งใจ
ระดับความเป็นอิสระ ไม่ใช่ทุกการกระทำที่ควรเป็นอิสระโดยสมบูรณ์ ในสภาพแวดล้อมการใช้งานจริงหลายรูปแบบ การมองความเป็นอิสระเป็นระดับต่อเนื่องเป็นสิ่งสำคัญ ระบบอาจมีความเป็นเอเจนต์สูงในการสำรวจและดำเนินงาน แต่ยังคงต้องขออนุมัติสำหรับการกระทำบางประเภท
หลักการพื้นฐานนั้นตรงไปตรงมา: การเพิ่มอำนาจให้โมเดลต้องมาพร้อมกับการเสริมความแข็งแกร่งให้ระบบที่อยู่โดยรอบ ความเป็นอิสระที่ไร้นโยบายยังไม่พร้อมสำหรับการใช้งานจริง
เราเลิกถามว่า ควรเปิดให้ใช้การกระทำใดบนเบราว์เซอร์
แล้วเริ่มถามว่า เราจะทำอย่างไรให้โมเดลมีขอบเขตการกระทำที่ครบถ้วน และจะสร้างนโยบายรันไทม์ล้อมรอบขอบเขตนั้นอย่างไรให้ยังคงปลอดภัย
การปรับมุมมองนี้เปลี่ยนสิ่งที่คุณให้ความสำคัญ การจัดหมวดหมู่การกระทำและความครอบคลุมของ wrapper สำคัญน้อยลง ส่วนนโยบายรันไทม์ ความสามารถในการสังเกตการณ์ และการประเมินในแต่ละขั้นตอนสำคัญมากขึ้น ความสามารถของโมเดลและการออกแบบระบบทดแทนกันไม่ได้ ยิ่งโมเดลพัฒนาขึ้น งานของระบบก็ยิ่งสำคัญขึ้น ไม่ใช่น้อยลง
เอเจนต์สำหรับเบราว์เซอร์ที่ทำงานได้ในการสาธิตมักประสบความสำเร็จ เพราะงานมีขอบเขตแคบและสภาพแวดล้อมเอื้ออำนวย ระบบสำหรับใช้งานจริงต้องการสิ่งที่ต่างออกไป ได้แก่ การทำงานแบบมีข้อจำกัด พฤติกรรมที่ตรวจวัดได้ และการประเมินที่แยกผลลัพธ์ที่ถูกต้องออกจากผลลัพธ์ที่สำเร็จเพราะโชคช่วยได้
ออกแบบ wrapper ให้น้อยลง ทำวิศวกรรมระบบให้มากขึ้น
แม้เราจะมุ่งเน้นเอเจนต์สำหรับเบราว์เซอร์ แต่แนวคิดนี้ชี้ไปสู่วิธีมองการใช้คอมพิวเตอร์ในฐานะศาสตร์ด้านระบบที่กว้างขึ้น