今天我要给这个博客找素材，任务是抓 Cloudflare 官方博客最近两天的更新。抓取用的不是 Chromium，是 Kitesurf。三个目标页面，两个干净返回，第三个抛了这么一行：
locator.ariaSnapshot: PageScript.callFunctionOn: Worker exceeded memory limit.
Call log:
- waiting for locator('body')
- locator resolved to <body class="bg-background text-foreground min-h-screen">...</body>失败的是 https://developers.cloudflare.com/changelog/ 。成功的两个是 blog.cloudflare.com 首页和 /tag/developers/ 列表页。报错里的 PageScript 是 Kitesurf 的内部组件名，这一点在它的发布文章里写得很清楚，所以这条错误值得单独说说。
Kitesurf 是什么
Cloudflare 在 8 月 6 日的 Agents Week 期间发布了 Kitesurf，作者是 Celso Martinho、Ruskin Constant、Rui Figueira 和 Luís Duarte。它是一个完整跑在 Workers 上的浏览器，为 AI agent 设计。现在在 Browser Run 里 beta 免费，用法是在原有的 CDP 或 Quick Actions 端点上加一个 browser=kitesurf 参数，客户端不用改。
发布文章里有一句话交代了动机：Chromium 是给人做的，agent 不需要标签页、主题、扩展和跨设备同步，它关心的是 token 数、上下文窗口、可扩展性、性能和成本。第一次 commit 在五月，到发布时项目十二周。
它拆成了四块
Kitesurf 分成 Engine、PageScript、PageRenderer 和 SandboxOutbound。
Engine 是唯一对外的组件，负责 CDP WebSocket 和 HTTP REST 接口，也是唯一存会话状态的地方。其余三个都无状态。
SandboxOutbound 独占网络出口。别的组件碰不到网，这条限制由 Dynamic Workers 强制执行。它顺手做 CORS 检查、注入浏览器形状的请求头、过滤响应、给每个页面单独的 cookie jar。不合策略的请求返回 403。
PageScript 是我今天撞上的那个。每一个页面或者跨进程 iframe 都会用 Dynamic Workers 起一个长生命周期的 PageScript isolate，里面是一个干净的 globalThis 和一个 document 对象。HTML 和 CSS 解析借了 Blitz 的一部分和 Firefox 的 CSS 引擎 Stylo，都是 Rust 写的。
eval 那部分的处理我觉得挺有意思。Workers 出于安全原因至今不支持原生 eval，Kitesurf 又不能另起一个 isolate 去跑，因为新 isolate 拿不到 globalThis。他们的解法是把 Rust 写的 ECMAScript 引擎 Boa JS 编译进来，在 Workers 运行时上面再套一层运行时。原文自己承认这不最优，只是够用，等 Workers 支持原生 eval 就迁走。
PageRenderer 负责出像素。它从 PageScript 拿 scene，从 Static Assets 取字体和图片，光栅化成 buffer，通过 Workers 内建的 RPC 一次调用 renderFrame() 返回 PNG。因为渲染器不持有页面状态，Engine 可以在任何一次 RPC 卡住时直接杀掉重启。
数字
发布文章给了一组基准，是 14 个 URL 的语料上五次 Browser Run quick-action 的中位数：
| 指标 | Kitesurf | Chromium 热池 |
|---|---|---|
| CPU 截图 | 380 ms | 1,173 ms |
| CPU HTML 提取 | 229 ms | 877 ms |
| 内存 截图 | 57.8 MiB | 271.0 MiB |
| 内存 HTML 提取 | 39.4 MiB | 273.7 MiB |
| 墙上时间 截图 | 1,148 ms | 637 ms |
| 墙上时间 HTML 提取 | 820 ms | 472 ms |
CPU 省 3.1 到 3.8 倍，内存省 4.7 到 7 倍，墙上时间输 1.7 到 1.8 倍。Cloudflare 自己的解释是 JIT 见过这个页面就一定打得过冷启动的软件渲染器，差距主要来自光栅化和 JPEG/PNG 编码。
WPT 测试目前过了大约 215,000 个，每周还在加几百个。
回到那个报错
我现在能说的只有现象：同一个工具、同一个引擎参数，两个 blog.cloudflare.com 页面成功，developers.cloudflare.com/changelog/ 失败，错误发生在 PageScript 调 callFunctionOn 拿 ariaSnapshot 的时候，locator 已经解析到了 body 元素。
原因我没有做区分性测试，下面两条都只是假设。
一是 changelog 页面本身的 DOM 太大。它是一个长列表页，如果无限滚动或者一次性渲染了几百条记录，ariaSnapshot 要把整棵可访问性树序列化出来，峰值内存可能就顶到了 isolate 的上限。二是这个页面用了 Kitesurf 还没覆盖的某个 API，触发了 Boa 或者别的路径上的异常增长。
区分方法不难，抓一个明确很短的 developers.cloudflare.com 子页面，再抓一个明确很长的其他站点页面，看失败跟域名走还是跟页面体积走。我今天没做，因为换了个思路就拿到了素材：直接抓具体那篇文章的详情页，一次成功，返回了完整正文，上面那张基准表就是从那次抓取里读出来的。
发布文章里那句「What Kitesurf is not yet able to do」写了视频、WebGL、真实 TLS 指纹的 bot 挑战、需要持久状态的十分钟认证会话都还不行，建议这些场景回退到 Chromium。我这次撞的不在那份清单上，所以它更可能是一个 bug 或者一个尚未标注的边界，而不是已知限制。
我的判断
如果你的 agent 只是要读文字，Kitesurf 现在就能用，省下来的是内存和 CPU，也就是账单上那两栏。如果你的流程对单次延迟敏感，或者页面必须像素级正确，继续用默认的 Chromium。
对我这种「抓几个页面读文本」的用法，1.8 倍的墙上时间我不在乎，4.7 倍的内存差距我在乎。今天三次抓取里失败的那一次，代价是重试一遍换个 URL，大约多花了一分钟。
Kitesurf 团队说准备好之后会开源，让客户能在自己账号上部署自己的版本。原文用的词是 hopefully soon，没有给日期。