Skill

0 序

前置知识:

[AI/LLM/Agent/工具调用] Function Calling（函数调用）：让大模型"动手干活"的【标准化工具调用机制】 - 博客园/数据知音

[AIGC/Agent] MCP := 模型上下文协议 := AI Agent应用与外部系统集成的标准协议 - 博客园/千千寰宇

[AI应用] AI Agent Skill综述：告别Prompt炼丹，把AI的“经验”封装成可复用的工程资产 - 博客园/数据知音

1 概念辨析：Function Calling (Tool Use) / MCP / Skill

1.1 综合对比

1）多维度对比 | FC/Tool:【工具调用】时必选、MCP: 【工具调用】时可选、Skill：可对【工具调用】等AI Agent组件统一编排的SOP/SubAgent

维度	Function Calling	Tool	MCP	Skill
本质	模型输出结构化调用请求的接口机制	可被调用的原子能力实体	工具发现/描述/调用的开放协议	指令+脚本+资源的可复用能力包
回答的问题	模型怎么表达"我要调用你"	有哪些能力可用	工具怎么被标准接入、跨应用复用	某类任务怎么按 SOP 稳定完成
抽象层级	① 最底层（推理 API 语义）	② 能力本体层（执行对象）	③ 工具标准层（应用间协议）	④ 工具封装层（流程编排）
粒度	单次调用请求	单函数	一批工具+资源+提示词	多步流程，可内含多个工具调用
是否执行	否（纯决策+格式化）	是（由你的应用代码/MCP server 执行）	MCP Server 执行工具并返回	加载指令进上下文；可能含(curl/bash等)脚本或Tool可被调用
可见性	每次请求全量注入（占 token）	LLM 在 tool_use 中按名引用	动态发现（tools/list），按需	渐进式披露：启动只见元数据，命中才加载全文[4][6]
生命周期	请求内	应用内注册一次	跨 Host/Client/Server 共享	目录形态，可分发、可版本管理
类比	函数调用的 ABI / 接口约定	一个 API / 函数本体	USB-C / LSP（连接标准）	专业工具套装 / 任务说明书
代表性实现	OpenAI `tools` 参数、Claude `tool_use`	自定义函数、web_search、code_execution	MCP Server（filesystem/github/postgres…）	Anthropic Agent Skills、OpenAI Skills、豆包 Skills[5]

2）底层关系：AI应用中，一次真实调用里它们，看怎么协作

这4个东西不是互斥选项，而是同一条调用链上的不同环节。

看一次"用户提问 → 得到答案"的完整数据流：

sequenceDiagram participant U as 用户 participant Agent as Agent/编排器 participant LLM as 大模型 participant FC as Function Calling 机制 participant T as Tool(本地函数) participant MCP as MCP Server U->>Agent: "帮我审查这个 PR" Note over Agent: ① Skill 层：编排器判断任务类型， 按需加载"PR审查"Skill(指令+SOP) Agent->>LLM: 加载 Skill 内容 + 任务 LLM->>FC: ② FC 层：模型决策，输出结构化意图 tool_use(read_file, "pr/123") FC->>T: ③ Tool 层：本地工具直接执行 FC->>MCP: ③' 外部工具经 MCP 路由 tools/call(github, ...) T-->>FC: 返回结果 MCP-->>FC: 返回结果 FC->>LLM: ④ 结果回传，模型继续推理 LLM-->>Agent: 生成最终审查意见 Agent-->>U: 展示结果

这条链路揭示的底层关系：

Skill 在最高层——它是"指挥者视角"的编排单元，LLM 通常看不到 Skill 内部，只看到它包装出的高层能力（如"审查这个 PR"）[3]；

FC 在最底层——它是模型与一切工具之间唯一的"语言"，无论 Tool 是本地的还是经 MCP 来的，最终都转成 function call 给模型[1][2]；

Tool 与 MCP 是平级互补的——本地工具直接跑，外部工具经 MCP 标准化路由出去，两者都是"执行单元"[1]；

MCP 最终必须落回 FC——MCP 解决"工具从哪来、怎么描述"，但它本身不产生调用语义，落地时仍调用模型的 function calling[2]。

1.2 四大分层 | 工具封装层/Skill:SOP内编排 -> 工具标准层/MCP:暴露/发现/路由 -> 工具能力层/Tool:能力本体 -> 工具机制层/FC:模型表达调用意图的机制

flowchart TB subgraph L4["④ 工具封装层 · Skill（SOP内可编排Tool;能力包/经验包/）"] S["Skill = 指令(SKILL.md) + 脚本 + 资料 + SOP 按需加载 · 渐进式披露 · 可编排多个工具（Tool）"] end subgraph L3["③ 工具标准层 · MCP（协议/路由/暴露/分发）"] M["MCP = 工具发现/分发/复用的开放协议 MCP Server 是 Tool 的来源容器"] end subgraph L2["② 工具能力层 · Tool（实体/本体）"] T["Tool = 可被调用的原子能力单元 本地函数 / API / 厂商内置能力"] end subgraph L1["① 工具机制层 · Function Calling（语言）"] FC["FC = 模型表达'调用意图'的机制 输出 name + 结构化 arguments，不执行"] end S -->|"编排/加载"| T T -->|"部分经"| M M -->|"最终转成"| FC T -->|"被模型经"| FC

1.3 Function Calling vs. Tool : FC是调用方式与机制、Tool是被调用对象

**Tool 是名词（对象），FC 是动词（机制）

MCP 是副词（怎么连），Skill 是句子（一段完整的能力表达）。**

Tool 是"被调用的东西"，FC 是"调用它的方式"

MCP 是"它怎么被发现和到达"，Skill 是"把多个词句组织成一段完整表达"。

1.4 Function Calling vs. MCP Tool: 地基 vs 可选层、MCP Tool 基于FC构建、工具调用默认选FC、跨团队复用时选MCP （必读）

基于 Function Calling 地基的 MCP Tool 的经典工作流程

以 AI Agent 的本地工具调用（MCP Tool by stdio 传输）为例：

特征：MCP Server 以子进程方式跑在本地，通过 stdin/stdout 与 Client 通信；Claude Desktop、Trae、Cursor 桌面版默认走这条路。注意初始化握手（initialize → initialized）是每个会话的必经步骤。

sequenceDiagram autonumber participant U as 用户 participant H as MCP Client(Host) Claude Desktop / Trae participant L as 大模型(LLM) participant S as 本地 MCP Server filesystem / sqlite / 自研 rect rgb(230,240,255) Note over H,S: ① 初始化握手（每个会话一次） H->>S: 启动子进程，建立 stdio 通道 H->>S: initialize(protocolVersion, capabilities) S-->>H: serverInfo + capabilities (tools/resources/prompts) H->>S: notifications/initialized end H->>S: tools/list S-->>H: [get_weather, read_file, query_db ...] U->>H: "北京今天天气怎么样？" H->>L: 用户消息 + 工具清单(转成 function call) L-->>H: tool_use(get_weather, {city:"北京"}) H->>S: tools/call(get_weather, {city:"北京"}) S-->>H: {temp:18, condition:"晴"} H->>L: 工具结果回传(再走一次模型推理) L-->>H: "北京 18℃，晴" H-->>U: 展示回答

要点：

tools/list 是动态发现—— 工具清单在运行时获取，而非硬编码，这是 MCP 与 "直接把工具塞进 prompt" 的本质差异；

图中的 tool_use → tools/call 恰好印证了：MCP 的工具最终仍通过 Function Calling 机制呈现给模型。

对比总结

MCP 的 Tool 最终都要转成 function calling 给模型，这一环确实建立在 FC 机制之上

从技术发展的时间线，也是：先有 Function Calling，后有 MCP。

MCP 除了 Tool 原语，还包含 Resources（资源）、Prompts（模板）、Sampling、Elicitation 等原语，这些 Function Calling 根本不覆盖；
MCP 解决的是工具的【发现】与调用、分发、跨应用复用（协议层），Function Calling 解决的是 "怎么调"（更底层的地基）。
既然 MCP Tool 是基于 Function Calling 了，是否还有必要再单独写 Function Calling。AI Agent 领域，写 Function Calling 的多，还是写 MCP Tool 的多？

仍有必要写 Function Calling。二者不是替代关系，是 "【地基:FC】 vs 【可选层:MCP】"：

FC 是必写层：模型调用工具的底层机制，MCP 落地也依赖它；单应用、工具少、路径明确时直接用 FC 最轻量（零服务器、零协议、零额外依赖）；

MCP 是可选层：只有 "多个客户端 / 多个团队要复用同一批工具" 时才值得引入协议开销。

FC 和 MCP 的业界，写哪个多？—— 目前直接写 Function Calling 的仍是绝对多数，但生产里两者混用。

大厂 Agent 团队原话："【工具调用】全走原生 Function Call，灵活、轻量、没额外依赖"，痛点只在 "【跨团队复用】" 时暴露，此时才上 MCP；

2026 年业界共识是分层混用：共享工具走 MCP、模型原生推理走 FC，二者互补而非二选一；

MCP 生态增长快，但主要覆盖 "跨客户端复用" 通道；单个 Agent 内部的工具定义仍以 FC 直连为主流。

1.5 Tool vs. Skill : Tool=底层的可执行函数、Skill=上层(对各Agent组件)的编排者

这2个经常任意被混淆。

Tool = 底层的可执行函数：一次调用，一个动作，有副作用（写库、发请求）；
Skill = 上层(对各Agent组件)的编排者、指令包：本质是上下文工程，把知识、SOP、模板打包，靠"加载进模型上下文"发挥作用，不一定要有副作用；但它内部可以含可执行脚本，脚本里又能编排多个 Tool 调用。

所以: Skill 是 Tool 的上层组织者，而不是 Tool 的替代品。
一个 Skill 内部可以串联 read_file → 解析 AST → LLM 推理 → 写评论 多个工具。

1.6 深刻的观点（From 千问AI）

近日看到阿里巴巴的【千问AI团队】于2026年2月26日在其成员【沈询】在公众号发布的: AI Agent系列｜深入解析Function Calling、MCP和Skills的本质差异与最佳实践 - Weixin/千问AI平台/沈询一文，除了与本篇的总体观点基本一致外，还有几个深刻的观点来加强理解：

AI Agent工具调用的基本流程

Step1、LLM接收用户请求和工具描述

用户提出需求（比如"帮我查一下北京今天的天气"）

系统向LLM提供可用工具的列表和描述（比如"天气查询工具：可以查询指定城市的天气信息"）

Step2 LLM决定是否需要调用工具

LLM根据用户需求和工具描述，判断是否需要调用工具

如果需要，LLM会生成结构化的工具调用请求
这里的关键是: LLM返回的是结构化的JSON格式，而不是自然语言。比如用户说"帮我查一下北京今天的天气"，LLM可能会返回：

{
  "id": "chatcmpl-abc123",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": null,
        "tool_calls": [
          {
            "id": "call_abc123",
            "type": "function",
            "function": {
              "name": "get_weather",
              "arguments": "{\"city\": \"北京\", \"date\": \"today\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ]
}

这种结构化的输出格式，就是Function Calling的核心机制。它让系统能够稳定地解析LLM的意图，而不需要复杂的文本解析逻辑。注意关键字段：

tool_calls：当需要调用工具时，这里包含工具调用的信息；

function.name：要调用的工具名称；

function.arguments：工具的参数（JSON字符串格式）；

Step3 应用系统做解析、并执行工具调用

系统解析LLM生成的工具调用请求；

执行对应的工具函数（比如调用天气API）；

获取工具执行结果还是以上面的llm返回为例；
上面的JSON格式会被系统解析并转换为真正的函数调用。以JavaScript为例：


// 1. 从LLM响应中提取工具调用信息
const toolCall = response.choices[0].message.tool_calls[0];
const functionName = toolCall.function.name;  // "get_weather"
const functionArgs = JSON.parse(toolCall.function.arguments);  // {city: "北京", date: "today"}

// 2. 根据工具名称找到对应的函数
const tools = {
  get_weather: (city, date) => {
    // 执行天气查询逻辑
    return `北京今天天气：25°C，晴天`;
  },
  // ... 其他工具
};

// 3. 执行工具调用
const result = tools[functionName](functionArgs.city, functionArgs.date);
// 实际调用：tools["get_weather"]("北京", "today")

这个过程是自动的：系统根据function.name找到对应的函数，解析function.arguments获取参数，然后执行调用。这就是Function Calling让【工具调用】变得可预测和可靠的核心机制。

Step4 将结果返回给LLM

工具执行结果被返回给LLM；

LLM根据结果决定下一步行动（继续调用工具，或者生成最终回答）。

【工具调用/Function Calling】的本质：`LLM`必须想办法在两种信息形式之间架起桥梁：将非结构化的用户需求转换为结构化的函数调用，才能完成对【外部系统】的交互 —— MCP / Skill 存在的基础

这个流程的核心在于：

LLM需要把用户的非结构化需求（一段自然语言文本）转换为结构化的函数调用（函数名和参数），然后与其他应用程序交互，再将结构化结果返回给模型，让模型能够基于这些结果进行下一步决策。

问题的本质在于，历史上其他系统（数据库、API、文件系统等）只能处理结构化信息，而LLM擅长处理非结构化信息（文本）。

因此，LLM必须想办法在两种信息形式之间架起桥梁：将非结构化的用户需求转换为结构化的函数调用，这样才能与外部系统交互——这就是Function Calling机制的本质，也是后面MCP和Skills能够存在的前置条件。

既然有了【工具调用】，为什么又会有MCP和Skills呢？

1）工具的集成成本太高: MxN 的集成复杂度 => `MCP`产生的原因：提供一个服务，可以让既有系统快速集成到LLM中（M+N的复杂度）

Function Calling确实解决了核心问题：让LLM能够稳定地输出结构化的工具调用请求，实现了非结构化→结构化"的转换，并获得【外部系统】的响应结果。这是 AI Agent 工具能力的基础。

但在实际应用中，开发者很快发现了一个新的问题：工具的集成成本太高。

Function calling会有工具集成成本高的问题

现实世界中，有大量的既有系统和数据：数据库里存储着业务数据，文件系统里有各种文档和代码，GitHub上有项目仓库和Issue，dingding里有团队沟通记录，还有各种API服务提供实时数据。这些既有系统里有着丰富的信息，如果能让LLM直接使用这些系统和数据，AI Agent的能力会大大增强。

但问题是：如何让LLM能够使用这些既有系统？
在Function Calling的框架下，每个既有系统都需要【单独集成】到AI应用中。每个组织或公司都有自己的API、认证方式、数据格式，开发者需要为每个组织或公司编写对应的函数实现。这就是MCP产生的原因：提供一个服务，可以让既有系统快速集成到LLM中。

MCP的核心: MCP Tool 原语——其实还是基于Function Calling的。它做的事情很简单：把Function Calling的调用，在客户端转换成一套JSON+HTTP的请求。然后提供一套MCP Server来响应这个JSON+HTTP请求，这样就能实现各类应用都可以被LLM使用的效果。

LLM -> Function Calling -> MCP Client -> JSON+HTTP请求 -> MCP Server -> 既有系统（GitHub/Slack/数据库等）
                                                                    ↓
LLM <- Function Calling结果 <- MCP Client <- JSON响应 <- MCP Server <- 既有系统返回结果

2） Function Calling和MCP都会有任务流程定义困难的问题 => Skill 产生的原因: 提供一个方式，让用户可以用文字定义指令、脚本和资源，形成可复用的Agent任务流程

MCP解决了工具的集成问题后，但又出现了另一个问题: Function Calling和MCP都会有任务流程定义困难的问题

在实际使用中，用户经常需要让AI Agent按照特定的方式执行任务。比如，格式化Excel表格要按照公司的品牌指南，法律审查要遵循特定的合规性要求，数据分析要按照组织的工作流程。这些任务往往需要复杂的提示词和多个步骤的组合。

但在Function Calling和MCP的框架下，用户面临一个两难的问题：当前的大模型很难仅仅依托自己的模型能力就做出最优的工具调用步骤。很多任务需要特定的执行顺序、规则和约束，但把这些步骤全部写成代码又不太现实。就像之前讲的，【模型的核心优势】是面对不确定性时可以走一步看一步，动态调整策略。如果全部落成程序，就会丧失模型的核心优势。

举个例子，我们以Lynxe项目中实际在跑的一个new_branch流程定义为例，我这个流程用文字写到一个markdown里面，每次都让模型遵照执行：

1) 确认本地的 VERSION 与 pom.xml 与 本地branch 中的版本一致，不一致的话以pom.xml为准
2) mvn package 
3) 进入 ui-vue3 运行pnpm lint 
4) 退回项目目录， git merge upstream/main
5) 项目目录，运行 make ui-deploy
6) git 提交 branch到origin
7) git 打包 tag名字与pom的版本号一致，先删除远程tag（如果存在）：git push upstream :refs/tags/v{版本号}，然后上传tag到 upstream (上传之前请先用git remote 看一下upstream是哪里，确认是spring-ai-alibaba/JManus)

这个流程有7个步骤，每个步骤都有特定的顺序、条件和规则。
如果完全写成代码，每一步都要处理各种异常情况（比如版本不一致、tag已存在、upstream地址不对等），代码会变得非常复杂。
但如果只给模型一个简单的提示词"帮我创建新分支"，模型可能无法按照这个精确的流程执行，或者执行顺序不对。
而用文字表达，非常直接简单，而且实际跑的过程中只有很小的概率会出错，非常爽。

而这就是这个问题的本质：如何在尽可能的准确的前提下，能让用户能用文字（而非代码）指导模型按照特定的流程和规则执行任务？

这就是Skills产生的原因（其实也是Lynxe的Func-Agent项目产生的核心原因）：提供一个方式，让用户可以用文字定义指令、脚本和资源，形成可复用的Agent任务流程。

3) `Skills`的核心也是基于`Function Calling`的 => 把"加载文档"这个操作封装成一个FC函数，然后让 AI Agent 在需要时自动调用

继续上一观点的延续。

Skills的核心其实也是基于Function Calling的。

它做的事情很巧妙：通过一个固化的函数和参数，让【模型】去查找和加载固定的【skills】文档。

这里的关键是，Skills完全依赖于Function Calling这个基础能力。
如果没有Function Calling，Skills就无法工作。Skills只是在Function Calling之上的一个巧妙应用：把"加载文档"这个操作封装成一个函数，然后让Claude在需要时自动调用。

具体工作流程是这样的：

初始化阶段：用户用文字定义指令、脚本和资源，打包成Skills（包含SKILL.md和可选的脚本、参考资料等）。

Claude在启动时会读取所有Skills的元数据（名称和描述），这些元数据被加载到模型的上下文中（每个约100 token）。

发现阶段：当用户发起请求时，Claude会根据请求内容，对比已加载的Skills元数据，判断是否需要使用某个Skill。

这个判断过程本质上就是LLM根据上下文做决策，跟Function Calling中判断是否需要调用工具是一样的。

加载阶段（Function Calling）：如果Claude判断需要某个Skill，它会通过Function Calling机制调用一个专门的加载函数（类似load_skill(skill_name)），将对应的SKILL.md文档内容读取并加载到当前上下文中。

这一步完全依赖Function Calling的能力。

执行阶段（继续使用Function Calling）：SKILL.md的内容（包含指令、流程、示例等）被加入到上下文后，Claude按照文档中定义的指令执行任务。

如果SKILL.md中定义了需要执行脚本（比如scripts/rotate_pdf.py），Claude还是会通过Function Calling调用执行脚本的函数。如果需要加载参考资料，同样是通过Function Calling调用读取文件的函数。

可以看到，整个Skills的运行过程，从加载文档、执行脚本到读取资源，每一步都离不开Function Calling。
Skills并没有创造新的能力，它只是把Function Calling这个基础能力组织成了一个更易用的形式：
    让用户可以用文字定义流程，让Claude自动发现和加载相关知识。 

从本质来说，他替代的是 mcp 调用的函数里面，过去可能会用代码写的一套串接各种API的逻辑流程，用这种方式，可以增强流程的适应性，其实也是呼应了我们的核心观点：

AI Agent将决策权完全下放给了 Agent 和 Prompt，能够解决【原有的编写应用程序】不能解决的问题——比如处理不确定性、动态调整策略、理解自然语言意图等。

Claude 判断是否需调用某 Skill（基于请求内容匹配已加载的 skill_name 与 description）
↓
若需要，则通过 Function Calling 调用 load_skill(skill_name)
↓
将对应 SKILL.md 的内容注入当前上下文，作为执行指令依据
↓
Claude 依照 SKILL.md 中定义的流程执行任务
↓
在执行过程中，按需通过 Function Calling：
  • 调用 bash 执行附带脚本
  • 调用 read_file 读取所需资源文件
↓
整合执行结果

Function Calling、MCP、Skills的核心定位

1）MCP、Skill 均基于 Function Calling 之上构建

通过前面的分析，我们可以看到Function Calling、MCP和Skills三者之间的本质关系：MCP和Skills都是基于Function Calling的，它们只是在Function Calling这个基础能力之上的不同应用方式。

2）MCP的核心: 解决与既有业务系统的对接问题（尤其是在【跨应用、跨平台、跨团队】条件下）

MCP的核心: 解决与既有业务系统的对接问题（尤其是在【跨应用、跨平台、跨团队】条件下）

实际上，与外部系统接驳的方法并不只有MCP这一种——我们完全可以用curl、bash等传统方式来与程序接驳。
MCP的价值在于它提供了一套标准化的接驳协议，让不同的工具和数据源能够以统一的方式被LLM使用。
通过JSON-RPC协议和标准化的工具描述格式，MCP降低了工具集成的成本，让开发者不需要为每个系统单独编写集成代码。
但本质上，MCP更偏重是一套接驳标准，而不是唯一的接驳方式。

3）Skill作为SubAgent，让用户可以用【自然语言】来定义标准化的业务流程；让LLM可根据实际情况动态调整策略，以理解【用户意图】、处理【不确定性】 => 与【高确定性】的传统软件相反，Agent 将决策权下放给LLM模型、Prompt，以拥抱【不确定性】

Skills则实际上是一个sub-agent的包装

它让用户可以用文字来编写业务流程，替代了过去在MCP调用的函数里用代码写的一套串接各种API的逻辑流程。
这种方式可以增强业务流程的环境适应性——因为【模型】可以根据实际情况动态调整策略，处理不确定性，理解自然语言意图。
这正是先前提到的核心观点：Agent将【决策权】完全下放给了【模型】和【Prompt】，能够解决原有写程序不能解决的问题。
但代价就是不可能100%准确，因为模型的行为存在不确定性，无法像【传统应用代码】那样保证完全可预测的执行结果。

MCP与Skills的生存关系：竞争 + 合作（双方均可整合多个系统，仅实现范式不同）

虽然很多人认为MCP和Skills是互补关系，但实际上，这两者更多是竞争关系。这种竞争主要体现在它们解决的是同一个问题：如何整合多个既有系统，实现复杂的多步骤任务。
要理解它们的竞争关系，我们需要回到Function Calling的本质：LLM要实现工具调用，实际上最需要的内容只有：函数名、参数要求，以及一个description。

基于这个前提，我们来看看MCP和Skills的不同解决思路：

MCP的解决思路：通过标准化的协议和Server架构，引入了一个新的协议转换Server（这个Server可以用Node.js、Python或其他语言来实现）。但这个协议转换层往往也只是先做了函数调用的协议转换，然后再增加一个description，打包，发布。这个流程是非常薄的——它本质上只是在Function Calling的基础上，增加了一层JSON-RPC协议转换。

Skills的解决思路：选择了更简单的办法，可以不需要这层协议转发Server，直接用bash以参数形式调用，结果其实是一样的，还更省事。

换句话说，MCP的JSON-RPC可以被直接替换为命令行脚本或curl远程调用，在本地直接调用。这样甚至都不需要额外做MCP封装了。
而且在这个基础上，Skills还能支持更复杂的流程定义——通过SKILL.md文档告知LLM如何组合多个接口调用，所以长流程任务的成功率会更高。

这就是为什么说它们存在竞争关系：当用户选择使用Skills时，他们就不需要在MCP Server的函数中编写复杂的串接代码了；反之，如果选择在MCP Server中实现完整逻辑，Skills的价值就会降低。

它们解决的是同一个问题（如何整合多个既有系统），但采用了不同的方法（协议转换Server+代码型流程定义 vs 直接命令行调用+文字化流程定义）。

总结：三者的对比表

维度	Function Calling	MCP (Model Context Protocol)	Skills (Claude Skills)
定位/本质	AI Agent调用工具的基础能力，将非结构化需求转换为结构化函数调用	标准化接驳协议，提供统一的方式让LLM与外部系统交互	sub-agent的包装，让用户用文字定义可复用的任务流程
解决的问题	将用户的非结构化需求（自然语言）转换为结构化的函数调用（函数名和参数），实现LLM与外部系统的交互桥梁	工具集成成本高：每个既有系统都需要单独集成，每个组织都有自己的API、认证方式、数据格式	任务流程定义困难：需要特定执行顺序、规则和约束，但写成代码会丧失模型灵活性优势
实现方式	LLM生成结构化的JSON格式输出（tool_calls字段包含function.name和function.arguments），系统解析并执行对应函数	基于Function Calling，将调用转换为JSON-RPC协议和HTTP请求；采用MCP Client/Server架构，通过标准化的工具描述格式（JSON Schema）定义工具	基于Function Calling，通过固化函数load_skill()查找和加载SKILL.md文档；采用渐进式披露机制（元数据→SKILL.md→资源），支持自动发现和按需加载
适用场景	所有工具调用的基础，任何需要LLM调用外部功能的场景	与既有系统接驳：GitHub、Slack、数据库、文件系统、各种API服务等需要统一接入的场景	需要特定流程和规则的任务：代码审查、部署流程、文档格式化、合规性检查等需要文字化流程定义的场景
替代方案	可以要求模型用固定格式输出替代，但因为模型对func-call做过很多优化，实际遵循程度来说FC还是目前最优解	可以用curl、bash调用等传统方式与调用既有程序，MCP更偏向是一套侧重于【跨应用/平台/团队】调用时的接驳标准而非唯一方式（这也是目前的实践，用bash掉python/java其实比mcp更简单）	可以用代码替代（在MCP调用的函数里写代码串接各种API），但会失去处理不确定性、动态调整策略的能力

1.X 小结：选型决策——什么时候用哪个

需求	该用哪个	原因
让模型能调用你自己的几个函数/API	Tool + Function Calling	最直接，一个 app 内即可，无需引入协议
跨应用/跨团队复用同一套工具（Cursor/Claude/自己 app 共用）	MCP	一次实现，处处可用，避免每个 app 重写一遍
让 Agent 稳定完成一类复杂任务（含多步 + 领域知识 + 规则）	Skill	把 SOP/经验沉淀成可复用的能力包，按需加载不撑爆上下文
纯格式约束、无副作用（抽取结构化数据）	Structured Outputs	不需要工具往返，别引入 FC 开销
大型 Agent 批量任务	全部组合	Skill 编排 → Tool 执行 → MCP 分发外部能力 → FC 贯通

Y 推荐文献

https://github.com/spring-ai-alibaba/Lynxe

X 参考文献

posted @ 2026-08-27 13:09 数据知音阅读(4) 评论(0) 收藏举报

刷新页面返回顶部