构建一个完整的 web 浏览器引擎是软件工程领域最具挑战性的任务之一。浏览器需要正确解析 HTML 和 CSS、执行 JavaScript、管理复杂的布局计算、处理各种渲染边界情况，同时保持安全隔离和性能优化。传统上，这样的项目需要数十名工程师数年时间的协作。然而，Cursor 的 Wilson Lin 团队在 2026 年初完成了一个令人瞩目的实验：使用数百个并行运行的 AI Agent，在一周内生成了超过三百万行 Rust 代码，构建出了一个名为 FastRender 的实验性浏览器引擎。这个项目不仅展示了 AI 在系统软件开发中的潜力，更重要的是，它探索出了一套可复用的并行 Agent 协调架构 ——Planner-Worker 模式，这套模式对于任何需要大规模并行 AI 协作的场景都具有重要的参考价值。
从民主式协调到 Planner-Worker 架构的演进
在 FastRender 项目的早期阶段，团队尝试了一种看似自然的协调方式：给予每个 Agent 同等的地位，让它们通过共享文件系统进行协调。每个 Agent 可以认领任务、更新状态、在完成时释放锁。然而，这种「民主式」协调很快遇到了严重的瓶颈。当 Agent 数量增加到二十个时，系统的吞吐量反而下降到了仅相当于两到三个 Agent 的水平。大部分时间都消耗在了锁竞争、状态同步和冲突解决上，而不是实际的代码生成工作。这个失败的经验揭示了一个关键问题：在没有明确分层的情况下，并行 Agent 之间的协调开销会迅速成为系统的瓶颈，而非优势。
团队随后转向的 Planner-Worker 架构从根本上解决了这个问题。在这个新模式中，系统引入了一个专门的任务规划层 ——Planner。Planner 的职责是分析整体项目需求，将其分解为独立且粒度适当的任务单元，然后将这些任务分发给 Worker Agent 去执行。每个 Worker 专注于完成分配给自己的任务，完成后向 Planner 报告结果。这种分层设计将原本扁平的 Agent 网络转化为一个有向无环图结构，Planner 处于根节点，负责维护全局视野和任务依赖关系，而 Worker 则只需要关注局部任务的完成。这个设计在后续的实验中得到了验证：系统能够稳定地运行两千个并发 Agent，吞吐量随着 Agent 数量的增加而近似线性增长。
不可变树流水线：渲染引擎的核心抽象
FastRender 的渲染管线采用了不可变树（Immutable Tree）架构，这一设计选择在代码生成层面具有深远的影响。整个渲染过程被划分为四个完全独立的阶段：解析（Parse）、样式计算（Style）、布局（Layout）和绘制（Paint）。每个阶段消费上一阶段产生的树结构，输出新的树结构供下一阶段使用。这种设计的好处是多方面的：首先，它天然支持增量计算 —— 当 CSS 发生变化时，系统不需要重新解析 HTML，只需要从样式计算阶段开始重新执行；当用户滚动页面时，布局结果可以被缓存，只有绘制阶段需要重新执行。其次，它使得每个阶段的职责边界清晰，便于不同 Agent 独立开发和测试。
具体而言，解析阶段将 HTML 字节流转换为 DOM 树，将 CSS 字节流转换为样式表集合。样式计算阶段将 DOM 树与样式表结合，通过完整的 CSS Cascade Level 4 算法（包括层、作用域、自定义属性等特性）计算每个元素的最终样式，生成带样式的树（Styled Tree）。布局阶段将带样式的树转换为盒模型树（Box Tree），处理块级格式化上下文、行内格式化上下文、Flexbox、Grid、表格和多列布局等八种格式化上下文，最终生成片段树（Fragment Tree）。绘制阶段则根据片段树构建显示列表（Display List），按照 CSS 2.1 附录 E 定义的堆叠顺序（Stacking Order）进行光栅化，输出最终的像素数据。这种流水线设计使得每个阶段都可以独立演进，也为 AI Agent 的分工协作提供了清晰的模块边界。
多进程目标架构与当前实现状态
虽然当前的 FastRender 仍然运行在单进程模式下（渲染器在主进程的 worker 线程中执行），但项目已经定义了完整的多进程目标架构。这套架构将浏览器划分为四个主要进程：浏览器进程负责 UI、标签页管理和导航控制；网络进程处理 HTTP 协议栈、磁盘缓存和 Cookie 管理；渲染进程（运行在沙箱中）负责 HTML 解析、样式计算、布局和绘制；GPU 进程则专门处理图形加速。各进程之间通过 IPC 通道进行通信，共享内存帧缓冲区用于传输像素数据以避免复制开销。
沙箱安全是这套架构的重要组成部分。项目已经为三大桌面平台实现了操作系统级别的沙箱支持：在 Linux 上使用 seccomp-bpf 过滤系统调用，Landlock 提供可选的文件系统限制；在 macOS 上使用 Seatbelt 配置文件限制文件系统和网络访问；在 Windows 上使用 AppContainer 结合零权限配置，配合 Job Objects 限制进程资源。这些安全机制的代码已经就绪，只等待多进程架构完成集成后即可启用。从工程角度来看，这种「先设计后实现」的做法对于 AI 生成的大型项目尤为重要 —— 它确保了即使代码是分批生成的，最终系统也能满足安全和架构要求。
面向大规模并行 Agent 的工程启示
FastRender 项目为未来 AI 驱动的系统软件开发提供了几个重要的工程启示。首先，架构设计必须先于代码生成。在启动数百个 Agent 同时工作之前，团队需要明确模块边界、数据流和接口契约。Planner-Worker 模式的成功正是源于它在 Agent 协作层面提供了清晰的抽象 ——Planner 维护全局一致性，Worker 保持局部自治，两者通过结构化的任务协议进行通信。其次，不可变数据流是降低协调复杂度的有效手段。当每个阶段的输入输出都是不可变树时，Agent 之间不需要担心中间状态的竞争和污染，可以自由地并行处理各自负责的子任务。最后，渐进式目标设定比一步到位更为实际。FastRender 当前的单进程实现并不妨碍它成为一个可用的渲染引擎，同时多进程架构的设计已经为未来的演进预留了空间。
从技术参数的角度来看，这套架构可以承载的并发规模受限于几个核心配置：Planner 与 Worker 的比例通常维持在 1:20 到 1:50 之间，确保 Planner 有足够的带宽进行任务分发和状态汇总；每个任务的粒度经过精心调优，既不能太细（导致调度开销占比过高），也不能太粗（导致负载不均衡）；任务队列采用多生产者单消费者模式，Planner 持续向队列推入新任务，Worker 从队列中拉取任务执行。对于类似规模的项目，这些参数可以作为初始配置基准，再根据实际运行情况进行调整。
资料来源
本文主要参考了 FastRender 的官方 GitHub 仓库（https://github.com/wilsonzlin/fastrender）中的技术文档，以及 Simon Willison 对 Wilson Lin 的访谈记录（https://simonwillison.net/2026/Jan/23/fastrender/），这些资料详细介绍了项目的架构设计、Agent 协调模式和渲染管线实现细节。