做Agent开发有一段时间了有个感受越来越明显大模型本身再强不把“工具调用”和“经验沉淀”这两件事做好做出来的Agent永远停留在“聊天机器人”阶段。很多人问我为什么别人做的Agent能自动查资料、操作浏览器、改代码、出报告而我调了半天API效果还是差一大截差别基本都出在MCP和Skill这两个能力上。MCP解决了Agent“手不够长”的问题Skill解决了“脑子里的经验不够用”的问题这两者结合才是新一代智能体开发的核心玩法。这篇文章我打算把从MCP到Skill这条技术路径完整梳理一遍。不管你是刚接触AI大模型应用开发的新手还是已经用过Claude这类工具但没搞懂底层原理的进阶玩家应该都能从中找到可以直接抄作业的配置方案和踩坑经验。1. Agent能力体系的整体认知从“会聊天”到“会干活”1.1 大模型的本质局限与Agent的价值先聊一个底层问题。我们天天说大模型但拆开看大模型实际上就是一个“根据前文预测下一个词”的概率模型。你问它“帮我查一下今天上海的天气”它能生成一段看起来通顺的回复但它并不知道真实天气因为它没有联网能力。你让它“把这份Excel里的数据做个透视表”它能写出操作步骤但它没有访问你本地文件的权限更不会真的去操作Excel。这就是大模型的能力边界。它不是“不会”而是“够不着”。让大模型真正去执行任务就需要一层中间件——Agent。Agent负责拆解任务、调用工具、观察结果、调整策略就像一个“调度员”把大模型的文本生成能力和外部的工具、数据源、软件操作对接起来。我见过不少项目把大模型API接上就声称做了Agent实际只做了个对话接口没有任何工具调用和任务规划能力。这种“伪Agent”在demo里还能跑一放到真实场景就废了。真正的Agent至少要具备四个要素任务规划能力、工具调用能力、记忆能力、反馈循环。而MCP和Skill一个管“工具怎么接”一个管“经验怎么存”正好命中前两个要素。1.2 MCP给Agent装上一排“万能插座”MCP的全称是Model Context Protocol模型上下文协议。这是Anthropic在2024年底推出来的开放协议目的很直白统一大模型连接外部工具的方式。在MCP出现之前每个Agent要对接一个工具就得写一套适配代码。你要接GitHub、接Slack、接数据库每一个都是独立的实现维护成本高到怀疑人生。MCP把这事做成了“插座和插头”的标准化。MCP Server负责把某个工具的能力暴露出来MCP Client负责跟这些Server通信大模型只需要按照统一协议去调用就行。我举个例子你给Claude配置了一个文件系统的MCP ServerClaude就能直接读取你电脑上的文件配置一个浏览器自动化的MCP Server它就能操控浏览器执行点击、填表、截图。整个过程对大模型来说像“插上就能用”不需要关心背后的实现细节。MCP支持stdin/stdout和SSE两种传输方式。前者适合本地工具直接通过进程间通信完成后者适合远程服务通过HTTP和Server-Sent Events建立连接。后面我会详细讲配置这里先建立一个认知MCP是Agent连接外部世界的“万能插座”。1.3 Skill把“熟练工”的手法和行业经验固化下来如果说MCP解决的是“外部工具”的问题那Skill解决的就是“内部经验”的问题。Skill本质上是一组结构化的指令、示例、脚本和参考资料的集合它告诉模型“面对这类任务你应该按照什么流程去做”。举个例子。同样是让Claude帮你写一份周报没有任何Skill的情况下模型会按照自己的理解写一篇通顺的周报但格式可能不符合公司模板、数据可能不够结构化、措辞可能不够专业。而如果你给模型加载了一个“周报写作Skill”这个Skill里包含了你们公司的周报模板、过往优秀周报的示例、写周报时需要注意的评分标准模型就会按照这套标准来产出效果立竿见影。市面上很多热门的Skill比如仓颉Skill针对特定编程语言的项目生成、Workbuddy Skill编排工作流、Codex Skill编码辅助等本质上都是把某类任务的执行经验封装成了可复用模板。你可以把Skill理解成“给模型的一本岗位操作手册”模型每次接到任务时先翻手册再动手干。1.4 Agent MCP Skill三者各司其职想把这套体系用好得先理清三者的关系。我常用一个比喻来理解Agent是“大脑”负责规划和决策MCP是“手脚”负责执行具体操作Skill是“职业培训手册”负责让大脑知道“这个行业的活儿应该怎么干”。一个典型的工作流是这样的用户给Agent下达一个任务Agent先识别任务类型匹配到合适的SkillSkill提供了一套执行流程和模板执行过程中需要查询数据、操作外部系统Agent就通过MCP调用对应的Server拿到结果后再按照Skill的格式要求组织成最终输出。比如你让Agent“根据设计稿生成一个登录页面的前端代码”。Agent先匹配到“前端开发Skill”Skill里规定了组件库、代码风格、目录结构然后Agent通过Figma MCP读取设计稿的标注信息再通过蓝湖MCP获取切图资源最后按Skill的规范写出代码。整个过程没有MCP就拿不到设计稿数据没有Skill产出的代码就四不像。两个能力缺一不可。2. MCP协议的深度拆解与实战配置2.1 MCP核心概念与工作模式MCP协议的核心模型是“客户端-服务器”架构。MCP Server暴露三类原语能力Tools、Resources、Prompts。Tools是可执行的操作比如“发送HTTP请求”“查询数据库”Resources是可读取的上下文数据比如“用户的配置文件”“项目的README”Prompts是预先定义的提示模板可以引导模型按特定方式完成任务。这三类能力各有分工。Tools是动词要让模型“去做某事”Resources是名词给模型“提供背景信息”Prompts则是“套路”告诉模型“这种场景下应该怎么开口”。在传输层MCP目前主推两种模式。第一种是stdio模式MCP Server作为一个本地子进程运行MCP Client通过标准输入输出和它通信。这种模式适合文件系统访问、本地数据库操作这类场景配置简单没有额外的网络开销。第二种是SSE模式Server运行在远程服务器上Client通过HTTP的SSE通道接收消息。远程API服务、共享工具中心这类场景用SSE更合适。从实际体验来看本地开发环境首选stdio生产环境部署Agent服务时再考虑SSE。我之前图省事把一个本地的MCP Server配成了SSE模式结果每个请求都要走一遍HTTP握手和鉴权响应速度慢了不少后来改成stdio才恢复正常。2.2 常用MCP Server选型与能力对比MCP社区目前已经有大量现成的Server覆盖了开发、设计、办公、数据等多个领域。我把自己实测过的几个整理成了表格方便大家选型。Server名称能力范围典型使用场景传输方式配置复杂度Playwright MCP浏览器自动化操作网页截图、表单填写、数据抓取、UI测试stdio低Figma MCP读取Figma设计稿信息从设计稿提取组件、样式、标注给开发用SSE/本地中蓝湖MCP设计稿标注与切图资源获取在Trae等AI编码工具中获取蓝湖设计数据SSE中Filesystem MCP本地文件系统读写让Agent读取/写本地文件stdio低GitHub MCP仓库、Issue、PR操作Agent自动处理仓库事务SSE中Database MCP数据库查询与操作Agent直接基于数据库生成分析报告stdio高说说我实际使用的一些感受。Playwright MCP是我日常使用频率最高的一个因为浏览器的通用性太强了——让Agent打开一个网页自动提取结构化数据截图留存全程不需要我再手写Playwright脚本效率提升非常明显。Figma MCP和蓝湖MCP适合设计师和前端开发配合的场景设计师在设计工具里把界面画好Agent直接从设计稿抽取样式和尺寸信息生成代码这个流程跑通后切图标注的沟通成本几乎降为零。GitHub MCP则是“开源维护党”的福音整理Issue、创建PR、触发CI这类重复操作直接交给Agent。选MCP Server时还有一个原则优先选社区维护活跃、文档齐全的。MCP生态更新实在太快了一个Server如果三个月不更新很可能就跟不上协议版本出现各种兼容性问题。2.3 MCP Server在Claude Code中的配置实操说到MCP的实际应用就绕不开Claude Code。这是Anthropic推出的终端编程工具可以直接在命令行里让Claude帮你写代码、运行测试、提交Git。Claude Code原生支持MCP协议配置起来很方便。第一步全局配置。在项目根目录执行下面的命令把MCP Server添加到Claude Code的配置里claude mcp add playwright-server -- npx playwright/mcplatest这里的playwright-server是给这个MCP Server起的别名后面的npx命令是启动Server的方式。执行完成后Claude Code会自动把Server注册到配置文件中。第二步配置文件校验。Claude Code的全局配置存放在用户目录下的.claude.json里项目级配置在.claude/settings.json中。通过命令添加的Server会写入全局配置你可以手动打开文件确认。一个典型的MCP配置项长这样{ mcpServers: { playwright-server: { command: npx, args: [playwright/mcplatest] } } }第三步验证连接是否正常。重新启动Claude Code后输入斜杠命令查看已加载的MCP工具列表/mcp如果列表里能看到playwright-server对应的工具列表说明MCP连接成功。接下去你直接给Claude下指令比如“打开百度首页把搜索结果前3条标题整理成一个表格”Claude就会自动通过Playwright MCP去操作浏览器。还有一个技巧值得分享MCP也可以按项目维度隔离配置。比如A项目只需要GitHub MCPB项目需要数据库MCP那就把配置写在对应项目的.claude/settings.json里避免所有项目加载一堆用不上的工具既省token又能减少模型“选错工具”的概率。2.4 配置MCP时经常踩的坑MCP配置看着简单实际操作中坑还真不少。我遇到的第一个高频问题是“Server启动失败”。这种情况多半是环境变量问题。像Database MCP这类Server启动时需要数据库连接串、账号密码等环境变量如果这些变量只配在了系统级而终端没有继承npx拉起来的时候就会报错。解决方法是把环境变量显式写进配置命令里或者写成一个启动脚本。第二个常见坑是“工具加载了但调用超时”。这通常不是MCP本身的问题而是Server对应的外部服务响应慢。我就碰到过Figma MCP加载设计稿特别快但拉取某一层的图片资源时经常超时的情况。后来排查发现是Figma API的限流策略短时间请求过多会触发限流。解决办法是降低并发请求数或者在Prompt里明确要求模型“分批拉取”。第三个坑是端口冲突。如果你在本地同时跑了多个SSE模式的MCP Server默认端口容易撞车。建议启动时显式指定不同端口避免出现“Server起来了但没注册上”的灵异问题。还有一点需要注意MCP Server本质上是有权限执行操作的代码比如文件系统Server可以读写你的磁盘数据库Server可以执行查询和变更。配置来源不明的Server时要有一定安全意识尽量使用官方发布或社区高star的项目不要贪图功能随意安装来路不明的Server。3. Skill的设计与构建实践3.1 Skill文件结构与编写规范聊完MCP再来看看Skill。Skill的定位是“可复用的行为模板”那么它到底长什么样不同平台对Skill的定义略有差异但主流结构都差不多。以Anthropic的Agent Skills规范为例一个Skill核心包含三部分一个SKILL.md主文件、一个可选的scripts目录、一个可选的assets目录。SKILL.md是Skill的灵魂用Markdown编写文件头部是YAML格式的frontmatter声明Skill的name和description正文部分则详细描述该技能的适用场景、执行步骤和注意事项。scripts目录存放辅助脚本比如某个Skill需要处理Excel你可以放一个Python脚本进来处理数据。assets目录存放参考资料比如模板文件、示例输出等。编写SKILL.md有一个非常关键的技巧description一定要写得足够具体因为Agent判断“当前任务要不要用这个Skill”时主要就是靠匹配description和用户指令的语义。我见过有人写“用于帮助用户解决问题”这种描述等于没写模型根本不知道什么时候该调用它。正确的写法是明确描述任务类型、输入条件、输出物比如“用于把产品需求文档自动转换成PRD格式输入是需求描述文本输出是包含背景、目标、范围、需求的PRD文档”。3.2 从实际工作流沉淀Skill案例拆解Skill的价值在于“从实践中来到实践中去”。我建议不要一开始就追求做通用Skill而是从自己重复做的工作流里提炼。下面我拆解一个“科研论文写作Skill”的构建过程你可以参考这个思路去沉淀自己的Skill。这个Skill的目的是让Claude辅助科研人员写作和润色论文。我在SKILL.md里的frontmatter是这样写的--- name: academic-paper-writing description: 辅助科研论文写作与润色。适用于论文初稿生成、段落润色、摘要重写、参考文献格式规范化、审稿意见回复等场景。输入为论文片段或写作需求输出为高质量学术文本。 ---正文部分我按流程拆解了六个步骤理解用户需求、检查论文结构完整性、对照学术写作规范逐段处理、统一术语表、生成修改建议清单、输出润色后的全文。每个步骤下面都有具体的操作规范和示例。scripts目录里我放了一个terminology.py脚本用来从用户提供的论文中提取高频术语自动维护一份术语一致性对照表。assets目录里存放了摘要写作模板、引言结构模板等参考文件。实际使用下来效果比单纯把一个“你是论文写作专家”提示词丢给Claude要好得多。原因在于普通提示词只能告诉模型“要写好”而Skill里的步骤和模板把“怎样算好、按什么路径写”都约束清楚了。模型不需要临场发挥只需要按Skill的流程执行就行。再举一个典型的场景“把一本书转化为技能库”。现在有很多知识类Agent项目想做“私域知识技能化”比如把你收藏的几十篇行业报告整理成一个Skill。具体做法是先让Agent通读全部报告提取高频概念、分析框架、关键数据整理成结构化的知识点文档然后生成一个“行业分析Skill”SkilSkill里包含了该领域的分析维度、常用指标、数据获取方式。这样后续你再问Agent行业相关问题时它会优先加载这套Skill回答的专业度和深度明显不一样。3.3 Skill与MCP的协作Agent怎么综合调用前面我刻意把MCP和Skill分开讲但真实项目里它们通常是配合使用的。理解这套协作机制是搞懂新一代Agent开发的关键。我用自己的一个实际工作流来展示。这是一个“从需求文档到前端页面”的场景用户给Agent一份需求描述要求生成一个可运行的登录页面。第一步Agent识别任务类型是“前端代码生成”匹配到“前端开发Skill”。Skill提供了项目脚手架结构、组件选型约定、样式规范等约束。第二步Agent发现需要设计稿信息于是通过Figma MCP读取设计稿的尺寸、颜色、字体变量。第三步Agent通过蓝湖MCP获取切图资源。第四步Agent根据Skill规范 MCP获取的素材开始生成代码。第五步Agent使用Playwright MCP打开本地预览页面自动截图检查效果发现样式不对再返回修改。这个流程的妙处在于Skill负责“保证产出方向正确”MCP负责“保证输入数据真实”。如果只有Skill没有MCPAgent生成的前端代码是“凭想象做的”只能算个demo只有MCP没有Skill虽然拿到了准确的设计数据但代码结构可能混乱、组件规范也不统一。Agent是先匹配Skill还是先执行MCP这与具体实现有关。多数Agent框架会让模型自主决策它会在思考过程中判断“当前阶段需要打开哪份手册、调用哪个工具”。作为开发者我们能做的是把Skill的触发描述写得足够精准把MCP Server的命名和工具描述写得足够清晰让模型的决策更可靠。3.4 Skill构建中的实战避坑经验Skill做起来不难但想做好有几个坑必须绕开。第一个坑是“指令过载”。有人觉得Skill里的内容越多越好写了几千行把能想到的规则全塞进去。实际效果往往很糟糕因为模型在处理超长指令时注意力会被分散真正关键的约束反而被淹没。我的经验是Skill正文控制在500到1500行之间聚焦在“执行流程”和“输出标准”上其他背景知识放assets目录等需要时再加载。第二个坑是“没有示例”。大模型是“少样本学习”的强手你在Skill里写十条抽象规则不如放一条完整的输入输出示例。特别是表格、JSON这类结构化输出必须给示例。我在写“周报Skill”时曾忽略了示例生成的周报格式每次都不一样后来在assets里加了过去三周的正式周报作为参考输出格式立刻稳定了。第三个坑是“不测试就上线”。Skill的description写得如何、正文步骤是否会被模型正确执行都需要实测验证。测试方法很简单在一个单独的会话里不提供任何额外提示直接用描述中的典型任务句型提问看Agent能否自动触发Skill并正确执行。对Claude的用户来说还可以在输入框里直接输入skill名手动加载方便调试细节。还有个经验Skill是迭代出来的不是一步到位的。我建议每次使用Skill后检查一次输出质量把不满意的地方记录成问题清单集中修改SKILL.md。这样迭代四五次之后Skill基本就能达到“老员工手把手带新人”的效果了。4. 从MCP到Skill的进阶路径与效率提升实践4.1 场景化选型什么时候用MCP什么时候用Skill这是被问到最多的问题“我到底该做MCP还是做Skill”我的判断逻辑很简单核心看这个能力是不是“与外部世界互动”。MCP适合需要实时数据、物理操作、系统交互的场景。比如操作浏览器、调用外部API、读取数据库、访问文件系统这些背后都有“真实世界”的对象必须通过MCP去对接。Skill适合纯智力工作的场景。比如按规范写代码、润色文章、分析数据、整理文档这些任务的输入输出都是文本核心是“按什么标准、什么流程来做”。我做了个对比表应该能帮你快速判断对比维度MCPSkill本质外部工具连接协议经验/流程封装模板解决的核心问题Agent够不到外部数据/操作Agent不知道“老手怎么干”典型场景读取网页、操作设计稿、查询数据库写PRD、审查代码、写周报是否需要写代码通常需要大部分情况只需要写Markdown依赖外部服务强烈依赖基本不依赖更新频率随外部系统API变化随业务经验沉淀变化有一类场景是“模棱两可”的比如需求文档转PRD。这个任务本身是文本转换理论上做Skill就够了但如果你的PRD需要从某个在线文档平台拉取最新的需求描述那就需要MCP先把数据拿回来再交给Skill处理。所以实际项目中很多能力都是“MCP取数据 Skill加工数据”的组合模式。4.2 一个完整工作流的实战示例从需求到交付为了让你更直观地感受整个体系的威力我完整走一遍“从需求到交付”的流程。这次我用的是Claude Code 文件系统MCP 前端开发Skill的组合。场景设定产品经理给了一份文字版的需求描述要求在一个小时内交付一个可运行的活动落地页。我在终端里新建目录启动Claude Code直接输入任务指令“请根据docs/需求描述.txt中的文案生成一个活动落地页要求符合品牌风格并输出可运行代码。”Claude Code的处理过程大致如下它先通过文件系统MCP读取docs/需求描述.txt的内容理解了活动的目的、文案和转化目标。匹配到“落地页开发Skill”Skill的SKILL.md指导它按“移动端优先、首屏露出核心CTA、品牌色统一、性能优化”等标准来构建页面。根据Skill里的“组件库约定”它选择了合适的UI组件组合方式。生成index.html、style.css、main.js三个文件。通过Playwright MCP启动本地预览对页面进行截图自检发现首屏文字在手机尺寸下被遮挡自动调整了CSS布局。再次截图确认效果后向我汇报完成情况并附上本地预览地址。整个过程耗时不到十分钟。作为对比同样一个任务如果纯手工做至少要一到两个小时而且还需要设计师反复确认样式。这里面MCP保证了Agent“能读到需求文件、能打开浏览器自检”Skill保证了Agent“知道活动页该怎么做才达标”。这就是我前面说的“手脚”和“手册”协同工作的力量。4.3 常见问题与排查技巧实录实践过程中遇到的各种问题我用一张速查表给整理出来方便你对照排查。问题现象可能原因排查与解决方案MCP Server启动失败环境变量缺失依赖未安装查看Claude Code日志确认启动命令把环境变量写入配置检查Node/Python版本MCP工具已加载但调用报错Server内部运行异常单独在命令行运行启动命令观察报错信息确认外部API的权限和限流Skill一直不触发description写得太泛用具体任务描述改写description手动输入“skill名”测试Skill触发后执行效果差缺少示例或执行步骤模糊补充输入输出示例把步骤拆得更细明确每个步骤的产物多个Skill同时匹配两个Skill的description语义相近调整描述突出各自擅长的场景给Skill增加适用/不适用条件Agent生成结果格式不稳定输出规范和示例不足在Skill里增加严格的输出格式说明和图表示例系统资源占用过高多个MCP Server常驻内存只按需加载当前项目需要的MCP不用时手动卸载排查问题有一个通用的笨办法分步隔离。先把Agent能力关到最小只保留一个MCP或者一个Skill测试通过后再逐步叠加。叠加到哪一步出问题问题基本就在那个环节。这招虽然笨但在复杂项目里比看半天日志有效得多。4.4 关于效率提升方向的一些个人体会最后分享一点个人判断。MCP和Skill这套体系本质上是在把“大模型能力”往“生产力工具”方向推。MCP解决“连接”问题Skill解决“经验”问题这两件事恰好是知识工作者日常花费时间最多的地方。做完这轮实践后我最大的体会是不要把所有任务都丢给大模型“自由发挥”也不要试图把一切能力都固化成模板。正确姿势是“分层处理”——高频、确定性的流程沉淀成Skill动态、交互式的操作接入MCP两者覆盖不到的地方才让模型自由发挥。同时建议把维护Skill和MCP配置当成常态化工作这个月用着顺手的Skill下个月可能因为业务变化就要调整保持迭代心态很重要。更值得关注的是这类技术正在从“开发者专属”走向“人人可用”。现在不少Agent平台已经支持拖拽式创建Skill、一键启用云端MCP服务。未来普通用户也能像“配置快捷键”一样给Agent配置自己的技能体系。提前把MCP和Skill这套思维模型建立起来不管技术形态怎么变你都站在了更容易抓住机会的那一边。
