AI Agent 的代理技术栈 — browser-use、Computer Use、MCP、Operator

过去这一年里我们看到的 Agent 流量，比之前五年加起来还要多。形态也变了。2023 年典型的客户是跑一批 Playwright worker 反复爬那五个固定域名；2026 年典型的客户则是跑一个 LLM 驱动的 Agent，它的执行计划指到哪它就去哪——在十几家零售商之间比价、在 SEC 文件和财报电话会纪要之间来回跳着做调研、对着一长串小众网站自动下单。这类负载的代理决策，跟你给 2023 年爬虫做的决策完全是两回事，而很多 Agent 开发者都做错了。

这篇文章其实就是客户上门说"本地跑得好好的，一上生产就挂"时我们给出的那套实操建议。我们会讲清楚:为什么 Agent 流量在反爬栈眼里显得可疑、什么样的会话策略真正管用、怎么按目标站的难度档位选 IP 池,以及我们看到客户最终沉淀下来的几套接线方案——覆盖 browser-use、Anthropic Computer Use、OpenAI Operator 以及 MCP 风格的工具服务器。这些都不是纸上谈兵,而是从我们工单队列里提炼出来的真实模式,并在合适的地方回链到住宅代理、ISP 静态、移动和数据中心产品。

为什么 Agent 流量是反爬的活靶子

拿一个全新的 LLM Agent,配一个干净的住宅 IP,丢到一个有 Cloudflare 防护的站点上,看着它失败。IP 没问题,有问题的是 Agent。原因跟 2010 年代早期 Selenium 脚本失败的原因一模一样:就算 IP 看起来像人,流量也不像人。

有三种模式会稳定地把 Agent 出卖掉。

节奏太均匀。 人的停留时间是有起伏的——扫两秒、点一下、看八秒、滚动、走神、再回来。而 LLM 驱动的 Agent 是一个确定性循环:收到截图或 DOM、思考几百毫秒、点击、等页面加载、重复。每个动作之间的间隔会紧紧地聚集在模型的响应延迟附近。行为模型在一次会话里就能识别出来——十来次交互之后,这个时间间隔的直方图就不像人了。

视口暴露身份。 browser-use 这个基于 Playwright 的库,已经成了事实上的开源 Agent 标准栈,它默认用 headless Chromium 配一个固定视口。Anthropic Computer Use 从一块虚拟显示器上截图,这块显示器通常是 1024x768。OpenAI Operator 跑在远端基础设施上,带着 OpenAI 自己的指纹。这些都跟反爬从真实用户那里看到的视口分布对不上。

鼠标轨迹是直线。 Playwright Agent 点击一个坐标时,光标是直接跳过去的。真人的光标会划弧线、会过冲、会回拉修正、会抖动。PerimeterX 和 Akamai 的传感器层尤其会采集鼠标移动轨迹,对这种直线"瞬移"打很低的分。

User-Agent 是框架默认值。 browser-use 自带 Playwright 的 UA,Computer Use 也有自己的默认值。不去覆盖这些默认值的 Agent,会跟成千上万个同样的 Agent 共用同一个指纹,而这些指纹早就进了同一批威胁情报源。等你把它指向一个真实站点的时候,那个默认 UA 已经在拦截名单上了。

这就把失败模式分成了两半。再高端的住宅 IP 也救不了一个节奏和视口都在大喊"我是自动化"的 Agent;而一个调教好、隐身做得到位的 Agent,仍然需要一个干净的 IP。这两层是叠加的。 只在一层上花钱的开发者,会想不通自己的成功率为什么总是不上不下。

三层检测难题

代理只是三层中的一层,只盯着代理想问题的客户,预算分配是错的。

第一层:TLS 指纹。 JA3 和 JA4 是对 TLS ClientHello 做的哈希——密码套件列表、扩展顺序、支持的椭圆曲线组。真实的 Chrome 会产出一个特定的 JA4。用默认 urllib3 的 Python requests 会产出另一个,而这个值跟全世界所有其他 Python 脚本干干净净地映射在一起。TLS 指纹跟 User-Agent 头对不上,就是一个很强的自动化信号。代理不会改变你的 TLS 指纹——代理是透明的,ClientHello 还是你的客户端产出的——所以这一层是 Agent 自己的活。

第二层:IP 类别。 这才是代理所在的层。数据中心 ASN(AWS、GCP、各大主机托管商)默认被标为高风险。来自真实 ISP 的住宅 ASN 评分更高。移动运营商评分最高,因为对站点来说,误封一个运营商 IP 的代价太大了。ISP 类代理——托管在数据中心、但挂着住宅 ASN——处在中间。

第三层:行为。 请求一旦进来,会话就会随时间被持续打分。鼠标移动、点击节奏、滚动模式、页面停留时长。默认情况下,Agent 在这一层都很糟糕。

陷阱在于:只修好一层,另外两层照样把你标出来。高端住宅配 Python 的 TLS 指纹,会失败;调教好的 headless Chrome 跑在 AWS IP 上,会失败。代理是答案的一部分,不是答案的全部。

粘性还是轮换:Agent 的会话难题

这是我们见到的最大的配置错误。客户带着爬虫时代的习惯过来——那个年代默认就是按请求逐次轮换——照着这个思路配 Agent,会话状态立刻就崩了。

Agent 是有状态的。一个在做下单的 Agent,有购物车、有会话 cookie、有 CSRF token,还有一堆 UI 状态,这些全都假定是同一个浏览器在跨多次请求跟服务器对话。在"加入购物车"和"去结算"之间轮换 IP,站点就会让会话失效——有时悄无声息,有时直接把 IP 轮换当成劫持企图标记出来。不管哪种,Agent 都会丢掉进度然后重试,这既烧带宽又拉高反爬的怀疑度。

对几乎所有 Agent 负载来说,正确的设置都是粘性会话。在 Hell World 住宅代理上,粘性是通过用户名来配置的——加一个会话 token 后缀,形如 username-session-abc123——在上游 IP 轮换之前能保持大约 30 分钟。ISP 静态本身就是粘性的。移动粘性通常是 10-30 分钟,具体取决于 IP 池。

时间窗口很关键。粘性窗口太短,会话会在流程中途丢状态;住宅上粘性窗口设太长也没用,底层 IP 到点照样在上游轮换,因为住宅 IP 是真实的 ISP 连接,本来就会循环。做得好的客户会把窗口设得比自己最长的任务再长一点点——一个 5 分钟的下单流程,配 10 分钟粘性就很从容。而对动辄数小时的调研会话,ISP 静态更稳妥,因为底下什么都不会轮换。

还有一套模式适合长时间运行的 Agent:按任务轮换、任务内粘性。Agent 从队列里取一个任务,拿到一个全新的粘性会话,跑到完成,丢掉这个会话。下一个任务再拿一个新的。对于任务彼此独立的 Agent 集群——调研、比价、监控——这才是对的形态。

按目标档位选 IP 池

不是每个目标都需要同一种代理。数据中心和移动在零售价上大约差 30 倍,那些不管什么目标都默认用住宅的客户,在低对抗目标上是在超额花钱。

目标档位	示例	推荐 IP 池	粘性窗口
第一档 — 低反爬	公开文档、新闻站、搜索结果页、政府开放数据、维基百科	数据中心或轻量住宅	短窗口或逐请求
第二档 — Cloudflare 防护的 SaaS、B2B	大多数 SaaS 后台、B2B 门户、中端电商、分类信息	住宅	5-10 分钟
第三档 — 高对抗、高价值	银行、票务、球鞋站、社交平台、高端流媒体、重账号工作流	ISP 静态独享,或 4G 移动	整个会话生命周期

第一档是 Agent 开发者最浪费钱的地方。如果你的 Agent 是去那些没有反爬的站点上调研公开信息,数据中心代理就够了,而且便宜一个数量级。唯一值得加钱往上走的理由,是数据中心覆盖不到的地理位置。

第二档是我们工单里 Agent 流量的大头。大多数 B2B SaaS 用的是中等灵敏度的 Cloudflare Bot Management。住宅粘性 5-10 分钟是标准答案。廉价池在这里会挂,而高端池能过——原因我们在反爬态势那篇里讲过:便宜住宅 IP 回收得太快,近期的滥用历史还粘在上面。

第三档是 Agent 要么贵贵地成功、要么便宜地失败的地方。重账号流程——任何要登录的、任何背后有风控团队的——对 IP 变化的惩罚极其凶狠。ISP 静态独享是首选。你按月租下一个特定 IP,站点看到你的账号永远从同一个地址过来,你就不会触发"异常登录位置"告警。球鞋发售或票务的模式是移动粘性,详见球鞋代理指南。

接线方案

我们看到客户实际部署的三套配置,大致形态如下。

browser-use + 住宅粘性

browser-use 接受一个 BrowserConfig,里面可以传一个 Playwright 风格的 proxy 字典:

proxy_user = "your_account-session-task42"
proxy = {
  "server": "http://gate.hellworld.io:7777",
  "username": proxy_user,
  "password": "your_password"
}

用户名里的会话 token(-session-task42)维持着粘性窗口。每个任务挑一个 token,在任务期间一直用,任务结束就丢掉。Agent 的规划器不需要知道代理的存在——它看到的是 Playwright 加载出来的页面,而那已经是经代理路由过的页面了。再配上一个 Chrome UA 和一个调教过的视口,你就有了一套能用的第二档技术栈。

Anthropic Computer Use + ISP 独享

Computer Use 跑在一个带虚拟显示器的容器里。出站流量会走操作系统层面配置的 HTTP/HTTPS 代理,通常是通过传进去的 HTTP_PROXY 和 HTTPS_PROXY 环境变量。对于重账号工作流——一个管理 SaaS 后台的 Agent、一个银行流程——把这些环境变量指向你按月租下的 ISP 静态代理。

相比住宅,它有两点好处。一是 IP 不轮换,所以只要 Agent 在跑,会话就一直稳定。二是同一个 IP 多次对着同一目标运行,会积累正向声誉,而不是每次都从冷启动开始。当一个 ISP IP 向某个 SaaS 账号持续输送几周的正常流量之后,反爬栈就学会了:这个 IP 加这个账号是一对正常组合。

MCP 服务器 + 按任务粘性住宅

MCP(Model Context Protocol)是 Anthropic 给工具服务器定的标准——Agent 调用 MCP 服务器暴露出来的工具,比如 fetch_url 或 search_web。当这些工具发起出站 HTTP 请求时,代理配置由 MCP 服务器持有,Agent 根本看不到。

模式是这样的:服务器从 Agent 那里接一个 task_id,据此派生出一个会话 token,然后把抓取请求通过住宅上的 username-session-${task_id} 路由出去。每个任务拿到自己专属的粘性出口;任务一结束,会话就丢掉。这是我们在生产栈里见到的最干净的职责分离——Agent 负责规划,MCP 层负责网络身份,而按任务隔离限制了某个 IP 被标记后的交叉污染。

地理位置比 Agent 开发者想的更重要

数量惊人的一批 Agent 开发者会忘了:"调研德国当前的价格"需要一个出口在德国的 IP。他们从美国的执行环境、用一个美国住宅 IP 跑 Agent,Agent 去搜 Google,Google 返回的是 google.com 的英文结果配美国价格,然后 Agent 一本正经地把这些当成德国价格报上来。Agent 自己根本意识不到。用户拿到错误结果,反过来怪模型。

Hell World 住宅覆盖 210 个国家,支持国家、州/省、城市级定位。地理选择器放在用户名里——username-country-de-session-task42 就是一个德国住宅出口。对于做本地化调研的 Agent,要把地理感知做进规划器:任务说"在德国"时,工具调用就指定对应的地理参数。14 个品牌的地理覆盖明细在对比页里,需要知道我们都测过哪些的话可以去看。

成本账

一个典型的 Agent 任务每小时烧掉 50-300 MB 带宽,取决于它是截图密集型(Computer Use)还是 DOM 密集型(browser-use)。按我们 $0.23/GB 的住宅价算,一小时 Agent 工作的成本是个位数美分。这跟 LLM 推理成本比起来微不足道。

真正会快速飙升的数字是重试。一个撞上 CAPTCHA、失败、重新规划、重试、再次失败的 Agent,在单个任务上很容易把带宽翻 5-10 倍。挑战验证页会加载图片和 JS,这些全都会计费。真正重要的成本优化是避免重试——第一次就选对池、正确地维持粘性会话、把 Agent 的隐身调到不触发挑战验证。在廉价池上省下的那 $0.05/GB,跟因重试损失掉 30% 任务比起来根本不值一提。

该监控什么

按优先级排序,能早期发现问题的几个指标:

按目标的成功率。 把任务按目标域名分桶。某个桶掉下去,意味着那个目标收紧了,或者你这个池的 IP 进了它的拦截名单。局部信号每次都比整体成功率更有用。

被标记前的会话寿命。 一个粘性会话在被挑战之前能处理多少次请求?如果这个数字随时间下降,说明你的池在退化,或者你的行为在泄露身份。如果它随目标不同而变化,说明你有针对特定目标的调优要做。

出口 IP 类别构成。 抽样出口,检查 ASN 分布。如果你买的是住宅,却有 20% 的出口显示为数据中心 ASN,说明你的池在混类——去找你的供应商谈。

代理解决不了什么

我们是卖代理的,所以直说:没有任何代理能修好一个工程做得稀烂的 Agent。TLS 指纹错了,IP 无所谓;节奏机械了,IP 无所谓;视口是框架默认值,IP 无所谓。隐身和 IP 声誉是两个独立的层,两者都得做对。

我们见过廉价池在调教好的 Agent 上能用,也见过高端池在马虎的 Agent 上照样挂。把第一轮迭代花在 Agent 本身上——把 User-Agent、视口、TLS 指纹、节奏都搞对。然后再加代理。顺序很重要,因为当你确定 Agent 本身是干净的,调试会快得多。

一旦做到了这一点,代理这一层就成了一个有实际意义的杠杆。第一档的活转到数据中心,省钱。第二档选对住宅品牌,不再在 Cloudflare 上栽跟头。第三档走 ISP 或移动,登录态流程不再被标记。对比页是挑池的起点;住宅、ISP、移动和数据中心各页有具体细节。按档位选、把粘性配对、在任务需要的地方做地理定位、上生产后做监控。这就是全部的技术栈。