事件经过
本 周，r/LocalLLaMA 上的一篇帖子引发了社区关 注：开发者 /u/mr_il 在将 Qwen3.6-35B 用于 agentic 编程工作流时，观察到其工具调用可靠性 和推理循环行为相较 Qwen3.5 出现了明显退步。该 测试者在多种量化格式下——包括 8-bit MLX、Q6_K_XL、Q8_XL 以 及 BF16——均复现了相同的故障模式。
测试通过 OpenCode agent 进 行，分别以 oMLX 和 LM Studio 作为推 理后端，并全程采用官方推 荐的精度任务参数：temperature 0.6、 top-k 20。核心发现是：与前代模型相比，该 模型更频繁地陷入无限推理循环，工具调用失败率也更高。
为何 值得关注
Agentic 编程工作流——即模型需 要规划任务、调用工具、评估输出并迭代执行——是推动工程 师群体采用本地 LLM 的最高价值场景之一。一个 在循环控制上出现退步的模型，无 论其在静态评测基准上的分数多么亮眼，在 多步骤任务中实际上都是不可用的。
这里 描述的故障模式——过度防御性自检、 而非推进任务执行——是 RLHF 高 度优化模型中一类已知的失效形式。训 练过程中的奖励黑客行为（reward hacking）会导致模型产 生冗长的自我审查输出，从而阻塞执行图的推 进。若该问题在更大范围内得到确认，这将代 表一次训练层面的退步，而非量化引发的伪影—— 因为该行为在 BF16（全精度）和多种压缩格式下表现一致。
报 告还将工具调用失败列为次要问题，但测试者指出，这也可能源 于工具链中的解析器（parser）缺陷，而非模型本身。这一区分至 关重要：模型侧的工具调用格式错误属于能力退步 ；解析器侧的故障则是可在下游修复的集 成 bug。
问题范围
- 无限推理循环在所有测 试量化级别下均有观察（8-bit MLX、Q6_K_XL、Q8_XL、BF16）
- 故障集中出现在复杂任务上——测试者以一个简单 3D 游戏作为触 发临界点
- 基础应用生成据报未受影响
- 工具调用失败 已被标记，但成因尚未确认（模型侧还是 解析器侧）
技术细节
所描述的行为——持 续自我复查却毫无进展——与在训练后对齐 阶段被过度优化为"谨慎优先"的模型表现一 致。当模型在 RLHF 或 DPO 训练中，奖励信号对错误答案 惩罚过重、而对不作答或循环行 为惩罚不足时，模型便会学会通过反复验证先前步骤来规 避风险，而非果断发起工具调用或代码写入。
在 agen tic 循环中，这一问题会进一步放大：每次重新验证都消耗上下文 窗口，如果模型的内部状态持续标记不确定性，就永远无法发出本可 消除歧义的工具调用。最终结果是上下文耗尽却任务未完成——测 试者描述这种情况甚至在"上下文几乎为空"时也会 发生，这表明循环是由任务复杂度信号触发的，而非上下文压力本 身。
BF16——未经量化的全精度推理——同样出现了 相同的行为，这排除了量化导致退步的可能性，将根 本原因指向基础模型或其微调过程，而非压缩管道。
据
来源披露，测试环境参数为：temp=0.6, top_k=20
，通过 OpenCode agent 在 oMLX 和 LM Studio 上运行。这些是保守的推理参数，与
Qwen 官方针对确定性任务执行的推荐设置一致。
后 续关注点
- 社区复现：r/LocalLLaMA 上 的这篇帖子只是第一个信号，尚非定论。未 来两周内，需关注来自运行 结构化 agentic 评测（如 SWE-bench 风 格或工具调用准确率基准）团队的佐证报告。
- Alibaba/ Qwen 团队回应：若循环退步在更大范围内得到确认，预 计 Qwen 团队将发布经过微调的修复版本或更新系统提示（ system prompt）指导。其模型迭代节奏一 贯较快。
- 工具链排查：OpenCode 和 LM Studio 的维 护者应独立调查解析器侧的工具调用失败问题。即便不等待模型更新， 该层面的修复也可能部分缓解已报告的失 败率。
- 竞品动态：若 Qwen3.6-35B 的 agentic 退步得 到确认，将为竞争性 30B 级别模型重新打开本 地编程 agent 部署的市场空间——包括 Mistral 以 及 Meta 的 Llama 系列。
注：本报告基于单一社区测试者的发 现，尚未经 Alibaba 独立核实或确认。请将 其作为早期信号看待，需经更多复现验 证后方可对模型整体质量做出结论。