Browser-Use 与 Computer-Use AI Agent 的代理配置指南（2026）

2026 年是 AI agent 不再只是 demo 的一年。browser-use、OpenAI 的 Operator 式 agent、Anthropic 的 computer use，以及十几个基于 Playwright 搭起来的框架，如今都在驱动真实浏览器去访问真实网站——订票、下单、调研、监控。而它们全都撞上同一堵墙：它们操作的那些网站把它们当作机器人，因为它们就是机器人。

这篇指南专门讲驱动浏览器的 AI agent 的代理层。如果你的 agent 用的是 HTTP 库而不是浏览器（LangChain 工具、CrewAI 里的爬虫），请看 AI Agent 代理实战：LangChain、AutoGPT 与 CrewAI——本文讲的是控制完整浏览器的 agent。

为什么浏览器 Agent 比爬虫更快被封

反直觉但确实如此：一个驱动真实 Chrome 浏览器的 LLM agent，往往比一个朴素的 Python 爬虫被封得更快。三个原因：

1. 数据中心 IP + 完美浏览器 = 自相矛盾。浏览器指纹说「真实硬件上的真实 Chrome」，但 IP 属于 AWS 或 GCP——大多数 agent 都跑在那里。反爬厂商给 IP 的 ASN 很高的权重；一个住宅级的指纹配上数据中心 ASN，是教科书级的自动化特征。
2. Agent 像机器一样重试。当一个动作失败时，LLM 循环会立即从同一个 IP、以几乎相同的节奏重试。连续三次飞快的相同重试，是行为检测的入门课。
3. CDP 会留下痕迹。大多数 agent 框架通过 Chrome DevTools Protocol 驱动浏览器。网站会探测 navigator.webdriver、CDP 特有的时序痕迹以及 headless 的破绽。再叠加一个被标记的 IP，分数瞬间就越过封禁阈值。

这三者里 IP 是最便宜的修复项，而且光修它就能解决大部分封禁：把 agent 的流量走住宅代理，让 IP 的故事和浏览器的故事对得上。

配置：browser-use 配住宅代理

browser-use 跑在 Playwright 之上，所以原生支持代理。模式是：每个 agent 任务一个 sticky 会话，让 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：本任务内保持同一个 IP
        "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} 后缀。没有它，轮换网关可能在任务中途给 agent 换一个新 IP——购物车清空、登录掉线，agent 白白浪费 LLM 调用去重做步骤。有了它，整个任务从头到尾跑在一个 IP 上，下一个任务再拿一个干净的。

配置：原生 Playwright / Computer-Use 循环

如果你是在 Playwright 上自建的 agent 循环（大多数 Operator 式和 computer-use 实现背后的模式），代理就配在浏览器 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",   # 与代理所在国家匹配
    )
    page = await context.new_page()
    # ... agent 循环：截图 -> LLM -> 动作 -> 重复

把 locale 和 timezone_id 设成与代理所在国家匹配。一个从美国 IP 浏览、却带着 UTC+8 时钟的 agent，是行为系统会给你扣分的不一致。

按 context 配代理还能让你做到一个浏览器，多个 agent：每个 new_context() 都能带自己的 session 后缀，于是十个并发的 agent 任务可以跑在十个不同的住宅 IP 上，而不需要起十个 Chrome 进程。

Agent 工作负载的会话策略

Agent 工作负载	会话策略	原因
调研 / 比价（无需登录）	Sticky，10 分钟，每任务换新会话	任务内稳定，跨任务换新 IP
登录态账号操作	Sticky 30 分钟，每次运行用同一个 session ID	网站会标记两次登录之间跨国跳变的账号
结账 / 订购流程	Sticky 30 分钟	结账中途换 IP 会让会话失效并触发风控审核
大批量监控（数百页）	轮换，不钉会话	最大化 IP 多样性，没有状态需要保留

成本控制：Agent 很烧流量

住宅流量按 GB 计费，而浏览器 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/无障碍树，那图片也一起拦——能砍掉 60–80% 的流量。
2. 只路由该路由的东西。LLM API 调用（OpenAI/Anthropic）绝不能走住宅代理——那是纯粹浪费 GB 还增加延迟。代理浏览器 context，而不是宿主进程。
3. 在框架层面限制重试。最多两次重试，带退避，第二次换一个新 session ID——一个新 IP 解决的封禁，比第三次相同的尝试要多。

开启图片拦截和按需路由后，典型的浏览器 agent 任务能落在 2–8 MB 区间——按 $2/GB 算，每一百个任务也就几美分。

代理解决不了什么

实话实说环节。住宅 IP 能修复 ASN 不匹配和 IP 信誉问题，这是 2026 年反爬打分里最重的单一信号。但它修复不了：

• CDP/headless 检测——用你框架的 stealth 选项（browser-use 自带打过补丁的启动参数；原生 Playwright 可以看 rebrowser 风格的补丁），高价值流程优先用 headed 模式。
• TLS 指纹——对真实浏览器 agent 来说不是问题（浏览器的 TLS 是真货），但这正是为什么你后面不能用 requests「直接重放」agent 的请求。见 JA3/JA4 详解。
• 动作流上的行为打分——在动作之间加入小幅随机延迟，避免多次运行间出现像素级完全相同的点击坐标。

把这三样都叠在一个住宅 IP 上，浏览器 agent 就能通过真实用户同样的检查。对于最硬的目标（DataDome、PerimeterX），见我们的 DataDome/PerimeterX 指南。

小结

• 跑在数据中心 IP 上的 agent 等于自报家门；住宅 IP 让 IP 的故事和浏览器的故事对得上。
• 每个 agent 任务一个 sticky 会话；登录态账号永远用同一个 session ID；无状态监控用轮换。
• 把 timezone_id/locale 对齐到代理所在国家。
• 拦掉图片/字体/视频，绝不让 LLM API 调用走住宅带宽。
• 重试要换新 session ID，而不是用同一个 IP。