1. 第一课没讲完的事MCP和Skills为什么总是被人放在一起比上一篇我们聊完OpenClaw的部署和基础接入评论区问得最多的一个问题就是“MCP和Skills到底有什么区别我是不是配好了MCP就不用再折腾Skills了”这个问题问得特别到位因为所有刚接触OpenClaw和Claude Code的人几乎都会在同一个地方绕晕打开配置文件一看MCP有几十个现成服务可以加Skills也有人分享了一大堆现成技能包两边都是“装进去就能用”的东西名字还很像自然就会觉得它们是同类。但其实这两者完全不是一回事。打个比方MCP像是给你的工具间添置了一套带标准接口的高级电动工具——电钻、切割机、示波器接口统一、随插随用它解决的是“我能碰到哪些外部世界”的问题。而Skills像是你给老师傅写好的工序卡片——告诉他“做木工活要先开料、再打眼、最后上胶固定遇到红木要换什么刀头”它解决的是“面对任务时该怎么按方法论干活”的问题。一个是扩展能力的边界一个是规定行为的方式。方向不同、职责不同但真正的高手两个都配配合着用。这篇就完全围绕OpenClaw和Claude Code这两个环境里MCP与Skills的边界及搭配展开适合那些已经装好OpenClaw、跑通过基础对话、但对“该给Agent加什么”还没有清晰判断的读者。看完之后你至少能回答三个问题某个能力到底该用MCP还是Skills去实现两者之间重叠了怎么取舍搭配起来之后要怎么防止它们互相打架2. MCP的真实角色它是OpenClaw的“外设总线”不是知识库2.1 从MCP协议的设计看它的能力边界先花点时间把MCPModel Context Protocol这个协议的动机讲透。MCP是Anthropic设计的一套标准化协议目的是解决大模型应用接入外部工具时的“碎片化集成”问题。在MCP出现之前你想让Claude Code去读一个数据库通常的做法是在代码里写死一个调用函数或者用提示词把SQL逻辑塞进系统提示里。问题是每换一个工具就要重新写一套接入逻辑维护成本爆炸。MCP的做法是把工具抽象成统一协议的客户端/服务端结构Model Context Protocol Server负责封装资源、工具和提示Model Context Protocol Client负责被发现和调用。只要双方都遵循这个协议你的Agent插上服务端就可以用这套工具。但注意了MCP解决的全都是“连接性”问题。它给你的是工具的使用权不是工具的使用方法。一个很典型的例子你给OpenClaw配上Playwright MCP它能操作浏览器了能调页面元素、能点按钮、能截图。但如果你不告诉它“做前端验收的时候要先定位关键交互路径再动手”它就会毫无章法地满屏点来点去像刚拿到驾照的人上了高速却不知道看路牌。MCP不会自带使用策略它的能力是中性的。2.2 OpenClaw里MCP的常见落地形态在OpenClaw的环境里MCP有几种常见的接入形态你可以根据自己的使用场景灵活选择本地进程型MCP以本地子进程的方式运行通过stdio通信。适合本地开发工具比如Playwright MCP、Burp Suite MCP、Chrome DevTools MCP配置后会出现在你的配置文件里。网络型MCP通过Streamable HTTP或者WebSocket连接远程服务运行在远程机器上适合和团队共用或者连接云端工具。平台内置MCP比如Claude Code Desktop这种客户端自带的MCP管理面板、Chrome扩展侧的MCP连接开关这类往往是为了让工具厂商的MCP能更贴近终端用户。我见过不少用户在OpenClaw里把MCP配置堆到20个以上每个都是热门工具。但实际跑起来后效果并不好Agent每轮都要“挨个测试”哪个工具该上场响应速度明显变慢还会因为工具描述过于相似导致调用错配。这就像你把工具箱里所有规格的扳手全挂在腰带上看起来装备齐走路都不利索。2.3 为什么MCP的“可感知性”这么好却救不了行为规范MCP还有一个特性让它在Agent体系中非常抢眼工具会被自动暴露给模型模型能在对话过程中感知到一个工具的存在并自主决定调不调用。这个“模型主动调用”的机制给很多人的错觉是我装的MCP越多我的Agent就能干越多的事情。但如果这个工具需要的是一整套流程才能发挥价值光有工具是远远不够的。举一个实际发生的场景有人给OpenClaw配了Yakit MCP本意是好用的安全测试工具集结果让Agent直接对着一个目标做扫描目标未授权操作严重违规。问题根源不是MCP有问题而是Agent没有内化的操作边界。工具是增强“能做到什么”的管不了“应该怎么做”和“哪些不能做”的规则。所以MCP只是能力层这一层再丰富行为层的规则完全空白翻车是迟早的事。3. Skills才是真正的“行为方法论”教你干活而不是给你工具3.1 Claude Code里的Skills到底是什么Skills在Claude Code里的形态是一组带有结构化元数据的指令和参考文档通常放在项目的.skills目录或者全局的skills目录下。每个Skill由一个SKILL.md文件加上一系列辅助文件组成。SKILL.md里的Frontmatter会声明这个技能的名称和描述正文则给出这个技能具体的执行流程、注意事项、示例甚至是失败时的回退策略。它是押注在“给模型一套可复用的经验模板”上当任务匹配到这个技能的触发条件时Claude Code会把Skill内容加载进上下文让模型按照里面写好的方法论去工作。听起来是不是很像提示词工程是但也不全是。Skills比提示词走得更远它不只是告诉模型“你要认真”而是构造了一套带版本管理和组织结构的“行为插件”。你可以把Skills理解成给Agent安装一本岗位SOP手册手册上写清楚了遇到哪种情况要走哪套流程什么顺序执行什么结果算合格什么情况要停下来问人。现在社区里流行的Skills也非常多典型的分几类开发类前端开发Skills、代码Review Skills要求模型按特定路径先读哪些文件、再改哪些文件、最后怎么自测。安全测试类安卓脱壳Skills、代码审计Skills规定了工具调用顺序、取证规范、报告输出格式。内容创作类AI漫剧常用Skills、数学建模Skills这类多是把工作流模板化比如分镜、草稿、终稿。提效类SuperPower Skills这种整合型技能包本质是把多种能力训练成一套标准的任务拆解和执行框架。3.2 Skills的边界它不提供新工具只教现有工具怎么用得更好这一点是我特别想强调的几乎所有人混淆MCP和Skills都是栽在这里。Skills可以引用MCP的工具可以规定“先用MCP里的浏览器工具打开页面再检查DOM结构最后截图归档”但它自己并不会创建那个浏览器工具。Skills内部不能凭空增加Agent没有的工具接口它的全部参考对象都是模型已有的能力以及外部已接入的MCP工具。如果你写了一个Skill要求“调用某个地点天气查询接口”但你的环境里根本没有对应的MCP Server挂上这个Skill就只是一个写得很好的空头支票。Skills是行为层不是能力层。理解了这个边界再看“MCP和Skills该选哪个”这个问题你就能给出准确判断了如果你缺的是“调用现实世界某个服务的能力”——比如操作浏览器、连数据库、访问系统API你需要的是MCP。如果你缺的是“一套稳定可靠的做事步骤”——比如转前端项目要按Vite、Tailwind、组件拆分顺序执行或者做GUI自动化测试要先测主流程再测边界你需要的是Skills。如果两者都没有——比如你既没有浏览器操作能力也没有一套验收流程那正确的路径是先配MCP再写Skills顺序反了你只会得到一堆干不成活的流程文本。3.3 一个具体案例说明Skills的触发与执行机制我举个自己实际用到过的例子。我做过一个小项目用Claude Code在Trae IDE里配了Burp Suite的MCP Server这个属于工具层帮我搞定的是“让AI能直接操控Burp Suite”——能发包、能看代理记录、能跑Intruder。但光有这个MCP测试流程非常乱。模型一会儿抓包一会儿改包一会儿去做被动扫描毫无头绪效率很低。后来我写了一个web_security_testing的Skill在SKILL.md里明确规定测试路径必须按这样的顺序执行先配置目标会话和认证Token确认测试授权。启动被动流量收集用MCP的代理模块观察目标流量梳理出URL路径列表。再针对URL列表做主动扫描优先测登录、文件上传、参数引用等敏感入口。每个漏洞产出独立的复现步骤附请求包截图存证。扫描结束后生成Markdown格式报告包含漏洞等级、影响范围、修复建议。添加了这个Skill之后Claude Code的行为立刻从一个“会用Burp但没规划的新手”变成一个“按照渗透测试标准流程推进的初级测试工程师”结果的完整度和可用性提升了一个档次。这就是MCP和Skills组合起来应该有的样子MCP提供“触手”Skills提供“脑回路”。4. 两者组合的实战编排从能力矩阵到分工原则4.1 先画一张能力矩阵再做组合决策如果你手头已经在OpenClaw或Claude Code上攒了一批MCP和Skills遇到新任务时最容易犯的错误是“凭直觉挑选工具”。我的建议是先做一个表格把你已经拥有的能力项列出来然后分别标记它属于“能力层”还是“行为层”。我给出一个参考格式能力项需要外部服务/工具吗有既定流程吗该用什么承载浏览器自动化测试需要浏览器控制能力有先主流程后边界流程MCP装PlaywrightSkills定义验收顺序代码仓库操作需要Git接口部分有提交规范可以自定义MCP装Git工具Skills写commit规范日志分析定位线上故障不需要外部工具模型可读文本有需要排查顺序不要MCP只写Skills数据库查询需要数据库连接没有固定流程只配MCP暂不写Skills前端代码规范检查不需要外部工具有检查顺序固定只写Skills不用MCP做完这个矩阵你会发现有几种典型的组合模式MCP主导型任务强依赖外部软件的实时操作比如调用Yakit做扫描、调Playwright跑页面。Skills在这里的存在感很弱Operator自己写脚本控制即可。Skills主导型纯靠模型自身推理和已有知识就可以做的任务比如写文案、做技术方案、整理会议纪要。这类任务不需要MCP加Skills可以让输出稳定可控。双轨配合型既需要操作外部工具又要求执行顺序和规范比如安全测试、自动发版、UI验收。这类是最有价值的编排方式MCP接工具Skills定流程串联起来后Agent能真正完成复杂的多步任务。4.2 组合使用时谁优先谁执行谁兜底在OpenClaw和Claude Code的实际运行环境中MCP和Skills有一个执行层面的先后关系。理清这个分工可以让你的Agent行为更可预测模型会先感知当前可用的MCP工具但它不会一上来就乱用。它根据用户的指令判断“这个任务需要什么能力”然后从MCP工具列表里挑。如果任务命中了某个Skill的description描述模型会加载对应的SKILL.md内容。加载后Skill内部描述的流程会指导模型怎么用MCP工具、怎么组织中间结果。在双轨配合里Skill经常是发起方MCP是执行方。Skill负责拆解任务并给模型发出明确的步骤指令模型在每个步骤里去调用相应的MCP工具实现动作。我自己的经验是永远不要指望模型在没有任何Skill的情况下仅凭MCP的工具描述就能自己发明一套合理的流程。尤其是那些涉及多步操作、有先后约束、有输出规范的任务不加Skills的结果基本都是“每一步都是对的整体流程是乱的”。4.3 重叠场景下的取舍与防冲突技巧最烦人的情况是一个能力MCP里有对应工具某个社区Skills里也写了类似的流程两个都装上后Agent的行为反而出现互相干扰。例你在Claude Code里装了Playwright MCP又装了一个“网页自动操作Skills”这个Skill自己定义了调用浏览器的方式。结果模型有时候听MCP的有时候听Skill的操作风格不一致你排查半天也不知道是哪里串了。我的处理办法是三条铁律Skill里不要重复描述MCP工具本身的API用法只写任务流程和判定标准。工具怎么调用是协议层的事Skill越俎代庖只会制造冲突。多个Skill之间要保证description互斥。如果一个Skill的触发描述覆盖了另一个Skill的场景模型就会频繁加载错技能。写description的时候刻意把场景限定精确一点比如“适用于WordPress主题开发的项目启动”“适用于Vue类SPA项目的样式调试”。同一类能力只选择一个主入口。要么让MCP的工具描述承担“入口”要么让Skill的描述承担“入口”不要让两者同时成为入口。我习惯让Skill当入口因为它在加载后能带来额外执行规范而MCP的工具描述只做简洁的“能执行XX操作”。4.4 组合示例给OpenClaw配一个“前端页面验收Agent”为了更直观地展示整个组合过程我把自己在OpenClaw里做过的一个“前端页面验收Agent”配置方案拆给大家看分为两层的完整组成MCP层Playwright MCP提供浏览器控制、页面DOM查询、截图、点击、表单填充等基础操作能力。Chrome DevTools MCP提供网络请求监听、Performance面板数据、Console日志获取。Skills层前端验收Skill定义验收流程先加载页面URL再检查控制台报错接着验证核心用户路径登录、数据加载、提交表单每步都要求截图存档最后按“阻断/主要/次要”三级生成缺陷清单。页面性能回归Skill规定在“网络请求延迟”异常时需要采集的数据点、阈值判断方法以及失败时的公告格式。两层落位后我在OpenClaw的配置里只做了一件事在系统提示词里加了一句话——“前端验收类任务请严格遵循验收Skill定义的操作顺序使用MCP工具完成节点动作”。之后我对这个Agent说“验收一下这个页面的登录流程”它就会自动跑完整套流程唤起浏览器打开页面、监听控制台、执行登录操作、截图留证、生成一份带严重级别标注的验收报告。整个过程我几乎不用再给第二步指令。MCP和Skills各干各的活Agent像有了一套完整的岗位训练体系。5. 实际部署中的配置点位与调试思路5.1 在OpenClaw和Claude Code里分别怎么落位如果你想在OpenClaw里配MCP一般会用到配置文件里的mcpServers字段声明服务名、type类型local或remote、端点和启动参数。以本地型为例配置大概长这样{ mcpServers: { playwright: { type: local, command: [npx, playwright/mcplatest] }, chrome-devtools: { type: local, command: [npx, chrome-devtools-mcplatest] } } }Skills在Claude Code里的目录结构则建议按照“一人一目录、一技能一文件夹”的方式来组织。每个Skill文件夹里至少要有SKILL.md复杂一点的还会带上参考文档、示例模板、快速检索表等。SKILL.md的Frontmatter里description字段一定要好好写清楚这个技能在什么场景下启用这直接决定了Claude Code在加载Skill时的命中率。5.2 排查链路技能没生效时先查哪再查哪在交流群里被问到最多的问题就是“我装了Skills但感觉Agent根本没按Skill干活”“我配了MCP但调用时一直报错”。遇到这类问题我建议按下面的链路来排查每一步都有明确目的不要跳确认MCP服务端已成功启动。在OpenClaw的会话里直接问Agent“你现在有哪些可用工具”如果工具列表里看不到对应MCP说明服务端配置或连通有问题查启动日志。确认Skill被正确识别。看Claude Code启动日志或者直接在对话中让模型解释你的Skill内容——如果它复述不对说明Skill文件没有加载如果直接说不知道说明路径配置有问题。检查触发描述与任务描述的匹配度。很多Skill“生效”了但看起来没生效是description写得太模糊模型没理解什么时候该加载。改法是把触发场景写具体比如把“用于安全测试”改成“当用户要求对某个授权web应用做漏洞扫描时使用”。检查Skill内部是否引用了未接入的MCP工具。这个错误很隐蔽Skill规定了“调用A工具的X接口”但你的MCP配置里没有A工具模型会尝试调用然后失败。排查时重点核对Skill文档里有没有出现过你根本没配过的工具名。这四条里最容易卡住人的其实是第一条。很多人配了MCP但会话里不生效原因是MCP服务进程没拉起来或者依赖的运行时版本不对。我的建议是每次改完MCP配置先重启OpenClaw会话再验证不要热载入硬试省得日志信息混乱。5.3 关于本机环境的一个常见坑WSL状态检查既然话题涉及部署就顺便提一个我们踩过的坑如果你是在Windows上开发使用了WSL环境来跑OpenClaw或者调用内置的bash第一步永远先确认WSL处于健康状态。终端跑一下wsl --status如果反馈显示内核或发行版不在运行状态那所有依赖Linux子系统的MCP服务端都可能会启动异常。这个问题会伪装成“MCP配置错误”其实是底层的虚拟环境没起来。提示如果你已经在Windows的PowerShell里写好了全套配置却发现所有本地进程型MCP都启动失败先检查wsl --status再回头查配的启动命令有没有执行权限。顺序别搞反。6. 我踩过几次之后的个人经验编排的三个反直觉结论最后说几个不太符合直觉的经验它们是我在实际使用中反复验证过的建议你记住第一Skills不是越多越好MCP也不是越全越强。能力层和行为层的“量”都会影响模型的决策质量。我实测下来主动暴露给模型的MCP工具最好控制在15个以内待命的Skills库里虽然可以多放但description要做到“高触发精准度”否则模型平均每轮加载2个以上Skill后上下文就会被大量规则文本撑爆推理效率明显下降。第二MCP覆盖不到的隐性能力恰恰是Skills最能发挥价值的地方。很多人觉得Skills是用来教模型“用什么工具”实际上它的更大价值在于“当模型没有明确用什么工具时它能靠经验给出一条可靠路径”。比如写代码Review不用接任何MCP但Skills能把“先看接口变更再检查单元测试最后验证边界条件”的顺序定下来输出质量完全不一样。第三Skill和MCP发生冲突时优先相信Skill的流程设计。道理不复杂——Skill是脚本化的人类经验而MCP的工具描述更多是客观的能力说明。模型把两者同时放进上下文时应该以一套稳定的流程去调用那批工具而不是让模型在每次任务里临场编排。所以我配置时都会在SKILL.md里加一句“本Skill规定任务执行顺序MCP工具仅在对应步骤中被调用”。回到开篇那个问题MCP和Skills不是“二选一”的关系是一起构建Agent能力体系的左右手。MCP定义了“能”Skills定义了“会”一个负责触达世界一个负责规范动作。把这层关系理清了你再去配OpenClaw和Claude Code思路就会清晰很多。下一篇我准备围绕“Skills的开发规范”单独展开——怎么写一个让别人也能用、且不会污染上下文的Skill那是另一个值得深挖的话题。