Kitesurf：在 V8 隔离中运行的代理优先浏览器

我们应该构建自己的浏览器吗？这是多年来 Cloudflare 内部每隔几个月就会出现的问题之一。毫不奇怪，这是一种会触发长线程的类型，有多种原因和有说服力的论据来说明为什么我们应该这样做。浏览器显然是我们每天在计算机上使用的最重要的软件；它可以说是互联网的操作系统。我们是一家以帮助建立更好的互联网为使命的公司——谁不想接受构建新浏览器的挑战呢？但我们从未在这种努力的技术难度和我们要解决的独特问题之间找到平衡。于是，这个想法就被一次又一次地搁置了。到目前为止。神奇的事情发生了：我们达到了一个转折点，我们的开发者平台中的一系列强大的技术进步成为现实，而人工智能代理的出现和对新型浏览器的需求同时变得至关重要。在Workers中运行WebAssembly（Wasm）现在已经非常成熟。动态工作者、基于 SQLite 的持久对象、工作者到工作者 RPC、服务绑定、更高的 NodeJS 兼容性和更高的限制等原语为更加雄心勃勃和复杂的应用程序打开了大门，这在以前是不可能的。 Browser Run 是我们的无头浏览器自动化 API 产品，随着人工智能的兴起而取得了巨大的增长。代理需要浏览器才能执行许多任务，并且在许多情况下，没有浏览器就无法成功。但有一个问题——像 Chromium 这样的浏览器引擎是为人类而不是代理构建的，它们带来的开销是人工智能模型根本不需要的。它们消耗如此多的内存和计算量，以至于为每个代理提供自己的实例的成本极其昂贵，从而将网络的大部分限制为仅使用具有更高参数知识的最复杂、最昂贵的人工智能模型，同时锁定了许多其他代理应用程序。我们应该为所有智能体提供一个擅长处理对人工智能模型重要的内容的浏览器，即使这意味着只关注对人类有用的内容。例如：人工智能不关心选项卡、主题、浏览器扩展或跨设备同步。它关心令牌计数、上下文窗口、可扩展性、性能和成本。结构化、机器可读的内容很重要，但视觉完美、流畅的 60 fps 滚动则不重要。如果 CSS 解析稍有偏差或渲染像素不完美，代理就可以了。使用浏览器的人工智能背景下的威胁模型是不同的。快速注入和工具安全等新问题是首要任务。面对这些认识，12 周前我们再次提出了这个问题：我们应该构建自己的浏览器吗？这次大家的回答是一致的：是的！今天，我们宣布推出 Kitesurf，这是一款完全在我们专门为代理构建的 Workers 之上运行的新浏览器，在 Browser Run 的测试版中免费提供。对于屏幕截图和 HTML 提取等常见代理任务，Kitesurf 在 CPU 和内存消耗方面明显比 Chromium 更高效。接下来是我们如何构建它的故事。系好安全带，这会变得很技术性——但我们保证让它保持有趣。它是如何开始的 Kitesurf 的开始就像 Cloudflare 开始的许多其他伟大的想法一样。有人发现了一些有趣的东西，接下来你知道他们最终用一个看似不可能但非常有吸引力的想法“书呆子狙击”团队的其他成员。我们从 obscura 中获得了最初的灵感，这是一个用 Rust 编写的用于 AI 自动化的无头引擎，“没有 Chrome，没有 Node.js，没有依赖项”。然后，在人工智能代理的帮助下，我们尝试将其移植到 Workers 上。起初效果不太好。但是，一旦我们给人工智能一个可靠的计划和一个明确的成功定义——足够详细，让代理可以无休止地循环并在需要时提出问题——它就确实起作用了。我们对这个（几乎）有效的概念证明感到震惊，决定让团队做饭。设计决策 以下是我们在开始之前做出的一些设计决策。测试、测试、测试 我们知道，从原型转向成熟的浏览器（实际上对大规模生产任务有用）需要大量的工作和迭代。我们不会隐瞒使用人工智能加速这一过程的关键。但是，如何在如此复杂的项目中使用人工智能，在不损失速度的情况下控制代码和结果的质量呢？答案是提供尽可能多的测试。输入 Web 平台测试 (WPT)，这是理想的设置：一套广泛的成功标准，为 AI 代理评估功能一致性提供了明确的目标。我们策划了分配给代理的功能的选择和顺序，使人们能够专注于架构工作并审查代理的方法。然而，WPT 测试的作用仅限于此：它们衡量的是对 W3C 标准的遵守情况，而不是浏览器呈现现实世界网站并与之交互的能力。为了弥补这一差距，我们