Tools

Function Calling、MCP 和 Skills - Why-What-How 框架解析

Function Calling、MCP 和 Skills 完全解析

🔧
Function Calling(函数调用)

Why:为什么需要它?

LLM 擅长处理非结构化信息(自然语言文本),但现实世界的外部系统(数据库、API、文件系统等)只能处理结构化信息。需要一个桥梁将用户的自然语言需求转换为结构化的函数调用,让 LLM 能与外部系统稳定交互。

What:它是什么?

AI Agent 调用工具的基础能力,是 MCP 和 Skills 能够存在的前置条件。它让 LLM 生成结构化的 JSON 格式输出,包含函数名和参数,而非自然语言。

核心机制

  • LLM 返回 tool_calls 字段,包含 function.name(工具名)和 function.arguments(参数)
  • 系统解析 JSON 并执行对应函数,无需复杂的文本解析逻辑

How:如何实现?

{ "tool_calls": [{ "function": { "name": "get_weather", "arguments": "{\"city\": \"北京\", \"date\": \"today\"}" } }] }

系统解析 → 找到对应函数 → 执行调用 → 返回结果给 LLM → LLM 生成最终回答

🔌
MCP(Model Context Protocol,模型上下文协议)

Why:为什么需要它?

Function Calling 虽然解决了调用问题,但工具集成成本太高。每个组织都有自己的 API、认证方式、数据格式,开发者需要为每个系统单独编写集成代码。MCP 旨在提供标准化的接驳协议,降低工具集成成本。

What:它是什么?

由 Anthropic 推动的开放标准(已捐赠给 Linux 基金会),为 LLM 应用提供标准化接口以连接外部数据源和工具。本质上是一套协议转换层,基于 Function Calling 实现。

How:如何工作?

LLM → Function Calling → MCP Client → JSON-RPC/HTTP请求 → MCP Server → 既有系统(GitHub/Slack/数据库等) ↓ LLM ← Function Calling结果 ← MCP Client ← JSON响应 ← MCP Server ← 既有系统返回结果

关键特点

  • 采用 Client/Server 架构
  • 使用 JSON-RPC 协议和标准化工具描述格式(JSON Schema)
  • 将 Function Calling 转换为统一的 HTTP/JSON 请求
🎯
Skills(技能)

Why:为什么需要它?

Function Calling 和 MCP 都有任务流程定义困难的问题。复杂任务(如代码审查、部署流程)需要特定执行顺序、规则和约束,但:

  • 全部写成代码 → 丧失模型处理不确定性的优势
  • 简单提示词 → 模型无法按精确流程执行

需要一个方式让用户用文字定义可复用的任务流程,同时保留模型的灵活性。

What:它是什么?

Anthropic Claude 的尝试,是 Sub-Agent 的包装。让用户用文字定义指令、脚本和资源,形成可复用的任务流程。本质上是在 Function Calling 之上的巧妙应用。

How:如何工作?

渐进式披露机制

  1. 初始化:加载所有 Skills 的元数据(名称+描述,约100 token)到模型上下文
  2. 发现:Claude 根据用户请求匹配 Skill 元数据,判断是否需要使用
  3. 加载(Function Calling):调用 load_skill(skill_name) 加载对应 SKILL.md 文档
  4. 执行(继续使用 Function Calling):按文档流程执行任务,按需调用脚本、读取资源
用户请求 → Claude 判断是否需调用某 Skill → Function Calling 调用 load_skill() ↓ ← 整合结果 ← 按 SKILL.md 流程执行 ← SKILL.md 内容注入上下文

三者对比总结

维度 Function Calling MCP Skills
本质 基础能力:非结构化→结构化转换 标准化接驳协议 Sub-Agent 包装:文字化流程定义
解决问题 LLM 与外部系统交互的桥梁 工具集成成本高 任务流程定义困难,保留模型灵活性
实现方式 LLM 输出结构化 JSON 基于 FC,转换为 JSON-RPC+HTTP 基于 FC,固化 load_skill() 函数,渐进式加载文档
适用场景 所有工具调用场景 与既有系统接驳(GitHub、Slack、数据库等) 需要特定流程的任务(代码审查、部署流程、合规检查等)
与 FC 关系 基础层 基于 FC 的协议转换 基于 FC 的文档加载与执行

核心洞察

💡 一切都是函数,函数才是第一公民

"一切都是函数,函数才是第一公民" —— Lynxe 的设计理念

三者的关系是层层递进、相互竞合

  1. Function Calling 是根基 —— 没有它,MCP 和 Skills 都无法工作
  2. MCP 和 Skills 是竞争关系 —— 都解决"如何整合多个既有系统实现复杂任务",但路径不同:
    • MCP:协议转换 Server + 代码型流程定义
    • Skills:直接命令行调用 + 文字化流程定义
  3. Skills 替代的是 MCP 函数中的串接代码 —— 用模型决策替代硬编码逻辑,增强适应性,但牺牲 100% 准确性

未来展望

文章作者认为,当前 Agent 方案仍有局限(纯文本描述不够结构化、只能以对话框形式接驳系统),因此提出了 Func-Agent 思路:

让每个 Agent 能力都通过函数化接口暴露,兼顾结构化输入输出与系统集成能力。

← 返回 4. Agent