Cursor 2.0 把多代理能力放出来之后我身边不少人开始纠结一个问题Rules、Commands、Skills、Sub-Agents这些都能指挥 AI 干活到底什么时候用哪个什么时候写几条规则就够了什么时候真得拉一个独立的 Agent 出来我自己用了一阵子踩了些坑把判断逻辑理清楚了写下来给你参考。先把四个东西分清楚Rules一直在场的规矩Rules 就是全局或局部的 prompt 约束每次调用都自动塞进上下文。说白了就是硬规矩——代码风格、技术栈偏好、哪些事不能干。放.cursor/rules/下面.mdc格式。可以用globs限定只对某些文件生效比如只管*.tsx也可以设alwaysApply全局生效。一个建议别写太长。500 行以内再长就占上下文了AI 反而消化不了。--- globs: [*.tsx] alwaysApply: false --- 始终为组件的根元素添加>Skills按需加载的操作手册Skills 是程序化的操作说明书Agent 判断任务相关时自动加载。跟 Rules 最大的区别是——Rules 永远在场Skills 只在需要时才进来。这意味着 Skills 可以写得更详细不用担心占用常驻上下文。放.cursor/skills/skill-name/SKILL.md下面。触发方式两种Agent 自己判断相关性自动调或者你用/斜杠命令手动触发。适合那种需要特定领域知识的工作流——处理 PDF、生成财务模型、跑数据库查询之类的。--- name: pdf-processor description: 处理 PDF 文档的提取、合并和转换 --- 1. 使用 PyPDF2 读取源文件 2. 按用户指令执行操作 3. 输出结果到指定目录Commands手动快捷方式Commands 本质就是快捷 prompt 模板/command_name主动调。说实话Commands 和 Skills 在手动调用这个场景下功能基本重叠社区论坛也讨论过这个事。区别在于 Skills 额外支持 Agent 自主发现和调用多了层智能性。所以我个人的倾向是——新东西优先用 SkillsCommands 留给那些不需要 Agent 动脑子的简单快捷指令。Sub-Agents独立上下文的专业角色Sub-Agents 是独立的 AI 实例有自己的上下文窗口、提示词、工具权限、模型配置。主 Agent 可以把子任务甩给它实现并行执行和上下文隔离。几个点值得注意上下文隔离子代理的对话历史跟父代理是隔开的。这个很重要——你让 Agent 去搜一大圈代码、翻一堆日志如果都堆在主会话里上下文很快就乱了。并行Cursor 2.0 支持最多 8 个 Agent 同时跑用 git worktrees 避免文件冲突。模型和权限可以单独配比如搜索这种活儿用轻量模型就够了省钱架构决策才上高级模型。还能设readonly只读模式碰敏感代码时安全。放.cursor/agents/agent-name.mdYAML frontmatter 定义配置。--- name: security-auditor description: 安全审计专家用于处理认证、支付等敏感代码 model: gpt-5.5 readonly: true --- 你是一名安全专家负责审计代码中的漏洞...什么时候该拉一个 Sub-Agent 出来这部分我觉得最值得讲清楚。很多人一上来就想给每个任务都配个 Agent其实没必要。该用 Sub-Agent 的情况子任务会产生大量中间输出日志分析、大范围代码搜索你不想这些东西把主对话窗口搅乱——隔离上下文多个独立子任务能同时干比如并行搜几个模块、同时生成多个测试文件——并行执行子任务适合用轻量模型跑来省成本或者需要限制成只读模式——独立配置有那种反复要用的专业角色——代码审查员、测试编写员、安全审计员主 Agent 只管拆任务和整合结果具体执行都甩出去不该用的情况永久性的编码规范、风格约束——用 Rules始终生效且轻量偶尔用的复杂工作流比如写一份 ADR 文档——用 Skills按需加载简单快捷指令——Commands 就够了项目级基础信息技术栈、目录结构、常用命令——AGENTS.md这是所有工具都能读的项目说明书一句话别为了用而用。Sub-Agent 的核心价值是隔离和并行你的场景不需要这两个前面几个方案就够了。再进一步用 SDK 把 Agent 编程化跑如果你需要脱离 IDE 运行 Agent——比如集成到 CI/CD 管道、嵌到产品里、在云端 VM 跑——Cursor 提供了 TypeScript/Python SDK。能干啥在云端跑本地关机了任务还在跑传入自定义工具Custom Tools扩展能力边界无头环境比如 CI里自动跑自动创建 PRimport{Agent}fromcursor/sdk;constagentawaitAgent.create({apiKey:process.env.CURSOR_API_KEY!,model:{id:composer-2},cloud:{repos:[{url:https://github.com/my/repo}],autoCreatePR:true,},});construnawaitagent.send(修复登录 token 过期 bug);到这一步Cursor 的角色就从IDE 里的助手变成了能编进基础设施的自动化组件。对你的团队意味着什么得看具体场景但至少这条路是通的。怎么选我的建议简单粗暴排个优先级AGENTS.md—— 先把项目背景交代清楚所有 AI 工具都能读Rules—— 代码规范、技术栈约束始终生效Skills—— 复杂工作流封装成按需加载的能力包Commands—— 简单快捷指令Sub-Agent—— 确实需要隔离上下文、并行执行、独立权限配置时才上Cursor SDK—— 要脱离 IDE 做自动化时考虑从最简单的开始。能用 Rules 解决的别上 Skills能用 Skills 解决的别拉 Agent。只有当任务真的需要隔离和并行的时候Sub-Agent 才物有所值。基于 Cursor 2.4 及 SDK 公开测试版功能部分特性Skills、Sub-Agents需要 Nightly 版本。