企业官网建设流程全解析

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协议的设计看它的能力边界

先花点时间把MCP（Model 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里明确规定测试路径必须按这样的顺序执行：

1. 先配置目标会话和认证Token，确认测试授权。
2. 启动被动流量收集，用MCP的代理模块观察目标流量，梳理出URL路径列表。
3. 再针对URL列表做主动扫描，优先测登录、文件上传、参数引用等敏感入口。
4. 每个漏洞产出独立的复现步骤，附请求包截图存证。
5. 扫描结束后生成Markdown格式报告，包含漏洞等级、影响范围、修复建议。

添加了这个Skill之后，Claude Code的行为立刻从一个“会用Burp但没规划的新手”变成一个“按照渗透测试标准流程推进的初级测试工程师”，结果的完整度和可用性提升了一个档次。

这就是MCP和Skills组合起来应该有的样子：MCP提供“触手”，Skills提供“脑回路”。

4. 两者组合的实战编排：从能力矩阵到分工原则

4.1 先画一张能力矩阵，再做组合决策

如果你手头已经在OpenClaw或Claude Code上攒了一批MCP和Skills，遇到新任务时最容易犯的错误是“凭直觉挑选工具”。我的建议是先做一个表格，把你已经拥有的能力项列出来，然后分别标记它属于“能力层”还是“行为层”。

我给出一个参考格式：

做完这个矩阵你会发现，有几种典型的组合模式：

• 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的，操作风格不一致，你排查半天也不知道是哪里串了。

我的处理办法是三条铁律：

1. Skill里不要重复描述MCP工具本身的API用法，只写任务流程和判定标准。工具怎么调用是协议层的事，Skill越俎代庖只会制造冲突。
2. 多个Skill之间要保证description互斥。如果一个Skill的触发描述覆盖了另一个Skill的场景，模型就会频繁加载错技能。写description的时候刻意把场景限定精确一点，比如“适用于WordPress主题开发的项目启动”“适用于Vue类SPA项目的样式调试”。
3. 同一类能力只选择一个主入口。要么让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/mcp@latest"] }, "chrome-devtools": { "type": "local", "command": ["npx", "chrome-devtools-mcp@latest"] } } }

Skills在Claude Code里的目录结构则建议按照“一人一目录、一技能一文件夹”的方式来组织。每个Skill文件夹里至少要有SKILL.md，复杂一点的还会带上参考文档、示例模板、快速检索表等。SKILL.md的Frontmatter里description字段一定要好好写清楚这个技能在什么场景下启用，这直接决定了Claude Code在加载Skill时的命中率。

5.2 排查链路：技能没生效时先查哪，再查哪

在交流群里被问到最多的问题就是“我装了Skills但感觉Agent根本没按Skill干活”“我配了MCP但调用时一直报错”。遇到这类问题，我建议按下面的链路来排查，每一步都有明确目的，不要跳：

1. 确认MCP服务端已成功启动。在OpenClaw的会话里直接问Agent“你现在有哪些可用工具”，如果工具列表里看不到对应MCP，说明服务端配置或连通有问题，查启动日志。
2. 确认Skill被正确识别。看Claude Code启动日志或者直接在对话中让模型解释你的Skill内容——如果它复述不对，说明Skill文件没有加载；如果直接说不知道，说明路径配置有问题。
3. 检查触发描述与任务描述的匹配度。很多Skill“生效”了但看起来没生效，是description写得太模糊，模型没理解什么时候该加载。改法是把触发场景写具体，比如把“用于安全测试”改成“当用户要求对某个授权web应用做漏洞扫描时使用”。
4. 检查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，那是另一个值得深挖的话题。