深入理解 Skills：从 API 调用到智能体行为封装

引言

在构建 AI 应用时，我们常常听到 LLM API、Function Calling、Tools、Skills 等概念。它们之间到底是什么关系？底层逻辑又是如何运作的？本文将从第一性原理 出发，结合 Spring AI 的技术实践，带你彻底理清这些概念的本质区别与联系。

一、底层认知：一切始于无状态的 HTTP API

首先必须明确一个核心事实：对接大模型，底层永远是通过 HTTP API 接口进行无状态访问。

每一次请求都是独立的，大模型本身不记忆任何上下文。我们常说的"对话记忆"、"多轮交互"，本质上都是在客户端（如 Java 服务）侧维护状态 ，通过将历史消息和工具结果重新塞入下一次请求来模拟"有状态"的行为。

这个认知是理解所有上层概念的基石。

二、Function Calling：让模型"伸出援手"

Function Calling 的出现，打破了纯文本交互的局限。

本质：大模型不再仅仅返回纯文本，而是可以返回结构化的 JSON 指令 （包含函数名和参数）。客户端解析这个 JSON，本地调用对应方法，然后将执行结果再次发送给大模型，最终生成自然语言回复。

关键流程：

开发者将**工具定义（名称、描述、参数 Schema）**合并到请求中发给大模型。
大模型判断是否需要调用工具，如需调用，则返回 tool_calls 的 ID 和参数。
客户端执行本地方法，将结果回传给大模型。
大模型根据结果生成最终回答。

核心价值 ：大模型通过 Function Calling 获得了"伸出援手"的能力，可以操作外部世界。

三、Tools：Function Calling 的泛化与资源抽象

Tools 是 Function Calling 的泛化和扩展。

如果说 Function Calling 强调"函数调用"，那么 Tools 则更强调**"外部能力接入"**。它不仅仅局限于本地函数，还可以是：

外部 API（如查询天气、发送邮件）
数据库操作（如 SQL 查询）
脚本执行（如 Python 脚本）
文件系统操作

在 Spring AI 中，@Tool 注解和 ToolCallback 接口提供了统一的工具注册与调用机制。Tools 本质仍是函数调用，但抽象层次更高 ，它代表了一个可被模型调用的能力单元。

四、Skills：多工具编排与智能体行为封装

Skills（技能） 是站在 Tools 之上的高层封装 。它不是单个工具，而是多个工具的编排 + 推理步骤（Chain of Thought） 的组合。

4.1 Skill 的底层逻辑（核心）

我在实践中理解的 Skill 底层逻辑是这样的：

Skill 类似于一个大号的 Tool 说明 。一方面，它描述了 Skill 适用的场景；另一方面，它将场景、思考过程、执行脚本 等信息发送给大模型，同样是通过 Function Calling 机制实现的。

但与普通 Tool 不同的是，Skill 内部包含了完整的推理和执行计划。

4.2 为什么需要分级处理？

一个重要原因是：适应大模型一次处理 message 的信息量有限的问题。

为了解决上下文窗口的限制，Skill 通常将信息分为目录（摘要） 和详细内容 进行分级多次调用：

目录（摘要） ：即 Skill 的场景描述。第一次全部发给大模型，用于匹配。
详细内容 ：包括思考过程（推理链） 和执行脚本（参数定义）。只有在匹配成功后，才会在后续轮次中动态拼装发送。

4.3 Skill 的典型执行流程（三轮交互）

以我拆解的实现为例，Skill 的执行通常分为三轮：

轮次	阶段	发送内容	模型输出	客户端动作
第一轮	匹配阶段	所有 Skill 的名称、简短描述（场景）	决定"哪个 Skill 可能有用"	选中目标 Skill
第二轮	规划阶段	选中 Skill 的详细指令（Prompt Template） + 思考示例（Few-shot）	生成结构化的执行参数（JSON）	解析参数，准备本地执行
第三轮	执行阶段	本地执行脚本（`@Tool` 方法）	（等待结果回传）	将执行结果再次发回大模型，生成最终自然语言回复

注意：这不是"一次性发给大模型"，而是多轮、动态拼装的过程，目的正是为了应对上下文窗口有限的问题。

五、一图看懂：五者的本质区别与联系

5.1 演进关系

复制代码

访问 LLM API（基础）
        ↓
   （增加结构化工具体系）
        ↓
   Function Calling（原子能力）
        ↓
   （扩展为资源抽象层）
        ↓
   Tools（工具泛化）
        ↓
   （引入规划与编排）
        ↓
   Skills（智能体行为封装）

5.2 对比表格

维度	访问 LLM API	Function Calling	Tools	Skills
输入输出	纯文本 ↔ 纯文本	文本 ↔ 结构化 JSON 指令	文本 ↔ 结构化指令 + 外部资源	文本 ↔ 文本 + 多个外部动作 + 最终回答
模型职责	仅生成文本	生成函数名 + 参数	同 Function Calling，但强调资源定位	生成执行计划，并分步决策
客户端职责	仅展示文本	解析 JSON → 调用本地方法 → 结果回传	同左，但支持多资源类型	状态管理 + 多轮循环 + 上下文拼接
是否改变模型状态	否（无状态）	否（无状态，但附加了工具定义）	否（无状态）	否（无状态，但通过多轮请求模拟有状态）
复杂度	低	中	中	高
典型场景	知识问答、翻译	查天气、发邮件	查询数据库、调用第三方 API	自动订机票酒店、智能客服全流程

六、Spring AI 中的实现映射

在 Spring AI 框架中，这些概念的具体对应关系如下：

概念	Spring AI 实现
访问 LLM API	`ChatClient` 或 `ChatModel.call(prompt)`
Function Calling	`@Tool` 注解 + `FunctionCallback` 注册
Tools	`ToolCallback` 接口 + `ToolExecutionChain`（可批量注册）
Skills	非内置，需自行用 `ChatClient` + `PromptTemplate` + 状态机实现

⚠️ 特别注意 ：Spring AI 官方未直接提供 Skill 抽象，它只提供了 Tools 层。如果你看到"Skill"这个概念，通常是在社区扩展或自定义 Service 层实现的。

因此，在 Spring AI 中实现 Skill ，本质上就是用 Java 写一个状态机或循环控制器，把多个 Tools 的调用串起来，并在每次调用前后动态修改 Prompt ------ 这正体现了我前面提到的"分级多次调用"的精髓。

七、一句话总结

LLM API 是"嘴巴"，Function Calling 是"手"，Tools 是"工具箱"，Skills 是"大脑指挥手用工具箱完成复杂任务"的整套流程。

它们共享无状态的 HTTP 通道 ，但复杂度依次递增，上层向下层请求原子能力，下层向上层提供执行基础。理解这套演进逻辑，是设计和实现高效 AI Agent 的关键。

如果你正在 Spring AI 中构建 Skill 能力，希望这篇文章能帮你少走弯路。欢迎在评论区交流你的实现思路！