1. 为什么 GLM-4-9B 在 BFCL 上能拿高分从榜单分数倒推评测逻辑如果你最近在选型 Function Calling 模型大概率会看到 GLM-4-9B-Chat 在 BFCLBerkeley Function Calling Leaderboard上的成绩被反复提及。但榜单上除了一个总分还挂着 AST 总分和 Exec 总分两列很多人第一次看会懵这两个分数到底在测什么为什么同一个模型在两个维度上会有差距我该信哪个先把结论说清楚BFCL 是伯克利 Gorilla 团队维护的函数调用评测榜单它用两套判定路径来评估模型把自然语言转成结构化工具调用的能力。AST 路径不真正执行函数而是把模型输出的 JSON 解析成抽象语法树逐项比对函数名、必填参数、参数类型、参数值Exec 路径则把生成的调用真正跑一遍看执行结果对不对。GLM-4-9B 之所以领先很大程度上是因为它在 AST 这一侧的结构化输出非常规整同时在 Exec 侧的可执行样例上也保持了较高通过率。这篇文章面向需要复现榜单结果的开发者。我会把两条判定路径拆开讲清楚给出可复制的评测配置片段并说明怎么通过 TaoToken 的统一 Key/API 通道接入被测模型在本地把验证流程跑通。你不需要先成为评测专家跟着步骤走就能得到自己的分数。BFCL 的评测数据集包含 2000 个问题-函数-答案对覆盖 Python、Java、JavaScript、REST API、SQL 等多种类型。其中 Python 类样例 1680 个是绝对主力。评测任务又细分为简单函数、多项函数、并行函数、并行多重函数以及聊天/相关性检测、REST API、SQL 等非 Python 类。理解这个构成你才能明白为什么单看一个总分不够——不同任务类型对模型能力的要求完全不同。AST 和 Exec 的分工是这样的AST 负责判断“你写的调用长得对不对”Exec 负责判断“你写的调用跑起来对不对”。一个模型可能 JSON 格式很漂亮但参数值填错AST 部分失分也可能格式一般但恰好能跑通Exec 得分还行。GLM-4-9B 的领先体现在两条路径上都比较均衡尤其是 AST 侧的必填参数和类型一致性做得扎实。2. TaoToken 前置准备统一 Key 与 API 通道接入被测模型在本地跑 BFCL 之前你需要一个能稳定调用被测模型的通道。BFCL 官方脚本默认走 OpenAI 兼容接口所以只要你的接入层提供 OpenAI 格式的/v1/chat/completions就能直接对接。TaoToken 在这里的作用是提供统一的 Key 和 API 通道让你不用为每个被测模型单独维护一套鉴权和地址。先明确三件套这是后面所有配置的基础Base URLhttps://taotoken.net/apiAPI Key在控制台创建形如sk-开头的一串字符Model ID被测模型的标识比如你要测 GLM-4-9B 就填对应的模型名创建 Key 的入口在控制台的 API Keys 页面登录后新建一个即可。这里有个细节BFCL 的评测脚本会并发发请求建议给评测单独建一个 Key方便后续按 Key 维度看用量和排查限流问题。拿到 Key 之后先做一次最小连通性验证别急着上评测脚本。用 curl 打一发curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: glm-4-9b-chat, messages: [{role: user, content: 你好}], max_tokens: 32 }如果返回里能看到choices数组和正常的message.content说明通道没问题。这一步能挡掉后面 80% 的“评测跑不动”问题——很多人的报错其实不是评测脚本的锅而是 Key 没生效或者 Base URL 写错了。关于模型选择如果你要复现 GLM-4-9B 的榜单结果Model ID 必须和榜单上标注的一致。不同版本的 GLM-4-9B比如 base 和 chat在 Function Calling 上的表现差异明显chat 版本才是榜单里那个。填错模型名你跑出来的分数对不上排查半天会发现是模型选错了。TaoToken 的接入文档里有各语言的最小示例Python 侧用 openai SDK 最省事from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api/v1, api_keysk-你的Key ) resp client.chat.completions.create( modelglm-4-9b-chat, messages[{role: user, content: 北京天气怎么样}], tools[{ type: function, function: { name: get_weather, description: 查询指定城市天气, parameters: { type: object, properties: {city: {type: string}}, required: [city] } } }] ) print(resp.choices[0].message.tool_calls)这段代码能跑通就说明你的通道支持 tools 参数可以进入正式评测了。注意base_url要带/v1这是 OpenAI SDK 的约定少写一段会 404。3. 可复制评测配置AST 与 Exec 两条路径的 settings 片段BFCL 的评测脚本通过配置文件指定模型、接入地址和评测类别。下面给出一份可直接改用的配置片段路径和字段名按官方仓库的结构来。假设你把 BFCL 仓库 clone 到本地配置文件放在berkeley-function-call-leaderboard/目录下。先看模型接入配置通常是一个 JSON 或 YAML 文件记录被测模型的 endpoint 信息{ glm-4-9b-chat: { model_name: glm-4-9b-chat, base_url: https://taotoken.net/api/v1, api_key: sk-你的Key, temperature: 0.001, max_tokens: 1024 } }temperature设成接近 0 是为了让输出稳定Function Calling 评测里随机性越小越好复现。max_tokens给 1024 足够函数调用的 JSON 一般不会太长。然后是评测类别选择。BFCL 把 AST 和 Exec 分开跑配置里要明确指定test_categories: - simple_python - multiple_function - parallel_function - parallel_multiple - relevance_detection - rest_api - sql evaluation_method: ast: true exec: true model_config: glm-4-9b-chat这里simple_python到parallel_multiple是 Python 类主力relevance_detection测的是模型该不该调用函数rest_api和sql走 Exec 路径。如果你只想快速看个大概先跑simple_python和multiple_function两类几分钟就能出结果。跑评测的命令大致是这样cd berkeley-function-call-leaderboard python openfunctions_evaluation.py \ --model glm-4-9b-chat \ --test-category simple_python \ --result-dir ./results结果会写到results/下包含每个样例的模型输出、AST 判定结果和 Exec 判定结果。AST 判定会逐项标注函数名对不对、必填参数齐不齐、类型一致不一致、值匹配不匹配。Exec 判定则记录函数是否成功执行、返回结构是否符合预期。如果你要测 Claude Code 这类编码场景的 Function Calling配置思路一样只是 Model ID 换成对应模型。TaoToken 的 coding-plan 页面有长期编码场景的套餐说明适合需要反复跑评测、调用量大的情况。评测本身是高频调用用按量计费还是套餐取决于你跑多少轮。配置里还有一个容易忽略的点并发数。BFCL 默认并发可能较高如果你的通道有速率限制把并发调低到 4 或 8避免大量 429。这个参数通常在评测脚本的命令行里用--num-threads指定。4. 验证请求与成功结果本地跑通一次完整评测配置就绪后先别跑全量用一个小样本验证整条链路。BFCL 支持指定样例数量跑 20 条simple_python看看。执行后你会看到类似这样的输出Loading model: glm-4-9b-chat Running category: simple_python Progress: 20/20 AST accuracy: 0.90 Exec accuracy: 0.85AST 准确率 0.90 意味着 20 条里有 18 条的结构化输出完全符合预期Exec 准确率 0.85 意味着 17 条真正执行成功。两个数字有差距是正常的因为有些调用结构对但参数值算出来不对或者依赖的外部 API 返回变了。具体到单条样例结果文件里会记录模型原始输出。一个正确的函数调用长这样{ name: calculate_triangle_area, arguments: { base: 10, height: 5 } }AST 判定会检查函数名calculate_triangle_area是否在函数列表里、base和height是否都是必填、类型是否都是数值、值是否和标准答案一致。四项全过才算这条 AST 正确。Exec 判定则真的调用这个函数看返回的面积是不是 25。如果模型输出里出现了函数列表里没有的函数名AST 会直接判错这就是所谓的函数幻觉。如果参数里多了一个函数定义中不存在的字段属于参数幻觉同样失分。GLM-4-9B 在这两类幻觉上控制得比较好这是它 AST 分数高的直接原因。跑通小样本后再跑全量。全量 2000 条按并发 8 算大概十几分钟到半小时取决于通道响应速度。跑完把results/下的汇总文件拿出来对照榜单看你的分数是否接近。如果差距很大先检查 Model ID 和 temperature这两个是最常见的偏差来源。验证模型对话能力可以用模型对话页面快速试几条确认模型本身响应正常再回到评测脚本。有时候评测跑不动不是脚本问题而是通道侧模型临时不可用。5. 本篇常见错排查401、local proxy failed 与 reading choices评测过程中最容易撞上的几类报错我按出现频率排一下并给出定位方法。401 UnauthorizedKey 无效或没带上。检查Authorization头是不是Bearer sk-xxx格式Key 有没有多余空格。如果你把 Key 写在配置文件里确认读取逻辑没把换行符带进去。还有一种情况是 Key 被删了或过期去控制台重新建一个。local proxy failed / connection refused这类报错通常指向 Base URL 写错或网络不通。确认地址是https://taotoken.net/api/v1注意/v1不能少。如果你在容器里跑评测检查容器能不能访问外网。这个报错和“代理”无关纯粹是地址或网络层的问题别往别的方向排查。Error reading choices / KeyError choices模型返回的 JSON 里没有choices字段。常见原因是请求体格式不对比如tools参数拼错、messages结构不合法导致服务端返回了错误对象而不是正常响应。把原始返回打印出来看error字段通常能直接定位。另一个原因是max_tokens设得太小模型还没输出完就被截断返回结构不完整。OAuth / token expired如果你用的是需要 OAuth 的接入方式token 过期会报这个。TaoToken 的 API Key 方式不涉及 OAuth如果你看到这个报错说明配置里混入了别的鉴权逻辑检查一下有没有残留的环境变量覆盖了 Key。AST 全错但 Exec 部分对这说明模型输出的 JSON 结构有问题但恰好能被解析执行。重点看函数名和必填参数通常是模型把参数塞到了错误的层级或者用了函数列表里没有的名字。调低 temperature 再跑一遍看是否稳定复现。Exec 报函数不存在评测脚本里的函数实现和数据集里的定义对不上。确认你用的数据集版本和脚本版本匹配BFCL 更新过数据集结构旧脚本配新数据会找不到函数。排查时养成一个习惯先把单条样例的原始请求和原始返回打出来。90% 的问题看这两样就能定位比盯着汇总分数猜有效得多。6. 语义一致 CTA把评测接入固定成可复用流程跑通一次评测之后建议把接入配置固化下来下次换模型只改 Model ID。TaoToken 的 API Keys 页面可以管理多个 Key给评测单独留一个方便按用量排查。接入文档里有各语言的完整示例Python、Node、curl 都有照着改 base_url 和 model 即可。如果你要长期做 Function Calling 评测和 Agent 开发Coding Plan 更适合高频调用场景不用每次担心额度。模型对话页面适合快速验证单个模型的工具调用行为改改 prompt 和 tools 就能看输出。把 BFCL 的 AST 和 Exec 两条路径都跑一遍你会对“模型函数调用能力”有更具体的认知AST 告诉你模型写调用写得规不规范Exec 告诉你这些调用能不能真正解决问题。GLM-4-9B 的领先不是单点突破而是两条路径上都少犯错。你自己复现一遍比看任何榜单解读都清楚。