90 轮代理任务实测：ThinkingCap、Fable Fusion 与原生 Qwen3.6-27B 对比

Reddit 用户 kmarble 在 r/LocalLLaMA 发布了一项针对代理任务（agentic）场景的模型对比实测，对象为 ThinkingCap、Fable Fusion 两个微调版本，以及原生 Qwen3.6-27B。整套测试共 90 次独立运行，覆盖 6 个自我评分任务，每个任务重复 5 次。

测试环境与方法

所有运行在作者的 Kubernetes 集群上以全新 Coder workspace 形式启动，由其自研代理框架 Hermes 驱动，模型通过 llama.cpp 与 llama-swap 在单张 RTX 5090 上服务。每次模型调用都经 OpenTelemetry shim 接入 SigNoz 进行追踪，完整对话记录逐次保存。三组测试使用相同的采样参数和 131k 上下文窗口，研究假设在首次运行前即预先注册，以避免事后调整。

所有 90 次运行均通过，因此单凭通过率无法区分模型，差异体现在效率与行为细节上。

主要量化发现

• ThinkingCap 相比 stock 减少 34% 的思考 token，并在 6 项任务中的 5 项上耗时最短。
• Fable Fusion 比 stock 多出 24% 的模型调用次数，但产出结果与 stock 相同。
• ThinkingCap 与其他模型相比，工具调用次数基本持平，但推理文本比 stock 少约 40%。
• 一次 Fable 运行在单个价格问题上消耗了 94 次工具调用。
• 一次 ThinkingCap 运行在追查一个 llama.cpp 发布标签时连续调用约 10 次工具，而 stock 仅用一次 API 调用完成。

行为特征分析

ThinkingCap 的效率呈现明显双峰分布：最佳运行是全场最便宜的，但两次最差运行也是全场最贵的。其优势更多体现在推理文本的精简，而非更少的动作步骤。

Fable Fusion 是最强的「调查者」，但也是最不可信的「叙述者」。它是唯一会主动校验失效配置是否为当前生效配置的模型，并在研究类任务中表现最佳：能从零售商页面的内嵌 JSON 中解析变体价格，通过 GitHub Users API 识别 llama-swap 维护者。然而在同一次运行中，它将 llama-swap 的维护者张冠李戴为「前 Red Hat 工程师 Matthew Garrett」，而实际维护者是 Benson Wong（mostlygeek）。模型将两个真实身份融合到一起，并仍通过了评分器。

原生 Qwen3.6-27B 表现最平淡但最严谨：补丁形式统一，会回读自己的输出，零虚构事实，并在多数任务上以「形式分」胜出。

结论与启示

作者认为基础模型仍应作为默认选择；多数微调版本并不优于其底座，90 轮测试并未改变这一结论。只有当思考 token 延迟成为瓶颈时，ThinkingCap 才值得专门考虑。完整的实验设计、各 lane 配置与逐任务分析已发布在作者博客。