Function Calling深度解析：从OpenAI到开源模型的工具调用差异

Function Calling（工具调用）是LLM从”对话机器”升级为”行动代理”的关键能力。但不同模型对Function Calling的实现方式差异巨大，迁移成本远高于切换对话API。

OpenAI的格式标准

OpenAI使用tools数组定义可用函数，包含name、description和parameters（JSON Schema）。模型返回tool_calls数组，每项包含函数名和参数JSON。这套格式已成为事实标准，但细节上有坑：strict模式下参数类型必须精确匹配，连optional字段缺失都会拒绝。

开源模型的碎片化

Qwen 2.5原生支持OpenAI兼容的tool calling，迁移成本最低。Llama 3.1使用自定义的<function=xxx>...</function>标记语法，需要适配层翻译。DeepSeek-V3兼容OpenAI格式但在嵌套对象参数解析上偶有遗漏。Mistral走的是[TOOL_CALLS]令牌方案，与OpenAI完全不兼容。

多轮工具调用的状态管理

最容易被忽视的问题：当Agent连续调用多个工具时，每个请求必须携带完整的对话历史和之前所有工具调用的结果。漏传一轮历史，模型就会”失忆”并重复调用同一个工具。建议用LangChain的MessageHistory或自建一个按session_id索引的对话缓冲区，确保每次API调用都带上全量上下文。

实践建议

如果需要在多个模型间切换，封装一个Tool Calling抽象层——统一用OpenAI格式定义工具，底层适配器负责转换为各模型的原生格式，并校验返回参数的有效性。这个抽象层的代码量约200行，但能省掉未来每次模型切换时的上千行修改。