4 คะแนน โดย GN⁺ 2024-10-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Skyvern ใช้ LLM และ computer vision เพื่อทำให้เวิร์กโฟลว์แบบทำด้วยมือบนเว็บไซต์เป็นอัตโนมัติ พร้อมให้บริการ SDK ที่เข้ากันได้กับ Playwright และตัวสร้างเวิร์กโฟลว์แบบ no-code
  • ต่างจากระบบอัตโนมัติบนเบราว์เซอร์แบบเดิมที่พึ่งพาการ parse DOM และ XPath จึงเปราะบางต่อการเปลี่ยนแปลงเลย์เอาต์ Skyvern ใช้ Vision LLM เพื่อทำความเข้าใจองค์ประกอบบนหน้าจอ และวางแผน·ดำเนินการกระทำที่จำเป็น
  • Skyvern ระบุว่าสามารถแมปองค์ประกอบที่มองเห็นกับการกระทำได้แม้ในเว็บไซต์ที่ไม่เคยเห็นมาก่อน และนำเวิร์กโฟลว์เดียวกันไปใช้กับหลายเว็บไซต์ได้โดยไม่ต้องมี XPath หรือ selector ที่กำหนดไว้ล่วงหน้า
  • SDK มีคำสั่ง page.act, page.extract, page.validate, page.prompt และ page.agent โดยเพิ่มการค้นหาองค์ประกอบด้วย พรอมป์ภาษาธรรมชาติ เข้าไปใน action เดิมของ Playwright
  • มีการนำเสนอการรันแบบโลคัล, Docker Compose, Skyvern Cloud, การควบคุม Chrome ที่มีอยู่เดิม, browser tunneling, ความแม่นยำ 64.4% บน WebBench, ไลเซนส์ AGPL-3.0 และข้อยกเว้นของฟีเจอร์ anti-bot ในคลาวด์แบบจัดการ

ปัญหาที่ Skyvern ต้องการแก้

  • Skyvern เป็นโปรเจกต์ที่ทำให้ เวิร์กโฟลว์บนเบราว์เซอร์ เป็นอัตโนมัติด้วย LLM และ computer vision
  • ให้บริการ SDK ที่เข้ากันได้กับ Playwright ซึ่งเพิ่มความสามารถด้าน AI บน Playwright
  • ยังมี ตัวสร้างเวิร์กโฟลว์แบบ no-code เพื่อให้ทั้งผู้ใช้สายเทคนิคและไม่ใช่สายเทคนิคสามารถทำให้เวิร์กโฟลว์แบบทำด้วยมือบนเว็บไซต์ใดก็ได้เป็นอัตโนมัติ
  • ระบบอัตโนมัติบนเบราว์เซอร์แบบเดิมมักพึ่งพาสคริปต์เฉพาะแต่ละเว็บไซต์, การ parse DOM และการโต้ตอบด้วย XPath และอาจพังได้เมื่อเลย์เอาต์เว็บไซต์เปลี่ยน
  • Skyvern ไม่ได้ใช้เฉพาะการโต้ตอบผ่าน XPath ที่นิยามด้วยโค้ด แต่เรียนรู้และโต้ตอบกับเว็บไซต์ด้วย Vision LLM

วิธีทำงานและการออกแบบ

  • Skyvern ได้แรงบันดาลใจจากการออกแบบ เอเจนต์อัตโนมัติที่ขับเคลื่อนด้วยงาน ซึ่ง BabyAGI และ AutoGPT ทำให้เป็นที่นิยม
  • และเพิ่มความสามารถในการโต้ตอบกับเว็บไซต์ด้วยไลบรารีระบบอัตโนมัติบนเบราว์เซอร์อย่าง Playwright
  • ใช้ สวอร์มของเอเจนต์หลายตัว เพื่อทำความเข้าใจเว็บไซต์ วางแผนการกระทำ และดำเนินการ
  • ข้อดีของแนวทางนี้สรุปได้เป็นสามข้อ
    • สามารถทำงานบน เว็บไซต์ที่ไม่เคยเห็นมาก่อน โดยแมปองค์ประกอบที่มองเห็นกับการกระทำที่จำเป็นโดยไม่ต้องเขียนโค้ดเฉพาะ
    • ทนต่อ การเปลี่ยนเลย์เอาต์เว็บไซต์ ได้ดีกว่า เพราะไม่มี XPath หรือ selector ที่กำหนดไว้ล่วงหน้าให้ค้นหาระหว่างการนำทาง
    • สามารถนำเวิร์กโฟลว์เดียวไปใช้กับหลายเว็บไซต์ และอนุมานการโต้ตอบที่จำเป็นในแต่ละไซต์ได้
  • รายงานทางเทคนิคของ Skyvern 2.0 ดูได้ที่ Skyvern 2.0: State-of-the-art web navigation with 85.8 on WebVoyager eval

วิธีรัน

  • Skyvern Cloud เป็นเวอร์ชัน คลาวด์แบบจัดการ ที่ให้รัน Skyvern ได้โดยไม่ต้องจัดการโครงสร้างพื้นฐานเอง
  • Skyvern Cloud สามารถรันอินสแตนซ์ Skyvern หลายตัวแบบขนาน และมีเมคานิซึมรับมือการตรวจจับ anti-bot, เครือข่าย proxy และ CAPTCHA solver
  • การรันแบบโลคัลเริ่มได้ด้วย pip install "skyvern[all]" แล้วตามด้วย skyvern quickstart
  • skyvern quickstart และ skyvern run server ใช้ ฐานข้อมูล SQLite ที่ ~/.skyvern/data.db เป็นค่าเริ่มต้น
    • หากต้องการใช้คอนเทนเนอร์ Postgres แบบโลคัล ให้ส่ง --postgres
    • หากต้องการใช้ฐานข้อมูลที่มีอยู่ ให้ส่ง --database-string
    • Docker Compose ใช้บริการ Postgres ที่บันเดิลมาให้
  • การรันด้วย Docker Compose จะทำให้ Postgres, API และ UI อยู่ในคอนเทนเนอร์ทั้งหมด โดยตั้งค่า LLM API key ใน .env แล้วเริ่มด้วย docker compose up -d
  • UI เข้าถึงได้ที่ http://localhost:8080 ตามค่าเริ่มต้น

SDK และส่วนขยาย Playwright ที่ขับเคลื่อนด้วย AI

  • Skyvern SDK เป็นส่วนขยายที่เพิ่ม ระบบอัตโนมัติบนเบราว์เซอร์ที่ขับเคลื่อนด้วย AI ให้กับ Playwright
  • วิธีติดตั้งแบ่งตามรูปแบบการใช้งาน
    • Python SDK / cloud API: pip install skyvern
    • เซิร์ฟเวอร์โลคัลและ UI แบบแพ็กเกจ: pip install "skyvern[all]" แล้ว skyvern quickstart
    • เซิร์ฟเวอร์โลคัลและ UI ที่ใช้ Postgres: pip install "skyvern[all]" แล้ว skyvern quickstart --postgres
    • UI แบบแพ็กเกจที่เชื่อมต่อกับ API ที่มีอยู่: pip install "skyvern[ui]" แล้ว skyvern run ui --api-url <api-url> --api-key <api-key>
    • TypeScript: npm install @skyvern/client
  • มีการเพิ่ม คำสั่ง AI สี่คำสั่งให้กับ page object
    • page.act(prompt): ทำการกระทำด้วยภาษาธรรมชาติ เช่น “คลิกปุ่มล็อกอิน”
    • page.extract(prompt, schema): ดึงข้อมูลแบบมีโครงสร้างด้วย JSON schema แบบเลือกใช้ได้
    • page.validate(prompt): ตรวจสอบสถานะหน้าและคืนค่า bool
    • page.prompt(prompt, schema): ส่งพรอมป์ใด ๆ ให้ LLM พร้อม schema คำตอบแบบเลือกใช้ได้
  • page.agent ให้คำสั่งเวิร์กโฟลว์ระดับสูงกว่า
    • page.agent.run_task(prompt): รันงานหลายขั้นตอนที่ซับซ้อน
    • page.agent.login(credential_type, credential_id): ยืนยันตัวตนด้วยข้อมูลรับรองที่เก็บไว้ใน Skyvern, Bitwarden, 1Password
    • page.agent.download_files(prompt): นำทางแล้วดาวน์โหลดไฟล์
    • page.agent.run_workflow(workflow_id): รันเวิร์กโฟลว์ที่สร้างไว้ล่วงหน้า
  • action เดิมของ Playwright รองรับ การค้นหาองค์ประกอบด้วย AI ผ่านพารามิเตอร์ prompt แบบเลือกใช้ได้
    • แทน page.click("#btn") ใช้ page.click(prompt="Click login button")
    • แทน page.fill("#email", "a@b.com") ใช้ page.fill(prompt="Email field", value="a@b.com")
    • แทน page.select_option("#country", "US") ใช้ page.select_option(prompt="Country dropdown", value="US")
    • แทน page.upload_file("#file", "doc.pdf") ใช้ page.upload_file(prompt="Upload area", files="doc.pdf")
  • โหมดการโต้ตอบมีสามแบบ
    • Playwright แบบเดิม: ใช้ CSS/XPath selector
    • ขับเคลื่อนด้วย AI: ใช้ภาษาธรรมชาติ
    • AI fallback: ลองใช้ selector ก่อน หากล้มเหลวจึงแทนด้วย AI

การควบคุมเบราว์เซอร์ขั้นสูง

  • Skyvern สามารถควบคุม เบราว์เซอร์ Chrome ที่ผู้ใช้มีอยู่เดิมได้
  • วิธีนี้ใช้เบราว์เซอร์ที่มีคุกกี้ การล็อกอิน และส่วนขยายเดิมอยู่แล้วตามนั้น
  • สามารถเปิดใช้งาน Chrome remote debugging ได้ที่ chrome://inspect/#remote-debugging
  • คำสั่ง skyvern init browser สามารถเปิดหน้า remote debugging รอจนผู้ใช้เปิดใช้งาน แล้วบันทึกการตั้งค่าได้
  • Skyvern Cloud ก็สามารถควบคุม Chrome ที่รันอยู่บนเครื่องโลคัลได้เช่นกัน
    • คำสั่ง skyvern browser serve --tunnel ทำทั้งการเริ่ม Chrome และการสร้าง tunnel ไปยัง Skyvern Cloud ในครั้งเดียว
    • มีประโยชน์เมื่อทำอัตโนมัติกับไซต์ที่ล็อกอินไว้แล้วหรืออยู่หลัง VPN
  • เมื่อนำเบราว์เซอร์ออกมาเผยผ่าน tunnel ต้องใช้ --api-key เสมอ
    • หากเผยโดยไม่มี API key ทุกคนที่มี URL จะควบคุมเบราว์เซอร์ได้ทั้งหมด
    • รายละเอียดที่เกี่ยวข้องอยู่ใน browser tunneling security docs

ประสิทธิภาพและการประเมิน

  • Skyvern ระบุว่าทำผลงานระดับ SOTA บน WebBench benchmark ด้วยความแม่นยำ 64.4%
  • รายงานทางเทคนิคและการประเมินดูได้ที่ Web Bench: A new way to compare AI browser agents
  • ยังระบุว่าเป็นเอเจนต์ที่มีประสิทธิภาพสูงสุดในงาน WRITE
    • ตัวอย่างงาน WRITE ได้แก่ การกรอกฟอร์ม การล็อกอิน การดาวน์โหลดไฟล์ เป็นต้น
    • หมวดนี้ส่วนใหญ่ใช้กับงานที่ใกล้เคียงกับ RPA

Tasks และ Workflows

  • Task เป็นหน่วยประกอบพื้นฐานภายใน Skyvern
  • Task แต่ละรายการคือคำขอเดียวให้สำรวจเว็บไซต์และบรรลุเป้าหมายเฉพาะ
  • Task ต้องมี url และ prompt
  • อาจมี data schema และ error codes แบบเลือกใช้ได้
    • data schema ใช้เมื่อกำหนดให้ผลลัพธ์ทำตาม schema เฉพาะ
    • error codes ใช้เมื่อให้หยุดการรันของ Skyvern ในสถานการณ์เฉพาะ
  • Workflow คือวิธีเชื่อมหลาย Task ให้เป็นหน่วยงานเดียว
  • ตัวอย่างเวิร์กโฟลว์
    • หากต้องการดาวน์โหลดใบแจ้งหนี้ทั้งหมดหลังวันที่ 1 มกราคม สามารถประกอบเป็นลำดับ: ไปที่หน้าใบแจ้งหนี้, กรองวันที่, ดึงรายชื่อใบแจ้งหนี้เป้าหมาย, ดาวน์โหลดใบแจ้งหนี้แต่ละรายการ
    • การทำระบบอัตโนมัติสำหรับการซื้อสินค้าอีคอมเมิร์ซสามารถประกอบเป็นลำดับ: ไปยังสินค้า, เพิ่มลงตะกร้า, ตรวจสอบสถานะตะกร้า, เช็กเอาต์
  • ฟีเจอร์เวิร์กโฟลว์ที่รองรับมี Browser Task, Browser Action, Data Extraction, Validation, For Loops, File parsing, Sending emails, Text Prompts, HTTP Request Block, Custom Code Block และการอัปโหลดไฟล์ไปยัง block storage
  • Conditionals แสดงสถานะว่า “Coming soon”

ฟีเจอร์หลัก

  • Livestreaming ส่ง browser viewport มายังเครื่องโลคัลแบบเรียลไทม์ เพื่อให้เห็นว่า Skyvern กำลังทำอะไรบนเว็บ
    • มีประโยชน์สำหรับการดีบัก ทำความเข้าใจการโต้ตอบ และเข้าแทรกแซงเมื่อจำเป็น
  • Form Filling สามารถกรอก form input บนเว็บไซต์ได้โดยพื้นฐาน
    • เมื่อส่งข้อมูลผ่าน navigation_goal Skyvern จะเข้าใจเนื้อหาและกรอกฟอร์ม
  • Data Extraction ดึงข้อมูลจากเว็บไซต์
    • หากกำหนด data_extraction_schema เป็นรูปแบบ jsonc ในพรอมป์หลัก ผลลัพธ์จะทำตามโครงสร้าง schema นั้น
  • File Downloading ดาวน์โหลดไฟล์จากเว็บไซต์
    • ไฟล์ที่ดาวน์โหลดจะถูกอัปโหลดอัตโนมัติหากตั้งค่า block storage ไว้ และเข้าถึงได้จาก UI
  • Authentication รองรับวิธียืนยันตัวตนหลายแบบเพื่อให้ง่ายต่อการทำงานอัตโนมัติหลังล็อกอิน
  • รองรับ 2FA หลายรูปแบบ
    • 2FA แบบ QR เช่น Google Authenticator, Authy
    • 2FA ทางอีเมล
    • 2FA ทาง SMS
    • เอกสารที่เกี่ยวข้องอยู่ที่ 2FA support
  • สถานะการผสานกับตัวจัดการรหัสผ่าน
    • รองรับ: Bitwarden
    • รองรับ: Custom Credential Service, HTTP API
    • ไม่รองรับ: 1Password
    • ไม่รองรับ: LastPass

การผสานระบบและ LLM ที่รองรับ

  • Skyvern รองรับ Model Context Protocol(MCP) จึงสามารถใช้ LLM ที่รองรับ MCP ได้
  • เอกสาร MCP อยู่ที่ MCP server documentation
  • รองรับการผสานกับ Zapier, Make.com, N8N
  • ผู้ให้บริการ LLM ที่รองรับมีดังนี้
    • OpenAI: GPT-5.5, GPT-5.4, GPT-5, GPT-4.1, o3, o4-mini
    • Anthropic: Claude 4.7 Opus, Claude 4.6 Sonnet/Opus, Claude 4.5 Haiku/Sonnet/Opus
    • Azure OpenAI: โมเดล GPT ทุกตัวที่ deploy ใน subscription ของ Azure
    • AWS Bedrock: Claude 4.7, Claude 4.6 Sonnet/Opus, Claude 4.5 Sonnet/Opus
    • Gemini: Gemini 3.1 Pro, Gemini 3 Flash, Gemini 2.5 Pro/Flash
    • Ollama: โมเดลที่โฮสต์แบบโลคัลผ่าน Ollama
    • OpenRouter: เข้าถึงโมเดลผ่าน OpenRouter
    • OpenAI-compatible: endpoint API แบบกำหนดเองที่ทำตามรูปแบบ OpenAI API ผ่าน liteLLM
  • การตั้งค่า LLM แบบละเอียดอยู่ใน LLM Configuration docs

ตัวอย่างการใช้งานจริง

  • ทำอัตโนมัติสำหรับ การดาวน์โหลดใบแจ้งหนี้ จากหลายเว็บไซต์
  • ทำอัตโนมัติสำหรับกระบวนการสมัครงาน
  • ทำอัตโนมัติสำหรับการจัดหาวัสดุของบริษัทผู้ผลิต
  • ลงทะเบียนบัญชีหรือกรอกฟอร์มบนเว็บไซต์ภาครัฐ
  • กรอกฟอร์ม contact us แบบสุ่ม
  • ค้นหาใบเสนอราคาประกันบนเว็บไซต์บริษัทประกันในหลายภาษา

การแก้ปัญหาและคำสั่งสำหรับปฏิบัติการ

  • บั๊กที่ทราบของ pip install skyvern==1.0.31 อาจทำให้เกิด (sqlite3.OperationalError) table organizations already exists
    • ให้ลบไฟล์ SQLite ที่เหลืออยู่ ~/.skyvern/data.db แล้วอัปเกรดเป็น 1.0.32 ขึ้นไปด้วย pip install --upgrade skyvern จากนั้นรัน skyvern quickstart
    • หากจำเป็นต้องใช้ 1.0.31 ต่อ สามารถใช้ uv pip install skyvern
  • หาก pip install skyvern ล้มเหลวพร้อม ResolutionImpossible อาจเป็นความขัดแย้งในการ resolve dependency ของ litellm / fastmcp ใน 1.0.31
    • ให้อัปเกรดเป็น 1.0.32 ขึ้นไป หรือใช้ uv pip install skyvern
  • คำสั่งที่มีประโยชน์ต่อการดีบัก
    • skyvern run server: รันเซิร์ฟเวอร์ Skyvern แยกต่างหาก
    • skyvern run ui: รัน Skyvern UI
    • skyvern status: ตรวจสอบสถานะบริการ
    • skyvern stop all: หยุดบริการทั้งหมด
    • skyvern stop ui: หยุด UI
    • skyvern stop server: หยุดเซิร์ฟเวอร์

ไลเซนส์และ telemetry

  • โดยค่าเริ่มต้น Skyvern เก็บสถิติการใช้งานเพื่อนำไปใช้ทำความเข้าใจรูปแบบการใช้งาน
  • หากต้องการปิด telemetry ให้ตั้งค่าตัวแปรสภาพแวดล้อม SKYVERN_TELEMETRY เป็น false
  • repository โอเพนซอร์สของ Skyvern ได้รับการสนับสนุนด้วย คลาวด์แบบจัดการ
  • ลอจิกหลักเผยแพร่ใน repository โอเพนซอร์สนี้ภายใต้ไลเซนส์ AGPL-3.0
  • มาตรการ anti-bot ที่รวมอยู่ในการให้บริการคลาวด์แบบจัดการถูกระบุว่าเป็นข้อยกเว้นจากลอจิกหลักของ repository โอเพนซอร์ส

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

 
GN⁺ 2024-10-25
ความเห็นจาก Hacker News
  • อยากรู้ว่ามองฟีเจอร์ computer use ของ Claude ที่ Anthropic เพิ่งเปิดตัวล่าสุดอย่างไร
    ตอนนี้ที่ computer use ของ Claude เพิ่งออกมาได้ไม่นาน อยากรู้ว่าจุดแตกต่างหลักของ Skyvern คืออะไร

    • ฉันทำงานอยู่ในสายนี้ และมองว่าความสามารถของ Claude ในการ นับพิกเซลและโต้ตอบกับหน้าจอด้วยพิกัดที่แม่นยำ เป็นนวัตกรรมที่มีประโยชน์มากพอสมควร ซึ่งอาจช่วยพัฒนาแนวทางเดิมได้
      วิธีเดิมโดยทั่วไปคือวาดกรอบล้อมรอบองค์ประกอบที่โต้ตอบได้ จากนั้นให้ LLM เรียกใช้เครื่องมืออย่าง click('A12') แล้วค่อยแมป A12 ไปยัง HTML element จริงเพื่อสั่งงานผ่าน Selenium/JS การวาดกรอบแบบนี้ด้วยฮิวริสติกก็ทำได้ยากอยู่แล้ว และหากตัว click handler ไปผูกกับ DOM element ตัวอื่น ก็อาจทำให้การกระทำที่ถูกต้องทำได้ยากขึ้นด้วย
      สำหรับงานอัตโนมัติ การสั่งการระดับสูงอย่าง click(x, y) หรือ type("foo") ลงบนหน้าจอโดยตรง โดยไม่ต้องแมปองค์ประกอบภาพกลับไปเป็น HTML element อาจมีประสิทธิภาพมากกว่า อย่างไรก็ตาม ตอนนี้ก็ยังมีแนวโน้มว่าเมื่อให้ HTML เป็นบริบทกับ LLM แล้ว ผลลัพธ์จะดีกว่าการใช้การให้เหตุผลเชิงภาพล้วน ๆ ดังนั้นจึงมองแนวทางของ Claude ในแง่บวกมากกว่า และยิ่งถ้าการให้เหตุผลเชิงภาพพัฒนาต่อไปก็ยิ่งน่าตื่นเต้นมาก
    • ผลิตภัณฑ์และการเปิดตัวของ Anthropic นั้นยอดเยี่ยมมาก และก็น่าประทับใจที่สามารถทำสิ่งต่าง ๆ ได้มากมายด้วยแค่ การใช้เครื่องมือ + ไมโครเอเจนต์ + สกรีนช็อต + พิกัด เพื่อโต้ตอบกับเว็บไซต์
      แต่ก็สงสัยว่าคู่แข่งจะนั่งเฉยโดยไม่ทำของคล้ายกันหรือไม่ xAI, Gemini, OpenAI, Mistral, MetaAI คงไม่รอดูเฉย ๆ และเพราะพื้นที่นี้มีโอกาสเป็นแกนใหญ่ของอนาคต ก็คงไม่ใช่สิ่งที่บริษัทเดียวจะครอบครองทั้งหมดได้
      อีกจุดสำคัญคือคุณค่าที่แท้จริงของระบบแบบนี้มาจากตรงไหน แค่เดโมกับผลิตภัณฑ์ที่ดูดีและใช้งานได้ระดับหนึ่งอาจยังไม่พอ เพราะคนส่วนใหญ่อยากได้ระบบอัตโนมัติสำหรับ workflow จริง ๆ สำหรับการใช้งานส่วนตัวอาจเพียงพอ แต่ในฝั่งองค์กรก็น่าจะต้องการอะไรที่ซับซ้อนกว่านั้น
      สุดท้าย ประเด็นสำคัญคือสิ่งนี้จะถูกปรับให้เหมาะกับ Claude เท่านั้นหรือไม่ หากต้องการรันบน LLM โอเพนซอร์สของตัวเอง หรืออยากสลับไปใช้โมเดลที่ดีที่สุดในตลาดเรื่อย ๆ ก็อาจยากที่จะได้ความยืดหยุ่นแบบนั้นจากโซลูชันของผู้เล่นรายใหญ่ เพราะ Anthropic เองก็มีแรงจูงใจให้คนใช้ Claude ภายในระบบของตน
      จุดสุดท้ายนี้ทำให้มีความหวัง ผู้ใช้โอเพนซอร์สของ Skyvern เลือกโมเดลที่ต้องการได้และไม่ถูกผูกกับ Claude สามารถรันบน Gemini, GPT-4O, Llama 3.2 รวมถึงโมเดลโอเพนซอร์สอื่น ๆ ได้
  • ดูไม่น่าใช่ AI wrapper ตัวแรกบน Playwright ที่ออกมาในสัปดาห์นี้ และอาจไม่ใช่ตัวแรกของเดือนนี้ด้วยซ้ำ
    การนำไปใช้ในมุมของ ระบบอัตโนมัติกระบวนการทำงาน ดูน่าเชื่อถือกว่าระบบอัตโนมัติสำหรับการทดสอบ เพราะงานทดสอบให้ความสำคัญกับความถูกต้องและการทำซ้ำของกระบวนการมากกว่า ขณะที่งานอัตโนมัติทางธุรกิจในหลายกรณีขอแค่ผลลัพธ์ถูกต้อง แม้จะไปถึงด้วยเส้นทางแปลก ๆ ก็ไม่เป็นไรนัก
    แต่ในวิดีโอตัวอย่างดูเหมือนต้องเขียนพรอมป์ต์ขนาดค่อนข้างใหญ่เพื่อให้มันทำงานได้ และยังต้องใส่ข้อมูลเพย์โหลดระดับหลาย KB ในรูปแบบข้อความล้วนแทน CSV ด้วย หากความคาดหวังคือสิ่งนี้จะมาแทนคนที่มองว่าการใช้ตัวสร้างโค้ดของ Playwright โดยตรงเป็นเรื่องเทคนิคเกินไป ก็ยังไม่แน่ใจว่าจะมีคนจำนวนมากแค่ไหนที่ทำอย่างหนึ่งได้แต่อีกอย่างทำไม่ได้
    แถมยังดูเหมือนผู้ใช้ต้องส่งข้อมูลล็อกอินเว็บไซต์และข้อมูลบัตรเครดิตในรูปแบบข้อความล้วนด้วย หากบัญชี Skyvern ของผู้ใช้ถูกเจาะ ระบบจัดการข้อมูลอ่อนไหวจำเป็นต้องแข็งแกร่งมาก มิฉะนั้นผลกระทบอาจรุนแรง
    อีกอย่าง ฉันคิดว่าฝั่งที่ทำ Playwright wrapper บน LLM มักพูดเกินจริงเรื่อง ความถี่ที่เว็บไซต์ปรับโฉมใหม่ โดยเฉพาะเมื่อเจอกับเว็บไซต์เก่าหรือเว็บไซต์ภาครัฐ ตัวอย่างเช่น ฉันดูแลชุดบราวเซอร์อัตโนมัติ Playwright ขนาดยาวที่ใช้โต้ตอบกับเว็บภาครัฐมาหลายปี และซ่อมบำรุงเพียงครั้งเดียวตอนกระบวนการทำงานของหน่วยงานเปลี่ยน ถ้าใช้ Skyvern ก็คงต้องแก้ทั้งพรอมป์ต์และเพย์โหลดอยู่ดีเพราะขั้นตอนเปลี่ยนไปแล้ว
    ความต่างเมื่อเทียบกับระบบอัตโนมัติของ Playwright คือ เราสามารถยืนยันความสำเร็จ/ล้มเหลวของแต่ละขั้นตอนและความถูกต้องของการบันทึกข้อมูลด้วย assertion ได้ จึงรู้ได้ว่าต้องอัปเดตขั้นตอน แต่ใน Skyvern ไม่เห็นว่าจะมีทางเลือกแบบนั้น เลยกังวลว่ามันอาจพลาดการเปลี่ยนแปลงของขั้นตอน แล้วเริ่มกรอกข้อมูลผิดหรือข้ามบางขั้นตอนไป

    • เป็นความจริงที่โครงสร้างพรอมป์ต์และเพย์โหลดในตอนนี้ค่อนข้างซับซ้อน แต่เราก็สามารถใช้ LLM ช่วยผู้ใช้สร้างเพย์โหลดนี้ให้ได้
      ผู้ใช้สายเทคนิคมักอยากเรียนรู้เพิ่มเติมและสร้างเพย์โหลดเอง ส่วนผู้ใช้ที่ไม่ใช่สายเทคนิคก็มักเริ่มจากให้ LLM ช่วยสร้างพรอมป์ต์สุดท้ายสำหรับ Skyvern ให้ ซึ่งแม้จะเกินความคาดหมาย แต่กลับเป็นกระบวนการที่เป็นธรรมชาติอย่างน่าประหลาด
      ขั้นที่ 1 คือการสร้างด้วยวิธีซับซ้อน ซึ่งก็คือ Playwright ขั้นที่ 2 คือสถานะปัจจุบันที่ใช้พรอมป์ต์ซับซ้อนเพื่อสร้างสิ่งที่เทียบเท่า Playwright และขั้นที่ 3 คือการสร้างสิ่งที่ช่วยสร้างสิ่งเทียบเท่า Playwright ด้วยพรอมป์ต์ที่ง่ายกว่า แต่ละขั้นช่วยลดกำแพงทักษะที่จำเป็นต่อการสร้างระบบอัตโนมัติ
      ฉันมองว่าความถี่ของการเปลี่ยนแปลงเว็บไซต์เป็นคุณค่ารองของระบบอัตโนมัติที่ใช้ LLM คุณค่าหลักคือมันรับมือกับ สถานการณ์ที่เปลี่ยนแปลงสูงมาก ได้ ตัวอย่างเช่น หากจะทำระบบอัตโนมัติสำหรับเว็บอีคอมเมิร์ซที่ป๊อปอัปโปรโมชันเปลี่ยนทุกสัปดาห์ Skyvern แทบไม่ต้องสนใจเรื่องนี้ แต่สคริปต์ Playwright อาจพังได้
      อีกเหตุผลที่ชอบตัวอย่าง Geico ก็เพราะมันแสดงให้เห็นชัดว่าสิ่งที่เมื่อก่อนทำให้อัตโนมัติได้ยากมาก ตอนนี้ทำได้ง่ายขึ้น ฟอร์มเปลี่ยนทุกครั้งที่รัน แต่ Skyvern ก็ผ่านได้สบาย
      ในแง่ความถูกต้องของข้อมูล เรากำลังเปิดตัว ฟีเจอร์ workflow ที่เชื่อมหลายงานเข้าด้วยกัน สิ่งที่น่าสนใจของฟีเจอร์นี้คือสามารถเพิ่มขั้นตอนให้ Skyvern ตรวจสอบผลลัพธ์ด้วยตัวเองก่อนดำเนินการต่อได้ เช่น ใส่สินค้าจำนวน n ชิ้นลงตะกร้า แล้วไปที่ตะกร้าเพื่อตรวจสอบสถานะของตะกร้า
      ตามที่คาดได้ สิ่งนี้ยังเป็นรากฐานให้เอเจนต์อื่นสามารถใช้เครื่องมือแบบนี้เพื่อสร้าง workflow ของตัวเองด้วยพรอมป์ต์ที่ง่ายกว่าได้เอง สรุปคือ นี่เป็นก้าวแรกของการเดินทางระยะยาวในการทำให้ระบบอัตโนมัติกระบวนการทำงานด้วย LLM ง่ายขึ้นเรื่อย ๆ
  • ณ ตอนนี้ การสร้างสตาร์ตอัปบน LLM ของบุคคลที่สาม ดูเหมือนต้องใจถึงมาก หรือไม่ก็ต้องมีโมเดลธุรกิจที่มุ่งหารายได้ระยะสั้น
    ถ้ากรอบเวลาไม่ใช่แค่ไม่กี่เดือนแต่เป็นหลายปี ความเสี่ยงก็ค่อนข้างสูง Anthropic เพิ่งลงมาเล่นในพื้นที่นี้เมื่อวาน และ OpenAI กับ Google ก็น่าจะตามมาในไม่ช้า

    • หลายบริษัทอย่าง Vercel และ Supabase ก็สร้างธุรกิจใหญ่จากการ “ครอบ” AWS
      บริษัทเหล่านี้ใช้ AWS เพื่อให้บริการผลิตภัณฑ์ของตัวเอง ทั้งที่ก็แข่งขันกับ AWS ไปพร้อมกัน ตลาดนี้มีขนาดใหญ่ และยังเปิดช่องให้มีแนวทางที่หลากหลาย
      แน่นอนว่า OpenAI, Anthropic และ Google จะสร้างธุรกิจใหญ่ในพื้นที่นี้ แต่ก็ไม่มีเหตุผลที่จะตัดความเป็นไปได้ที่คนอื่นจะมีไอเดียดี ๆ แล้วทำให้เกิดขึ้นจริงโดยอาศัยผู้ให้บริการโครงสร้างพื้นฐานรายใหญ่
    • ไม่แน่ใจว่าคำว่า “ลงมาเล่นแล้ว” หมายถึงอะไร ไม่ค่อยรู้ว่าเกิดอะไรขึ้นบ้าง
  • น่าสนใจที่เลือกโอเพนซอร์สภายใต้ AGPL
    อาจมีคำตอบอยู่ในเอกสารแล้ว แต่ลองค้นซอร์สแบบเร็ว ๆ ดูเหมือนว่าจะไม่ได้ใช้ LangChain และมีแผนจะทำ integration เพื่อส่งกลับให้คอมมูนิตี้นั้นในอนาคต เลยอยากรู้ว่าตอนสร้าง ตรรกะสายโซ่การคิด/การกระทำ ใน Skyvern ใช้อะไร และถ้าจะเริ่มใหม่ตอนนี้จะพิจารณาแนวทาง LangChain/Graph หรือไม่

    • ตอนแรกใช้ เฟรมเวิร์ก AutoGPT
      ร่องรอยของมันยังเหลืออยู่มากในส่วนอย่างงานและสเต็ปต่าง ๆ แต่พอพยายามขยายระบบและทำสิ่งที่ซับซ้อนขึ้น ก็พบว่าเฟรมเวิร์กนี้มีข้อจำกัดมาก
      ตัวอย่างเช่น ตอนนี้เราใช้สถาปัตยกรรมแบบหลายเอเจนต์ ที่มีไมโครเอเจนต์สำหรับวิเคราะห์ SVG หรือกรอก autocomplete แบบไดนามิก ซึ่งโครงสร้างแบบนี้คงทำได้ยากมากกับเฟรมเวิร์กเดิม
      เฟรมเวิร์กอย่าง LangChain เหมาะกับการทำต้นแบบช่วงแรก แต่ถ้าต้องการดันขีดจำกัดจริง ๆ มันจำกัดเกินไป
  • ถ้าคำว่า “browser automation” ยังทำให้งง มันก็คือการทำให้โปรแกรมไปควบคุมเว็บไซต์เป้าหมาย คล้าย ๆ พวก Selenium
    โดยทั่วไปคือส่งเหตุการณ์กดแป้นพิมพ์และการขยับ/คลิกเมาส์เข้าไปยังเว็บไซต์ที่คนอื่นเป็นเจ้าของ เพื่อให้เว็บไซต์นั้นทำบางอย่าง พอเข้าใจแบบนี้แล้ว คำอธิบายส่วนที่เหลือก็จะเข้าใจได้

  • ทุกครั้งที่เห็นเครื่องมือทำ workflow automation ด้วย LLM แบบนี้ ก็อดมีคำถามบางอย่างเกี่ยวกับกรณีใช้งานและผลระยะยาวไม่ได้
    อย่างแรก สงสัยว่ามันคือการเลี่ยงแรงเสียดทานที่เกิดจากการทำงานร่วมกันของเครื่องมือที่ยังไม่ดีพอหรือเปล่า เช่น ถ้าเจ้าของเว็บไซต์มี REST service ให้ใช้ มันจะมีประสิทธิภาพกว่าหรือไม่? แล้วถ้าเครื่องมือแบบนี้มีอยู่ บริษัทต่าง ๆ จะยิ่งไม่ทำ service endpoint ทั้งที่จริง ๆ ควรทำหรือไม่?
    อย่างที่สอง ถ้ามีเหตุผลที่ชอบธรรม เช่น เรื่องความปลอดภัย ที่ทำให้ไม่มี service endpoint workflow automation ก็อาจถูกใช้เพื่อหลบเลี่ยงมาตรการความปลอดภัยเหล่านั้นได้ ผู้ไม่หวังดีจะใช้เครื่องมือนี้เพื่อทำให้บริการสำคัญใช้การไม่ได้หรือไม่? คนที่สร้างเครื่องมือจะกลายเป็นผู้มีบทบาทในเรื่องนั้นหรือไม่? หรือพวก reseller จะใช้มันกว้านซื้อสินค้าที่มีความต้องการสูงจนผู้บริโภคทั่วไปซื้อไม่ได้หรือไม่?
    อย่างที่สาม ถ้ามันถูกใช้เพื่อเลี่ยงงานบำรุงรักษาที่ค้างคาของเครื่องมือภายในและกระบวนการทำงาน การมีอยู่ของเครื่องมือแบบนี้อาจกลายเป็นข้ออ้างให้ผู้บริหารเลื่อนการบำรุงรักษาออกไปอีก สุดท้ายมันอาจกลายเป็น การพึ่งพาหลัก ใน workflow ของฝ่ายซัพพอร์ต
    อย่างที่สี่ ถ้ามันถูกใช้ด้วยเจตนาดีเพื่อเลี่ยง anti-pattern ในการออกแบบเว็บไซต์ เจ้าของเว็บไซต์จะมีแรงจูงใจที่จะทำลาย workflow นั้นหรือไม่? สุดท้ายแล้วมันเป็นแค่อีกขั้นของการแข่งขันด้านอาวุธหรือเปล่า?
    ทุกครั้งที่เห็นการเอาซอฟต์แวร์ไปวางทับกระบวนการที่ซับซ้อน แล้วแทนที่จะทำให้กระบวนการต้นทางง่ายลงกลับเพิ่มความซับซ้อนอีกชั้นเพื่อกลบมัน ก็อดคิดเรื่องพวกนี้ไม่ได้ แน่นอนว่าโปรเจ็กต์นี้น่าจะมีประโยชน์ แต่ก็ยังสงสัยผลกระทบระยะยาว

    • เว็บไซต์ที่ไม่มี API โดยมากมักมีอยู่สองเหตุผล อย่างแรกคืออยากปกป้องข้อมูลแบบ LinkedIn และอีกอย่างคือไม่มีทรัพยากรหรือไม่ก็ไม่อยากทำ API แบบเว็บไซต์เล็ก ๆ หรือพอร์ทัลภาครัฐ
      Skyvern ช่วยแก้ปัญหานี้ได้ แต่ถ้าต้นทุน LLM ลดลง มันก็อาจทำให้เว็บไซต์เหล่านี้ไม่จำเป็นต้องสร้าง API เลย
      เราไม่อยากให้ Skyvern ถูกใช้กับเว็บไซต์ที่ห้ามพฤติกรรมแบบนี้ โดยเฉพาะ LinkedIn และเหตุผลที่เราไม่ได้โอเพนซอร์สโค้ดที่เกี่ยวกับ anti-bot หรือ captcha ก็เพราะมีคนขออะไรอย่าง “ปั่นคำแนะนำบน Reddit” เข้ามา เราไม่อยากสนับสนุนผู้ไม่หวังดีแบบนั้น
      โดยรวมแล้วมองว่า AI browser automation ให้ผลสุทธิในทางบวก ถ้าความจำเป็นของ API ลดลง ก็ไม่ต้องคอยดูแลทั้ง API และ UI พร้อมกัน ประสบการณ์จะเรียบง่ายขึ้น และโค้ดก็น้อยลงทำให้ระบบเรียบง่ายขึ้นด้วย
      ส่วนประเด็นสุดท้ายนั้นยังไม่มั่นใจ 100% ปกติผมตั้งสมมติฐานว่าที่บริษัทไม่ทำ API เพราะไม่มีงบมากกว่า ไม่ใช่เพราะเจตนาไม่ดี บริษัทอย่าง LinkedIn คงพยายามกันการทำ automation อยู่แล้ว แต่ผมไม่อยากเข้าไปเล่นเกมแมวจับหนูแบบนั้น
  • สงสัยว่า Skyvern จะดึงข้อมูลจากหลายเว็บไซต์ที่มีโครงสร้างต่างกัน แล้วรวม ข้อมูลแบบมีโครงสร้าง ออกมาเป็นไฟล์ CSV หรือ JSON เดียวได้หรือไม่
    เช่น ดึงอัตราดอกเบี้ยบัญชีเงินฝากจากเว็บไซต์ธนาคารหลายแห่ง แล้วแยกชื่อธนาคาร โลโก้ธนาคาร ชื่อผลิตภัณฑ์ และอัตราดอกเบี้ยของแต่ละบัญชี รวมถึงตั้งให้รันตามตารางเดิมทุกวันหรือทุกสัปดาห์ได้หรือไม่?

    • ในทางทฤษฎีทำได้ ใช้ ฟีเจอร์ workflow เพื่อตั้งค่า แล้วเชื่อมหลายงานเข้าด้วยกันเพื่อรวบรวมข้อมูล
  • อยากรู้ว่าเคยลองรัน Skyvern กับเว็บไซต์สายการบินไหม
    เช่น ใช้ดึงข้อมูลความพร้อมของที่นั่งรางวัลสำหรับตั๋วไมล์จากจุด A ไปจุด B พวกสายการบินดูเหมือนจะเปลี่ยนหน้าจอตลอดและมีมาตรการกัน scraping ค่อนข้างแรง

    • ยังไม่เคยช่วยเคสใช้งานแบบนั้นโดยตรง แต่ตอนนี้กำลังทำ integration กับบริษัทที่ใช้มันเพื่อทำการซื้อบัตรโดยสารของ Alaska และ Southwest แบบอัตโนมัติแทนคนจริง
      น่าจะเป็นในลักษณะการเบต้าเทสต์ธุรกรรมบัตรเครดิตและตรวจสอบความน่าเชื่อถือ
  • ผมกำลังทำอะไรคล้าย ๆ กันในสเกลเล็กกว่า และพื้นที่นี้ก็ดูมีอนาคตพอสมควร
    พอจำกัดขอบเขตปัญหาไว้ที่ การโต้ตอบ/การสแครปบนหน้าเดียว มันกลับเสถียรและมีประโยชน์มากในบริษัท แต่ automation แบบเอเจนต์ก็ดูน่าสนุกเหมือนกัน

    • มันมีประโยชน์มากโดยเฉพาะในสถานการณ์ที่ไดนามิกสูง
      เช่น งานกรอก contact form ของเว็บไซต์หลายร้อยแห่งนั้นจัดการความหลากหลายด้วยโค้ดปกติได้ยากมาก แต่สำหรับ AI agent กลับไม่ใช่ปัญหาใหญ่
  • อยากรู้ว่ามีตัวเลขจาก WebArena(https://webarena.dev) หรือ VisualWebArena(https://jykoh.com/vwa) หรือไม่

    • ยังไม่มี ชุดข้อมูลภายในมีอคติมากเกินไปเลยยังไม่ได้แชร์ต่อสาธารณะ แต่คาดว่าน่าจะมีออกมาในอีกไม่กี่สัปดาห์