这主要是由于其设计目标与Function Calling在指令遵循、输出格式等方面存在冲突。
这里有一个关键的时间点需要注意：DeepSeek-R1存在两个主要版本，它们对Function Calling的支持情况完全不同：
| 版本 | 发布日期 | 支持Function Calling |
|---|---|---|
| 初始版 (DeepSeek-R1) | 2025年初 | ❌ 不支持 |
| 新版 (DeepSeek-R1-0528) | 2025年5月底 | ✅ 支持 --22 |
🚫 初始版本 (DeepSeek-R1) 不支持的核心原因
对于初始版本的DeepSeek-R1，其不支持Function Calling的核心原因在于其设计哲学与实现路径。
-
设计理念的差异 ：DeepSeek-R1是一个典型的推理优先模型 ，其核心是通过多步推理和思维链（CoT）的方式，生成人类可读的思考过程（通常被
<think/>标签包裹）--6。而Function Calling要求模型严格遵循特定的格式化输出（如OpenAI标准的tools字段和结构化JSON），以便机器高效解析和执行-。这两种输出逻辑存在天然冲突，即工具调用与深度思考模式相互排斥 --26。这也是为什么许多社区实现需要从模型的自然语言回复中通过提示工程手动模拟 出函数调用效果的原因-2-18。 -
开源生态的局限 ：在大型语言模型（LLM）的发展过程中，对Function Calling的全面支持是商业模型先行，开源模型后续跟进的特征-2。DeepSeek-R1在发布初期，并未将此功能作为优先目标，模型本身的训练数据也未针对工具调用进行特殊优化-。
-
复杂场景下的应用困境 ：即使有社区或部署框架努力为DeepSeek-R1添加Function Calling支持（如vLLM、SGLang等框架），效果也十分有限-17-30。尤其在多轮对话 等复杂场景中，其准确率会急剧下降。例如，有社区测评显示，其多轮调用准确率一度低至4-6%，远低于官方宣称的水平-1。
✅ 新版 (DeepSeek-R1-0528) 已支持该功能
值得一提的是，这个情况已经在2025年5月29日发布的DeepSeek-R1升级版（DeepSeek-R1-0528 ）中得到了彻底解决--22。新版本原生支持了对Function Calling的调用，并且效果显著提升。
-
性能达标 ：在Tau-Bench的零售场景测试中，它的得分达到了63.9%，与OpenAI的o1-high模型持平-22。
-
官方推荐：因此，如果你的项目需要使用Function Calling功能，请务必选择DeepSeek-R1-0528或更新的版本。
💡 如何应对与规避
如果你因为各种原因仍需使用不支持该功能的初始版DeepSeek-R1，可以考虑以下两种方案：
-
模拟方案 ：通过提示工程（Prompt Engineering） 来模拟Function Calling。即在提示词中明确告知模型需要调用的工具名称、功能描述、参数格式，并要求其必须以特定结构化格式（如JSON）返回。通常还需要配合Pydantic模型定义和输出解析器来实现-6-18。
-
框架适配 ：借助一些开源框架的适配能力。例如，vLLM 等社区框架通过开发专用的工具解析器和聊天模板（chat template），使得在新版本发布前，DeepSeek-R1也能实现基础的函数调用-17。
💎 总结
简而言之，一个AI模型能否支持严格的 Function Calling，取决于它在推理灵活性 与指令遵循之间的权衡与设计选择。
即便是深度思考模型，随着技术迭代，它们也会逐步具备调用外部工具的能力。