AI Agent 的三种工作模式:Skills、Projects 与 Subagents 的设计哲学 AI 产品观察 2025-10-30 1 浏览 0 点赞 长文 ## 引言:当 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) - 重视边界设计(任务边界、上下文边界、控制边界) - 探索组合使用的可能性 Claude AI 官方账号 Anthropic Claude AI 官方 Twitter Claude 产品页面 Claude AI 的官方产品介绍 Claude 开发文档 Claude API 和功能的完整文档 Anthropic 研究 Anthropic 的 AI 安全与能力研究 #AI Agent #Anthropic #Claude AI #上下文管理 #产品架构 #工作流 #系统设计