Cline 中 AI 相关概念详解：Rules、Skills、Workflows、Steps、Subagents、Hooks、MCP

Posted Apr 17, 2026 Updated Apr 17, 2026

29 min read

在使用 AI 辅助开发工具（如 Cline）的过程中，我们经常会遇到各种各样的术语：规则(Rules)、技能(Skills)、工作流(Workflows)、步骤(Steps)、子代理(Subagents)、钩子(Hooks)、MCP… 这些概念各自扮演什么角色？它们之间又有什么区别和联系？本文将结合 Cline 官方文档，带你一一梳理。

整体架构概览

首先，让我们通过一张流程图来理解这些组件在 Cline 中的整体关系：

核心概念详解

1. Rules（规则）

定义：Rules 是跨会话持久化的指令集合，以 Markdown 文件形式存储，让 Cline 自动遵循你的偏好和标准。

定位：持久化的全局/项目级约束和指导

核心特点：

始终激活（除非手动关闭），每次对话都会加载
分为工作区规则（.clinerules/ 目录，提交到版本控制，团队共享）和全局规则（系统目录，个人偏好）
支持条件规则（Conditional Rules），通过 YAML frontmatter 中的 paths 配置，只有当用户操作匹配特定文件路径时才激活
工作区规则优先级高于全局规则
支持多种格式：.clinerules/、.cursorrules、.windsurfrules、AGENTS.md，兼容多工具

典型使用场景：

遵循团队编码规范（命名约定、文件组织、错误处理模式）
理解项目特定上下文（技术栈、架构决策、依赖关系）
应用一致的文档或测试要求
记住约束，如”不要修改 /legacy 目录下的文件”或”始终使用 TypeScript”

示例结构：

        
      
---
paths:
  - "src/components/**"
  - "src/hooks/**"
---

# React 组件规范

创建或修改 React 组件时：
- 使用函数式组件和 React Hooks
- 将可复用逻辑提取到自定义 React Hooks
- 保持组件单一职责
- 使用 TypeScript 编写类型定义

关键点：Rules 消耗上下文 Token，因为它们总是被加载。所以建议保持简洁，按关注点拆分文件，使用条件规则减少不必要的上下文加载。

2. Skills（技能）

定义：Skills 是针对特定任务的模块化指令集，按需加载，不使用时不消耗上下文。

定位：按需激活的模块化能力扩展

核心特点：

渐进式加载：
- 元数据（名称和描述）：启动时 always loaded，~100 tokens 每个技能
- 完整指令：技能触发时加载，保持在 5k tokens 以内
- 资源：需要时才加载
Cline 根据用户请求自动判断是否激活对应技能
每个技能是一个目录，包含 SKILL.md（必需）和可选的 docs/、templates/、scripts/
支持全局和项目级存储，同名时全局优先级更高

结构示例：

data-analysis/
├── SKILL.md          # 主指令文件
├── docs/             # 可选：附加文档
│   └── advanced.md
├── templates/        # 可选：模板文件
│   └── config.yaml
└── scripts/          # 可选：工具脚本
    └── helper.sh

SKILL.md 示例：

        
      
---
name: data-analysis
description: 分析数据文件并生成洞察。处理 CSV、Excel 或 JSON 数据文件需要探索、清洗或可视化时使用。
---

# 数据分析

分析数据文件时，遵循以下工作流：

## 1. 理解数据
- 读取文件样例了解结构
- 识别列类型和数据质量问题
- 注意缺失值或异常

## 2. 澄清问题
开始前询问用户：
- 他们在寻找什么特定洞察？
- 是否已知数据质量问题？
- 希望输出什么格式？

## 3. 执行分析
使用 pandas 进行数据处理：

```python
import pandas as pd

# 加载和探索
df = pd.read_csv("data.csv")
print(df.head())
print(df.describe())
print(df.info())

对于可视化，根据复杂度选择 matplotlib 或 seaborn。

**典型使用场景**：

- AWS CDK 部署技能
- PR 审查检查清单
- 数据库迁移
- API 客户端生成
- 数据分析

**关键点**：与 Rules 相比，Skills 是**懒加载**的，只在需要时才加载完整指令，节省上下文 Token。Skills 是实验性功能，需要在设置中开启。

---

### 3. Workflows（工作流）

**定义**：Workflows 是定义一系列步骤的 Markdown 文件，用于自动化重复或复杂任务，用户通过 `/` 命令触发。

**定位**：**可复用的多步任务自动化**

**核心特点**：

- 文件名就是命令名：`release-prep.md` 通过 `/release-prep.md` 调用
- 支持自然语言步骤或精确的 XML 工具调用
- Cline 按顺序执行每个步骤，需要时暂停等待用户批准
- 可以随时停止工作流
- 支持工作区和全局存储

**可以组合使用多种表达方式**：

1. **自然语言**：让 Cline 自己决定如何做：

```markdown
## Step 1: 检查未提交的改动
查看 git 状态。如果有未提交的改动，询问用户要继续还是暂存。

## Step 2: 运行测试套件
执行所有测试。如果有失败，展示失败结果并停止。

Cline 工具调用：精确控制：

        
      
<execute_command>
  <command>npm run test</command>
  <requires_approval>false</requires_approval>
</execute_command>

CLI 工具：直接调用系统命令：

        
      
git log --author="$(git config user.name)" --since="yesterday" --oneline

MCP 工具：调用外部 MCP 服务：

        
      
<use_mcp_tool>
<server_name>github-server</server_name>
<tool_name>create_release</tool_name>
<arguments>{"tag": "v1.2.0", "name": "Release v1.2.0", "body": "Changelog content here"}</arguments>
</use_mcp_tool>

完整示例：发布准备工作流：

        
      
# 发布准备

通过运行测试、构建和更新版本信息来准备新版本。

## Step 1: 检查干净工作目录
<execute_command>
<command>git status --porcelain</command>
</execute_command>

如果有未提交的改动，询问是否继续还是先暂存。

## Step 2: 运行测试套件
<execute_command>
<command>npm run test</command>
</execute_command>

如果任何测试失败，停止工作流并报告失败。

## Step 3: 构建项目
<execute_command>
<command>npm run build</command>
</execute_command>

验证构建成功完成。

## Step 4: 询问新版本
<ask_followup_question>
<question>新版本应该是什么？</question>
<options>["Patch (x.x.X)", "Minor (x.X.0)", "Major (X.0.0)", "Custom"]</options>
</ask_followup_question>

## Step 5: 更新版本
将 package.json 中的版本更新为用户指定的新版本。

## Step 6: 生成更新日志条目
<execute_command>
<command>git log --oneline $(git describe --tags --abbrev=0)..HEAD</command>
</execute_command>

使用这些提交为新版本编写更新日志条目。

典型使用场景：

项目部署
发布准备
新项目初始化
数据库迁移
重复的代码重构任务

关键点：Workflows 将多步过程转化为单命令执行，减少记忆负担，避免遗漏步骤。你可以在完成一次复杂任务后，让 Cline 自动为你创建工作流文件：”Create a workflow for the process I just completed.”

4. Steps（步骤）

定义：Steps 是 Workflow 内部的执行单元，将一个大任务分解为有序的子任务。

定位：工作流内部的结构化分解单元

核心特点：

Steps 不是独立存在的，是 Workflows 的组成部分
按顺序执行
可以是高级描述（”运行测试套件并修复失败”），也可以是精确指令
每个步骤完成后，通常等待用户批准再继续

在 Workflow 中的示例：

        
# 发布准备

## Step 1: 检查依赖 ⬅️ 这就是一个 Step
...

## Step 2: 运行测试 ⬅️ 这就是另一个 Step
...

关键点：不要将 Steps 与其他顶层概念混淆，Steps 属于 Workflows，是工作流分解的产物。

5. Subagents（子代理）

定义：Subagents 允许主 Cline 代理生成多个专注的研究代理，并行探索代码库，保持主代理上下文干净。

定位：并行代码研究的只读代理

核心特点：

每个子代理有独立的上下文窗口和 Token 预算
并行运行，同时探索多个领域
只读权限：只能读文件、搜索代码、列目录、运行只读命令，不能修改文件
不能访问浏览器、MCP 服务器，也不能生成嵌套子代理
每个子代理返回聚焦的研究报告给主代理
需要用户明确请求才会使用（”Use subagents to…“）
默认禁用，需要在设置中开启

子代理权限表：

工具	是否可用	目的
`read_file`	✅	读取文件内容
`list_files`	✅	列出目录内容
`search_files`	✅	正则搜索
`list_code_definition_names`	✅	列出顶层定义
`execute_command`	✅	只读命令（`ls`、`grep`、`git log` 等）
`use_skill`	✅	加载技能
`write_to_file`	❌	不能修改
`use_mcp_tool`	❌	不能访问 MCP
嵌套子代理	❌	不能生成

典型使用场景：

不熟悉项目的入门：让子代理并行绘制架构、关键入口点和数据流
调查横切关注点：让不同子代理同时追踪认证、日志和错误处理
编辑前研究：修改前，使用子代理从相关文件收集上下文，避免主代理上下文被占满
大型代码库：顺序读取多个文件会消耗主代理太多上下文，子代理可以并行探索

示例请求：

我刚接触这个代码库。使用子代理梳理出主要入口点、路由层和数据访问模式。

关键点：Subagents 通过并行化加速研究，保持主上下文清洁。对于小而聚焦的任务，增加了不必要的开销，直接问主代理即可。

6. Hooks（钩子）

定义：Hooks 是在 Cline 工作流关键点运行的可执行脚本，通过验证、guardrails 和上下文注入为 AI 的非确定性带来确定性。

定位：工作流关键点的可编程扩展点

核心特点：

在特定生命周期事件自动触发
接收 JSON 输入，返回 JSON 输出
可以：
- 取消操作（cancel: true）
- 注入上下文（contextModification）
- 返回错误信息给用户
支持 8 种钩子类型，覆盖整个任务生命周期
全局和项目级钩子都运行，全局先运行，任意一个返回 cancel: true 就会停止操作

钩子类型和执行时机：

钩子类型	执行时机
`TaskStart`	开始新任务时
`TaskResume`	恢复中断任务时
`TaskCancel`	取消运行中任务时
`TaskComplete`	任务成功完成时
`PreToolUse`	Cline 执行工具之前
`PostToolUse`	工具执行完成之后
`UserPromptSubmit`	用户发送消息时
`PreCompact`	Cline 截断对话历史释放上下文之前

完整的钩子生命周期：

输入输出结构：

输入（JSON via stdin）：

        
      
{
  "taskId": "abc123",
  "hookName": "PreToolUse",
  "clineVersion": "3.17.0",
  "timestamp": "1736654400000",
  "workspaceRoots": ["/path/to/project"],
  "userId": "user_123",
  "model": {
    "provider": "openrouter",
    "slug": "anthropic/claude-sonnet-4.5"
  },
  "preToolUse": {
    "tool": "write_to_file",
    "parameters": {
      "path": "src/config.ts",
      "content": "..."
    }
  }
}

输出（JSON via stdout）：

        
      
{
  "cancel": false,
  "contextModification": "注意：此文件是自动生成的。修改可能被覆盖。",
  "errorMessage": ""
}

典型示例：TypeScript 项目强制拦截：

        
      
#!/bin/bash
# PreToolUse hook - 阻止在 TypeScript 项目中创建 .js 文件

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')

if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
  echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
  exit 0
fi

echo '{"cancel":false}'

典型使用场景：

阻止危险操作（如在 TypeScript 项目创建 .js 文件）
文件保存前运行 linter 或自定义验证
防止违反安全策略的操作
追踪每一件事用于分析或合规
在正确时机触发外部工具或服务
根据 Cline 的操作添加上下文到对话

关键点：Hooks 是真正的可编程扩展点，给了你在每个生命周期节点插入自定义逻辑的能力，可以进行验证、阻断、注入上下文。Rules 是自然语言指导，而 Hooks 是可执行代码，能够强制实施规则。

7. MCP（Model Context Protocol，模型上下文协议）

定义：MCP 是开放协议，让 AI 模型安全连接到外部工具和数据源。Cline 支持连接任何实现 MCP 协议的服务器，获得原生工具不支持的额外能力。

定位：AI 与外部世界接口的标准化协议

核心特点：

开放标准，社区贡献了许多预构建服务器
每个服务器暴露一组工具给 Cline 使用
Cline 可以连接到多个 MCP 服务器
完全本地运行：你的数据永远不会离开你的环境
可以构建自定义服务器连接到你需要的任何服务

常见 MCP 服务器示例：

服务器	能力
GitHub	创建 issue、PR、管理仓库、搜索代码
Slack	发送消息、读取对话、管理频道
PostgreSQL	运行查询、分析 schema、获取数据库信息
Brave Search	进行网络搜索获取最新信息

使用示例（在 Workflow 中调用 MCP 工具）：

        
      
<use_mcp_tool>
<server_name>github-server</server_name>
<tool_name>create_release</tool_name>
<arguments>{"tag": "v1.2.0", "name": "Release v1.2.0", "body": "Changelog content here"}</arguments>
</use_mcp_tool>

典型使用场景：

需要 AI 访问实时数据（新闻、天气、股价）
需要 AI 与外部服务交互（GitHub、Slack、Jira）
需要查询数据库获取业务洞察
需要访问内部 API 或自定义工具
集成到你自己的服务和基础设施

关键点：MCP 是协议，不是单个功能。它定义了 AI 模型和外部服务之间如何通信，让 Cline 能够安全地使用外部世界提供的能力。每个 MCP 服务器提供一组具体能力，你可以根据需要连接不同的服务器。

概念对比：区别与联系

让我们通过表格对比这些概念的关键区别：

概念	定位	激活时机	存在形式	可编程？	主要目的
Rules	持久化约束指导	每次会话加载	Markdown	❌ 自然语言	让 AI 始终遵循偏好和标准
Skills	模块化能力扩展	需要时懒加载	目录 + SKILL.md	❌ 自然语言	按需提供特定任务的指导
Workflows	多步任务自动化	用户通过 `/` 触发	Markdown 文件	⚠️ 可包含工具调用	自动化重复任务
Steps	工作流分解单元	工作流执行时	Workflow 的一部分	N/A	将大任务分解为有序子任务
Subagents	并行研究代理	用户请求时	动态生成	❌（由主代理控制）	并行探索代码，保持主上下文清洁
Hooks	生命周期扩展点	特定事件自动触发	可执行脚本（bash/PowerShell）	✅ 真正可编程	在关键点注入自定义逻辑验证、阻断
MCP	外部接口协议	需要调用外部能力时	外部服务器	✅ 通过服务器实现	标准化连接外部工具和数据源

层次关系理解

这些概念形成了一个层次化的扩展体系：

关键区别故事

想象你是一个团队技术负责人：

Rules 就像是你写的编码规范文档，每个人每次写代码都要遵守
Skills 就像是专项操作手册，只有做这个特定任务时才拿出来看
Workflows 就像是标准操作程序（SOP）文档，定义了发布、部署等重复任务一步步该怎么做
Steps 就是 SOP 里的每一步
Subagents 就像是派出多个实习生同时去不同部门收集信息，最后汇总给你
Hooks 就像是门禁保安，在每个关键点检查，阻止不符合规范的操作进入
MCP 就像是公司对外的接口标准，定义了如何和外部服务（如 GitHub、Slack）通信

何时使用什么？决策指南

当你需要…

✅ 让 AI 始终记住团队编码规范 → Rules

放在 .clinerules/ 目录，提交到仓库
利用条件规则，只对特定路径激活
保持简洁，避免占用过多上下文

✅ 当需要特定任务能力，又不想一直占用上下文 → Skills

比如数据分析、CDK 部署、数据库迁移等专门任务
只有当用户提到相关任务时才会加载完整指令
适合不常用但需要详细指导的场景

✅ 自动化重复的多步任务 → Workflows

发布准备、部署、项目初始化
完成一次复杂任务后，让 Cline 自动生成工作流：”Create a workflow for the process I just completed”
下次直接 /workflow-name 一键执行

✅ 大型代码库，需要同时从多个地方收集信息 → Subagents

新项目入门，理解整体架构
调查跨多个模块的横切关注点
保持主代理上下文不被占满

✅ 在特定执行点强制验证或阻止操作 → Hooks

阻止违反项目约定的操作（如在 TS 项目创建 JS 文件）
记录所有操作日志用于审计
在任务开始自动注入项目上下文
操作完成后触发外部流水线

✅ 需要 AI 访问外部服务或数据 → MCP

查询 GitHub API
发送消息到 Slack
数据库查询
网络搜索获取最新信息

常见组合使用

Rules + Hooks：Rules 写规范，Hooks 强制实施

Rules 说："这个项目只用 TypeScript"
Hooks 拦截：当有人要创建 .js 文件时直接阻止

Workflows + MCP：工作流自动化，需要时调用外部服务

Workflow 定义发布全过程，最后调用 MCP 在 GitHub 创建 Release

Rules + Skills：Rules 定义通用规范，Skills 提供专项指导

Rules 定义整体编码规范，Skill 提供数据分析专项流程

Subagents + 主编辑：子代理并行研究，主代理做修改

```
子代理探索相关文件，返回关键路径，主代理基于结果进行修改，不浪费上下文
```

总结

概念	一句话记住
Rules	持久化的规矩，一直带在身上
Skills	专门的手艺，用的时候再拿出来
Workflows	重复的流程，一步一步自动化
Steps	流程里的一步，分解任务
Subagents	多个人同时干活，回来汇总
Hooks	关键点站岗，不合规就拦下
MCP	对外接口标准，连接外部世界

理解这些概念的定位和区别，你就能更好地组合使用它们，构建出更加强大、可控、自动化的 AI 辅助开发流程。这些工具不是互相替代的关系，而是互补的——Rules 给方向，Hooks 做保障，Workflows 自动化重复任务，Subagents 加速研究，MCP 扩展能力边界，一起构成了完整的可扩展 AI 开发体验。

希望这篇文章能帮助你更好地理解这些术语，在实际使用中做出正确的选择。

technology

This post is licensed under CC BY 4.0 by the author.

目录

整体架构概览

核心概念详解

1. Rules（规则）

2. Skills（技能）

4. Steps（步骤）

5. Subagents（子代理）

6. Hooks（钩子）

7. MCP（Model Context Protocol，模型上下文协议）

概念对比：区别与联系

层次关系理解

关键区别故事

何时使用什么？决策指南

当你需要…

常见组合使用

总结

Trending Tags