工具调用与 MCP（模型上下文协议）详解

工具调用：模型如何“使用”软件

大模型只会输出 token，自己没法打开文件或调用 API。工具调用（也叫函数调用）就是连接两者的桥梁：

1. 你的应用把对话连同一份工具清单发给模型，每个工具有名称、描述和参数的 JSON Schema。
2. 如果某个工具有帮助，模型会回复一个结构化的工具调用（代替文字或和文字一起）：{"name": "get_weather", "arguments": {"city": "上海"}}。
3. 你的代码校验参数、执行工具，再把结果作为工具消息发回去。
4. 模型读到结果，要么给出回答，要么继续调用下一个工具。

sequenceDiagram
  participant App as 你的应用
  participant LLM as 模型
  participant Tool as 工具 / API
  App->>LLM: 消息 + 工具定义（名称、描述、JSON Schema）
  LLM-->>App: 工具调用 get_weather(city="上海")
  App->>Tool: 执行（先校验参数、检查权限）
  Tool-->>App: temp_c=21, sky=cloudy
  App->>LLM: 工具结果
  LLM-->>App: "上海现在 21 °C，多云。"

一个工具定义大致长这样（各家格式略有不同，见 OpenAI 和 Anthropic 的文档）：

{
  "name": "search_issues",
  "description": "在一个 GitHub 仓库里搜索 issue。用于回答关于 bug 或功能需求的问题。最多返回 20 条，包含编号、标题、状态和链接。",
  "input_schema": {
    "type": "object",
    "properties": {
      "repo":  { "type": "string", "description": "owner/name 格式，例如 'ollama/ollama'" },
      "query": { "type": "string", "description": "关键词，支持 'is:open'" }
    },
    "required": ["repo", "query"]
  }
}

模型经过训练会输出这样的调用；安全边界在你的代码里，由它决定什么真正被执行。

为什么需要一个协议

MCP 出现之前，每个 AI 应用都要逐个对接每个工具：M 个应用 × N 个工具 = M×N 套定制集成。Anthropic 在 2024 年 11 月推出的模型上下文协议（MCP）（发布公告）把它变成 M + N：工具提供方写一个 MCP 服务器，任何支持 MCP 的应用都能用。它常被比作“AI 应用的 USB-C 接口”。

MCP 的架构

flowchart LR
  subgraph Host["宿主应用（桌面助手、IDE、编程 Agent）"]
    LLM["模型"]
    C1["MCP 客户端"]
    C2["MCP 客户端"]
  end
  C1 <-->|"stdio（本地进程）"| S1["MCP 服务器：文件 / git / 浏览器"]
  C2 <-->|"Streamable HTTP + OAuth"| S2["远程 MCP 服务器：SaaS / 数据库"]

• 宿主（Host）：用户运行的 AI 应用，里面有模型循环，并为每个服务器连接创建一个客户端。
• 服务器（Server）：对外提供能力。消息格式是 JSON-RPC 2.0；服务器可以在本地通过 stdio 运行，也可以通过 Streamable HTTP 远程提供，远程服务器使用基于 OAuth 的授权机制（规范）。

服务器提供三种基本能力（架构说明）：

客户端也可以向服务器提供能力，比如 sampling（让服务器请宿主的模型生成内容）、roots（服务器能看到哪些文件夹）、elicitation（向用户询问输入）。连接建立时，双方协商版本和能力；客户端随后列出工具，把它们的定义交给模型。

本站收录的不少软件就是 MCP 宿主或服务器：例如 Claude、Claude Code、Cherry Studio、5ire 是客户端；iMCP（macOS 的信息、通讯录、提醒事项、日历）和 Peekaboo（截屏与画面分析）是服务器。

MCP 与 A2A

MCP 把 Agent 连接到工具和数据（“纵向”）。由 Google 发起的 Agent2Agent 协议（A2A） 把 Agent 彼此连接起来（“横向”）：一个 Agent 发布 Agent Card，描述自己的技能和接入地址，其他 Agent 就可以把任务委派给它（a2a-protocol.org）。2025 年 12 月，MCP 被捐给 Linux 基金会新成立的 Agentic AI Foundation（新闻稿），A2A 也在 2026 年 8 月加入，两者都成了厂商中立的标准。详见 A2A 与多 Agent 协作。

怎样写出 Agent 真正用得好的工具

工具质量是决定 Agent 成败的最大因素之一（见 AI Agent 工作原理）。下面这些实用原则，与 Anthropic 关于 为 Agent 编写工具 的建议一致：

1. 写清用途和边界：什么时候用、什么时候不用、返回什么。
2. 少而精、按任务设计的工具，胜过给每个 API 端点套一层薄包装；避免功能几乎重复、让模型难以选择的工具。
3. 在 Schema 里写清参数名、类型、枚举值和示例。
4. 返回精简、相关的输出：分页或过滤，别把一万行内容倒进上下文。
5. 可操作的报错：“仓库不存在，应为 'owner/name' 格式”能帮模型自我纠正，一段堆栈信息则不能。
6. 最小权限与人工确认：默认只读，破坏性操作需要确认。工具描述本身也可能成为攻击入口（见 提示注入与工具投毒）。

动手试试

把一个本地 MCP 服务器接入支持 MCP 的桌面应用，问一个必须用到它的问题，再查看应用显示的工具调用记录。然后读一读这个服务器的工具描述：你读到的，正是模型看到的提示词。