Function Calling on SelfTechHub

第5章：MCP——工具调用的标准化革命

Mon, 01 Jun 2026 00:00:00 +0000

第5章：MCP——工具调用的标准化革命

系列导读：本章是上章的延伸。如果你还在手写每个工具的集成代码，MCP 就是来救你的。它能让你接入一个工具的效率从「一天」降到「十分钟」。

一、没有 MCP 之前，接工具有多麻烦？

想象你要给 Claude Desktop 接入三个工具：GitHub（查仓库）、文件系统（读本地文件）、Slack（发通知）。

在没有 MCP 之前：

写 GitHub API 调用代码 + OAuth 认证 + 错误处理 + 格式转换，确保返回结果能被模型理解
写文件系统操作代码 + 权限管控 + 路径沙箱，防止模型删除不该删的文件
写 Slack API 调用代码 + Bot 配置 + 消息格式化

折腾了三周，终于接好了。三个月后 Claude 升级了，接口变了，你的代码又得重写。

最致命的问题：每个工具都要单独集成，而且强绑定到某个模型。你想换 Gemini 用这些工具？之前写的所有代码都要重写一遍嫁接逻辑。更别说换个多模态模型（比如能看图、能听语音的），工具 layer 可能完全不兼容。

这种碎片化的结果就是：目前市面上有成百上千个有用的工具 API，开发者和模型提供者之间形成了一个糟糕的分发瓶颈——每一家模型厂都要跟每一家工具厂谈合作、做适配。

二、MCP 是什么？

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年底推出的开放协议（不是框架，是协议）。

它的核心目标是：工具实现一次，到处复用；任何支持 MCP 的 AI 客户端，都能自动发现并接入。

你可以把它理解成 AI 时代的「USB-C 接口」——所有工具都按统一标准做接口，所有 AI 客户端都支持这个接口。工具提供者按协议标准写一个 Server，任何支持 MCP 的客户端都能直接拿来用，不需要再说服 OpenAI 或 Google 专门为你做对接。

三、MCP 的架构：Client-Server 模式

    ┌──────────────┐                    ┌──────────────┐
    │  AI Client   │ ←─── MCP 协议 ───→ │ MCP Server 1 │ (GitHub工具)
    │ (Claude,     │    JSON-RPC 2.0     └──────────────┘
    │  OpenAI SDK) │                          ┌──────────────┐
    │              │ ←─── MCP 协议 ───→       │ MCP Server 2 │ (文件系统)
    └──────────────┘    (stdio / SSE / HTTP) └──────────────┘

MCP Server：每个工具按 MCP 协议实现一个服务进程，暴露能力
AI Client：在配置文件中声明 MCP Server 地址，自动发现可用的工具
通信方式：支持 stdio（本地进程）、SSE（HTTP流式）、HTTP（远程调用）

这种设计的妙处在于：工具提供者只需要写一份标准化的 Server 实现，所有客户端（Claude、OpenAI SDK、Cursor IDE、Zed 编辑器等）都能自动发现并调用它的能力。工具生态的分发效率得到了本质提升。

四、MCP 的三类核心能力

1. Tools（工具）—— 执行有副作用的操作

如发送邮件、创建文件、调用 API。每次调用都可能改变外部世界状态。工具调用后需要返回执行结果给模型，模型据此决定下一步。

2. Resources（资源）—— 只读数据通道

如读取文件内容、访问数据库、查看日志。资源可以被"挂载"到客户端上下文，模型可以随时调用，不会产生副作用。

3. Prompts（提示词模板）—— 结构化输入模板

预定义一组任务模板，用户可以在使用前填充参数。比如 “生成代码审查提示词” → 填充 “文件路径” → 拿到完整 prompt。这类能力让 MCP Server 不仅是被动的工具提供者，也是主动的交互助手。

这三类能力覆盖了 AI 工具生态中的"执行"、“读取”、“交互模板"三个核心场景。

五、MCP vs Function Calling：不是替代，是互补

维度	Function Calling	MCP
层级	API 调用格式（命令）	工具生态协议 + 发现机制
解决的问题	模型怎么说出「我要调什么」	工具怎么被接入和管理
类比	HTTP 请求格式	REST API 规范 + 服务注册发现
关系	依赖关系	MCP 底层还是靠 Function Calling！

最关键的一句话：MCP 底层驱动的仍然是 Function Calling。MCP 不是「不用 Function Calling 了」，而是在 Function Calling 之上加了一层生态层。

Function Calling 说：模型输出的工具调用应该是 JSON Schema 格式
MCP 说：工具怎么注册、怎么发现、怎么通信、怎么复用，都按统一标准来

你可以只靠 Function Calling 写一辈子代码，但接入第10个工具时你就会想要 MCP。手动管理10个工具的 schema、认证、状态同步、错误重试，是在做重复的体力活。

六、配置一个 MCP Server 有多简单？

以 Claude Desktop 为例，它的配置文件中加几行就行：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/docs"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx" }
    }
  }
}

启动 Claude Desktop 后：

自动启动各 MCP Server 进程
读取各 Server 暴露的 tools/resources/prompts 列表
Claude 自动发现这些工具并能随时调用

零代码接入。

七、MCP 对生态的影响

工具开发者：按 MCP 标准实现一次，OpenAI、Claude、Gemini 都能用。分发成本从 O(NxM) 降到 O(N+M)。
AI 客户端开发者：接入 MCP 协议就能自动获得成百上千的工具
终端用户：AI 能做的事情从「聊天+联网搜索」变成「调用整个数字世界”

MCP 的意义跟当年 HTTP 协议标准化 web 服务是一样的底层逻辑。如果没有 HTTP，每个网站都得写自己的传输协议，浏览器永远做不到通用。MCP 的目标是让 AI 工具的接入也有同样的标准化基础。

八、本章小结

MCP 是 AI 工具生态的"USB-C"标准化协议
三类能力：Tools（执行）、Resources（只读数据）、Prompts（模板）
MCP 和 Function Calling 是不同层次的东西：FC 解决"格式"问题，MCP 解决"生态"问题
配置 MCP Server 只需几行配置，零代码接入
MCP 代表了 AI 工具生态从碎片化走向标准化的关键转折点

思考题

MCP 的「开放协议」定位意味着它的生命周期会长于任何单一公司的产品。如果这个协议成为事实标准，会对 AI 工具生态产生什么深远影响？
在 MCP 的三种能力（Tools/Resources/Prompts）中，你认为哪一类最有商业想象空间？为什么？

第4章：Function Calling——让大模型从「聊天者」变成「执行者」

Sat, 30 May 2026 00:00:00 +0000

第4章：Function Calling——让大模型从「聊天者」变成「执行者」

系列导读：从本章开始，我们进入 LLM 的「行动能力」阶段。如果你还没看第1章，建议先了解 LLM 的本质，再去理解为什么它能「调用工具」是真正的事半功倍。

一、Function Calling 到底是什么？

LLM 本身是一个文本生成器，它生成了天气查询请求，但它不能自己去调用 API。

Function Calling（工具调用）就是解决这个问题的机制：让 LLM 输出结构化的工具调用指令（通常是 JSON 格式），你的代码负责解析并执行真实的调用。

核心原则：模型只判断「该做什么」，代码负责「真正把它做了」。

二、Function Calling 的两轮对话流程

用户提问 → LLM 判断需要调工具 → 输出 tool_call JSON →
代码解析 JSON → 真正调用 API → 获得结果 →
把结果塞回对话 → LLM 生成最终答案

这是最基础的流程，实际可能有多次工具调用循环。

具体例子

Round 1 - 用户输入：

“北京今天的天气怎么样？”

Round 1 - LLM 响应（不是答案，是工具调用指令）：

{
  "tool_calls": [{
    "id": "call_abc123",
    "type": "function",
    "function": {
      "name": "get_weather",
      "arguments": "{\"city\": \"北京\", \"date\": \"2026-07-21\"}"
    }
  }]
}

代码层 - 解析并执行：

tool_call = response.tool_calls[0]
if tool_call.function.name == "get_weather":
    args = json.loads(tool_call.function.arguments)
    result = get_weather(args["city"], args["date"])

Round 2 - 把结果塞回对话：

User: 北京今天的天气怎么样？
Assistant: [tool_call: get_weather(city="北京", date="2026-07-21")]
Function: {"temperature": 32, "condition": "晴", "humidity": "65%"}
Assistant: 北京今天晴天，气温 32℃，湿度 65%，非常适合户外活动！

三、Schema 定义：关键工程细节

Function Calling 的核心是 schema 的定义。schema 告诉模型每个工具：

name：工具名称，越具体越好
description：工具的详细用途，模型靠这个决定要不要调它
parameters：参数结构，包含每个参数名、类型、描述、是否必填
required：必填参数列表

Schema 示例：

{
  "name": "get_weather",
  "description": "获取指定城市和日期的天气信息，包括温度、天气状况、湿度。支持中国境内城市。",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "要查询天气的城市名称，例如：北京、上海、广州"
      },
      "date": {
        "type": "string",
        "description": "查询日期，格式为 YYYY-MM-DD"
      }
    },
    "required": ["city", "date"]
  }
}

description 是最关键的字段。模型完全靠 description 来判断该不该调这个工具。写 description 的技巧：

明确边界：不是什么都调，只在什么场景下调
给出例子：比如 “当用户问 xx 时调用”
避免触发词陷阱：description里别用模型的名字（如 “ChatGPT”），否则模型可能误触发

四、Function Calling 和「土办法」的区别

在没有 Function Calling 之前，开发者只能靠解析自然语言文本来判断模型要不要调工具：

# 土办法
response = model.chat("帮我查北京天气")
if "天气" in response:
    # 手动解析，极其脆弱
    city = extract_city(response)  # 容易出错

Function Calling 以后：

# Function Calling 方式
response = model.chat("帮我查北京天气", tools=[weather_tool_schema])
if response.tool_calls:
    # 模型输出的是结构化 JSON，解析安全得多
    tool_call = response.tool_calls[0]

关键区别：结构化输出 vs 自然语言解析。结构化输出准确率接近100%，自然语言解析经常抽风。

五、高级特性

1. 并行工具调用

模型可能在一次响应中输出多个 tool_calls，比如用户问"北京和上海的天气":

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

你的代码可以并行执行两个调用，然后再把结果一起塞回去。

2. 强制使用工具

有些场景要求模型必须调工具，不提供直接回答：

response = model.chat(query, tools=tools, tool_choice="required")
# 设置 tool_choice 为 "required" 强制模型输出 tool_calls

3. 多轮工具调用链

复杂任务可能需要多次调用：查天气 → 根据温度推荐衣服 → 查找推荐店铺的地址 → 查询交通路线。

每一轮把结果塞回 history，LLM 自动判断下一步该做什么。这就是 Agent 的基础。

六、常见坑

坑	解决方案
模型选错工具	description 写清楚边界 + 用 tool_choice 限制
参数类型错误	schema 中严格定义 enum/number/string
函数结果太长塞爆 context	摘要压缩后返回
工具调用死循环	max_iterations 限制 + 超时熔断
结果格式不一致	在 function result 中也标准化输出格式

七、本章小结

Function Calling = 模型决策 + 代码执行，两者严格分离
Schema description 是核心，决定了模型是否选对工具、传对参数
并行调用、强制调用、多轮链式调用是高级用法
它是通往 Agent 的必经之路

思考题

为什么 Function Calling 要求模型输出的是 JSON schema 而不是自由文本？这背后的设计哲学是什么？
如果模型的 tool_calls 返回的参数含危险操作（如删除文件），你的拦截策略应该放在哪一层？