Skills、MCP、SubAgents：谁负责「连线」，谁负责「干活」，谁负责「懂业务」？

星浩AI
0 阅读11分钟

面对 Skills、MCP、多智能体这些概念，很多人的第一反应是：它们到底有什么区别？什么时候该用哪个？

一、导读

上一篇文章我们聊了「为什么需要 Skills」——大模型很聪明，但缺流程、缺行规、缺经验沉淀。Skills 就是给 Agent 的「专业手册」，让它在特定场景下按你的方式做事。

但现实中的企业架构往往更复杂：你不仅要让 Agent「懂业务」（Skills），还要让它「能连外部系统」（MCP），甚至要处理「多个 Agent 怎么分工协作」。

这篇文章要回答的核心问题是：
Skills、MCP、多智能体分别解决什么问题？边界在哪里？面对一个新项目，你该怎么选、怎么组合？

二、一张图看懂：谁负责什么？

先看一张对比图，把三个概念的核心职责说清楚：

2-comparison-table.png

  • MCP 负责「连线」：把 Agent 和外部世界（数据库、API、文件系统）连起来，提供统一的工具接口。典型场景： 连接数据库、API、文件系统、第三方服务。
  • Skills 负责「懂业务」：把「这个任务应该怎么做、注意什么、输出什么格式」写成可复用的手册。典型场景： 写报告、做审查、配图、合规检查
  • 多智能体负责「组织分工」：当任务太复杂、需要多个「智能体」协作时，决定谁做什么、什么时候做、怎么交接。典型场景： 多阶段任务、多角色协作、大规模并发。

这三者不是「三选一」的关系，而是可以组合使用的。接下来，我们先从最底层、最“工程基础”的 MCP 讲起，再向上看 Skills 和多智能体。

三、MCP：统一工具总线，负责「连线」

3-mcp-architecture.png

3.1 MCP 是什么？

MCP（Model Context Protocol） 是 Anthropic 提出的一个开放协议，用于标准化 Agent 与外部系统（数据库、API、文件系统等）的连接方式。

MCP 的核心价值是统一接口：

  • 以前：每个 Agent 框架都要自己实现「怎么连数据库」「怎么调 API」「怎么读文件」，代码重复、标准不一。
  • 现在：MCP 定义了一套标准协议，任何符合 MCP 的 Server 都可以被任何支持 MCP 的 Agent 调用。

3.2 MCP 解决什么问题？

MCP 主要解决工具接入 层面的问题：

  1. 统一连接方式：不用为每个外部系统写一套连接代码，用 MCP Server 统一封装。
  2. 标准化接口：所有工具都遵循同一套协议，Agent 调用方式一致。
  3. 可复用性：一个 MCP Server 写好，可以被多个 Agent、多个项目复用。

3.3 典型 MCP Server 示例

MCP Server 类型功能典型场景
文件系统 MCP读写本地/远程文件代码仓库操作、文档管理
数据库 MCP连接数据库并执行查询业务数据查询、报表生成
API MCP封装第三方 API调用外部服务（如 GitHub、Slack）
向量数据库 MCP检索向量数据RAG、知识库查询

3.4 MCP 的边界

MCP 只负责「连线」，不负责：

  • ❌ 不负责「业务流程」：MCP 告诉你「怎么调数据库 API」，但不告诉你「写报告应该先查什么、再查什么」。
  • ❌ 不负责「业务约束」：MCP 告诉你「怎么读文件」，但不告诉你「报告格式应该长什么样、哪些话不能说」。

业务流程和约束，是 Skills 的职责。 换句话说，MCP 解决的是「接上什么工具」的问题，而不是「具体应该怎么干活」。

四、Skills：业务手册库，负责「懂业务」

4.1 Skills 解决什么问题？

Skills 解决**「业务流程/经验/约束」**层面的问题：

  1. 流程标准化：把「这个任务应该怎么做」写成可复用的 SOP。
  2. 经验沉淀：把「这个领域/团队的行规、模板、示例」打包成 Skill。
  3. 约束与合规：把「不能做什么、必须做什么」写进 Skill，让 Agent 自动遵守。

4.2 Skills 与 MCP 的关系

4-skills-mcp-relationship.png

Skills 可以站在 MCP 之上，表达业务流程。

举个例子：写一份企业报告。

  • MCP 层：提供「怎么连数据库」「怎么读文件」「怎么调 API」的工具接口。
  • Skills 层：提供「写报告应该先查什么数据、再套什么模板、最后怎么校验」的业务流程。

在这个例子中：

  • MCP 负责「连线」：提供数据库连接、文件读取的工具接口。
  • Skills 负责「懂业务」：告诉 Agent「写报告应该先做什么、再做什么、注意什么」。

4.3 Skills 的边界

Skills 只负责「业务流程」，不负责：

  • ❌ 不负责「工具接入」：Skills 不直接连数据库、不直接调 API，而是通过 MCP 调用工具。
  • ❌ 不负责「多 Agent 分工」：一个 Skill 通常只教一个 Agent「怎么做」，不涉及「多个 Agent 怎么协作」。

简单记：MCP 解决“接什么工具”，Skills 解决“按什么流程做事”；至于“谁来做、如何分工”，要交给多智能体去负责。

五、多智能体：组织分工层，负责「谁来做、怎么分工」

5-multi-agent-modes.png

5.1 多智能体的四种模式（LangGraph 视角）

当任务过于复杂、单一智能体难以胜任时，就需要引入多智能体架构——即多个具有独立角色、工具甚至记忆的 Agent 协同工作。在 LangGraph 中，常见的多智能体协作模式有以下四种：

💡 提示：如果你想看这些模式在代码中如何实现，可参考前面的 LangGraph 系列：

  • 第 5 讲：Routing（路由与分支）
  • 第 8 讲：Multi-Agent（Orchestrator-Worker、多 Agent 编排）

1. Orchestrator-Worker（编排-工作者）

定义：一个主智能体（Orchestrator）负责任务分解与协调，将子任务分派给多个专门的 Worker Agent 执行。

典型场景：

  • 代码审查：Orchestrator 拆解任务 → Worker A 检查安全性 → Worker B 分析性能 → Worker C 审查代码风格
  • 文档生成：Orchestrator 规划结构 → Worker A 撰写摘要 → Worker B 编写正文 → Worker C 生成配图建议

特点：

  • Orchestrator 负责「规划、调度、汇总」，Worker 负责「专注执行」
  • 适合任务可明确拆分、子任务相对独立的场景
  • 对应 LangGraph 第 8 讲的 Supervisor-Worker 模式

2. Router → Specialist（路由分发）

定义：一个 Router Agent 根据用户请求的内容或意图，动态决定将任务路由给哪个 Specialist Agent。

典型场景：

  • 客服系统：Router 识别问题类型 → 路由至「技术专家」「财务专员」或「产品顾问」
  • 跨领域问答：Router 判断查询属于「金融」「医疗」或「法律」→ 转发给对应领域的 Specialist

特点：

  • Router 只做「决策」，不执行具体任务；Specialist 专注「垂直领域」
  • 适合多知识域、高并发请求的场景
  • 对应 LangGraph 第 5 讲的 Conditional Routing 模式

3. Handoff（任务交接）

定义：一个 Agent 在完成当前阶段后，将任务完整或部分地「交接」给另一个 Agent 继续处理。

典型场景：

  • 客服升级：一线客服 Agent 判断需技术支持 → Handoff 给「技术专家 Agent」
  • 审批流程：初审 Agent 完成评估 → Handoff 给「法务 Agent」进行合规审查

特点：

  • 任务具有天然的阶段性，不同阶段由不同角色负责
  • 支持人机协作（如 Handoff 给 human）
  • 在 LangGraph 中通过状态变更和条件边实现任务流转

4. Collaborative Agents（协作式多智能体）

定义：多个 Specialist Agent 平等参与任务，通过轮流发言、辩论或共识机制共同推进目标，无中央控制器。

典型场景：

  • 专家会诊：医疗、法律、财务三个 Agent 共同评估一个商业合同风险
  • 创意协作：文案、设计、营销 Agent 联合策划一场产品发布会

特点：

  • 强调多视角协同而非单向分工
  • 适合高可靠性、需多角度分析的任务
  • 可基于 LangGraph 实现自定义的 GroupChat 或 Speaker Selection 逻辑

5.2 多智能体的边界

多智能体只负责「组织分工」，不负责：

  • ❌ 不负责「工具接入」：多智能体架构中的每个 Agent 仍然通过 MCP 连接外部系统。
  • ❌ 不负责「业务流程」：每个 Agent 仍然通过 Skills 学习「怎么做」，多智能体只是决定「谁来做」。

前文已经多次强调：工具接入交给 MCP，业务流程交给 Skills，多智能体只管“谁在什么时候做哪一段”。

六、决策思路：什么时候用哪个？

6.1 决策流程图

6-decision-flowchart.png

6.2 具体决策场景

场景 1：只有一个 Agent，但任务类型多样

问题：Agent 需要处理「写报告」「配图」「代码审查」等多种任务，每种任务都有固定的流程和规范。

决策：

  • ✅ 优先上 Skills：为每种任务类型写一个 Skill，Agent 根据任务自动加载对应的 Skill。
  • ✅ 如果需要连接外部系统：引入 MCP，统一工具接入。
  • ❌ 不需要多智能体：一个 Agent + 多个 Skills 就够了。

架构示例：

7-scenario-1-single-agent.png

场景 2：业务天然是多阶段、多角色

问题：一个完整的业务流程需要「初审 → 复审 → 法务审核 → 最终审批」，每个阶段由不同角色负责。

决策：

  • ✅ 考虑 Handoffs：每个阶段由一个专门的 Agent 处理，完成后 Handoff 给下一个 Agent。
  • ✅ 每个 Agent 仍然用 Skills：每个阶段的 Agent 都有自己的 Skill（如 initial-review、legal-review）。
  • ✅ 工具接入用 MCP：所有 Agent 共享同一套 MCP Servers。

架构示例：

8-scenario-2-handoffs.png

场景 3：多知识域 + 大规模请求

问题：客服系统需要处理「技术问题」「财务问题」「产品问题」等多种类型的请求，每天有大量并发。

决策：

  • ✅ 考虑 Routers：Router Agent 根据请求类型，路由到对应的 Specialist Agent。
  • ✅ 每个 Specialist 用 Skills：技术 Specialist 用 technical-support Skill，财务 Specialist 用 financial-support Skill。
  • ✅ 工具接入用 MCP：所有 Agent 共享同一套 MCP Servers。

架构示例：

9-scenario-3-routers.png

场景 4：任务可以明确拆分、子任务相对独立

问题：代码审查需要同时检查「安全性」「性能」「代码风格」，每个检查项相对独立。

决策：

  • ✅ 考虑 SubAgents：主 Agent 拆任务 → 创建三个 SubAgent 并行处理。
  • ✅ 每个 SubAgent 用 Skills：Security SubAgent 用 security-review Skill，Performance SubAgent 用 performance-review Skill。
  • ✅ 工具接入用 MCP：所有 Agent 共享同一套 MCP Servers。

架构示例：

10-scenario-4-subagents.png

6.3 组合使用：MCP + Skills + 多智能体

在实际项目中，这三者往往是组合使用的：你不会只选一个，而是按「底层→中层→上层」的顺序逐步叠加。

11-enterprise-architecture.png

关键原则：

  1. MCP 作为「统一工具总线」：所有 Agent 都通过 MCP 连接外部系统，避免重复实现。
  2. Skills 作为「业务手册库」：每个 Agent 根据自己的任务类型，加载对应的 Skills。
  3. 多智能体作为「组织分工层」：当任务太复杂时，用多智能体架构决定「谁做什么、什么时候做」。

七、常见误区

12-misconceptions-comparison.png

误区 1：把 MCP 和 Skills 混为一谈

错误理解：MCP 和 Skills 都是「教 Agent 怎么做」，有什么区别？

正确理解：

  • MCP：负责「工具接入」，告诉你「怎么连数据库、怎么调 API」。
  • Skills：负责「业务流程」，告诉你「写报告应该先做什么、再做什么、注意什么」。

类比：

  • MCP = 「工具箱的使用说明书」（怎么用锤子、怎么用螺丝刀）
  • Skills = 「装修房子的操作手册」（应该先做什么、再做什么、注意什么）

误区 2：认为多智能体可以替代 Skills

错误理解：既然可以用多个 Agent 分工，为什么还需要 Skills？

正确理解：

  • 多智能体：决定「谁做什么、什么时候做」。
  • Skills：决定「怎么做、注意什么」。

两者是互补的：多智能体架构中的每个 Agent 仍然需要 Skills 来学习「怎么做」。

类比：

  • 多智能体 = 「团队分工」（谁负责什么）
  • Skills = 「每个员工的操作手册」（具体怎么做）

误区 3：一开始就上多智能体

错误理解：为了「架构先进」，一开始就设计多智能体架构。

正确理解：

  • 优先上 Skills：如果只有一个 Agent + 多个任务类型，先用 Skills 解决。
  • 需要时再上多智能体：只有当任务确实需要多个 Agent 协作时，才考虑多智能体。

原则：从简单到复杂，从单 Agent + Skills 开始，需要时再引入多智能体。

八、小结

MCP 负责「连线」，Skills 负责「懂业务」，多智能体负责「组织分工」。三者可以组合使用，但各有边界。面对新项目时，优先从「单 Agent + Skills + MCP」开始，需要时再引入多智能体。

决策路径：

  1. 只有一个 Agent + 一堆工具？ → 优先上 Skills
  2. 业务天然是多阶段、多角色？ → 考虑 Handoffs
  3. 多知识域 + 大规模请求？ → 考虑 Routers
  4. 任务可以明确拆分、子任务相对独立？ → 考虑 SubAgents

参考资源：

  • MCP 官方文档：https://modelcontextprotocol.io
  • Agent Skills 官方标准站点：https://agentskills.io
  • Anthropic 官方工程文章（Agent Skills 实战理念）：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
avatar
文章
阅读
粉丝