推理模型和工具调用的冲突，后来是怎么解决的？

先这样答

结论是，工具调用放在思考阶段结束之后。模型先把这一轮思考完整生成，再决定是否调用工具。这样可以保证一次思考不会被工具调用打断。

现在常见的折中方案是参考 o3、Claude 的扩展思考工具集成。模型先完成一轮思考和输出。如果这轮判断需要外部信息，就在这一轮结束后调用工具。工具返回结果后，模型再开启下一轮思考。它不是在同一轮思考中边想边调用，而是把思考和工具调用分成连续的多个阶段。

从依赖链看，MCP 底层还是靠 Function Calling 驱动。推理模型对 Function Calling 的支持并不完整，所以 MCP 这一层也会受到限制。工具调用不能只看 MCP 的协议设计，还要看底层模型是否能稳定支持对应的 Function Calling。把调用放到思考结束之后，是目前更容易落地的处理方式。

面试官会怎么追问

• 「为什么不让模型一边思考，一边调用工具？」 这样会打断当前的思考过程。工具调用放到思考阶段结束之后，可以让模型先把这一轮完整生成，再根据结果决定是否需要外部信息。

• 「需要多次工具调用时，流程怎么走？」 模型先完成一轮思考。如果需要外部信息，就发起工具调用。拿到工具结果后，再开启下一轮思考，继续判断后续是否还需要调用工具。

• 「MCP 为什么会受到推理模型能力的限制？」 MCP 底层靠 Function Calling 驱动。推理模型的 Function Calling 支持不完整，MCP 就不能脱离这个限制独立工作。模型支持到什么程度，MCP 的工具集成就会受到相应影响。

回答的坑

• 不要把方案说成思考过程中随时调用工具，核心做法是先结束一轮思考，再调用工具。
• 不要只谈 MCP 协议本身，还要说明它依赖底层 Function Calling，而推理模型的支持并不完整。