月刷1000个PR：Cursor工程师如何同时驾驭100+Agent

近日，X 上一段关于 Cursor 首席工程师（Principal Engineer）的采访引发了开发者社区的广泛讨论。这位工程师入职 Cursor 时间不长，却已经能做到每月产出 1000 多个 PR，更令人震撼的是，他同时运行着 100 多个 Agent 以全托管的形式帮他干活——这些 Agent 甚至可以直接把代码 merge 进 main 分支。

PR（Pull Request）是现代软件开发中代码协作的核心机制，开发者完成一个功能或修复后，会创建一个 PR 请求将代码合并到主分支。通常 PR 需要经过代码审查、自动化测试通过等环节才能合并。每月 1000 多个 PR 意味着平均每个工作日产出约 50 个 PR，这在传统开发模式下几乎不可能——一个高产的人类工程师每月通常提交 20-40 个 PR。更值得注意的是，这些 Agent 可以直接 merge 进 main 分支，跳过了传统的人工 code review 环节，这对代码质量保障体系提出了极高的要求。

本文基于 B 站 UP 主对这次采访的深度解读，梳理出对 AI Native 开发真正有价值的方法论。需要先说明的是，Cursor 内部 token 无限使用这一前提，普通开发者难以复制，但从"同时驾驭 2-3 个 Agent"到"管理 100+ Agent 舰队"的思路演进，才是本次分享最具含金量的部分。

从 2 个 Agent 到 100 个 Agent 的跨越

大多数开发者在尝试并行使用 AI Agent 时，往往在管理 2-3 个时就已经力不从心。原因很简单：Agent 的质量下限很低，一旦规模扩大，人工把关就成了不可逾越的瓶颈。

这里需要理解 AI Agent 在软件开发语境中的含义：它不是简单的代码补全工具，而是具备自主决策能力的 AI 系统，拥有完整的工作循环——接收任务、分析上下文、生成方案、执行代码修改、运行验证。Cursor 的 Agent 模式允许 AI 直接在编辑器中执行终端命令、修改多个文件、运行测试套件，形成一个接近自主开发者的工作流。当并行运行多个 Agent 时，本质上相当于同时管理多个独立的开发工作流，每个工作流都需要独立的上下文空间和计算资源。

这位工程师的实践证明，规模化管理 Agent 并非靠堆砌算力，而是靠一整套系统化的方法论。核心思路可以概括为三点：建立信任、硬约束胜过软约束、让代码库对 Agent 更友好。

建立对 Agent 的信任：规模化管理的第一步

这是整个方法论中最有共鸣的一点。当你要管理几十个 Agent 时，信任就成了最大的瓶颈。

这就好比你作为老板，手下有一个不太给力的员工，你不得不时刻 micro-manage（微观管理）他。而当"员工"变成几十个时，这种事无巨细的把关会直接压垮管理者。

让 Agent 学会自查

工程师给出的关键建议是：给 Agent 配置能够自我验证质量的 skills。比如教会 Agent 如何抓取 CPU profile、memory profile，如何打开 iOS 模拟器，以及如何分析这些性能数据。

CPU profile 和 memory profile 是软件性能分析（profiling）的两大核心手段。CPU profile 记录程序在特定时间段内各函数的 CPU 占用情况，帮助识别性能瓶颈——比如某个函数意外消耗了 80% 的 CPU 时间。Memory profile 则追踪内存分配和释放的模式，用于发现内存泄漏或过度分配。传统上，这些分析需要开发者手动启动 profiling 工具（如 Chrome DevTools、Instruments、pprof 等），采集数据后进行人工解读。让 Agent 学会自主执行这些操作，意味着 Agent 能在完成代码修改后自动验证性能影响，无需人类介入采集和分析环节，这是实现全托管开发的关键能力。

核心思想是让 Agent 具备自查能力。如果做不到这一点，你就会沦为整个流程的瓶颈：不停地手动抓 profile、反复截图、把 console error 复制粘贴给 Agent。只要还需要这种人工的来回复制粘贴，你就永远无法实现真正的并行。

换句话说，Agent 的自主验证能力，决定了你能并行管理多少个 Agent。

硬约束胜过软约束：保证 Agent 代码质量的关键

第二个极具启发性的观点是：如果你希望 Agent 永远保持高质量的代码产出，就必须依靠硬约束，而不是软约束。

硬约束与软约束的区别

• 硬约束：架构设计、linter、CI、编译器（compiler）。这些是机器强制执行的规则，Agent 无法绕过。
• 软约束：当下很火的 skills、memory 以及各种 prompt。这些本质上是"建议"，Agent 可能遵守也可能不遵守。

Linter 是一种静态代码分析工具，能在代码运行前检查语法错误、风格违规和潜在缺陷，常见的包括 ESLint（JavaScript/TypeScript）、Pylint（Python）等。CI（Continuous Integration，持续集成）则是一种自动化实践，每次代码提交都会触发一系列自动化检查——编译、单元测试、集成测试、linter 检查等。二者之所以被称为"硬约束"，是因为它们在代码合并流程中设置了不可跳过的关卡：如果检查不通过，代码就无法合并。相比之下，写在 prompt 或 rules file 中的指令是"软约束"，大语言模型可能因为注意力机制的局限性而在复杂任务中忽略这些指令。将规则编码为 linter rule，本质是把自然语言的"请求"转化为确定性的程序逻辑。

工程师的判断非常犀利：如果你只靠软约束，代码烂掉只是时间问题。

用 Linter Rule 替代反复提醒

举个例子，如果你不希望 Agent 写注释（comment），最好的做法不是在 prompt 里反复叮嘱，而是写一条 linter rule 直接把 comment 全部 ban 掉。

这里还有一个非常实用的经验法则：当你发现自己在反复给 Agent 提同一个建议时，就应该考虑能否把这个建议固化为一条 linter rule 或 CI check。这样就能把靠"提醒"实现的软约束，升级为机器强制执行的硬约束。

这一思路本质上是把人的经验沉淀进工具链，从"每次都要说"变成"一次性设定、永久生效"。对于管理 100 个 Agent 的场景而言，这一点的重要性怎么强调都不为过——你不可能在 100 个 Agent 的 prompt 里都准确无误地写上同一条规则，但一条 linter rule 可以一劳永逸地覆盖所有 Agent 的产出。

打造 Agent 友好型代码库

第三个观点关注的是代码库本身的组织方式。工程师建议主动把代码库改造得更加 agent-friendly。

Feature Map：给 Agent 一张导航地图

他的具体做法是，在 Cursor 的代码库里维护一份专门的 feature map。这张地图相当于一份导航，告诉 Agent 某个具体的 UI 在哪里、有哪些功能、快捷键是什么。

在大型项目中，代码组织往往按照技术层（如 model、view、controller）或业务域（如 auth、payment、notification）来划分，但 UI 层面的功能与代码文件之间的映射关系并不总是直观的。传统团队通常依赖架构文档、README 文件或团队成员的隐性知识来解决"某个功能的代码在哪里"的问题。Feature map 的创新之处在于，它专门为 AI Agent 的消费场景设计——用结构化的方式描述 UI 元素与代码位置的对应关系、快捷键绑定、功能边界等信息。这与近年来兴起的"docs-as-code"理念一脉相承，但目标受众从人类开发者扩展到了 AI Agent。

有了这张地图，Agent 定位代码的速度会快很多。反之，如果用户提交一个反馈加一张截图，Agent 可能要耗费大量的 context window 去搜索对应的代码，效率极低。

Context window（上下文窗口）是大语言模型的核心技术参数，指模型在单次交互中能够处理的最大 token 数量。虽然当前主流模型的 context window 已扩展到 128K 甚至 200K tokens，但在实际的代码库场景中，一个中等规模项目的代码量可能轻松超过数百万 tokens。当 Agent 需要理解一个 bug 报告并定位到对应代码时，它需要在有限的窗口中加载相关文件、依赖关系、类型定义等信息。每多加载一份无关文件，就会挤占用于推理和生成的空间，增加"噪音"。因此，context window 中噪音越少，模型的输出质量越高。

在 Agent 时代，context window 是稀缺资源，减少 Agent 的"寻路成本"，等于直接提升了它的产出效率和质量。

方法论背后的管理哲学

你可能没注意到，这位工程师给 Agent 设置了大量的 principle（原则），而其中很多原则，正是他此前作为管理者对人类员工提出过的要求。

这揭示了一个有趣的洞察：管理 Agent 舰队与管理团队，在底层逻辑上高度相通。无论是建立信任、设立明确规则，还是降低协作的摩擦成本，人类团队管理的智慧同样适用于 AI Agent 的编排。这并非巧合——大语言模型本身就是在海量人类文本上训练而来的，它对"指令""规则""原则"的理解方式，在某种程度上映射了人类对这些概念的理解。用管理学的语言来说，硬约束对应"制度管理"，软约束对应"文化管理"，而 feature map 则对应"知识管理"。最有效的团队管理从来不是三选一，而是三者协同。

他也开源了自己的一部分 skills，感兴趣的开发者可以在 GitHub 上搜索 pstack，其中包含了如 no-comments 这样的实用 skill 和一系列 principles。

总结：从执行者到 Agent 架构者的角色转变

虽然普通开发者难以复现"无限 token + 100 个 Agent"的极端配置，但这套方法论的核心——让 Agent 自查、用硬约束保底、让代码库更易被 Agent 理解——对任何想要走向 AI Native 开发的团队都极具参考价值。

从"手把手带一个 Agent"到"编排一支 Agent 舰队"，本质上是一次从"执行者"到"架构者"的角色转变。真正的杠杆，不在于你能写多少代码，而在于你能设计出多好的系统，让 Agent 替你写出可靠的代码。这一转变与软件工程历史上的多次范式跃迁异曲同工：从手写汇编到高级语言，从单体应用到微服务，从手动部署到 CI/CD，每一次跃迁的本质都是将人的知识和经验编码进系统，用更高层次的抽象来替代重复的低层操作。管理 Agent 舰队，很可能就是这条演进线上的下一个里程碑。

核心要点