Proxy สำหรับ AI agent แบบ browser-use และ computer-use (คู่มือ 2026)

ปี 2026 คือปีที่ AI agent เลิกเป็นแค่เดโม browser-use, agent สไตล์ Operator ของ OpenAI, computer use ของ Anthropic และเฟรมเวิร์กอีกหลายสิบตัวที่สร้างบน Playwright ตอนนี้ขับเคลื่อนเบราว์เซอร์จริงกับเว็บไซต์จริง — จองตั๋ว ซื้อของ ค้นคว้า เฝ้าติดตาม และทั้งหมดนั้นชนกำแพงเดียวกัน คือ เว็บไซต์ที่พวกมันทำงานด้วยมองว่ามันเป็นบอท เพราะมันเป็นบอทจริง ๆ

คู่มือนี้ครอบคลุมเลเยอร์ proxy สำหรับ AI agent ที่ขับเบราว์เซอร์โดยเฉพาะ ถ้า agent ของคุณใช้ไลบรารี HTTP แทนเบราว์เซอร์ (เครื่องมือ LangChain, สแครปเปอร์ภายใน CrewAI) ดู Proxy สำหรับ AI Agent: LangChain, AutoGPT & CrewAI — บทความนี้พูดถึง agent ที่ควบคุมเบราว์เซอร์เต็มรูปแบบ

ทำไม Browser Agent ถึงโดนบล็อกเร็วกว่าสแครปเปอร์

ขัดกับสามัญสำนึกแต่เป็นเรื่องจริง: agent LLM ที่ขับเบราว์เซอร์ Chrome จริงมักโดนบล็อกเร็วกว่าสแครปเปอร์ Python ธรรมดา ด้วยสามเหตุผล:

1. IP ดาต้าเซ็นเตอร์ + เบราว์เซอร์ที่สมบูรณ์แบบ = ไม่เข้ากัน ลายนิ้วมือเบราว์เซอร์บอกว่า "Chrome จริงบนฮาร์ดแวร์จริง" แต่ IP เป็นของ AWS หรือ GCP — ซึ่งเป็นที่ที่ agent ส่วนใหญ่รันอยู่ ผู้ให้บริการ anti-bot ให้น้ำหนักกับ ASN ของ IP สูงมาก ลายนิ้วมือระดับ residential บน ASN ของดาต้าเซ็นเตอร์คือลายเซ็นของการทำงานอัตโนมัติตามตำรา
2. Agent ลองใหม่เหมือนเครื่องจักร เมื่อแอ็กชันล้มเหลว ลูป LLM จะลองใหม่ทันที จาก IP เดิม ด้วยจังหวะเวลาที่แทบจะเหมือนกันเป๊ะ การลองซ้ำเหมือนกันเร็ว ๆ สามครั้งคือบทเรียนพื้นฐานของการตรวจจับเชิงพฤติกรรม
3. CDP ทิ้งร่องรอย เฟรมเวิร์ก agent ส่วนใหญ่ขับเบราว์เซอร์ผ่าน Chrome DevTools Protocol เว็บไซต์จะตรวจหา navigator.webdriver, สิ่งบ่งชี้จังหวะเวลาเฉพาะของ CDP และสัญญาณ headless เมื่อรวมกับ IP ที่ถูกตั้งธง คะแนนจะข้ามเกณฑ์การบล็อกทันที

IP เป็นสิ่งที่แก้ได้ถูกที่สุดในสามอย่างนี้ และการแก้แค่มันอย่างเดียวก็แก้ปัญหาการบล็อกได้ส่วนใหญ่: route agent ผ่าน residential proxy เพื่อให้เรื่องราวของ IP สอดคล้องกับเรื่องราวของเบราว์เซอร์

การตั้งค่า: browser-use กับ Residential Proxy

browser-use ตั้งอยู่บน Playwright การรองรับ proxy จึงเป็นแบบเนทีฟ รูปแบบคือ: หนึ่ง sticky session ต่อหนึ่งงานของ agent เพื่อให้ IP คงที่ระหว่างที่ agent ทำงาน และได้ IP ใหม่สำหรับงานถัดไป

from browser_use import Agent, Browser, BrowserConfig
from langchain_openai import ChatOpenAI
import uuid

task_id = uuid.uuid4().hex[:8]

browser = Browser(config=BrowserConfig(
    proxy={
        "server": "http://us.jibaoproxy.com:913",
        "username": f"USERNAME-session-{task_id}",   # sticky: same IP for this task
        "password": "PASSWORD",
    },
))

agent = Agent(
    task="Find the current price of the Sony WH-1000XM6 on the three largest US retailers.",
    llm=ChatOpenAI(model="gpt-4o"),
    browser=browser,
)
result = await agent.run()

รายละเอียดสำคัญ: ส่วนต่อท้าย session-{task_id} ถ้าไม่มีมัน gateway แบบหมุนเวียนอาจส่ง IP ใหม่ให้ agent กลางคัน — ของในตะกร้าหายไป การล็อกอินหลุด และ agent เสีย LLM call ไปกับการทำขั้นตอนเดิมซ้ำ ถ้ามีมัน งานจะรันบน IP เดียวตั้งแต่ต้นจนจบ และงานถัดไปจะได้ IP สะอาดใหม่

การตั้งค่า: ลูป Raw Playwright / Computer-Use

ถ้าคุณสร้างลูป agent ของตัวเองบน Playwright (รูปแบบที่อยู่เบื้องหลังการ implement แบบ Operator และ computer-use ส่วนใหญ่) proxy จะอยู่บน browser context:

from playwright.async_api import async_playwright

async with async_playwright() as p:
    browser = await p.chromium.launch(headless=False)
    context = await browser.new_context(
        proxy={
            "server": "http://us.jibaoproxy.com:913",
            "username": "USERNAME-session-agent42",
            "password": "PASSWORD",
        },
        viewport={"width": 1366, "height": 768},
        locale="en-US",
        timezone_id="America/Chicago",   # match the proxy country
    )
    page = await context.new_page()
    # ... agent loop: screenshot -> LLM -> action -> repeat

ตั้ง locale และ timezone_id ให้ตรงกับประเทศของ proxy agent ที่ท่องเว็บจาก IP ของสหรัฐแต่มีนาฬิกาเป็น UTC+8 คือความไม่สอดคล้องที่ระบบเชิงพฤติกรรมจะนำมาคิดคะแนนต่อต้านคุณ

proxy แบบ per-context ยังให้คุณ หนึ่งเบราว์เซอร์ หลาย agent: แต่ละ new_context() สามารถพก session suffix ของตัวเองได้ ดังนั้นงาน agent สิบงานที่รันพร้อมกันจึงรันบน residential IP สิบตัวที่ต่างกันโดยไม่ต้องมีโปรเซส Chrome สิบตัว

กลยุทธ์ Session สำหรับโหลดงานของ Agent

โหลดงานของ agent	กลยุทธ์ session	เหตุผล
ค้นคว้า / เช็กราคา (ไม่ล็อกอิน)	Sticky, 10 นาที, session ใหม่ต่อหนึ่งงาน	คงที่ภายในงาน, IP ใหม่ข้ามงาน
การทำงานในบัญชีที่ล็อกอินแล้ว	Sticky 30 นาที, session ID เดิมทุกครั้งที่รัน	เว็บไซต์ตั้งธงบัญชีที่กระโดดข้ามประเทศระหว่างการล็อกอิน
ขั้นตอน checkout / จอง	Sticky 30 นาที	การเปลี่ยน IP กลาง checkout ทำให้ session ตายและทริกเกอร์การตรวจสอบการฉ้อโกง
การเฝ้าติดตามปริมาณสูง (หลายร้อยหน้า)	หมุนเวียน, ไม่ปักหมุด session	เพิ่มความหลากหลายของ IP สูงสุด, ไม่มีสถานะที่ต้องรักษา

การควบคุมต้นทุน: Agent กิน Bandwidth

ทราฟฟิก residential คิดเงินต่อ GB และ browser agent ดึงทั้งหน้า — รูปภาพ ฟอนต์ ตัวติดตาม — ไม่เหมือน HTTP สแครปเปอร์ ถ้าไม่จัดการ งานของ agent หนึ่งงานอาจกินไป 20–50 MB สามวิธีแก้ เรียงตามผลกระทบ:

1. บล็อกทรัพยากรหนักที่ LLM ไม่ต้องการ:

   await context.route("**/*.{png,jpg,jpeg,webp,gif,woff,woff2,mp4}",
                       lambda route: route.abort())

   ถ้า agent ของคุณอ่านสกรีนช็อต ให้เก็บรูปภาพไว้บนหน้าเป้าหมายแต่ยังคงบล็อกวิดีโอและฟอนต์ ถ้ามันอ่าน DOM/accessibility tree ก็บล็อกรูปภาพด้วย — ลดทราฟฟิกลง 60–80%
2. Route เฉพาะสิ่งที่ต้อง route การเรียก LLM API (OpenAI/Anthropic) ต้องไม่ผ่าน residential proxy — นั่นคือ GB ที่เสียเปล่าล้วน ๆ และเพิ่ม latency ให้ proxy เฉพาะ browser context ไม่ใช่ host process
3. จำกัดการลองใหม่ที่ระดับเฟรมเวิร์ก ลองใหม่ได้สูงสุดสองครั้ง พร้อม backoff และ session ID ใหม่ในครั้งที่สอง — IP ใหม่แก้การบล็อกได้มากกว่าการลองครั้งที่สามที่เหมือนเดิม

ด้วยการบล็อกรูปภาพและการ route แบบจำกัดขอบเขต งานของ browser-agent ทั่วไปจะอยู่ในช่วง 2–8 MB — ที่ $2/GB นั่นคือไม่กี่เซ็นต์ต่อร้อยงาน

สิ่งที่ Proxy แก้ไม่ได้

ส่วนพูดความจริง residential IP แก้ความไม่เข้ากันของ ASN และชื่อเสียงของ IP ซึ่งเป็นสัญญาณเดี่ยวที่หนักที่สุดในการให้คะแนน anti-bot ปี 2026 แต่มันไม่ได้แก้:

• การตรวจจับ CDP/headless — ใช้ตัวเลือก stealth ของเฟรมเวิร์กคุณ (browser-use มาพร้อม launch flag ที่แพตช์แล้ว; สำหรับ raw Playwright ให้ดูแพตช์แบบ rebrowser) และเลือกโหมด headed สำหรับขั้นตอนที่มีมูลค่าสูง
• การทำลายนิ้วมือ TLS — ไม่ใช่ปัญหาสำหรับ agent ที่ใช้เบราว์เซอร์จริง (TLS ของเบราว์เซอร์เป็นของแท้) แต่มันเป็นเหตุผลที่คุณไม่สามารถ "แค่รีเพลย์" คำขอของ agent ด้วย requests ในภายหลังได้ ดู JA3/JA4 อธิบาย
• การให้คะแนนเชิงพฤติกรรมบนสตรีมของแอ็กชัน — เพิ่มดีเลย์สุ่มเล็ก ๆ ระหว่างแอ็กชัน และหลีกเลี่ยงพิกัดคลิกที่ตรงพิกเซลเป๊ะ ๆ ในแต่ละการรัน

วางทั้งสามอย่างซ้อนกันบน residential IP แล้ว browser agent จะผ่านการตรวจสอบเดียวกับที่ผู้ใช้จริงผ่าน สำหรับเป้าหมายที่ยากที่สุด (DataDome, PerimeterX) ดู คู่มือ DataDome/PerimeterX ของเรา

สรุป

• Agent บน IP ดาต้าเซ็นเตอร์เปิดเผยตัวเอง; residential IP ทำให้เรื่องราวของ IP สอดคล้องกับเรื่องราวของเบราว์เซอร์
• หนึ่ง sticky session ต่อหนึ่งงานของ agent; session ID เดิมตลอดไปสำหรับบัญชีที่ล็อกอินแล้ว; หมุนเวียนสำหรับการเฝ้าติดตามแบบไร้สถานะ
• จับคู่ timezone_id/locale ให้ตรงกับประเทศของ proxy
• บล็อกรูปภาพ/ฟอนต์/วิดีโอ และอย่า route การเรียก LLM API ผ่าน bandwidth residential เด็ดขาด
• ลองใหม่ด้วย session ID ใหม่ ไม่ใช่ IP เดิม