Cursor的Agent团队实践：如何突破40%生产力瓶颈

从写代码到重构研发全生命周期

当AI编程助手的热度席卷整个软件行业时，Cursor团队却发现了一个反常识的现象：客户在部署工具初期会获得令人兴奋的效率提升，但大约一年后，这种增长就会停滞在平均40%左右的生产力提升水平，不再继续往上走。

这个数字背后藏着一个被忽视的真相。Cursor团队指出，一家公司的研发预算中，大概60%到80%都花在手工编写代码的工程师身上。如果AI真能瞬间接管这部分工作，直觉上应该带来三到四倍的效率跃升。但现实是，多数团队被卡在了40%的吞吐量天花板上。

据这次分享的核心论点，这其实是"第二阶段"——即把AI当作编码助手——的根本性极限。你可以让助手跑得越来越快，但在真正进入下一阶段之前，你的吞吐量注定会停在某个位置。

值得关注的是数据对比：从年初AI编写代码占比几乎为零，到企业级场景下攀升至15%-20%，再到更前沿的数字达到75%。而在Cursor这样激进采用AI的公司，约98%的合并提交都由AI完成。代码编写环节已经被彻底改变，但真正的瓶颈却转移到了别处。

瓶颈不在写代码，而在整个SDLC

为什么效率提升会停滞？Cursor的答案是：AI只替代了软件开发生命周期（SDLC）中极小的一部分。

一个完整的研发流程远不止写代码：规划（plan）、构建（build）、发布与验证（ship & validate）、以及复盘（retro）。工程、产品和设计团队做的事情，远比敲代码多得多。当编码这一环节被AI加速后，所有其他环节反而成了新的瓶颈。

Cursor团队提出了一个很有启发性的思考角度——不去问"AI能做什么"，而是反过来问：在这个新世界里，到底哪些步骤仍然需要人类？

在规划阶段，Agent或许已经擅长收集用户访谈反馈、做市场调研、甚至探索解决方案空间。但在投入大量资源去构建和营销之前，你仍然需要一个人来审视这份严谨的计划，确认这确实是值得投资的方向。

在构建阶段，即便几乎所有代码都由Agent编写，你依然需要一份说明架构决策和风险代码段的文档。你未必要读完两万行PR的每一节，但那些关键的一百行必须有人过目。更重要的是，在真正上线生产之前，几乎所有人都认同：需要一个署上自己名字、说"没问题，可以发布"的人类。

SDLC（Software Development Life Cycle，软件开发生命周期）是描述软件从概念到退役全过程的框架，通常涵盖需求分析、系统设计、编码实现、测试验证、部署发布和运维维护等阶段。不同组织对阶段的划分略有差异，但核心思想一致：软件交付是一条由多个环节串联而成的流水线，任何一个环节的瓶颈都会限制整体吞吐量。这与制造业中的"约束理论"（Theory of Constraints）高度吻合——系统的最大产出由最慢的那个环节决定。当AI工具将编码速度提升数倍后，瓶颈自然转移到需求评审、架构决策、测试策略和发布审批等此前被编码速度所掩盖的环节。这也解释了为何单纯引入AI编程助手的收益会在一年左右趋于饱和：编码不再是限制因素，加速它的边际收益接近于零。

用Agent团队填补新瓶颈

Cursor把这个系统抽象为三层结构：顶层是人类，负责审阅产物（artifact）并给出反馈；底层是"智能"，即模型和harness；中间则是需要搭建的Agent团队。

这里真正的难点在于：系统应该向人类输出什么。理想情况下，是高度打磨的产物——清晰呈现Agent做了什么、需要人类做哪些决策、以及所有相关的界面细节，让人能准确想象Agent的提案。同时还要有高质量的反馈回路，人类的反馈能被Agent直接采纳、修复并继续推进。

基于这个思路，Cursor搭建了多个具体的Agent，而且很多都落在核心编码环节之外，为PM、安全团队、增长团队等角色创造杠杆。

PM Agent 与 EM Agent：从一个偶然观察开始

最让人意外的是PM Agent和EM Agent的诞生。一位名叫Lauren的工程师在值班时注意到一个问题：当公司内部试用新Agent窗口（内部代号Glass）时，每天都有10到20个问题被报到Slack的"Issues Glass"频道。大家习惯性地启动云端Agent去修复——团队的内部玩笑是"我派了个人去搞定"——但这些"人"经常卡住，没能真正推进修复。

Lauren的洞察在于：问题往往出在bug报告本身不够详尽。于是她构建了两个技能（skill）——"how skill"和"why skill"，教会harness更严谨地检视代码库，获得更深入的解释。配合系统提示词，这套自动化会在收到Slack消息后主动研究代码库，几分钟内带着更多追问回到报告者面前。

有趣的是，这个"bug报告Agent"有时甚至会像在"调侃"报告人一样追问细节，而且不少问题在它查完代码库后就自行解决了——它像客服一样回答了疑问，问题随之消失。

在此之上又叠加了两个更高层的Agent：一个把所有issue分类并triage成P0、P1、P2优先级；另一个更实验性的EM Agent，会直接找到对应工程师说"有两个新的remote SSH bug进来了，你能看一下吗"。后者目前还不完美，因为团队还缺少一张"谁负责哪块代码"的精确地图，这正是他们正在教Agent的东西。

文中提到的"harness"是AI Agent系统中的一个关键工程概念，指围绕底层模型构建的执行框架与编排层。它负责管理Agent的工具调用（如读写文件、执行命令、查询API）、上下文窗口的组装与裁剪、多步骤任务的状态管理以及错误重试逻辑。可以把模型理解为"大脑"，harness则是"身体与神经系统"——决定大脑能感知什么信息、能操作什么工具、以及如何将多个动作串联成完整的工作流。"skill"（技能）则是harness中可复用的子能力模块，例如"读取代码库并生成解释"或"在Slack频道发送消息"，多个skill组合即可构成一个完整的Agent。这种分层设计使得不同Agent可以共享底层skill，降低重复建设的成本。

安全、代码审查与增长中的Agent杠杆

Agent的价值远不止于规划环节。Cursor在多个业务线都做了类似尝试。

安全Bot：修复超200个漏洞

安全团队的Travis做了一个在PR发布时触发的自动化。如果拥有无限的安全资源，你会让应用安全工程师逐个审查每个PR、花数小时查找各级别漏洞。但现实中没人有这么多安全工程师。这个Agent运行一系列提示词，去发现应用安全工程师通常会找的那类问题，至今已修复超过200个漏洞，且绝大多数是自动修复的。结果是，安全团队无需按常规速度扩张，反而能对每个PR做更彻底的检查。

低风险提交的智能检测

Cursor曾收紧代码审查政策，导致大量PR会触发多达八位审查者——哪怕只是一个微小的字符串改动，工程师们对此颇有怨言。于是团队让Agent对PR做风险评估。

他们先观察了一周，确认评估结果合理后，才让"极低风险"的PR无需人工审查直接合并。一个意外的好处是：当评估为中高风险时，Agent还能基于对代码库的深度理解，指出谁最了解这块代码，从而比传统的code owners文件路由到更合适的审查者。这套机制既放行了低风险改动，又让真正需要审查的代码得到了更严谨的把关。

增长实验的全流程自动化

增长团队只有约两名工程师，每月却要跑20到30个实验。他们的流程是：规划、启动、运行、决策、发布、清理代码。团队搭建了四个Agent：一个审计实验设置（避免指标没正确绑定），一个在Notion、Linear、StatsSig和代码之间同步文档，一个监控实验运行（避免实验跑了六天才发现指标记录错误、不得不从头重启），还有一个读取StatsSig数据并建议获胜方案。

最后的决策仍由人类拍板，但当你选定某个变体后，Agent会自动提交PR清理StatsSig中的相关代码和废弃的feature flag，让生产环境里不再堆积死分支。结果是实验吞吐量大幅提升，团队得以把精力集中在真正重要的部分——该押哪些注、怎么设计实验。

文中提到的StatsSig（即Statsig）是一个面向产品团队的实验与功能管理平台，提供A/B测试、Feature Flag（功能开关）管理和指标分析等能力。Feature Flag允许团队在不重新部署代码的情况下动态开启或关闭某个功能，是现代持续交付流程的核心基础设施。在增长实验场景中，一次实验通常对应一个Feature Flag：实验启动时开启、结束后需要在代码中删除对应的分支逻辑，否则会在代码库中积累大量"死代码"，增加维护负担和认知成本。这正是文中所说"清理代码"步骤的核心工作量——它枯燥、容易遗忘，却必须完成，因此是Agent自动化的理想切入点。

组织与文化的连锁变化

当你开始构建这个"元系统"和Agent团队时，优先级会随之改变。

Cursor正在演化团队文化。他们有一个dev X频道，是工程师抱怨开发体验问题的地方。有人提出一个有趣的质疑：为什么人类有这个频道，而云端运行的Agent却没地方"抱怨"？于是团队建了一个agent X频道，现在里面流淌着一串Agent因为做不到某事而"沮丧"的消息——团队正在尝试能否自动修复这些问题。

一旦大家开始谈论"工厂"（the factory），这种文化会产生复利效应：人人设定构建可被他人复用的技能的目标，去寻找早期的"冠军"推动者。那位搭建了PM和EM Agent的新员工Lauren，正是帮团队以更"元"的方式思考如何构建工厂的关键人物。

团队的构成也在改变。那个增长团队是两名软件工程师、一名数据科学家、一名设计师、一名PM——这是一个与过去截然不同的配比。但事实证明，当Agent能承担大量工作时，这套新比例反而是更高效的组合。

对于正在思考如何演进组织的工程负责人，这些来自一线的实践笔记，或许正是突破那道40%天花板的起点。