烧掉数万亿 Token、数百 Agent 连跑一周：Cursor“从零写浏览器”，结果是拼装人类代码？

整理 | Tina 现在，大模型可以独立写完整整一个浏览器了？ Cursor CEO Michael Truell 最近分享了一项颇为吸睛的实验：他们用 GPT-5.2 让系统连续不间断运行一周，从零构建出一个“可用”的 Web 浏览器。按他的描述，产出规模达到：超过 300 万行代码、横跨数千个文件，全部通过这套 AI 驱动的编程平台生成。 数百个Agent “从零” 写了一个浏览器？ 按照他的说法，这个项目并没有依赖现成的渲染引擎，而是用 Rust 从零实现了一整套渲染引擎，其中包括 HTML 解析、CSS 级联规则、布局计算、文本排版（text shaping）、绘制（paint）流程，甚至还实现了一个自定义的 JavaScript 虚拟机。 Truell 也坦言，这个浏览器目前只是“勉强能用”，距离 WebKit 或 Chromium 等成熟引擎还有很大差距；但团队依然“感到震惊”，因为简单网站在它上面渲染得很快，而且整体效果在很大程度上是正确的。 与此同时，Cursor 还发布了一篇博客文章，题为《Scaling long-running autonomous coding》（扩展长时间运行的自主编程）。文章回顾了一系列实验：让“编程 agent 连续自主运行数周”，目标是“理解在那些通常需要人类团队耗费数月完成的项目中，agentic coding 的能力边界究竟可以被推进到什么程度”。 在这篇文章里，他们重点讲的是多 Agent 如何协同：如何在单个项目上同时运行数百个并发 Agent、如何协调它们的工作，并观察它们写出超过一百万行代码和数万亿个 token 的过程与经验。 Cursor 先承认了单个 Agent 的局限：任务规模一大、依赖一复杂，推进速度就会明显变慢。并行化看似顺理成章，但他们很快发现，难点不在并发，而在协同。 “学习如何协同：我们最初的方法是让所有 agent 具有同等地位，并通过一个共享文件自行协同。每个 agent 会检查其他 agent 在做什么、认领一个任务并更新自己的状态。为防止两个 agent 抢占同一项任务，我们使用了锁机制。 这一方案在一些有趣的方面失败了： agent 会持有锁太久，或者干脆忘记释放锁。即使锁机制正常工作，它也会成为瓶颈。二十个 agent 的速度会下降到相当于两三个 agent 的有效吞吐量，大部分时间都花在等待上。 系统非常脆弱：agent 可能在持有锁的情况下失败、尝试获取自己已经持有的锁，或者在完全没有获取锁的情况下更新协调文件。 我们尝试用乐观并发控制来替代锁。agent 可以自由读取状态，但如果自上次读取后状态已经发生变化，则写入会失败。这种方式更简单、也更健壮，但更深层的问题依然存在。 在没有层级结构的情况下，agent 变得非常规避风险。它们会回避困难任务，转而做一些小而安全的修改。没有任何一个 agent 承担起解决难题或端到端实现的责任。结果就是工作长时间在空转，却没有实质性进展。” 为了解决这一问题，Cursor 最终引入了更明确的角色分工，搭建一条职责清晰的流水线：将 Agent 分为规划者和执行者。 “规划者（Planners） 持续探索代码库并创建任务。他们可以针对特定区域派生子规划者，使规划过程本身也可以并行且递归地展开。 执行者（Workers） 领取任务并专注于把任务完成到底。他们不会与其他执行者协调，也不关心整体大局，只是全力处理自己被分配的任务，完成后再提交变更。 在每个周期结束时，会有一个评审 Agent 判断是否继续，然后下一轮迭代会从干净的初始状态重新开始。这样基本解决了我们的协同问题，并且让我们可以扩展到非常大的项目，而不会让任何单个 Agent 陷入视野过于狭窄的状态。” 在此基础上，Cursor 把这套系统指向一个更具挑战性的目标：从零构建一个浏览器。他们表示，Agent 持续运行了将近一周，在 1,000 个文件中写出了超过 100 万行代码（原文如此，跟 Michael Truell 说的 300 万行不同），并将源码发布在 GitHub 上供外界浏览。 Cursor 进一步宣称：即便代码库规模已经很大，新启动的 agent 仍然能够理解它并取得实质性进展；同时， 成百上千个 worker 并发运行，向同一个分支推送代码，而且几乎没有冲突 。 一场“全民打假”的开始？ 这次实验之所以引发强烈反应，很大程度上是因为：Web 浏览器本身就是软件工程里公认的“地狱级”项目。 它难的不只是“写代码”，而是工作量的量级、模块之间的高耦合，以及兼容性这条几乎看不到尽头的长尾。 在 Hacker News 上，有人顺手抛了一个问题：“开发一个浏览器最难的地方是什么？”很快就有人给出一个类比：“说句真心话，这个问题几乎等同于：开发一个操作系统最难的地方是什么？” 因为现代浏览器是千万级代码量的系统，能够运行非常复杂的应用。它包含网络栈、多种解析器、frame 构建与回流（reflow）模块、合成（composite）、渲染（render）与绘制（paint）组件、前端 UI 组件、可扩展框架等等。这里面每一个模块，都必须同时做到：既支持 30 年前的旧内容，也支持复杂得离谱的当代 Web 应用。同时，它还得在高性能、高安全前提下尽可能少占用系统资源，并且往往要跨 Mac、Windows、Linux、Android、iOS 等多个平台运行。 还有人提到，最难的是那张超长的任务清单。浏览器里包含多个高复杂度模块，每一个单拎出来都可能要做很久；更麻烦的是，它们之间还要通过一套相当“啰嗦”的 API 连接起来——很多接口你必须实现，至少也得先把壳子（stub）搭出来，否则系统就会崩。 Cursor 在博客中配了一段视频，并写道：“虽然这看起来像是一张简单的屏幕截图，但从头开始构建一个浏览器是非常困难的。” 然而如果外界自己去尝试编译这个项目，会很快意识到：它离“功能齐全的浏览器”还差得很远，甚至看起来在公开代码状态下，连最基本的构建都很难稳定通过。 从仓库公开信息来看，近期 main 分支的多次 GitHub Actions 运行结果显示失败（其中还包括工作流文件本身的错误）；不少开发者的独立构建尝试也报告了数十个编译错误。与此同时，最近的一些 PR 虽然被合并，但 CI 仍处于失败状态。 更有开发者表示自己回溯 Git 历史，往前翻了约 100 个提交后表示，依然没能找到一个可以“干净编译通过”的版本。 这也引出了一个问题：这些被 Cursor 描述为在代码库中长期并发运行的“agent”，在工程链路上到底做到哪一步？至少从当前公开状态看，它们似乎并没有把“能编译、能检查”当成最基础的收敛目标——因为无论是 cargo build 还是 cargo check，都会立刻暴露出成片的编译错误和大量警告。 而 Cursor 的博客文章除了提供代码仓库链接外，既没有提供可复现的演示，也没有提供任何已知的有效版本（标签 / 发布 / 提交）来验证截图。无论如何，这文章本身给人一种原型功能完备的错觉，却忽略了此类声明应有的基本可复现性特征。 有人在 Michael Truell 的 LinkedIn