GitHub Copilot in VS Code 2026 年 8 月更新：/btw 與 Agent sessions 怎麼用
GitHub Copilot in VS Code 的 Agent 任務一旦跑超過幾分鐘，真正難追的通常不是模型有沒有回應，而是「這個問題問在哪個對話？」、「剛才的決定有沒有回到主任務？」以及「兩個 agent 會不會同時改同一個檔案？」
官方在 2026 年 8 月的更新總結涵蓋 VS Code v1.132 到 v1.135。其中最值得放進日常流程的，不是再多一個模型選項，而是讓 Agent sessions 更容易切分、查找、續接，以及用 /btw 暫時離開主線問一個不必打斷工作的問題。
這篇先把幾個名稱分清楚，再給一條可以直接套用的工作流程。若你也在比較不同 agent 如何隔離程式碼，可以接著看 Git worktree 與 AI coding agent 的隔離工作流。
這次更新先抓住三個使用情境
8 月更新的功能很多，但和長時間 coding 任務最直接相關的是三組：
| 情境 | 更新後可以怎麼做 | 解決的問題 |
|---|---|---|
| 主任務還在執行，突然想問細節 | 用 /btw 開側邊對話 | 不必把主對話改成解釋模式 |
| 任務需要拆成多條工作線 | 建立新 chat、fork，或另開 worktree session | 不再把所有需求塞在一條歷史裡 |
| 任務曾在其他工具啟動 | 用 External sessions 篩選並續接 | 找回最近的外部 agent 工作階段 |
此外，官方更新也加入 prompt timeline、對話內容搜尋，以及更多 Agent Plugins 和瀏覽器操作能力。這些功能的共同方向是讓「正在做什麼」更容易被回看；但它們不會自動替你決定哪一個 session 應該修改哪一批檔案。
/btw 適合問側題，不是另一個主執行緒
當主 Agent 正在分析測試失敗、掃描多個檔案，或等待一個長任務完成時，可以在 Agents window 輸入：
/btw 這個錯誤最可能代表哪一層的責任？請只列出判斷方向，不要修改檔案。官方說明中，/btw 會繼承主對話最近一輪的脈絡與 prompt cache，讓側邊問題可以快速取得背景；它的定位是 explanation-first 的側題對話。適合的問題包括：
- 請主 agent 解釋某段 diff 的風險，但不想讓主線停下來。
- 想確認一個 API 或設定選項的語意，再決定要不要把答案帶回主任務。
- 需要整理測試失敗的假設，卻不想把除錯方向直接混進主 prompt。
要留意兩個邊界。第一，官方文件目前把 /btw 限定在 Copilot 與 Claude 的 Agents window；它不適用於 Codex session，也不適用於一般 Chat view。第二，側邊對話的回答不應被當成已經套用到主任務的變更；確認答案後，仍要把決策明確地寫回主 chat，或手動修改需求。
新 chat、fork 與 worktree session 怎麼選
這三個選項看起來都像「開一條新的對話」，但保留的東西不同：
| 選項 | 會保留什麼 | 適合什麼時候用 | 主要風險 |
|---|---|---|---|
| New chat | 同一個 workspace 或 worktree，但不帶原 chat 歷史 | 另一個獨立問題，不需要前一條推理 | 你以為它知道前情，其實必須重新交代 |
| Fork | 原對話歷史的分支 | 想沿用上下文，卻要探索另一個解法 | 兩條分支的決策可能被混在一起 |
| Worktree-isolated session | 獨立 worktree 與自己的檔案狀態 | 平行任務可能改到相同檔案 | 合併前仍要處理 diff 與衝突 |
簡單判斷方式是：只想換問題，用 new chat；想保留推理，用 fork；想讓檔案變更互不干擾，用 worktree。 新 chat 和原 chat 仍可能共享同一個 workspace，因此「對話分開」不等於「檔案隔離」。
如果兩個 session 會改同一個 src/ 元件、同一份 migration 或同一個設定檔，直接在同一個 worktree 平行執行，衝突只是延後到最後才出現。此時先建立 worktree-isolated session，再讓每條工作線有明確的驗證與合併條件。
External sessions：先調整篩選，再找回工作
VS Code 的 Agent sessions 可以發現並續接部分外部工具建立的 local session，文件列出的來源包括 Copilot CLI、GitHub Copilot app、Claude Code 與 Codex。這對「昨天在終端機啟動、今天想回到編輯器繼續」的情況很有用。
外部工作階段預設不一定會出現在清單裡。開啟 Agent sessions 後，先使用 External 篩選，依需求選擇最近一天、最近七天或全部；Copilot 的外部工作階段還會受 repository 關聯與最近更新時間影響。找到目標後再送出訊息，VS Code 才會把它接回目前的工作流程。
找 session 時建議保留三個辨識資訊：
- 它是在哪個 repository 或 worktree 啟動的。
- 最後一輪任務的目標與未完成條件。
- 它是否已經修改檔案，或只是停在分析階段。
不要只用「最新的一個」判斷。多個 agent 可能同時處理同一個 repository；先看工作樹、分支與最後一輪摘要，再決定要續接、fork，或重新開一個乾淨 session。
一條可重複的 Agent session 流程
可以把一次較長的 coding 任務拆成以下順序：
- 先開主 session：只放一個可驗收的目標，例如「找出測試失敗原因並提出最小修正」。
- 用
/btw問側題：要求解釋、比較方案或整理風險，並明確寫上「不要修改檔案」。 - 把決策帶回主線：確認側題答案後，在主 chat 寫出要採用的方案與不做的方案。
- 需要新方向時再切分：無須前情就開 new chat；需要前情就 fork。
- 可能碰到同一檔案時隔離：改用 worktree-isolated session，並在任務描述中列出禁止觸碰的路徑。
- 離開後用 External 篩選找回：先核對 repository、worktree 和最後狀態，再續接工作。
這個流程的重點是讓「上下文保留」與「檔案隔離」成為兩個獨立決策。對話歷史越長，不代表 agent 就越知道目前哪個檔案是唯一真相；每次續接都應重新確認 git diff、測試結果與工作目錄。
結論：讓 session 邊界對應工作邊界
/btw 解決的是主任務中的即時側問，new chat 和 fork 解決的是對話上下文的切分，worktree session 解決的是檔案狀態的隔離，External sessions 則解決的是跨工具找回工作。把四者混成同一個「開新對話」按鈕，才容易在長任務中迷路。
實務上可以先用 /btw 保持主線專注；當需求真的分叉，再根據是否要保留歷史、是否會改同一批檔案，分別選 fork 或 worktree。最後以實際 diff、測試與 session 所在的 worktree 驗收，不要只看對話視窗還能不能繼續輸入。
常見問題
Q: /btw 會把回答自動套用到主 Agent 嗎？
A: 不要這樣假設。它是共用主脈絡的側邊對話，適合快速解釋與比較；要改變主任務方向，請把確認後的決策明確寫回主 chat，並檢查實際 diff。
Q: 開新 chat 後，原本的 prompt 歷史還在嗎？
A: 一般 new chat 不會繼承原 chat 歷史。若需要保留上下文，使用 fork；若只是同一 workspace 中的另一個獨立問題，才適合開新 chat。
Q: 兩個 Agent session 可以同時改同一個專案嗎？
A: 可以同時執行，但不能把它當成檔案隔離。若兩個任務可能碰到相同路徑，先使用 worktree-isolated session，完成後再逐一檢查 diff 與合併衝突。
參考資料：
GitHub Changelog：GitHub Copilot in VS Code, August 2026 releases
回報錯字、失效連結，或告訴我你想看的延伸主題。