一文讲清 Agent 三要素：Skill、MCP 与子 Agent 的区别与组合

在 Agent 项目里Skill、MCP、子 Agent 是被反复提起却始终容易混淆的三个概念。Skill 被当成插件MCP 被当成技能包子 Agent 被当成多线程任务这些理解都会让系统设计走偏。三者的抽象层次并不相同Skill 是给模型看的操作知识MCP 是连接外部系统的标准协议子 Agent 是承担局部任务的执行单元。分不清它们不只是命名问题而是整个 Agent 架构的职责边界会跟着乱掉。这篇内容会围绕定义、定位、适用场景、组合方式和最常见误区展开读完你至少能回答三个问题任务表现不好时该补什么、外部系统接不进来时该查什么、上下文塞不下时该拆什么。1. 把 Skill、MCP、子 Agent 放进同一张架构图里看1.1 一句话定义知识、连接、执行实际项目里一个 Agent 要完成一次真实任务至少需要三样东西知道这件事按什么流程做能够拿到外部数据和操作外部系统以及有足够的上下文空间去执行复杂步骤。这三样正好对应 Skill、MCP 和子 Agent。Skill 是知识层。它把完成某类任务的步骤、规范、常见坑和示例打包成模型可读取的指令。模型读到 Skill 之后知道这件事应该先做什么、后做什么、输出长什么样但它本身不提供数据访问能力。MCP 是连接层。MCP 全称 Model Context Protocol是一套开放协议用标准化的方式把文件系统、数据库、设计工具、浏览器、代码仓库等外部能力暴露给模型。模型要通过工具调用才能操作这些外部系统MCP 解决的就是怎么连、怎么调、拿什么数据。子 Agent 是执行层。它是主 Agent 在独立上下文中拆分出的执行单元负责完成一个有明确边界的局部任务。子 Agent 有自己独立的上下文窗口、自己的规划和执行循环结束后把结构化结果交回主 Agent。这三个词回答的问题完全不同。Skill 回答按什么流程做MCP 回答用什么接口拿数据子 Agent 回答这么复杂的任务该由谁在独立上下文里执行。很多人纠结Skill 和 MCP 到底选哪个本质上是把三个不同层的问题揉成了一句话。1.2 用项目分工理解三个角色用一个团队协作模型来类比三个概念的边界会清晰很多。主 Agent 像一个项目经理。它接收用户需求判断任务复杂度决定是自己干还是拆分。子 Agent 像项目组里的专业工程师。工程师有自己独立的工作空间和职责范围接收项目经理拆分出来的子任务完成后只汇报结果。好处是互不干扰坏处是多一次汇报和上下文重建的成本。Skill 像工程师手里的作业手册和规范文档。手册里写了做事步骤、检查项、验收标准、常见错误示例。工程师技术水平再高也要按项目和公司的规范来Skill 就是把这些规范固化下来让每次执行结果尽量稳定。MCP 像公司的办公系统和外部服务接口。OA、数据库、设计系统、代码仓库这些基础设施通过标准化接口开放出来。工程师要访问这些系统不需要自己重新发明一套对接流程按接口规范调用即可。这个类比能解释大部分场景但有一个技术细节要补充Skill 不是给工程师随意翻阅的纸质文档而是会被注入到模型的上下文窗口里的指令文本。MCP Server 也不是物理设备而是一个运行中的服务进程外部系统通过它对外暴露工具和数据资源。1.3 三个概念分别回答什么问题概念核心问题现实载体常见实现示例Skill这类任务按什么流程做指令文档、SOP、模板、示例清单Claude Code 的 SKILL.md、Codex skill、opencode skillMCP外部数据和系统怎么连接协议、MCP Server、工具集合Figma MCP、Playwright MCP、数据库 MCP、GitHub MCP子 Agent谁在独立上下文中执行局部任务子任务配置、独立执行循环常见 Agent 框架里的 subagent、任务委派、多智能体编排从这里已经能看出三个概念不是并列选项而是同一个 Agent 运行时里的三个不同组件。真正要比较的不是Skill 还是 MCP而是当前缺的是方法、接口还是执行实体。2. Skill给模型看的程序性知识不是工具也不是插件2.1 Skill 在常见实现里长什么样Skill 这个概念在 Claude Code、Codex、opencode 等工具推出技能目录后被广泛讨论。不同实现细节不同但核心形态高度一致一个目录里面放一个带元信息的 Markdown 文件通常叫 SKILL.md 或 skill.md文件里描述这个技能适合什么场景、按什么步骤执行、输出什么格式。模型在启动或任务匹配时会读到 Skill 的名称和描述如果判断当前任务适用就把完整内容加载进上下文。也就是说Skill 本质上是上下文增强它不创建新的执行单元也不建立新的网络连接只是让模型在做某类任务时拥有更完整、更标准的方法。一个 Skill 通常包含四部分元信息名称、描述、适用场景。核心步骤明确的操作顺序。检查项和验收标准做完之后如何确认结果。示例和反例正确做法是什么容易踩的坑是什么。在设计上Skill 的目标是把靠模型临场发挥变成按沉淀的方法执行。同一个任务有 Skill 和没有 Skill结果差异往往很大因为模型默认只会按通用推理路径处理问题而不会自动知道你们团队的代码规范、接口约定和验收习惯。2.2 一个最小 Skill 文件示例下面是一个代码审查 Skill 的最小示例用于说明结构实际项目要结合自己的技术栈和团队规范调整。--- name: code-review description: 对指定代码目录执行代码审查输出问题清单和修改建议。 when_to_use: 当用户要求检查代码质量、发现潜在 bug 或评审合并请求时使用。 --- # 代码审查技能 ## 执行步骤 1. 定位目标代码目录确认语言和框架。 2. 读取关键文件先理解整体结构和核心调用链。 3. 按审查清单逐项检查 - 正确性逻辑分支、边界条件、空值处理。 - 异常处理是否有裸捕获、是否吞掉关键错误。 - 性能是否有循环内查库、重复计算、明显 N1。 - 安全是否拼接 SQL、是否信任未校验的输入。 - 可维护性命名、函数长度、重复代码。 4. 输出问题分级表和修改建议。 ## 输出格式 | 级别 | 文件 | 行号 | 问题描述 | 建议 | | --- | --- | --- | --- | --- | ## 常见坑 - 不要只挑语法问题优先找影响正确性和稳定性的问题。 - 不要在没有理解调用链的情况下直接给修改建议。 - 不确定的问题标注需确认不要用肯定语气误导。这个文件的关键点在于描述和步骤必须具体。when_to_use决定模型在什么情况下加载这个 Skill如果写得太宽泛模型会在不合适的场景里触发如果写得太窄需要的时候又想不起来。执行步骤必须可验证最好是读完代码、按清单检查、输出表格这种能被逐步执行的操作而不是认真审查这种空话。需要特别强调Skill 不能连数据库不能发 HTTP 请求不能操作文件。它只是一段文本指令。真正执行这些操作的是 Agent 内建的工具或 MCP 提供的工具。Skill 负责的是知道怎么做工具负责真的去做。2.3 Skill 和 MCP 最容易混淆的三个边界疑问Skill 的答案MCP 的答案我的 Agent 能直接操作文件吗只写 Skill 不够Skill 不提供文件读写能力需要文件系统工具或 MCP Server 暴露文件能力我想让模型按公司规范审查代码很适合写成 Skill把规范固化为步骤MCP 只提供代码仓库读取接口不负责审查方法MCP Server 能教会模型怎么做吗不能方法必须沉淀在 Skill 或 Prompt 里MCP Server 提供工具描述和参数说明但不是完整作业流程最常见的误区是我接了一个 MCP Server就相当于给模型装上了技能。实际上 MCP Server 暴露的是能力接口比如可以获取某个文件、可以读取数据库表、可以操作浏览器。模型知道这些接口存在但不知道怎么用它们完成一个优质结果。把作业方法写进 Skill把外部能力通过 MCP 接进来两者缺一不可。3. MCP连接外部系统的协议层不是能力本身3.1 MCP 的四个关键角色MCP 的架构分为四部分MCP Host运行 Agent 的宿主应用比如 Claude Code、Codex、自己开发的 Agent 程序。MCP Client内嵌在 Host 中负责和 Server 建立连接、发现工具、发起调用。MCP Server独立进程或服务把外部系统能力包装成标准的工具、资源、提示词。传输层常见的有 stdio 和 HTTP/SSE 两种方式。本地工具常用 stdio远程服务常用 HTTP。MCP Server 对外暴露三类元素元素作用类比Tools工具可被模型调用的函数有名称、描述、参数 Schema对外服务接口Resources资源可被模型读取的数据内容只读数据源Prompts提示词可复用的提示词模板标准调用话术MCP 本身不思考、不规划、不保证任务质量。它只做一件事把外部能力用统一协议暴露给模型让接一个新的外部系统变成加一个 MCP Server 配置而不是给每个系统单独写一套工具调用逻辑。3.2 一个典型调用链路Figma 设计稿以读取 Figma 设计稿并还原成前端代码为例MCP 的接入方式很直观。先在 Agent 的 MCP 配置里注册 Figma 相关的 MCP Server。不同工具配置位置不同下面是一份常见的 JSON 配置结构{ mcpServers: { figma: { command: npx, args: [-y, figma-developer-mcp], env: { FIGMA_API_KEY: 你的 Figma API Key } } } }启动后Agent 里的 MCP Client 会向 Server 发起工具列表查询把 Server 暴露的工具 Schema 注入到模型上下文。模型在规划阶段看到类似get_file_images、get_file_nodes、get_component_info这样的工具名和参数说明就会在需要时发起调用。调用链路大致是用户提出需求把某个 Figma 页面还原成 Vue 组件。模型选择 MCP 提供的工具传入文件 Key 和节点 ID。MCP Server 调用 Figma API把图层数据、样式参数、切图资源返回给模型。模型基于返回数据生成代码。这个过程中 MCP 负责的是拿到数据至于代码应该怎么写、组件怎么拆分、样式规范是什么仍然需要 Skill 或模型自身能力来解决。数据库场景也一样Chat2DB MCP 可以把数据库表结构和查询能力暴露给模型但这个查询怎么写才正确仍然需要模型和业务规则保证。3.3 MCP 工具注册不上到底是什么意思很多人在 Codex、Claude Code、VS Code Copilot 里接入 MCP 后发现模型根本调不到对应工具报错或工具列表里找不到。这个现象叫工具注册失败。工具注册的本质是MCP Client 启动时向 Server 发起tools/list请求拿到服务端声明的工具集合然后把工具名称和参数描述注入模型上下文。模型能看到的工具是经过这一步注册后的结果。如果 Server 没启动成功、配置没被加载、鉴权失败、或者传输模式不匹配工具就永远不会出现在模型面前和模型能力无关。常见原因包括MCP Server 的命令在本地不存在、依赖未安装、API Key 未配置、配置文件放错位置、Server 进程启动即崩溃。排查顺序在后文会单独展开。4. 子 Agent承担局部任务的执行单元不是进程也不是插件4.1 子 Agent 与主 Agent 的关系子 Agent 是指主 Agent 在执行任务过程中把一个有边界的子任务委派给另一个独立 Agent 实例。这个独立实例拥有自己的上下文窗口可以加载自己的 Skill、使用自己的工具集、按自己的规划循环工作最终把结果返回给主 Agent。主 Agent 负责全局目标、任务拆分、结果汇总和质量把关。子 Agent 负责局部执行。这种设计解决的核心问题是上下文隔离。举例来说主 Agent 在做一个大型 Web 项目改造上下文里已经塞满了需求文档、项目结构、接口定义。如果再让它同时处理十几个文件的代码生成模型很快就会丢失关键信息出现前面说过的约定后面忘了的问题。这时把文件生成任务拆给子 Agent每个子 Agent 只关心自己的模块和自己的那份上下文主 Agent 只保留拆分和汇总信息整体稳定性会明显改善。子 Agent 不是线程不是进程也不是插件。它是一个完整的 Agent 实例有独立的提示词、上下文和执行循环。把它当成可以随时零成本调用的函数是最常见的误解。4.2 什么时候应该拆子 Agent拆子 Agent 是有代价的四个信号出现时值得拆上下文逼近窗口上限。主 Agent 上下文越用越多关键信息开始被截断或稀释。子任务边界清晰。任务可以描述成输入是什么、输出是什么、由谁负责。子任务可并行。多个模块互不依赖串行执行会浪费大量时间。需要隔离风险。某个子任务可能失败或产生大量中间输出不希望污染主上下文。反过来如果任务只有三步、上下文还很宽裕、结果需要频繁汇总就不该拆。过度拆分会让任务变成频繁创建子 Agent、频繁汇报、频繁重建上下文成本反而更高。4.3 子 Agent 的运行时成本会被很多人忽略成本项主 Agent 直接做拆子 Agent 做上下文主上下文持续变大子上下文独立但每次创建要载入角色、Skill、工具列表延迟少一次委派延迟较低多一次规划、执行、汇报总耗时更长Token 消耗一个执行循环多个执行循环加上输出汇总总消耗更高排错难度日志集中在一个会话需要分别查看主 Agent 和子 Agent 的日志错误传播失败直接中断子 Agent 失败可重试但需要定义返回错误格式创建子 Agent 时它不会自动知道该用什么 Skill 和工具。主 Agent 必须在委派时明确告诉子 Agent你的角色是什么、有哪些 Skill 可用、允许调用哪些 MCP 工具、最终输出要什么格式。这些指令本身也要消耗 Token。所以子 Agent 适合的是复杂度换稳定性的场景而不是省事的场景。一个简化的运行时流程可以用伪代码表达主 Agent 接收用户任务 if 任务复杂度和上下文接近阈值: 创建子 Agent 为子 Agent 配置: 角色说明 相关 Skill 列表 可用 MCP 工具列表 输出格式模板 子 Agent 独立执行并返回结果 主 Agent 校验结果并汇总 else: 主 Agent 直接执行5. 三者如何组合从决策表到一个完整例子5.1 先回答该用谁的决策表很多项目的真实问题是已经接了 MCP但效果还是不稳定或写了 Skill但模型不按步骤走。这些问题的根源常常在于只补了其中一层另外两层没有跟上。需求场景优先方案补充说明让 Agent 按固定规范做代码审查写 Skill把规范固化成步骤和检查清单需要读取 Figma 设计稿或浏览器页面接 MCP外部数据必须通过工具连接大仓库多模块并行开发拆子 Agent上下文隔离加并行执行任务既要规范流程又要外部数据Skill MCP 组合方法靠 Skill数据靠 MCP任务上下文很大且要调用多个外部系统子 Agent Skill MCP子 Agent 负责隔离Skill 负责方法MCP 负责连接组合不是越复杂越好。能用 Skill 解决的问题不要急着接 MCP能用 MCP 解决的数据访问不要靠硬编码能靠上下文管理解决的并行需求不要一律拆子 Agent。先确认缺的是哪一层再决定加什么。5.2 完整例子用 Codex 加 Figma MCP 做设计稿还原用一个真实场景把三个角色串起来用户要求把 Figma 设计稿还原成一整套 Vue 页面。第一阶段主 Agent 加载了一个frontend-specSkill里面写明了团队的前端规范组件划分方式、间距体系、命名规则、代码生成后的验收清单。这一步保证模型知道按什么标准做。第二阶段主 Agent 通过 Figma MCP 读取设计稿。具体路径是MCP Client 列出工具模型调用工具获取画布数据、图层树、样式参数和切图资源。这一步解决数据从哪来。第三阶段主 Agent 判断页面较多、组件较复杂决定拆分。它创建了三个子 Agent分别负责头部导航区、商品列表区和详情弹窗区。每个子 Agent 被明确告知使用哪个组件规范 Skill、可以使用哪些 MCP 工具、最终输出什么格式。这一步解决由谁来执行更稳定。第四阶段子 Agent 各自完成后返回结果主 Agent 汇总再加载代码审查 Skill 对产物做一轮质量检查最后输出完整交付。这个例子里Skill 提供了方法和规范MCP 提供了数据和工具接入子 Agent 提供了上下文隔离和并行执行。每一层都在解决不同的问题把它们拆开理解组合时就不会乱。5.3 项目目录与配置示例如果把上述结构落到项目里常见的目录组织方式如下project/ ├── skills/ │ ├── frontend-spec/ │ │ └── SKILL.md │ └── code-review/ │ └── SKILL.md ├── agents/ │ ├── main-agent.md │ ├── component-builder.md │ └── reviewer.md ├── .mcp.json └── src/skills目录放技能文档agents目录放各 Agent 的角色定义.mcp.json放 MCP Server 的集合配置。这样设计的好处是技能、代理、连接配置各自独立哪一层出了问题可以直接定位不需要在整个项目里翻找。6. 最常见误区与一条实用排查链路6.1 五个高频误区误区一把 Skill 当成能连外部系统的工具。Skill 是文本指令它告诉模型怎么做事但它本身不发起网络请求、不读写数据库。如果任务需要外部数据必须配合工具或 MCP。误区二把 MCP 当成流程知识。MCP Server 暴露的是接口能力工具描述只能让模型知道能调什么不能让它知道怎么调才能得到高质量结果。同一个数据库 MCP有人查 SQL 又快又准有人查出来一堆错误数据差异在于提示词和 Skill不在协议本身。误区三把子 Agent 当成高性能并行线程。子 Agent 是完整 Agent 实例创建和上下文重建都有明显成本。以为开了子 Agent 就一定更快的人实际会看到 Token 消耗暴涨总耗时反而变长。误区四写了 Skill 却不测试、不迭代。Skill 是代码一样的产物它会被模型反复读取。一个写满空话、步骤含糊的 Skill还不如不写因为模型会被误导。Skill 必须经过单场景验证、版本迭代和失败样例补充。误区五MCP 工具能注册但调用失败直接归因到模型。工具能注册说明 Server 和配置基本正常但调用阶段可能还有参数错误、权限不足、Server 崩溃等问题。这时候要看的是调用返回的 error 信息而不是反复改提示词。6.2 MCP 工具注册不上的系统排查顺序当模型上下文里看不到预期工具时按下面的顺序排查不要一上来就怀疑模型步骤检查内容检查方式处理建议1配置文件是否被加载确认 MCP 配置放在当前项目或全局配置的正确位置修改配置后必须重启 Agent 会话2Server 能否独立启动在终端手动执行配置里的 command 和 args补装依赖、修正命令路径3传输方式是否匹配本地工具用 stdio远程服务用 HTTP/SSE按 Server 文档设置 transport4工具列表能否列出用 MCP 调试工具或客户端查询 tools/list确认 Server 是否注册了工具5鉴权和网络是否正常检查 API Key、Token、回调地址、网络策略补充环境变量和权限配置6配置缓存是否陈旧确认修改后是否重新加载了 MCP Client清理缓存并重启会话这一步的关键是工具注册是在模型看到工具之前完成的前几步全是基础设施检查和模型本身的推理能力无关。先把链路打通再谈模型表现。6.3 判断加 Skill、加 MCP 还是拆子 Agent排错之后面对系统效果不好的问题可以按这个顺序判断先看任务方法是否清晰。如果模型不知道流程、产出不稳定、每次结果差异大优先写 Skill。把步骤、检查项、输出格式固化下来。再看数据来源是否缺失。如果任务需要读取外部系统、文件、数据库、设计工具而模型拿不到数据优先接 MCP。先解决能不能拿到再解决拿得好不好。最后看上下文是否超限。如果任务步骤多、依赖多、单线程塞不下或者有明确可并行的子任务再考虑拆子 Agent。拆之前先确认子任务边界和输出格式已经定义清楚。这个顺序不是绝对的但适用于大多数项目。先方法、再数据、后隔离每一层解决完再评估下一层避免一次性把所有扩展都堆上去。7. 落地项目时真正要盯住的实践清单7.1 写 Skill 的检查清单每个 Skill 的 name 唯一description 足够具体when_to_use 能区分触发场景。执行步骤可操作、可验证不使用认真检查仔细处理这类空话。包含输出格式模板模型能按模板产出统一结果。包含常见坑和反例比只写正确步骤更有用。每个 Skill 用单独场景测试确认加载时机正确、执行结果稳定。纳入版本管理变更时记录原因避免悄悄改掉团队已确认的规范。7.2 接 MCP Server 的检查清单同一会话里 MCP Server 数量控制在少数几个工具太多会挤占上下文。鉴权信息走环境变量或密钥管理不写在项目配置文件里提交到仓库。每个关键工具调用要有错误处理Server 失败时要能降级或明确报错。明确工具的超时时间避免模型长时间挂起。定期更新依赖但升级前先在测试环境验证工具列表和调用行为。进入生产环境前补日志和监控至少能看出哪个 Server、哪个工具、耗时多少。7.3 拆子 Agent 的检查清单委派前明确输入、输出格式、可用 Skill 和允许调用的工具。给子 Agent 设定最大步数和超时时间防止死循环。定义返回错误的结构方便主 Agent 判断是重试、换方案还是终止。记录子 Agent 的完整执行日志排错时不至于只有最终结果。预估 Token 成本并行拆太多时要评估总消耗是否可接受。主 Agent 对子 Agent 结果做验收不能直接信任所有返回内容。7.4 下一步学习路径对刚开始接触这三个概念的开发者建议按这个顺序实践先用一个普通 Agent 完成单步任务理解模型调用工具的基本流程然后接一个 MCP Server比如 Playwright MCP 或数据库 MCP体验工具注册和调用接着为重复性任务写第一个 Skill观察模型输出是否变得更稳定再尝试在主 Agent 里拆一个子 Agent对比 Token 消耗和执行质量最后加入日志、评估和版本管理把三者的组合沉淀成团队可复用的规范。实际项目里最值得记住的一点是Skill 管方法、MCP 管连接、子 Agent 管执行。每次系统表现不符合预期先判断是方法不清晰、数据连接不通还是上下文撑不住问题定位准确了方案自然也会清晰。