Skill、MCP、子 Agent 这三个词最近几乎成了 AI Agent 项目里绕不开的热门词。很多人在同一个项目里既看到 Skill 目录又看到 MCP Server 配置还能在配置面板里“创建子 Agent”于是很自然地问它们到底有什么区别是不是有其中一个就不用另外两个说实话90% 的人分不清它们不是因为概念太深而是因为把它们放在了同一个维度上比较。真正的答案是Skill、MCP、子 Agent 根本不在同一个层级它们不是三选一的竞品而是一套组合体系里三个不同位置的零件。这篇文章我会从定位、使用场景、组合方式和最常踩的坑四个角度拆开讲清楚最后给出一套可以直接落地的判断方法和验证流程。1. 先破一个误区三者在不同层面不能直接放在一起比较1.1 它们看起来都像“给 AI 加功能”但机制完全不同站在使用者的视角Skill、MCP、子 Agent 都让 AI 显得“更能干”。比如你可以给 AI 装一个“网页转 Markdown”的 Skill也可以给它配一个能访问网页的 MCP Server还可以让它把一个“整理网页资料”的任务派给子 Agent 去完成。从对话界面看结果都是 AI 完成了一件之前做不到的事。但拆开来看三者的本质差异非常大。Skill 解决的是“模型知道该怎么做”的问题。它是一套指令、流程、示例和规则的集合告诉模型在处理某类任务时应该按照什么步骤来、输出什么格式、避免哪些错误。它不改变模型能访问什么只改变模型完成任务的方式。MCP 解决的是“模型能连接什么”的问题。MCP即 Model Context Protocol是一个标准化的接口协议。它让模型客户端可以通过一个统一协议发现外部工具、调用外部工具、读取外部数据源。简单说MCP 是模型和外部世界之间的插头标准。子 Agent 解决的是“任务应该由谁来执行”的问题。子 Agent 是一个独立的执行单元有自己独立的上下文、系统提示词、工具集和任务目标。主 Agent 把子任务委派给子 Agent子 Agent 执行完再返回结果。它更像一个任务调度体系里的岗位分工。一旦理解了这三个层级你就能明白“用 Skill 还是用 MCP”这个问题本质上是不成立的。真正的问题是你的任务卡在哪一层1.2 用一次任务拆开看三者的配合假设你想让 AI 做这样一件事把一个网页里的正文整理成 Markdown 文件然后按照固定格式命名保存。模型没有直接抓网页的能力吗不一定。如果模型客户端内置了网页抓取工具那这一步可以直接做。如果没有就需要通过 MCP Server 暴露一个“网页抓取”工具模型才能拿到网页内容。这就是 MCP 的职责。拿到网页内容之后模型知道要怎么提取正文、去掉广告、把标题转成二级标题、把正文拆成段落、最后按YYYY-MM-DD-slug.md格式保存吗如果模型之前没做过或者做过但输出格式不稳定就需要一套 Skill 提供明确的步骤规范和示例。这就是 Skill 的职责。如果这个任务同时要做 20 个网页并且每个网页还要先判断分类再决定保存到不同目录那主 Agent 很可能会被超长上下文和多重步骤拖垮。这时就可以拆分出“网页抓取子 Agent”“文章整理子 Agent”“文件归档子 Agent”每个子 Agent 只负责一段相对独立的任务。这就是子 Agent 的职责。一次看似简单的任务三者在不同环节各司其职。没有了 MCP模型拿不到网页内容没有了 Skill模型可能整理得乱七八糟没有了子 Agent任务一多就容易上下文溢出、互相干扰。所以不要问“这三个我该选哪个”而要问“我当前的任务到底在哪一层出问题”。2. 分别说清Skill、MCP、子 Agent 到底定义了什么样的能力2.1 Skill把“一次做对”沉淀成“每次都会”Skill 最核心的形态是一组模型在任务开始前可以读取的指令文件。常见实现是放一个 Markdown 文件里面写清楚任务描述、执行步骤、输入输出格式、规则、边界条件和示例。有些平台还支持把脚本、模板、参考文档一起打包进 Skill 目录。Skill 的价值在于复用。一个人第一次手工调用 AI 做出一套很好的结果把过程总结经验化写进 Skill 文件之后遇到同类任务模型就能直接照着这套经验执行。这相当于把私人经验变成团队 SOP。典型场景语言学习模型按你指定的“先给词汇再给例句再给测试题”的结构输出。写作风格模仿模型在动笔前先分析参考文本的句式、用词、段落结构再按分析结果写作。数学建模模型先列假设再建模型再求解最后写结论每一步都有固定模板。代码审查先看变更范围再检查安全性、性能、可读性最后给出分级问题清单。需要注意的是Skill 不是“魔法插件”。它只是提高了模型“做对”的概率并不能凭空给模型增加访问外部系统的权限。如果模型本身没有连接某个数据库或设计工具的能力Skill 再详细也拿不到数据。2.2 MCP把“工具接入”变成标准插头MCP 的完整含义是 Model Context Protocol中文可以叫“模型上下文协议”。它定义了一套标准通信方式让 AI 客户端可以像 USB 设备一样随时插入各种工具服务。在没有 MCP 之前每接入一个外部工具都要为特定的客户端写一套适配代码。模型和工具之间是“一对多”的私有对接。MCP 出现后工具方只需要实现一个 MCP Server暴露若干工具客户端只需要支持 MCP 协议就能自动发现并调用这些工具。你可以这样理解MCP Server 是一个“服务端”负责把某个工具或数据源封装成标准接口。例如 Figma 的 MCP Server可以把“读取设计稿”“获取图层信息”封装成可调用的工具。AI 客户端是“客户端”负责决定什么时候调用哪个工具并把调用结果放进上下文继续推理。两者之间通过 JSON-RPC 消息通信工具的描述、输入参数、输出格式都由协议定义。这就解释了为什么热搜里会出现“figma mcp 在 codex 中总是工具注册不上”。在实际项目里工具注册不上往往不是协议本身的问题而是 MCP Server 的启动环境、依赖版本、网络权限或配置路径出了问题。但很多人一看到“MCP”就以为要用新的协议知识其实先要解决的是最基础的工程问题。典型场景连接 Figma读取设计稿元素。连接 GitHub创建 Issue、读取代码仓库。连接本地文件系统读写特定目录。连接数据库执行查询语句并返回结果。连接浏览器访问网页内容。MCP 的价值在于“标准化”。一旦工具方实现了 MCP Server任何支持 MCP 的客户端都可以复用不需要单独适配。2.3 子 Agent让主 Agent 从“所有事都自己做”变成“调度别人做”子 Agent 并不神秘。本质上子 Agent 也是一个模型运行实例但它被限制在一个独立的上下文窗口里配置了独立的系统提示词、工具列表和任务目标。主 Agent 负责拆解用户请求生成子任务列表然后把每个子任务委派给对应的子 Agent 执行。子 Agent 执行完成返回结果给主 Agent主 Agent 汇总后给用户最终答案。为什么要拆分第一上下文长度有限。主 Agent 的上下文窗口是有限的如果所有中间结果都堆积在主 Agent 里很快就会超过窗口限制导致遗忘或混乱。子 Agent 用独立上下文处理后只把摘要或关键结果返回给主 Agent能显著减轻上下文压力。第二任务需要并行。某些任务可以拆成互相独立的多个子任务比如同时抓取多个数据源或者同时做多个文件的格式转换。用子 Agent 并行执行比主 Agent 逐个串行处理更快。第三角色隔离。不同子任务可能需要不同的行为规范。比如一个做数据清洗一个做报告撰写。如果放在同一个上下文里很容易互相污染。子 Agent 可以给每类任务加载专属的系统提示词和 Skill让行为边界更清晰。当然子 Agent 不是免费的。每个子 Agent 都会消耗 token、增加延迟、带来额外的调度复杂度。如果一个任务让主 Agent 直接做只需要两轮对话那拆分反而更慢。拆分的前提是任务确实足够长、足够复杂、需要并行或隔离。3. 适用场景别急着选先看你的问题出在哪一层3.1 一张表判断你的任务需要哪一层我经常用一种“三问法”来帮助判断你可以在设计 AI 工作流时直接用问题如果命中优先考虑模型是不是“不知道怎么做”而做不好输入相同的情况下模型质量不稳定格式不对步骤乱Skill模型是不是“没有能力访问某处”而做不到需要读数据库、设计稿、网页、本地文件模型当前没连接MCP主 Agent 是不是“被任务长度或上下文压垮”了任务步骤多、中间结果多、需要并行或角色分离子 Agent这三个问题可以同时命中。比如一个任务既需要固定流程又需要访问外部工具还需要处理很长的中间数据那就要把三层组合起来用。3.2 三类典型场景的特征Skill 更偏向个人经验沉淀和固定流程。适合那些“你已经很懂怎么做、只是懒得每次都重复交代”的任务。它不依赖外部资源只要模型本身具备基础能力就够了。比如写作风格调整、数据分析步骤、代码规范检查、教学辅助内容生成。MCP 更偏向系统集成和数据打通。适合那些“模型再聪明也看不见外部世界”的任务。你需要在 AI 客户端和某个外部系统之间建立一条标准通道。比如从项目管理系统拉取需求、读取数据库里的订单数据、操作设计软件里的画布对象。子 Agent 更偏向复杂任务管理和并行调度。适合那些“主 Agent 一人扛不住”的任务。比如一个客服系统里主 Agent 先判断用户意图再分派给“订单查询子 Agent”和“售后处理子 Agent”一个研究任务里主 Agent 让多个子 Agent 分别做资料搜集、结构分析和初稿撰写最后汇总成报告。3.3 从真实热词看用户的困惑集中在哪在搜索引擎和开发者社区里关于这三个词的问题非常典型。“agent skill 和 mcp 有什么区别”说明很多人把它们看作同层概念。这时候你需要先画一个三层模型Skill 在上层是任务执行的方法MCP 在中间是工具连接的通道子 Agent 在调度层是任务拆分的执行器。“figma mcp 在 codex 中总是工具注册不上”说明实战里 MCP 接入仍然有很多工程坑。注册不上要先查启动日志和网络而不是先怀疑协议设计。“如何编写 skill”“skill 怎么写”说明真正的需求是把零散经验整理成结构化指令。这块内容目前很像早期写提示词没有统一标准但对效果影响很大。“codex 接入 MCP 控制 matlab”说明工具链整合已经延伸到专业软件领域。这类需求需要 MCP Server 具备对专业软件的控制接口同时还要考虑授权、批量任务和错误恢复。4. 组合方式三种最常见的落地架构4.1 最小可用主 Agent Skill这是最轻量的架构。不接外部工具不拆分任务只给主 Agent 增加一套固定流程。典型流程用户输入目标。主 Agent 读取对应 Skill 文件。按 Skill 中定义的步骤执行。输出符合规范的结果。适合场景内容生成、格式转换、代码规范检查、学习方法指导。Skill 目录示例结构skills/ ├── web-to-markdown/ │ ├── SKILL.md │ └── scripts/ │ └── extract.py ├── math-modeling/ │ ├── SKILL.md │ └── templates/ │ └── paper_template.md └── code-review/ ├── SKILL.md └── rules/ └── security_checklist.mdSKILL.md 里通常会包含# 网页正文转 Markdown ## 任务角色 你是内容整理助手专门把网页正文转换成格式化 Markdown。 ## 执行步骤 1. 获取网页 HTML。 2. 定位 main 或 article 区域。 3. 删除导航、广告、脚注等无关内容。 4. 将标题层级映射为 H2/H3。 5. 保留代码块、引用、表格。 6. 按 YYYY-MM-DD-slug.md 格式命名输出。 ## 边界 - 只整理正文不生成摘要。 - 页面没有正文时返回明确错误说明不要猜测。这种架构的好处是简单、方便、见效快。缺点是模型自身的工具能力有限数据来源和动作执行都受限。4.2 工具增强主 Agent MCP Server当任务需要访问外部系统时在主 Agent 的基础上接入 MCP Server 是自然选择。典型流程用户输入需求主 Agent 判断需要调用某个工具。主 Agent 通过 MCP 协议向 MCP Server 发送工具调用请求。MCP Server 执行实际动作比如查询数据库、读取文件、调用 Figma API。MCP Server 返回结构化结果。主 Agent 把结果放入上下文继续推理。MCP 配置示例结构{ mcpServers: { figma: { command: npx, args: [-y, modelcontextprotocol/server-figma], env: { FIGMA_API_TOKEN: your-token } }, filesystem: { command: npx, args: [-y, modelcontextprotocol/server-filesystem, /data/projects] } } }这只是一个常见结构的示意不同客户端的配置字段可能不一样。落地前一定要先确认客户端支持的 MCP 配置格式和版本。这种架构适合需要打通设计稿、代码仓库、数据库、本地文件等场景。关键点是工具注册、权限管理、错误处理都要工程化处理。比如 Figma API Token 过期、网络超时、返回数据过大都会影响结果稳定性。4.3 复杂任务主 Agent 子 Agent Skill MCP当任务足够复杂时三层架构需要一起出现。这也是 Agent 最接近“团队协作”的一种形态。典型流程用户提出一个复杂目标例如“分析 30 个网页的内容生成一份行业趋势报告”。主 Agent 拆解任务抓取网页、内容清洗、主题聚类、报告撰写。为“抓取网页”建一个子 Agent配备 MCP 的浏览器或文件工具。为“内容清洗”建一个子 Agent配备数据处理 Skill。为“主题聚类”建一个子 Agent配备分析步骤 Skill。所有子 Agent 把结果返回给主 Agent主 Agent 汇总并生成最终报告。伪代码示意# 示意结构不是具体平台 API main_agent create_agent( system_prompt你是项目经理负责拆解任务并汇总结果。, ) crawler create_sub_agent( system_prompt你负责网页抓取只输出结构化内容。, tools[fetch_url_via_mcp, read_html], ) cleaner create_sub_agent( system_prompt你负责内容清洗按清洗规范输出干净的正文。, skills[web-to-markdown], ) topic_analyzer create_sub_agent( system_prompt你负责主题聚类按聚类规则输出主题和证据。, skills[topic-clustering], ) main_agent.delegate(task抓取以下 30 个 URL, sub_agentcrawler) main_agent.delegate(task清洗抓取结果, sub_agentcleaner) main_agent.delegate(task聚类分析, sub_agenttopic_analyzer) main_agent.synthesize()这种架构的效果上限高但复杂度也高。最需要设计的是“任务接口”子 Agent 之间传递什么结构的数据失败时是重试还是跳过结果超过上下文限制时如何摘要每个子 Agent 用什么系统提示词和 Skill这些都需要提前规划。5. 最常见误区为什么你的项目总是跑不起来5.1 误区一把 Skill 当成插件市场装得越多越好Skill 确实可以提升模型输出质量但模型在每次任务开始时通常只能看到部分 Skill 内容。如果装了几十个 Skill每个都占用上下文空间反而会挤占真正任务相关的信息导致模型注意力分散、输出质量下降。更合理的做法是只保留高频使用的 3 到 5 个核心 Skill并且把每个 Skill 尽量精简。新 Skill 要先在小样本任务上验证有效再收进正式目录不要一边做任务一边不断加载一堆规则。5.2 误区二MCP 工具注册不上先怀疑协议而不是先排查环境从我的经验看MCP 接入问题90% 以上都不是协议复杂而是环境问题。以热搜里的“figma mcp 在 codex 中总是工具注册不上”为例常见原因大致有这几种Node.js 版本偏低导致 MCP Server 无法启动。启动命令路径不对npx 找不到指定包。缺少环境变量比如 Figma API Token 没有配置或过期。网络无法访问 Figma API被防火墙或代理拦截。配置文件里路径、端口或参数写错。服务器已经启动但客户端没有刷新工具列表。遇到这类问题不要先重写协议、不要反复更换 Server 实现应该按下面这个顺序排查看现象客户端是报“找不到工具”还是“调用超时”还是“返回空结果”看输入配置文件路径、环境变量名、参数格式是否正确。看环境Node 版本、系统依赖、网络连通性、MCP Server 能否独立运行。看参数命令参数、路径参数、Token 是否有效。看边界该 MCP Server 是否支持当前客户端版本、是否对工具数量或调用频率有限制。你可以在终端单独启动 MCP Server观察日志输出。如果 Server 本身能启动并打印工具列表那问题大多在客户端侧如果 Server 自己都起不来就优先修环境。5.3 误区三子 Agent 越多越好结果互相干扰子 Agent 有独立的上下文但最终所有结果都要汇聚到主 Agent。子 Agent 过多容易造成几个问题结果汇总时主 Agent 上下文爆炸。多个子 Agent 并发写同一个文件或数据库出现冲突。子 Agent 之间没有统一的输出规范汇总时格式不兼容主 Agent 需要花大量 token 做“翻译”。过度拆分导致每个子 Agent 只看到局部信息错过全局关联。建议先不拆子 Agent等主 Agent 在处理某类任务时明显出现上下文不足、反馈速度变慢或步骤混乱再考虑拆分。每次拆一个子 Agent验证有效后再拆下一个。5.4 误区四以为三者可以互相替代Skill 不能代替 MCP。就算你把 Skill 写得再详细模型没有访问外部系统的通道依然拿不到 Figma 上的实际设计稿。MCP 不能代替子 Agent。MCP 只是提供工具不能帮你把一个长任务拆成可并行的多个子任务。子 Agent 不能代替 Skill。子 Agent 也需要方法指导否则它只是另一个没有经验的模型在独立上下文里瞎跑。正确理解是Skill 提供方法MCP 提供连接子 Agent 提供分工。三者是组合关系不是竞争关系。6. 实操建议如何设计你的第一个三合一路径6.1 先画任务链路再决定加什么拿到一个真实任务第一步不是去安装 Skill、配置 MCP、创建子 Agent而是先把任务链路画出来。用一张表格记录任务步骤模型需要做什么是否需要外部数据源是否可以固定流程是否需要独立上下文1. 抓取网页访问 URL 并获取 HTML是否是2. 提取正文清洗 HTML提取正文否是否3. 生成摘要基于正文生成摘要否是否4. 保存文件写本地文件是是否根据这张表你就能判断“抓取网页”需要外部数据源优先考虑 MCP。“提取正文”“生成摘要”是固定流程优先考虑 Skill。“抓取多个网页”时可以用子 Agent 并行处理。6.2 用一个最小验证样例跑通全流程不要一上来就处理 30 个文件。先选 1 个样例跑通完整流程。验证内容包括输入是否正确URL、文件路径、查询参数。输出是否符合规范格式、命名、内容完整性。日志是否完整每一步耗时、调用了什么工具、返回了什么结果。失败时行为某个工具调用失败后任务是重试、跳过还是中断只有样例跑通才能继续加入批量任务。批量任务要慢慢加先并行 3 个再 5 个观察资源占用和稳定性。6.3 建立三层一体的长期维护视角不要以为配置完就一劳永逸。Skill 需要持续迭代。任务流程变化了Skill 里的步骤也要跟着更新否则模型会沿用旧的、不再适用的规则。MCP Server 需要关注安全补丁和 API 变化。外部服务的 API 升级后MCP Server 可能也要更新Token 过期、权限变更要定期检查。子 Agent 的任务拆解也要随实际效果调整。如果某个子 Agent 总是失败可能是它的职责边界太宽需要继续拆分如果某个子 Agent 的任务太简单则可以考虑合并回主 Agent。6.4 一个可复用的判断框架最后我把整套判断逻辑浓缩成四个问题你可以直接在项目里用模型在当前任务里是不是因为“不知道怎么做”而做不好如果是写一个 Skill。模型是不是因为“没有能力访问关键系统”而做不到如果是接一个 MCP Server。主 Agent 是不是因为“任务太长、上下文太满、并发需求高”而扛不住如果是拆一个子 Agent。三个问题都命中那就按“主 Agent 子 Agent Skill MCP”的组合来搭建但每一步都必须从最小样例开始验证。这四句话看起来简单但执行起来需要你持续观察任务的真实瓶颈。Skill 解决质量不稳定MCP 解决数据与动作断层子 Agent 解决上下文和并发压力。先定位瓶颈再选择方案比盲目堆配置有效得多。很多人第一次接触这几个概念时总想着“哪个最厉害、哪个最流行”。但真正有价值的不是记住名词而是理解它们在任务链路里的位置。下一次你再看到某个项目同时包含 Skill、MCP 和子 Agent就不用再问“能不能互相替代”了。你可以直接看它的任务链路判断每一层是否放对了地方。如果层和层之间接得上样例验证能通过那这个 Agent 架构就是成立的如果只是把热门工具都堆进去但链路没有设计好跑不起来才是常态。