我们应该自己构建一个浏览器吗？这是在 Cloudflare 内部每隔几个月就会出现的问题，已经持续了很多年。不出所料，这是一个会引发长篇讨论的问题，提出多个理由和有说服力的论点，为什么我们应该这样做。显然，浏览器是我们每天在计算机上使用的最重要的软件；可以说它是互联网的操作系统。我们是一家致力于帮助构建更好互联网的公司——谁不想迎接构建新浏览器的挑战呢？但是，我们从未找到技术难度与通过此举解决独特问题之间的平衡。因此，这个想法一次又一次被搁置。直到现在。发生了一些神奇的事情：我们达到了一个临界点，我们的开发平台中一系列强大的技术进步成为现实，同时人工智能代理的出现和对新型浏览器的需求也变得至关重要。在 Workers 中运行 WebAssembly（Wasm）现在已经非常成熟。像动态 Workers、基于 SQLite 的持久对象、Worker 到 Worker 的 RPC、服务绑定、更高的 NodeJS 兼容性和更高的限制等原语为更雄心勃勃和复杂的应用打开了大门，而这些在之前根本不可能。随着人工智能的兴起，我们的无头浏览器自动化 API 产品 Browser Run 也经历了巨大的增长。代理需要浏览器来执行许多任务，很多情况下没有它们是无法成功的。但有一个问题——像 Chromium 这样的浏览器引擎是为人类而构建的，而不是为代理，它们带来了 AI 模型根本不需要的开销。它们消耗了如此多的内存和计算资源，以至于为每个代理提供自己的实例显得昂贵得多，限制了网络的大部分资源只能被最复杂和最昂贵的 AI 模型所利用，而许多其他代理应用则被排除在外。我们应该给所有代理一个在 AI 模型中重要的浏览器，即使这意味着对人类只有用的功能轻量化。例如：人工智能不关心标签、主题、浏览器扩展或设备间同步。它关注的是令牌计数、上下文窗口、可扩展性、性能和成本。结构化的、机器可读的内容是重要的，但视觉完美和流畅的 60 帧每秒的滚动并不重要。如果 CSS 解析稍有偏差或渲染不是像素完美的，代理也会处理得很好。在使用浏览器的人工智能的威胁模型是不同的。像提示注入和工具安全等新问题是最优先的。面对这些认识，12 周前我们再次提出了这个问题：我们是否应该构建自己的浏览器？这次答案是一致的：是的！今天，我们宣布风筝冲浪，这是一个完全运行在 Workers 之上的新浏览器，我们专门为代理构建，现已在 Browser Run 的测试版中免费提供。风筝冲浪在 CPU 和内存消耗方面对于截图和 HTML 提取等常见代理任务比 Chromium 更高效。接下来是我们如何构建它的故事。准备好，因为这将变得相当技术化——但我们承诺会保持趣味性。如何开始 风筝冲浪开始于 Cloudflare 许多其他伟大想法开始的方式。有人发现了一些有趣的事情，接下来你知道他们最终“狙击”了团队的其余成员，提出了一个看似不可能但非常吸引人的想法。我们从 obscura 获取了最初的灵感，这是一种用 Rust 编写的无头引擎，用于人工智能自动化，且“没有 Chrome、没有 Node.js、没有依赖关系”。然后，在一个 AI 代理的帮助下，我们尝试将其移植到 Workers。起初结果并不理想。但是一旦我们给了 AI 一个切实的计划和明确的成功定义——详细到足以让代理无限循环并在需要时提问——它就成功了。被这个（勉强）有效的概念验证震惊，我们决定让团队继续开发。设计决策 在开始之前，我们做出了一些设计决策。测试、测试，再测试 我们知道，从原型转变为一个能够在生产中大规模实际使用的完整浏览器需要大量的工作和迭代。我们不会掩饰，利用 AI 加速这一过程至关重要。但是在这样一个复杂的项目中，如何使用 AI，同时保持代码和结果的质量不失控而又不降低进度？答案是提供尽可能多的测试。进入 Web 平台测试（WPT），理想的设置：一个广泛的成功标准套件，为 AI 代理提供了清晰的目标，以评估功能一致性。我们策划了分配给代理的功能的选择和顺序，使人类可以专注于架构工作并审查代理的方法。然而，WPT 测试仅能做到这一点：它们衡量的是对 W3C 标准的符合性，而不是浏览器渲染和与真实网站交互的能力。为了弥补这一差距，我们...