ARTICLE · 1042673
AI 为什么会调用工具?
AI 为什么会调用工具？
一篇讲清 Tool Calling 与 MCP
如果你问 AI：“上海现在会下雨吗？”它需要的不是一段更聪明的推理，而是实时天气数据。
这时，应用可以把天气查询能力作为工具提供给模型。模型判断该用哪个工具，并生成调用参数；真正发起查询的是应用或 Agent 运行时。结果返回后，模型再把数据整理成自然语言。
我们看到的是一句完整回答，背后其实完成了一次“模型提请求、程序去执行、结果再回来”的闭环。
一、模型“调用工具”时，实际发生了什么
先看一条完整路径：
1. 用户提出问题； 2. 应用把当前可用的工具定义交给模型； 3. 模型选择工具，生成工具名称和参数； 4. 应用或 Agent 运行时接收调用请求，检查后执行真实工具； 5. 工具把结果返回给应用，应用再把结果交回模型； 6. 模型根据结果继续回答，必要时也可以再次请求工具。
可以把它压缩成一条流程：
用户提问 → 模型生成调用请求 → 应用检查并执行 → 工具返回结果 → 模型组织回答
这里最容易误解的是第 3 步。
模型输出的不是天气、订单状态或文件内容，而是一份结构化请求，意思接近：“请调用 get_weather，参数是 city=上海。”
后面的连接、鉴权、执行和异常处理，仍由应用、Agent 运行时或它们托管的工具系统完成。一次 Tool Call 只是“请求执行”，不等于动作已经成功。
二、为什么工具调用要用结构化数据
如果只让模型说一句“请帮我查上海天气”，程序还要从自然语言里猜工具名、城市和参数格式，很容易产生歧义。
因此，应用会先把工具定义提供给模型。一份基础定义通常包含：
• 名称：程序应该调用哪一个工具； • 描述：这个工具负责什么，适合在什么情况下使用； • 参数结构：需要哪些输入、每个输入是什么类型、哪些字段必填。
下面是一份简化后的天气工具定义，重点是看结构，不对应某个平台的完整请求格式：
{"name":"get_weather","description":"查询指定城市的实时天气","parameters":{"type":"object","properties":{"city":{"type":"string","description":"需要查询的城市名称"}},"required":["city"]}}
用户询问上海天气时，模型可能生成这样的调用请求：
{"name":"get_weather","arguments":{"city":"上海"}}应用读到这份请求后，才会运行对应代码或访问天气服务。
结构化格式让程序知道该调用谁、传入什么，也方便执行前做校验。不过，它约束的是输出形状，不会自动保证模型选对工具、参数含义正确或用户有权执行。应用仍然要检查。
三、应用才是工具执行的中间人
把模型、应用和工具分开看，很多问题就容易理解了。
模型擅长理解意图、选择工具、填写参数，再根据结果组织回答。应用负责维护工具清单、控制权限、验证参数、执行调用，并把结果送回模型。真正的业务代码或外部服务负责完成查询、计算、写入等动作。
例如，用户说：“帮我查一下订单 20260918 的配送状态。”
• 模型可能选择 get_order_status，生成订单号参数；• 应用检查当前用户是否有查询权限，再调用订单系统； • 订单系统返回状态； • 模型把系统结果解释成便于阅读的回复。
如果用户要求“取消订单”，应用还可以在执行前弹出确认。是否允许自动执行，由产品规则、权限和用户授权共同决定，不能只交给模型判断。
四、Tool Calling 和 MCP 有什么关系
Tool Calling 描述的是模型参与工具使用的交互方式：模型从可用工具中做选择，并按约定格式生成调用请求；运行时执行工具，再把结果交回模型。
但工具从哪里来、怎样发现、如何传递调用和结果，是另一层问题。
没有 MCP，也可以使用 Tool Calling。开发者可以把本地函数、公司 API 或第三方服务逐个封装成工具。只是工具一多，不同系统的连接、鉴权和数据格式就会带来大量适配工作。
MCP（Model Context Protocol）提供了一套标准协议，让 AI 应用可以连接 MCP Server，发现 Server 暴露的能力，并按统一方式交换请求和结果。
二者关注的层面不同：
• Tool Calling 关注一次调用怎样发生：选哪个工具、参数是什么、结果怎样回到模型； • MCP 关注外部能力怎样接进来：Host 和 Server 如何发现能力、建立会话并交换消息。
接入 MCP 后，模型仍然是在生成调用意图和参数。Host、Client、Server 负责协议通信和实际执行。MCP 没有让模型绕过应用，也没有替应用做权限判断。
五、Host、Client、Server 怎么配合
MCP 采用 Host—Client—Server 架构。入门时可以这样理解：
Host：用户正在使用的 AI 应用
Host 是承载对话、模型和用户交互的应用，例如桌面助手或集成 AI 的开发工具。它负责管理连接、权限、用户授权和上下文，也会创建并管理 MCP Client。
Client：Host 里的协议连接组件
Client 负责和某一个 MCP Server 建立会话、协商双方支持的能力，并在 Host 与 Server 之间双向传递消息。一个 Client 与一个 Server 保持独立连接，避免不同 Server 直接共享整段对话或彼此的数据。
Server：对外提供能力的一端
Server 可以是本地进程，也可以是远程服务。它向 Client 暴露自己支持的工具、资源和提示模板，并在收到合规请求后返回结果。
用户主要和 Host 交互，Client 处理协议通信，Server 提供具体能力。Host 仍然掌握连接、上下文与授权边界。
六、MCP Server 可以提供什么
MCP Server 常见的三类基础能力是 tools、resources 和 prompts。它们不只是内容不同，通常由谁触发也不同。
Tools：让模型选择的可执行能力
Tools 用来查询信息或产生动作，例如查询数据库、创建工单、读取天气、写入文件。模型可以根据任务选择某个 Tool，但客户端仍应在敏感操作前让用户确认，并由 Server 校验输入、权限和执行条件。
Resources：由应用管理的上下文资料
Resources 是 Server 提供的数据或内容，例如文件、项目文档、数据库结构或应用信息。它们通常由 Host 决定怎样展示、读取或放入模型上下文，也可以让用户显式选择。
Prompts：由用户选择的任务模板
Prompts 是 Server 提供的提示模板，可以带参数。它们通常作为命令或任务入口展示给用户，由用户选择后再交给模型，而不是模型在后台自动执行。
这三类能力可以由同一个 Server 提供，也可以只实现其中一部分。连接初始化时，Client 和 Server 会声明各自支持的能力；没有声明的能力，不能默认存在。
七、Tool Calling、MCP、Agent Skill 怎样区分
这三个词常常同时出现。把它们放进一个具体任务里，分工会更直观。
假设我们要“查询线上错误记录，并生成一份故障分析”：
• Tool Calling：模型生成查询错误记录所需的工具名称和参数； • MCP：AI 应用通过统一协议连接提供错误记录的 Server； • Agent Skill：保存故障分析的步骤、参考资料、输出格式和检查要求。
一句话概括：
Tool Calling 管一次调用怎样发起，MCP 管外部能力怎样接入，Agent Skill 管一类任务怎样反复做好。
Agent Skill 可以要求 Agent 在某一步调用工具，也可以附带脚本和参考资料；但仅仅安装一个 Skill，并不会自动获得某个外部系统的访问权。真正的连接、凭证、权限和执行能力，仍要由运行环境或 MCP 等工具接入方式提供。
三者可以配合，但不能互相替代。
八、授权确认与安全边界
工具接入后，调用和回答仍然可能出错，而且错误会出现在不同环节：
• 模型选错工具，或生成了不合适的参数； • 当前用户没有相应权限； • 网络超时，或服务暂时不可用； • 工具返回过期、缺失或格式异常的数据； • 外部系统本身给出了错误结果； • 工具返回的文本里包含误导模型的恶意指令。
因此，应用至少要做好几件事：
• 只开放当前任务需要的工具和最小权限； • 执行前校验工具名称、参数类型和必要字段； • 删除、付款、发送、发布、修改账号等高影响操作要求用户确认； • 给调用设置超时、重试上限和清楚的失败提示； • 把工具结果当作外部输入，检查来源、格式和合理性； • 保留必要的调用记录，方便发现问题后追查。
工具返回的数据也不能天然视为事实。模型组织回答时，应忠实反映工具结果；结果不完整或互相冲突时，应该明确说明，而不是自行补齐。
九、从一次查询看懂整个过程
下次看到 AI 查询天气、搜索文件或创建任务时，可以把界面背后的流程拆开：
模型先根据工具定义生成结构化调用，应用检查并执行，工具返回数据，模型再继续回答。MCP 可以帮助应用用统一协议连接不同 Server，Agent Skill 则可以规定整项任务应该按什么步骤完成。
先分清谁在选择、谁在执行、谁在连接、谁在提供方法，工具调用就不再像一个藏在对话框里的魔法动作。