我在本地代理席位中换上了一个“更好”的9B模型。在80次尝试中，它有5次将工具调用静默地写成了普通文本。

在信任本地代理席位的模型更换之前，我进行了一次正式的比较，有趣的部分不在于哪个模型得分更高，而在于较差的那个模型是如何失败的。 设置：20个任务模拟实际代理工作，每个类别（读、写、编辑、补丁）各五个，使用我工具中的真实工具模式，而非简单示例。每个任务以四种方式运行，覆盖种子和思考模式，因此每个模型有80次尝试。 现有模型是qwen3.5:9b。挑战者是MiMo-V2.6-Distill-Qwen-9B，量化为IQ4_XS。 关键数据：现有模型严格通过45/80，挑战者为30/80。Fisher精确检验p = 0.026，因此这是一个真实的差距，而非种子噪声。 但分数是我学到的最不有用的东西。挑战者有五次将工具调用写入回复文本，而不是发出调用。现有模型则没有。 如果你不比较解析后的tool_calls和回复内容，这会被视为成功。模型描述调用工具，对话记录看起来合理，但什么都没执行。这是代理最糟糕的失败形态，因为重试逻辑不会触发，而人类浏览输出时会看到未发生的工作。 二十次补丁尝试中有十六次输入为空。现有模型至少生成了格式错误的补丁体，可以检测和修复。空参数通过形状检查，但不执行任何操作。 有两次它调用了工具列表中从未有过的bash工具。对于沙盒席位，这不是质量问题，而是边界违规。模型发明未授予的能力，正是你的权限模型应该防止的，值得直接测试。 八次完全偏离为普通文本而没有调用，对比一次。 一个方法论说明让我避免了错误的结论。在责怪模型之前，我验证了两个GGUF共享相同的聊天模板，逐字节相同，特殊token ID和预分词器也一致。大多数“这个模型不擅长工具调用”的说法都是模板错误。先检查这个，否则你的结果毫无意义。 注意事项：单轮、80次尝试、一个量化版本，且没有推理评估，而推理正是蒸馏模型构建的目的。延迟和内存消耗差不多。 无论选择哪个模型，我都会从中学到两件事。统计以文本形式出现的工具调用，并将其视为一个独立的失败类别，而不是归入“错误答案”。同时，对工具列表进行断言，因为一个发明工具名称的模型最终可能会发明你已有的工具。