企业官网建设流程全解析

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 自主发现和调用，多了层"智能性"。所以我个人的倾向是——新东西优先用 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";constagent=awaitAgent.create({apiKey:process.env.CURSOR_API_KEY!,model:{id:"composer-2"},cloud:{repos:[{url:"https://github.com/my/repo"}],autoCreatePR:true,},});construn=awaitagent.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 版本。