摘要： Qwen Code 在6月11日發布v0.18.0-preview週更,以/fork背景任務、/skills管理面板與user層級跨專案記憶處理長任務阻塞、skill管理和換repo遺忘偏好。這些改動可讓長任務不阻塞主對話、可用能力可搜尋鎖定,但並行fork遇到同一組檔案仍要自行驗收,跨專案記憶路由偶爾會分錯類且須定期清理。同批Workflow tool屬實驗性opt-in,預設關閉。
主對話被長任務卡住、skills 多到沒人叫得出名字、換個 repo 偏好全部重來——coding agent 用上一陣子，這三種麻煩遲早會碰上。Qwen Code 這份 6 月 11 日發出的週更（v0.18.0-preview，合併 50+ 個 PR）把三個問題一次拆開處理：/fork 背景任務、/skills 管理面板與 user 層級跨專案記憶扛起主線，/stats 面板、防休眠與實驗性的 workflow tool 則列在同一批週邊。
/fork：長任務移往背景，context 原樣跟著走
下達 /fork <instruction> 之後，背景 agent 隨即開跑，而它繼承到的是你當下的完整工作狀態：system prompt、對話歷史、tools、model 設定與 prompt cache 一樣不缺——交到它手上的不是濃縮過的任務摘要，而是你此刻 context 的原件。主對話照常運作、不受阻塞；fork 收工時，background task panel 會跳出通知，成果另存成 JSONL transcript，事後都能翻查。
它和 /branch 的分工有必要講明白：branch 是把眼下的對話整份複製到新 session，用意是往另一個方向探索；fork 則是在原 session 裡派出背景 worker，適合承接「幫這個模組補測試」「先研究這個錯誤」這種能獨立驗收的子任務。prompt cache 一併繼承，代表 fork 不用從零暖機——背景任務以暖狀態起跑，這正是它能立刻接手背後的成本結構。fork 允許同時開多個，但會受 concurrency limits 管控；指令留空或缺設定時，系統回的是明確錯誤訊息，靜默失敗並不存在。
代價集中在檔案邊界。幾個 fork 若動到同一組檔案，省下來的等待時間可能整筆砸進解衝突。並行壓低的是等待成本，驗收紀律並沒有跟著鬆綁——每個 fork 的任務邊界與完成條件，照樣要在動手前想清楚。
/skills：不必再背名稱，換成可搜尋、可鎖定的面板
從前想用 skill，得先把名稱背起來；要停用，只能徒手改 settings.json。現在打開 /skills 就有 picker dialog：所有 skills 的名稱、描述與來源層級一覽無遺，鍵盤搜尋找得到目標，Space 鍵切換啟用與停用，Enter 則把指令帶進輸入框直接執行。
治理的細節落在 scope。停用狀態會寫入 workspace 層級的 skills.disabled 設定，而且當前 session 立刻生效：<available_skills> 清單與 slash completions 同步更新，不必重啟。若 skill 是在 user 層級被停用，workspace 面板會標上 [locked: User]，專案層級無從覆寫。對個人使用者，這是搜尋取代記名字；對團隊，這是以鎖定取代成文的規範文件——同一塊面板照顧兩種治理尺度，正是這個小功能值得留下紀錄的原因。
跨專案記憶：路由靠 prompt 決定，而非 hardcode
「換了 repo，agent 就把你忘光」——新增的 user 層級記憶目錄 ~/.qwen/memories/ 與專案層級 .qwen/memories/ 並行運作，針對的正是這個老毛病。設計核心在路由：判斷沿用既有四種 memory 分類，規則本身寫進 memory extraction agent 的 prompt、不做 hardcode——個人偏好屬 user 類，一律進 user 層級；deadlines、events 這類 project 類一律留在專案層級，過程零新增設定；夾在中間的兩類也各有預設走向：feedback 類預設歸 user 層級，除非內容是明確的專案慣例；reference 類預設留在專案層級，屬於全公司共用的資源才升上 user 層級。
兩層 scope index 都會渲染進 system prompt：user 層級排在前頭、扮演背景資訊，project 層級殿後、內容更具體，覆蓋順序自然由一般走向具體。就算 user 層級的 MEMORY.md 一片空白，系統仍會渲染 placeholder，讓 agent 清楚目錄存在而且寫得進東西。開關沿用既有的 memory.enableManagedAutoMemory，一樣不必額外安裝。
取捨同樣要攤開來講：路由交給 prompt 決定，終究不是 deterministic 規則，偶爾會分錯類；user 層級記憶經年累月會囤積過期偏好，值得定期安排人工檢視。不過「偏好跟著人走、專案資訊留在專案」這條界線畫得正確——個人風格能跨 repo 帶著走，repo 專屬資訊也不會滲進下一個工作區。遷移成本則是另一項務實之處：分類、開關與渲染機制全數沿用現成設計，升級完即可使用，沒有新的設定檔要學。
同批更新的其他亮點
/stats 換裝成三頁籤互動面板，用量資料在 session 結束與執行 /clear 時寫入 ~/.qwen/usage_record.jsonl——token、成本與 cache 命中率頭一回累積出可以回頭翻閱的縱深；對把 agent 當日常工具的團隊來說，這份紀錄把「用量」從模糊印象升級成可對帳的數據。防系統睡眠轉為預設開啟（general.preventSystemSleep: true），macOS、Linux、Windows 分別交給 caffeinate、systemd-inhibit、SetThreadExecutionState 落實——長任務跑到一半，電腦不會再自己睡著。Skills 宣告的 allowedTools 現在自動授權，執行 /review 這類 skill 時不會再被權限提示連環攔下。
實驗階段的 Workflow tool（P1）採 opt-in，預設關閉：
QWEN_CODE_ENABLE_WORKFLOWS=1把這個環境變數設好之後，model 就能在 node:vm sandbox 裡寫 JavaScript，將多個 subagents 編排起來。方向確實有看頭，只是官方自己都標明還在實驗階段，生產環境暫且觀望。
給 Builder 的行動清單
今天就能著手的三件事：能獨立驗收的子任務交給 /fork，需要你親自判斷的工作留在主對話；用 /skills 關掉用不到的 skill，讓 agent 的可用指令清單變短；挑任何一個 repo 教會 agent 你的偏好，下個專案由 user 層級記憶自動接手。記憶內容也該排進例行維護：每隔一陣子翻檢 ~/.qwen/memories/，清掉過期偏好，被誤路由的條目順手搬回正確位置。三個功能表面各自為政，指向的其實是同一件事：agent 的生產力瓶頸正從模型能力移往管理摩擦，時間（fork）、能力（skills）、上下文（memory）如今都各自有了對應的治理介面。