LLM - 将业务 SOP 变成 AI 能力：用 Skill + MCP 驱动 Spring AI 应用落地不完全指南

文章目录

• 概述。
• 一、从「工具调用」到「任务完成」
  • 1.1 传统工具调用的三个痛点
• 二、MCP：统一「接外部世界」的模型上下文协议
  • 2.1 MCP 是什么
  • 2.2 典型 MCP 架构：谁和谁在「说话」
• 三、Skill：把「会用工具」变成「会做事情」
  • 3.1 Skill 的基本概念
  • 3.2 Skill 解决了 MCP 解决不了的问题
• 四、Skill vs MCP：概念与职责对比
  • 4.1 核心对比表
• 五、实战一：用 Skill 搭建「自动周报 / 数据分析」工作流
  • 5.1 场景设定
  • 5.2 Skill 目录结构示例
  • 5.3 Skill 内部逻辑（简要示意）
  • 5.4 价值：从即兴输出到标准产物
• 六、实战二：Skill + MCP + Spring AI，从外部系统拉数据再生成报告
  • 6.1 场景设定
  • 6.2 使用 Spring AI 暴露 MCP 工具
  • 6.3 在 Spring AI 客户端侧调用 MCP 工具并交给 Skill
  • 6.4 Skill + MCP + Spring AI 协同模式的优势
• 七、工程实践：如何在落地 Skill 与 MCP
  • 7.1 推荐的分层架构
  • 7.2 团队协作与职责划分建议
  • 7.3 渐进披露与 Token 管理
• 八、给不同类型开发者的实践建议
  • 8.1 后端 / 平台工程师
  • 8.2 业务工程师 / 产品向开发者
  • 8.3 架构师 / 技术负责人
• 九、结语：下一步可以做什么？

概述。

在大模型时代，Agent 已经从「会聊天的机器人」进化为「能完成复杂任务的数字员工」。
要让 Agent 真正落地到业务场景，绕不开两个关键能力：接入外部世界，以及复用成熟的方法论与流程。

Anthropic 提出的 Model Context Protocol（MCP）和 Agent Skills（Skill）正是在这两点上分别发力：MCP 负责把模型接到各种工具和数据源上，而 Skill 负责把这些能力组织成可复用的任务工作流。

接下来我会从概念、架构、Spring AI 实战到工程实践，系统拆解 Skill 与 MCP 如何协同，帮助你构建真正可用的 AI Agent。

一、从「工具调用」到「任务完成」

1.1 传统工具调用的三个痛点

早期的 LLM 工具调用（如简单插件、函数调用）在工程实践中暴露出几个典型问题：

• 上下文膨胀
  • 每个工具都要在 prompt 里声明能力、参数、使用方式，工具一多，prompt 就像「API 文档大全」。
  • 结果是模型用于思考的 token 被大量工具描述挤占，成本高、效果不稳定。
• 逻辑散落
  • 业务逻辑往往写在 prompt、代码和工具实现之间，难以复用和测试。
  • 同一类任务（如「生成周报」）在多个项目里重复造轮子，协作困难。
• 缺乏标准协议
  • 不同厂商的工具接入方式五花八门，很难跨模型、跨平台迁移。
  • 一旦更换大模型或 Agent 框架，现有集成几乎要推倒重来。

在这个背景下，MCP 和 Skill 分别瞄准了不同层级的痛点：MCP 标准化「怎么连工具」，Skill 规范化「怎么完成任务」。

二、MCP：统一「接外部世界」的模型上下文协议

2.1 MCP 是什么

Model Context Protocol（MCP）是一个开放协议，用于在模型和外部系统之间建立统一、可互操作的连接方式。
可以把 MCP 想象成模型世界的通用「外设接口标准」，而不是某个具体的插件市场。

核心特征包括：

• 基于 JSON‑RPC 的请求/响应模型
• 标准化的工具、资源、会话等抽象
• 明确的安全边界和权限控制
• 独立于具体模型厂商，可复用到不同 LLM / Agent 系统中

在工程实践中，MCP 常用于把以下系统暴露给模型使用：

• 数据库（PostgreSQL、MySQL、Snowflake 等）
• 代码仓库与 CI/CD 系统
• 各类 SaaS 服务（工单、CRM、监控告警）
• 文件系统（本地或云存储）

2.2 典型 MCP 架构：谁和谁在「说话」

一个典型 MCP 架构中，会有三类角色：

• 模型 / Agent
  • 通过 MCP 客户端向 MCP 服务器发起 JSON‑RPC 请求（调用工具、读取资源）。
• MCP Server（服务端）
  • 对接真实世界系统（数据库、API、文件），并按 MCP 规范对外暴露操作。
  • 提供工具列表、schema、权限策略等元信息。
• 开发者 / 运维
  • 负责配置 MCP 服务器、权限、密钥与部署方式。

这样一来，模型不必关心「如何连数据库」，而只需要理解「有一个工具可以执行安全 SQL 查询」，从而实现能力解耦与可迁移。

三、Skill：把「会用工具」变成「会做事情」

3.1 Skill 的基本概念

Agent Skills（Skill）是一种面向任务的「AI 技能包」，每个 Skill 是一套围绕某类任务的可复用知识与流程。
可以把 Skill 理解为：针对一个具体任务，打包好 prompt、步骤设计、工具调用策略与资源的组合。

一个典型 Skill 的结构大致包括：

• 说明文件（如 SKILL.md）
  • 描述 Skill 的目的、输入输出、适用场景与使用示例。
• 任务指导与提示模版
  • 类似「专业 SOP + Prompt」，告诉模型该如何一步步完成任务。
• 可选代码或脚本
  • 针对特定任务的预处理 / 后处理逻辑，例如文本解析、格式转换。
• 附加资源
  • 模板文档、示例数据、品牌规范等支持性文件。

3.2 Skill 解决了 MCP 解决不了的问题

MCP 解决的是「连什么」和「如何安全地连」，但不会告诉模型「在什么场景下先做什么再做什么」。
Skill 则将这层业务任务逻辑显性化，让 Agent 可以像专业员工一样执行完整工作流。

一句话概括两者差异：

• MCP：我给你一堆工具和数据源，你自己决定怎么用。
• Skill：我告诉你如何完成「写周报」「生成财报」「做代码审查」这类任务，并在过程中合理使用那些工具。

四、Skill vs MCP：概念与职责对比

4.1 核心对比表

从这张表可以看出，Skill 与 MCP 并不是竞争关系，而是分层协作的关系。

五、实战一：用 Skill 搭建「自动周报 / 数据分析」工作流

第一个实战先不引入 MCP，只用 Skill 展示如何把「写周报 / 数据分析报告」这种常见办公任务系统化。

5.1 场景设定

目标：构建一个「报告生成 Skill」，输入是：一周业务数据 + 笔记 + 关键事件；输出是：结构化的周报。

典型需求包括：

• 自动梳理数据趋势（环比、同比）
• 提炼关键问题与风险
• 生成可直接发给老板 / 团队的 Markdown / 文档结构

5.2 Skill 目录结构示例

伪示例结构（偏概念性）：

reporting-skill/ ├── SKILL.md ├── prompts/ │ ├── system.txt │ └── report_template.md ├── scripts/ │ └── preprocess_data.py └── examples/ └── weekly_report_example.md 

SKILL.md 描述该 Skill 的用途、输入格式（如 JSON 数据 + 文本）、输出示例、以及对模型的指示。

5.3 Skill 内部逻辑（简要示意）

逻辑可以被抽象为几个步骤：

1. 解析输入数据
   • 使用脚本归一化各渠道数据，转化为统一字段。
2. 生成分析要点
   • Prompt 引导模型先列出「本周亮点」「问题与风险」「下周计划」，这一阶段只聚焦内容本身。
3. 套用报告模版
   • 使用 report_template.md 帮助模型输出结构化报告，保持格式一致性。
4. 迭代与审阅
   • 支持「细化某一部分」「调整语气面向老板 / 团队」等交互，提升实用性。

5.4 价值：从即兴输出到标准产物

这种基于 Skill 的设计有几点明显优势：

• 把经验丰富同事的写报告套路显性化沉淀。
• 报告风格统一，内容和结构更稳定，便于长期对比。
• Skill 可以被不同 Agent、不同模型重用，只要遵守相同输入输出约定。

六、实战二：Skill + MCP + Spring AI，从外部系统拉数据再生成报告

第二个实战更贴近真实工程：报告不再手动喂数据，而是通过 MCP 直接从外部系统提取（如数据库 / API），再由 Skill 负责分析与写作。

这里选用 Spring AI 作为 Java / Spring 生态中的实现方式。

6.1 场景设定

需求升级为：

• 从数据库或业务 API 自动拉取一周运营数据。
• 数据拉取逻辑通过基于 Spring AI 的 MCP Server 对接。
• Skill 负责组织问题、生成分析结论与自然语言报告。

换句话说：MCP 管「去哪拿数据」，Skill 管「拿到数据后怎么写好报告」。

6.2 使用 Spring AI 暴露 MCP 工具

先在服务端用 Spring AI 暴露一个 MCP 工具 getWeeklyMetrics，对接数据库或外部服务。

下面是一个简化、示意性的配置代码：

// 数据访问服务示例@ServicepublicclassAnalyticsService{publicWeeklyMetricsgetWeeklyMetrics(LocalDate startDate,LocalDate endDate){// 这里通常会查询数据库或调用外部 APIWeeklyMetrics metrics =newWeeklyMetrics(); metrics.setStartDate(startDate); metrics.setEndDate(endDate);// 填充指标数据：pv/uv、转化率、收入等return metrics;}publicstaticclassWeeklyMetrics{privateLocalDate startDate;privateLocalDate endDate;// 这里省略各种业务指标字段的定义和 getter/setter}}

使用 Spring AI 的 MCP 支持把它暴露为 MCP 工具（示意）：

@ConfigurationpublicclassMcpConfig{// 将业务方法包装为 MCP 工具@BeanpublicToolCallbackProviderweeklyMetricsTools(AnalyticsService analyticsService){returnMethodToolCallbackProvider.builder().toolObjects(newWeeklyMetricsTool(analyticsService)).build();}// 包装类，方法会被暴露为 MCP 工具publicstaticclassWeeklyMetricsTool{privatefinalAnalyticsService analyticsService;publicWeeklyMetricsTool(AnalyticsService analyticsService){this.analyticsService = analyticsService;}@Tool(name ="get_weekly_metrics", description ="获取指定日期范围内的核心业务指标")publicAnalyticsService.WeeklyMetricsgetWeeklyMetrics(@ToolParameter(description ="开始日期，格式 yyyy-MM-dd")String startDate,@ToolParameter(description ="结束日期，格式 yyyy-MM-dd")String endDate ){LocalDate start =LocalDate.parse(startDate);LocalDate end =LocalDate.parse(endDate);return analyticsService.getWeeklyMetrics(start, end);}}}

这里利用 Spring AI 对 MCP 的封装，把带有 @Tool 注解的方法暴露为 MCP 工具，模型或 Agent 通过 MCP Client 即可发现并调用。

6.3 在 Spring AI 客户端侧调用 MCP 工具并交给 Skill

在客户端（消费 MCP 工具的一侧），可以使用 Spring AI 提供的 ChatClient，让模型在对话中调用 MCP 工具，然后结合 Skill 的提示完成报告生成。

伪示例代码：

@ServicepublicclassWeeklyReportService{privatefinalChatClient chatClient;publicWeeklyReportService(ChatClient.Builder builder){this.chatClient = builder.build();}publicStringgenerateWeeklyReport(LocalDate startDate,LocalDate endDate){String systemPrompt =""" 你是一名专业的数据分析师和业务顾问。 现在你需要根据提供的一周业务指标，生成一份结构化的运营周报。 周报结构应包括：本周整体概览、核心指标分析、亮点与问题、下周建议。 """;String userPrompt =""" 请根据本周的业务数据生成运营周报。 时间范围：{start} 到 {end}。 如果当前没有业务数据，请先调用工具获取一周的业务指标，再进行分析和写作。 """;return chatClient.prompt().system(systemPrompt).user(userSpec -> userSpec .text(userPrompt).param("start", startDate.toString()).param("end", endDate.toString()))// 告诉模型可以使用的工具（底层通过 MCP 暴露）.tools(toolsSpec -> toolsSpec .tool("get_weekly_metrics")).call().content();}}

在这个示例中：

• MCP Server 通过 Spring AI 将 get_weekly_metrics 暴露为工具。
• Spring AI 的 ChatClient 在对话中允许模型使用这个工具。
• Skill 的逻辑主要体现在 systemPrompt 与整体对话设计中：它描述了如何撰写周报、报告结构和分析维度。

如果你希望把 Skill 进一步模块化，可以将上面的 prompt 和模版抽到单独的 Skill 包中，再在 Spring 服务里简单引用。

6.4 Skill + MCP + Spring AI 协同模式的优势

这种组合带来的价值非常明显：

• 数据获取与权限控制交给 MCP + Spring AI 服务端，安全可审计、可统一运维。
• 报告撰写、分析逻辑交给 Skill 与 LLM，便于业务团队迭代和复用。
• 两者高度解耦：
  • 换数据源只改 MCP Server 或 Spring Bean 实现。
  • 换报告风格只改 Skill 的模版和提示。
  • 换大模型只需在 Spring AI 配置层调整，大量业务代码复用不变。

七、工程实践：如何在落地 Skill 与 MCP

7.1 推荐的分层架构

在实际系统里，可以按以下分层方式来接入 Skill 与 MCP：

• 接入层（Integration Layer）
  • 部署一个或多个基于 Spring AI 的 MCP Server，对接数据库、API、文件系统等。
  • 管理密钥、访问控制、审计日志。
• 能力编排层（Capability Orchestration）
  • 使用 Spring AI 的 ChatClient / Agent 能力，负责路由调用到 MCP 工具。
  • 可以接入多个 MCP Server 或其他工具源。
• 任务技能层（Task Skills）
  • 以 Skill 为单位定义报告生成、测试分析、代码审查、客服自动总结等任务。
  • 每个 Skill 描述清楚输入输出与内部步骤，可存于版本库。
• 应用层（Applications）
  • 将不同 Skill 组合成业务应用：智能助理、自动化工作流、内部 Copilot。

这种分层的好处是：当你要接入新模型或替换 Agent 框架时，只要保持 MCP 和 Skill 层的契约，大部分能力可以直接迁移。

7.2 团队协作与职责划分建议

在团队内部，可以这样划分职责：

• 平台 / 基础设施团队
  • 负责 MCP Server 的搭建、接入、监控与安全。
  • 提供统一的「企业工具目录」。
• 业务 / 应用团队
  • 以 Skill 为单位沉淀业务 SOP 与最佳实践。
  • 维护 Skill 文档、模板和测试用例。
• AI / 架构团队
  • 制定 Skill 规范与评估标准。
  • 设计整体 Agent 架构与性能优化策略（例如分阶段推理、渐进披露）。

7.3 渐进披露与 Token 管理

为了避免上下文爆炸，可以在 Skill 设计中采用「渐进披露」策略：

• 初次加载 Skill 时，只给模型一个摘要和关键能力描述。
• 当模型决定需要执行具体步骤时，再按需加载详细说明或示例。
• 将长文档拆成多个模块，在实际推理过程中按需注入。

对于拥有大量 Skill 的大型系统，这是控制成本与提升稳定性的关键策略之一。

八、给不同类型开发者的实践建议

8.1 后端 / 平台工程师

优先关注 MCP 与 Spring AI：

• 尝试搭建一个简单的 Spring Boot 应用，开启 Spring AI MCP server starter。
• 暴露几个典型工具：
  • 根据用户 ID 查询订单汇总。
  • 根据时间范围查询运营指标。
• 熟悉如何通过注解或工具提供者动态增删 MCP 工具，便于后续按业务权限进行控制。

8.2 业务工程师 / 产品向开发者

可以先从 Skill 着手：

• 找出团队中重复性高、结构稳定的任务：
  • 周报、月报、运营分析、代码评审意见总结等。
• 为这些任务设计 Skill：
  • 写清楚输入输出、约束条件与示例。
  • 把资深同事的「隐性经验」转化为可执行步骤。
• 与平台同事协作，在 Skill 中引入 MCP 工具，让数据拉取自动化。

8.3 架构师 / 技术负责人

建议从整体架构与治理角度规划：

• 明确哪些任务适合做成通用 Skill，哪些只在单一系统内使用。
• 设计一个「Skill 仓库」与「MCP 工具目录」，支持版本管理与质量评估。
• 制定统一的 Skill 设计规范（命名、目录结构、输入输出约定），避免无序扩张。
• 评估 Spring AI 在现有 Spring 技术栈中的集成方式，减少学习与迁移成本。

九、结语：下一步可以做什么？

MCP 和 Skill 代表了 Agent 工程化的两条主线：能力接入标准化和任务逻辑模块化。
它们并不是要取代现有的开发方式，而是帮助开发者以更低成本复用工具与经验，让「为 AI 编程」更接近传统软件工程的可维护与可协作形态。

如果你想在自己的项目中落地这套范式，一个实际可行的路径是：

• 从一个小型 MCP Server 开始，只对接一两个关键数据源，用 Spring AI 快速搭建。
• 为一个高频任务（如周报、运营分析）设计首个 Skill，并在服务端封装为可复用组件。
• 在一个小团队中试点，逐步扩展 Skill 数量与 MCP 覆盖面。

随着 Skill 与 MCP 生态的完善，未来「为 Agent 安装技能」「为企业构建通用 Agent 平台」会像今天接入微服务和消息队列一样自然，成为现代软件架构中的基础设施之一。