FastRender：AI开发的浏览器
上周 Cursor 发布了扩展长期自主编码，这篇文章描述了他们协调大量自主编码代理的研究工作。文章中提到的一个项目是 FastRender，这是一个他们使用代理群体从零开始构建的网络浏览器。我想了解更多，所以我问 Wilson Lin（FastRender 背后的工程师）是否可以录制关于该项目的对话。这个 47 分钟的视频现在在 YouTube 上提供。我在下面包含了一些亮点。
看我之前的文章了解我自己试用 FastRender 的笔记和截图。
1、FastRender 现在能做什么
我们开始对话时，首先演示了 FastRender 加载不同的页面（03:15）。由于 JavaScript 引擎尚未工作，所以我们也加载了 github.com/wilsonzlin/fastrender、Wikipedia 和 CNN——所有这些都可用，虽然显示有点慢。
JavaScript 已被其中一个代理禁用，后者决定添加功能标志！04:02
JavaScript 目前已禁用。代理们做出了这个决定，因为他们目前仍在实现引擎并在其他部分取得进展...他们从技术上决定将其关闭或置于功能标志后。
2、从副项目到核心研究
Wilson 开始将 FastRender 作为一个个人副项目来探索 Claude Opus 4.5、GPT-5.1 和 GPT-5.2 等最新前沿模型的能力。这是从00:56开始的。
FastRender 是我从，我会说，11 月开始的我的个人项目。这是一个实验，目的是看看像 Opus 4.5 和后来的 GPT-5.1 这样的前沿模型如何处理更复杂、更困难的任务。
浏览器渲染引擎是这种理想选择，因为它既极其雄心勃勃和复杂，但也定义得非常明确。而且你可以直观地看到它的效果如何！01:57
随着实验的进展，我看到能够在该项目上真正取得良好进展的单一代理的结果。在这一点上，我想知道，嗯，下一个水平是什么？我如何进一步推动这一点？
一旦清楚地表明这是尝试多个代理共同工作的机会，它就升级为官方 Cursor 研究项目，可用资源得到了放大。
FastRender 的目标从来不是构建一个与 Chrome 等竞争的浏览器。41:52
我们从未打算让它成为生产软件或可用的，但我们希望观察这个多代理框架的行为，看看它们如何在大规模下工作。
浏览器的优点在于它的范围如此之广，它可以在这个空间中为未来许多年提供持续的实验。JavaScript，然后是 WebAssembly，再然后是 WebGPU……要处理代理面临的新挑战可能需要很多年。
3、一次运行数千个代理
关于 FastRender 最有趣的事情是该项目使用多个代理并行工作来构建浏览器的不同部分。我询问同时运行了多少个代理：05:24
在高峰期，当我们有一个系统稳定运行一周时，大约有 2,000 个代理同时运行。而且我相信他们每小时有数千次提交。
该项目有近 30,000 次提交！
你如何一次运行 2,000 个代理？他们使用了真正的大型机器。05:56
我们采用的简单基础设施方法是让大型机器运行这些多代理框架之一。每台机器都有充足的资源，每台可以并发运行约 300 个代理。这能够良好地扩展和运行，因为代理花费大量时间思考，而不仅仅是运行工具。
在这一点上，我们切换到了在其中一台大型机器上运行的框架的实时演示（06:32）。代理排列在树结构中，规划代理触发任务，然后是工作代理执行它们。07:14
这个代理集群正在致力于构建浏览器的 CSS 方面，无论是解析、选择器引擎还是这些功能。我们通过将浏览器项目分成多个指令或工作流并让每个在自己的机器上运行其中一个框架，设法进一步推动这一点，从而能够进一步并行化并增加吞吐量。
但是所有这些代理在相同的代码库上工作不会导致大量的合并冲突吗？显然不会：08:21
我们注意到大多数提交没有合并冲突。原因是框架本身能够非常有效地拆分和划分范围和任务，以便它尽量最小化工作重叠量。这也反映在代码结构中——提交会在不同时间进行，它们通常不会同时触及彼此。
这似乎是从并行代理解锁好处的一个关键技巧：如果规划代理足够好，将工作分解为不重叠的块，您可以让数百甚至数千个代理立即处理一个问题。
令人惊讶的是，Wilson 发现 GPT-5.1 和 GPT-5.2 比编码专家 GPT-5.1-Codex 更适合这项工作：17:28
一些初步发现是这里的指令比仅仅是编码更广泛。例如，如何操作和与框架内交互，或如何在无需用户交互或获得大量用户反馈的情况下自主操作。我们发现这类指令与通用模型配合得更好。
我问他们看到的该系统在无人干预下运行的最长时间是多久：18:28
所以这个系统，一旦你给出一个指令，实际上无法引导它，你不能提示它，你要去调整它的进展方式。唯一能做的就是停止它。所以我们最长的运行基本上都是自主的。我们在执行时不会改变轨迹。 [...]
所以迄今为止发布时的最长时间大约是一周，这非常接近于最长。当然，研究项目本身只有大约三周，所以你知道我们可能可以更长。
4、规范和反馈循环
该项目设计的一个有趣方面是反馈循环。为了让代理长期自主工作，它们需要尽可能多地关于他们正在解决的问题的有用上下文，并结合有效的反馈循环来帮助他们做出决策。
FastRender 仓库使用 git 子模块来包含相关规范，包括 csswg-drafts、tc39-ecma262（用于 JavaScript）、whatwg-dom、whatwg-html 等等。14:06
对系统的反馈循环非常重要。代理在非常长的时间内连续工作，如果没有护栏和反馈来知道他们做的是对还是错，可能会在长期推出中产生重大影响。规范绝对是重要的一部分——你可以在代码库中看到大量注释，AI 专门引用他们在规范子模块中找到的规范。
GPT-5.2 是视觉能力模型，FastRender 反馈循环的一部分包括获取渲染结果的截图并将这些反馈回模型：16:23
在该项目的早期演变中，当时只是进行屏幕截图的静态渲染时，这绝对是我们教它做的一件非常明确的事情。而且这些模型是视觉模型，所以它们确实有这种能力。我们有进度指标来告诉它与黄金样本进行比较。
Rust 编译器的严格性也有助于提供反馈循环：15:52
Rust 的优点是你可以仅从编译中获得大量验证，而这在其他语言中是不可用的。
5、代理们选择了依赖项
我们谈到了该项目积累的 Cargo.toml 依赖项，其中几乎所有都是代理们自己选择的。
其中一些，比如 Skia 用于 2D 图形渲染或 HarfBuzz 用于文本整形，是显而易见的选择。其他如 Taffy 感觉可能违反了项目从头开始的目标，因为该库直接实现了 CSS flexbox 和网格布局算法。这不是预期的结果。27:53
同样这些是代理选择用于引擎小部分的依赖项，可能应该实际上自己实现。我认为这反映了指令的重要性，因为我实际上从未专门编码我们应该自己实现的依赖项水平。
代理们选择了 Taffy 并对该供应商副本应用了一系列更改。31:18
它目前是供应商版本。当代理们对其工作时，他们确实会对其进行更改。这实际上是项目非常早期阶段的产物，在它成为一个成熟的浏览器之前……它正在实现诸如 flex 和网格层之类的东西，但也有其他布局方法，如 inline、block 和 table，而在我们的新实验中，我们要完全删除它。
尽管存在自实现的 ecma-rs，QuickJS 的包含也有一个有趣的起源故事：35:15
我相信它提到它引入 QuickJS 是因为它知道其他代理正在研究 JavaScript 引擎，它需要快速解除自身的阻塞。 [...]
最终，一旦它完成了，让我们删除它并替换为正确的引擎。
我喜欢这类似于大规模人类团队的动态，你可以绝对看到一个工程师对另一个团队尚未交付而感到沮丧，然后通过引入第三方库解除自己的阻塞。
6、间歇性错误实际上是可以的
这里有一些我发现真的令人惊讶的事情：代理们被允许在它们工作时在代码库中引入小错误！39:42
权衡之一是：如果你希望每一次提交都百分之百完美，确保它总是可以编译，那可能是同步瓶颈。 [...]
特别是你将系统分解为更加模块化的方面时，你可以看到引入了错误，但小错误，对吗？API 更改或某些语法错误，但随后它们在几次提交后很快得到修复。所以在系统中有一点松弛以允许这些临时错误，以便整个系统可以以真正高的吞吐量继续取得进展。 [...]
人们可能会说，嗯，那不正确的代码。但不是错误在累积。这是一个稳定的错误率。 [...] 这似乎是一个值得权衡的权衡。
如果你要拥有数千个并行代理工作，为了吞吐量而不是正确性进行优化，这是值得探索的策略。
7、2026年1月的一个工程师加上一群代理
关于 FastRender 我觉得最有趣的是它展示了单个工程师在 2026 年初在代理群体的帮助下可以实现的极端边缘。
FastRender 可能不是生产就绪的浏览器，但它代表了几万行 Rust 代码，在几周内编写，已经可以渲染真正的网页到可用的程度。
浏览器实际上是研究实验这个新的、形状奇怪的软件工程形式的理想项目。
我问 Wilson 他在浏览器渲染方面与代理协调方面投入了多少心智努力。11:34
浏览器和这个项目是共同开发的，并且非常共生，仅仅是因为浏览器对我们来说是一个非常有用的目标，用来测量和迭代框架的进度。目标是迭代和研究多代理框架——浏览器只是研究示例或目标。
FastRender 实际上是在使用完整的浏览器渲染引擎作为多代理协调的"hello world"练习！
原文链接: Wilson Lin on FastRender: a browser built by thousands of parallel agents
汇智网翻译整理，转载请标明出处