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
---
始终为组件的根元素添加 data-testid 属性

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 自主发现和调用，多了层"智能性"。所以我个人的倾向是——新东西优先用 Skills，Commands 留给那些不需要 Agent 动脑子的简单快捷指令。

Sub-Agents：独立上下文的专业角色

Sub-Agents 是独立的 AI 实例，有自己的上下文窗口、提示词、工具权限、模型配置。主 Agent 可以把子任务甩给它，实现并行执行和上下文隔离。

几个点值得注意：

• 上下文隔离：子代理的对话历史跟父代理是隔开的。这个很重要——你让 Agent 去搜一大圈代码、翻一堆日志，如果都堆在主会话里，上下文很快就乱了。
• 并行：Cursor 2.0 支持最多 8 个 Agent 同时跑，用 git worktrees 避免文件冲突。
• 模型和权限可以单独配：比如搜索这种活儿用轻量模型就够了，省钱；架构决策才上高级模型。还能设 readonly 只读模式，碰敏感代码时安全。

放 .cursor/agents/<agent-name>.md，YAML 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）里自动跑，自动创建 PR

import { Agent } from "@cursor/sdk";

const agent = await Agent.create({
  apiKey: process.env.CURSOR_API_KEY!,
  model: { id: "composer-2" },
  cloud: {
    repos: [{ url: "https://github.com/my/repo" }],
    autoCreatePR: true,
  },
});

const run = await agent.send("修复登录 token 过期 bug");

到这一步，Cursor 的角色就从"IDE 里的助手"变成了"能编进基础设施的自动化组件"。对你的团队意味着什么得看具体场景，但至少这条路是通的。

怎么选？我的建议

简单粗暴排个优先级：

1. AGENTS.md —— 先把项目背景交代清楚，所有 AI 工具都能读
2. Rules —— 代码规范、技术栈约束，始终生效
3. Skills —— 复杂工作流封装成按需加载的能力包
4. Commands —— 简单快捷指令
5. Sub-Agent —— 确实需要隔离上下文、并行执行、独立权限配置时才上
6. Cursor SDK —— 要脱离 IDE 做自动化时考虑

从最简单的开始。能用 Rules 解决的别上 Skills，能用 Skills 解决的别拉 Agent。只有当任务真的需要隔离和并行的时候，Sub-Agent 才物有所值。

---

基于 Cursor 2.4+ 及 SDK 公开测试版功能，部分特性（Skills、Sub-Agents）需要 Nightly 版本。