在AI应用开发领域，我们正在见证一场深刻的范式转变。传统的LLM应用开发模式正逐渐暴露出其固有的局限性：工具调用缺乏标准化、能力复用困难、系统集成复杂度高。而随着MCP（Model Context Protocol）和Skill这两个核心概念的兴起，我们终于拥有了构建真正智能化、可扩展AI应用的坚实基础架构。
本文将深入探讨传统LLM工具调用的痛点，并从概念、架构、Spring AI 实战到工程实践，系统拆解 Skill 与 MCP 如何协同，帮助你构建真正可用的 AI Agent。
一、传统 LLM 工具调用的痛点
传统 LLM 工具调用的痛点，主要集中在效率、可维护性、通用性三个核心维度：
1.1 上下文膨胀：思考空间被 “工具说明” 挤爆
核心问题：要让大模型调用工具，必须把 API 文档、工具参数、使用规则都塞进 Prompt 里。
直接后果：
工具描述占了大量 Token，挤压了模型真正用于 “理解用户问题、规划任务” 的思考空间。
调用成本飙升（Token 费变高），还容易因为信息太多，模型漏看关键规则，导致调用失败、效果不稳定。
1.2 逻辑散落：工具、代码、Prompt “各玩各的”，没法复用和维护
核心问题：工具调用的逻辑被拆成了三块 ——Prompt 里的规则、模型生成的代码、底层的工具实现，三者之间没有统一的流程规范。
直接后果：
业务逻辑分散在不同环节，调试、测试、排查问题都非常困难。
不同场景的工具调用逻辑没法通用，每次都要 “重复造轮子”，团队协作也很难沉淀通用能力。
1.3 缺乏标准协议：换个模型 / 平台，工具就要 “推倒重来”
核心问题：不同大模型（比如 Model A、Model B）、不同 Agent 框架的工具接入方式完全不统一，没有通用的协议规范。
直接后果：
接入方式五花八门，一套工具没法同时适配多个模型 / 平台。
一旦要更换模型或者迁移平台，几乎要重写所有的工具适配代码，迁移成本极高。
这些痛点，也正是后来 MCP（标准化工具连接协议） 和 Skill（规范化任务能力） 想要解决的问题：前者统一 “工具怎么连” 的标准，后者沉淀 “任务怎么完成” 的通用逻辑，让工具调用更高效、可复用、易迁移。
二、MCP：标准化工具连接协议
2.1 MCP 是什么
MCP（Model Context Protocol）是由Anthropic推出的开放协议，旨在建立AI模型与外部工具、数据源之间的标准化连接方式。MCP的设计理念类似于数据库领域的JDBC或消息队列领域的AMQP——提供统一接口，实现"一次定义，处处可用"。
2.2 核心架构
MCP 架构分为客户端层与服务端层，两者通过标准化的 JSON-RPC 协议实现双向通信，实现了 “模型 / 应用” 与 “工具 / 资源” 的解耦：
MCP Client（客户端）：作为 LLM 应用中的抽象接口层，它向下对接 LLM 模型，向上与 MCP Server 通信。它的核心职责是协议协商、消息路由和请求响应管理，同时维护与每个 MCP Server 的独立会话，保障通信安全与隔离。
MCP Server（服务端）：作为外部工具 / 资源（如数据库、API、文件系统）的提供者，它通过标准化接口向客户端暴露工具能力。服务端可以独立部署、按需扩展，无需关心上层模型或应用的具体实现。
MCP 可以直接在 AI 与数据（包括本地数据和互联网数据）之间架起一座桥梁，通过 MCP 服务器和 MCP 客户端，大家只要都遵循这套协议，就能实现“万物互联”。
在工程实践中，MCP 常用于把以下系统暴露给模型使用：
数据库（PostgreSQL、MySQL、Snowflake 等）
代码仓库与 CI/CD 系统
各类 SaaS 服务（工单、CRM、监控告警）
文件系统（本地或云存储）
有了MCP，可以和数据和文件系统、开发工具、Web 和浏览器自动化、生产力和通信、各种社区生态能力全部集成，实现强大的协作工作能力，它的价值远不可估量。
三、Skill：规范化任务能力
3.1 Skill 的基本概念
Skill是对AI能力的更高层次抽象，它封装了特定领域的知识、工具组合和执行策略。如果说MCP提供了"标准化的螺丝刀"，那么Skill就是"标准化的维修手册"——它告诉你如何组合使用各种工具来完成复杂任务。可以把 Skill 理解为：针对一个具体任务，打包好 prompt、步骤设计、工具调用策略与资源的组合。
my-skill/
├── SKILL.md # 【核心定义】技能说明、触发条件与SOP流程（必选）
├── skill.yaml # 【元数据配置】技能参数、权限、依赖声明（可选）
├── scripts/ # 【执行能力】可运行的脚本/工具调用逻辑（可选）
│ ├── main.py # 主执行入口
│ ├── utils.py # 工具函数
│ └── validators.py # 输入输出校验逻辑
├── reference/ # 【资源层】参考文档、模板、知识库（可选）
│ ├── 业务规则.md
│ ├── 数据模板.xlsx
│ └── 案例库/
└── examples/ # 【示例层】使用示例与测试用例（可选）
├── test_case_1.json
└── test_case_2.json3.2 Skill 解决了 MCP 解决不了的问题
MCP 解决的是「连什么」和「如何安全地连」，但不会告诉模型「在什么场景下先做什么再做什么」。
Skill 则将这层业务任务逻辑显性化，让 Agent 可以像专业员工一样执行完整工作流。
一句话概括两者差异：
MCP：我给你一堆工具和数据源，你自己决定怎么用。
Skill：我告诉你如何完成「写周报」「生成财报」「做代码审查」这类任务，并在过程中合理使用那些工具。
四、Skill vs MCP：概念与职责对比
MCP（Model Context Protocol，模型上下文协议）：
是一套标准化的通信协议，解决「模型 / 应用怎么和外部工具 / 资源连接」的问题，是工具连接层的标准。
Skill（智能体技能模块）：
是一套可复用的任务能力单元，解决「怎么按业务流程完成一个完整任务」的问题，是业务能力层的封装。
简单说：
MCP 管 “怎么连工具”，Skill 管 “怎么用工具完成任务”。
核心对比表
五、实战：Skill+MCP 搭建「门店经营数据分析」
MCP 和 Skill 不是二选一的关系，而是上下层配合、互补的关系。接下来，将通过项目中的一个实际案例，来说明Skill和MCP如何配合使用。
5.1 需求描述
做一个「门店经营数据分析」的 Agent：
模型触发这个 Skill，Skill 按流程执行：
第一步：解析对话内容中的门店信息；
第二步：通过 MCP 调用「门店经营数据API」获取指定时间的经营数据；
第三步：分析经营数据，给出结论。
整个过程中，MCP 负责工具连接，Skill 负责流程编排。
5.2 使用 Spring AI 暴露 MCP 工具
先在服务端用 Spring AI 暴露一个 MCP 工具 getStoreDataTool，用于查询指定门店某个时间范围内的经营数据：
/**
* 门店经营数据查询工具
* 使用 Map 类型接收 JSON 对象参数
*/
@Bean
public FunctionToolCallback getStoreDataTool() {
return FunctionToolCallback.builder("get_store_data", (Map<String, Object> input) -> {
log.info("调用门店数据获取工具，输入参数: {}", input);
Long storeInfoId = parseStoreInfoIdFromMap(input);
log.info("解析后的门店ID: {}", storeInfoId);
return fetchStoreDataFromApi(storeInfoId);
})
.description("查询门店经营数据。参数：storeInfoId - 门店ID（数字）")
.inputType(Map.class)
.build();
}
/**
* 直接调用 API 获取门店数据
*/
private String fetchStoreDataFromApi(Long storeInfoId) {
// 查询数据库或调用接口
}5.3 在 Spring AI 客户端侧调用 MCP 工具并交给 Skill
在客户端（消费 MCP 工具的一侧），可以使用 Spring AI 提供的 ChatClient，让模型在对话中调用 MCP 工具，然后结合 Skill 的提示完成报告生成。
---
name: 门店数据MCP工具分析
description: 当用户需要分析指定门店的经营数据时，使用本技能通过 MCP Tool (get_store_data) 获取数据并进行财务分析
---
# 门店数据 MCP 工具分析技能
## 技能名称
门店数据MCP工具分析
## 适用场景
当用户只提供门店ID需要分析门店经营数据时，使用本技能。本技能演示 MCP Tool 的使用方式。
## MCP Tool
本技能使用 `get_store_data` MCP Tool 获取门店经营数据：
- **Tool 名称**: `get_store_data`
- **参数类型**: Long（门店ID）
- **返回**: 门店经营数据 JSON
## 执行步骤
1. 从输入中获取门店ID数值（输入会是上一个 agent 提取的纯数字）
2. 调用 get_store_data，参数格式：{"storeInfoId": 数字}
3. 分析返回数据，输出不超过100字结论
## 输入要求
输入的内容：门店ID（数值），例如：1、2、100
## 输出格式
分析总结不超过100字，包含：
- 回款总额、确认收入概况
- 收入/回款比分析
- 经营建议 /**
* 注册 FileSystemSkillRegistry，加载 skills 目录下的技能文件
*/
@Bean
public SkillRegistry skillRegistry() {
return ClasspathSkillRegistry.builder()
.classpathPath("skills")
.autoLoad(true)
.build();
}
/**
* 创建 SkillsAgentHook，将 skills 注入 Agent
*/
@Bean
public SkillsAgentHook skillsAgentHook(SkillRegistry skillRegistry) {
return SkillsAgentHook.builder()
.skillRegistry(skillRegistry)
.build();
} @Bean("mcpToolReactAgent")
@DependsOn("skillRegistry")
public ReactAgent mcpToolReactAgent(ChatModel chatModel,
@Qualifier("skillsAgentHook") SkillsAgentHook skillsAgentHook) {
return ReactAgent.builder()
.name("mcp-tool-agent")
.model(chatModel)
.systemPrompt("""
你是一个门店经营数据分析专家。
门店ID：{store_info_id}
使用技能：门店数据MCP工具分析，获取指定门店的数据，进行门店经营数据分析。
""")
.hooks(List.of(skillsAgentHook))
.tools(List.of(getStoreDataTool()))
.outputKey("analysis_result")
.build();
}在这个示例中：
MCP Server 通过 Spring AI 将 get_store_data 暴露为工具；
Skill 设计则明确的分析的过程：如何解析对话中的门店信息，并在流程中调用MCP Server，规范了分析的流程及输出格式；
Spring AI 的 ReactAgent 在对话中允许模型使用Skill。
5.4 Skill + MCP + Spring AI 协同模式的优势
门店经营数据的获取与权限控制交给 MCP + Spring AI 服务端，安全可审计、可统一运维。数据分析、报告生成交给 Skill 与 LLM，便于业务团队迭代和复用。
两者高度解耦：
更换数据源只改 MCP Server 或 Spring Bean 实现。
调整报告分析风格只改 Skill 的模版和提示。
更换大模型只需在 Spring AI 配置层调整，大量业务代码复用不变。
六、结语：下一步可以做什么？
MCP 和 Skill 代表了 Agent 工程化的两条主线：能力接入标准化和任务逻辑模块化。它们并不是要取代现有的开发方式，而是帮助开发者以更低成本复用工具与经验，让「为 AI 编程」更接近传统软件工程的可维护与可协作形态。
如果你想在自己的项目中落地这套范式，一个实际可行的路径是：
从一个小型 MCP Server 开始，只对接一两个关键数据源，用 Spring AI 快速搭建。
为一个高频任务（如周报、运营分析）设计首个 Skill，并在服务端封装为可复用组件。
在一个小团队中试点，逐步扩展 Skill 数量与 MCP 覆盖面。
随着 Skill 与 MCP 生态的完善，未来「为 Agent 安装技能」「为企业构建通用 Agent 平台」会像今天接入微服务和消息队列一样自然，成为现代软件架构中的基础设施之一。