Skill、MCP、子 Agent 这三个词最近在 Claude Code、Codex、Cursor 以及各种 Agent 框架里出现的频率非常高。但很多人看了一圈文档仍然分不清Skill 是不是一种插件MCP 是不是就是 API子 Agent 是不是就是多开几个对话窗口这次就用一篇讲透。先从最核心的定位差异开始再逐个拆解编写方式、接入方式和组合策略最后给出最容易踩的几个误区。先把结论放在前面三者解决的问题完全不同——Skill 管的是“Agent 会不会做”MCP 管的是“Agent 能不能连到外部系统”子 Agent 管的是“一个复杂任务要不要拆给多个执行者”。下面展开。1. 三者的核心定位速览先看一张对比表把最关键的差异放在一起维度SkillMCPModel Context Protocol子 Agent本质一组提示词 脚本 工作流定义一种标准化工具调用协议一个独立的 Agent 实例解决的核心问题让模型知道怎么高质量完成一类任务让 Agent 能连接外部数据源和工具让复杂任务可以被拆解、分工、并行执行承载形式通常是SKILL.md文件 辅助脚本MCP Server服务端 MCP Client客户端独立的上下文窗口 独立系统提示词是否强依赖外部服务依赖方式因实现而异多数场景纯本地必须有一个 Server 端通常通过网络连接大多数复用同一个模型服务只是上下文分离是否需要编码不一定写 Markdown 就能生效通常是但也可以直接用现成 Server不一定框架配置即可典型产品形态Claude Code 的.claude/skills/目录、Codex 的 Skill 目录mcpServers配置、MCP Registry、MCP InspectorLangGraph 的 Agent 节点、Claude Code 的 Task Agent、Coze 的 Workflow Agent类比给员工一份作业指导书给员工统一规格的网络接口给员工分配子任务并让他独立完成一句话版本Skill 是“方法”告诉模型这一类任务按什么步骤做、用什么输出格式、调用哪些本地脚本。MCP 是“连接”把外部工具、数据源、业务系统统一成 Agent 可以调用的服务。子 Agent 是“执行者”当一个任务超过单一上下文窗口或需要多角色协作时拆给多个 Agent 并行处理。三者不互斥实际项目里经常叠加使用。下面逐个拆开。2. Skill给 Agent 准备的“岗位说明书”2.1 Skill 到底是什么Skill 最早被广泛讨论和 Claude Code 的 Skills 机制、Codex 的SKILL.md规范关系很大。它的形态并不是一个“运行中的程序”而是一组静态文件核心是一个SKILL.md文件里面描述这个 Skill 适合解决什么问题执行这类任务的完整步骤有哪些边界条件和常见坑必要时如何调用同目录下的辅助脚本。模型在对话中判断当前任务匹配某个 Skill 时会先读取SKILL.md再按照里面写的流程逐步执行。也就是说Skill 本质上是给模型加装了一套高质量的工作方法。2.2 Skill、Prompt 和插件有什么区别很多人把 Skill 当成“复杂一点的 Prompt”这个理解方向对但不够准确。普通 Prompt 是对话开始时写在系统提示词里的一段文本每次对话都要携带内容长了会占用大量上下文窗口。Skill 不同它是按需加载的模型遇到匹配任务时才读取平时不挤占上下文。插件通常指具备实际运行能力的代码模块比如 VSCode 插件、浏览器插件。Skill 里的辅助脚本也可以算一种轻量插件但 Skill 的主体是流程定义代码脚本只是辅助执行手段。所以更准确的理解是Skill 高质量 Prompt 可选的本地脚本 触发条件 输出规范。2.3 怎么编写一个 Skill以 Claude Code 和 Codex 生态里常见的格式为例一个 Skill 目录长这样my-skill/ ├── SKILL.md └── scripts/ └── process.pySKILL.md的核心结构如下--- name: python-api-doc-generator description: 自动为 Python 项目生成 API 文档适用于 FastAPI、Flask 项目。当用户要求生成或更新 API 文档时使用。 version: 1.0.0 --- # Python API 文档生成 Skill ## 适用场景 - 需要为 FastAPI 路由自动生成 OpenAPI 文档 - 需要为现有 Flask 项目补充接口文档 ## 执行步骤 ### 1. 分析项目结构 1. 扫描项目根目录 2. 定位 main.py 或 app.py 3. 列出所有路由装饰器 ### 2. 提取接口信息 - 对每个路由记录路径、方法、请求体、响应模型、状态码 - 检查是否有 Pydantic 模型可复用 ### 3. 调用辅助脚本生成文档 bash python scripts/process.py --input ./src --output ./docs/api.md4. 检查输出确认覆盖所有路由确认请求示例可运行输出格式生成的文件必须包含接口列表、请求示例、响应示例、错误码说明。常见坑FastAPI 的response_model可能会隐藏额外返回字段提取时要注意。路由前缀api/v1需要保留不能遗漏。写 Skill 的关键原则 1. **描述要可触发**description 写得越具体模型越容易在遇到对应任务时准确匹配。 2. **步骤要可执行**每个步骤都要有明确输入和输出不要写“分析一下数据”这种模糊指令。 3. **脚本要弱依赖**辅助脚本优先用标准库避免引入复杂环境否则换机器就跑不动。 4. **要有失败兜底**在文档里写清楚“如果脚本报错退回到手动提取模式”。 ### 2.4 什么时候适合用 Skill - 你反复让 Agent 做同一类事情比如每周生成周报、处理 CSV 数据、整理代码提交记录 - 这类事情有固定套路但步骤又多每次在对话里重复描述太浪费 token - 你希望不同项目之间共享同一种“工作习惯”。 Skill 最适合标准化、重复性高、流程稳定的任务。反过来一次性任务、探索性任务、需要大量实时判断的任务写 Skill 收益不大。 ## 3. MCPAgent 连接外部世界的标准插座 ### 3.1 MCP 要解决什么问题 MCPModel Context Protocol是 Anthropic 在 2024 年底提出的开放协议设计目标很直接不要让每个 Agent 框架都给每个外部工具单独写一套适配代码。它把“工具接入”这件事标准化了类似 USB-C 接口之于外设。 没有 MCP 之前Agent 要接一个数据库、一个设计稿、一个浏览器需要给每个工具写专门的工具调用代码。有了 MCP 之后工具提供方只要实现一个 MCP Server所有支持 MCP 的客户端都能直接连接。 ### 3.2 MCP 的架构三段式 MCP 协议里三个角色 | 角色 | 职责 | 例子 | | --- | --- | --- | | MCP Host | 用户直接交互的程序负责调度 | Claude Desktop、Claude Code、Codex、Cursor | | MCP Client | Host 内部与 Server 通信的组件 | 协议客户端通常由框架内置 | | MCP Server | 暴露工具、资源、提示词的服务端 | Figma MCP Server、Playwright MCP Server、自定义业务 MCP Server | 传输方式通常有两种stdio本地子进程通信和 HTTP/SSE远程服务。 ### 3.3 一个 MCP Server 内部长什么样 下面是一个用 Python 写的最小 MCP Server 示意基于官方 SDK 风格 python import json from mcp.server import Server from mcp.server.stdio import stdio_server app Server(demo-server) app.tool() async def get_weather(city: str) - str: 获取某个城市的天气参数 city 为城市拼音或中文名。 # 这里替换为真实天气 API 调用 return json.dumps({city: city, temperature: 26, condition: 晴}) async def main(): async with stdio_server() as (read_stream, write_stream): await app.run(read_stream, write_stream) if __name__ __main__: import asyncio asyncio.run(main())在客户端比如 Claude Code的配置文件claude_desktop_config.json或.mcp.json里注册{ mcpServers: { weather-demo: { command: python, args: [/path/to/server.py], env: { API_KEY: your-key } } } }配置完成并重启客户端后Agent 对话里就会自动多出get_weather这个工具。模型判断需要天气信息时会按工具签名传参调用。3.4 MCP 的核心能力与调试方法MCP Server 能提供的资源有三类Tools工具可执行的操作比如“读取 URL”“发送 Slack 消息”“执行 SQL”。Resources资源可读取的上下文比如一份文档、一个数据库 schema。Prompts提示词模板可复用的用户指令模板。调试 MCP Server 有一个官方工具MCP Inspector安装后启动npx modelcontextprotocol/inspector node /path/to/server.js浏览器打开本地地址后可以列出所有工具、手动传参调用、查看完整请求响应。排查“工具注册不上”“调用超时”“参数校验失败”这类问题这都是第一站。3.5 什么时候适合用 MCPAgent 需要访问外部系统GitHub、数据库、设计稿、浏览器、企业内部系统工具数量多、且要被多个 Agent 或多种客户端复用你需要对工具的权限、日志、审计做统一管理。MCP 不适合的场景纯本地且只在单个项目里用到的一次性脚本直接写函数调用比起一个 MCP Server 简单得多。4. 子 Agent任务拆解与并行执行4.1 子 Agent 是什么子 Agent 不是一个新概念在 LangChain、LangGraph、AutoGen、Coze 等框架里早就有了。它的核心是在同一个 Agent 系统里再实例化一个拥有独立上下文、独立角色定义、独立工具权限的 Agent负责完成总体任务中的某一部分。主 Agent 负责理解用户意图、拆解任务、分配任务子 Agent 收到子任务后独立执行最后把结果交回主 Agent 汇总。4.2 什么时候必须拆子 Agent有几种情况主 Agent 自己硬扛反而会出问题上下文超限一个任务涉及的长文档太多强行塞进单一上下文窗口很快就到达上下文上限后面的推理质量暴跌。拆给子 Agent 处理每个子 Agent 只关心自己的那部分材料。多角色冲突比如一个任务里既要“严格按代码规范审查代码”又要“快速输出可运行原型”同一个模型容易在两种风格之间摇摆。拆成 Reviewer Agent 和 Coder Agent各管各的效果更稳。线性任务太长几十步的流程任务一个 Agent 从头做到尾一旦中间某步出错很难定位是策略问题还是执行问题。子 Agent 分段执行后可以逐段验证。4.3 子 Agent 的配置示例在 LangGraph 里定义一个子 Agent 节点通常需要单独的系统提示词和工具列表from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI # 主 Agent main_llm ChatOpenAI(modelgpt-4o, temperature0.1) # 子 Agent代码审查专用 review_llm ChatOpenAI(modelgpt-4o, temperature0.0) review_system_prompt 你是严格的高级代码审查员。你的职责 1. 只审查代码不修改代码 2. 按 P0/P1/P2 分级输出问题 3. 检查安全性、性能、可读性、测试覆盖 输出格式Markdown 表格。 # 子 Agent代码生成专用 coder_llm ChatOpenAI(modelgpt-4o, temperature0.4) coder_system_prompt 你是资深工程师。你的职责 1. 根据需求编写可运行代码 2. 遵守项目现有代码风格 3. 完成后简述设计决策 不要修改需求不要解释与实现无关的内容。 def review_node(state): code state[code] response review_llm.invoke( review_system_prompt \n\n请审查以下代码\n code ) return {review_result: response.content} def coder_node(state): requirement state[requirement] response coder_llm.invoke( coder_system_prompt \n\n请实现 requirement ) return {code: response.content} graph StateGraph(dict) graph.add_node(review, review_node) graph.add_node(coder, coder_node) graph.set_entry_point(coder) graph.add_edge(coder, review) graph.add_edge(review, END) app graph.compile()这里只是示意。实际项目里还要考虑子 Agent 的模型可以不同复杂任务用大模型简单任务用便宜模型子 Agent 之间的上下文需要显式传递不能靠全局内存要设置子 Agent 的最大轮次和超时时间防止无限循环。4.4 子 Agent 与多 Agent 系统的边界子 Agent 是“一个系统内部分工”多 Agent 系统则可能是多个独立服务共同协作。两者边界在实际产品中越来越模糊。关键判断标准是子 Agent 的生命周期由主 Agent 控制多 Agent 系统里的成员通常是独立部署、独立扩展的。用户请求 ↓ 主 Agent任务拆解、质量验收 ↓ 任务A → 子 Agent A数据清洗 任务B → 子 Agent B代码生成 任务C → 子 Agent C文档撰写 ↓ 结果汇总 → 主 Agent 统一输出这种“主管 专员”的结构是现在工业界最常用的 Agent 协作模式。5. Skill、MCP、子 Agent 到底怎么区分三个概念放在一起容易乱是因为它们常常同时出现在同一条 Agent 执行链路上。一个最简单的心法问自己三个问题。这个问题出在“模型不知道该怎么做”还是“模型做不到”不知道怎么做 → 写 Skill。做不到是因为没有外部数据或操作能力 → 接 MCP。这个任务是“把一个东西做得更好”还是“要同时做很多个东西”把一个东西做得更好 → Skill MCP 优化单 Agent。要同时做很多个东西或者任务太多容易串 → 拆子 Agent。这个能力是要“复用”还是“调用”复用一套工作方法 → Skill。调用一个外部服务 → MCP。再给一个更直观的表格场景用 Skill用 MCP用子 Agent让 Agent 每次按统一格式生成周报是否否让 Agent 查询 MySQL 里的订单数据否是否让 Agent 既要读文档、又要写代码、又要生成测试结合结合是让 Agent 调用公司内部的工单系统否是否让 Agent 自动完成一个 30 步的数据处理流程是可能可选一次对话里代码审查和代码生成同时做否否是6. 三者怎么组合一条完整的 Agent 工作流拆解看一个实际场景用 Agent 完成“从 Figma 设计稿生成前端项目代码”。这个任务如果只靠一个 Agent会非常吃力因为包含的环节太多读取 Figma 设计稿获取图层、样式、组件结构根据设计规范生成页面骨架生成组件代码绑定接口数据生成测试用例输出项目说明文档。组合方案如下第一步接 MCP让 Agent 能读 Figma。配置 Figma MCP Server。这一步解决“模型看不到设计稿”的问题。{ mcpServers: { figma: { command: npx, args: [ -y, figma-developer-mcp, --stdio ], env: { FIGMA_API_KEY: your-figma-token } } } }第二步写 Skill让 Agent 知道“前端项目生成”要按什么步骤做。Skill 里定义先读取设计稿的样式 token再生成 Tailwind 配置再按组件层级生成 JSX最后按项目模板填充目录。第三步拆子 Agent让不同模型和上下文互不干扰。主 Agent负责接收用户需求、拆任务、整合输出设计解析 Agent只读 Figma 数据输出结构化设计稿描述代码生成 Agent根据设计稿描述生成代码测试 Agent专门给生成的代码写测试用例。这个链路里Skill、MCP、子 Agent 各司其职MCP 负责连接Skill 负责质量子 Agent 负责分工。7. 最常见的几个误区误区一Skill 必须写代码不是。Skill 的主体是 Markdown 文档脚本只是可选辅助。很多高质量的 Skill 就是一份足够详细的流程文档效果已经很好了。误区二MCP 就是 API 封装MCP 确实封装了 API但它同时规范了工具发现、参数校验、错误返回、鉴权方式、日志审计。如果一个 Agent 框架直接调 HTTP API那这只是普通调用通过 MCP Server 封装后才能被任何支持 MCP 的客户端发现和调用。误区三子 Agent 越多越好子 Agent 数量越多上下文传递开销越大任务失败率也越高。单 Agent 能完成的简单任务强行拆成多 Agent反而会引入更多错误点。合理的判断标准是能单 Agent 做就先不拆。误区四Skill 和 MCP 二选一这两者不是竞争关系。Skill 定义“怎么做”MCP 定义“用什么做”。复杂任务通常是 Skill 调用 MCP 工具MCP 工具返回的数据又被 Skill 指导模型整理。误区五子 Agent 一定能解决上下文超限子 Agent 的上下文窗口是独立的但它从主 Agent 接收任务描述时主 Agent 仍然要把足够的信息传给它。如果任务描述本身就很长这个传递过程也会消耗主 Agent 上下文。正确做法是先让主 Agent 对材料做摘要再分发而不是把原始长文直接塞给子 Agent。误区六MCP 只适用于 Claude / Anthropic 生态MCP 是开放协议Claude、Codex、Cursor、以及大量开源框架都已支持。社区里已经有大量第三方 MCP Server覆盖浏览器操作、数据库、设计工具、企业办公系统、代码安全扫描等场景。8. 选型建议与实践策略给一个保守但可落地的选型顺序第一优先级写好 Prompt。很多问题不是缺 Skill、缺 MCP、缺子 Agent而是系统提示词本身没有写清楚。先把主 Prompt 优化到位。第二优先级加 Skill。当你在同一类任务上反复调 Prompt 调细节时把这套方法沉淀成 Skill 文件让 Agent 按需加载。第三优先级接 MCP。当任务必须访问外部数据或工具时再考虑 MCP。优先使用社区成熟 Server减少自研。第四优先级拆子 Agent。只有任务链路上出现了明显瓶颈比如上下文超限、任务风格冲突、并发执行需求再拆。实践建议给 Skill 和 MCP Server 都加版本号方便回溯MCP Server 的鉴权和网络策略要单独设计不要直接暴露到公网子 Agent 拆分的任务描述主 Agent 每次都要生成清晰的 JSON 结构避免模糊指令整个链路里每一步都留日志Skill 是否触发、MCP 工具调用是否成功、子 Agent 返回是否完整。工程上Skill、MCP、子 Agent 的关系可以统一理解为Skill 是“策略”MCP 是“通道”子 Agent 是“进程”。三者在设计阶段就要分开考虑运行时再组合到一起。9. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 没有触发 Skill直接按默认方式回答了Skill description 写得不够具体模型没有匹配到对应场景打开 Agent 的调试日志查看是否加载了 Skill 目录重写 description加入更多触发词和边界条件缩小 Skill 数量避免互相干扰Skill 已加载但执行步骤混乱SKILL.md 里的步骤存在歧义模型理解成多种路径单独把 SKILL.md 里的步骤交给模型问它理解为几步把步骤改成无序列表更清晰的 numbered list每步给出“完成标准”MCP Server 配置后工具注册不上路径错误、Python 环境错误、依赖缺失用 MCP Inspector 单独调试确认 command 可用、args 路径完整、依赖已安装查看客户端日志里 MCP 注册段调用 MCP 工具时超时Server 端处理慢或网络延迟高用 Inspector 手动调用看耗时给工具加超时和重试机制考虑把耗时任务变成异步任务立即返回 taskId子 Agent 返回结果丢失上下文主 Agent 分发任务时信息传少了检查子 Agent 收到的 prompt 日志主 Agent 在分发前先做信息摘要和格式化子 Agent 执行结果不符合预期子 Agent 的系统提示词与主任务目标冲突单独测试子 Agent 的提示词子 Agent 的系统提示词要更聚焦只保留该子任务相关约束Skill 和 MCP 同时存在时Agent 不知道该先做哪个Skill 流程里没有明确调用 MCP 工具的时机查看 Agent 的推理片段在 SKILL.md 的步骤里显式写“先调用哪个 MCP 工具拿到数据后如何处理”显存 / 内存占用过高Agent 框架加载多个模型实例或子 Agent 并发过多用系统监控工具查看进程资源占用限制子 Agent 最大并发数给子 Agent 分配更小的模型10. 总结与下一步Skill、MCP、子 Agent三者不是同一个维度的概念。Skill 解决单 Agent 的“能力上限”问题MCP 解决 Agent 与外部世界的“连接标准化”问题子 Agent 解决多任务场景下的“分工执行”问题。实际项目中最常见的错误是想着用一个方案解决所有问题。正确路线是先写好主 Agent 的 Prompt再沉淀 Skill按需接 MCP最后才考虑拆子 Agent。如果要自己动手验证推荐按这个顺序做实验在 Claude Code 或 Codex 里新建一个 Skill让它完成一次周报生成接一个现成的 MCP Server比如 Playwright MCP 或 Figma MCP测试外部工具调用在一个较长任务里手动拆两个子 Agent对比拆与不拆的效果差异。三个实验做完你基本就不会再把这三个词搞混了。最容易踩的坑也提前说清楚别急着堆技术先把一个最小链路跑通再逐步加复杂度。