月刷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 环节，这对代码质量保障体系提出了极高的要求。

Cursor 是一款基于 VS Code 构建的 AI 原生集成开发环境（IDE），由 Anysphere 公司开发。它不仅提供传统的代码补全功能，还深度集成了大语言模型驱动的 Agent 模式，允许 AI 在编辑器中自主执行多步骤开发任务，包括文件编辑、终端命令执行、测试运行等。Cursor 的 Agent 模式代表了 IDE 从"工具"向"协作者"演进的趋势，这也是为什么它成为讨论 AI 编程最前沿实践的核心平台。

本文基于 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 时，本质上相当于同时管理多个独立的开发工作流，每个工作流都需要独立的上下文空间和计算资源。全托管（fully autonomous）模式是 AI Agent 开发的最高形态，意味着 Agent 从接收任务到提交代码的全流程无需人类干预。这需要 Agent 具备完整的反馈闭环：不仅能生成代码，还要能运行测试、分析输出、诊断错误并自我修正。这与 DevOps 领域的"自愈系统"（self-healing system）理念一脉相承，只不过这里自愈的主体从运维基础设施扩展到了开发流程本身。

这位工程师的实践证明，规模化管理 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 能在完成代码修改后自动验证性能影响，无需人类介入采集和分析环节，这是实现全托管开发的关键能力。

在 Cursor 的 Agent 框架中，skills 是预定义的能力模块，可以教会 Agent 执行特定的操作序列，比如如何启动调试器、如何运行特定类型的测试、如何采集和解读性能数据等。Skills 的设计质量直接决定了 Agent 的自主程度——一个精心设计的 skill 包含了完整的操作步骤、预期输出判断标准和异常处理逻辑，使 Agent 能像经验丰富的开发者一样自主完成复杂的诊断流程。

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

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

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

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

硬约束与软约束的区别

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

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

这一区分的深层原因与大语言模型的工作机制有关。LLM 基于概率分布生成 token，即便是最强的模型也无法保证 100% 遵循复杂的多条件指令。当 prompt 中规则过多时，模型可能因为上下文竞争（context competition）而"遗忘"部分约束。而 linter 和 CI 是确定性程序——要么通过，要么不通过，不存在概率性遗漏。这种确定性 vs. 概率性的本质差异，是"硬约束胜过软约束"这一论断的技术根基。

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

用 Linter Rule 替代反复提醒

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

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

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

更进一步地思考，这种将软约束固化为硬约束的方法论，还可以扩展到编程语言和类型系统的选择层面。TypeScript 相比 JavaScript 的优势不仅体现在人类开发中，对 AI Agent 而言更为显著——强类型系统提供了额外的约束层，编译器会在代码生成阶段就拦截类型错误。类似地，Rust 的所有权系统能在编译期捕获内存安全问题，Haskell 的纯函数约束能防止副作用。在 Agent 时代，选择约束更强的语言和工具链，可能比精心调优 prompt 更加有效，因为它从根本上缩小了 Agent 犯错的可能空间。

打造 Agent 友好型代码库

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

Feature Map：给 Agent 一张导航地图

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

在大型项目中，代码组织往往按照技术层（如 model、view、controller）或业务域（如 auth、payment、notification）来划分，但 UI 层面的功能与代码文件之间的映射关系并不总是直观的。一个"设置页面的导出功能"可能涉及 5-6 个分散在不同目录中的文件，而这种映射关系通常只存在于资深开发者的头脑中。传统团队依赖架构文档、README 文件或团队成员的隐性知识来解决"某个功能的代码在哪里"的问题。Feature map 的创新之处在于，它专门为 AI Agent 的消费场景设计——用结构化的方式描述 UI 元素与代码位置的对应关系、快捷键绑定、功能边界等信息。这与近年来兴起的"docs-as-code"理念一脉相承，但目标受众从人类开发者扩展到了 AI Agent。当 Agent 能直接查阅 feature map 而非在整个代码库中搜索时，它的任务执行效率会有质的飞跃。

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

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

在 Agent 时代，context window 是稀缺资源，减少 Agent 的"寻路成本"，等于直接提升了它的产出效率和质量。这也解释了为什么 feature map 不仅仅是"锦上添花"，而是规模化 Agent 管理的基础设施——当你同时运行 100 个 Agent 时，每个 Agent 节省的寻路时间和 token 消耗都会被放大 100 倍。

方法论背后的管理哲学

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

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

这种类比还可以进一步延伸。在人类团队中，管理者的核心职责不是亲自完成每一项任务，而是建立流程、制定标准、消除障碍——这正是 Peter Drucker 所说的"管理的本质是激发善意和潜能"。当管理对象从人类变为 AI Agent 时，"激发潜能"的方式变成了优化 prompt 和 skills，"建立流程"变成了配置 CI/CD pipeline 和 linter rules，"消除障碍"变成了维护 feature map 和简化代码架构。管理者的价值不在于他们自己能做多少事，而在于他们能让整个系统产出多少。

他也开源了自己的一部分 skills，感兴趣的开发者可以在 GitHub 上搜索 pstack，其中包含了如 no-comments 这样的实用 skill 和一系列 principles。pstack 中的 no-comments 规则是一个典型案例——通过 linter 规则禁止代码中的注释，迫使代码本身具备自解释性（self-documenting）。这一理念源自 Robert C. Martin 在《Clean Code》中提出的观点：好的代码不需要注释来解释它在做什么，清晰的命名和简洁的结构就是最好的文档。对于 AI Agent 来说，这还有额外的好处——减少代码中的自然语言噪音，使 Agent 能更高效地理解代码的实际逻辑，避免被过时或误导性的注释干扰判断。

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

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

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

值得思考的是，这种角色转变对开发者的能力模型提出了新的要求。未来的顶级工程师可能不再以"代码量"或"技术深度"作为唯一衡量标准，而是以"系统设计能力"——即设计出能让 AI Agent 高效、可靠运作的整套基础设施的能力——作为核心竞争力。这包括制定编码规范并将其工具化、设计 Agent 友好的代码架构、构建自动化的质量保障体系，以及在人类判断和 AI 自主性之间找到最优平衡点。从这个角度看，这位 Cursor 工程师的实践不仅是技术上的突破，更是对"工程师"这一角色定义的重新书写。