ฟีเจอร์ Computer Use ของ AI มีค่าใช้จ่ายสูงกว่า Structured API ถึง 45 เท่า

 (reflex.dev)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในงานเดียวกันบนแผงผู้ดูแลระบบ vision agent ควบคุม UI ด้วยภาพหน้าจอและการคลิก ขณะที่ API agent เรียกใช้แฮนด์เลอร์ของแอปเดียวกันผ่านการตอบกลับแบบมีโครงสร้าง ทำให้ตัวแปรที่ต่างกันมีเพียงอินเทอร์เฟซ
  • ด้วยพรอมป์ต์พื้นฐาน API agent ทำงานเสร็จใน 8 ครั้งของการเรียกใช้ แต่ vision agent มองข้ามรีวิวที่รออยู่ 3 รายการซึ่งอยู่ต่ำกว่าพื้นที่ที่มองเห็น จึงอนุมัติได้เพียง 1 จาก 4 รายการ
  • เมื่อเพิ่ม UI walkthrough แบบ 14 ขั้นตอน vision agent ก็ทำงานสำเร็จเช่นกัน แต่ใช้เวลารันราว 14 นาทีและกิน input token ราว 500,000 โทเค็น และคำแนะนำที่ละเอียดเช่นนี้เองก็เป็นต้นทุนวิศวกรรมอีกชั้นหนึ่ง
  • จากผลรวมทั้งหมด โดยอิงตาม Sonnet เส้นทาง vision ใช้เฉลี่ย 53 ขั้นตอน, 1003 วินาที, และ input token 550,976 โทเค็น ขณะที่เส้นทาง API จบใน 8 ครั้งของการเรียก, 19.7 วินาที, และ input token 12,151 โทเค็น พร้อมความผันผวนของต้นทุนและเวลาก็น้อยกว่ามาก
  • ช่องว่างด้านต้นทุนไม่ได้มาจากความสามารถของโมเดล แต่เกิดจาก โครงสร้างของอินเทอร์เฟซ และหากสามารถสร้าง HTTP endpoint อัตโนมัติจาก event handler ได้แบบ Reflex 0.9 การคำนวณความคุ้มทุนก็จะเอนเอียงไปทางเส้นทาง Structured API สำหรับเครื่องมือภายในที่พัฒนาขึ้นเอง

เป้าหมายของเบนช์มาร์กและการตั้งค่าการทดลอง

  • ให้ vision agent และแนวทาง Structured API ควบคุมแผงผู้ดูแลระบบเดียวกัน เพื่อวัดต้นทุนของแนวทางแบบใช้งานเบราว์เซอร์หรือคอมพิวเตอร์
  • เมื่อ AI agent ต้องควบคุมเว็บแอปที่ไม่ได้เปิด API ไว้ vision agent มักกลายเป็นตัวเลือกเริ่มต้นโดยง่าย
  • ในสถานการณ์ที่แต่ละทีมมีเครื่องมือภายในมากกว่า 20 ตัว การเขียน MCP หรือ REST surface ให้แต่ละแอปกลายเป็นโครงการวิศวกรรมแยกต่างหาก ทำให้หลายทีมเลือกใช้ vision agent
  • แอปที่ใช้ทดสอบคือแผงผู้ดูแลระบบสำหรับจัดการลูกค้า คำสั่งซื้อ และรีวิว โดยอิงจาก react-admin Posters Galore demo
  • เอเจนต์ทั้งสองใช้แอปที่กำลังรันเดียวกัน, Claude Sonnet ตัวเดียวกัน, ชุดข้อมูลคงที่เดียวกัน, และงานเดียวกัน โดยให้ อินเทอร์เฟซเป็นตัวแปรเดียว
  • งานคือค้นหาลูกค้าที่มีชื่อ “Smith” และมีจำนวนคำสั่งซื้อมากที่สุด จากนั้นหาคำสั่งซื้อล่าสุดของลูกค้าคนนั้นที่ยังรอดำเนินการ อนุมัติรีวิวที่รอทั้งหมด และทำเครื่องหมายคำสั่งซื้อว่าได้จัดส่งแล้ว
  • งานนี้แตะ 3 resource และรวมทั้งการกรอง, pagination, การค้นหาข้ามเอนทิตี, รวมถึงการอ่านและเขียน จึงคล้ายกับงานทั่วไปของเครื่องมือภายใน

สองเส้นทางการรัน

  • เส้นทาง A: Vision agent

    • Claude Sonnet ใช้ browser-use 0.12 ในโหมด vision เพื่อควบคุม UI ด้วยภาพหน้าจอและการคลิก

  • เส้นทาง B: API agent

    • Claude Sonnet เรียก HTTP endpoint ของแอปโดยตรงในรูปแบบการใช้เครื่องมือ
    • แต่ละเครื่องมือแมปกับ event handler อย่างน้อยหนึ่งตัวของ state ในแอป และใช้ฟังก์ชันเดียวกับที่ปุ่มบน UI เรียกใช้
    • เอเจนต์ได้รับ การตอบกลับแบบมีโครงสร้าง แทนที่จะดูหน้าที่เรนเดอร์แล้ว

เหตุใด vision agent จึงล้มเหลวด้วยพรอมป์ต์พื้นฐาน

  • ให้ทั้งสองเอเจนต์ทำงานเดียวกันจากคำสั่ง 6 ประโยคชุดเดียวกัน
  • API agent ทำงานเสร็จด้วยการเรียกใช้ 8 ครั้ง
    • แสดงรายการรีวิวของลูกค้าที่กรองด้วยสถานะรอ
    • อนุมัติแต่ละรีวิว
    • ทำเครื่องหมายคำสั่งซื้อว่าได้จัดส่งแล้ว
  • แม้ทั้งสองเอเจนต์จะเรียกใช้ตรรกะของแอปเดียวกัน แต่ API agent อ่านการตอบกลับแบบมีโครงสร้างโดยตรงแทนการดูหน้าที่เรนเดอร์แล้ว
  • vision agent ภายใต้พรอมป์ต์เดียวกันพบและอนุมัติรีวิวที่รอเพียง 1 จาก 4 รายการ ก่อนจะไปขั้นถัดไป
  • รีวิวที่เหลืออีก 3 รายการอยู่ต่ำกว่าพื้นที่ที่มองเห็นบนหน้ารีวิว และเอเจนต์ไม่ได้รับสัญญาณว่าต้องเลื่อนหน้าจอ
  • ความล้มเหลวนี้ไม่ได้มาจากปัญหาการให้เหตุผลของโมเดล แต่เกิดจากการที่หน้าที่เรนเดอร์แล้วไม่ส่งสัญญาณว่ามีข้อมูลส่วนอื่นอยู่อีก
  • API agent เรียกใช้แฮนด์เลอร์เดียวกับที่ UI เรียก แต่ในการตอบกลับมีทั้งผลลัพธ์ทั้งหมดที่แฮนด์เลอร์คืนค่า ไม่ใช่แค่แถวที่กำลังเรนเดอร์อยู่
  • API agent ไม่ต้องตีความตัวควบคุม pagination จากพิกเซล แต่สามารถอ่านข้อมูลอย่าง “หน้า 1 จาก 4 หน้า โดยแสดง 50 รายการต่อหน้า” ได้โดยตรง

ผลลัพธ์เมื่อเพิ่มคำแนะนำ UI 14 ขั้นตอน

  • เพื่อให้เทียบกันอย่างเป็นธรรม พรอมป์ต์ของ vision ถูกเขียนใหม่เป็น UI walkthrough ที่ชัดเจน
  • มีการระบุชื่อองค์ประกอบ UI ที่เอเจนต์ต้องโต้ตอบในแต่ละขั้นตอน เช่น รายการในแถบข้าง แท็บ และช่องแบบฟอร์ม
  • กระบวนการนำทางที่เดิมเอเจนต์หาเองไม่เจอ ถูกเขียนเป็นคำสั่งลำดับหมายเลข 14 ข้อ
  • เมื่อให้คำแนะนำนี้ vision agent ก็ทำงานสำเร็จ
  • อย่างไรก็ตาม การรันใช้เวลา 14 นาที และใช้ input token ราว 500,000 โทเค็น
  • คำสั่งแบบลำดับหมายเลขแต่ละข้อไม่สะท้อนอยู่ในจำนวนโทเค็น แต่หมายถึงต้นทุนวิศวกรรมจริง
  • หากต้องการ deploy vision agent กับเครื่องมือภายใน ก็ต้องเขียนพรอมป์ต์ที่ละเอียดระดับนี้ หรือยอมรับความเสี่ยงที่เอเจนต์อาจพลาดงานไปแบบเงียบ ๆ

รูปแบบการรันและความผันผวน

  • เส้นทาง API รัน 5 ครั้ง ส่วนเส้นทาง vision รัน 3 ครั้ง
  • เส้นทาง vision ใช้เวลา 14–22 นาทีต่อครั้ง และใช้ 400,000–750,000 โทเค็น จึงจำกัดไว้ที่ 3 ครั้ง
  • เส้นทาง vision มี ความแปรปรวน ระหว่างการรันสูง
    • เวลาแบบ wall-clock ใน 3 ครั้งอยู่ระหว่าง 749 วินาทีถึง 1257 วินาที
    • input token อยู่ระหว่าง 407,000 ถึง 751,000 โทเค็น
    • รอบที่สั้นที่สุดใช้ 43 cycle และรอบที่ยาวที่สุดใช้ 68 cycle
  • ลูปภาพหน้าจอ-ให้เหตุผล-คลิกมีความไม่เป็นเชิงกำหนดมากพอ จึงยากจะประเมินต้นทุนตัวแทนจากการรันเพียงครั้งเดียว
  • เส้นทาง API ไม่มีความผันผวนแบบนี้
    • Sonnet ใช้การเรียกเครื่องมือ 8 ครั้งเหมือนกันทุกครั้งจาก 5 ครั้งที่รัน
    • จำนวน input token ต่างกันเพียงในช่วง ±27 ตลอดทั้ง 5 ครั้ง
    • การตอบกลับแบบมีโครงสร้างไม่ได้เปิดช่องให้เอเจนต์หลุดเส้นทาง จึงเรียกแฮนด์เลอร์ชุดเดิมในลำดับเดิม

ผลลัพธ์รวม

ตัวชี้วัด Vision agent (Sonnet) API (Sonnet) API (Haiku)
ขั้นตอน / การเรียก 53 ± 13 8 ± 0 8 ± 0
เวลา wall-clock 1003 วินาที ± 254 วินาที, ประมาณ 17 นาที 19.7 วินาที ± 2.8 วินาที 7.7 วินาที ± 0.5 วินาที
Input token 550,976 ± 178,849 12,151 ± 27 9,478 ± 809
Output token 37,962 ± 10,850 934 ± 41 819 ± 52
  • ตัวเลขทั้งหมดเป็นค่าเฉลี่ย ± sample standard deviation (n−1) โดยเส้นทาง API มี n=5 และเส้นทาง vision มี n=3
  • รายละเอียดการรันทั้งหมดดูได้จากที่เก็บซอร์ส
  • Haiku ไม่สามารถทำเส้นทาง vision ให้เสร็จได้
  • ความล้มเหลวนี้จำกัดอยู่ที่ structured output schema ของ browser-use 0.12 โดย Haiku ไม่สามารถสร้างสิ่งนี้ได้อย่างเสถียรทั้งในโหมด vision และโหมดข้อความล้วน
  • ในเส้นทาง API นั้น Haiku ทำงานเสร็จในเวลาไม่ถึง 8 วินาที ใช้ input token ไม่ถึง 10,000 โทเค็น และเป็นตัวเลือกที่ถูกที่สุดในการตั้งค่าที่ทดสอบ

ช่องว่างด้านต้นทุนเชิงโครงสร้าง

  • ความต่างของต้นทุนเกิดขึ้นโดยตรงจากสถาปัตยกรรม
  • เอเจนต์ที่ต้องมองเห็นก่อนจึงจะลงมือทำได้ จะต้องจ่าย ต้นทุนของการมองเห็น เสมอ ต่อให้โมเดลดีขึ้นก็ตาม
  • โมเดล vision ที่ดีกว่าอาจลดอัตราความผิดพลาดต่อภาพหน้าจอได้ แต่ไม่ได้ลดจำนวนภาพหน้าจอที่ต้องใช้เพื่อไปถึงข้อมูลที่เกี่ยวข้อง
  • การเรนเดอร์แต่ละครั้งคือภาพหน้าจอ และภาพหน้าจอแต่ละภาพกลายเป็น input token หลายพันโทเค็น
  • เอเจนต์ทั้งสองผ่านตรรกะแอปเดียวกัน
    • ทั้งคู่กรองข้อมูล, ทำ pagination, และอัปเดตในแบบเดียวกับ UI
    • ความต่างอยู่ที่แต่ละขั้นตอนอ่านอะไร
  • vision agent อ่านพิกเซล และต้องเรนเดอร์พร้อมตีความทุกสถานะคั่นกลาง
  • API agent อ่านการตอบกลับแบบมีโครงสร้างจากแฮนด์เลอร์เดียวกัน ซึ่งมีข้อมูลที่ UI ตั้งใจจะแสดงรวมอยู่แล้ว
  • โมเดลที่ดีกว่าอาจลดต้นทุนต่อขั้นตอนได้ แต่ จำนวนขั้นตอน ถูกกำหนดโดยอินเทอร์เฟซ จึงไม่ลดลง

เมื่อค่าใช้จ่ายด้านวิศวกรรม API ลดลง การตัดสินใจก็เปลี่ยนไป

  • เบนช์มาร์กนี้รันได้ในต้นทุนต่ำด้วย Reflex 0.9
  • Reflex 0.9 มีปลั๊กอินที่สร้าง HTTP endpoint อัตโนมัติจาก event handler ของแอป Reflex
  • ข้อสรุปเชิงโครงสร้างไม่ได้ขึ้นกับ Reflex แต่ Reflex ทำให้เส้นทาง API รันได้โดยไม่ต้องมี codebase แยก
  • ประเด็นสำคัญคือ เมื่อค่าใช้จ่ายด้านวิศวกรรมของ API surface ใกล้ศูนย์ จะเกิดอะไรขึ้นได้บ้าง
  • vision agent ยังเหมาะกับแอปพลิเคชันที่ไม่ได้อยู่ในการควบคุมโดยตรง
    • ผลิตภัณฑ์ SaaS ของบุคคลที่สาม
    • ระบบ legacy
    • แอปพลิเคชันที่แก้ไขไม่ได้
  • แต่สำหรับเครื่องมือภายในที่สร้างเอง การคำนวณความคุ้มทุนจะเอนกลับอีกด้าน

ขอบเขตการทดลองและข้อควรระวัง

  • ผลลัพธ์ของ vision จำกัดอยู่ที่โหมด vision ของ browser-use 0.12 และ vision agent ตัวอื่นอาจทำงานต่างออกไป
  • ตัวรันของเส้นทาง B นำ endpoint ที่สร้างอัตโนมัติมาแปลงเป็น REST tool surface ขนาดเล็กราว 30 บรรทัด
  • เอเจนต์มองสิ่งนี้เป็นเครื่องมืออย่าง list_customers, update_order
  • ชุดข้อมูลเป็นแบบคงที่และมีขนาดเล็ก
    • ลูกค้า 900 คน
    • คำสั่งซื้อ 600 รายการ
    • รีวิว 324 รายการ
  • ยังไม่ได้วัดพฤติกรรมบนข้อมูลขนาด production
  • vision agent รันผ่าน ChatAnthropic ของ LangChain
  • API agent รันโดยใช้ Anthropic SDK โดยตรง
  • จำนวนโทเค็นที่รายงานคือ input token ที่ไม่ได้ cache

เอกสารสำหรับการทำซ้ำ

  • ในที่เก็บซอร์สมีทั้งการสร้าง seed data, react-admin demo ที่ถูกแพตช์, สคริปต์ของเอเจนต์ทั้งสองแบบ และผลลัพธ์ดิบ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2 시간 전
ความเห็นบน Hacker News

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

    • แปลกดีที่คนที่เมื่อก่อนไม่เชื่อ กลับมาขยันทำแนวปฏิบัติวิศวกรรมซอฟต์แวร์ที่ดีเพราะ AI โดยเฉพาะเรื่อง การเขียนสเปก
      ตอนที่เป็นเรื่องของมนุษย์กลับไม่ยอมทำ แต่พอ AI ต้องการ ทุกคนกลับรีบทำกันใหญ่ น่าสนใจและก็หดหู่นิดหน่อย สุดท้ายก็ดูเหมือนจะทำเพื่อ AI เพราะรู้สึกว่ามันให้ประโยชน์กับตัวเองมากกว่ากับใครสักคนในอนาคตแบบนามธรรม
    • ประเด็นคือทำให้มันเป็นสิ่งที่มนุษย์อยากทำ [0] แสดงให้เห็นว่าองค์ประกอบแบบโต้ตอบขยับได้ และทำให้โต้ตอบกับสภาพแวดล้อมตามบริบทได้
      [0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
    • สุดท้ายแล้ว ASP WebForms อาจเป็นเทคโนโลยีที่เราต้องการมาตลอดก็ได้
    • เคยมีโปรเจ็กต์หนึ่งที่แอปเดสก์ท็อปตั้งใจซ่อนเนื้อหาทั้งหมดของ grid control จาก Windows accessibility API, และยังกันไม่ให้การเลือก checkbox หรือ radio button ผ่าน accessibility API มีผลจริงด้วย อีกทั้งฟีเจอร์ส่งออกข้อมูลก็ถูกป้องกันด้วย CAPTCHA ทั้งหมด
      ตอนนั้นยังไม่ใช่ยุคของ generative AI แต่เราก็ต้องผสม OCR, การจำลองอินพุตผู้ใช้, และการจับภาพจากการพิมพ์เข้าด้วยกันเพื่อใช้งานแอปและส่งออกข้อมูล ถ้านักพัฒนารู้เรื่อง Windows DRM API ที่กันการแคปหน้าจอ หรือรู้ว่าข้อความในไฟล์ PostScript สามารถกู้คืนได้ง่ายพร้อมรูปแบบพื้นฐานขั้นต่ำ พวกเขาอาจทำอะไรที่แย่กว่านี้ก็ได้
      ที่น่าขันคือ กระบวนการเดิมก่อนถูกแทนที่คือให้แรงงานราคาถูกจากต่างประเทศเข้าถึงข้อมูลทั้งหมดในระบบแบบรีโมตโดยอ่านได้อย่างเดียว ซึ่งจริง ๆ แล้วเป็นความเสี่ยงด้านความปลอดภัยที่ร้ายแรงกว่าการให้อุปกรณ์ในเครื่องจากผู้ขายที่เชื่อถือได้แก่พนักงานที่ได้รับอนุมัติเพื่อทำงานอัตโนมัติโดยไม่ต้องเข้าถึงเครือข่ายเสียอีก

  • ผมกำลังสร้างสิ่งที่แก้ปัญหานี้โดยตรงอยู่[1]
    ในหน้า landing page ยังไม่ได้พูดถึงเรื่องนี้ แต่แก่นของมันคือการให้อุปกรณ์ชุดเล็กกับเอเจนต์เพื่อสำรวจพื้นผิวของแอป และโดยเฉพาะ functional API ของ macOS ที่เกี่ยวกับ accessibility
    หลังจากเอเจนต์สำรวจแอปแล้ว มันสามารถเขียน workflow ที่ทำซ้ำได้ และหลังจากนั้นก็รันจาก CLI ได้แบบ invoke chrome pinTab
    เหตุผลที่ใช้ accessibility ก็เพราะสุดท้ายมันคือ DOM ที่ดีสำหรับแอป แม้ไม่ใช่ทุกแอปจะทำได้สมบูรณ์ แต่มีจำนวนมากพอที่จะมีประโยชน์มาก
    [1] https://getinvoke.com - ตอนนี้ landing page ยังทำสำหรับครีเอเตอร์อยู่ จึงยังไม่ครอบคลุม use case นี้

    • ถ้าเอเจนต์ช่วยผลักดันให้มี accessibility (a11y) ที่ดีขึ้นได้ ผมก็ยอมรับได้นะ บ่นหน่อยแต่ก็รับได้
    • ถ้าคุณสนใจด้านนี้บน macOS ผมแนะนำอย่างยิ่งให้เปิด Accessibility Inspector.app ที่มากับระบบ แล้วลองเล่นกับแอปและเบราว์เซอร์โดยตรง
      คุณจะเห็นได้ว่าเซลล์สีเขียวสามารถชี้นำ LLM ให้แค่อ่านบางส่วนของหน้าจอหรือใช้ OCR ได้อย่างไร, มีข้อความมากแค่ไหนที่ accessibility engine มีให้อยู่แล้ว, และมันต่อยอดได้ทั้งกับ MCP และตัวสร้างโค้ดที่สร้างแล้วรันสคริปต์ของตัวเองเพื่อ crawl accessibility layer ของ workflow
      ผมมองว่านี่เป็นพื้นที่ที่อุดมสมบูรณ์มาก ห้องแล็บใหญ่ ๆ ต้องใช้แนวทางที่ทำงานข้ามหลายแพลตฟอร์มและ workflow แบบสุ่มได้ ดังนั้นวิสัยทัศน์ทั้งหน้าจอจึงเป็นตัวหารร่วมต่ำสุด วิธีเฉพาะแพลตฟอร์มยังเป็นพื้นที่เปิดที่น่าสนใจมาก
    • แทนที่ทุกคนจะทำงานใช้คอมพิวเตอร์แบบเดียวกันซ้ำ ๆ แล้วเผาโทเค็นทิ้ง การสร้างวิธี แชร์ workflow น่าจะเป็นคำตอบที่ดี
      แต่ก็คงต้องรับประกันให้ได้ว่า workflow ที่ดึงข้อมูลผู้ใช้ เช่น รหัสผ่าน จะไม่ถูกแชร์ออกไป
    • น่าสนใจ ผมเองก็เริ่มทำอะไรคล้าย ๆ กันอยู่ แม้จะเสร็จน้อยกว่าและค่อนข้างต่าง แต่ก็ใช้ องค์ประกอบ UI ด้าน accessibility เหมือนกัน
      ปัญหาใหญ่คือมีแอปมากเกินไปที่เปิดเผยองค์ประกอบเหล่านี้ได้แย่มาก แนวทางของผมคือใช้ UIAccess หรือวิชันโมเดลแบบ one-pass เพื่อสร้าง UI template: https://github.com/willwade/app-automate?tab=readme-ov-file#...
      ข้อโต้แย้ง reddit ต่อเรื่องนี้คือประสบการณ์จริงกลับแทบตรงข้าม UIA ดูเหมือนสม่ำเสมอบนเอกสาร แต่ WPF, WinForms, และ Win32 ต่างก็เปิดเผย control pattern คนละแบบ สุดท้ายจึงต้องใช้ handler แยกตาม toolkit ส่วน Qt ต้องมีการคอมไพล์ QAccessible และโหลด accessibility plugin ตอนรันไทม์ก่อนถึงจะเปิดเผยอะไรได้ ซึ่งแทบไม่เคยเกิดกับไบนารีที่แจกจริง Electron เองก็ทึบพอ ๆ กับบน macOS แม้อยู่บน Windows เพราะสุดท้ายก็เป็น Chromium ตัวเดียวกันที่วาดลงบน canvas เส้นแบ่งที่แท้จริงจึงไม่ใช่ระบบปฏิบัติการต่อระบบปฏิบัติการ แต่เป็น native toolkit กับทุกอย่างที่เหลือ

  • การบอกว่าการเขียนพื้นผิว MCP หรือ REST ให้แต่ละแอปเป็นโปรเจ็กต์วิศวกรรมแยกต่างหากนั้น ไม่จำเป็นต้องจริงเสมอไป ถ้า แบ็กเอนด์ถูกแยกจากฟรอนต์เอนด์ดีพอ และงานฝั่งเซิร์ฟเวอร์ถูกออกแบบอย่างรอบคอบและเป็นภาพรวมมาตั้งแต่แรก

  • ผมสงสัยว่าจะให้วิชันเอเจนต์ช่วย “ทำแผนที่” UI แล้วเปิดเผยให้เอเจนต์อีกตัวหนึ่งเป็นชุดอินเทอร์เฟซที่ดูคล้าย API มากขึ้นได้ไหม
    ตอนนี้ผมเข้าใจว่าวิชันเอเจนต์ต้องรู้ทั้งว่า “หน้าถัดไป” แปลว่ามีผลลัพธ์เพิ่ม และยังต้องรู้ด้วยว่าควรดึงผลลัพธ์เพิ่มตั้งแต่แรก
    ถ้าเอเจนต์ตัวหนึ่งได้สำรวจเฉพาะ UI ในสภาพแวดล้อมทดสอบเพื่อสร้างคำอธิบายที่มีโครงสร้างระดับหนึ่งเกี่ยวกับองค์ประกอบและการทำงานของ UI แล้วให้อีกเอเจนต์รับคำอธิบายนั้นไป มันจะทำได้ดีกว่าเอเจนต์ที่ต้องทั้งสำรวจ UI และทำภารกิจไปพร้อมกันไหม
    เช่น อาจนิยามว่า “ดึงรีวิวทั้งหมด” หมายถึงไปแต่ละหน้าแล้วคลิก “ดูรีวิวเต็ม” สำหรับแต่ละสรุปรีวิว หรือ “ไปแต่ละหน้า” หมายถึงเริ่มจากหน้า 1 ซึ่งเป็นค่าเริ่มต้นของแท็บรีวิว แล้วกด “ถัดไป” ไปเรื่อย ๆ จนปุ่มหายไป
    แบบนั้นเอเจนต์ตัวที่สองก็ไม่ต้องเสียแรงคิดวิธีสำรวจ เพราะมีเทคนิคอยู่แล้ว ส่วนเอเจนต์ตัวแรกก็สำรวจ UI แค่ครั้งเดียวในสภาพแวดล้อมทดสอบโดยไม่ต้องกังวลเรื่องทำพลาด ผมอาจเข้าใจบทความผิดไปหมดก็ได้ แต่ก็ยังน่าสนใจอยู่ดี

    • ผมก็คิดแบบเดียวกันทันที ทุกวันนี้การพัฒนาเว็บพึ่งการสร้างโค้ดอย่างมาก จากนั้นก็เติมการทำให้อ่านยากและการบีบอัดเข้าไป แล้ว JavaScript ฝั่งไคลเอนต์ก็มาประกอบทุกอย่างใหม่อีกรอบ
      สุดท้ายจึงต้องฝ่าความซับซ้อนของ HTML/CSS/JavaScript ไม่ว่าจะดีหรือร้าย เว็บแอปขนาด 5~10MiB ก็ไม่ใช่เรื่องแปลกแล้ว
      แทนที่จะเข้าหาแบบ “จากล่างขึ้นบน” ราวกับทำงานย้อนกลับสิ่งที่ browser engine ทำ การมองการแสดงผลด้วยสายตาแบบมนุษย์แล้วเข้าหา “จากบนลงล่าง” ดูจะง่ายกว่า
    • น่าจะใช่ เราอาจทำให้เอเจนต์เรียนรู้ วิธีที่เว็บไซต์ทำงาน แบบเดียวกับเรา แล้วเปิดเผยโมเดลนั้นออกมาเป็น API ง่าย ๆ
      สำหรับการสำรวจยังคงต้องมีงานด้านวิชันอยู่บ้าง แต่จะเป็นงานวิชันง่าย ๆ ที่ไม่ต้องคิดมาก
    • ผมว่าการขอให้วิชันเอเจนต์ “ทำแผนที่” นั้นยาก เพราะโมเดลวิชันส่วนใหญ่เวลาแปลง image→text จะโฟกัสทีละบางส่วนของภาพ
      ส่วน image→image ใช้ภาพทั้งภาพ

  • ผมไม่ค่อยเข้าใจสมมติฐาน ถ้าเป็นแอปภายในองค์กร ทำไมต้องหยิบคอมพิวเตอร์ยูสขึ้นมา แทนที่จะให้เอเจนต์สร้าง CLI หรือ MCP ล่ะ
    แน่นอนว่า computer use แย่กว่า มันควรเป็นทางเลือกสุดท้าย เวลาเราจัดการสถานะใน DB ที่เราเป็นเจ้าของเอง ไม่ควรใช้มัน
    ที่น่าประทับใจกลับเป็นการที่มันแย่กว่า แค่ 50 เท่า เท่านั้น

  • เห็นด้วยเต็มที่ ช่วงหลังผมทำเครื่องมือภาพ AI และลองทั้งสองแนวทางมาแล้ว ความ หน่วงและต้นทุน ของการใช้เบราว์เซอร์แบบ “เอเจนต์ทั่วไป” นั้นร้ายแรงถึงขั้นใช้กับแอปผู้บริโภคแบบเรียลไทม์ไม่ได้ในตอนนี้
    structured API หรือแม้แต่แค่สายโซ่เรียก LLM ที่ใช้ JSON schema แบบเข้มงวด ไม่เพียงถูกกว่า 40 เท่า แต่ยังชี้ขาดพอให้สร้างผลิตภัณฑ์ที่เสถียรได้จริง computer use เป็นเดโมที่เท่ แต่ structured API ต่างหากที่ช่วยจ่ายค่าเซิร์ฟเวอร์

    • “วิศวกรรมแบบเอเจนต์” เป็นแค่ กระแส ที่ช่วยเพิ่มรายได้ให้ผู้ให้บริการโทเค็นเท่านั้น
      ถ้าคุณคิดว่า LLM เหมาะกับงานใด ก็สร้าง middleware ที่นิยามชัดเจนและมีความกำหนดแน่นอนสูงบน Openrouter ให้ตรงกับเป้าหมายนั้นไปเลย

  • structured API ต้องใช้การคิดจริง ๆ แต่ทุกวันนี้ การคิด ไม่ค่อยถูกมองว่าเป็นเรื่องดีนัก

  • เมื่อไม่กี่เดือนก่อน ผมสร้าง desktopctl CLI สำหรับควบคุมแอป GUI โดยได้แรงบันดาลใจจาก kubectl
    บน Mac มันผสาน OCR กับ Accessibility API เพื่อแสดง UI เป็น Markdown และเปิดเผยการกระทำของเมาส์กับคีย์บอร์ด
    แนวคิดหลักคือให้ลูปรับรู้แบบ “เร็ว” ทำงานในเครื่องทั้งหมด โดยปรับแต่งการแปลง UI เป็นโทเค็นและตรวจจับการเปลี่ยนแปลงด้วย GPU ส่วนลูปควบคุมแบบ “ช้า” ต้องมีการวนกลับไปหา LLM และใช้ Markdown interface ที่ประหยัดโทเค็นสำหรับผลลัพธ์ CLI
    ตัวควบคุมใช้ตัวระบุที่ค่อนข้างเสถียร เอเจนต์จึงสามารถเขียนสคริปต์การกระทำทั่วไปอย่าง desktopctl pointer click --id btn_save ได้โดยไม่ต้องพึ่งลูปแปลง UI เป็นโทเค็น
    https://github.com/yaroshevych/desktopctl/tree/main

    • เมื่อเทียบกับ API แล้ว อินเทอร์เฟซสำหรับมนุษย์นั้นช้าและรกกว่า แต่ผมได้เรียนรู้ว่าข้างหลังมันก็ยังมีวิทยาศาสตร์อยู่มาก
      แอปที่ดีเปิดเผยข้อมูลได้ดี และถูกปรับให้เหมาะกับการคลิก การพิมพ์ ฯลฯ
      GUI ที่ดีที่สุดใช้ ความจำของกล้ามเนื้อ ได้ดีมาก จึงเป็นผู้สมัครชั้นเยี่ยมสำหรับการทำสคริปต์ผ่าน CLI เช่นลำดับง่าย ๆ อย่าง “เปิดแอป Notes, กด Cmd+F, ใส่คำค้น, อ่านรายการผลลัพธ์” สามารถกลายเป็นคำสั่ง Bash เดียวที่ AI agent เรียกใช้ได้

  • โดยรวมแล้วผมสงสัยกับแนวคิด “computer use” มาตลอด มันเหมือนกับการจ้างใครสักคนเข้ามาในบ้าน ปล่อยให้นอนบนเตียง ใช้ห้องน้ำ กินของในตู้เย็น ดูทีวี แล้วบอกด้วยว่ารหัสตู้เซฟอยู่ตรงนี้
    เพียงแต่ว่าคนที่คุณจ้างมาคือ ลิง

    • ผมนี่เริ่มสงสัยว่าตัวเองบ้าไหม เราไม่มีความสามารถจะสร้างวิธีให้ซอฟต์แวร์ตัวหนึ่งถามและสั่งซอฟต์แวร์อีกตัวหนึ่งได้จริง ๆ จนต้องให้ AI มาคลำเมาส์แล้วกดนั่นกดนี่อย่างนั้นเหรอ
    • ถ้าจะให้แฟร์ ก็คือเราแค่อยากให้ลิงตัวนั้นทำ งานจุกจิกแบบลิง ๆ ที่เราไม่อยากทำเอง

  • เว็บไซต์ที่กำลังพยายามกัน Claude Code หรือ AI agent ตัวอื่น ๆ ตอนนี้ กำลังสู้ในเกมที่แพ้ตั้งแต่ต้น
    computer use ยังอยู่ช่วงแรก และสิ่งที่ขวางการใช้งานในวงกว้างดูจะเป็นจำนวนโทเค็นที่ต้องใช้ ถ้าเอเจนต์ลองผิดลองถูกกับคำสั่ง CLI 10 คำสั่งก่อนเจอคำสั่งที่ถูก เราแทบไม่สนใจเลย
    แต่กับ visual agent อย่างการใช้เบราว์เซอร์หรือ computer use ต่อให้สุดท้ายไปถึงจุดที่ถูก เราก็ไม่มีความอดทนพอจะรอ 20 นาทีเพื่อให้มันคลิกปุ่มเดียว เมื่อโทเค็นถูกลงและเร็วขึ้น ก็มีโอกาสสูงที่จะมีโมเดลที่ใช้ UI ได้เป็นธรรมชาติพอ ๆ กับ CLI

    • ผมไม่แน่ใจว่าโทเค็นจะถูกลง เงินทุนจาก VC ที่ช่วยอุดหนุนราคาโทเค็นก็เพื่อสร้างฐานผู้ใช้ แต่สุดท้ายเมื่อเปลี่ยนจากการเติบโตไปสู่ความทำกำไร ราคาโทเค็น น่าจะสูงขึ้น
    • และยังมี สามเงื่อนไขมรณะ ด้วย อย่างน้อยตอนนี้ AI provider ทุกเจ้าติดคำเตือนแรงมากเรื่องการอนุญาตให้ AI เข้าถึงข้อมูลส่วนตัวในเบราว์เซอร์ แม้จะเป็นปัญหากับเอเจนต์ทุกตัวก็ตาม
    • ในทางปฏิบัติแล้ว ผู้ให้บริการ LLM ห้ามกันไม่ได้จริง พวกเขาใช้คำขอปลอมตัวเพื่อสแกนคอนเทนต์ และบางครั้งก็ใช้ พร็อกซีเครือข่ายบ้านพักอาศัย ด้วย
    • มันไม่จำเป็นต้องได้ผล 100% แค่ทำให้คนกลัวว่าจะโดนระงับบัญชีจนไม่คิดจะลองก็พอ
    • สิ่งที่ขวางการใช้งานในวงกว้างน่าจะไม่ใช่จำนวนโทเค็น แต่เป็น ต้นทุนมหาศาล, การสิ้นเปลืองพลังงานที่เพิ่มขึ้น, และการสิ้นเปลืองน้ำที่ใช้ได้จริง