已经有了 MCP，为什么 AI Agent 还需要 Skills？

随着 AI Agent 技术逐渐成熟，开发者正在接触越来越多的新概念。

从早期的 Function Calling，到后来广泛使用的 Model Context Protocol（MCP），再到如今受到关注的 Agent Skills，AI Agent 的能力扩展方式正在不断演进。

但一个问题也随之出现：

既然 MCP 已经能够让大模型连接外部工具，为什么还需要 Skills？

例如，我们已经通过 MCP 为 AI 接入了数据库、文件系统、Git 仓库以及各种业务 API。如果希望 AI 完成一次完整的系统巡检，是不是只需要把这些工具提供给模型即可？

理论上可以，但实际效果往往不够稳定。

因为工具能够被调用，不代表模型知道如何正确组合工具，更不意味着模型理解完整的业务流程。

本文从技术原理出发，分析 Function Calling、MCP 与 Skills 的关系，并结合实际案例，讨论如何构建更加可靠、可维护的 AI Agent 工具体系。

一、先理解一个问题：AI Agent 为什么需要工具？

传统大语言模型的主要能力是理解和生成文本。

它能够解释代码、回答技术问题、生成 SQL，甚至编写一份完整的系统部署脚本。

但模型本身并不天然拥有访问本地文件、查询实时数据库或者执行系统命令的能力。

例如，用户提出：

“帮我检查生产环境最近 30 分钟的服务运行情况，生成一份巡检报告。”

完成这个任务，需要获取实时监控指标、查询错误日志、分析异常并生成报告。

其中，监控数据和日志都来自外部系统。

如果没有工具，模型只能根据用户提供的信息进行分析，无法主动获取实时运行状态。

工具调用机制正是为了解决这个问题。

不过，随着 Agent 能够访问的工具越来越多，新的工程问题也开始出现。

工具应当如何定义？不同 Agent 如何复用工具？模型怎样理解复杂的执行流程？如何限制危险操作？

Function Calling、MCP 和 Skills，分别从不同层面回答了这些问题。

二、Function Calling：让模型知道应该调用什么

Function Calling 是大模型与外部系统交互的一种基础机制。

开发者向模型提供函数名称、参数定义及用途说明，模型根据用户请求判断是否需要调用某个函数，并生成符合要求的调用参数。

例如，我们提供一个查询服务监控指标的函数：

{
  "name": "get_service_metrics",
  "description": "查询指定服务的监控指标",
  "parameters": {
    "type": "object",
    "properties": {
      "service": {
        "type": "string",
        "description": "服务名称"
      },
      "window_minutes": {
        "type": "integer",
        "description": "查询最近多少分钟"
      }
    },
    "required": [
      "service",
      "window_minutes"
    ]
  }
}

当用户提出“查询 order-api 最近半小时的运行情况”时，模型可以生成如下调用参数：

{
  "service": "order-api",
  "window_minutes": 30
}

需要特别注意：

Function Calling 并不意味着模型直接执行了函数。

通常情况下，模型只是生成调用意图和参数，真正执行函数的是应用程序或 Agent Runtime。

执行完成后，应用程序再将结果返回给模型，供其继续分析。

完整过程可以概括为：

用户请求 → 模型选择函数 → 生成参数 → 应用程序执行 → 返回结果 → 模型生成回答。

Function Calling 解决了模型如何表达工具调用意图的问题。

但对于规模较大的 Agent 系统，这还不够。

假设有五个不同的 AI 应用，都需要访问相同的数据库和监控系统。

如果每个应用都要分别开发工具接口、定义参数、处理认证与异常，那么工具集成工作就会产生大量重复。

这也是 MCP 出现的重要背景。

三、MCP：解决工具如何标准化接入

MCP，全称 Model Context Protocol，是一种面向 AI 应用与外部系统的数据和工具交互协议。

它采用 Host、Client、Server 的架构，将 AI 应用与外部能力提供方进行解耦。

开发者可以将数据库、Git、文件服务及其他系统封装成 MCP Server，由支持 MCP 的客户端进行发现和调用。

MCP 不只是工具调用协议，还包括三类重要的服务端能力。

在技术实现上，MCP 使用 JSON-RPC 进行协议交互，常见传输方式包括本地标准输入输出（stdio）以及远程 Streamable HTTP。

例如，我们可以开发一个监控系统 MCP Server，对外提供三个工具：

• get_service_metrics：获取服务运行指标。

• query_error_logs：查询错误日志。

• get_recent_alerts：查询近期告警。

支持 MCP 的 Agent Host 可以通过对应的 MCP Client 连接服务端，发现可用工具，并将其提供给模型。

这意味着相同的监控接口可以被多个兼容的 AI 应用复用，而不需要每个应用都重新设计底层调用协议。

当然，协议统一不代表实现完全兼容。

不同客户端支持的 MCP 功能、认证方式以及部署限制可能存在差异，实际接入仍需要验证。

MCP 的核心价值，是建立一种相对统一的外部能力接入方式。

但 MCP 同样存在一个边界。

它能够告诉 Agent 有哪些工具、工具需要什么参数，却不能仅凭这些工具定义保证 Agent 理解完整的业务流程。

这正是 Skills 可以发挥作用的地方。

四、Skills：让 Agent 掌握一套可以复用的工作方法

Agent Skills 并不是另一种替代 MCP 的工具调用协议。

它更接近于一种面向 Agent 的任务知识和执行流程封装机制。

按照公开的 Agent Skills 规范，一个 Skill 至少包含一份 SKILL.md 文件，可以按需包含脚本、参考文档和其他资源。

一个典型的 Skill 目录如下：

service-health-check/
├── SKILL.md
├── scripts/
│   └── generate_report.py
├── references/
│   └── inspection-rules.md
└── assets/
    └── report-template.md

其中：

SKILL.md 负责描述技能的用途、触发条件、执行步骤和注意事项。

scripts 可以包含辅助执行程序。

references 可以保存较长的操作规范、业务规则及参考资料。

assets 则可以放置报告模板等静态资源。

与直接把所有知识写进系统提示词不同，Skills 通常采用按需加载的方式。

Agent 可以先读取技能的名称和描述，在确认任务需要某项技能之后，再加载完整的执行说明。

更详细的参考文件和脚本，也可以在实际使用时再访问。

这种机制有利于减少不必要的上下文占用，同时提高技能的可维护性。

但应当强调，Skill 本身并不自动赋予 Agent 执行权限。

Skill 中描述的脚本、工具和操作，只有在宿主环境提供相应能力并允许执行的情况下才能真正运行。

因此，可以用一句话区分两者：

MCP 解决 Agent 能够连接哪些外部能力，Skills 解决 Agent 应该怎样组织和使用这些能力。

五、实际案例：让 AI 自动完成一次系统巡检

为了更清楚地理解三者的协作方式，我们设计一个系统巡检 Agent。

用户只需要输入：

“检查 order-api 最近 30 分钟的运行情况，生成巡检报告。”

系统需要完成以下操作：

1. 查询 CPU、内存、请求延迟等监控指标。

2. 查询最近 30 分钟内的错误日志。

3. 获取近期告警信息。

4. 根据预先定义的规则判断是否存在异常。

5. 生成结构化巡检报告。

1. 第一层：通过 MCP 提供数据访问能力

我们首先开发监控 MCP Server。

对外暴露三个只读工具：

get_service_metrics(service, window_minutes)

query_error_logs(service, window_minutes)

get_recent_alerts(service, window_minutes)

MCP Server 负责真正访问监控平台和日志系统，并返回结构化结果。

例如：

{
  "service": "order-api",
  "window_minutes": 30,
  "cpu_usage_percent": 42.5,
  "memory_usage_percent": 68.2,
  "p95_latency_ms": 125,
  "error_rate_percent": 0.15
}

这是一份示例数据，并不代表某个真实服务的运行状态。

在这一阶段，MCP Server 不需要理解什么是“完整巡检”。

它只需要保证数据访问可靠、参数校验正确，并遵守调用者的权限限制。

2. 第二层：使用 Skill 固化巡检流程

接下来，我们为 Agent 编写一份 SKILL.md。

---
name: service-health-check
description: 检查服务运行状态并生成巡检报告。当用户要求系统巡检、健康检查或故障分析时使用。
---

# 服务健康巡检

## 执行步骤

1. 确认目标服务和时间范围。
2. 调用 get_service_metrics 获取性能指标。
3. 调用 query_error_logs 查询错误日志。
4. 调用 get_recent_alerts 获取告警信息。
5. 按 references/inspection-rules.md
   中的规则判断异常。
6. 使用 assets/report-template.md
   生成巡检报告。

## 注意事项

- 不允许自动重启服务。
- 不允许修改监控配置。
- 数据缺失时明确标记为未验证。
- 不得将采集失败解释为指标正常。
- 报告必须包含数据时间范围。

这样，Agent 就获得了一套明确的执行规范。

当用户要求进行巡检时，支持该 Skill 的 Agent 可以读取相应说明，按照规定步骤使用工具。

这里需要注意一个重要的工程细节：

Skill 应当引用真实可用的工具名称，而不是仅仅描述“查询监控系统”。

如果工具未安装、连接失败或当前账户没有权限，Agent 应当报告执行失败，而不是生成看似完整的虚假巡检结果。

3. 第三层：Function Calling 负责具体调用

当 Agent 执行巡检步骤时，模型需要判断当前应该使用哪个工具，并生成调用参数。

例如：

{
  "name": "get_service_metrics",
  "arguments": {
    "service": "order-api",
    "window_minutes": 30
  }
}

实际调用可能经过模型函数调用接口、Agent Runtime、MCP Client 和 MCP Server。

MCP Server 查询监控平台后，将结果逐级返回。

模型继续执行 Skill 中定义的其他步骤，最终生成巡检报告。

整个过程形成了一条清晰的能力链：

Skill 定义执行方法 → 模型生成工具调用 → MCP 提供标准化连接 → 外部系统执行并返回结果。

这三个部分不是竞争关系，而是可以相互协作的不同技术层次。

六、Skills 与 MCP 为什么不应该混为一谈？

从前面的例子可以看出，两者的职责存在明显差异。

例如，一个只有本地文件处理能力的 Agent，也可以通过 Skill 学习如何生成报表，而不需要 MCP。

同样，一个只需要查询数据库的简单聊天应用，也可以直接调用 MCP 工具，不必额外编写 Skill。

此外，MCP 本身已经包含 Prompts 能力。

那么 MCP Prompts 与 Skills 是否存在重叠？

答案是存在一定的功能交集，但侧重点不同。

MCP Prompts 主要用于提供可复用的交互模板；Skills 则可以组织多步骤任务说明，并配套脚本、参考文件和资源。

需要注意，二者的具体边界取决于宿主产品的实现。随着生态发展，也已经出现通过 MCP 分发和使用 Skills 的扩展方式。

因此，没有必要将它们理解成互相排斥的两套体系。

七、真正影响 Agent 效果的，是上下文管理和工具组织

在实际开发中，很多开发者会遇到类似问题：

给 Agent 配置了几十个工具，但模型经常选择错误的工具，或者重复执行不必要的操作。

这并不一定是模型能力不足。

工具设计和上下文管理同样可能是主要原因。

1. 不是工具越多越好

每增加一个工具，模型就可能需要理解更多的名称、描述和参数结构。

如果多个工具用途高度相似，模型选择工具的难度会进一步增加。

例如，同时提供：

search_file
find_file
query_file
lookup_file

如果没有清楚定义差异，模型可能难以判断应该调用哪个函数。

更合理的设计是统一工具语义，明确输入与输出结构。

对于规模较大的工具集，可以通过工具搜索、按需加载等机制，避免一次性暴露全部接口。

2. 不是 Skill 越长越好

另一个常见问题，是将大量业务说明、操作手册和异常处理规则全部写入 SKILL.md。

这样虽然能够提供丰富信息，却可能占用大量上下文。

更好的做法是分层组织。

主文件保留技能用途、核心流程和必要约束。

复杂规范放在 references 中。

稳定且确定性的操作逻辑优先交给脚本或程序处理。

例如，计算错误率、判断监控数值是否超过阈值等工作，应尽量采用明确的程序规则。

不需要让大模型每次重新推理这些确定性的逻辑。

3. 不是所有流程都应该交给模型自主决定

假设巡检任务规定必须查询三项数据，并依据固定规则生成报告。

那么系统完全可以将数据采集和指标校验编排为确定性的流程。

模型主要负责异常解释、原因分析和报告撰写。

这样的方案通常比让模型自主决定每一个技术步骤更加可控。

可以理解为：

确定性的业务规则交给程序，不确定性的语义判断交给模型。

这种分工有利于降低重复调用、异常决策和不可预测行为带来的风险。

八、企业级 Agent 应该怎样组织 MCP 与 Skills？

对于企业内部使用的 Agent 平台，建议将能力组织为三个相对独立的部分。

第一部分：公共工具服务

将数据库查询、文件访问、监控平台、工单系统等能力统一封装。

根据实际需要，可以通过 MCP Server 或已有企业 API 提供接口。

重点关注接口稳定性、身份认证、访问控制、参数校验和审计日志。

需要注意，MCP 并不能替代原有业务系统的安全机制。

即使模型能够调用工具，也必须由服务端再次校验实际操作权限。

第二部分：可复用技能库

将常见工作流程封装为独立 Skills。

例如：

• 日常系统巡检。

• 生产故障分析。

• 数据质量检查。

• SQL 代码审查。

• 技术文档生成。

每项技能应当具备明确的触发条件、输入要求、执行步骤和成功标准。

同时，需要对技能进行版本管理和测试。

不能仅凭 SKILL.md 语法正确，就认为该技能能够稳定完成业务任务。

第三部分：Agent 运行与管理平台

Agent Runtime 负责模型调用、技能选择、工具编排和执行状态管理。

对于企业应用，还应当提供任务超时、失败恢复、权限审批和执行审计等能力。

最终形成以下逻辑架构：

            用户 / 业务系统
                  |
             Agent Runtime
                  |
          +-------+-------+
          |               |
       Skills          模型推理
    任务执行规范       Function Calling
          |               |
          +-------+-------+
                  |
              MCP Client
                  |
              MCP Server
                  |
          企业 API / 数据服务
                  |
          数据库、监控、工单等

这里展示的是一种参考架构，并不是所有 Agent 都必须采用这种结构。

例如，小规模应用可能直接使用 Function Calling 访问内部 API，而不引入 MCP。

当工具需要跨多个客户端复用，或者企业希望建立统一能力目录时，再引入 MCP 通常更有价值。

工程选型应服务于实际需求，而不是追求协议数量。

九、还需要注意一个问题：Skills 本身也可能成为安全入口

Skills 本质上是一种可以被 Agent 读取并执行的任务说明。

如果技能来源不可信，其中可能包含恶意指令、危险脚本，或者诱导模型泄露数据的操作要求。

同样，MCP Server 也可能返回不可信内容。

因此，不能因为某个技能安装成功，或者某个 MCP Server 能够正常连接，就默认它是安全的。

对于企业环境，至少需要建立以下机制：

第一，对技能和 MCP Server 建立来源审核及版本管理机制。

第二，对脚本执行、文件系统和网络访问设置明确的权限边界。

第三，涉及数据修改、批量导出以及外部发送的操作，应当进行额外授权。

第四，不允许通过自然语言指令直接绕过业务系统原有的权限校验。

第五，记录工具调用过程，并对敏感凭据及业务数据进行脱敏处理。

从安全角度来看，Skills 是工作方法，不是授权凭证；MCP 是连接协议，也不是天然可信的安全边界。

真正的权限控制必须由运行平台和业务系统共同保证。

十、总结：AI Agent 正在从工具调用走向能力工程化

回顾整个技术演进过程，可以发现 Function Calling、MCP 和 Skills 分别解决了三个不同的问题。

Function Calling 让大模型能够表达结构化的工具调用意图。

MCP 让 AI 应用与外部系统之间建立标准化的连接机制。

Skills 则让 Agent 可以复用任务知识、执行流程和工程经验。

三者组合后，开发者能够在不重复开发底层工具的前提下，逐步积累可复用的智能体能力。

但工具接入只是起点。

真正成熟的 Agent 系统，还需要解决工具发现、执行编排、状态管理、权限控制和质量评估等工程问题。

对于开发者而言，不应该只关注 Agent 接入了多少工具，更应该关注它能否稳定完成明确的任务。

也不应该只关注模型能不能自主规划，而要进一步考虑哪些流程应该由模型决策，哪些步骤必须由程序控制。

Function Calling 是调用机制，MCP 是连接标准，Skills 是能力组织方式。

理解三者的关系，才能避免重复建设，形成更加清晰、可扩展和可维护的 AI Agent 架构。

随着 AI Agent 从个人辅助工具走向企业生产环境，这种对能力进行分层设计、统一管理和持续验证的工程思路，将变得越来越重要。