「Agent随笔」02 MCP？还是Skills？

上一篇说到我的 agent 中已经躺着几十个 Skills 了，所以打算梳理一番，先看的是浏览器相关的 Skills，于是就详细了解了一下 ABT（Agent Browser Tooling）的底层原理。那就是 agent 会使用 ABT 来连接 Chrome 的 CDP（Chrome DevTools Protocol），进而操作 Chrome。

那 agent 又是如何调用 ABT 的呢，就是通过 ABT 提供的 MCP 或 CLI。MCP 是 AI 时代的产物，后面细说。CLI（Command-Line Interface）就是命令行界面，通俗地说就是你在那个黑乎乎的命令行窗口里使用的 shell 命令。

而 agent 从一开始就具备的，也是最最重要的一个功能，就是执行 shell 命令，也就是 agent 可以直接调用 ABT 提供的 CLI。如何使用 CLI 需要一些方法技巧，而 Skills 正是负责让 agent 掌握这种方法技巧的工具，所以一般 Skills + CLI 一起使用。

MCP 和 Skills

MCP（Model Context Protocol） 是 Anthropic 在2024年11月发布的，是用来解决 agent 和外部系统的连接问题的，比如连接数据库，云盘等。然后还是 Anthropic，在一年后的2025年10月又发布了 Agent Skills，用来封装可复用的知识和技能，最经典的例子就是处理办公文档。

MCP 是客户-服务器架构风格，agent 就是客户端（client），在本地使用时一般也由 agent 来启动服务端（server），这样它们就能通过 stdio 来通信。这类似于上一篇提到 CDP 的 Pipe，只不过 MCP 是父子进程通过标准输入输出 FD0/FD1 来通信，而 CDP 的 Pipe 是创建了新的文件描述符 FD3/FD4 来通信。

而如果是单独启动的 MCP，或是网络上部署的 MCP，就是只能通过 HTTP 协议来通信了，这个后面细说。

MCP server 负责操作外部资源，同时向客户端也就是 agent 提供操作外部资源的工具，并通过上下文模版向 agent 说明这些工具的使用方法。这样 agent 就可以通过 MCP 来操作外部资源了。

Skills 则更加简单，他就是存储在本地的各种文件，主要有自然语言的 Markdown 文件和执行的脚本文件，还有其他所需的任何文件。Skills 通过自然语言来说明应该如何完成一项任务，当不涉及到外部资源时，它本质上就是提示词。而当需要操作外部资源时，它就成了脚本和 CLI 的使用说明书。

如何选择

如上所说，MCP 和 Skills 在为如何操作外部资源提供说明这一点上是有能力重合的，但 Skills 从创建到使用都更加简单，所以当它出现后，这方面需求大家就不愿意再用 MCP 了。

刚才也说了，当不涉及外部资源时，Skills 本质上就只是提示词，这时候完全不需要 MCP。而在涉及到外部资源的场景下，例如今天要说的操控浏览器，MCP 才可能成为选择。

目前来说，纯本地环境下，你可以直接选择使用 Skills。而网络环境中，要看供应商是否直接暴露了底层能力接口。就拿云托管的浏览器举例，如果人家暴露了 CDP，那你也可以选用 Skills。可如果人家没暴露，只提供了 MCP 服务，那你也没得选了。

就像我一开始说的，这里的 Skills 是指 Skills + CLI，CLI 负责调用 ABT 的能力，而 Skills 负责指导 agent 如何使用 CLI。Skills 当然也可以用来指导如何使用 MCP，但刚才也说了 MCP 本身就自包含这个能力，它也能封装一定的知识与技能，所以不一定需要 Skills。

不过 MCP 内部封装的知识和技能都存在于其代码中，不像 Skills 写个 md 文件就行，所以不够灵活。而且相比 Skills，MCP 注入到上下文的内容会更多。打个比方，MCP 和 Skills 是两本书，使用 MCP 的话会把书的目录注入到上下文，而使用 Skills 的话只需要注入图书简介。

所以总的来说，都是优先选择使用 Skills，只有一些特殊场景，比如你的 agent 无法正常使用 shell，或者 MCP 能力需要频繁更新的，Skills 很难做到统一升级，或者 MCP 内部有些不方便直接暴露的底层能力等等，才需要使用 MCP。

MCP 协议升级

如今的 MCP 更多是应用于网络环境了，为了适应这样的变化，就在上个月，7月28日，MCP 发布了最新的规范，将其协议升级为了请求响应式的无状态协议。

这一升级从架构层面看，很显然是为了适应其能在网络环境中使用，对架构感兴趣的小伙伴可以复习下 REST，它这里添加一些 REST 的约束，例如无状态、可缓存、分层系统，进而提升了整个系统的可靠性，可扩展性和可见性。

最早一版（2024-11-05）的 MCP 提供的基于 HTTP 的传输方式，使用的是输入输出双端点，输入端提供了一个 POST 接口，用来接收客户端发来的请求，而输出端则是一个 SSE 端点，需要客户端保持一个长链接。

长连接这种东西，对于网络应用来说，开销又大，维护成本也高，稳定性扩展性都是问题。于是转年的另一个版本（2025-03-26）用 Streamable HTTP 取代了之前的 HTTP + SSE。

Streamable HTTP 方案只保留了一个端点，请求支持 POST 或 GET，响应支持application/json 和 text/event-stream，不再强制要求客户端维持长连接了。既可以发一个短链接请求，立马拿到响应，也可以随时打开一个 SSE 流。

按 REST 的话讲，这次升级在统一接口、分层系统、无状态方面都向前迈了一小步，但这对于一个网络应用来说还是不够的。于是我们看到今年7月28日的这次升级，又对协议做了很大的改动。

完全去除了会话机制，每个请求都是独立的，并强制在请求头中添加工具名等信息，算是真的实现了无状态、可缓存和分层系统，为它大规模的网络部署提供了架构基础。

ABT

再回到咱们要说的 ABT，如果是在本地使用，那就安装它提供的 CLI 和 Skills 就好了。现在也有不少服务商提供了云端托管的浏览器服务，还同时提供了 CDP 和 MCP 服务，有的 MCP 服务还提供了更多功能。你可以用 Skills + CLI 直连 CDP，或者你也可以选择它的 MCP 以获得更多的功能。

各种 agent 软件基本都提供了安装 MCP 的功能，按着指引操作就行。它们也提供了安装 Skills 的功能，但我个人还是喜欢使用 Vercel 提供的skills工具来进行安装和管理，尤其是当你使用多种不同的 agent 时，skills可以避免重复安装，还能统一管理。

Vercel 提供的skills如何使用我就不细说了，你可以访问 https://www.skills.sh/ 或者直接问 AI。不过就像我开头说的，当 Skills 越来越多时，skills也不足以满足我的需求了，所以我才开始整理我的 Skills，打算做个管理工具。

不过这都是后话了，下一篇咱们具体介绍下各种 Agent 浏览器工具。