工具调用与 MCP：Agent 的双手与通用接口
Function Calling 让模型能"动手"，MCP 让工具接入从 N×M 的项目工程变成即插即用。拆解机制、生态与局限。
Function Calling：让模型递出第一只手
模型天生只会做一件事：生成文本。函数调用（Function Calling，也称工具调用，Tool Calling）是让模型触碰真实世界的机制，直觉上分三步：
- 报名：应用在请求时告诉模型”这里有哪些工具可用”，每个工具带名称、功能描述和参数的 JSON Schema（参数结构定义）。
- 点名：模型根据任务判断需要哪个工具，输出一个结构化的”调用意向”——工具名 + 参数值。注意这一步模型只是在填表，并不执行任何东西。
- 执行：应用代码（而非模型）真正执行该函数，把结果作为新信息发回模型，模型据此继续生成——回答问题，或发起下一次调用。
理解这个机制的关键在于：模型是决策者，不是执行者。它决定”调什么、传什么参数”，但执行的权限、环境、安全边界完全掌握在应用手里。这也是 Agent 系统中权限管控的根基——模型永远无法调用你没有提供给它的工具。这套机制如何嵌入 Agent 的整体循环，见《Agent 架构解剖：规划、工具、记忆、反思》。
N×M 问题：MCP 出现前的痛点
Function Calling 解决了”模型怎么用工具”，但没解决”工具从哪来”。在 MCP 出现前，给一个 AI 应用接入工具是一次定制工程：为你的应用框架写一遍工具的接入代码；换一个框架（或一个 Agent 产品），同样的工具要重写一遍。
这是典型的 N×M 问题：N 个 AI 应用 × M 个工具，理论上要做 N×M 次集成。每家公司都为自己的平台维护一套工具生态，开发者重复劳动，工具能力无法跨平台复用——就像 USB 出现之前，每种设备各配一种充电接口。
MCP：模型世界的 USB-C
模型上下文协议（Model Context Protocol, MCP）由 Anthropic 于 2024 年底发布并开源 [待核实：发布时间的准确表述]，目的就是把 N×M 变成 N+M。它采用客户端-服务器模型：
- MCP 服务器（Server）：工具或数据的提供方。把数据库、文件系统、Slack、GitHub 等能力封装成标准服务，对外声明”我提供这些工具和资源”。
- MCP 客户端（Client）：AI 应用一侧（IDE、聊天客户端、Agent 框架）内置的标准接口，负责发现并调用任何 MCP 服务器。
于是工具方只需实现一次 MCP 服务器，就能被所有支持 MCP 的应用使用；应用方只需实现一次 MCP 客户端，就能接入所有 MCP 服务器。工具接入从”每个项目里重写一遍胶水代码”，变成”装一个现成的服务器”。OpenAI、Google 等主要厂商随后宣布支持 MCP，事实标准地位基本确立 [待核实：各家支持的完整范围]。
生态现状与局限
冷静地看，MCP 解决的是接口标准问题，不解决集成质量问题：
- 安全边界仍是自己的责任。协议标准化让接入变容易，也让”顺手装一个来路不明的服务器”变容易。恶意或粗劣的 MCP 服务器可以把有害指令（提示注入，Prompt Injection）或危险工具带进你的 Agent。供应链信任问题，协议本身不解决。
- 质量参差。工具描述写得好不好、报错信息对模型是否友好，直接决定 Agent 用得顺不顺。装得上 ≠ 用得好。
- 动态性有限。大量工具一次性塞给模型时，选择准确性会下降；协议不替你做工具编排与筛选。
所以 MCP 之后，工程重心不是消失而是转移：从”写胶水代码”转向工具治理——审核来源、控制权限、设计工具暴露策略。这与《什么是 AI Agent》中”权限最小化”的原则一脉相承。
观点：从项目工程到即插即用
本篇观点：协议标准化正在把”Agent 接工具”从一次性项目工程变成即插即用的能力配置，这是 Agent 走向规模化生产的前提。
历史反复上演同一剧本：HTTP 标准化了信息交换，催生了 Web；USB 标准化了外设接口，催生了配件生态。MCP 正在 AI 领域扮演类似角色。对企业而言，合理姿势是：工具的封装与治理按长期资产来做（你的 MCP 服务器就是你的工具资产），而对具体某个 Agent 框架保持可替换——协议存在的意义，就是让你不必绑死任何一方。
小结
- Function Calling 三步：报名、点名、执行；模型只决策不执行，权限始终在应用手里。
- MCP 把工具集成的 N×M 问题变成 N+M，是模型世界的”USB-C”。
- MCP 不解决工具质量与供应链安全，工程重心正转向工具治理。
- 协议标准化让工具沉淀为跨平台的长期资产，框架选择保持可替换。