标准回答
先区分两件事：模型能力 vs 接口支持
回答这题最重要的是分清「模型本身有没有工具调用能力」和「这个接口/产品是否开放了 FC/MCP」。很多时候模型不是做不到，而是该版本没做对齐或产品上没开放。把这两层混为一谈是常见失分点。
训练层面的原因
早期一些以长链思维（CoT）为核心的推理模型（如某些 o1 / R1 的早期版本）训练目标聚焦在「先展开长推理、再给最终答案」，提升的是数学、代码、复杂推理的深度。它们没有专门做工具调用对齐，也缺少函数调用所需的固定格式 / 特殊 token 训练，因此天然不会稳定地输出可解析的结构化调用。
格式与流程冲突
推理模型会先产出一大段 reasoning，再给答案；而 Function Calling 要求在合适时机吐出结构化的 tool_call、等待工具结果回填、再继续。长 reasoning 与结构化调用在解析边界、流式输出、多轮交错上存在冲突，早期实现很难把「长思考」和「中途调用工具」稳定地编排在一起。
产品与工程取舍
还有架构与产品层面的选择：部分厂商刻意把工具编排放在外层 Agent 框架（由框架决定何时调用、模型只管推理），而不是让模型内置工具调用；也有接口定位、稳定性、上线节奏等取舍，导致某些版本暂不开放 FC/MCP。
趋势判断
本质上这是「训练对齐与产品选择」的问题，而非根本不可能。新一代推理模型已经在长推理的同时补齐了 Function Calling / MCP 支持，能边思考边调用工具，差距正在被快速抹平。
常见误区
⚠️ 常见踩坑
别下「推理模型在原理上无法做工具调用」的结论——这是训练对齐和产品取舍，不是能力天花板；也别把「某个接口不支持 MCP」直接等同于「这个模型不会工具调用」，接口支持与模型能力是两层。
追问
追问 1：MCP 和 Function Calling 是一回事吗？
不是同一层。Function Calling 是模型「在合适时机输出结构化调用」的能力，属于模型/接口层；MCP（Model Context Protocol）是把工具、数据源标准化暴露给模型的协议层，解决「工具怎么接入、怎么发现」。一个模型要好用地接 MCP，通常需要它本身具备稳定的工具调用能力，两者配合但不等价。
追问 2：如果一个推理模型不支持 FC，工程上还能让它用工具吗？
可以，靠外层编排兜底：用 Agent 框架或提示工程让模型按约定文本格式（如输出特定标记的 JSON）表达调用意图，框架解析后执行工具并把结果回填进上下文，再让模型继续推理。这是「在框架层补能力」，稳定性和准确率一般不如模型内置的原生 FC，但能在缺原生支持时落地。
追问 3：为什么新一代推理模型能同时做长推理和工具调用？
因为后训练把两类数据和格式统一对齐了：在长 CoT 轨迹中插入「思考→调用工具→读结果→继续思考→作答」的交错样本，并规范 reasoning 与 tool_call 的解析边界和流式协议。模型因此学会在长思考过程中按需触发结构化调用，而不再是只能一口气推到底，从而把推理深度和工具使用能力结合起来。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习