MCP, Rules, Skills...

Agent 的本质是一个基于 LLM 的循环，接收到用户的一个 prompt 之后，可以通过工具调用来完成用户提出的任务。

但是一般情况下，一个 Agent 可用的工具都是由开发者通过代码内置，用户无法集成自定义的工具，于是在2023年11月2日，Anthropic 公开提出并开源了 MCP（Model Context Protocol），这是一个标准协议，Agent 开发者只需要实现 MCP Client 的部分，用户就可以接入任意实现了 MCP Server 的工具，来达到让 Agent 支持接入自定义工具的能力。

MCP Server 一共提供了 3 个 feature，分别是：

• Tools
• Resources
• Prompts

但实际上使用最广泛的还是 Tools，据 MCP 官网统计，共计收录了 107 个实现了 MCP Client 的应用，其中只有 42% 实现了 Resources，38% 实现了 Prompts。但是我们还是有必要了解一下 MCP 为什么要设计 Resources 和 Prompts 这两个 feature，这对后面理解 Skills 会有一些帮助。

先说 Prompts，Prompts 其实就是一系列的 Prompt 模版，同时支持传入参数，需要用户手动触发。这与当前各大 Coding Agent 支持的斜杠命令是相同的，能够解决常用的优化后的长 Prompt 的复用问题，不再需要每次手动复制粘贴。

之所以 Prompts 的使用频率低，被 Coding Agent 的斜杠命令取代，个人猜测是因为大家会发现，Prompt 模版更多以个人/项目为维度，个人维度则存放在用户目录下，项目维度则存放在项目目录下。而 MCP 是以工具为维度，并不适合用来存储和使用 Prompt 模版。

再说 Resources，Resources 的官方定义是：「Passive data sources that provide read-only access to information for context, such as file contents, database schemas, or API documentation.」即暴露数据和内容给 LLM，但是 Resources 被设计成由应用来控制，而不应该由模型来控制，所以一般的交互形式是由用户自行选择 MCP Resources 中的部分内容，或者是应用根据用户的请求自动选择最合适的内容。但开发者往往还是希望由模型自行来选择，这种场景下 Resources 的定位就会和 Tools 重合，Resources 能实现的功能，Tools 也都能实现。

最后我们来看一下 Tools，下面是一个经典的查天气的 Tool，MCP 工具的开发者，可以通过 MCP SDK 实现这样的 Tool 定义，这与 LLM API 中的工具调用的声明几乎是一致的。

{
  "name": "get_weather_data",
  "title": "Weather Data Retriever",
  "description": "Get current weather data for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "temperature": {
        "type": "number",
        "description": "Temperature in celsius"
      },
      "conditions": {
        "type": "string",
        "description": "Weather conditions description"
      },
      "humidity": {
        "type": "number",
        "description": "Humidity percentage"
      }
    },
    "required": ["temperature", "conditions", "humidity"]
  }
}

工具调用的具体流程，也与 Agent 中内置的工具调用基本一致，LLM 选择了具体要调用的工具和参数之后，通过 Client 调用 Server 来执行，收到结果后再返回给 LLM。

一切看起来都很正常，并且还解决了用户自定义工具调用的难题，但是社区中出现了这样的讨论，MCP 存在性能问题：大部分的 MCP Client 在实现时，将用户注册的 MCP Server 中的所有工具一次性全量加载到上下文中，从而导致 token 爆炸。Anthropic 也在 Code execution with MCP: Building more efficient agents 这篇博客中承认了这个问题，并且引入了渐进式披露（Progressive Disclosure）来修复。

这篇博客中指出了两个问题：

• 工具定义会超载上下文窗口（这就是我们刚才所提到的）
• 中间工具结果会消耗额外的令牌：大部分的 MCP Server 提供的都是原子能力，往往需要多个 Tool 组合，而 Agent 在循环过程中，每一步的工具调用的结果都会存在在上下文中

其实这两个问题与 MCP 本身并没有多大关系，而是 Agent 的设计，因为如果没有 MCP，一个 Agent 一样可能存在大量的工具定义，一样会存在中间工具结果耗费 token 的情况。

而 Anthropic 的主要解决方式是引入了 Code execution，将 MCP Tools 变成可以代码调用的形式，LLM 可以直接输出代码，来组合多个工具调用得到最终想要的结果，而不是直接定义在 LLM API 的可选工具中，一遍遍的循环执行，并且可以通过 search_tools 工具来查询定义。

但是 Code execution 的概念并不是 Anthropic 最先提出来的，早在 2024 年就有一篇 CodeAct 的论文，提出了使用编写 Python 代码来代替工具调用。

渐进式披露的概念最早出现在 Anthropic 的 Effective context engineering for AI agents 这篇博客：

Letting agents navigate and retrieve data autonomously also enables progressive disclosure—in other words, allows agents to incrementally discover relevant context through exploration.

博客中指出可以通过文件系统、工具、just-in-time 等方式来”逐层发现”上下文，避免一次性塞满 token。

紧接着在 2023年10月16日，Anthropic 发布了 Equipping agents for the real world with Agent Skills，在 Claude 中引入了 Skills（Agent Skills），并且在 12月18日公开了 Skills 标准，把渐进式披露明确定义为 Skills 的核心设计原则，给出了 Skills 的三层架构：

• 第 1 层（始终加载）：YAML frontmatter（name + description）≈100 tokens
• 第 2 层（按需加载）：完整 SKILL.md 正文 <5k tokens
• 第 3 层及以后（进一步按需）：references/、scripts/、assets/ 等文件

但其实，Anthropic 并不是最早实现渐进式披露的， Cursor 最早提出并实现了 Rules，其中就有一种类型为 Apply Intelligently 的规则，他与 Skills 的第一层和第二层一致，并且规则中可以通过 @ 来引用其他文件，能够实现与 Skills 第三层一样的效果。

回到 Skills，此时你会发现，Skills 就是一个高级的 Prompt 模版，融合了以上提及的所有内容：

skill-name/
└── SKILL.md          # Required
└── scripts/
└── references/
└── assets/

SKILL.md 可以理解成是一个 Prompt 模版，scripts, references, assets 可以统称为 resources，scripts 中的脚本可以让 LLM 生成代码来组合调用，也可以直接执行。

所以 Skills 也没什么特别的。

Reference

• LLM Powered Autonomous Agents
• Introducing the Model Context Protocol
• Agent Skills