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

小小工匠2026-01-09 8:57

文章目录

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

维度 MCP Skill
关注层级 能力接入层（工具 / 数据） 任务与工作流层（方法论 / SOP）
核心职责 标准化「模型如何连接外部世界」 标准化「模型如何完成具体任务」
形式 协议 + Server 实现 技能包目录 + 文档 + Prompt + 代码
可移植性 跨模型、跨 Agent 框架，只要支持 MCP 客户端即可 同类任务可跨项目 / 团队复用，依赖 Skill 定义方式
开发者角色 偏基础设施 / 平台工程师 偏业务工程师 / Prompt 工程 / Domain Expert
示例 暴露「执行 SQL 查询」「读取仓库文件」等工具 「生成季度业务分析报告」「编写品牌一致营销物料」等
主要价值 降低工具集成成本，提高安全性与统一性 提升任务完成质量与复用度，沉淀领域知识

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

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

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

5.1 场景设定

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

典型需求包括：

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

5.2 Skill 目录结构示例

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

text 复制代码 
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，对接数据库或外部服务。

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

java 复制代码 
// 数据访问服务示例
@Service
public class AnalyticsService {

    public WeeklyMetrics getWeeklyMetrics(LocalDate startDate, LocalDate endDate) {
        // 这里通常会查询数据库或调用外部 API
        WeeklyMetrics metrics = new WeeklyMetrics();
        metrics.setStartDate(startDate);
        metrics.setEndDate(endDate);
        // 填充指标数据：pv/uv、转化率、收入等
        return metrics;
    }

    public static class WeeklyMetrics {
        private LocalDate startDate;
        private LocalDate endDate;
        // 这里省略各种业务指标字段的定义和 getter/setter
    }
}

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

java 复制代码 
@Configuration
public class McpConfig {

    // 将业务方法包装为 MCP 工具
    @Bean
    public ToolCallbackProvider weeklyMetricsTools(AnalyticsService analyticsService) {
        return MethodToolCallbackProvider.builder()
                .toolObjects(new WeeklyMetricsTool(analyticsService))
                .build();
    }

    // 包装类，方法会被暴露为 MCP 工具
    public static class WeeklyMetricsTool {

        private final AnalyticsService analyticsService;

        public WeeklyMetricsTool(AnalyticsService analyticsService) {
            this.analyticsService = analyticsService;
        }

        @Tool(name = "get_weekly_metrics",
              description = "获取指定日期范围内的核心业务指标")
        public AnalyticsService.WeeklyMetrics getWeeklyMetrics(
                @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 的提示完成报告生成。

伪示例代码：

java 复制代码 
@Service
public class WeeklyReportService {

    private final ChatClient chatClient;

    public WeeklyReportService(ChatClient.Builder builder) {
        this.chatClient = builder.build();
    }

    public String generateWeeklyReport(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 平台」会像今天接入微服务和消息队列一样自然，成为现代软件架构中的基础设施之一。

相关推荐
一条咸鱼_SaltyFish17 小时前
[Day12] 合同审查引擎开发中的技术挑战与解决之道 contract-review-engine
开发语言·人工智能·程序人生·开源软件·ddd·个人开发·ai编程
百***243717 小时前
GPT-5.2国内稳定调用指南：API中转适配与成本管控实操
大数据·人工智能
瑶芯微电子17 小时前
荣誉奖项 | 瑶芯荣获碳化硅器件十强企业及年度优秀产品奖
人工智能
Want59517 小时前
未来AI会取代人类吗？
人工智能·大模型·aigc
昨夜见军贴061617 小时前
IACheck AI审核：旅游行业服务规范合规升级
大数据·人工智能·旅游
过河卒_zh156676617 小时前
喜讯：第十五批生成合成类算法备案备案号公布
人工智能·算法·aigc·生成式人工智能·算法备案
努力犯错17 小时前
如何在ComfyUI中配置LTX-2:2026年AI视频生成完整指南
大数据·人工智能·计算机视觉·语言模型·开源·音视频
予枫的编程笔记17 小时前
Elasticsearch聚合分析与大规模数据处理：解锁超越搜索的进阶能力
java·大数据·人工智能·分布式·后端·elasticsearch·全文检索
raoxiaoya17 小时前
cloudwego - eino 使用教程
人工智能·golang
热门推荐
01GitHub 镜像站点02安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）03Linux下V2Ray安装配置指南04Labelme从安装到标注：零基础完整指南05jdk21下载、安装（Windows、Linux、macOS）06【踩坑笔记】50系显卡适配的 PyTorch 安装07手把手教你通过Gemini3 pro 学生认证，白用一年，手慢无！08Opencode CLI 安装成功,但是启动失败09GitLab 零基础入门指南：从安装到项目管理全流程10Claude Code Plan 模式完全指南：从入门到精通