去年年底我在一个内部项目里被一个问题卡了很久Claude明明能写代码、能改文件可一旦让它去“操作”Figma设计稿、去“查询”线上数据库它就变成只会给建议、不会动手的“嘴强王者”。后来我把MCP Server接进去问题解决了一半但AI依然偶尔把工具用得很笨。直到我把Skills也补齐才算真正把Agent从“能用”推到“好用”。这篇东西就是围绕这条“从MCP到Skill”的落地链路写的适合正在做Agent开发、想在Claude Code或类似工具里接入外部能力的开发者也适合那些对MCP和Skill概念还比较模糊、想一次性搞清楚边界的人。1. 从一次失败的“AI改前端”任务说起1.1 没接MCP之前AI只是在“纸上谈兵”当时团队接了一个官网改版需求设计师把Figma里的间距、颜色、字体都调好了剩下的活是让前端照着实现。我偷懒试了一下让Claude直接改样式结果它回复了一堆“你可以打开Figma看节点”“建议手动检查设计规格”之类的话。不是Claude笨而是它根本没有访问Figma的通道所有信息只能靠我粘贴过去的截图和描述。这个阶段的核心问题在于大模型本身只是一个“文本进、文本出”的系统。它能理解我贴过去的HTML和CSS也能给出很合理的修改建议但它无法读取设计稿的原始数据无法调用公司内部的接口也无法直接操作浏览器做验证。说白了模型有了“大脑”却没有“手脚”。所以早期做Agent的人会做一件事给模型套一层Function Calling把工具封装成一个又一个函数让模型在生成回复时顺便输出“要调用哪个函数、参数是什么”。这个方法能解决一部分问题但每个工具都要单独写一套接口约定换一个模型或者换一个前端框架对接逻辑就可能全废。1.2 接上MCP之后AI才真正开始“动手”后来我发现Figma官方提供了MCP Server装好之后在Claude Code里配置一条命令AI就能直接读取设计稿的节点结构、导出CSS变量、拿到标注信息。记得第一次让它读取一个按钮组件时Claude直接把背景色、圆角、字体大小全列出来了还顺手生成了对应Tailwind类名。那一刻的感受是模型终于长出了手。MCP的引入其实改变了Agent开发的底层思考方式。以前我们想的是“我有哪些工具要不要封装成API”现在变成“模型需要什么上下文、需要执行哪些动作我用MCP把这些能力标准化地暴露出去”。AI要读数据库就通过数据库MCP要操作浏览器就通过Playwright MCP要改Blender模型就通过Blender MCP工具不再是散落的代码片段而是统一协议下的“即插即用”模块。1.3 有了工具还不够Skill补上“怎么用好”但很快我又遇到第二个问题MCP给了AI一把扳手可AI有时候不知道拧哪颗螺丝。比如它确实能调用Figma MCP的接口但面对一个设计规范复杂的项目它不知道该读取哪些节点、该优先处理哪些样式冲突它能调用Playwright打开页面却不知道测试用例该怎么组织经常会跑出一些低价值的检查。这就是Skill存在的理由。Skill不是给模型加新的工具而是给模型一份“该怎么做”的操作指南。它告诉Agent在这种场景下第一步看什么、第二步查什么、遇到什么情况要怎么处理。把“会用工具”升级成“会干活”靠的就是Skill这一层。所以你现在去捋新一代智能体开发的体系会发现它们其实是分工明确的MCP解决“能力接入”Skill解决“能力使用”Agent本体解决“任务规划和执行调度”。三者没有谁替代谁而是层层叠加的关系。2. MCP的底层逻辑给AI一个标准化的“万能插座”2.1 一句话理解MCP的工作方式如果你用过USB-C大概能理解MCP为什么让整个生态都兴奋起来——它就是AI世界的USB-C。在MCP出现之前每个AI应用想接入一个外部工具都要自己写一套适配逻辑模型供应商、工具方、前端框架各说各话集成成本很高。MCP统一了这些接口规范让AI宿主比如Claude Desktop、Claude Code、Cursor按照同一套标准去连接任意MCP Server。整个链路大概是这样的宿主应用MCP Client负责和模型交互去调用MCP Server暴露出来的能力MCP Server是一个本地或远程服务里面定义了这个工具能做什么、需要什么参数两者通过JSON-RPC方式通信模型在生成内容时如果判断需要某个工具就会构造一条工具调用请求发给ServerServer执行完把结果再返回给模型。我在项目里最常用的方式是本地运行MCP ServerClaude Code通过stdio方式和它通信。这样Server不需要部署到公网数据也不会被第三方中转权限边界很清晰。2.2 Tool、Resource、Prompt三类原语分别解决什么问题初次接触MCP协议时很多人会把所有能力都塞进工具Tool里其实MCP还定义了两个同样重要的原语Resource和Prompt。理解了这三者的区别你的MCP Server设计思路会清晰很多。原语作用场景举例Tool执行动作主动调用有副作用发送HTTP请求、执行Shell命令、修改文件Resource暴露数据供模型读取上下文读取日志文件、获取数据库模式、查看设计稿节点Prompt提供可复用的提示词模板引导模型完成任务一套标准化的Bug分析流程、周报生成模板我第一次写MCP Server的时候把所有东西一股脑做成Tool结果Agent经常需要自己拼参数用起来很别扭。后来把“读取项目配置文件”改成Resource“一键生成周报”改成Prompt模型的理解成本和调用准确率都明显提升。2.3 MCP和Function Calling、传统插件生态的区别有人问MCP不就是Function Calling的升级版吗某种程度上可以这么说但差异在于抽象层级。Function Calling是模型厂商提供的一套API规范你定义一个参数Schema模型输出结构化调用这套东西和厂商绑定很紧。MCP则是在“模型”和“工具”之间加了一层独立的协议层工具方只需要实现一次MCP Server就能被所有支持MCP的客户端使用不用为每家模型单独适配。传统IDE插件也是类似的思路但插件通常深度绑定编辑器生命周期扩展点由编辑器厂商定义。MCP更轻量、更通用一个Server可以被Claude Code、桌面版、甚至你自己的Web应用同时连接。这也是为什么这半年各路工具都在快速补MCP支持因为它把“工具接入成本”拉到了一个非常低的位置。3. Skill的定位把“会调用工具”升级成“会干活”3.1 Skill的本质是一份给Agent看的“作业指导书”我后来给团队内部写了一份前端开发Skill结构很简单一个文件夹里面放SKILL.md外加几个参考文件。SKILL.md用Markdown写成内容包含这个Skill的适用场景、使用步骤、关键规则和示例。Claude在对话过程中会根据任务描述自动判断要不要加载这份Skill加载后就相当于有了一位“老师傅”在旁边指点。这种感觉怎么描述呢就像你去一个新公司虽然办公软件都会用但如果没有SOP你还是不知道报销流程怎么走、代码评审找谁。Skill就是Agent的SOP把“做某类任务的隐性经验”显式化、文件化让模型下次遇到相似场景时可以复用。而且Skill不需要是大型的复杂系统小到“如何生成符合团队规范的Git提交信息”都可以做成一份Skill。我见过很多团队把常用的代码审查规则、数据库查询规范、文档写作风格都沉淀成Skill文件效果立竿见影。3.2 一个Skill的内部结构长什么样以我写的一个“前端代码审查Skill”为例code-review-skill/ ├── SKILL.md ├── rules/ │ ├── react-best-practices.md │ ├── css-variables.md │ └── performance-checklist.md └── examples/ ├── bad-component.tsx └── good-component.tsxSKILL.md的开头会有清晰的YAML元信息包括name和descriptiondescription尤其重要因为Claude就是靠它来判断该Skill在什么情况下被加载。正文部分会写清楚工作流程比如“先读package.json确认技术栈再按rules下的清单逐项检查如果发现问题给出修复建议”。我自己的经验是示例文件比空泛的规则更有用。Claude是少样本学习给它一个“差代码”和“好代码”的对照它就能非常准确地理解你期望的审查标准。如果只写“要遵循最佳实践”最终结果往往很泛。3.3 现成Skill推荐Superpower Skills与实用场景如果你不想从零开始写社区里已经有不少成熟的Skill包可以直接用最出名的是Superpower Skills。这套Skill把写作、阅读、研究、编程辅助这些常见任务都做了优化安装之后Claude在处理这些任务时明显更“有章法”。拿Superpower里的写作类Skill来说它内置了“任务规划-素材收集-初稿生成-自我修正”的完整流程模型不再是直接甩一段文字而是先和你对齐目标、列提纲再逐步输出。这个过程对复杂任务特别重要因为大模型一口气生成长文时很容易跑偏分阶段执行能有效降低出错率。不过我也要提醒一句不要迷信Skill包越多越好。Skill文件多了以后Claude可能会在无关任务上加载错误Skill反而拖慢响应。我一开始装了好几套热门Skill后来发现很多场景根本用不上还经常出现“检查节奏被打乱”的情况。现在我的原则是按真实业务场景挑选一个领域只保留一到两个核心Skill。3.4 我踩过的Skill坑描述含糊导致AI乱用第一次写Skill时我在description里写了“帮助用户解决前端开发相关问题”结果Claude什么前端问题都去加载这个Skill里面针对组件规范的流程和样式调整的任务根本不匹配经常出现答非所问。后来我改成了“用于React项目组件开发与代码评审读取项目结构后按团队规范进行检查并输出修改建议”加载精准度明显高了。另一个坑是Skill内容写得像文档而不是操作手册。大段大段的背景介绍、原理说明Agent读完反而抓不住重点。正确做法是写“步骤化的指令”第一步做什么、第二步做什么、每一步的输入输出是什么。Agent不是人它没有能力去“领悟”你的长篇大论你需要把经验压缩成一条清晰的操作链路。4. 实战用Claude Code把一个MCP Server跑起来4.1 环境准备从安装到配置在正式做MCP开发之前我建议先把Claude Code装好。目前最常用的安装方式是通过npmnpm install -g anthropic-ai/claude-code安装完以后在终端执行claude就能进入交互式编程环境。这个工具本身就可以作为MCP Client你要做的就是把MCP Server的配置告诉它。配置MCP Server有两种方式一种是项目级配置在项目根目录放一个.mcp.json另一种是用户级配置通过claude mcp add命令写入全局配置。我在团队项目里倾向于用.mcp.json因为它可以跟代码仓库走队友拉下来就能直接用。需要特别注意的是Windows环境。有些人在Windows上安装Claude Code后启动时会看到类似“Claude’s workspace requires the virtual machine platform on Windows”的报错这是因为Claude Code在Windows上依赖虚拟机平台相关的组件。解决方法是到控制面板的“启用或关闭Windows功能”里勾选“虚拟机平台”然后重启电脑。我当时在这个问题上卡了差不多半小时最后发现就是缺了这个系统功能。4.2 一个最简单的MCP Server实现下面我用Python的fastmcp库写一个简单的MCP Server功能是查询指定Git仓库最近N天的提交记录生成一份周报素材。这个工具看起来很基础但在团队日常里非常实用。from fastmcp import FastMCP import subprocess from datetime import datetime, timedelta mcp FastMCP(GitReportServer) mcp.tool() def get_git_log(repo_path: str, since_days: int 7) - str: 获取指定仓库最近N天的提交记录用于生成周报。 Args: repo_path: Git仓库的本地路径 since_days: 要追溯的天数默认7天 since (datetime.now() - timedelta(dayssince_days)).strftime(%Y-%m-%d) result subprocess.run( [git, log, f--since{since}, --prettyformat:%h|%an|%s, --dateshort], capture_outputTrue, textTrue, cwdrepo_path, ) return result.stdout mcp.resource() def git_repo_status(repo_path: str) - str: 读取Git仓库的当前状态信息。 result subprocess.run( [git, status, --short], capture_outputTrue, textTrue, cwdrepo_path, ) return result.stdout or 工作区干净没有未提交的变更。 if __name__ __main__: mcp.run()启动这个服务很简单先安装依赖pip install fastmcp然后运行脚本python git_report_server.py这个Server默认通过stdio和Client通信当你把它的命令配置进Claude Code后模型就能调用get_git_log这个工具获取提交记录再配合一个“周报生成Skill”输出结构化周报整个流程完全可以自动化。4.3 引入SSE流式输出和中断控制让交互更贴合实际使用MCP解决的是Agent的工具调用问题但如果你在做的是Web端Agent应用还有一个绕不开的点模型输出的实时渲染。我见过很多人在后端调了大模型接口然后用await等完整结果最后一次性推给前端。这个方案在简单对话里还能忍但在Agent执行多步任务时用户体验奇差。正确的做法是用SSEServer-Sent Events做流式输出。后端在生成过程中把每个增量片段主动推给前端前端逐段渲染用户能看到模型“思考”和“打字”的过程。下面是一段前端对接SSE的示例const controller new AbortController(); const response await fetch(/api/agent/chat, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ message: 帮我生成一份本周工作总结 }), signal: controller.signal, }); const reader response.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value, { stream: true }); // 解析SSE数据帧追加到对话区域 renderChunk(chunk); }代码里的sinal: controller.signal就是给请求挂了一个AbortController用户点击“停止生成”按钮时执行controller.abort()前端会立即断开连接后端也会收到中断信号停止继续生成。这个能力在多轮Agent交互中非常重要因为模型一旦进入错误的执行路径及时中断能帮你省下大量时间和Token。4.4 常见报错排查连接失败、工具未发现、Windows虚拟化问题实战中不可避免会遇到报错我在下面整理了一张排查表也标注了我自己遇到时的处理经验。报错现象可能原因处理方法MCP Server连接超时Server地址写错、网络不通、防火墙拦截先用命令行手动启动Server确认端口或stdio能正常输出日志工具未发现Server已连接但Tool未加载或配置的name不匹配在Claude Code里执行claude mcp list查看实际加载的工具列表调用工具后返回空结果Server侧抛异常错误信息被吞掉了在Code中加try/except并打印完整异常先用独立脚本测试函数本身Windows提示需要虚拟机平台系统功能未启用控制面板-启用或关闭Windows功能-勾选“虚拟机平台”重启权限不足拒绝写入目录Claude Code运行的目录权限受限确认项目目录不在受保护的系统目录下或给Server配置合适的工作目录排查问题时我养成了一个习惯先在Server端打印完整日志再去Client看配置文件。很多看起来像是“MCP配置有误”的问题实际上都是Server端代码抛了异常被MCP SDK静默吞掉了。5. 真实工作流MCP加上Skill提升效率的三种组合打法5.1 前端开发场景Figma MCP加前端开发Skill前端接设计稿应该是我见过收益最明显的场景。Figma MCP让Claude可以直接读取设计稿中的图层、样式、布局信息等于把“视觉效果”变成了机器可读的数据。再配上一份前端开发Skill规定好“拿到设计稿后先梳理颜色变量、再拆组件结构、最后生成响应式布局”整个从设计到代码的流程就能串起来。实际操作中我在Claude Code里让Agent“把Figma设计稿的第一屏实现成React组件”它会先通过Figma MCP拿到节点树再根据前端Skill里的规范生成Tailwind类名还会主动检查组件拆分是否合理。这一套组合下来基础页面的产出速度比我手动写快了好几倍。团队内部如果有自己的组件库可以把组件的使用规范写进Skill让AI生成代码时自动匹配现有设计系统。蓝湖MCP也是类似逻辑。国内团队如果设计稿沉淀在蓝湖接上蓝湖MCP后同样能把这些标注数据直接给到Agent减少来回截图沟通的成本。关键是看你们的资产在哪一侧哪一侧就接哪侧的MCP。5.2 浏览器自动化场景Playwright MCP控制真实浏览器另一个高频应用是浏览器自动化官方提供的Playwright MCP可以直接让Agent打开浏览器、操作页面、截图、读取控制台日志。我拿它做端到端回归测试效果很好。以前写自动化测试要一行行写脚本现在只需要给Agent一句话“打开登录页输入测试账号截图确认登录成功然后跳到设置页检查默认选项”它会自己调用Playwright MCP去执行。为了让执行更稳定我会单独写一个“测试执行Skill”要求Agent每一步都记录截图和日志遇到弹窗先尝试关闭再做断言。没这份Skill时Agent经常打开页面等都不等就直接操作导致测试脚本不稳。5.3 创意设计场景Blender MCP与3D资产联动如果你觉得MCP只适合写代码那就低估它了。Blender MCP是一个非常极客的例子MCP Server跑在本地通过Socket和Blender通信AI能读取3D场景里的物体列表、修改材质参数、执行建模命令。我试过让Claude在Blender里生成一个低多边形的小房子它真的能拆解成“先创建立方体、再缩放拉伸、最后加材质”的步骤一步步操作出来。这个场景背后有三层依赖Blender MCP提供了操作通道Claude负责把文字指令翻译成API调用序列而“正确的建模顺序”其实需要一份3D建模Skill来约束。没有Skill时Claude会用很绕的方式建模有了Skill它就会按标准流程来。这说明在创意工作流里MCP加Skill的分工依然成立。5.4 本地部署大模型的取舍与配置参考聊到Agent开发就绕不开模型选择。很多团队因为数据隐私或成本顾虑倾向于本地部署大模型。用GGUF格式加Ollama是当前比较主流的一条路径配置门槛也不高。本地部署最大的好处是数据不出内网推理链路自己可控适合处理敏感业务数据但代价是模型规模受限显存需求很现实。以7B到14B的量化模型为例7B Q4量化通常需要6GB到8GB显存14B Q4量化基本要10GB以上这还只是推理需求。做Agent任务时模型还需要理解工具调用、遵循多步指令小参数模型在这些场景下明显吃力。所以我的建议是优先用云端API跑复杂Agent任务本地模型用在数据敏感、任务逻辑固定的小场景里。部署相关问题可以参考Ollama社区里针对不同显存规模的推荐配置实测下来比盲目追求大参数更靠谱。6. 我自己的选型原则与建议6.1 什么项目适合MCP什么场景更需要Skill根据我半年多的使用经验MCP和Skill的投入优先级取决于你当下的瓶颈在哪。如果你的Agent连接不了任何外部系统只能靠手工复制粘贴喂数据那当务之急是接MCP。挑一个价值最高的工具先接比如数据库或浏览器把一个核心链路跑通。如果你已经接了不少MCP工具但Agent干活质量还是不稳定那问题大概率出在Skill缺失上。这时候不要急着接更多工具先沉淀一份针对高频任务的操作手册让模型知道工具该怎么组合使用。我见过不少团队反着来装了十个MCP Server但没有任何Skill文件结果AI每个工具都会用却经常用得很肤浅。这个状态很像一个所有工具都摆在桌上但没人教流程的新人效率根本起不来。6.2 团队协作时配置文件和Skill怎么管理MCP配置和Skill文件都应该进版本库。我会在项目根目录维护一个.mcp.json里面只放团队通用的工具个人调试用的Server通过claude mcp add加到用户级避免污染公共配置。Skill文件则单独放到一个skills目录和代码放一起评审代码时顺便评审Skill内容。安全也是必须考虑的。MCP Server尽量遵循最小权限原则能给只读权限就不给写入权限能在本地跑就不暴露到远程。尤其是浏览器自动化和数据库操作的MCP权限开得太大Agent一旦被Prompt Injection诱导后果可能很难收拾。我在生产环境只开放白名单指令集比如数据库MCP只允许执行SELECT查询写操作全部走人工审批。6.3 几条让我少走弯路的实操心得最后分享几条心得每一条都是用时间换来的。第一不要一上来就搞复杂架构。先写一个极简的MCP Server比如一个查天气的小工具把它跑通再去看原理。协议这东西光看文档很容易飘真正按一次链路走下来很多概念自然就通了。第二Skill要小而专。一份Skill最好只覆盖一个明确的任务域。我见过把“代码审查、文档生成、测试编写”都塞进一份Skill的情况结果模型每次都要读一堆无关内容响应变慢准确率也下降。拆成多个小Skill让Claude按需加载效果反而更好。第三日志意识要强。调试MCP时开启日志能省一半时间。Claude Code里有调试模式MCP Server也尽量把每次调用的输入输出打出来。很多时候AI表现“奇怪”不是模型问题而是你的Server返回了意外数据模型只能基于错误数据继续发挥。第四如果你想跟上社区多关注官方示例和热门工具仓库的更新。MCP协议本身还在快速演进Skill的写法也在不断优化隔几个月就会有新思路出现。自己从零摸索当然可以但站在别人的实践上迭代显然更快。
