一、Skill 的传统定义及其局限

在深入讨论 MCP 如何重新定义 Skill 之前，我们需要先回顾 Skill 在传统 Agent 架构中的定义及其内在局限。

在传统的 Agent 开发框架中（如 LangChain、CrewAI 或我们所说的 OpenClaw 类框架），Skill 通常被理解为一个“能力函数”——一段可被 Agent 调用的代码，接受输入参数，执行某些操作，返回结果。开发者编写一个Python 函数，用框架提供的装饰器或应用程序编程接口将其“注册”为 Skill，然后 Agent 就可以调用它。

这种定义在简单场景下是有效的。当 Skill 数量少、调用关系简单、安全要求不高时，一个函数加一个描述文本就足够了。但随着系统规模扩大，这种“能力函数”的定义暴露出了三个根本性的局限。

局限一：Skill 是“裸”的，没有任何治理附着

在传统定义中，Skill 只是一个函数。它不知道谁在调用它，不知道调用是否被授权，不知道调用应该被记录。所有这些治理能力——认证、授权、审计、限流、熔断——都需要开发者手动在每个 Skill 内部实现，或者完全忽略。

结果是：要么每个 Skill 都重复实现一套相似的治理逻辑，导致代码臃肿、容易出错；要么系统根本没有治理能力，这是危险的。

局限二：Skill 的边界是模糊的

一个函数可以调用其他函数。在传统 Skill 定义中，一个 Skill 内部可以调用数据库、调用外部应用程序编程接口、调用其他 Skill。这种内部调用的边界是模糊的——你无法从外部知道一个 Skill“到底做了什么”。

这种模糊性带来的问题是：Agent 无法知道调用一个 Skill 会产生什么副作用；审计系统无法记录 Skill 内部发生的所有操作；安全策略无法应用于 Skill 内部的子操作。

局限三：Skill 的描述和实现是分离的

在传统架构中，Skill 的“描述”和“实现”是分离的。描述写在提示词里或作为函数的文档字符串，实现在代码里。这种分离导致了一个严重的问题：描述和实现可能不一致。

开发者修改了 Skill 的实现，但忘记更新描述。Agent 根据过时的描述做出决策，调用 Skill 后得到了意料之外的结果。这种不一致在传统软件中可以通过类型系统和接口定义来避免，但在 Agent 系统中，由于描述是自然语言，无法进行静态检查。

二、MCP 对 Skill 的根本性重构

MCP 不是简单地在传统 Skill 外面包一层协议，而是从根本上重新定义了 Skill 是什么。在 MCP 体系中，Skill 不再是“能力函数”，而是“可治理行为”。

从“函数”到“行为”的转变

“函数”是代码层面的概念——它有输入、输出、副作用。但“行为”是系统层面的概念——它包含谁发起的、为什么发起、在什么上下文中发起、产生了什么后果。

MCP 将 Skill 从一个被动的代码单元，转变为一个可观测、可控制、可审计的系统行为。当 Agent“调用一个Skill”时，在 MCP 体系中实际上是“发起一个行为”。这个行为被 MCP 网关捕获、验证、记录、转发。

MCP 体系中 Skill 的新定义

在 MCP 体系中，一个 Skill 包含以下要素：

1. 能力描述：用结构化语言定义 Skill 的输入参数、输出格式、副作用类型。这不是自然语言的“描述”，而是机器可读的规范。
2. 治理策略：谁可以调用、在什么条件下可以调用、需要什么审批、调用频率限制等。这些策略不在 Skill 内部实现，而是在 MCP 控制平面中配置。
3. 执行逻辑：实际执行操作的代码。这部分与传统 Skill 类似，但它不再需要关心治理问题——认证、授权、审计都由 MCP 网关处理。
4. 可观测性接口：Skill 暴露状态信息，供 MCP 控制平面进行监控和告警。

三、MCP 为 Skill 附加的治理能力

MCP 的核心贡献之一，是将治理能力从 Skill 内部抽离出来，附加到 Skill 外部。这种抽离带来了几个关键的变化。

变化一：认证从 Skill 内部移到网关

在传统架构中，每个 Skill 都需要自己验证调用者的身份——通常是通过检查应用程序编程接口密钥或 JSON Web 令牌。这意味着每个 Skill 都要重复实现相似的认证逻辑。

在 MCP 体系中，认证在 MCP 网关层统一处理。Agent 通过 MCP 协议与网关通信，网关验证 Agent 的身份后，将请求转发给 Skill。Skill 收到的请求已经被认证过，它不需要关心“谁在调用”——它只关心“做什么”。

这种设计的好处是：新增 Skill 不需要实现认证逻辑；认证策略可以在网关层统一修改和升级；所有 Skill 的认证行为是一致的。

变化二：授权从 Skill 内部移到策略引擎

类似地，授权也由 MCP 控制平面处理。在 MCP 体系中，Skill 本身不包含任何授权逻辑。当网关收到 Agent 的调用请求时，它会查询策略引擎，判断这个 Agent 是否有权调用这个 Skill。

策略引擎中定义的规则是结构化的、可版本控制的、可测试的。例如：“类型为 customer_service 的 Agent 可以调用 query_order Skill，但只能查询状态为 completed 的订单。”

Skill 不需要知道这些规则的存在。如果调用被策略引擎拒绝，Skill 根本不会收到请求。这种设计使得授权逻辑与业务逻辑完全分离。

变化三：审计从 Skill 内部移到网关

在传统架构中，审计日志要么不存在，要么由每个 Skill 自己记录。这导致日志格式不统一、关键字段缺失、难以集中查询。

在 MCP 体系中，每一次 Skill 调用都会被 MCP 网关自动记录。网关知道：哪个 Agent 发起的调用、什么时间、调用了哪个 Skill、传入了什么参数、结果是什么、耗时多久。这些信息被结构化地存储在审计系统中，可以导出到安全信息与事件管理工具进行合规分析。

Skill 不需要做任何额外工作就能获得完整的审计能力。

变化四：限流和熔断从 Skill 内部移到网关

当某个 Skill 被频繁调用时，可能需要限流以防止系统过载。在传统架构中，限流逻辑需要每个 Skill 自己实现，或者在前置的负载均衡器中配置。

在 MCP 体系中，限流和熔断策略在网关层统一配置。网关可以按 Agent、按 Skill、按用户实现细粒度的限流。当某个 Skill 的调用失败率超过阈值时，网关可以自动熔断，不再转发请求，直到 Skill 恢复健康。

Skill 开发者不需要关心这些运维问题。他们只需要确保 Skill 本身是正确的、高效的。

四、MCP 如何解决传统 Skill 的三个局限

现在，我们可以回顾传统 Skill 的三个局限，看看 MCP 是如何逐一解决的。

解决局限一：治理从“内置”变为“附加”

传统 Skill 的治理是“内置”的——每个 Skill 都要自己实现认证、授权、审计。这导致代码重复和遗漏风险。

MCP 将治理变为“附加”的——治理能力由 MCP 网关和控制平面提供，Skill 只需要关心业务逻辑。新增一个Skill 时，开发者不需要写任何治理代码。治理策略在控制平面中统一配置，所有 Skill 自动获得完整的治理能力。

解决局限二：边界从“模糊”变为“清晰”

传统 Skill 的内部调用是黑箱，外部无法知道一个 Skill“到底做了什么”。

MCP 要求 Skill 声明其副作用类型，并通过网关进行调用。如果 Skill 内部需要调用其他 Skill，这些调用也会经过网关，形成完整的调用链。这使得 Skill 的行为边界变得清晰——所有对外部的交互都通过 MCP 协议进行，可以被观测、被审计、被策略控制。

解决局限三：描述与实现从“分离”变为“统一”

传统 Skill 的描述和实现是分离的，容易产生不一致。

MCP 使用结构化的 JSON 模式来定义 Skill 的接口规范。这个规范既是“描述”，也是“验证”。由于规范和实现是分离的但都是机器可读的，可以通过工具自动检查一致性。更重要的是，规范可以被版本控制，变更可以被追踪。

五、从“函数思维”到“行为思维”的转变

MCP 对 Skill 的重新定义，要求开发者从“函数思维”转向“行为思维”。

函数思维的特征

在函数思维中，开发者关注的是：

• 输入是什么类型
• 输出是什么类型
• 函数内部做了什么
• 如何高效地执行

这种思维适合编写工具函数、库、软件开发工具包。但在 Agent 系统中，仅仅关注这些是不够的。

行为思维的特征

在行为思维中，开发者关注的是：

• 这个行为谁可以发起？
• 在什么上下文中是允许的？
• 这个行为会产生什么副作用？
• 行为失败时应该怎么处理？
• 这个行为需要审计吗？需要审批吗？

这些问题不是关于“如何实现”，而是关于“如何治理”。MCP 强制开发者思考这些问题，因为 Skill 在 MCP 体系中不是一个孤立的函数，而是系统行为的一部分。

一个具体的例子

假设你要实现一个“发送邮件”的 Skill。

在函数思维中，你会写一个函数，调用简单邮件传输协议或邮件应用程序编程接口，处理发送失败的情况。然后把它注册给 Agent。

在行为思维中，你会考虑：

• 谁可以发送邮件？只有经过认证的用户？
• 发送邮件的频率有限制吗？防止被滥用？
• 邮件内容需要审计吗？合规要求？
• 发送给大量收件人需要审批吗？
• 发送失败时重试几次？重试间隔多长？

这些问题在 MCP 体系中，一部分由 Skill 实现者回答，一部分由平台管理员回答。但无论谁回答，这些问题都不会被忽略。

六、MCP 体系中 Skill 的工程实践

在 MCP 体系中，实现一个 Skill 的典型流程如下：

第一步：定义 Skill 规范

使用 JSON 模式定义 Skill 的输入参数和输出格式。同时声明副作用类型：只读、写操作、高风险、不可逆。

json

{

  "name": "send_email",

  "description": "Send an email to a recipient",

  "side_effects": "write",

  "input_schema": {

    "type": "object",

    "properties": {

      "to": {"type": "string", "format": "email"},

      "subject": {"type": "string"},

      "body": {"type": "string"}

    },

    "required": ["to", "subject", "body"]

  },

  "output_schema": {

    "type": "object",

    "properties": {

      "message_id": {"type": "string"},

      "status": {"type": "string"}

    }

  }

}

第二步：实现执行逻辑

实现 Skill 的实际业务逻辑。这一步与传统的函数实现没有本质区别，但有一个关键约束：Skill 不应该包含任何认证、授权、审计逻辑——这些由 MCP 网关处理。

第三步：将 Skill 封装为 MCP 服务器

将 Skill 部署为一个 MCP 服务器，暴露 MCP 协议接口。这一步通常由 MCP 软件开发工具包自动完成，开发者只需要提供规范和执行逻辑。

第四步：注册到 MCP 控制平面

在 MCP 控制平面中注册这个 Skill，并配置治理策略：哪些 Agent 可以调用、调用频率限制、是否需要审批等。

第五步：Agent 通过 MCP 协议调用

Agent 通过 MCP 客户端向网关发送调用请求。网关执行策略检查、记录审计日志、转发请求到 MCP 服务器。Skill 执行结果通过同样的路径返回给 Agent。

七、小结：Skill 的重新定义是 MCP 的核心贡献

本章的核心结论如下：

1. 传统 Skill 的定义存在三个根本局限：治理能力需要内置导致代码重复；行为边界模糊导致不可观测；描述与实现分离导致不一致。
2. MCP 将 Skill 从“能力函数”重新定义为“可治理行为”。这不是简单的包装，而是概念层面的根本性转变。
3. MCP 将治理能力从 Skill 内部抽离到外部：认证、授权、审计、限流、熔断都在网关层统一处理。Skill 只需要关心业务逻辑。
4. MCP 解决了传统 Skill 的三个局限：治理从“内置”变为“附加”；边界从“模糊”变为“清晰”；描述与实现从“分离”变为“统一”。
5. MCP 要求开发者从“函数思维”转向“行为思维”。在 Agent 系统中，治理问题比实现问题更重要。

在下一章，我们将从工程视角深入 MCP 的内部机制，探讨 MCP 中的 Action、Context、Permission 是如何协同工作的。这将帮助我们理解 MCP 协议层的具体运作方式。