Cursor 2.4 的更新日志我本来是当又一次换皮升级点开的结果发现 Subagents 和 Skills 这两个词背后的改动比我想象的大得多。我花了一周时间把一个真实项目的迭代任务从原来的单 Agent 流程迁到新架构上期间写废了三个 Skill 初稿重新编排了两次任务分工最后才跑出一套稳定的组合流程。这篇文章就是那次迁移的完整记录——Subagents 为什么要用、任务怎么拆、Skills 怎么自己写、两者怎么组合以及被问得最多的中文显示和注册问题。如果你正准备把项目切到 2.4这篇应该能帮你少走几天的弯路。1. 单 Agent 模式的瓶颈为什么 Subagents 非出不可1.1 上下文窗口爆炸让一个 Agent 什么都记住不现实以前的 Agent 模式本质上是一个 Agent 从头干到尾。给它一个需求它自己读代码、自己改文件、自己跑命令听起来很美好但实际操作里有特别明显的两个问题。第一个问题是上下文爆炸。一个中型项目少说几十个文件Agent 要完成一次跨模块改造就不得不把相关的代码、报错信息、历史对话全部塞进上下文窗口。窗口是有限的塞得越多它越容易把前面的信息忘掉于是经常出现改到第三个文件时开始违反你在第一个文件里定下的约束。这是所有用过长会话 Agent 的人都切身感受过的痛。第二个问题是单线程。一个 Agent 同一时间只能做一件事。前后端联调的时候你特别希望有人能同时去改接口、改页面、写测试但单个 Agent 只能按顺序来先改后端再改前端再补测试。每一步都要等上一步完成整个流程的时间就拖得很长。而且每次切换任务上下文都可能引入新的混乱。1.2 编排与执行分离一主多从的协作模型Cursor 2.4 的 Subagents解决的就是这两个问题。它的设计思路用一个词概括编排与执行分离。主 Agent 不再亲自下场写每一行代码而是扮演项目经理的角色负责理解需求、拆解任务、分配资源然后把具体的执行交给一个或者多个 Subagent 并行处理。我理解这套模型的时候脑子里浮现的就是一个开发小组主 Agent 是组长Subagent 是组员。组长不写具体代码但知道整体目标、需要哪些人、每个人干什么组员不用管全局只需要把自己分到的那块活干漂亮。这样的好处非常直接上下文隔离。每个 Subagent 只拿到和它任务相关的文件与说明不需要把整个项目的背景全部塞给它。它的窗口里没有噪音准确率自然更高。并行加速。多个互不依赖的任务可以同时跑整体耗时明显下降。可复用性。你可以在一次会话里多次启动同类型的 Subagent因为它的角色说明是可以沉淀的这正好和后面要讲的 Skills 接上了。当然这套模型也不是没有代价编排任务书怎么写、任务粒度怎么切、结果怎么合并这些都是新问题。我下一节就用一次真实的项目改造来演示顺便把翻车点一次性讲清楚。2. Subagents 真实项目编排拆任务、分配角色、合并结果2.1 案例背景给内部管理系统加一个数据看板模块我用来验证 Subagents 的项目是一个内部管理系统的前后端单仓后端是 Node.js TypeScript前端是 React数据库用 PostgreSQL。这次迭代的需求是新增一个数据看板模块包含三个查询接口、两个页面组件、一组数据库迁移脚本以及对应的单元测试。这个需求放在以前我会直接扔给单个 Agent 让它一条龙处理。运气好能跑通但大概率会在中段出现前面写好的接口约定被忘了后面又按自己的想法重新定义之类的错位。这次我换成了 Subagents 流程整个过程走下来效果和效率都有明显变化但过程中也踩了几个坑。2.2 主 Agent 的任务书怎么下指令最稳先说结论任务书的关键不是字数多而是把边界划清楚。一个合格的 Subagent 任务书至少要包含四样东西角色、输入、输出、约束。我给这次改造下的任务书大致长这样分析组读一遍现有路由注册和数据库迁移的目录结构梳理出看板模块应该插入的位置输出一份清单。后端组按清单实现三个查询接口输入是路由规范文档输出是代码和接口定义约束是必须复用现有的错误处理中间件。前端组基于后端组的接口定义实现两个页面组件约束是使用项目现有的组件库不做重复封装。测试组给接口补单元测试约束是测试数据用 factory不允许直接连真实数据库。注意这里的关键点每个 Subagent 的输入都被主 Agent 明确指定了尤其前端组依赖后端组的接口定义这个依赖关系必须在任务书里说清楚让前端组等后端组产出后再启动而不是一上来就猜接口。我实际操作的顺序是先起分析组拿到清单后把清单分别喂给后端组和测试组后端组完成后再把接口定义喂给前端组。这个顺序我试了好几轮是目前最稳的。2.3 并行协作里最容易翻车的三个点第一是文件冲突。两个 Subagent 同时改同一个文件结果必然有一个的改动被覆盖。我的解决办法是在任务书里明确互斥文件清单比如数据库迁移文件只有一个只允许后端组碰路由注册文件同理。第二是接口约定漂移。前端组在没有拿到最终接口定义时很容易自己假设字段名。我后来养成的习惯是宁可多等一轮也要先把接口定义固定下来再放开前端组和测试组并行。第三是验收标准不写清楚。如果你只说实现这个接口Subagent 会默认写完代码就算完成不会跑测试不会检查类型。所以我的任务书里都会加一条强制项完成后必须执行 pnpm typecheck 和对应测试把失败项列出并修复直到全绿。还要补一句并行不是越多越好。我试过同时开五个 Subagent结果编辑器和终端的负载明显上升有些任务之间还存在隐式依赖反而比串行还慢。目前我控制在两到三个并行效果最好。3. Skills 技能系统把团队规范做成 Agent 能加载的模块3.1 SKILL.md 的结构与加载触发机制Skills 是 Cursor 2.4 里和 Subagents 配套的另一块拼图。如果说 Subagent 解决的是谁来做Skills 解决的是按什么规矩做。从文件结构上看一个 Skill 就是一个目录最核心的文件是 SKILL.md。目录名就是技能名SKILL.md 的头部有 frontmatter里面写 name 和 descriptiondescription 尤其重要因为它是 Agent 判断什么时候该用这个技能的依据。正文部分就是具体的操作规范可以是步骤、代码约定、命令清单甚至内嵌小脚本。我理解这套设计的时候直接把它类比成给 Agent 预装的操作手册。以前你让 Agent 按团队规范写代码得在每轮对话里重复粘贴规范现在规范被打包成 Skill主 Agent 在拆任务时直接把对应 Skill 指派给 SubagentSubagent 展开目录、读 SKILL.md、按里面的流程执行这就把个人经验转化成了可共享、可版本管理的资产。3.2 手写一个前端组件开发 Skill 的完整步骤我自己写的第一个 Skill是给前端 Subagent 用的重点解决组件风格不统一的老毛病。步骤很简单把目录放在项目的 .cursor/skills 下结构长这样.cursor/skills/ frontend-component/ SKILL.md scripts/ check-structure.shSKILL.md 的内容大概是这样--- name: frontend-component description: 在创建新的 React 组件、重构现有组件或调整组件样式时使用。适用于页面组件和通用组件的开发任务。 --- # 前端组件开发规范 1. 创建组件前先检查 src/components 下是否已有相似组件有则复用或扩展。 2. 组件采用函数式写法使用 hooks禁止 class 组件。 3. 样式使用项目内的 css modules禁止全局 class 污染。 4. 所有对外暴露的 props 需要写 TypeScript 类型并给出默认值。 5. 组件完成后运行 npm run lint 并修复全部报错。写完后既可以在对话里直接提到技能名触发也可以像前面说的在给 Subagent 的任务书里让主 Agent 把技能指派给它。实测下来加了 Skill 之后前端组产出的代码风格比我自己口头约束稳定得多——因为它每次都会重新读一遍规范而不是靠记住。3.3 从社区安装 Skills 之前我建议你先做这三件事现在社区里已经有大量现成的 Skills 可以下载使用覆盖前端、后端、测试、文档生成等领域。但我建议在安装之前先做三件事第一审查 SKILL.md 的指令内容。Skill 本质上是带权限的指令包它会让 Agent 按你的账号去执行操作所以里面如果出现可疑指令比如让你执行来历不明的脚本一定要警惕。我见过标注为自动审计的 Skill实际内容却涉及收集环境信息这类工具只应该用于你自己授权过的项目别在正式环境随便装。第二确认 Skill 的触发描述是精确的。很多社区 Skill 的 description 写得过于宽泛比如用于所有代码任务结果它会在各种任务里被自动加载反而污染上下文。我会把 description 收窄到具体场景。第三把 Skill 纳入版本管理。我习惯把 .cursor/skills 提交进仓库和团队共享这样规范变更有迹可循比在群里发一份新的开发规范.docx靠谱得多。4. Subagents Skills 组合工作流我沉淀下来的模板4.1 场景一次涉及后端、前端、测试的全栈迭代把前面两部分拼起来就是我在 Cursor 2.4 里的完整工作流。拿一次典型的全栈迭代举例给系统加一个导出报表功能涉及后端生成文件的接口、前端下载按钮和进度提示以及一条端到端测试。我的启动方式是在主对话里下发需求并明确要求主 Agent 先拆任务。主 Agent 的产出是一张任务卡片包含三个 Subagent 的配置Subagent角色使用的 Skill约束后端组实现导出接口api-design复用现有鉴权输出接口定义前端组实现下载交互frontend-component等待接口定义样式合规测试组补端到端测试test-case覆盖成功与失败分支表格里的 Skill 都是我事先在仓库里写好的。后端组的 api-design 技能里规定了接口路径命名、错误码规范、响应体结构测试组的 test-case 技能里规定了测试文件的命名和断言风格。主 Agent 在指派任务时会把技能一并带上Subagent 启动后先读 SKILL.md 再动手。4.2 组合使用中的约定与节奏控制这套流程跑顺之后我自己总结了几条约定一是一次会话一个主任务。主 Agent 的上下文里尽量只放一个完整需求需求之间的切换通过新会话完成避免多个主任务的上下文互相干扰。二是先固定接口再放开并行。跨端任务里接口定义是天然的依赖锚点我会让主 Agent 先产出接口定义确认无误后再放前端和测试并行。三是每个 Subagent 的任务书里都带验收命令。强制要求 typecheck、lint、test 三项跑绿再回报。这样合并结果的时候冲突率会低很多。四是产出即提交。每个 Subagent 完成产出后先让它把改动提交到本地分支再让主 Agent 做合并审阅。这样即使合并时出了问题也能通过分支历史回退。这套组合流程用下来最大的感受是以前让 AI 全自动改完一个项目的那种不安全感被拆成了多个可审阅的小块。每个 Subagent 的产出范围小、规范明确、有测试兜底我只需要在合并处把把关整体质量比单 Agent 流程稳得多。5. 被问麻了的几个问题中文设置、注册、免费额度、杂牌小问题5.1 让 Cursor 稳定输出中文的方法这个话题我必须多说两句因为问的人实在太多。目前 Cursor 的界面本身没有完整的官方中文语言包网上流传的汉化大多是第三方补丁我不太建议随便装。想让 Cursor 说中文最可靠的办法是控制它的回复语言在 Rules 里加入一条Always reply in Chinese或者在每次对话开头明确说请用中文回复。如果你希望所有项目都强制中文输出就写在全局配置的 Rules 里这样每个新会话都会自动生效不用每轮重复交代。5.2 手机号注册和免费额度的实际情况关于注册Cursor 支持国际手机号注册国内手机号可以正常接收验证码填写的时候记得选对国家区号。如果遇到输入时自动打括号之类的干扰直接切到英文输入法输入再切回中文这通常是输入法导致的不是注册接口的问题。关于免费额度免费账户每月有固定次数的 AI 请求额度额度用完后会自动降级或提示等待具体数值以客户端内的用量面板为准。如果你发现额度消耗得特别快大概率是低效会话太多——在同一个超长对话里反复追问上下文会越滚越大每次请求消耗都更高。建议用完即开新会话反而省额度。5.3 响应慢、工具面板布局这类小毛病的处理思路响应慢和Taking longer than expected几乎是高频问题。我排查的顺序是先看是不是单个会话上下文太长太长就先开新会话再看是不是高峰期换个时段或换一个模型再试最后看是否有异常插件加载禁用掉再对比。绝大多数情况下前两步就能解决。至于搜索等工具都在顶部怎么移回左边这类界面布局问题我一般是去 View 菜单或主题配置里找布局选项如果找不到直接重置布局看看。这些小问题不影响核心功能折腾之前建议先看一眼更新日志有时是版本临时调整下一个版本就改回来了。6. 用了一周之后的个人体会最后说点主观的东西。这一周用下来我对 Cursor 2.4 的 Subagents 和 Skills 的评价是前者解决的是AI 能不能同时干多件事的问题后者解决的是AI 能不能按你的规矩干每一件事的问题。单独用其中一个效果提升有限组合起来才是这次版本更新的完全体。我个人的体会是不要急着把旧流程一次性全换掉。最稳的上手路径是先给项目写上两三个高频的 Skill从组件规范、接口设计、测试要求这些你最在意的地方开始然后找一个中等规模的需求用主 Agent 拆一次任务开两个 Subagent 并行跑一轮确认顺畅之后再逐步扩大范围。这个过程不用太久但能帮你把踩坑成本控制住。还有一个小技巧可以分享我在写 SKILL.md 的时候会刻意在 description 里加上在 X 情况下使用这类限定词而不是只写处理前端任务。描述越精确Agent 越不会在无关任务里误加载技能上下文也会更干净。下一步我计划做两件事一是把仓库里的 Skill 整理成更适合团队共享的结构让新成员接手项目时可以直接沿用二是尝试把文档生成类任务也交给带独立 Skill 的 Subagent让接口文档和代码保持同步。如果你也在用 Subagents 和 Skills欢迎把你的协作约定告诉我这种玩法值得互相借鉴。