以 Agent 工具调用为核心的模型基准：Goose "Vibe Check" 评测方法与开源模型实测解读

本篇指南以 Goose 官方首轮模型评测（Goose Vibe Check）为对象，完整介绍其社区化评测思想、8 任务 × 3 次的评测协议、LLM-as-a-judge 评分细则，以及 32 个闭源/开源模型的实测排行。读者将同时掌握：如何在本地用 Ollama 复现这类评测、如何理解 ToolShim 桥接层对不支持原生工具调用模型的补救与局限，以及上下文长度、量化等级、GPU 后端等直接影响 Agent 表现的关键工程参数。文中结论均有 官方评测博客、ToolShim 源码 或 benchmark 脚本 作为依据。

为什么要把"Agent 能力"单独拿出来评测

Goose 是一个开源、可扩展的 AI Agent：它能安装、执行、编辑代码并配合任意 LLM 做测试。正因为 Agent 的典型工作流是"工具调用循环"——例如修改文件要先在文件系统中定位、查看内容、再执行写入——Goose 团队认为：模型在问答/代码生成类基准上的得分，并不能代表它在真实 Agent 场景下调用工具完成多步任务的能力。

Vibe Check 的评测灵感来自 r/LocalLlama 等社区自发的"草根评测"：爱好者用"写一个 flappy bird""做一个弹球旋转六边形动画"这类直观任务快速比较模型。这类评测不追求学术基准的严格性，但能给出跨模型、跨版本的可读能力信号。Goose 在此精神上发布了第一版 Goose Vibe Check leaderboard，专门衡量模型"驾驶 Goose 完成工具型任务"的能力。

提示：本评测结果反映 博客原文 发布（2025 年 3 月底）时各模型的版本与推理服务状态。模型迭代很快，阅读历史榜单时应以发布时间为前提。

第一版排行榜：32 个模型的平均得分

所有任务默认使用 *toolshim 标记的模型表示一种特殊配置：主模型 + 一个本地小模型（Ollama）作为"解释器"，把主模型的自然语言输出转译成 Goose 可调用的工具。评测期间这些模型需工具调用能力，但其中部分并不原生支持，因此采用 ToolShim 方案（详见下文"ToolShim 桥接层"）。

Rank	Model	Average Eval Score	Inference Provider
1	claude-3-5-sonnet-2	1.00	databricks (bedrock)
2	claude-3-7-sonnet	0.94	databricks (bedrock)
3	claude-3-5-haiku	0.91	databricks (bedrock)
4	o1	0.81	databricks (bedrock)
4	gpt-4o	0.81	databricks (bedrock)
6	qwen2.5-coder:32b	0.8	ollama
7	o3-mini	0.79	databricks (bedrock)
8	qwq	0.77	ollama
9	gpt-4o-mini	0.74	databricks (bedrock)
10	deepseek-chat-v3-0324	0.73	openrouter
11	gpt-4-5-preview	0.67	databricks
12	qwen2.5:32b	0.64	ollama
13	qwen2.5:14b	0.62	ollama
14	qwen2.5-coder:14b	0.51	ollama
15	deepseek-r1-toolshim-mistral-nemo*	0.48	openrouter
16	llama3.3:70b-instruct-q4_K_M	0.47	ollama
17	phi4-toolshim-mistral-nemo*	0.46	ollama
18	phi4-mistral-nemo	0.45	ollama
19	gemma3:27b-toolshim-mistral-nemo*	0.43	ollama
20	deepseek-r1-toolshim-qwen2.5-coder7b*	0.42	openrouter
21	llama3.3:70b-instruct-q8_0	0.41	ollama
22	deepseek-r1:14b-toolshim-mistral-nemo*	0.37	openrouter
23	deepseek-r1-distill-llama-70b-toolshim-mistral-nemo*	0.36	ollama
24	phi4-toolshim-qwen2.5-coder7b*	0.3	ollama
25	mistral-nemo	0.27	ollama
26	deepseek-r1-distill-llama-70b-toolshim-qwen2.5-coder7b*	0.26	openrouter
27	llama3.2	0.25	ollama
28	gemma3:27b-toolshim-qwen2.5-coder7b*	0.24	ollama
29	deepseek-r1:14b-toolshim-qwen2.5-coder7b*	0.22	ollama
29	gemma3:12b-toolshim-qwen2.5-coder7b*	0.22	ollama
31	mistral	0.17	ollama
32	gemma3:12b-toolshim-mistral-nemo*	0.15	ollama

*关于 toolshim 行的解读：得分偏低可能反映的是 shim 层性能而非基础模型本身。所有标注 toolshim 的模型在此次实验中的表现均不理想，这是后续改进 shim 的出发点。

开源模型部署细节与参数量

参与评测的开源模型，其参数量与量化档位如下（本地运行于消费级硬件，如 RTX 4080 与 Mac M 系列）：

Rank	Model	Model Params	Quantization
1	qwen2.5-coder:32b	32B	Q4_K_M
2	qwq	32B	Q4_K_M
3	deepseek-chat-v3-0324	671B total, 37B active	-
4	qwen2.5:32b	32B	Q4_K_M
5	qwen2.5:14b	14B	Q4_K_M
6	qwen2.5-coder:14b	14B	Q4_K_M
7	deepseek-r1-toolshim-mistral-nemo	671B total, 37B active	fp8
8	llama3.3:70b-instruct-q4_K_M	70B	Q4_K_M
9	phi4-toolshim-mistral-nemo	14B	Q4_K_M
10	phi4-mistral-nemo	14B	Q4_K_M
11	gemma3:27b-toolshim-mistral-nemo	27B	Q4_K_M
12	deepseek-r1-toolshim-qwen2.5-coder7b	671B total, 37B active	fp8
13	llama3.3:70b-instruct-q8_0	70B	Q8_0
14	deepseek-r1:14b-toolshim-mistral-nemo	14B	Q4_K_M
15	deepseek-r1-distill-llama-70b-toolshim-mistral-nemo	70B	-
16	phi4-toolshim-qwen2.5-coder7b	14B	Q4_K_M
17	mistral-nemo	12B	Q4_0
18	deepseek-r1-distill-llama-70b-toolshim-qwen2.5-coder7b	70B	-
19	llama3.2	3B	Q4_K_M
20	gemma3:27b-toolshim-qwen2.5-coder7b	27B	Q4_K_M
21	deepseek-r1:14b-toolshim-qwen2.5-coder7b	14B	Q4_K_M
21	gemma3:12b-toolshim-qwen2.5-coder7b	12B	Q4_K_M
23	mistral	7B	Q8_0
24	gemma3:12b-toolshim-mistral-nemo	12B	Q4_K_M

参数规模与得分的关系

博客通过参数规模对比图给出如下观察：在 15–32B 档位，qwen2.5-coder:32b（0.80）与 qwq（0.77）表现突出；同时各尺寸档位都呈现出原生工具调用模型与 toolshim（虚线）模型之间的稳定差距。结论指向：原生工具调用能力对 Agent 型任务影响显著，若能在工具调用上针对性增强，更大的开源模型有望缩小与闭源模型在 Agent 场景的差距。

Token 消耗与得分的关系

从博客公布的数据看，Claude 系列无论 token 消耗多少都能拿下 0.9+ 高分；qwen2.5-coder:32b 这类开源模型以适中 token 消耗取得较好成绩。toolshim 模型整体得分偏低，说明 shim 在弥补原生工具支持差距上收效有限；而 token 消耗在到达某个临界点之前，通常越多表现越好。

工具调用次数与得分的关系

工具调用过少或过多都会拉低得分——有效的工具调用质量（而非单纯频率）与表现相关。toolshim 模型普遍调用更少的工具，提示当前 shim 实现不足以让模型正确命中目标工具。

关键结论

综合 32 个模型、每模型 24 次运行的评测，官方总结出五条核心发现：

1. 闭源模型目前整体领先：Claude、GPT 系列在 Agent 型任务上仍普遍优于开源替代。
2. 开源挑战者崭露头角：Qwen 系列与 deepseek-chat-v3-0324 展现出明显潜力，但在全任务的一致性、可靠性上尚未达到闭源模型水平。
3. Token 效率至关重要：部分开源模型能以更少 token 达成不错成绩，意味着更快的任务完成时间与更低成本。例如 claude-3-7-sonnet 与 claude-3-5-sonnet-2 表现相近，但前者 token 消耗显著更高。
4. 工具调用是分水岭，但开源模型目前还不够稳：可靠地生成结构化工具调用仍是显著差异点。
5. 评测集仍需扩容：仅 8 个任务（各跑 3 次）不足以区分头部模型——0.77–0.81 区间聚集了多个模型，正是任务偏简单、复杂推理要求偏低的体现。

评测方法论：8 任务 × 3 次，聚焦工具调用

Vibe Check 的核心差异点是：不同于侧重文本生成的基准（问答、代码生成），它强调工具调用能力。工具调用让模型得以操作 MCP 扩展、发起 API 请求，从而扩展 Goose 的能力边界。很多任务要求多次链式工具调用：例如修改文件需要先定位、再查看内容、最后写入，每一步都必须正确执行。

评测套件：Core Suite 与 Vibes Suite

• Core Suite（核心套件）——面向开发者工作流的基础操作：
  • Create a file：生成并保存新文件；
  • List files：读取并展示目录内容；
  • Developer Search/Replace：在大文件中搜索并完成多次替换。
• Vibes Suite（氛围套件）——"vibe check"式多样化任务，其中 Flappy Bird、Goose Wiki 输出可直接肉眼比对：
  • Blog summary：抓取博客并总结要点；
  • Flappy Bird：用 Python 实现 2D 游戏；
  • Goose Wiki：制作一张关于 Goose 的 Wikipedia 风格网页；
  • Restaurant research：检索纽约东村最佳川菜馆；
  • Squirrel census：对 CSV 做数据分析。

套件仍处于持续扩充阶段，官方欢迎社区贡献高质量、有区分度的任务。

执行协议

• 每模型执行上述 8 个任务 × 3 次 = 24 次运行；
• 每次评测为单轮 prompt，未来可能扩展到多轮与迭代改进；
• Goose 必须以无用户介入的工具执行循环自主完成任务；
• 若 Goose 中途停下征求用户意见（如"我准备把如下内容写入文件，是否继续？"），该次任务被视为未完成——即使方向正确也不算成功；
• 每任务跑 3 次以吸收输出随机性。

评分与判据

榜单分数 = 各任务得分的平均；任务得分 = 该任务 3 次运行归一化到 0–1 后的平均。每个任务按以下维度打分：

1. 工具调用执行：模型是否正确发出了完成任务所需的工具调用；
2. LLM-as-a-judge（部分任务适用）：用 GPT-4o 按 0–2 分评估回答质量——0 分：错误或根本性缺陷；1 分：部分正确但有瑕疵；2 分：完全正确且执行良好。每次生成 3 份评审，取众数；必要时补第 4 次评审打破平局；
3. 任务特定标准：输出格式正确（如 markdown、写文件）、期望答案命中（如数据分析洞察）、实现合法（如 Python 代码可运行）。

代码执行、文件创建类任务有近似单元测试的清晰 pass/fail 边界；博客总结、餐馆研究等开放式任务则依赖定性与 LLM 判分。评测还额外记录 Token 效率（成功运行消耗的 token 总数）与 Duration（任务耗时）。耗时不进榜单——它严重受推理服务商与硬件影响。

人工抽检观察

在 768 次总运行（32 模型）规模下无法全量人工校验，抽查结论包括：

• LLM 判分对"完全错误（0 分）"辨识可靠，但对 1 分与 2 分的区分较主观；
• 博客总结、餐馆检索等任务缺乏自动化事实核验：框架能确认"是否调用了工具（如执行了 web 搜索）"，LLM 判分能部分评估指令遵循度，但系统整体无法验证回答事实是否准确；
• 工具执行失败是性能波动主因：模型也许能生成正确文本，但若没把输出写入指定文件等后续工具动作执行到位，任务即不完整——这正是 Agent 需要"自主多步行动"而非"仅生成正确答复"的证据。

开源模型的两大技术挑战

上下文长度限制

评测早期遇到的典型约束：Ollama OpenAI 兼容端点默认上下文仅 2048 token，远不足以支撑交互式 Agent。仅 Goose 系统提示词就约消耗 1000 token，留给用户查询、上下文与工具返回的空间所剩无几，长任务会因丢上下文而失败。评测期间 Ollama 引入了上下文长度覆盖（override）参数，得以缓解。量化（如默认 4-bit）虽省显存但可能损伤性能。

工具调用格式不一致

不同模型对工具调用格式预期不同——Ollama 要求 JSON，部分模型用 XML，Functionary 用 XML，这给推理服务商带来适配负担。评测中还观察到随宿主与输入输出格式变化的性能波动。模型训练侧需要标准化的工具调用格式。对不支持原生工具调用的模型，Goose 团队开发了 "toolshim" 解释层。

ToolShim 桥接层：源码级原理与实测局限

核心机制

对不支持原生工具调用的模型（如 DeepSeek、Gemma3、Phi4），ToolShim 用一个更小、本地的模型作为"解释器"，把主模型的自然语言回答翻译成 Goose 可以执行的结构化工具调用，小模型侧依赖 Ollama 的 structured outputs 强制输出格式。

这与 Goose 仓库中的 ToolShim 模块 实现一致：其注释定义了五步流水线——取出任意 LLM 的文本输出 → 交给独立的解释器模型 → 由模型抽取工具调用意图并格式化为合适形态 → 转换为 CallToolRequestParams → 把工具调用回填到原始消息。

从源码看，该模块有这些可验证的关键设计：

• ToolInterpreter trait（crates/goose/src/providers/toolshim.rs#L854-L862）定义了"把文本解析为工具调用"的统一接口，并提供 OllamaInterpreter（调用 Ollama /api/chat）与 llama.cpp 本地 LocalInterpreter 两种实现；
• 默认解释器模型为 mistral-nemo（DEFAULT_INTERPRETER_MODEL_OLLAMA），可通过 GOOSE_TOOLSHIM_OLLAMA_MODEL 覆盖；
• 结构化输出 schema（L965-L989）要求模型输出形如 {"tool_calls": [{"name": ..., "arguments": {...}}]} 的 JSON；
• 模块内还包含宽容的工具名解析：能容忍 functions.shell:0、Developer.shell 等带前缀/别名/角标的写法并归一化到真实工具名，甚至针对 execute/execute_code 别名做兼容处理与安全拒绝（L118-L164）。

启用方式见 Ollama Tool Shim 实验文档 与 Tool Shim 指南：

# 1. 启动 Ollama 并拉取默认解释器模型
ollama pull mistral-nemo

# 2. 以 shim 模式启动 goose
GOOSE_TOOLSHIM=true goose session

如需更换解释器模型：

export GOOSE_TOOLSHIM=true
export GOOSE_TOOLSHIM_OLLAMA_MODEL=llama3.2

若使用 goose 内置本地推理（llama.cpp）作为解释器而非独立 Ollama 实例，可切换后端：

export GOOSE_TOOLSHIM_BACKEND=local      # 合法值：ollama(默认) / local / llama.cpp
export GOOSE_TOOLSHIM_MODEL=my-model-name   # 或配置 LOCAL_LLM_MODEL

从源码可见后端解析逻辑（crates/goose/src/providers/toolshim.rs#L74-L90）：GOOSE_TOOLSHIM_BACKEND 缺省即为 ollama；local/llama.cpp 后端要求必须提供 GOOSE_TOOLSHIM_MODEL 或 LOCAL_LLM_MODEL，否则报错。benchmark 驱动脚本（scripts/run-benchmarks.sh#L49-L55）也会把 -t/--toolshim 映射为 GOOSE_TOOLSHIM=1、-m 映射为 GOOSE_TOOLSHIM_OLLAMA_MODEL，可见 shim 变量已是评测工具链的一等公民。

为什么 shim 效果受限

博客指出两条核心原因：

• 指令遵循不足：解释器多为小模型，长输入下指令遵循能力弱，解析主模型输出为正确工具调用时易出错；同时 shim 模型对提示措辞非常敏感；
• 结构化输出干扰：Ollama 结构化输出会影响 token 采样过程——最终 JSON 质量受限于小模型本身的信息抽取与 JSON 生成能力。

实测中，所有 toolshim 配置的模型在实验里均未能达到理想的成功率。博客作者认为微调 shim 模型使其专门面向工具调用生成，是未来的潜在方向。

本地模型用户的实战建议

针对在消费级硬件（RTX 4080、Mac M 系列）上用 Ollama 跑开源模型的用户，官方给出四条经验：

1. 扩大上下文长度

默认 2048 token 很快会被系统提示词占满。通过环境变量启动 Ollama 即可扩大：

OLLAMA_CONTEXT_LENGTH=28672 ollama serve

也可在 Ollama Modelfile 中设置上下文长度后执行 ollama create 重建模型。

2. 关注量化等级

• 4-bit：压缩最大、显存要求最低，但可能牺牲质量；
• 8-bit：消费级硬件的均衡之选，性能与质量俱佳；
• 16-bit：质量更高，但显存需求显著增加，低端硬件可能受限。

Ollama 多数情况默认 4-bit；对复杂推理或工具使用任务，建议测试 8-bit 等更高量化档位。

3. 小模型更吃提示工程

小模型推理容量有限，对提示变化更敏感，通常需要更明确、更少歧义的指令。必要时把任务进一步拆解，压缩可能的输出范围。

4. 硬件与显存管理

评测使用了 Apple M1、NVIDIA RTX 4080、RTX 4090、H100 等混合硬件与多家推理服务；正因硬件差异，任务耗时未纳入榜单。GPU 后端选择上：

• CUDA（NVIDIA）：本地 LLM 当前性能与兼容性最优，多数开源模型与推理框架优先针对 CUDA 优化；
• Metal（Apple Silicon）：M 系列上加速良好，7B–13B 模型已日趋可用；
• ROCm（AMD）：支持持续改善但仍落后于 CUDA，部分模型与量化方式可能遇到兼容问题。

Ollama 会把模型层在 CPU/GPU 间拆分，使超过单卡显存的大模型也能运行，但要注意两点：模型不完全驻留显存时，CPU↔GPU 的持续数据搬运会显著拖慢性能；完全装入显存的模型会比需要 CPU 卸载的快得多。

5. 云端托管开源模型的注意点

经 OpenRouter 等云服务跑 70B 级开源权重时，性能可能因不同托管服务而异：后端可能悄悄量化、采用影响工具调用的不同集成模式、或使用不同硬件配置。建议实测多家服务；OpenRouter 支持按需求指定路由到特定 provider。

在 Goose 上复现与扩展自己的评测

Goose 鼓励社区用各自硬件与配置自行评测，并欢迎贡献更多 eval。仓库中的 run-benchmarks.sh 提供了一个批处理入口：它接受 provider:model 对与套件名，设置 GOOSE_PROVIDER/GOOSE_MODEL 环境变量后调用 goose bench --suites <suites> --output <file> --format json，产出 JSON 与 summary，再经 parse-benchmark-results.sh 汇总分析。常用参数示例（来自脚本 usage 与实现）：

# 运行 core、small_models 两套评测
./scripts/run-benchmarks.sh \
  --provider-models 'openai:gpt-4o,anthropic:claude-sonnet-4' \
  --suites 'core,small_models' \
  --output-dir ./benchmark-results

若要以 toolshim 模式批量评测（对应博客中标注 * 的配置）：

./scripts/run-benchmarks.sh -p 'ollama:gemma3:12b' -s 'core' -t -m mistral-nemo

脚本会把 -t 映射为 GOOSE_TOOLSHIM=1、-m 映射为 GOOSE_TOOLSHIM_OLLAMA_MODEL（见 scripts/run-benchmarks.sh#L161-L167）。注意脚本会优先使用 ./target/release/goose 或 ./target/debug/goose，未找到时才回退到系统 goose，且需要 jq 解析 JSON 结果。

未来方向

官方规划包括：用覆盖更多消费级硬件的评测理解系统要求、执行时间与量化档位影响；引入面向多模态模型的视觉评测（图像处理、多模态推理、可视化工具交互）；为面向非开发者的工作流设计评测；以及测试长上下文保持与多轮交互，评估模型在复杂、持续对话中的表现。

运行结果示例

• Flappy Bird：成功生成可用 pygame 游戏的模型运行样例以 GIF 形式存放于 flappy_bird_carousel 目录（含 claude-3-5-haiku、claude-3-7-sonnet、deepseek-chat-v3-0324、qwen2.5-coder-32b、qwq 等 12 个模型）；
• Goose Wiki：成功写出 index.html 的模型渲染效果见 wiki_pages_carousel 目录（21 个模型的网页截图）。缺失的模型多为"在聊天中输出代码并让用户自行落地"而未能自主写文件。

如果某模型能在纯文本对话里给出正确结果、却无法把结果通过工具写入磁盘，任务依然判为失败——这正是 Vibe Check 想量化的、问答基准无法揭示的 Agent 能力差距。