1. 先把三个词摆到台面上它们根本不在一个层级很多人第一次接触这三个概念时会下意识地把它们并列起来比较就像比较三种不同的数据库或者三个前端框架。这个直觉是错的而且错得挺离谱。Function Calling、MCP、Skill 这三样东西压根不在同一个抽象层级上——把它们放在一起问啥关系有点像问发动机、高速公路、驾驶执照三者到底啥关系。它们确实协同工作但各自扮演的角色完全不同。我在带团队做 AI Agent 落地的时候发现新人最容易混淆的就是这一点。有人以为 MCP 是 Function Calling 的替代品有人觉得 Skill 就是包装了一下的 Function Calling还有人干脆认为这三个是同一种东西的不同叫法。这些理解都会导致架构设计上的严重误判。先把最核心的定位说清楚Function Calling是模型层面的一种能力——让大语言模型能够输出结构化的调用意图告诉外部系统我要调用某个函数参数是什么。它是模型和外部世界之间的接口协议。MCPModel Context Protocol是一套标准化的通信协议——规定了 AI 应用和外部工具/数据源之间怎么发现、怎么描述、怎么调用。它是传输和发现层的规范。Skill是面向具体业务场景的能力封装——把一组相关的工具调用、提示词、上下文管理打包成一个可复用的单元。它是业务语义层的抽象。用一句话概括它们的关系Skill 是业务目标Function Calling 是执行手段MCP 是连接标准。一个 Skill 可能内部用到多个 Function Calling而这些调用可以通过 MCP 协议来标准化地暴露和发现。1.1 为什么大家会把它们搞混混淆的根源在于这三者在实际代码里经常出现在同一个文件、同一个流程里。你写一个 Spring AI 的 Controller可能同时看到Tool注解Function Calling 的声明、MCP 的 Server 配置、以及一个被命名为 XxxSkill 的 Service 类。视觉上它们混在一起但逻辑层次泾渭分明。另一个原因是厂商宣传的模糊化。有些平台把三者打包成一个概念卖导致开发者以为它们是一体的。实际上拆开来看每一层都有独立的技术选型和替换空间。比如你可以用 Function Calling 但不用 MCP也可以基于 MCP 构建 Skill 但底层不用模型的原生 Function Calling 能力而是用提示词工程模拟。1.2 一张表看清三者的定位差异维度Function CallingMCPSkill所属层级模型能力层通信协议层业务抽象层解决什么问题模型如何表达调用意图工具如何被发现和调用业务能力如何复用和编排标准化程度各模型厂商格式不同统一协议规范无统一标准因业务而异典型载体JSON Schema 定义Server/Client 架构类、模块、配置文件谁在定义模型厂商协议社区业务开发者可替换性换模型可能需调整换实现不影响上层换业务逻辑不影响底层这张表建议反复看几遍。很多架构决策的困惑本质上是因为没搞清楚当前讨论的问题落在哪一层。2. Function Calling 的真实工作方式不只是调个函数那么简单Function Calling 这个词有很强的误导性。它听起来像是模型真的去执行了一个函数但实际上模型做的事情只有一件输出一段结构化的 JSON说明它想调用哪个函数、传什么参数。真正的函数执行发生在模型之外的应用程序里。2.1 一次完整的 Function Calling 到底经历了什么我拿一个实际场景来拆解。假设用户问帮我查一下北京今天的天气如果下雨就提醒我带伞。第一步应用程序启动时会把可用的函数定义名称、描述、参数 Schema一起发给模型。这些定义通常长这样{ name: getWeather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: { type: string, description: 城市名称 }, date: { type: string, description: 日期格式 yyyy-MM-dd } }, required: [city] } }第二步模型收到用户问题后判断需要调用getWeather于是输出一个结构化的调用请求而不是直接回答。这个输出里包含函数名和参数值。第三步应用程序解析这个请求真正去执行getWeather(北京, 2025-01-15)拿到结果比如{condition: rain, temp: 8}。第四步应用程序把函数执行结果作为一条新消息追加到对话历史里再次发给模型。第五步模型基于这个结果生成最终的自然语言回复北京今天有雨气温 8 度记得带伞。整个链路里模型只负责决策和表达执行永远是应用侧的事。理解这一点非常关键因为它决定了安全边界、错误处理、超时控制这些工程问题该在哪里解决。2.2 参数 Schema 设计是最容易翻车的地方我见过太多项目在 Function Calling 上踩坑根源几乎都出在参数 Schema 的设计上。模型不是人它对你的函数理解完全依赖于 description 和参数描述的质量。几个血泪教训description 写得太简略。你写查询天气模型不知道你支持哪些城市、返回什么格式、有没有日期限制。写清楚查询中国地级市及以上的当前天气返回温度摄氏度和天气状况模型的选择准确率会明显提升。参数没有约束。如果date参数不写格式要求模型可能传今天、2025年1月15日、01/15各种格式你的解析代码直接崩。函数粒度不合理。有人把查询天气和发送提醒塞进一个函数导致模型要么全调要么全不调失去了组合的灵活性。正确的做法是拆成原子化的函数让模型自己编排。提示参数 Schema 里的enum约束非常有用。如果某个参数只有固定几个取值一定要用 enum 列出来这能大幅降低模型传错值的概率。2.3 不同模型的 Function Calling 格式差异这是实际项目里很烦的一点。OpenAI 的函数调用格式、Anthropic 的 tool use 格式、国内各家模型的格式虽然思路一致但字段名和结构有差异。Spring AI 这类框架的价值就在这里——它做了一层抽象让你用统一的 API 写代码底层自动适配不同模型。但要注意抽象层不是万能的。某些模型特有的能力比如并行函数调用、强制调用某个函数在抽象层里可能没有对应接口。选框架之前先确认它对你目标模型的支持程度。3. MCP 要解决的真正问题工具体系的USB 接口如果说 Function Calling 解决的是模型怎么表达调用意图那 MCP 解决的是一个更宏观的问题当你有几十上百个工具分布在不同的服务里怎么让 AI 应用统一地发现、理解和调用它们3.1 没有 MCP 的世界有多乱在 MCP 出现之前每个 AI 应用集成工具的方式都是定制的。你要接一个数据库查询工具得写一套适配代码要接一个文件系统工具再写一套要接一个第三方 API又写一套。工具的定义格式、调用方式、错误处理各不相同。这就像早期的手机充电接口每个品牌一个样出门得带一堆线。MCP 想做的就是把这个接口统一成USB-C——不管什么工具只要实现了 MCP 协议任何支持 MCP 的 AI 应用都能直接接入。3.2 MCP 的核心架构Server 和 ClientMCP 采用典型的 Client-Server 架构MCP Server工具或数据源的提供方。它对外声明自己有哪些能力tools、resources、prompts并处理调用请求。MCP ClientAI 应用侧。它连接到一个或多个 MCP Server获取能力列表在需要时发起调用。通信上MCP 支持多种传输方式本地进程间通信用 stdio远程通信用 HTTP 或 WebSocket 类的长连接。这种设计让 MCP Server 可以跑在本地比如访问本地文件也可以跑在远端比如访问云端数据库。3.3 MCP 声明的三类能力MCP Server 可以暴露三种类型的能力这个划分很值得琢磨Tools工具可执行的函数模型可以主动调用。比如查询订单状态、发送邮件。这对应 Function Calling 的场景。Resources资源可读取的数据通常由应用侧决定何时加载。比如当前项目的配置文件、用户的历史订单列表。资源更像是给模型提供上下文而不是让模型主动操作。Prompts提示模板预定义的提示词模板可以由用户或应用触发。比如代码审查模板、周报生成模板。这个三分法体现了一个重要思路不是所有东西都该让模型主动调用。有些数据应该是被动提供的上下文有些操作应该是用户显式触发的。把这三者分开能让系统行为更可控。3.4 MCP 和 Function Calling 的衔接点很多人问既然有了 Function Calling为什么还需要 MCP答案在于规模和标准化。Function Calling 是单次对话内的机制工具定义跟着每次请求走。而 MCP 是持久化的服务发现机制工具定义通过协议动态获取。当你的工具数量少、变化不频繁时直接用 Function Calling 就够了。但当工具数量多、由不同团队维护、需要动态上下线时MCP 的价值就体现出来了。实际落地中MCP Server 暴露的 tools 最终会被转换成 Function Calling 的定义发给模型。也就是说MCP 是工具怎么组织和发现的答案Function Calling 是工具怎么被模型调用的答案。两者是上下游关系不是竞争关系。4. Skill 的本质把业务能力打包成可复用的积木Skill 这个词在不同平台含义不太一样但核心思想是一致的把完成某个业务目标所需的一切——工具、提示词、上下文、编排逻辑——封装成一个高内聚的单元。4.1 Skill 和 Function Calling 的根本区别一个 Function Calling 是原子的、无状态的、单一职责的。比如queryDatabase(sql)就是一个函数调用。一个 Skill 是复合的、可能带状态的、面向目标的。比如生成月度销售报告这个 Skill内部可能包含查询销售数据、计算同比环比、生成图表、套用报告模板、导出 Word 文档。这一系列操作对用户来说是一个整体对模型来说可能只需要触发一次。打个比方Function Calling 是厨房里的各种刀具Skill 是一道菜的完整菜谱。菜谱会告诉你用哪把刀、切什么、什么顺序下锅。4.2 Skill 的典型组成要素一个设计良好的 Skill 通常包含这几部分触发条件什么情况下该激活这个 Skill。可以是关键词匹配、意图识别也可以是模型自主判断。工具集合这个 Skill 需要用到哪些 Function Calling 或 MCP tools。提示词模板指导模型在这个场景下如何思考和回复的系统提示。上下文管理需要预先加载哪些数据需要维护哪些中间状态。输出规范结果以什么格式呈现有哪些质量约束。4.3 为什么 Skill 层不可或缺有人会问我把所有工具都通过 MCP 暴露出去让模型自己组合不就行了为什么还要 Skill 这层理论上可行实践中会出问题。当工具数量超过一定规模模型的组合能力会急剧下降——它会选错工具、漏掉步骤、参数传错。而且每次都要模型从零开始规划token 消耗大、延迟高、结果不稳定。Skill 的价值在于把经过验证的最佳实践固化下来。一个业务场景跑通之后把它的工具组合和提示词固定成一个 Skill下次遇到同类需求直接复用不需要模型重新规划。这既提升了稳定性又降低了成本。5. Java 落地全流程从零搭一个带 Skill 编排的 Agent前面讲的是概念现在进入实操。我用 Spring AI 作为基础框架因为它在 Java 生态里对 Function Calling 和 MCP 的支持相对成熟。整个流程分五步走。5.1 环境准备与依赖选择先明确技术栈JDK 17 或以上Spring AI 对高版本 JDK 支持更好Spring Boot 3.xSpring AI 的对应 starterMaven 依赖大致是这样dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-mcp-spring-boot-starter/artifactId /dependency这里有个选型要点模型提供商的选择会影响后续所有代码。如果你用 OpenAI 兼容接口的模型配置里改 base-url 和 model 名就行。如果用国内模型确认它是否兼容 OpenAI 的 Function Calling 格式不兼容的话需要额外的适配层。注意Spring AI 的版本迭代很快不同版本 API 差异较大。建议锁定一个稳定版本不要盲目追新。我踩过的坑是升级小版本后Tool注解的行为变了导致参数解析失败。5.2 用 Tool 注解声明 Function CallingSpring AI 提供了Tool注解可以把一个普通 Java 方法暴露成模型可调用的函数。这是最省事的做法。Component public class WeatherTools { Tool(description 查询指定城市的当前天气返回温度和天气状况) public WeatherResult getWeather( ToolParam(description 城市名称如北京、上海) String city, ToolParam(description 日期格式 yyyy-MM-dd) String date) { // 实际调用天气 API return weatherService.query(city, date); } }几个实操细节方法参数上的ToolParam描述会直接进入发给模型的 Schema写清楚能显著提升调用准确率。返回类型建议用结构化的 POJOSpring AI 会自动序列化成 JSON。返回纯字符串虽然简单但模型解析起来效果差。一个类里可以放多个Tool方法它们会被一起注册。5.3 接入 MCP Server 扩展工具来源如果工具来自外部服务通过 MCP 接入比自己写适配代码更规范。Spring AI 的 MCP starter 支持配置多个 MCP Server。配置示例spring: ai: mcp: client: servers: - name: database-server transport: stdio command: java args: [-jar, db-mcp-server.jar] - name: file-server transport: sse url: http://localhost:8080/mcp配置好之后MCP Server 暴露的 tools 会自动注册到工具列表里和本地Tool方法一起参与 Function Calling。对上层业务代码来说本地工具和远程工具没有区别。这里有个容易忽略的点MCP Server 的启动时机。stdio 方式下Client 会拉起 Server 进程如果 Server 启动慢第一次调用可能超时。建议在应用启动时做一次健康检查确认所有 MCP Server 就绪。5.4 构建 Skill 层做业务编排到了 Skill 层就是纯业务代码了。我的做法是定义一个 Skill 接口每个具体 Skill 实现这个接口。public interface Skill { String name(); String description(); String execute(SkillContext context); }然后实现一个具体的 Skill比如销售报告生成Component public class SalesReportSkill implements Skill { private final ChatClient chatClient; public String execute(SkillContext context) { return chatClient.prompt() .system(你是一个销售数据分析助手需要生成结构化的月度报告) .user(context.getUserInput()) .tools(weatherTools, databaseTools) .call() .content(); } }Skill 层的关键设计决策是哪些逻辑交给模型哪些逻辑写死在代码里。我的经验是数据查询、格式转换、文件生成这类确定性操作写死在代码里让模型只负责意图理解和结果润色。这样既稳定又省钱。5.5 把三层串起来一个完整的请求链路现在把整个链路串一遍。用户发来请求帮我生成本月销售报告。第一层应用侧的路由逻辑识别出这是报告生成意图匹配到SalesReportSkill。第二层Skill 内部调用 ChatClient把用户输入、系统提示、可用工具一起发给模型。这里的工具既包括本地Tool方法也包括通过 MCP 接入的远程工具。第三层模型判断需要先查数据输出 Function Calling 请求。应用侧执行查询把结果回传。模型再判断需要生成图表再次发起调用。如此循环直到模型认为信息足够生成最终报告文本。第四层Skill 拿到报告文本套用 Word 模板导出文件返回给用户。整个过程中MCP 负责工具的发现和连接Function Calling 负责单次调用的表达Skill 负责整体编排和业务逻辑。三者各司其职。6. 踩坑实录那些文档里不会写的细节概念和流程讲完了但真正让项目跑起来的是对这些坑的认知。以下都是我在实际项目里踩过的。6.1 工具描述写不好模型就是不用最典型的场景你精心写了一个工具模型死活不调用或者调用了错误的工具。九成情况下是 description 的问题。我的排查方法把发给模型的完整工具定义打印出来假装自己是模型看能不能仅凭这段描述判断出什么时候该用这个工具。如果连你自己都要想一下模型大概率会出错。一个技巧是给工具描述加上何时使用和何时不使用的说明。比如当用户询问订单物流状态时使用此工具如果用户只是询问订单金额不要使用此工具直接用订单查询工具。6.2 多轮调用中的上下文膨胀Function Calling 的每一轮调用都会往对话历史里追加消息。如果一个任务需要调用十几次工具对话历史会迅速膨胀token 消耗飙升甚至超出模型上下文限制。解决方案有两个方向一是减少不必要的调用轮次把能合并的工具调用合并二是对历史消息做摘要压缩把早期的工具调用结果替换成简短摘要。Spring AI 提供了对话记忆管理的抽象可以自定义压缩策略。6.3 MCP Server 的错误处理MCP 协议规定了错误返回的格式但实际实现里各家 Server 的行为不一致。有的 Server 在工具执行失败时返回错误码有的直接抛异常断开连接。我的做法是在 Client 侧加一层包装统一捕获异常并转换成模型能理解的错误消息。比如把连接超时转换成工具暂时不可用请稍后重试或换用其他方式。这样模型能优雅降级而不是直接卡死。6.4 Skill 粒度的把握Skill 切得太细等于没切每个 Skill 就一两个工具调用还不如直接用 Function Calling。切得太粗一个 Skill 包罗万象又失去了复用性。我的经验法则是一个 Skill 对应一个用户可感知的完整任务。用户说生成报告是一个任务说查一下数据是另一个任务。按用户视角切而不是按技术视角切。6.5 模型切换带来的连锁反应项目中途换模型是很常见的事但换模型可能引发一连串问题。不同模型对工具描述的理解能力不同对参数格式的遵循程度不同甚至对同一个提示词的响应风格都不同。建议在项目早期就做好模型抽象把所有模型相关的配置集中管理。切换模型时准备一套回归测试用例覆盖所有 Skill 的核心场景确保切换后行为一致。7. 三者协同的架构模式与选型建议讲到这里三者的关系应该比较清楚了。最后分享几种常见的架构模式以及不同场景下的选型建议。7.1 三种典型的架构组合轻量模式只用 Function Calling不引入 MCP 和 Skill。适合工具数量少少于 10 个、业务逻辑简单的场景。一个 Spring Boot 应用加几个Tool方法就能跑起来。标准模式Function Calling Skill工具本地声明。适合工具有一定规模、需要业务编排、但工具都由自己团队维护的场景。Skill 层提供复用和稳定性。平台模式Function Calling MCP Skill 全上。适合工具来源多样、需要跨团队协作、工具有动态上下线需求的场景。MCP 提供标准化的工具接入Skill 提供业务编排。7.2 选型的判断依据不要为了用而用。判断是否需要 MCP看你的工具是否满足这几个条件数量多、来源分散、需要独立部署和更新、有多个 AI 应用要共享。如果都不满足本地Tool就够了。判断是否需要 Skill 层看你的业务场景是否重复出现、是否需要稳定的输出质量、是否涉及多步工具编排。如果只是简单的问答加查询不需要 Skill。7.3 一个务实的演进路径我的建议是从简单开始按需演进先用 Function Calling 把核心功能跑通验证模型能力是否满足需求。当工具数量增长、开始出现复用需求时引入 Skill 层做编排。当工具需要跨团队共享、或者需要接入外部服务时再引入 MCP。每一步演进都由实际痛点驱动而不是提前过度设计。我见过太多项目一上来就搭全套架构结果大部分能力闲置维护成本还高。8. 关于 Java 生态的几句实在话Java 在 AI 应用开发上确实不如 Python 生态活跃但也不是不能用。Spring AI 这两年的进步很明显Function Calling、MCP、对话记忆、RAG 这些核心能力都有覆盖。实际用下来Java 的优势在于工程化——类型安全、依赖注入、成熟的 Web 框架、稳定的并发模型。当你需要把 AI 能力集成进一个已有的企业级系统时Java 的这套基础设施能省很多事。劣势在于新特性跟进慢。模型厂商出了新的调用格式Python SDK 可能当天就支持Java 这边要等框架更新。应对办法是保持对底层协议的了解必要时自己写适配层不要完全依赖框架。我在实际项目里的体会是把 AI 能力当成系统里的一个普通组件来对待用工程化的思路管理它——定义清晰的接口、做好错误处理、加上监控和日志、准备回归测试。这些传统软件工程的做法在 AI 应用里同样适用甚至更重要因为模型的行为本身就有不确定性外围的工程保障必须更扎实。最后分享一个小技巧在开发阶段把每次 Function Calling 的请求和响应都完整记录下来包括发给模型的工具定义。排查问题时这份日志比任何调试工具都好用。很多模型不听话的问题看一眼实际发出的工具定义就找到原因了。