前言：當「單次提示完美」遇上「多輪對話崩潰」
最近 r/LocalLLaMA 上有一篇帖子引發了廣泛共鳴——一位使用者在 RTX 6000 上跑 Qwen 3.6 27B，發現它在單一提示（single prompt）下表現驚人，能輸出漂亮的 HTML 頁面、生成长內容；但一旦進入 Agentic Work（多輪工具呼叫代理工作），每四輪左右就會出現一次「完全腦死」的行為：亂改檔案、跳錯路徑、重複走相同流程……
「它在單次提示下很優秀，但在 agentic work 中絕對崩潰。每隔幾輪就做一件完全腦殘的事。」
這篇文章的討論串長達數百則回覆，匯聚了數十位在地端部署 Qwen 系列模型的實戰經驗者。今天我們就來系統性地整理：Qwen 3.6 27B 在 Agentic Work 中為什麼會崩潰？核心原因是什麼？又該如何修復？
一、問題全貌：什麼叫「四輪腦死」？
根據原始帖者的描述，典型的崩潰行為包括：
| 症狀 | 具體表現 |
|---|---|
| 工具呼叫失敗 | 多工具呼叫時產生 malformed JSON，污染後續 context |
| 思考區塊洩漏 | </think> tag 遺失，導致 reasoning block 跨輪堆積 |
| 路徑跳躍 | 突然 cd / 到根目錄、讀取不存在的 .tokenring/linters/ 路徑 |
| 內容覆蓋錯誤 | 無視指導原則，直接覆寫既有文件 |
| 循環執行的 | 重複走相同決策路徑，無法自我修正 |
最關鍵的觀察是：這些問題不是隨機的，而是系統性的。 一位 vLLM 開發者指出：「每當模型有自由選擇工具/格式/參數的機會，就等於多擲一次骰子；8-12 輪之後，你幾乎保證會遇到一次壞結果。」
二、五大核心原因解析
1. preserve_thinking 未啟用（最常見的原因）
Qwen 3.6 是首批原生支援「思考過程跨輪保留」的模型之一。預設情況下，如果沒有設定 preserve_thinking=true，模型在每一輪都會忘記自己上一輪的思考結論，導致它重複走相同的路徑、做出相同的錯誤決策。
多位使用者證實：只要加上 preserve_thinking=true，「腦死」頻率從每四輪一次降到幾乎看不見。
「沒有 preserve thinking 的話，模型會以為每一輪都是全新的開始——它根本不知道上一輪已經得出了什麼結論。」
但要注意： Qwen 3.6 的原始 chat template 有一個 bug，即使設定了 preserve_thinking=true，舊版模板仍然無法正確處理 interleaved thinking（思考與工具呼叫交錯）的情況。這就引出了第二個關鍵原因。
2. Chat Template 不匹配
Qwen 3.6 的推理模式跟 3.5 不同——它會在同一個回應中交錯輸出思考區塊和工具呼叫。原始 template 無法正確處理這種情況，導致：
</think>closing tag 遺失- 後續輪次的 context 被 reasoning block 污染
- KV cache 無效化（cache invalidation）
社群貢獻者 froggeric 修復了這個問題，提供了 Qwen-Fixed-Chat-Templates ，支援所有主流推理框架（llama.cpp、vLLM、MLX 等）。另一位貢獻者 Allan Chan 則進一步推出了 qwen3.6-enhanced.jinja ，專門處理 CoT leakage（思考洩漏）問題。
核心修復邏輯： 在渲染 tool call 之前，檢查是否有未關閉的 </think> tag——如果有，自動補上 closing tag，確保工具呼叫不會被困在 reasoning block 裡面。
3. Tool-call Parser 不正確
另一位 vLLM 開發者指出了一個常被忽視的問題：
「當我用 XML tool-call parser 時，多工具呼叫的回合會產生 malformed JSON。這些垃圾被 replay 到下一輪 context，看起來就像模型突然發瘋。」
Qwen 3.6 支援兩種 tool-calling 格式：
- XML 格式（預設）：
<tool_call>tool_name[ARGS]...[/tool_name] - Qwen3 Coder 格式：專門針對 coding agent 優化的 parser
選擇錯誤的 parser 會直接導致工具呼叫解析失敗，進而污染後續輪次。
4. Quantization 過低 + KV Cache 精度不足
多位使用者提到一個關鍵細節：KV cache 的量化格式對 Qwen 3.6 特別敏感。
| KV Cache 設定 | 效果 |
|---|---|
--cache-type-k q8_0 --cache-type-v q8_0 | ✅ 穩定，推薦 |
--kv-unified（預設） | ⚠️ 可能導致長期運行漂移 |
| FP8 KV cache（無 prefix caching） | ❌ 每輪浮點誤差累積，模型表現不一致 |
一位使用者分享：「即使啟用了 preserve thinking、換了修復 template、加了 --swa-full，27B Q8 還是會產生 ‘Sampling Configuration’ 這種奇怪輸出。換成 Q5_K_XL 後才穩定。」
核心原則： Agentic work 對 quantization 敏感度遠高於一般對話。Q4 在 coding agent 中尚可接受，但超過 6-8 bit 的量化（如 FP4、低品質 MXFP4）會顯著降低多輪可靠性。
5. Harness / Agent Framework 不匹配
最後一個常被忽視的原因：你用的 agent harness 可能不是為小模型設計的。
Qwen 3.6 27B 的推理能力在「特定場景下」可以接近 Claude Sonnet 等級，但它不像 122B 那樣有足夠的參數來容錯。一個過度複雜的 system prompt、太多 tool definitions、或沒有做好 context 管理的 harness，都會讓小模型迅速超載。
三、完整修復方案（從高到低優先級）
以下按影響程度排序，建議依序嘗試：
🥇 Level 1：Chat Template + preserve_thinking（必做）
llama.cpp：
./build/bin/llama-server \
-m Qwen3.6-27B-Q8_K_XL.gguf \
--jinja \
--chat-template-file /path/to/qwen3.6-enhanced.jinja \
--temp 0.6 --top-p 0.95 --top-k 20 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--ctx-size 131072 \
--flash-attn on
vLLM：
vllm serve Qwen3.6-27B \
--chat-template /path/to/qwen3.6-enhanced.jinja \
--default-chat-template-kwargs '{"preserve_thinking": true}' \
--enable-prefix-caching
關鍵參數說明：
--jinja：啟用 Jinja template（Qwen 3.6 需要）--chat-template-file：指定修復後的 templatepreserve_thinking: true：保留思考過程跨輪--cache-type-k q8_0 --cache-type-v q8_0：高品質 KV cache--enable-prefix-caching：穩定 system prompt 的 KV cache（對 agent loop 至關重要）
🥈 Level 2：Sampling Parameters 調整
Qwen 官方提供的 sampling 參數是針對「思考模式」優化的。Agentic work 建議設定：
| 參數 | 推薦值 | 說明 |
|---|---|---|
temperature | 0.6 | 平衡創造力與一致性 |
top_p | 0.95 | 避免過低（太死板）或過高（不穩定） |
top_k | 20 | 限制候選詞範圍 |
min_p | 0.0 | 預設即可 |
repeat_penalty | 1.0 | 防止重複模式 |
presence_penalty | 1.5（可選） | 鼓勵探索新工具/動作 |
🥉 Level 3：Quantization 選擇
根據社群實測，推薦的 quant 順序：
| Quant 等級 | 推薦度 | VRAM 需求 | 備註 |
|---|---|---|---|
| Q8_K_XL（ Unsloth UD） | ⭐⭐⭐⭐⭐ | ~18 GB | 最穩定，agentic work 首選 |
| Q6_K（Bartowski/Unsloth） | ⭐⭐⭐⭐ | ~14 GB | 性價比最佳 |
| Q5_K_XL / Q5_K_S | ⭐⭐⭐⭐ | ~12 GB | 適合 VRAM 有限的場景 |
| Q4_K_XL（Unsloth UD） | ⭐⭐⭐ | ~10 GB | 可用但需要更多 tweaking |
| FP8（官方） | ⭐⭐⭐ | ~16 GB | 需搭配 prefix caching |
| FP4 / 低品質 MXFP4 | ⭐ | ~8 GB | Agentic work 不推薦 |
🏅 Level 4：MTP（Multi-Token Prediction）設定
如果你使用 MTP quantized 版本，draft token 數量需要微調：
--spec-type draft-mtp --spec-draft-n-max 6
多位使用者反映：--spec-draft-n-max 超過 6 之後速度開始下降，品質反而變差。 建議從 4-6 開始測試。
另外一個有趣的發現：有使用者報告 關閉 thinking（enable_thinking: false）+ MTP 的組合在某些場景下比開啟 thinking 更穩定——特別是當模型容易陷入過度思考循環時。這取決於你的具體工作負載。
🎖️ Level 5：Harness / Agent Framework 選擇
對於 27B 等級的模型，社群普遍建議使用輕量級 harness：
| Harness | 適合度 | 備註 |
|---|---|---|
| Pi Agent | ⭐⭐⭐⭐⭐ | 極簡工具集、context 控制精確 |
| Hermes Agent | ⭐⭐⭐⭐ | 對 Qwen 有良好支援，但需調整 system prompt |
| OpenCode | ⭐⭐⭐⭐ | 需要手動優化 template 和 tool parsing |
| Claude Code（via API） | ⭐⭐⭐ | 可跑長 context，但速度較慢 |
核心原則： 「任何程式碼能確定性處理的事，就不要問模型。」——一位使用 Qwen 35B-A3B MoE 的開發者總結道。用 GBNF grammar constrained（解碼時強制工具名稱和參數格式）、deterministic repair layer（執行前自動修正錯誤）、以及將大任務拆成小 context 的子 agent，可以大幅提升可靠性。
四、進階技巧：Prefix Caching 與 FP8
如果你使用 vLLM 並開啟 --enable-prefix-caching，會有一個隱藏的穩定性提升效果：
沒有 prefix caching 時，system prompt 的 KV cache 在每次請求時都會重新計算——由於 batching effects 和 kernel-level floating-point non-determinism，每次重算產生的 K/V tensor 會有微小差異。
開啟 prefix caching 後，system prompt 的 K/V tensor 被快取並重複使用，模型從完全相同的內部表示開始每一輪。這就是「stable」的真正含義。
FP8 quantization 在沒有 prefix caching 時會加劇這個問題（每次重算經過低精度運算，誤差累積），但開啟 caching 後 FP8 的 K/V tensor 被凍結，反而能獲得一致的表現。
五、27B vs 122B：到底該選哪個？
這是討論串中最激烈的爭議之一。讓我們客觀比較：
| 維度 | Qwen 3.6 27B | Qwen 3.5 122B-A10B |
|---|---|---|
| VRAM（Q8） | ~18 GB | ~62 GB |
| VRAM（Q4） | ~10 GB | ~30 GB |
| 硬體門檻 | RTX 3090/4090 即可 | 需 A100/H100 或 2x RTX 6000 |
| Agentic 可靠性 | 需要 tweaking | 更 resilient |
| Context rot | ~60K tokens 開始下降 | ~180K tokens 仍穩定 |
| 單次生成品質 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 多輪工具呼叫 | ⭐⭐⭐（需優化） | ⭐⭐⭐⭐⭐ |
結論： 如果你只有一張 consumer GPU（3090/4090），27B 是唯一選擇，但需要花時間調校。如果你有 A100/H100 或雙 RTX 6000，122B 在 agentic work 中的表現明顯更穩定、context rot 更少。
六、總結：一套立即可用的配置範例
以下是社群實測驗證過的一套完整配置（適用於 llama.cpp + Qwen 3.6 27B）：
./build/bin/llama-server \
-m unsloth/Qwen3.6-27B-MTP-GGUF:UD-Q8_K_XL \
--jinja \
--chat-template-file /path/to/qwen3.6-enhanced.jinja \
--host 0.0.0.0 --port 11434 \
--no-mmap \
--flash-attn on \
--cache-type-k q8_0 --cache-type-v q8_0 \
--ctx-size 131072 \
--spec-type draft-mtp --spec-draft-n-max 6 \
--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 \
--repeat-penalty 1.0 \
--reasoning-budget 8192 \
--presence-penalty 1.5
搭配 preserve_thinking=true（透過 chat template kwargs），這套配置已經能讓 Qwen 3.6 27B 在 agentic work 中穩定運行數百輪而不崩潰。
最後一句真心話： Qwen 3.6 27B 不是「不夠聰明」，而是它的參數量決定了它需要更精細的 harness 來吸收不確定性。把可靠性從模型本身移到模型周圍的工程架構上——這才是讓小模型在 agentic work 中發揮潛力的關鍵。
參考資源
- Qwen-Fixed-Chat-Templates — froggeric 修復的 chat template
- qwen3.6-enhanced.jinja — Allan Chan 處理 CoT leakage 的進階 template
- Qwen3.6-27B 官方 Blog — 阿里雲 Qwen 團隊的性能報告
- Unsloth MTP Guide — MTP quant 的官方參數指南
- Reddit: Follow up on Qwen3.6-27B Tool Calling Fix — preserve_thinking 深度解析
原文來源：r/LocalLLaMA - Qwen 3.6 27B absolutely fails at agentic work