概述
在大模型时代，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 目录结构示例
伪示例结构（偏概念性）：
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 内部逻辑（简要示意）
逻辑可以被抽象为几个步骤：
- 解析输入数据
- 使用脚本归一化各渠道数据，转化为统一字段。
- 生成分析要点
- Prompt 引导模型先列出「本周亮点」「问题与风险」「下周计划」，这一阶段只聚焦内容本身。
- 套用报告模版
- 使用
report_template.md帮助模型输出结构化报告，保持格式一致性。
- 使用
- 迭代与审阅
- 支持「细化某一部分」「调整语气面向老板 / 团队」等交互，提升实用性。
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，对接数据库或外部服务。
下面是一个简化、示意性的配置代码：
// 数据访问服务示例
@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 工具（示意）：
@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 的提示完成报告生成。
伪示例代码：
@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 平台」会像今天接入微服务和消息队列一样自然，成为现代软件架构中的基础设施之一。
