Tool: browser_use — agent ย่อยที่รัน browser จริงเมื่อ login/กรอกฟอร์มจำเป็น
browser_use ควบคุมเบราว์เซอร์เพื่อทำงานกับเว็บที่ต้องโต้ตอบจริง เช่น กดปุ่ม กรอกฟอร์ม หรือรอข้อมูลที่สร้างด้วย JavaScript จึงใช้เมื่อการดึงหน้าเว็บแบบปกติไม่พอ
Tool นี้คืออะไร
เปิด browser จริง (Chromium ผ่าน Playwright) แล้วให้ AI ควบคุมเหมือนคนใช้งานจริง — คลิก, scroll, กรอกฟอร์ม, navigate หลายหน้า ใช้เมื่อ browse_url (ที่ใช้ Jina Reader ดึง static content) ไม่พอ เช่นหน้าที่ต้อง login, หน้าที่ JS-heavy มากจน Jina render ไม่ครบ
จุดที่น่าสนใจที่สุด: agent เรียกใช้ agent อีกตัว
browser_use ไม่ใช่แค่ automation script ธรรมดา — มันคือAI agent ตัวที่สอง จากไลบรารี browser-use ที่รับ task เป็นภาษาธรรมชาติ (เช่น “หาช่องกรอกอีเมล แล้วกรอก test@example.com”) แล้วตัดสินใจเองว่าจะคลิกตรงไหน scroll ยังไง ไม่ใช่ automation ที่เขียน selector ไว้ล่วงหน้า
จุดที่สำคัญกว่านั้น: agent ย่อยตัวนี้ขับเคลื่อนด้วยโมเดลตัวเดียวกันที่รันอยู่ในเครื่อง (ChatOpenAI ชี้ไปที่ MLX_BASE_URL เดียวกับที่ agent หลักใช้) ไม่ใช่โมเดลแยกหรือ API ภายนอก — เป็นสถาปัตยกรรมแบบagent เรียกใช้ agent โดยทั้งคู่ใช้ทรัพยากรโมเดลตัวเดียวกันในเครื่อง ไม่มีการเรียก API ต่างประเทศ
Cache-first เหมือน tool web อื่นๆ ในกลุ่ม
ก่อนจะยอมรัน browser จริง (ซึ่งช้าและใช้ทรัพยากรมาก) ระบบเช็ค cache ก่อนเสมอ — ถ้า URL นี้เคยถูก browse มาแล้วในเซสชันนี้ คืนสรุปจาก cache ทันทีโดยไม่เปิด browser เลย เพราะการเปิด Chromium ทุกครั้งมีต้นทุนสูงทั้งเวลาและหน่วยความจำ
จำกัดเวลาไว้ 120 วินาที
Agent ย่อยตัวนี้ทำงานได้ไม่แน่นอน (ต่างจาก tool อื่นที่พฤติกรรม deterministic กว่ามาก) — เพราะขึ้นอยู่กับหน้าเว็บที่กำลังเจอ, ปฏิกิริยาของ JS, ความซับซ้อนของ task ระบบจึงตั้ง timeout ไว้ที่ 120 วินาที (ปรับได้ผ่าน env) ถ้าเกินเวลาจะตัดจบด้วย error ทันที ไม่ปล่อยให้ agent ย่อยรันไม่รู้จบ
ผลลัพธ์เข้า pipeline สรุปเดียวกับ tool web อื่น
ผลลัพธ์ดิบจาก browser agent ถูกต่อท้ายด้วย context (task + URL) แล้วส่งเข้าฟังก์ชัน summarize() เดียวกับที่ web_search และ browse_url ใช้ — cache ทั้ง raw และสรุปไว้เหมือนกันทุกประการ ทำให้ recall_web เรียกดูรายละเอียดของผลลัพธ์จาก browser_use ได้เหมือนกับ URL ที่มาจาก tool web อื่นๆ ไม่ต้องมี logic แยก
ทำไมเรื่องนี้ถึงสำคัญ
browser_use แสดงให้เห็นว่าสถาปัตยกรรม agent สามารถซ้อนกันได้ — ไม่ใช่ทุก task ต้องแก้ด้วยการเพิ่มความสามารถให้ agent หลักโดยตรง บางครั้งการมอบหมายงานเฉพาะทาง (ควบคุม browser แบบโต้ตอบ) ให้ agent ย่อยที่ออกแบบมาเพื่องานนั้นโดยเฉพาะ (พร้อมโมเดลตัวเดียวกันในเครื่อง ไม่เพิ่มต้นทุนภายนอก) ให้ผลลัพธ์ที่ดีกว่าและปลอดภัยกว่าการพยายามให้ agent หลักจัดการทุกอย่างเอง — และเพราะรันหนักกว่า tool อื่น จึงถูกจัดเป็นตัวเลือกสุดท้าย ไม่ใช่ตัวเลือกแรก
ความคิดเห็น
กำลังโหลดความคิดเห็น...