AI Agent开发必懂：Skill、MCP、子Agent的区别与组合

最近很多人在群里聊 AI Agent 开发时，都会遇到一个共同的困惑：今天看文档说要给 Claude 写一个 Skill，明天看到某个项目在提 MCP Server 的配置，后天又听人说复杂任务要拆成子 Agent 去跑。这三个词听起来都跟“让模型更聪明”有关，但真到自己动手的时候，却完全不知道先做哪个、怎么做、边界在哪里。

我见过不少人一开始就把 Skill 当成 MCP 的替代品，也有人把子 Agent 理解成“更高级的 Skill”。结果就是，花了很长时间去写一个 Skill，发现根本调不到外部数据；或者辛辛苦苦搭好 MCP Server，却发现模型只是多了一个工具，并没有真正学会一套完整的做事流程。

这篇文章想把三者之间的关系彻底讲清楚。先说结论：Skill、MCP、子 Agent 不是同一个赛道上的三个选手，而是 AI Agent 系统里三个不同层级的组件。Skill 解决的是“模型会不会做这件事”，MCP 解决的是“模型能不能连到外部世界”，子 Agent 解决的是“这件事要不要拆出去单独做”。三者可以独立存在，也可以在真实项目里组合使用。搞清楚它们的定位，比你多写十个 Skill 都重要。

1. 为什么这三个概念会让你分不清

Skill、MCP、子 Agent 被混为一谈，不能全怪开发者。这几个词在传播过程中都经历过“定义漂移”：模型厂商、开源项目、技术博主各说各话，同一个词在不同文章里指的东西可能完全不一样。

1.1 混乱的根源：它们都在“让模型做事”

如果只看表面行为，三者确实很像。模型调用一个 Skill 是做事，通过 MCP 调用一个工具也是做事，把一个任务交给子 Agent 还是做事。对使用者来说，差别只是“模型多做了一步”，但在系统架构里，这三步发生在完全不同的层次。

打个比方。如果你是一家公司的老板，Skill 相当于给员工一本《标准作业手册》，告诉他“遇到这种客户应该怎么接待”。MCP 相当于给员工配了一部电话和通讯录，让他能联系到外部供应商。子 Agent 相当于你把一个项目整体分包出去，让一个小团队全权负责。这三件事都在提升公司效率，但它们是不同层面的管理动作。

1.2 各家的产品包装加剧了混乱

另一个原因是商业产品在宣传时会刻意模糊边界。某些 Agent 产品把内置流程框架命名为“Skill”，有些 MCP Server 也提供着类似工作流的“技能包”，还有一些平台把子 Agent 包装成“Skill 的一种高级形态”。这导致出现了大量类似“Agent Skill 和 MCP 有什么区别”“Skill 和 Agent 的区别”这样的搜索问题——用户的困惑是真的，而且这种困惑在每一轮新工具出来后都会重复。

1.3 一个不严谨但很实用的二分法

如果你不想深究每一家产品的实现细节，可以先建立一个粗框架：Skill 是“往里装知识”，MCP 是“往外接世界”，子 Agent 是“往旁边拆任务”。这句话不一定能覆盖所有边界情况，但能帮你在绝大多数选择场景里快速定位。后面每个概念我们都会展开讲，最后再给出真正的组合方法。

2. Skill 到底解决什么问题

Skill 是三者中最容易被误解的一个。很多人以为 Skill 就是“给模型加一个插件”，让它能调用某个 API。这种理解把 Skill 和 MCP 搅在了一起。实际上，Skill 的核心并不在“连接外部”，而在“教会模型一套做事的流程和规范”。

2.1 Skill 的本质：把做事方法固化成可复用资产

你可以把 Skill 理解成一个“打包好的专项能力包”，里面通常包含提示词文本、使用说明，有时候还会附带脚本或参考数据。它解决的核心问题是：大模型虽然拥有海量知识，但在面对一个专业任务时，不一定会“按照你想要的方式”去完成。

举一个常见场景。你希望模型帮你审查代码中的安全问题，普通对话模式下，模型会泛泛地列出几个安全风险。但如果你把团队沉淀的安全审查清单、漏洞分级标准、报告格式要求写进一个 Skill，模型就会严格按照这套规范执行：先看输入输出校验，再看权限控制，接着查敏感信息暴露，最后按固定模板输出风险等级和修复建议。

这就是 Skill 的价值——它把一次性的提示词工程，变成了可以积累、可以复用、可以团队共享的资产。从实现上看，很多 Skill 就是一个文件夹加一个 Markdown 说明文件，比如 Claude Code 中的 SKILL.md。模型在执行任务时，会根据用户指令主动读取这个文件，然后按照里面的指示行动。

2.2 Skill 和普通 Prompt 有什么不一样

Skill 本质上也是一种提示词，但和普通的用户 Prompt 有三个重要区别。

第一，Skill 是结构化的。它不是用户在某次对话里临时输入的一句话，而是提前组织好的、带固定文件结构的说明文档。它有自己的名称、描述、使用步骤和注意事项。

第二，Skill 可以包含可执行脚本。有些 Skill 不只是“读文档”，还可以挂载脚本去完成重复性操作，比如格式化代码、解析日志、生成测试数据。这让 Skill 具备了一定的自动化能力，而不仅仅是“说给模型听”。

第三，Skill 是可发现、可选择的。系统会通过 Skill 的元信息（名称、描述）来决定什么场景下应该启用它。模型不是随机调用一个 Skill，而是先判断当前任务匹配哪个 Skill，再按需加载。

2.3 新手最容易踩的两个 Skill 坑

第一个坑：把 Skill 当成万能工具库。你写了一个“文件整理 Skill”，就期望它能直接操作你磁盘上的所有文件。但 Skill 本身并不天然具备文件系统访问能力，它只是告诉模型“你应该怎么整理”，真正去读文件或移动文件，仍然需要模型具备对应的工具调用能力。这类能力在本地 CLI 工具里可能由 Agent 框架提供，但在纯 API 对话环境里并不存在。

第二个坑：把 Skill 当成 MCP 的替代方案。Skill 不能帮模型调用未接入的外部 API，也不能让模型访问一个全新的数据源。数据连接是 MCP 的职责，Skill 的职责是“用好已经能用的东西”。如果你发现模型连数据都拿不到，那不是 Skill 写得不够好，而是缺少一个 MCP Server。

3. MCP 到底解决什么问题

如果说 Skill 是“教模型怎么做”，那 MCP 就是“让模型够得到”。MCP 的全称是 Model Context Protocol，它要解决的是一个更基础也更容易被轻视的问题：如何让模型标准化地连接外部工具和数据源。

3.1 MCP 出现之前的世界

在 MCP 出现之前，模型要调用一个外部工具，每一种工具都需要单独开发一套对接方式。比如让模型查询数据库，你需要写一个 Python 函数，把 SQL 执行结果转成文本再丢给模型；让模型控制浏览器，你需要再写一套 Playwright 的封装；让模型操作设计软件，你又要用另一套 API。每个工具一套集成方案，每套方案都要自己维护认证、超时和错误处理。

这种模式下，每接入一个新工具，成本都高得离谱。而且不同的 Agent 框架对接工具的方式还不一样，给 Claude 写了一套工具调用逻辑，到了别的 Agent 平台又要重写。

3.2 MCP 的标准化思路

MCP 的提出就是为了解决这种碎片化。它定义了一套统一的协议，让 AI 应用（MCP Client）可以连接外部能力（MCP Server）。Server 通过标准接口暴露自己的工具和资源，Client 负责发现这些工具，并让模型在合适的时机调用它们。

可以这样理解：MCP 之于 AI Agent，就像 USB-C 接口之于电子设备。没有 USB-C 之前，每个设备都要专属线缆；有了统一标准之后，一个接口能通用于显示器、硬盘、手机。MCP 做的是同样的事情，它让“模型具备某种外部能力”这件事从“定制开发”变成了“标准接入”。

在实际工程里，你经常会听到“MCP Server”这个词。一个 MCP Server 通常运行在独立进程中，通过 JSON-RPC 与 Client 通信。它内部可以封装任意逻辑：调用 GitHub API、读写本地文件、操作浏览器、查询数据库，都可以。对外暴露的就是统一的 MCP 接口。业界也已经出现了大量现成 Server，比如文件系统 MCP、浏览器 MCP、设计工具 MCP，这也是为什么搜索平台上“免费联网 MCP”“MCP 服务 Java”这类词热度一直很高——大家确实在到处找好用的现成接入方案。

3.3 MCP 和 Skill 的本质区别

这里要特别强调一个容易被忽略的点：MCP 的核心是“协议”，Skill 的核心是“内容”。

MCP 不关心你的工具内部做了什么，它只提供一套标准化的通信方式。它改变的是模型与外部世界的“连接方式”。Skill 则是在“模型已经有了能力”的基础上，告诉模型“怎么把这件事做得更专业”。它改变的是模型的“做事方式”。

用一句话总结：模型通过 MCP 获得“手”，通过 Skill 获得“大脑里的操作手册”。光有 MCP，模型能调工具，但不知道调完之后按什么流程检查、按什么标准汇报；光有 Skill，模型知道流程，但伸手出去发现什么都够不到。真实项目里，两者经常一起出现，但它们的职责边界必须分清。

4. 子 Agent 到底解决什么问题

子 Agent 是三个概念中层级最复杂的一个。它可以很小，也可以很庞大；它既可以被看作一种“执行单元”，又可以被看作一种“架构设计模式”。但不管怎么定义，它的核心价值都指向同一件事：把复杂的任务拆出去，让不同的执行单元各管一段，降低单次对话的认知负担。

4.1 子 Agent 的本质：一条独立的执行线程

如果用一个不太严谨但好理解的类比，主 Agent 和子 Agent 的关系，类似于一个进程和它派生的子线程。主 Agent 负责理解用户的总体意图、拆解任务、调度资源；子 Agent 接收一个被明确界定的子任务，在独立的上下文窗口里执行，执行完再把结果交回主 Agent。

为什么需要这种独立上下文？因为大模型的上下文窗口是有限的。如果你在一个对话里同时处理“项目代码审查”“编写测试用例”“整理发布说明”三项任务，很快就会把上下文撑满，而且前面的信息可能干扰后面的判断。更好的做法是：主 Agent 把“代码审查”这个任务交给子 Agent 去完成，子 Agent 只加载代码相关的信息，执行完毕后返回一份精简的审查报告；主 Agent 继续处理其他任务。

这种设计在 OpenAI 开源的 Swarm 思路里体现得很清楚：每个 Agent 拥有自己独立的 System Prompt 和工具集，Agent 之间可以互相传递任务，执行完后把控制权交回。这个设计理念现在已经成了 Agent 工程的主流做法，只不过有的产品叫 Workflow，有的叫 Task，有的叫子 Agent。

4.2 子 Agent 解决的核心问题

子 Agent 在实际项目里主要解决三类问题。

第一，上下文隔离。长任务执行过程中，不同阶段的信息互不干扰。做调研的子 Agent 不需要关心主 Agent 之前的对话历史，它只需要拿到调研目标和相关材料，然后输出结构化的结果。

第二，职责单一。一个子 Agent 只做一类事情，System Prompt 可以写得非常聚焦。这让它的行为更可控、更可预测，也更容易测试。相比之下，如果让主 Agent 一个人身兼数职，它的 Prompt 越长，越容易在各种任务之间摇摆。

第三，并行和路由。在一些 Agent 框架里，你可以同时派出多个子 Agent，分别处理不同方向的调研，最后汇总结果。这能显著缩短整体任务时间，也符合“用多个小模型/多个上下文窗口组合成一个大系统”的思路。

4.3 子 Agent 与 Skill、MCP 的关系纠葛

很多人会把子 Agent 和 Skill 搞混，原因是它们都像“让模型用另一种方式做事”。但两者的本质区别是：Skill 改变的是“模型做事的方法”，子 Agent 改变的是“执行任务的主体”。

同样的道理，子 Agent 和 MCP 的边界也要分清。MCP 是你给 Agent 配的工具，子 Agent 是使用工具的“另一个大脑”。一个子 Agent 内部可以调用多个 MCP 工具，也可以在逻辑里嵌入 Skill 的使用流程。它们不在同一个层级，不存在“非此即彼”的选择关系。

5. 三者对比：从四个维度彻底分清

前面分别解释了每个概念是什么，这一节用一个统一框架把它们放到同一张表里对比。掌握了这张表，你就掌握了三者关系的核心。

这张表可以帮助你做快速判断：当你在设计一个 Agent 功能时，先问自己想解决的是“怎么做得更好”，还是“怎么连得上”，还是“谁来负责这一段”。答案不同，对应的技术选择完全不同。

5.1 补充一个更贴近开发的视角

从开发者的实际操作来看，三者还可以用“文件、进程、实例”来重新映射：

Skill 通常表现为项目里的一个文件或文件夹，它随项目走，可以提交到 Git，可以评审，可以复用。它强调“规范性”和“可沉淀”。

MCP 通常表现为一个独立进程（Server），它有自己的生命周期，需要启动、连接、鉴权。它强调“标准协议”和“外部系统集成”。

子 Agent 通常表现为框架里的一个类或一个实例，它在程序运行时被创建、调用、销毁。它强调“任务路由”和“上下文管理”。

这种映射能帮你更准确地判断自己在当前阶段真正缺的是哪一种能力。如果你的问题是“模型输出的代码风格不符合团队规范”，你应该写 Skill；如果你的问题是“模型无法读取数据库里的订单数据”，你应该配 MCP Server；如果你的问题是“一次对话做太多事，越到后面越乱”，你应该拆子 Agent。

6. 真实项目里如何组合使用

概念讲清楚了，还要解决一个更实际的问题：在一个真实项目里，三者到底怎么配合？这里给出一个典型的组合决策链路，以及一个最小示例代码。

6.1 组合决策链路

假设你要设计一个“代码仓库助手”，它需要完成代码审查、生成测试用例、提交 PR 三步任务。在设计系统时，你可以按下面的顺序做决策：

第一步，确定主 Agent 的职责。主 Agent 负责接收用户请求、理解意图、规划任务。它是整个系统的调度中心。

第二步，确定需要哪些 MCP Server。代码助手必须连接 Git 仓库，所以你需要一个 GitHub MCP Server 或 Git 工具 MCP；如果要读本地代码，再挂一个文件系统 MCP。这一步解决的是“模型怎么访问数据”的问题。

第三步，确定哪些环节需要 Skill。“代码审查”这一步对输出格式和检查标准有严格要求，这时候给它挂一个“安全审查 Skill”；“生成测试用例”需要遵循团队的测试规范，给它挂一个“单元测试规范 Skill”。Skill 在这里负责让每一步的执行质量符合预期。

第四步，确定哪些任务要拆给子 Agent。“代码审查”如果涉及多个模块，可以让一个子 Agent 审查前端代码、另一个子 Agent 审查后端代码，同时执行。每个子 Agent 内部再使用对应的 Skill，并通过 MCP 读取对应目录的代码。

这个链路嵌套了三个层级：主 Agent 调度子 Agent，子 Agent 使用 Skill 规范行为，Agent 通过 MCP 获取外部数据。三者各司其职，而不是互相替代。

6.2 最小组合示例代码

下面用一段 Python 风格的伪代码来说明这个组合思路。这里不绑定任何具体 Agent 框架，重点是展示“哪些代码对应 Skill，哪些代码对应 MCP，哪些代码对应子 Agent”。如果读者需要跑通真实版本，可以把它映射到自己正在用的框架上。

# 文件路径: agent_system_demo.py # 说明：演示 Skill、MCP、子 Agent 在同一个 Agent 系统中的组合方式 # 这不是某个框架的完整实现，而是概念示意代码 from dataclasses import dataclass # ---------- MCP 层：负责连接外部工具 ---------- class McpClient: """模拟一个 MCP Client，负责发现和调用 MCP Server 上的工具""" def __init__(self, server_url: str): self.server_url = server_url self.tools = self.list_tools() def list_tools(self): # 实际项目中，这里会调用 MCP 协议接口，从 Server 拉取工具清单 return [ {"name": "read_file", "description": "读取本地文件"}, {"name": "search_code", "description": "在代码仓库中搜索关键字"}, {"name": "create_pr", "description": "创建 GitHub Pull Request"}, ] def call_tool(self, tool_name: str, args: dict): # 实际项目中，这里会把参数序列化后发给 MCP Server print(f"[MCP] 调用工具: {tool_name}, 参数: {args}") if tool_name == "search_code": return {"matches": ["main.py", "utils/parser.py"]} if tool_name == "read_file": return {"content": "def hello():\n print('hi')\n"} return {"ok": True, "pr_url": "https://github.com/demo/repo/pull/42"} # ---------- Skill 层：负责固化做事流程 ---------- class ReviewSkill: """模拟一个 Skill：代码安全审查技能""" def __init__(self, rules_file: str): self.rules_file = rules_file def apply(self, code_content: str) -> dict: # 实际项目中，Skill 的文本会被注入到模型上下文中， # 模型再按照规则生成审查结果。这里用简单的规则引擎模拟。 risk_keywords = ["eval(", "exec(", "SELECT *"] risks = [kw for kw in risk_keywords if kw in code_content] return { "skill": "code-security-review", "rule_file": self.rules_file, "risks": risks if risks else ["未发现明显风险"], "status": "reviewed", } # ---------- 子 Agent 层：负责执行独立子任务 ---------- @dataclass class SubAgentResult: task_name: str result: dict status: str class CodeReviewSubAgent: """子 Agent：只负责代码安全审查，拥有独立上下文和工具集""" def __init__(self, mcp_client: McpClient, review_skill: ReviewSkill): self.mcp_client = mcp_client self.review_skill = review_skill def run(self, module_name: str) -> SubAgentResult: print(f"[子Agent] 开始审查模块: {module_name}") # 子 Agent 通过 MCP 读取代码 files = self.mcp_client.call_tool("search_code", {"keyword": module_name}) latest_file = files["matches"][0] code = self.mcp_client.call_tool("read_file", {"path": latest_file}) # 子 Agent 使用 Skill 规范审查流程 review = self.review_skill.apply(code["content"]) return SubAgentResult( task_name=f"review:{module_name}", result=review, status="done", ) # ---------- 主 Agent 层：负责调度 ---------- class MainAgent: def __init__(self, mcp_client: McpClient): self.mcp_client = mcp_client self.review_skill = ReviewSkill(rules_file="security/rules.md") self.review_sub_agent = CodeReviewSubAgent(mcp_client, self.review_skill) def handle(self, user_request: str) -> None: print(f"[主Agent] 收到请求: {user_request}") # 主 Agent 规划任务：先审查，后提交 PR modules = ["main", "parser"] for module in modules: result = self.review_sub_agent.run(module) print(f"[主Agent] 子任务完成: {result}") # 审查通过后，主 Agent 通过 MCP 创建 PR self.mcp_client.call_tool("create_pr", {"title": "security review"}) print("[主Agent] 全部流程结束") if __name__ == "__main__": mcp = McpClient(server_url="http://localhost:3000/mcp") agent = MainAgent(mcp_client=mcp) agent.handle("帮我审查代码并提交 PR")

这段代码虽然是示意，但它把三者分工展示得很直白：MCP 层管理“读文件”“搜代码”“提 PR”的工具调用；Skill 层管理“代码审查”的规则与流程；子 Agent 层拥有独立的执行入口，负责把某个模块的审查任务跑完；主 Agent 只做调度和汇总。

6.3 运行与验证建议

如果你把上面的代码保存为agent_system_demo.py，直接用 Python 3.9 及以上版本运行，可以看到终端输出里出现了[MCP]、[子Agent]、[主Agent]三类日志，分别对应三层组件。这样就能直观验证：子 Agent 通过 MCP 拿到代码，再通过 Skill 产出审查结果，主 Agent 拿到结果后继续处理后续动作。

实际项目里，验证标准应该再提高一层：不仅要看流程能跑通，还要看每一个环节是否“按协议工作”。MCP 层要确认 Server 工具清单能被正常发现，Skill 层要确认模型输出确实遵循了规则文件里的格式要求，子 Agent 层要确认它的输出没有污染主 Agent 的上下文。

7. 常见误区与排查建议

这一节把搜索热词里频繁出现的问题整理成一份误区清单。很多困惑不是因为你理解能力不够，而是因为这些坑太常见。

7.1 一个典型的排错路径

如果你在实际配置中遇到了“MCP 工具注册不上”这类问题，比如在一些代码 Agent 工具里接入 Figma MCP 时提示注册失败，可以按下面的顺序排查：

第一步，确认 MCP Server 进程是否正常启动。很多注册失败不是协议问题，而是 Server 根本没有跑起来。第二步，确认 Client 能拿到工具清单。MCP 的一个关键机制是工具发现，Client 启动时会主动拉取 Server 暴露的工具列表。如果清单为空，模型就没有任何工具可以调用。第三步，确认环境变量和认证信息是否完整。一些 Server 需要 API Token 才能工作，配置缺失会导致调用报错。第四步，检查 Client 的配置项里是否启用了对应的 MCP Server。有些框架默认不加载所有 Server，需要手动启用。

这个排错路径对任何 MCP 接入问题都适用，建议收藏备用。

8. 工程落地建议与最佳实践

最后这部分写给真正要上生产环境的开发者。前面已经解决了“是什么”和“怎么选”的问题，这里重点讲“怎么落地不翻车”。

8.1 在项目里引入这三个概念时的优先级

如果团队从零开始构建一个 Agent 系统，不要一开始就追求大而全。更推荐的推进顺序是：

第一，先用 MCP 解决“数据可达性”。这是所有上层能力的基础。模型连数据都读不到，写再多 Skill 也是纸上谈兵。先把项目需要的外部工具和数据源接入进来，用最小 MCP Server 验证通一条链路。

第二，再沉淀 Skill。在业务流跑通之后，把重复出现的操作流程固化成 Skill。比如你发现每次生成周报，模型都会漏掉上线的风险记录，那就写一个“周报生成 Skill”，把章节结构、风险项模板、数据来源写清楚。Skill 应该来自真实业务中的重复问题，而不是从网上抄一个模板。

第三，最后拆子 Agent。只有当任务复杂度真正超过单上下文承受能力时，再把任务拆出去。拆分的标准是：子任务是否有明确的输入和输出，是否可以被独立验证。不确定的情况下，先不拆。

8.2 命名、版本与团队协作规范

Skill 和子 Agent 都应该像代码一样纳入版本管理。Skill 文件建议用有意义的前缀命名，例如code-review-security.md、release-note-generator.md，并在文件头部写明适用场景和已知限制。子 Agent 的职责边界要写进文档，否则后期很容易出现两个子 Agent 功能重叠的情况。MCP Server 的配置信息（地址、Token、超时时间）必须放在环境变量或配置中心管理，禁止硬编码在代码里。

8.3 安全边界必须前置

任何涉及数据库操作、文件写入、远端仓库修改的功能，都必须在 MCP 层做好权限控制。MCP Server 暴露给 Agent 的工具清单要遵循最小权限原则：只暴露当前任务必需的工具，不需要的工具不要注册。对于“删除文件”“执行 SQL”“推送代码”这类高风险操作，应该在 Server 内部增加二次确认机制，或者要求必须传入人工审批后的令牌。

另外，调用第三方 MCP Server 时，要检查它的数据流向。不要随便在 Server 配置里填入高权限 Token，最好为 Agent 单独创建低权限账号，防止模型在意外情况下执行越权操作。这一点在生产环境里怎么强调都不过分。

8.4 可观测性设计

三个概念引入之后，系统的复杂度会明显上升。建议在每一层都打日志：MCP 层记录工具名、参数和返回状态；Skill 层记录命中的技能名称和规则版本；子 Agent 层记录任务名称、开始时间、结束时间和结果状态。这样一旦出问题，你可以快速定位是哪一层出了问题，而不是在一堆对话记录里大海捞针。

9. 写在最后

Skill、MCP、子 Agent 这三个概念，本质上代表着 AI Agent 工程化过程中三个不可互相替代的抽象层级。Skill 让你把流程沉淀下来，MCP 让你把外部世界连进来，子 Agent 让你把复杂任务拆出去。真正的高手不会纠结于“哪一个更重要”，而是会像搭积木一样，根据任务的数据流和执行流，把三者组合成一套系统。

对于正在学习 Agent 开发的读者，建议下一步找一个真实的小任务，比如“读取一份本地日志并生成分析报告”，亲手把流程拆一遍：需要哪个 MCP Server、需要哪些 Skill 规则、要不要拆子 Agent。把这个最小系统跑通，你对三者关系的理解就会超过大多数停留在概念层面的人。