摘要： Qwen Code在2026年7月9日發出v0.19.6到v0.19.8週更,合併超過150個PR,重點包含opt-in model fallback與預設五層的巢狀subagent。fallback只由容量或限流類錯誤觸發,認證、配額、設定與client端錯誤會立即失敗,且只在尚無可見輸出時推進;巢狀則以schema和runtime雙層防止超深遞迴。這些設計把長時間agent的可用性與可除錯性分開處理,對進入正式環境的團隊特別重要。
Qwen Code 在 2026 年 7 月 9 日發出當週週報，v0.19.6 到 v0.19.8 三個 stable release 一次到位，併入的 PR 超過 150 個。項目從 model fallback、巢狀 subagent、session 管理、WeCom 通道一路排到權限控制，主軸卻始終如一：讓需要長時間運作的 agent 在真實環境中撐得更久。已經讓 agent 進入日常生產流程的團隊，會覺得這批改動比再添幾個平行 worker 更搔到癢處。
Model fallback 的取捨：該吞下哪些錯誤、該攤開哪些
對 coding agent 而言，真正難受的斷點不是模型給出錯誤答案，而是長任務跑到一半冒出 429、503 或 529。自己動手換模型、重送一次，節奏被打斷之外，累積到一半的 context 也可能不保。這次新增的 model fallback 走 opt-in 的鏈狀設計：primary 模型把 retry budget 耗盡之後，就自動交棒給鏈上的下一個模型。
觸發條件才是這項設計真正的判斷所在。切換只會被 capacity 與 rate limiting 一類的錯誤觸發；authentication、quota、configuration 與 client 端錯誤則一概馬上失敗。這條界線值得多看一眼：「暫時沒有容量」可以靠換模型救回來，壞掉的憑證或寫錯的設定卻不行。若連後者都被掩蓋，能修的配置問題就被包裝成了模型問題，往後除錯只會更加費力。暫時性故障交給 fail-over，確定性錯誤交給 fail-fast——一條線畫在何處，就分出了 fallback 系統的可信與自欺。
從兩個細節看得出團隊把後果想過一輪。其一，fallback 的推進只發生在還沒有任何可見輸出的時候；萬一 fallback 模型已經串流出部分內容才失敗，系統就此打住、不會再往下一個試——免得幾個模型各寫一半的回答被縫成一份拼裝貨。下一個 user turn 一律回到 primary 從頭開始，任務不會被丟在次選模型身上。其二，設定落地靠 scope flags 劃清界線：/model --project 寫進專案的 .qwen/settings.json，--global 寫 ~/.qwen/settings.json，--fast、--voice、--vision 也吃同一組 flags。fallback 鏈於是能按專案各自隔離——哪個 repo 配得上貴模型、哪個 repo 該鎖在便宜模型上，成本不再被迫全機器一體適用。維運上的含義同樣直白：先在測試 repo 調好整條鏈，production repo 的行為就不會被另一個專案不小心動到。
巢狀 subagent：深度上限與治理設計
Subagent 現在能夠再派出自己的 subagent，深度預設 5 層，想調整就改 model.maxSubagentDepth，改回 1 即可恢復原本的行為。這個深度可不是擺著好看的：TUI 與 Web Shell 會把巢狀關係畫成樹狀結構，縮排處以 ↳ 標示；parent 結束退出之後，children 隨之升格為 root，並掛上 from <parent> 註明出身。
雙層保護負責防堵失控，兩層的思路並不相同：在 schema 階段，最深的 agent 壓根見不到 agent tool——它無從得知自己還有再生的能力；到了 runtime 階段，超出深度的 spawn 請求會當場遭到拒絕。一層讓它看不見，一層讓它被擋下，指數型的擴張就這樣被雙重機制按在治理範圍裡。
適用邊界同樣畫得清楚：巢狀預設就是開啟的；Fork subprocesses、teammates 與 workflow agents 不在巢狀適用之列；Arena sessions 允許巢狀；background agent 恢復時，深度與上限會一併還原。多數程式任務交辦個一兩層就夠了——一旦你察覺需要更深的樹，該先回頭檢查的是任務定義會不會太含糊，而非急著抬高上限。這正呼應治理設計的通則：上限真正的價值，不是擋下合理的需求，而是讓不合理的結構提早現形。
Session 與權限：功能列表長成了工作系統
Web Shell 的 session 管理這次一口氣納入 7 個 PR：封存與刪除、具名群組、顏色標籤、排程任務頁，還有分割畫面。內建規則處處是保護設計：active session 不允許被封存或刪除；已封存的 session 再也開不了，回應 409 session_archived；刪除走的是需要確認的 hard delete。Overview 卡片按 approvals needed、running、idle 的優先順位排列，想組多面板視圖，?split=a,b 這個 URL 參數就夠。對經營長期的專案來說，session 從一張平面清單變成可以整理的資源，「找回上週的上下文」就此從搜尋問題轉為瀏覽問題。
權限這邊補齊了兩塊。PreToolUse hook 的 ask 判定以前形同 deny，如今會貨真價實地跳出一個原生確認框——選項是 allow once 或 suggest changes，always allow 被刻意排除；非互動與 background 場景照舊回退成 deny。權限規則另外多出 Tool(param:value) 這種參數級語法，能把攔截範圍縮到特定參數的工具呼叫，例如擋下指向特定模型的 spawn。
其餘更新與修正項
WeCom 通道的接入門檻如今只剩兩個欄位：Bot ID 與 Secret，設定內容寫成 {"type":"wecom","botId":...,"secret":...}，再以 qwen channel start my-wecom 啟動。WebSocket 長連線收得到文字、語音與檔案，回覆採用 WeCom markdown；outbound 只支援本地 image markers。自動生成的 skills 這回有了 review dialog：內容先經 sanitize、讀取上限 64 KiB、顯示上限 12 行，按下 o 就能在 editor 裡直接編。修正方面，context window 預設值已更正為 200k，401 錯誤也不再 hang；升級只要一行：npm i @qwen-code/qwen-code@latest -g。
真正該記住的三個判斷
這批更新真正該帶走的不是功能清單，而是三個判斷。第一，fallback 只吞下暫時性故障、讓確定性錯誤當場現形，這是可用性與可除錯性之間的平衡點，任何自己打造的 agent 系統都用得上。第二，巢狀 subagent 以「看不見」搭配「被拒絕」組成雙層治理，把分工的彈性圈在可控範圍之內。第三，session 與權限被升格為正式功能，意味著 agent 正由實驗工具轉變成能長期營運的工作系統。可靠性向來不是最亮眼的賣點，卻握有決定 agent 能否進 production 的那一票。