Agent Skills 和 MCP 这两个词，最近在 AI 工程圈里已经快被说烂了，但真正把它们放到同一个项目里跑过一遍的人，可能还没那么多。我原本也觉得，一个是指令技能封装，一个是工具调用协议，各管各的；直到我自己在一个自动化测试项目里同时引入两者之后，才意识到它们根本不是并列关系，而是一个管脑子、一个管手脚，而且只有配合起来才能把 Agent 从"会说"变成"会做"。这篇文章我不打算从概念定义开始抄一遍文档，而是结合我实际用 Playwright MCP、Chrome DevTools MCP，以及自建 Skill 库的经验，把这两者的关系拆开揉碎讲清楚。
1. 先把主角认清楚：Agent Skills 和 MCP 到底是什么
1.1 Agent Skills：给 Agent 塞进一套"操作手册"
Agent Skills 说白了，就是我们可以给 Agent 预置的一套可复用的"技能包"。这个技能包不只是一个简单的提示词，而是包含任务目标、执行步骤、边界条件、常见坑位、甚至少量示例代码的结构化知识集合。比如你想让 Agent 成为一个合格的"网页信息采集员"，传统做法是每次对话时把采集步骤、选择器规则、反爬策略全部敲一遍；而有了 Skill，你可以把这些内容写进一个SKILL.md文件里，告诉 Agent "遇到网页采集任务时，先读这个 Skill，再按里面的步骤走"。
我自己实践的 Skill 目录大致长这样：
skills/ web_scraper/ SKILL.md examples/ 12306_ticket_query.md amazon_price_trace.md sql_optimizer/ SKILL.md prompts/ index_design.mdSKILL.md里写的不只是操作步骤，还包括了什么时候应该激活这个技能、什么情况下需要主动停止并请求人工介入。这其实是在给 Agent 划定"能力边界"，避免它在一个任务上无限发散。很多团队觉得 Agent 不听话，其实不是模型不行，而是没有给它足够清晰的"操作手册"，导致每次都在现场发挥。
1.2 MCP：给 Agent 装上了标准化的"插座"
MCP（Model Context Protocol，模型上下文协议）是一个让 AI 模型与外部工具、数据源进行标准化交互的协议。你可以把它理解为电脑上的 USB-C 接口：只要你的设备支持 USB-C，那么不管接的是显示器、硬盘还是扩展坞，都能即插即用。MCP 想做的事情也一样——只要工具方按 MCP 协议封装一个 Server，任何支持 MCP 的 Agent 客户端就能直接调用这个工具的能力，不用为每个工具单独写一套适配逻辑。
我们经常在贴子里看到类似wss://api.xiaozhi.me/mcp/?token=<your_token>这样的 endpoint，这就是一个通过 WebSocket 方式暴露的远程 MCP 服务地址。wss意味着这个连接走的是加密的 WebSocket，通常用于实时双向消息推送；而本地工具则更多通过 stdio 方式启动子进程通信。MCP 规范现在主要支持 stdio、HTTP（Streamable HTTP）以及 WebSocket 等传输层，底层请求都遵循 JSON-RPC 2.0 框架。
MCP 和之前那些工具调用框架最大的不同，在于它把"工具发现—鉴权—请求—响应"这个流程标准化了。以前接一个工具就要写一套 adapter，还要处理各种奇奇怪怪的参数格式；现在只要这个工具实现了 MCP Server，Agent 就能通过tools/list拿到工具清单，通过tools/call发起调用，整个流程完全一致。这也是为什么 MCP 能在这么短时间里被各家 Agent 产品广泛支持的原因。
2. 拆开看本质：Skills 是"招数"，MCP 是"经脉"
2.1 一个武侠类比帮你快速理解两者分工
如果非要用一个类比，我会把 Agent 比作一个武林高手。Skills 就是他的招式库，比如降龙十八掌、打狗棒法，每个招式都有固定的心法口诀和步伐套路；而 MCP 则像是打通任督二脉的经脉系统，真气能顺畅地流转到四肢百骸，让那些招数得以真正打出来。没有 Skills，Agent 就像一个内力深厚但脑袋空空的人，不知道该怎么出招；没有 MCP，Agent 就像一个只会背口诀但手脚被绑住的武林高手，什么也做不了。
这个类比虽然有点江湖气，但确实能说明问题：Skills 关注的是"做什么、怎么做"，MCP 关注的是"通过什么通道和介质去做"。Skills 里面可能包含工具调用的顺序、参数选择倾向、失败重试策略；MCP 则负责把 Agent 的意图翻译成具体工具的调用指令，再把结果拿回来交给模型理解。
2.2 软件协议还是硬件协议？MCP 更接近"软件开发中的接口规范"
有人看到"MCP 是软件协议 硬件协议那个概念叫什么来着"，其实想问的是它属于哪一层的协议。MCP 是纯应用层软件协议，跟 HTTP、WebSocket 这些传输协议层级不同；它更像是一套"接口规范"——约定好了请求体长什么样、错误码怎么定义、鉴权信息放在哪。类比到硬件世界，它最接近的是 USB 接口规范；软件世界里，它和 LSP（Language Server Protocol）的思路一脉相承：通过统一协议屏蔽底层差异，让各类客户端能共享同一种交互模式。
理解这一层很重要，因为很多人会把 MCP 当成某种具体的传输协议去配置，结果一遇到wss://或stdio://就迷糊。实际上 MCP 不关心你是用 WebSocket 还是标准输入输出，它只定义"业务层"的交互规则。传输方式是可替换的，而协议本身是稳定的。这点在我们排查问题的时候特别有用——连接不上时先确认传输层，再排查协议层，能少走好多弯路。
2.3 对比一张表：两者关注维度完全不同
| 对比项 | Agent Skills | MCP |
|---|---|---|
| 定位 | 能力封装与行为编排 | 工具接入与通信标准化 |
| 粒度 | 面向具体任务（如"采集商品价格"） | 面向通用工具能力（如"打开浏览器"） |
| 内容 | 步骤、提示词、模板、边界条件 | 工具定义、请求/响应格式、鉴权方式 |
| 复用方式 | 按需加载到上下文 | 客户端自动发现并调用 |
| 举例 | 电商采集 Skill、SQL优化 Skill | Playwright MCP、Chrome DevTools MCP、文件系统 MCP |
| 失败影响 | Agent 行为偏离或任务中断 | 工具调用超时或返回错误 |
从表格能看出，Skills 和 MCP 并不在一个维度上，不存在谁替代谁。MCP 强调的是"连得上"，Skills 强调的是"用得好"。现实里很多 Agent 项目只接了 MCP 没有沉淀 Skills，结果模型虽然能调用工具，但调用得很笨，经常用错参数、走错流程；反过来只有 Skills 没有 MCP，那 Skills 里写的步骤也只能是纸上谈兵。
3. 关系核心：MCP 提供"能力接口"，Skills 教会 Agent 怎么用好这些接口
3.1 "认知"和"交互"的闭环
我自己的体会是，Agent 工程化里最关键的闭环是：模型负责决策，Skills 提供决策依据，MCP 负责执行交互。举个例子，在网页自动化场景里，Playwright MCP 会暴露browser_navigate、browser_click、browser_snapshot这些工具，它们能力很强，但如果你只给模型一个工具列表，模型很可能不知道正确的点击顺序是什么，也不懂怎么处理弹窗、懒加载这些意外情况。
这时候如果有一个名为web_checkout_flow的 Skill，里面写清楚了"进入商品页—加购物车—填写地址—提交订单"的标准化流程，还额外标注了"遇到 anti-bot 检测时暂时停止并截图反馈"，Agent 就能按 Skill 的指引去调用 MCP 工具。所谓 Skilles 提供"认知"，MCP 提供"交互"，两者合在一起，Agent 才能从"有手"变成"上手"。
3.2 一个典型案例：自动采集商品信息
我最近帮朋友搭过一个采集化妆品价格的小项目，目标站点是某个电商平台。只接 Playwright MCP 的版本是这样的：用户说"帮我看看那款面霜多少钱"，Agent 会先调用browser_navigate打开首页，然后试图搜索，但因为不知道站点特定的搜索框选择器，经常点错位置；而且它每次重新开始都要摸索一遍流程，效率很低。
后来我给项目加了一个ecommerce_price_lookupSkill，内容大致包括：
- 触发条件：当用户请求涉及该电商平台的价格查询时自动加载。
- 标准流程：先访问商品搜索页，使用固定搜索框选择器，等待搜索结果卡片渲染，再提取价格字段。
- 注意事项：页面存在延迟加载，必须先滚动到底部再截取数据；请求频率过高会被限制，两次查询之间至少间隔 3 秒。
- 兜底策略：如果 5 秒内未能找到价格元素，放弃并提示用户手动输入商品链接。
加了 Skill 之后，Agent 的行为立刻变得稳定得多。它不再是"每次临场发挥"，而是像有经验的老手在按 SOP 办事。而底层真正执行操作的还是 Playwright MCP——通过browser_type、browser_click、browser_snapshot这些工具完成了所有实际动作。
3.3 Skills 还能决定 MCP 工具的"正确姿势"
MCP Server 暴露工具时，虽然会提供参数 schema，但模型未必知道怎样传参最合理。比如 Chrome DevTools MCP 里有一个take_screenshot工具，参数里没有规定"截图前要不要等页面稳定"，而很多页面渲染是异步的，直接截图会拍到空白。如果 Skill 里明确写了"调用take_screenshot前先等待网络空闲事件"，模型就会在调用前主动插入等待逻辑。
这个细节挺重要的。MCP 工具像一把好刀，但刀法好不好，要看 Skills 调教得好不好。工具调用参数里隐含的"时序关系"、"失败重试策略"和"上下文信息"是模型从 schema 里学不来的，只能沉淀在 Skill 文档里。
3.4 多 MCP Server 协同时的"编排大脑"
当项目里不止一个 MCP Server 时，Skills 的编排价值会更明显。比如同时接了 Playwright MCP 和一个数据库 MCP Server，用户提了一个需求："从数据库里找出所有订单金额超过 500 的用户，然后去他们的个人主页抓取头像。"这个任务需要先查数据库，再遍历浏览器访问每个主页。如果没有 Skill，模型很可能在第一步就把所有用户 ID 一股脑塞给浏览器工具，导致上下文爆炸。
而一个设计良好的 Skill 会这样引导Agent：先在数据库里查询并只保留前 10 个用户 ID，然后逐个取出 ID 调用浏览器导航，每处理完一个就释放相关上下文。这种"跨工具状态管理"的经验，只有写进 Skill 才能被稳定复用。MCP 把工具连接好了，但工具之间的配合策略，必须靠 Skills 来承载。
4. 实战：在真实项目里编排 Skills + MCP 的完整配置
4.1 本地开发环境怎么配置 MCP Server
以 Claude Desktop 或 Trae IDE 这类客户端为例，MCP Server 的配置文件一般长这样。这里给出 Playwright MCP 和 Chrome DevTools MCP 的配置：
{ "mcpServers": { "playwright": { "command": "npx", "args": ["@playwright/mcp@latest"] }, "chrome-devtools": { "command": "npx", "args": ["chrome-devtools-mcp@latest"] } } }各客户端的配置路径不一样：Claude Desktop 在claude_desktop_config.json里，Trae IDE 一般在项目级的.trae/config里。关键是command要能被 shell 直接执行，npx依赖 Node 环境，建议先用node -v确认版本在 18 以上。远程 MCP Server 则使用 URL 方式配置：
{ "mcpServers": { "remote-xiaozhi": { "url": "wss://api.xiaozhi.me/mcp/?token=<your_token>" } } }如果你在官方文档或别人分享的配置里看到类似的wss://地址，注意把 token 换成自己的，不要直接用别人的凭据，否则既不安全，也可能随时失效。
4.2 编写一个真正让 Agent"变聪明"的 Skill
我习惯把 Skills 放在一个独立仓库里，结构如下：
skills/mcp_web_automation/SKILL.md skills/mcp_web_automation/examples/baidu_search.mdSKILL.md的核心部分是"当 Agent 需要控制浏览器时，应遵循以下操作准则"：
# Web 自动化通用准则 ## 适用场景 用户要求打开网页、点击元素、填写表单、截图、抓取内容等浏览器交互任务。 ## 工具使用顺序 1. 调用 `browser_navigate` 跳转到目标 URL。 2. 调用 `browser_snapshot` 获取当前页面可访问性快照，而不是盲目猜测选择器。 3. 根据快照中的角色、名称、定位符来调用 `browser_click` 和 `browser_fill`。 4. 截图前先使用 `browser_wait_for_selector` 等待关键元素可见。 ## 注意事项 - 如果快照为空，先滚动页面或等待 1-2 秒再重新获取。 - 遇到弹窗时优先尝试关闭按钮，不要直接忽略。 - 如果连续三次操作没有改变页面状态，停止操作并向用户报告。这个 Skill 最大的作用，是让 Agent 在所有浏览器任务里形成统一的调用习惯。实际上，我在多个项目里复用同一个 Skill，即使底层 MCP Server 从 Playwright 换成了其他实现，Skill 仍能继续指导 Agent 完成任务——因为底层工具名字变了，但操作逻辑是相通的。
4.3 当 MCP 是安全测试工具时：Burp Suite 与 Skill 的组合
最近有个很热的内容是"Trae IDE 搭载 Burp Suite MCP Server 完整指南"，让 AI 能直接操控 Burp Suite。对于做安全测试的人来说，这个场景非常实用。Burp Suite MCP 会让 Agent 获得代理流量查看、请求重放、漏洞扫描等能力，但直接用 MCP 工具时，模型并不懂渗透测试的流程。
这时候一个名为burp_scan_guide的 Skill 就能派上用场。它定义了标准的测试流程：先通过 MCP 的get_proxy_history获取请求列表，然后根据用户目标筛选出可疑请求，再用send_to_repeater和send_request_manual进行重放测试。里面还会用大量提示词要求 Agent 在发送修改请求前先保存原始请求，方便对比。这样"Burp Suite 的能力"加上"安全测试的流程经验"才真正发挥出 Agent 渗透助手的作用。
4.4 IDE 场景：让 SQL 优化也变得可复用
JetBrains 系 IDE 的插件（比如通义灵码）也逐步支持通过 MCP 连接数据库。你可以在配置里接入一个数据库 MCP Server，从而实现自然语言查询 Oracle、MySQL 等数据库。但直接让 Agent 查询生产库很危险。于是我写了一个safe_sql_advisorSkill，里面明确要求：任何写操作语句必须先经过EXPLAIN PLAN验证，影响行数超过阈值时自动取消；查询时先读取对应表的最新索引文档，再决定是否使用SELECT *。
这个 Skill 的本质，是把 DBA 的日常经验沉淀成规则。MCP 只是给 Agent 开了一扇访问数据库的窗户，而 Skill 告诉 Agent 什么能看、什么不能碰、碰之前要准备什么。这比单纯在提示词里"劝一句"可靠得多，因为 Skill 的内容会在每次任务执行时被结构化地加载、评估。
5. 常见问题与排查：Agent 找不到工具、MCP 连不上、Skills 不生效
5.1 Codex 提示无法找到 MCP Server
Codex 这类 CLI 工具对 MCP 的配置要求比较苛刻，我遇到过几次"codex无法找到mcp"的情况，最常见的原因是 MCP server 没有在对话启动前被加载。Codex 一般是读取~/.codex/mcp.json或环境变量里配置的 server 列表，你需要先运行类似codex mcp list的命令确认 server 是否已被识别。如果列表里没有，检查配置文件里的name是否唯一，command路径是否为绝对路径。另一个坑是，启动 codex 后手动新增的 MCP server 不会自动热加载，必须重启会话。
5.2 Dify/浏览器 MCP 连接不上：先分清三层问题
在 Dify 这类低代码平台里接浏览器 MCP，如果连不上，我建议按三层排查：传输层、MCP 服务层、工具执行层。先看客户端日志里有没有 "WebSocket connection failed" 或 "stdio process exited" 这类信息，如果是远程wss://地址，还要确认证书是否有有效、token 是否过期。接下来看 MCP Server 是否注册成功，在 Dify 的工具列表里能不能看到对应工具。最后再点一次工具测试，把返回的错误信息拿来看——是超时、权限不足还是选择器没找到。三层逐层定位，基本能解决 80% 的问题。
5.3 Playwright MCP 与 Browser Use MCP 的选择问题
网上经常有人问 "browser use mcp 跟 playwright mcp 有什么区别"。我的对比表：
| 维度 | Playwright MCP | Browser Use MCP |
|---|---|---|
| 底层驱动 | Playwright（微软维护） | Browser Use 自研的浏览器自动化库 |
| 稳定性 | 很高，更新频繁 | 不错，但对复杂页面的支持略逊 |
| 特色能力 | 直接生成 Playwright 代码片段、全页截图 | 与 AI 代理深度集成，自然语言操作更直接 |
| 典型场景 | 测试自动化、数据采集 | 快速原型、个人 AI 助手浏览网页 |
实操上，如果你写的是严肃的自动化测试，我更推荐 Playwright MCP；如果只是做一个临时爬虫或者验证想法，Browser Use MCP 上手更快。但无论选哪个，Skill 都可以复用，因为 Agent 操作浏览器的逻辑模式高度一致。
5.4 Skills 不生效的排查三板斧
技能包明明写好了，Agent 却视而不见，这事我也遇到过。一般就三个原因：一是 Skill 的目录命名和描述与用户意图匹配度太低，比如文档里全是"处理页面交互"这种泛泛之词，模型不会主动关联；二是 SKILL.md 的前 10 行没有把触发条件写清楚，Agent 读完之后也不知道该不该用；三是客户端有缓存，新加的 Skill 需要清缓存或重启进程才能被识别。排查时先手动在对话里问一句"你有哪些可用技能"，看模型能否准确列出目标 Skill；列不出来就说明注册或索引有问题，列得出来却不主动用，那就是描述粒度问题。
6. 关于两者关系的一点实践总结
我踩过不少坑之后，最大的体会是：不要为了赶时髦接一堆 MCP Server，也不要迷信把 Skills 堆得越多越好。一个 Agent 项目能不能真正提效，取决于你是否为每一个 MCP Server 配好了对应的使用 Skill。先想清楚这个 Agent 要承担哪几类核心任务，比如"网页采集、SQL 查询、安全测试"，然后为每类任务写一个高质量 Skill，再去选型 MCP Server，让 Server 提供原始能力，让 Skill 提供使用经验。跑通一个组合后，再逐步复制到其他场景。
另外一个小技巧：把 Skill 文档和 MCP 配置一起纳入版本管理，Skill 单独一个仓库，MCP 配置用环境变量区分本地开发和线上部署。这样当你想给新成员交付一套 Agent 工具链时，只需要 clone 仓库并运行一条安装脚本，他立刻就能得到一个既会用工具、又懂流程的 Agent。这种工程化沉淀的价值，远大于在某个聊天界面里反复调提示词。
