最近在配置 Agent 的时候我经常遇到一个看起来很基础、实际很绕的问题到底是配置 Skills还是配置 MCP在 Claude Code、Codex、OpenCode 这类工具里来回试了几轮之后我越来越觉得这个问题的问法本身就有问题。Skills 和 MCP 并不是同一个层面的东西也不是你死我活的替代关系。Skills 解决的是“模型知不知道怎么把一件事做对”MCP 解决的是“模型能不能碰到真实世界的工具和数据”。真正该回答的判断只有一个当前任务缺的到底是流程方法还是外部连接这不是文字游戏。把这两个概念分开想清楚你在配置、排查、设计 Agent 工作流时会少走很多弯路。1. Skills 和 MCP 其实解决的是两种不同的问题1.1 Skills 是给 Agent 的操作手册Skills 这个叫法在不同工具里不完全一样但在 Claude Code、Codex、OpenCode 以及很多 Agent 工具里思路是一致的把一组完成特定任务的指令、步骤、示例、边界条件封装成一个可复用的文件或目录。当模型遇到相关任务时它会加载这份“操作手册”按照里面的方法去执行。它更像是在告诉模型面对这类需求你应该先做什么再做什么输出要符合什么格式哪些情况要额外检查。比如你可以写一个“前端页面生成”的 Skills里面规定先分析设计稿的整体布局。再按区块拆成组件树。每个组件要生成语义化 HTML 和可维护的 CSS。最后要检查响应式断点。这样做的本质是把“怎么做”这件事从模型临时发挥变成一种可复用、可维护、可迭代的知识资产。1.2 MCP 是给 Agent 的标准插头MCP也就是 Model Context Protocol是一套标准化的连接协议。它解决的是完全不同的另一件事让 AI 应用能够通过统一的方式去调用外部工具、访问外部数据源。在 MCP 出现之前每个 Agent 要接一个外部服务几乎都要定制一套插件或 API 适配。Figma 有一套接入方式数据库有另一套浏览器自动化又有一套各自为政。MCP 做的事情是把“工具调用”这件事标准化一个 MCP Server 可以暴露工具、数据资源和提示词模板任何支持 MCP 的客户端都可以用同一套协议去调用。所以 MCP 像是给 Agent 装了一排标准插头。插上 Figma 的设计稿数据插上数据库查询能力插上浏览器操作能力。它决定的是模型能碰到什么东西。1.3 为什么这两个概念总会被放在一起讨论因为在实际配置里它们经常出现在同一个界面、同一份配置文件、同一个“给 Agent 加能力”的操作流程里。你想让 Agent 从设计稿生成前端代码可能既需要一个 Skills 来告诉它按照什么步骤拆解设计稿也需要一个 MCP 来真正读取设计稿里的图层和数据。你写完一个 Skills要配置一个 MCP Server你给 Agent 装完一堆 MCP 工具又发现它还是不会按你的规范输出。于是“Skills vs. MCP”就成了一个看起来像二选一的问题。但如果站在系统角度看它们属于完全不同的层Skills 是流程和知识层MCP 是工具和连接层。一个管“会不会做”一个管“能不能碰到”。2. 从 Figma 到前端代码一次配置里两者是怎么分工的2.1 一个很典型的配置场景假设你现在想做一件事让 Agent 根据 Figma 设计稿生成一个前端页面。这个任务听上去很“标准”但在实际落地时会发现它至少包含两个完全不同的需求Agent 需要读取设计稿的布局、图层、颜色、尺寸、标注信息。Agent 需要按照你的团队规范来写代码比如组件命名、目录结构、样式写法。第一个需求涉及外部系统访问。设计稿不在对话上下文里Agent 不能靠猜它必须真正去读取设计稿数据。这个时候你大概率会需要 Figma 相关的 MCP Server或者蓝湖这类设计协作平台提供的 MCP 能力。它负责把外部设计数据“喂”给模型。第二个需求涉及行为约束。就算模型拿到了设计稿它也可能按照自己的习惯去写代码而不是按照你团队的标准。这时候你需要一个 Skills告诉它先拆组件再写布局样式文件放在哪个目录类名用什么规范。2.2 只配 Skills 会发生什么只配 Skills不配 MCP模型的表现往往是很懂“怎么做”但拿不到真实的输入。它可能在对话里收到一张截图然后开始“看图说话”。截图能提供一部分视觉信息但拿不到精确的像素间距、颜色变量、组件标注、切图资源。结果就是生成出来的页面看起来差不多但细节对不上颜色差一个色号间距差几个像素切图资源缺失。更麻烦的是如果设计稿更新了模型没有途径去重新读取最新数据。它只能依赖你在对话里重新描述或者重新贴截图。这类流程根本没法稳定复用。2.3 只配 MCP 会发生什么只配 MCP不配 Skills模型的表现是另一个极端它确实能读到设计稿但不知道按什么标准输出。它可能读到了完整的设计数据然后直接生成一整套页面代码。乍一看没问题但代码风格可能和你团队现有项目完全不一致没有按组件拆分样式全写在全局 CSS 里类名随意也没有考虑可维护性。也就是说MCP 把外部世界的数据给了模型但模型不一定知道“在这个团队里什么才是合格的结果”。Skills 在这里承担的是质量标准和工作流约束。2.4 两者配合的完整流程在实际配置里一个比较完整的流程会是这样Agent 收到“从 Figma 生成前端页面”的任务。加载“前端页面生成”Skills里面写明拆解顺序、组件规范、输出要求。通过 Figma MCP Server 连接设计稿读取图层结构、样式变量和标注数据。Agent 按 Skills 里的步骤把设计稿数据转换成组件树再生成代码。如果有额外资源通过 MCP 读取图片、图标等素材。你会发现Skills 负责“怎么干活”MCP 负责“能拿到什么”两者配合才能让同一个流程在不同设计稿、不同时间里稳定复现。3. 到底什么时候该用 Skills什么时候该用 MCP判断入口不是工具是任务3.1 先回答一个问题当前任务缺的是什么选型不用先看工具先看任务拆解。把任务拆开之后问自己两个问题这个任务里模型是不是需要访问外部系统、实时数据、第三方服务或当前对话里不存在的信息这个任务里模型是不是需要遵循一套特定的方法、步骤、规范或输出格式如果第一个问题的答案是“是”你需要考虑 MCP。如果第二个问题的答案是“是”你需要考虑 Skills。两个答案都是“是”就两个都用。两个答案都是“否”那当下可能什么扩展都不用加直接用基础模型能力就够了。3.2 优先用 Skills 的场景下面这些场景通常优先考虑 Skills因为它们核心是“知识、方法、规范”生成代码时需要遵守团队目录结构、命名规范、代码风格。写文档、写测试、写提交信息时需要有固定的格式和质量标准。处理某类任务时需要遵循固定排查路径比如先看输入再看环境再看日志。需要沉淀某个领域的经验比如后端项目从零生成 Spring Boot 3 代码时要求按固定模块拆解。需要给 Agent 提供历史项目中“什么是对的”的参照示例。Skills 的优点是轻量、灵活、能快速迭代。你不需要启动一个服务不需要维护接口权限只需要改一个 Markdown 文件就能改变 Agent 的工作方式。3.3 优先用 MCP 的场景下面这些场景通常优先考虑 MCP因为它们核心是“连接、数据读写、系统操作”需要读取设计稿比如 Figma、蓝湖里的布局和标注。需要查询数据库比如让 Agent 根据自然语言生成并执行 SQL然后返回结果。需要操作浏览器比如用 Playwright MCP 做端到端测试。需要访问外部业务系统比如支付接口、SSH 远程服务、内部管理系统。需要读取文件、搜索代码仓库、操作 CI/CD 流程。MCP 的价值在于它把“访问能力”标准化了。一个团队可以把某个数据库封装成 MCP Server然后让不同的 Agent、不同场景复用同一个连接能力。3.4 需要叠加使用的场景实际工作流里很多任务既需要外部连接也需要内部规范。比如用 Playwright MCP 做前端自动化测试时同时需要测试规范类 Skills 来规定用例命名、断言写法、报告格式。在 Dify 这类平台里配置 Agent 流程时可能需要通过 MCP 接入本地服务读取业务数据同时用 Skills 或提示词来约束 Agent 的对话节奏和回答结构。让 Agent 做数据库巡检时用 MCP 访问数据库用 Skills 规定巡检项、异常判断标准和报告输出方式。这也是为什么很多人纠结“Skills vs. MCP”因为在真实配置里它们经常是同时存在的。判断维度优先用 Skills优先用 MCP核心问题模型知道怎么做吗模型能碰到数据和工具吗典型内容步骤、规范、示例、模板数据库、设计稿、浏览器、支付、SSH修改方式改文件、改提示词配置 Server、维护接口和权限失败表现输出不符合预期、风格混乱调用失败、拿不到数据、上下文过大典型工具Claude Code Skills、Codex 提示词、项目规范文档Figma MCP、Playwright MCP、数据库 MCP Server4. 真正容易踩的坑把流程塞进工具把工具写进流程4.1 把任务流程硬编成 MCP Server新手最容易犯的错误之一是觉得“MCP 更强大”于是把任务流程也塞进 MCP Server 里。比如想做一个“从设计稿生成前端代码”的能力不是写一个 Skills 来规定步骤而是试图写一个 MCP Server让它内部去完成整条生成链路。这样做的问题在于MCP 的设计初衷是提供工具和数据访问而不是替模型思考。把流程强塞进 Server 端会让 MCP Server 变得非常重而且很难复用。设计稿生成页面的流程换一个团队规范就要改 Server测试流程变化了又要改 Server。从工程经验看MCP Server 更适合保持“原子的工具能力”读一个文件、查一条数据、执行一次操作。至于怎么把多个操作串成一个完整任务那是模型配合 Skills 要做的事。4.2 把工具调用写死在 Skills 里另一个相反的错误是在 Skills 里写死具体的工具调用方式比如把某个 API 地址、某个数据库连接方式直接写进 Skills 文件。表面上看这也没什么问题因为模型可以按照 Skills 里的说明去调用工具。但一旦工具变更、接口升级、服务器地址变化你就需要去改 Skills 文件而且可能每个相关 Skills 都要改一遍。更好的做法是Skills 里只描述“你需要读取设计稿数据”和“数据字段大概包含什么”真正怎么连接、怎么认证、用什么服务交给 MCP Server 处理。这样 Skills 关注的是业务方法MCP 关注的是连接实现两者边界清晰维护起来才不会互相牵连。4.3 上下文过大的常见入口很多人遇到上下文过大、频繁自动总结但还是超限的问题第一反应是“是不是我对话太长”。但在 Agent 配置场景里另一个常见原因往往被忽略MCP Server 返回的数据量过大。比如数据库 MCP 执行了一条没有限制条数的查询把整张表都返回回来或者文件读取 MCP 一次性把一个大文件塞进上下文或者设计稿 MCP 返回了大量不需要的图层数据。这些内容会迅速撑爆上下文窗口。Skills 也可能是元凶。如果一个 Skills 文件写得非常长又总是在任务开始时被整体加载它同样会占用大量上下文。所以排查上下文问题时不能只看对话长度还要看MCP 返回的数据有没有做裁剪。查询有没有加 LIMIT。读取文件时有没有按行数或范围截断。Skills 文件是否足够精简。Skills 是否每条消息都加载还是只按需触发。4.4 一条可复用的排查链路如果你遇到一个问题不确定是 Skills 还是 MCP 引起的我建议按下面这个顺序排查先看现象。是报错、卡住、无输出、输出异常、速度慢还是上下文溢出现象直接决定排查方向。再看输入。传给模型的数据是哪里来的如果是 MCP 返回的数据先看返回内容本身是否正常、是否过大。如果输入没问题再看下一步。再看配置。MCP Server 是否成功启动token、权限、路径、依赖版本是否都正确Skills 文件有没有语法问题描述是否足够清晰是否被正确触发再看运行环境。命令是在哪个目录执行的环境变量是否注入本地服务端口是否被占用系统差异有没有影响最后看设计边界。是不是这个任务根本不适合用 MCP或者这个流程根本不该由 Skills 来约束如果方案本身选错了调再多参数也没用。注意不要一上来就调参数。先确定问题发生在“连接层”还是“行为层”否则你会在错误的层里浪费很多时间。5. 一个可复用的三层选型框架5.1 第一层是否需要访问实时外部系统拿到一个新任务先看第一层任务完成后是不是必须用到当前对话里不存在的信息或者需要真实操作系统里的资源如果答案是“是”那么 MCP 的方向基本确定了。你需要进一步判断是不是已经有现成的 MCP Server 可以复用如果没有是不是值得自己写一个 MCP Server如果只是偶尔用一次是不是可以用文件导入、截图、复制粘贴等方式先临时解决常见实践里我会先尽量复用现成的 MCP Server比如设计稿类、浏览器类、数据库类。只有当现成能力确实不满足才考虑自建。5.2 第二层是否需要固化行为方式再看第二层这个任务是不是对“怎么完成”有明确要求比如团队要求代码必须符合某种风格测试必须覆盖某些维度文档必须按固定章节输出。如果是那你需要的是 Skills 这类流程层约束。写 Skills 的时候有几个建议不要写成“请生成高质量代码”这种空话要具体到步骤和判断标准。每个步骤之间要有明确的输入输出。加上反例或边界说明告诉模型什么情况下不要做。定期根据实际输出效果迭代 Skills 内容。Skills 不是一次写完就结束的。它会随着团队规范变化、项目结构调整、踩坑经验增加而持续修改。5.3 第三层是否需要沉淀独立工具层再往上一层看这套能力是只在这个项目里用还是会被多个项目、多个 Agent、多条流程复用如果只在一个项目里用先不要急着做独立的 MCP Server。你完全可以在项目里配置一个轻量 MCP或者先用现成工具组合解决。如果多个团队、多个 Agent 都要用到同一个数据库、同一套设计稿读取能力、同一个浏览器操作能力那就值得把它沉淀成独立的 MCP Server把认证、权限、日志、错误处理都做好。这就像一个团队先有一份操作手册后来发现很多部门都要用同一套设备才去把设备统一成标准接口。5.4 什么时候先别急着做任何扩展不是所有任务都需要 Skills 或 MCP。有时候最合理的做法是什么扩展都不加。比如你只是临时做一次实验没有打算长期复用。任务本身没有明确的方法论输出质量还处于探索阶段。你还不清楚目标系统有哪些数据、哪些权限、哪些限制。工具或接口还在频繁变更现在就封装可能很快就过时。在这些情况下我建议先用最原始的方式把流程跑一遍手动给模型足够的上下文手动贴数据手动纠正输出。等你对流程足够了解再考虑沉淀成 Skills 或封装成 MCP。阶段建议做法目标临时验证手动给上下文、贴数据、贴示例确认任务可以被完成高频使用写 Skills 固化流程和规范让输出稳定、可复现多场景复用封装 MCP Server 提供标准工具能力让能力跨项目和 Agent 复用长期维护补充日志、权限、错误处理、版本管理降低维护成本6. 长期视角这不是二选一而是两层能力6.1 Skills 会越来越像岗位说明书随着 Agent 进入真实工作流Skills 会越来越像“岗位说明书”或“标准作业程序”。它表达的是一个人或者一个团队希望 Agent 以什么方式工作。它不只是在告诉模型“做什么”更重要的是在告诉模型“什么算好”。这个标准很多情况下只有长期做这类业务的人才能提炼出来。所以 Skills 的沉淀过程本质上是把团队经验转化为可执行文档的过程。6.2 MCP 会越来越像标准接口层MCP 则会更像“标准接口层”。它的目标是让工具和数据访问变得通用、统一、可插拔。一个企业的数据库、支付系统、设计资源、内部系统如果能以标准 MCP Server 的方式暴露给 Agent那么不同 Agent、不同场景、不同模型都可以用同一套协议去连接。这种标准化带来的价值是单个 Skills 无法替代的。6.3 对开发者和团队的实际影响对开发者来说最需要练的能力不再是“记住某个工具的参数”而是判断一个需求到底属于哪一层是行为层的问题就通过 Skills、提示词、规范文档来解决。是连接层的问题就通过 MCP Server、API、数据源来解决。是两者边界不清的问题就先梳理流程再决定沉淀方式。对团队来说更合理的组织方式是把这两层分开维护。Skills 由最懂业务的人维护MCP Server 由最懂系统和工具的人维护。这样业务规范的更新不需要动工具层工具接口的升级也不需要改业务流程。6.4 回到最开始的那个判断所以Skills vs. MCP 这个提问方式已经过时了。更准确的提问方式应该是我在配置的这条工作流里哪一部分需要模型更懂方法哪一部分需要模型能触达真实系统下次再有人问“这个能力到底是用 Skills 还是用 MCP”我通常会反问一句你手里的 Agent 现在是不懂怎么做还是够不到需要的东西想清楚这个问题选型基本就出来了。剩下的才是配置和调优的事。