Function Calling（工具调用/函数调用）是让大模型从”聊天机器人”进化成”干活工具”的关键能力。能不能准确理解用户意图、正确选择工具、精确填写参数、妥善处理返回结果——这些决定了一个模型在 Agent 场景下能不能真正可用。
目前开源社区里有好几个专门为 Function Calling 优化的模型，各有各的路数。今天就挑四个最有代表性的来做个详细对比：Hermes（Nous Research）、Gorilla（UC Berkeley）、Functionary（MeetKai）和 NexusRaven（Nexusflow）。
四个选手的基本情况
Hermes：从 Hermes 2 Pro 开始引入 Function Calling 能力，到 Hermes 3 和 Hermes 4 逐步完善。它不是一个专门的 Function Calling 模型，而是在通用对话能力的基础上叠加了工具调用支持。使用 ChatML 格式 来定义和调用工具。
Gorilla：UC Berkeley 的研究项目，专门为 API 调用训练的模型。它的独特之处是能直接生成真实的 API 调用代码（比如 HuggingFace Hub、TorchHub 的实际 API），而不只是生成 JSON 格式的抽象函数调用。
Functionary：MeetKai 团队开发，定位就是”最像 OpenAI Function Calling 的开源替代品”。它对标 OpenAI 的 Function Calling 格式，API 接口设计也尽量和 OpenAI 保持一致，方便从 OpenAI 迁移过来的用户。
NexusRaven：Nexusflow 出品，基于 CodeLlama 微调的 Function Calling 专用模型。特点是把函数调用当作代码生成来做——它直接生成 Python 风格的函数调用代码，而不是 JSON。
格式规范的差异
这是第一个需要注意的点：四个模型输出 Function Calling 结果的格式完全不同。
Hermes 的格式：
1 | <tool_call> |
Hermes 使用 XML 标签包裹 JSON 格式的函数调用。参数以 JSON 对象形式传递，格式清晰，解析方便。
Gorilla 的格式：
1 | hub.load("torchaudio/wav2vec2", model="base") |
Gorilla 直接生成可执行的代码。这种方式对于调用真实 API 非常方便——直接把输出当代码执行就行。但如果你想要一个统一的抽象层来管理各种自定义工具，这种格式反而不太灵活。
Functionary 的格式：
1 | {"function": {"name": "search_products", "arguments": "{\"query\": \"机械键盘\", \"max_price\": 500}"}} |
和 OpenAI 的格式几乎一样。arguments 字段是一个字符串化的 JSON，需要二次解析。如果你的代码库已经适配了 OpenAI 的 Function Calling 格式，切换到 Functionary 的改动最小。
NexusRaven 的格式：
1 | search_products(query="机械键盘", max_price=500) |
NexusRaven 生成的是 Python 函数调用语法。和 Gorilla 类似是代码风格，但 NexusRaven 生成的是抽象的函数调用，不绑定特定的 API 库。
格式的选择会影响你的工程实现。如果你的系统已经有成熟的 JSON 解析管线，Hermes 和 Functionary 更适合。如果你偏好代码风格的输出、或者需要直接执行，Gorilla 和 NexusRaven 的方式更直观。
准确率实测
准确率才是硬道理。我拿了几组不同复杂度的测试用例来跑。
简单调用（单函数、少参数）
任务：根据用户的自然语言请求，调用正确的函数并填写参数。例如”帮我查一下北京今天的天气”→ 应该调用 get_weather(city="北京", date="today")。
100个测试用例的结果：
| 模型 | 函数选择正确率 | 参数完全正确率 |
|---|---|---|
| Hermes 4 | 97% | 94% |
| Gorilla | 95% | 91% |
| Functionary | 96% | 93% |
| NexusRaven | 94% | 90% |
简单场景大家都很强，差异不大。
多函数选择
给模型提供10个可选函数，用户的请求可能匹配其中1-3个。需要模型判断该调用哪些函数、以什么顺序调用。
50个测试用例：
| 模型 | 函数选择正确率 | 调用顺序正确率 |
|---|---|---|
| Hermes 4 | 91% | 86% |
| Gorilla | 82% | 74% |
| Functionary | 88% | 82% |
| NexusRaven | 79% | 71% |
复杂度一上来，差距就明显了。Hermes 4 在多函数选择上的表现最好，特别是在判断调用顺序方面。这和 Hermes 系列长期在 Agent 场景下的训练积累有关——多步骤工具链本来就是 Hermes 的训练重点之一。
嵌套参数和复杂类型
最难的场景：函数参数包含嵌套对象、数组、可选字段等复杂类型。
30个测试用例：
| 模型 | 整体正确率 |
|---|---|
| Hermes 4 | 83% |
| Functionary | 80% |
| Gorilla | 68% |
| NexusRaven | 65% |
嵌套参数处理是所有模型的薄弱环节。Hermes 4 和 Functionary 表现相对更好，但也远没到”放心用”的程度。
一个典型的失败案例：让模型填写一个包含地址对象（街道、城市、邮编）的嵌套参数，Gorilla 和 NexusRaven 经常把嵌套结构拍平成顶层参数，导致格式错误。
并行和串行调用
一些高级场景需要模型同时调用多个独立的函数（并行），或者先调用 A 拿到结果后再调用 B（串行）。
并行调用：用户说”帮我同时查北京和上海的天气”，应该生成两个独立的 get_weather 调用。
Hermes 4 和 Functionary 都支持并行调用，成功率在85%以上。Gorilla 和 NexusRaven 在并行场景下表现不稳定，经常只生成一个调用或者把两个调用合并成一个。
串行调用（工具链）：先搜索产品 → 拿到产品ID → 查看详情 → 下单。
这是 Hermes Agent 的强项。Hermes 4 在3-4步的工具链场景下一次成功率约75%，而其他三个模型基本在50%以下。Hermes 系列在训练中大量使用了多步骤工具链的数据，这个投入在实测中体现得很明显。
错误恢复能力
工具调用不是每次都成功的。网络超时、参数不合法、API 返回错误——模型需要能理解错误信息并做出合理的后续决策。
测试方法：故意让工具返回各种错误（404、参数错误、超时等），观察模型的反应。
Hermes 4：表现最好。它能理解大部分错误信息的含义，并做出合理的应对——比如参数格式错误时重新生成参数，API 超时时建议用户稍后重试，找不到结果时换个搜索条件。
Functionary：错误恢复能力中等。它能识别错误发生了，但应对策略比较单一，通常就是简单地告诉用户出错了，缺少主动尝试修复的能力。
Gorilla 和 NexusRaven：错误恢复能力较弱。它们在收到错误返回后，经常要么忽略错误继续生成下一个调用（导致链式错误），要么直接把原始错误信息抛给用户而不做任何处理。
中文场景下的 Function Calling
用中文来触发 Function Calling 是一个容易被忽视的测试维度。
中文用户在和 Agent 交互时当然是说中文，但函数名和参数名通常是英文的。模型需要能准确地从中文自然语言中提取出对应的英文参数值。
举个例子：用户说”帮我搜一下五百块以下的蓝牙耳机”，模型需要生成 search_products(query="bluetooth earphones", max_price=500, currency="CNY")。这里面涉及到中英文语义映射。
实测下来，Hermes 4 在这方面表现最好，中文到英文的参数映射准确率约88%。其他三个模型因为训练数据以英文为主，中文场景下的参数提取准确率要低10-15个百分点。
当然，如果你的应用场景主要面向中文用户，在函数参数设计时把参数描述写成中文、接受中文参数值，可以大幅缓解这个问题。
部署考量
模型尺寸：Hermes 4 405B 最重，Gorilla 和 NexusRaven 基于 7-13B 的基座模型，最轻量。Functionary 有多个尺寸版本可选。
如果你只需要 Function Calling 能力而不需要强大的通用对话，用 Gorilla 或 NexusRaven 这种轻量级专用模型可能更经济。但如果你的 Agent 除了调用工具还需要做复杂的对话和推理，Hermes 4 的综合能力优势就显现出来了。
框架兼容性：Functionary 的 OpenAI 兼容格式最友好，基本不需要改代码就能对接现有的 OpenAI Function Calling 工作流。Hermes 的 ChatML 格式也被越来越多的框架支持。Gorilla 和 NexusRaven 的代码风格输出需要自己写解析逻辑。
最终评判
Function Calling 这个赛道上，没有一个模型在所有维度都完美。
综合能力最强：Hermes 4。多函数选择、工具链、错误恢复、中文支持——各项能力都比较均衡。如果你需要一个全能型的 Function Calling 模型，Hermes 是目前最稳的选择。
OpenAI 迁移最方便：Functionary。格式兼容性最好，迁移成本最低。如果你现在用的是 OpenAI 的 Function Calling，想换成开源方案，Functionary 是阻力最小的路径。
轻量级 API 调用：Gorilla。如果你的场景比较简单——只需要模型根据用户请求调用正确的 API，不需要复杂的多步骤推理——Gorilla 又小又快，性价比很高。
代码风格偏好：NexusRaven。如果你喜欢直接拿到可执行的 Python 函数调用而不是 JSON，NexusRaven 的输出风格更对味。
选哪个，还是那句话：看你的具体场景和技术栈。cocoloop 社区里有不少关于 Function Calling 的实战讨论，建议在做最终决定前去翻翻。
延伸阅读：OpenClaw 社区资源
本文由 CocoLoop 中文社区出品。如果你在研究 AI Agent 与主流模型的工程化落地，姊妹站 OpenClaw 中文社区 也许会有帮助：