AI Agent 的三种工作模式：Skills、Projects 与 Subagents 的设计哲学

## 引言：当 AI 需要"分工协作"

在 AI Agent 从实验室走向生产环境的过程中，一个核心问题逐渐浮现：**如何让 AI 像人类团队一样，既能处理重复性工作，又能管理复杂项目，还能在必要时进行任务委派？**

Claude AI 官方最近发布的一份对比文档，揭示了他们在产品设计中的核心思考：将 AI 的工作模式拆解为三种不同的"协作范式"——**Skills（技能）、Projects（项目）与 Subagents（子代理）**。

这不是简单的功能分类，而是对"AI 如何组织工作"这一根本问题的系统性回答。它背后隐藏的设计哲学，对所有构建 AI Agent 系统的团队都有借鉴价值。

---

## 一、三种模式的本质差异：任务粒度与上下文边界

### 1.1 Skills（技能）：标准化的"肌肉记忆"

**核心定位**：通过定义标准操作流程（SOPs）自动化重复性工作。

想象一个场景：你每周都需要制作品牌风格统一的 PPT，每次都要调整字体、配色、版式。如果每次都从零开始，效率极低；但如果把这些步骤固化为"技能"，AI 就能自动执行。

Skills 的设计哲学类似于**人类的"肌肉记忆"**——当你学会骑自行车后，不需要每次都思考"先蹬左脚还是右脚"，身体会自动执行。同样，当 AI 掌握了某个 Skill，它会在识别到匹配任务时自动调用，无需用户明确指令。

**典型应用场景**：
- 制作符合品牌规范的 PPT（字体、配色、版式固定）
- 搭建稳健的 MCP 服务器（遵循最佳实践的配置流程）
- 代码审查（按照团队的 Linting 规则检查代码）
- 数据清洗（标准化的缺失值处理、异常值检测）

**关键特征**：
- **狭义聚焦**：针对具体任务的明确指导
- **自动触发**：Claude 根据任务内容自动判断是否调用
- **轻量级上下文**：仅在任务相关时加载技能指令
- **高复用性**：始终可用，适用于所有匹配任务

### 1.2 Projects（项目）：持久化的"工作空间"

**核心定位**：具备独立工作空间，包含聊天历史和知识库，适合管理复杂多面任务。

如果说 Skills 是"单次执行的动作"，那么 Projects 就是"持续演进的工作环境"。它不是为了完成某个具体任务，而是为了**管理一个长期的、多维度的目标**。

想象你在做一个季度财务分析项目：
- 需要多次对话来澄清需求
- 需要上传历史财报、行业报告等知识文档
- 需要在不同会话中保持上下文连续性
- 需要随着新数据的加入不断迭代分析

这种场景下，单次对话无法满足需求，你需要一个**持久化的工作空间**——这就是 Projects 的价值。

**典型应用场景**：
- 财务分析项目（利用最新文档和知识进行多轮分析）
- 产品设计项目（维护设计规范、用户研究、迭代记录）
- 学术研究项目（管理文献、实验数据、写作草稿）
- 客户服务项目（维护客户历史、产品文档、FAQ）

**关键特征**：
- **广泛上下文**：涵盖多会话、多文档的复杂信息
- **手动选择**：用户明确选择使用哪个项目
- **持久化存储**：聊天历史和知识库跨会话可见
- **模板化复用**：可复制为类似未来工作的模板

### 1.3 Subagents（子代理）：动态的"任务委派"

**核心定位**：自主执行子任务并管理独立上下文，避免主对话混乱。

Subagents 是三者中最"动态"的一种模式。它不是预定义的（像 Skills），也不是持久化的（像 Projects），而是**在工作流执行过程中临时创建的独立执行单元**。

想象一个复杂的数据分析任务：
1. 主代理接收任务："分析这份销售数据并撰写洞察报告"
2. 主代理判断需要两个子任务：数据分析 + 报告撰写
3. 主代理创建两个 Subagents：
   - **数据分析 Subagent**：专注于处理电子表格、生成图表
   - **写作 Subagent**：专注于将分析结果转化为商业洞察

每个 Subagent 拥有**独立的上下文**，避免了在主对话中混杂大量中间步骤。主代理只需要接收 Subagents 的最终输出，而不需要关心细节。

**典型应用场景**：
- 数据分析 + 报告撰写（分析 Subagent + 写作 Subagent）
- 多语言翻译（每种语言一个 Subagent）
- 并行任务执行（同时处理多个独立子任务）
- 复杂工作流（如 CI/CD 流程中的测试、构建、部署）

**关键特征**：
- **聚焦子任务**：工作流程内的明确分工
- **主代理调用**：由主代理决定何时创建和调用
- **独立上下文**：避免主对话的信息过载
- **临时实例**：按需创建，任务完成后可销毁

---

## 二、六个维度的深度对比：设计决策的底层逻辑

### 2.1 目的（Purpose）：解决什么问题？

| 维度 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| **核心目的** | 自动化重复性工作 | 管理复杂多面任务 | 自主执行子任务 |
| **解决的痛点** | 避免重复定义流程 | 维护长期上下文 | 隔离任务复杂度 |
| **价值主张** | 效率提升 | 知识管理 | 任务分解 |

**设计洞察**：
- Skills 的价值在于**消除重复**——一次定义，永久复用
- Projects 的价值在于**上下文连续性**——跨会话的知识积累
- Subagents 的价值在于**复杂度隔离**——让主代理专注于协调，而非执行

### 2.2 适用范围（Scope）：处理什么类型的任务？

| 维度 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| **任务粒度** | 狭义、具体 | 广泛、多维 | 聚焦、独立 |
| **时间跨度** | 单次执行 | 长期持续 | 工作流内 |
| **复杂度** | 低到中等 | 高 | 中等 |

**设计洞察**：
- Skills 适合"原子化"的任务——不可再分的最小执行单元
- Projects 适合"生态化"的任务——需要多种资源和多次迭代
- Subagents 适合"模块化"的任务——可以独立执行但需要协调

### 2.3 举例（Examples）：具体应用场景

**Skills 的典型场景**：
- **制作品牌 PPT**：固定的字体（Arial）、配色（品牌色）、版式（标题 + 3 点内容）
- **搭建 MCP 服务器**：遵循最佳实践（错误处理、日志记录、健康检查）
- **代码格式化**：按照团队规范（缩进、命名、注释）

**Projects 的典型场景**：
- **财务分析项目**：上传历史财报、行业报告，进行多轮对话分析
- **产品设计项目**：维护设计系统、用户研究、竞品分析
- **学术写作项目**：管理文献、实验数据、草稿迭代

**Subagents 的典型场景**：
- **数据分析 + 报告**：数据 Subagent 处理电子表格，写作 Subagent 撰写洞察
- **多语言翻译**：每种语言一个 Subagent，并行执行
- **CI/CD 流程**：测试 Subagent、构建 Subagent、部署 Subagent

**设计洞察**：
- Skills 的例子都是"可标准化"的——有明确的输入输出和执行步骤
- Projects 的例子都是"需要知识积累"的——依赖历史信息和多轮对话
- Subagents 的例子都是"可并行或串行"的——子任务之间有明确的依赖关系

### 2.4 调用方式（Invocation）：谁决定何时使用？

| 维度 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| **触发方式** | 自动调用 | 手动选择 | 主代理调用 |
| **决策者** | Claude（基于任务匹配） | 用户（明确选择） | 主代理（基于工作流） |
| **灵活性** | 低（自动化） | 高（用户控制） | 中（编程式） |

**设计洞察**：
- Skills 的自动调用体现了**"智能推荐"**的设计理念——AI 主动识别用户需求
- Projects 的手动选择体现了**"用户主权"**的设计理念——用户明确知道自己在哪个上下文中工作
- Subagents 的主代理调用体现了**"编程式协调"**的设计理念——通过代码逻辑控制任务分解

### 2.5 上下文管理（Context Management）：如何处理信息？

| 维度 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| **上下文范围** | 仅任务相关指令 | 跨所有项目聊天 | 独立子任务上下文 |
| **持久化** | 不持久化 | 持久化 | 临时（任务完成后可销毁） |
| **可见性** | 对用户透明 | 对用户可见 | 对主代理可见 |

**设计洞察**：
- Skills 的轻量级上下文避免了**"上下文污染"**——不会因为加载过多信息而影响性能
- Projects 的持久化上下文实现了**"知识复用"**——历史对话和文档可以在未来会话中继续使用
- Subagents 的独立上下文实现了**"关注点分离"**——主代理不需要关心子任务的执行细节

### 2.6 可复用性（Reusability）：如何在不同场景中使用？

| 维度 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| **复用方式** | 始终可用 | 模板化复制 | 按需创建 |
| **复用粒度** | 自动适用于匹配任务 | 复制为新项目 | 实例为临时 |
| **复用成本** | 零成本（自动） | 低成本（复制） | 中等成本（编程） |

**设计洞察**：
- Skills 的"始终可用"体现了**"零边际成本"**的设计理念——一次定义，无限复用
- Projects 的"模板化"体现了**"最佳实践沉淀"**的设计理念——成功的项目结构可以复制
- Subagents 的"按需创建"体现了**"动态资源分配"**的设计理念——只在需要时创建，避免资源浪费

---

## 三、设计哲学的深层启示：从功能到架构

### 3.1 任务粒度的"金字塔模型"

Claude 的三种模式实际上构成了一个**任务粒度的金字塔**：

```
        Projects（生态级）
       /                
  Subagents（模块级）    Subagents（模块级）
   /                    /      
Skills  Skills        Skills  Skills
（原子级）（原子级）  （原子级）（原子级）
```

- **底层（Skills）**：原子化的执行单元，不可再分
- **中层（Subagents）**：模块化的任务组合，可以调用多个 Skills
- **顶层（Projects）**：生态化的工作环境，可以包含多个 Subagents 和 Skills

这种分层设计的价值在于**"关注点分离"**：
- 用户只需要关心 Projects 层的目标
- 主代理负责协调 Subagents 层的任务分解
- Subagents 自动调用 Skills 层的标准化流程

### 3.2 上下文边界的"隔离原则"

三种模式在上下文管理上体现了不同的**隔离策略**：

**Skills：无状态隔离**  
每次调用都是独立的，不保留历史状态。这类似于函数式编程中的"纯函数"——相同输入总是产生相同输出。

**Projects：持久化隔离**  
不同 Projects 之间的上下文完全隔离，但同一 Project 内的所有会话共享上下文。这类似于操作系统中的"进程隔离"——每个进程有独立的内存空间。

**Subagents：临时隔离**  
Subagents 在执行期间拥有独立上下文，但任务完成后可以销毁。这类似于容器技术中的"容器隔离"——按需创建，用完即弃。

这种隔离设计的价值在于**"避免上下文污染"**：
- 如果所有任务都在同一个上下文中执行，主对话会充斥大量中间步骤
- 通过隔离，用户只看到最终结果，而不需要关心执行细节

### 3.3 调用方式的"控制权分配"

三种模式在调用方式上体现了不同的**控制权分配策略**：

**Skills：AI 控制**  
AI 自动判断何时调用，用户无需明确指令。这体现了**"智能推荐"**的设计理念——AI 主动识别用户需求。

**Projects：用户控制**  
用户明确选择使用哪个项目，AI 在项目内执行。这体现了**"用户主权"**的设计理念——用户始终掌握主导权。

**Subagents：主代理控制**  
主代理根据工作流逻辑决定何时创建和调用 Subagents。这体现了**"编程式协调"**的设计理念——通过代码逻辑控制任务分解。

这种控制权分配的价值在于**"平衡自动化与可控性"**：
- 过度自动化会让用户失去控制感
- 过度手动会降低效率
- 三种模式的组合提供了灵活的控制粒度

---

## 四、实践启示：如何在自己的系统中应用这套框架

### 4.1 识别任务类型：第一步是分类

在设计 AI Agent 系统时，首先要问自己：**这个任务属于哪种类型？**

**判断标准**：

| 问题 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| 是否重复执行？ | ✅ 是 | ❌ 否 | ❌ 否 |
| 是否需要长期上下文？ | ❌ 否 | ✅ 是 | ❌ 否 |
| 是否需要任务分解？ | ❌ 否 | ❌ 否 | ✅ 是 |
| 是否有标准流程？ | ✅ 是 | ❌ 否 | 部分是 |

**实践建议**：
- 如果任务是"每次都一样的"，考虑 Skills
- 如果任务是"需要多次对话和知识积累的"，考虑 Projects
- 如果任务是"可以分解为独立子任务的"，考虑 Subagents

### 4.2 设计 Skills：标准化是关键

**Skills 设计的三个要素**：

1. **明确的触发条件**：什么情况下应该调用这个 Skill？
   - 示例："当用户要求制作 PPT 时"
   - 实现：通过关键词匹配或意图识别

2. **标准化的执行流程**：具体步骤是什么？
   - 示例："1. 使用品牌配色；2. 应用标准版式；3. 检查字体一致性"
   - 实现：通过 Prompt 模板或代码逻辑

3. **清晰的输出格式**：最终产物是什么？
   - 示例："一个符合品牌规范的 .pptx 文件"
   - 实现：通过文件生成或 API 调用

**反模式警告**：
- ❌ 不要把复杂的、需要多轮对话的任务定义为 Skill
- ❌ 不要在 Skill 中包含需要用户决策的步骤
- ❌ 不要让 Skill 依赖外部状态（应该是无状态的）

### 4.3 设计 Projects：知识管理是核心

**Projects 设计的三个要素**：

1. **明确的项目范围**：这个项目要解决什么问题？
   - 示例："Q4 财务分析项目"
   - 实现：通过项目描述和目标定义

2. **结构化的知识库**：需要哪些文档和数据？
   - 示例："历史财报、行业报告、竞品数据"
   - 实现：通过文件上传和知识库管理

3. **持续的对话历史**：如何维护上下文连续性？
   - 示例："记录每次分析的结论和待办事项"
   - 实现：通过聊天历史和会话管理

**反模式警告**：
- ❌ 不要把一次性任务定义为 Project（应该用单次对话）
- ❌ 不要在 Project 中混杂无关的任务（应该保持主题聚焦）
- ❌ 不要忽视知识库的组织（应该有清晰的文件结构）

### 4.4 设计 Subagents：任务分解是艺术

**Subagents 设计的三个要素**：

1. **明确的子任务边界**：每个 Subagent 负责什么？
   - 示例："数据分析 Subagent 只处理数据，不撰写报告"
   - 实现：通过角色定义和职责划分

2. **清晰的输入输出接口**：Subagent 需要什么输入，产生什么输出？
   - 示例："输入：销售数据 CSV；输出：分析结果 JSON"
   - 实现：通过数据格式约定和 API 设计

3. **合理的协调机制**：主代理如何协调多个 Subagents？
   - 示例："先执行数据分析 Subagent，再将结果传递给写作 Subagent"
   - 实现：通过工作流编排和依赖管理

**反模式警告**：
- ❌ 不要创建过多的 Subagents（会增加协调成本）
- ❌ 不要让 Subagents 之间直接通信（应该通过主代理协调）
- ❌ 不要忽视错误处理（Subagent 失败时主代理应该如何应对）

### 4.5 组合使用：1 + 1 + 1 > 3

三种模式的真正威力在于**组合使用**。一个典型的复杂任务可能同时涉及三者：

**案例：自动化财务报告生成**

1. **Project 层**：创建"Q4 财务报告项目"
   - 上传历史财报、行业数据、公司战略文档
   - 维护多轮对话历史

2. **Subagents 层**：主代理创建三个 Subagents
   - **数据分析 Subagent**：处理财务数据，生成图表
   - **写作 Subagent**：撰写分析洞察和建议
   - **审核 Subagent**：检查报告的准确性和完整性

3. **Skills 层**：每个 Subagent 调用相关 Skills
   - 数据分析 Subagent 调用"数据清洗 Skill"、"图表生成 Skill"
   - 写作 Subagent 调用"商业写作 Skill"、"格式化 Skill"
   - 审核 Subagent 调用"事实核查 Skill"、"合规检查 Skill"

这种分层设计的优势：
- **用户视角**：只需要在 Project 中提出需求，无需关心执行细节
- **主代理视角**：负责协调 Subagents，无需关心具体实现
- **Subagent 视角**：专注于自己的子任务，自动调用相关 Skills
- **Skills 视角**：提供标准化的执行单元，被多个 Subagents 复用

---

## 五、未来展望：从"三种模式"到"智能编排"

### 5.1 动态模式切换

当前的三种模式是相对静态的——用户或系统需要提前决定使用哪种模式。未来可能出现**动态模式切换**：

- AI 自动判断任务类型，选择最合适的模式
- 在任务执行过程中，根据复杂度动态升级（从 Skill 到 Subagent 到 Project）
- 跨模式的无缝协作（如在 Project 中自动创建 Subagents）

### 5.2 自学习的 Skills

当前的 Skills 是预定义的，未来可能出现**自学习的 Skills**：

- AI 从用户的重复操作中自动提取 Skills
- Skills 根据执行反馈自动优化流程
- 用户可以"教"AI 新的 Skills，而不需要编程

### 5.3 协作式的 Projects

当前的 Projects 是单用户的，未来可能出现**协作式的 Projects**：

- 多个用户共享同一个 Project
- 不同用户的对话历史和知识库可以选择性共享
- AI 可以协调多个用户的任务分工

### 5.4 智能化的 Subagents

当前的 Subagents 是由主代理创建的，未来可能出现**智能化的 Subagents**：

- Subagents 可以自主决定是否需要创建更多的 Sub-subagents
- Subagents 之间可以直接通信和协商
- Subagents 可以从历史任务中学习最佳实践

---

## 结语：设计的本质是"边界"

Claude AI 的这套三模式框架，表面上是功能分类，实质上是对**"边界"**的精准定义：

- **任务边界**：什么是原子任务（Skills）、模块任务（Subagents）、生态任务（Projects）？
- **上下文边界**：什么信息应该共享、什么应该隔离？
- **控制边界**：什么由 AI 决定、什么由用户决定、什么由代码决定？

对于所有构建 AI Agent 系统的团队，这套框架提供的不是"标准答案"，而是**"思考框架"**：

- 当你设计一个新功能时，问自己：这是 Skill、Project 还 Subagent？
- 当你遇到性能问题时，问自己：是否上下文边界设计不合理？
- 当你发现用户困惑时，问自己：是否控制权分配不清晰？

**好的设计不是堆砌功能，而是划清边界**。Claude 的三种模式，正是这一设计哲学的最佳实践。

---

**核心要点总结**

| 维度 | Skills | Projects | Subagents |
|------|--------|----------|-----------|
| **本质** | 标准化流程 | 持久化工作空间 | 动态任务委派 |
| **粒度** | 原子级 | 生态级 | 模块级 |
| **触发** | 自动调用 | 手动选择 | 主代理调用 |
| **上下文** | 轻量级 | 持久化 | 独立临时 |
| **复用** | 始终可用 | 模板化 | 按需创建 |
| **适用** | 重复性任务 | 复杂多面任务 | 可分解任务 |

**设计原则**
1. **任务粒度金字塔**：Skills（原子）→ Subagents（模块）→ Projects（生态）
2. **上下文隔离策略**：无状态（Skills）、持久化（Projects）、临时（Subagents）
3. **控制权分配**：AI 控制（Skills）、用户控制（Projects）、主代理控制（Subagents）
4. **组合使用**：三种模式的协同产生 1+1+1>3 的效果

**实践建议**
- 先分类任务类型，再选择合适的模式
- 避免反模式（如把复杂任务定义为 Skill）
- 重视边界设计（任务边界、上下文边界、控制边界）
- 探索组合使用的可能性