agent 有了自己的浏览器，403 那堵墙还是过不去
Hello，我是飞飞。
Cloudflare 这周发了个东西叫 Kitesurf，说是给 AI agent 专门造的浏览器。
我第一反应是，这不就是 headless Chromium 套个壳吗。结果点进官方博客一看，完全不是那么回事。它是拿 Rust 编译成 WebAssembly，跑在 Cloudflare Workers 的 V8 隔离环境里，12 周从零造出来的。没有 Chromium，没有 UI，连 JIT 都没有。
这跟我天天在用的那套抓网页的路子，走的完全是两条路。
先撇清一下。七月十号我写过一篇「浏览器住进了 Claude Code」，讲的是 Claude Code 桌面版内置了浏览器之后，我只敢让 agent 看、不敢让它动。那篇盯的是权限怎么划。这篇不重讲那条线，只盯一个问题：给 agent 造一个它自己的浏览器，跟让它学着用人的浏览器，到底差在哪。
不是另一个无头浏览器
Kitesurf 跟 Puppeteer、Playwright 背后那套 headless Chromium 长得完全不像。
Chromium 是给人造的。它背着标签页管理、主题、扩展、60fps 渲染这一大堆给人看的东西。你把 UI 关掉变成 headless 模式给 agent 用，那些给人看的包袱还在，只是人不看了。
Kitesurf 反过来。官方博客里有句话我读了两遍：AI 不在乎标签页、主题、浏览器扩展，它在乎的是 token 数量、上下文窗口、可扩展性和成本。
说白了，人看的那些东西，对 agent 全是累赘。所以他们从零造了一个只服务 agent 的引擎。
架构拆成四块。管会话的、跑 JS 的、画像素的、管网络出口的，各自隔离，互相碰不着对方的资源。
JS 执行用的是 Boa，一个用 Rust 写的引擎。CSS 解析用的是 Stylo，Firefox 的那套。从头到脚没有一行 Chromium 代码。12 周，从零搓出来一个能跑 21 万条标准测试的浏览器引擎，这帮人是真敢干。
有一点让我上心：它兼容 CDP 协议。这意味着你现在用 Playwright 写的脚本，理论上换个 endpoint 指向 Kitesurf 就能跑，不用改代码。
两条路正面撞上了
我天天在跑的那条抓网页链路，是典型的「让 agent 学用人的浏览器」路线。
我的 content-researcher 这个 skill 抓网页有两条腿。主力是 playwright MCP，启动一个真实的 Chromium 实例去抓页面。被 403 或超时挡回来了，退到 jina.ai 的转换服务，把页面渲染成干净的 markdown 文本。两条腿配合着，大部分站能过。
这套东西能用，但重。每次抓一个页面，背后是一个完整的 Chromium 在那儿转，渲染引擎、JS 引擎、网络栈一整套全拉起来。我那条流水线一跑起来经常同时抓好几个页面，内存噌一下就上去了。有一回半夜跑素材采集，四五个页面同时抓，机器风扇直接起飞，我醒了过来查日志才发现是 Chromium 把内存吃满了。
Kitesurf 走的路完全不同。它不启动 Chromium，不占那份内存，不背那些给人看的包袱。Cloudflare 给了一组 14 个 URL 的基准测试数据，我把跟我最相关的几个数摆出来。
截图场景，Kitesurf 内存 57.8 MiB，Chromium 271 MiB，省了 4.7 倍。HTML 提取更狠，39.4 MiB 对 273.7 MiB，差了 7 倍。打个比方，Chromium 是开一辆 SUV 去便利店买瓶水，Kitesurf 是骑个自行车去，水一样买得到，油钱差了好几倍。
但有一个数得掰清楚。
墙钟时间，也就是从发请求到拿到结果你实际等了多久，Kitesurf 反而慢。截图慢 1.8 倍，HTML 提取慢 1.7 倍。原因直白：它没有 JIT 编译器。Chromium 的 V8 引擎有 JIT，遇到热代码能即时编译加速；Kitesurf 用的 Boa 引擎是解释执行，快不起来。
翻译成我的体感：我那条流水线串行跑，同时最多抓三五个页面，多等一秒其实没那么疼。倒是 Chromium 撑爆内存让我半夜爬起来查日志更疼。
省的是谁的钱
说真的，这里有个容易搞混的点。
Kitesurf 省的是基础设施成本，不是你的等待时间。
对 Cloudflare 来说，它卖的是 Browser Run 这个服务。每个 agent 请求都要起一个浏览器实例，如果每个实例吃 271 MiB 内存，几千个并发就是几百 GB。换成 Kitesurf 每个实例 57 MiB，同样的硬件能塞下多好几倍的任务。这笔账对做平台的人很值。
对我这种端上用的人来说，好处不在省内存，在少维护。我那套 playwright 链路最烦的不是慢，是三天两头出幺蛾子。Chromium 版本升了跟 playwright 不兼容，某个站改了反爬策略突然全 403，jina.ai 偶尔限流返回空内容。这些碎事每个都不大，积起来就是隔几天得停下正经活去修水管。
Kitesurf 跑在 Cloudflare 的云上，版本更新、安全补丁、资源回收这些维护活我不用管。代价是我得把抓取的活交出去，网络请求多走一跳。
那堵墙两边都翻不过
写到这里本来该说结论了，但有一条限制我读到的时候停住了。
Kitesurf 官方文档里写着：无法绕过使用 TLS 指纹协商的反爬机制。
这条我太熟了。我那条流水线被 403 卡着的站，十有八九就是这套机制在挡。说白了，网站那头看你的 TLS 握手指纹，发现不像正常浏览器，直接把门关上。我挂 jina.ai 当 fallback 就是因为这个，它走的是服务器端渲染，TLS 指纹跟正经浏览器一样，能绕过一部分。
Kitesurf 绕不过。因为它的 TLS 握手走的是 Workers 的网络栈，指纹跟 Chromium 不一样，网站一验就知道你不是人。
说实话，我原来以为 403 是个技术问题，换个更好的工具就能解决。现在看，不管你用 Chromium headless、用 Kitesurf、还是用我那套双通道，403 这堵墙的根子不在技术够不够强，在网站那头压根不想让 agent 来。
技术能做的是伪装得更像人。但伪装这条路有天花板：你改了 TLS 指纹，它查 JS 运行时特征；你补了 JS 环境，它上行为分析。猫鼠游戏没有终点。
真正让 agent 堂堂正正进门的路，在另一头。我之前写 GEO 那篇提过 WebMCP，网站主动把自己的功能暴露给 agent，不用模拟点击也不用偷渡。Kitesurf 也好、我那套 playwright 也好，都是在网站不配合的前提下想办法。什么时候网站愿意主动给 agent 开门，这两条路才算走到头。
我接下来怎么接它
诚实交代：Kitesurf 我还没实际接过。上面全是读完官方博客之后，拿我那条跑了大半年的老路子对照出来的判断。
短期我不会换。我那套 playwright 加 jina 的双通道跑着还行，虽然三天两头修水管，但产出稳定。Kitesurf 还在 beta，说了计划开源但没给时间表，我等它开源之后再接一下试。
真正让我动心的是 CDP 兼容。我现在 playwright 的脚本理论上不用改，换个 endpoint 就能跑。你知道吗，迁移成本低这件事，对我这种已经跑了大半年的链路来说，诱惑很大。
还有一件事我想试。Kitesurf 无状态、用完即毁的设计，跟我流水线里「每次抓取都是独立任务、不需要保持登录」的用法对上了。我那个 content-researcher 干的就是一次性的活：抓一个页面、提取正文、扔回来，不需要登录、不需要保持 cookie、不需要跨页面跳转。这种用法确实不需要背一个完整 Chromium。
给你一个今天就能做的判断。想想你让 agent 抓网页时，最头疼的到底是什么。如果是 Chromium 太重、内存炸了、维护烦，Kitesurf 这条路值得盯。如果跟我一样，最疼的是 403 和反爬，那换哪个浏览器都一样，因为那堵墙不在你这头。
你的 agent 抓网页时最常被什么卡住？是 Chromium 太重撑爆内存，还是被网站一个 403 怼回来？评论区聊聊你的绕法。