Cursor 疯狂实验：用 GPT-5.2 花了一个星期在 Cursor 中开发了一个300万行代码的浏览器以及Claude Opus与GPT-5.2、GPT-5.2-Codex模型在Vibe Coding方面有什么差异

在当下的开发圈子里，“Vibe Coding”（氛围编程？中文似乎还没有统一翻译）这个词正变得越来越火。以 Claude Code 为首的工具展现出了惊人的能力，让很多开发者体验到了前所未有的流畅感——你只需要描述意图，代码似乎就自然而然地“流淌”了出来。

然而，这种快感背后也隐藏着巨大的认知模糊区。大多数人其实并不清楚这些 AI Agent 的实际能力边界在哪里。比如，OpenAI 的 Codex 和 Anthropic 的 Claude 在处理复杂工程时到底有什么本质区别？它们是只能写写脚本和简单的 CRUD，还是真的能承载从零构建大型系统的重任？

就在大家还在争论 AI 编程上限的时候，Cursor 团队发布了一份非常值得大家关注的内部测试报告，展示了当我们将 Agent 的规模和运行时间推向极致时，会发生什么。这不仅仅是简单的代码生成，而是让 AI 像人类团队一样协作，构建百万行级别的项目。这项实验为我们揭示了 AI 在编码领域的潜力与局限，值得每位开发者关注。

Cursor 的一次“极限编程”实验：让 AI 连续跑一周做一个浏览器

Cursor 的团队构建了一个实验：让集成了 GPT-5.2 的 Agent 在 Cursor 平台上连续运行 近一周（7 天不间断），目标是从零开始构建一个 Web 浏览器。这个浏览器不是简单的演示，而是真正从头实现很多功能，包括：

• 自研渲染引擎（Rust）
• HTML 解析
• CSS 级联和布局
• 文本排版
• 绘制与渲染
• 自定义 JavaScript 虚拟机

最终，这个 AI 编写的浏览器代码库规模达到了 300 万+ 行代码，覆盖数千个文件。尽管现在它离 WebKit 或 Chromium 这样的成熟引擎还有很大差距，但简单网页已经可以快速且大致正确地渲染，这已超出很多人的预期。

下图就是他们的浏览器渲染的一个网页截图：

这种规模的连续长跑，对于一般的自动化代码生成工具来说几乎是不可想象的。它不仅证明了大模型在逻辑一致性、长期规划和跨模块协作上的潜力，还展示了在“真实且庞大工程项目”尝试中可能的成果。

这个实验的源代码已开源在 GitHub 上（https://github.com/wilsonzlin/fastrender ）。

其实不要看我们平时浏览器似乎很简单，但是从零开始搞是极其困难的，即使对于经验丰富的专业团队来说，也需要数月时间。但在这里，AI Agent通过数百个并发的子Agent，同时在同一个分支上推送代码，却几乎没有冲突。新加入的Agent也能快速理解整个代码库，继续推进工作。这证明了 AI 在处理大规模代码库时的鲁棒性。这种规模的连续长跑，对于一般的自动化代码生成工具来说几乎是不可想象的。它不仅证明了大模型在逻辑一致性、长期规划和跨模块协作上的潜力，还展示了在“真实且庞大工程项目”尝试中可能的成果。

Curosr其它实验：从代码迁移到产品优化

除了浏览器，Cursor 团队还进行了很多其他的长时运行的Agent实验，展示了 AI Agent的扩展性：

• Solid 到 React 的就地迁移：在 Cursor 代码库中进行，这个过程持续超过 3 周，涉及 +266K/-193K 的代码编辑。初步测试后，他们相信这些变更可以合并。这展示了 AI 在重构大型现有项目时的潜力。
• 产品改进：一个长期运行的Agent将视频渲染速度提升了 25 倍，使用高效的 Rust 版本实现。同时添加了对平滑缩放和平移的支持，包括自然的弹簧过渡和跟随光标的运动模糊。这些代码已被合并，即将上线生产环境。
• 其他正在进行的项目：
• Java LSP：7.4K 次提交，550K 行代码（https://github.com/wilson-anysphere/indonesia ）。
• Windows 7 模拟器：14.6K 次提交，1.2M 行代码（https://github.com/wilsonzlin/aero ）。
• Excel 实现：12K 次提交，1.6M 行代码（https://github.com/wilson-anysphere/formula ）。

这些实验总共处理了数万亿个 token，展示了 AI 代理在不同领域的适用性，从语言服务器到操作系统模拟，再到办公软件。总之一句话就是AI Agent几乎在代码领域开源做到相当多的工作了，可以大幅提高很多人的效率。按照这个趋势发展，代替初中级的程序员应该不是很远了~

Cursor实验中的经验分析

Curosr做的这些实验其实也不是一帆风顺，中间经历过许多曲折，我们这里总结一下Curosr实验中得到的一些结论。这些结论对于我们做Agent应用和开发来说是非常值得关注的。

1. 完全自治的扁平化代理结构会导致长时间任务空转：首先就是Curosr发现完全平等的Agent架构问题比较大。早期实验中，如果让所有Agent完全平等、没有明确分工，它们很容易陷入低效循环——倾向于做小改动、回避高风险任务、重复劳动，甚至整个系统停滞。典型例子是 20 个Agent并行运行，但是实际产出只相当于 2-3 个Agent在跑，因为大家都在“安全玩”。另外，早期用锁定机制来协调任务（类似抢锁避免冲突），反而制造了更大瓶颈：Agent经常卡在等待状态，系统脆弱，一有崩溃就全盘受影响。后来切换到乐观并发控制（允许冲突但失败时重试）才改善，但仍需定期重启Agent来对抗“隧道视野”（就是说只看着自己眼前一小块）和上下文漂移——代理跑太久就会忘记大局，陷入局部死循环。

2. 不同模型擅长不同角色，GPT-5.2与Opus 4.5各有优势：不是越“专业”的模型就越好，长期自主任务更看重持久力和稳定性。GPT-5.2 在这方面脱颖而出，尤其适合规划者角色：它能严格遵循指令、长时间保持焦点、不轻易漂移、精确实现细节。相比之下，Opus 4.5 经常过早收工或找捷径（比如简化任务逃避难度），不适合需要持久推进的项目；GPT-5.1-codex 虽然编码能力强，但在大局规划和长期协调上不如 GPT-5.2 可靠——它更容易偏离轨道或产生不一致的决策。实验证明，角色错配会直接拖累整个系统：用错模型，代理要么进度慢，要么输出质量低。

3. 好的 AI Agent 协作系统结构可能比想象中要简单：很多人以为多 Agent 系统必须层层机制、复杂协调才能跑起来，但 Cursor 发现恰恰相反——越复杂的结构往往越容易出问题。比如早期引入“整合者”（Integrator）角色，负责审查和合并工作者提交的代码（类似人类代码审查），本意是提升质量、减少冲突，结果却成了单点瓶颈：所有人都得排队等它，进度大幅下降。后来干脆去掉这个角色，让工作者直接提交合并，发现代理们自己就能处理好冲突，系统反而更流畅、鲁棒。Cursor 官方评价：“它制造的瓶颈多于解决的问题”。类似地，他们还尝试借鉴分布式计算（微服务架构）和人类组织模型来设计 Agent 系统，结果这些方法对 AI 不适用——AI Agent不像可靠进程或人类，会随机崩溃、漂移或输出无效变更，导致复杂结构整体更脆弱。最终结论：结构不能太松散（会冲突、漂移），也不能太繁杂（增加单点故障），简约的管道式分工（规划者 → 工作者 → 评判者）加上精准提示调优，往往是最稳健的方案。

这些经验基本覆盖了实验中的所有关键坑：从协调机制的演变、模型选型，到做减法的设计哲学。核心洞见是，多 Agent 系统成功的关键不在于“堆机制”，而在于针对 AI 的特性做精准简化和匹配。

Cursor 实验中总结出的多 Agent 协作设计

前面已经说了Cursor在构建这个多Agent协作系统中的很多问题和经验。简单来说就是过少的结构会导致重复和空转，过于复杂的结构则系统比较脆弱。最终我们可以看到几百个agent协作其实只有三种不同的角色。这其中关键点是角色分离，形成管道式结构：

• 规划者（Planners）：探索代码库，创建任务，并生成子规划者，实现并行和递归规划。
• 工作者（Workers）：专注于完成分配的任务，无需考虑大局，只需“磨”到完成并推送变更。
• 评判代理（Judge Agent）：在每个周期结束时评估进展，决定是否继续，重启迭代以保持新鲜度。

模型选择也很重要：GPT-5.2 被选为长期自主工作的首选，因为它在遵循指令、保持焦点、避免漂移和精确实现方面表现更好。不同角色分配不同模型，例如 GPT-5.2 作为规划者优于 GPT-5.1-codex，尽管后者专攻编码。Opus 4.5 则容易过早停止或走捷径。

提示工程强调简约：许多改进来自去除复杂性，比如取消整合者角色以避免瓶颈。整个系统优先简单性、角色特定模型和有效提示，而不是添加更多机制。

结论与展望

Cursor 的实验回答了一个核心问题：当前的大模型Agent在做复杂的软件工程、长时间运行会不会有问题，未来能不能搞定？看这些实验其实就容易理解，尽管很多人质疑当前的大模型不太可能替换专业程序员，特别是大型复杂软件系统根本搞不定。但是实际测试发现，这些大模型发展是非常迅速的。除了大模型本身水平在快速发展外，Agent整个系统设计也很重要。很多人说大模型应用的核心竞争力在基座模型上。这其实不太准确，基座模型固然重要，但是对于复杂的系统，如何设计才能让Agent协同工作也是非常考验工程经验的。

Curosr原文：https://cursor.com/blog/scaling-agents