GitHub Copilot 的 Stacked Sessions：從輔助工具到 Agentic 的關鍵一步

> Meta Shift

---

這個更新在解決什麼問題

如果你用過 GitHub Copilot Chat，應該有感覺到一個痛點：你只能跟它在同一個對話裡來回，一次只能處理一件事，做完再做下一件。這跟人類工程師的實際工作方式差很多 — 我同時可能在改一個 bug、等 CI 跑、順手看一個 PR，多線並行是基本款。

Copilot 的新功能 stacked sessions 就是在打這個痛點：讓 AI agent 可以同時跑多個 session，背景執行不同任務，你可以隨時切換查看進度。加上新的 pull request 整合，agent 做完事之後可以直接幫你開 PR，整個流程從「AI 幫你寫程式」推進到「AI 幫你完成任務」。

這個方向轉得很明確，我覺得值得拆開來看看。

---

架構概覽：Copilot 的 Agentic Loop 長什麼樣

要理解 stacked sessions，先要理解 Copilot 現在的 agent 架構是怎麼跑的。

傳統的 Copilot Chat 是一個典型的 request-response 模式：你問、它答、你問、它答，stateless，每次對話之間幾乎沒有連貫的任務狀態。即使有 context window，本質上還是人在主導節奏。

新的 agentic 架構長這樣：

使用者 → Copilot App（orchestrator）
              ↓
         Task Queue（多個 session 並行）
              ↓
    ┌─────────────────────────┐
    │  Session A（修 bug）     │
    │  Session B（寫 feature） │
    │  Session C（寫測試）     │
    └─────────────────────────┘
              ↓
      每個 session 有自己的：
      - 工具呼叫（file edit、terminal、search）
      - 狀態追蹤（in progress / waiting / done）
      - 結果輸出（code diff / PR）
              ↓
    直接開 Pull Request 到 repo

核心元件有幾個：

Session Manager：負責管理多個 session 的生命週期，讓每個任務在獨立的 context 裡跑，不互相干擾。這個設計讓 Copilot 可以背景執行任務，不需要使用者一直盯著。

Tool Use Layer：Copilot Agent 可以呼叫的工具集 — 讀寫檔案、執行 terminal 指令、搜尋 codebase、呼叫 GitHub API。這是讓它從「說說而已」變成「真的能幹活」的關鍵。

PR Integration：任務完成後直接透過 GitHub API 開 PR，包含 diff、commit message、description，讓人類工程師做最後的 review。這個設計保留了人在 loop 裡，沒有直接 merge，算是 responsible AI 的基本姿態。

資料流的關鍵在於每個 session 是獨立的 — 這跟你在同一個 chat window 裡開不同話題是完全不一樣的概念。獨立 session 代表 context 不會互相污染，A 任務的程式碼討論不會影響 B 任務的決策。

---

核心機制深入：三個關鍵設計決策

1. Session 並行 vs. 單執行緒

最直觀的問題：為什麼要做 stacked sessions，而不是讓一個 agent 一次把所有事做完？

原因在於 context limit 和任務複雜度的 trade-off。一個 LLM 的 context window 雖然現在已經很大（GPT-4o 是 128k tokens，Gemini 1.5 Pro 最高到 1M tokens），但當你把整個 codebase 塞進去、加上對話歷史、加上工具呼叫結果，context 很快就會爆。

更實際的問題是：任務之間可能有依賴，也可能完全獨立。與其讓一個超大的 agent 試圖同時管所有事，不如切成多個小的、focused 的 session，每個只負責一個清楚定義的任務。這是 microservices 思維應用在 AI agent 上。

trade-off 是協調成本。如果 Session A 的輸出是 Session B 的 input，你就需要某種 orchestration 機制來保證順序。目前 Copilot 的設計看起來傾向讓任務盡量獨立，不太支持複雜的 DAG 依賴關係 — 這是現在的限制，但也讓設計簡單很多。

2. PR-first 的任務完成定義

Copilot Agent 把「任務完成」定義為「開了一個 PR」，這個設計選擇很有意思。

它對齊了工程師的實際工作流程 — 在有 code review 文化的團隊，任何改動都應該走 PR。讓 AI 直接輸出 PR，代表它的輸出物跟人類工程師的輸出物是同一種格式，可以用同樣的流程去審查。

這也是一個很聰明的責任邊界設定。AI 做到 PR，人來 review 和 merge，這條線劃清楚了。如果 AI 直接 merge，出了問題誰負責？現在的設計把最後決策權留給人，降低了組織採用的心理障礙。

跟 Cursor 和 Windsurf 比：這兩個工具的核心體驗是在 IDE 裡直接改 code，沒有原生的 PR 工作流整合。Copilot 利用 GitHub 本身的平台優勢，把 PR 整合做成一等公民，這是它們目前很難複製的護城河。

3. 背景執行的 UX 設計

Stacked sessions 的另一個關鍵設計是背景執行：你可以丟一個任務給 Copilot，然後去做別的事，等它完成再回來看結果。

這聽起來很簡單，但背後要解決的問題不少：

• 狀態追蹤：使用者需要知道每個 session 現在在幹嘛、有沒有卡住、需不需要額外輸入
• 中斷與繼續：如果任務到一半發現走錯方向，要能夠介入糾正
• 錯誤處理：agent 遇到它不確定的情況，是自己猜、還是停下來問人？

目前 Copilot 的設計傾向讓 agent 在不確定的時候暫停並問人，而不是自己硬幹。這個決策保守但安全 — 在工程師還沒建立對 AI agent 信任的階段，這樣做是對的。

---

商業背景：GitHub 在 AI 編輯器大戰裡的位置

這個更新放在市場競爭的脈絡裡看，意圖非常清楚。

Cursor 在 2024 年底據報導 ARR 達到 1 億美金，Windsurf（前身 Codeium）也在快速成長，這些 AI-native IDE 正在搶食傳統開發者工具市場。它們的核心主張是：把 AI 深度整合進 IDE 體驗，讓寫 code 的每一步都有 AI 參與。

GitHub Copilot 的困境在於它是一個 plugin/extension 形式的產品，依附在 VS Code、JetBrains 這些宿主 IDE 上，體驗上天然受限。它沒辦法像 Cursor 那樣完全控制整個編輯器體驗。

所以 GitHub 的策略轉向很明確：不跟你比 IDE 體驗，比 platform 整合深度。GitHub 有 Issues、PRs、Actions、Packages 整個 DevOps 生態，這是 Cursor 和 Windsurf 沒有的。把 Copilot Agent 跟這些 GitHub platform 功能深度整合，做出競爭對手難以複製的差異化。

Stacked sessions + PR 整合就是這個策略的具體落地。你可以在 GitHub.com 上直接跑 Copilot Agent，不需要打開 IDE，agent 完成任務後直接產出 PR — 這個體驗是 GitHub 平台獨有的，Cursor 再怎麼強也做不到。

從投資者角度看，Microsoft 在 GitHub 上的策略是對的：與其在 IDE 這個戰場硬拚，不如強化 platform 壁壘。GitHub 的護城河不是編輯器，是全球最大的程式碼托管平台和開發者社群，這個資產用得好，長期競爭力遠比一個好用的 IDE 強。

目前 GitHub Copilot 的訂閱用戶數 Microsoft 沒有公開詳細數字，但 GitHub CEO Thomas Dohmke 在公開場合提過 Copilot 已經是 GitHub 最快速成長的產品線（來源：GitHub Blog）。

---

Meta 判讀：這是 Meta Shift，不是小 Patch

我把這個更新分類為 Meta Shift，理由是它改變的不是功能集，而是產品定位。

Copilot 從「你在寫 code，我在旁邊給建議」變成「你說一個目標，我去完成任務，結果放在 PR 等你 review」。這個轉變改變了人和 AI 在開發流程裡的角色分配。

類比電競的話：這相當於從「輔助位」升格成「有獨立操作能力的 carry」。以前 Copilot 是補刀輔助，現在它要嘗試自己拿人頭了。

但現在的 agentic AI 還沒到可以完全信任的階段 — agent 在複雜任務上的成功率、對 codebase 的理解深度，都還有很大的進步空間。Stacked sessions 和 PR 整合是對的方向，但真正的 Meta Shift 要等到 agent 的可靠性提升一個數量級才會完全發生。現在算是 早期 Meta Shift — 方向確立了，但還在 patch 細節。

對整個 AI coding assistant 市場來說，這個更新也是一個信號：agentic 是接下來一到兩年的主戰場，誰先把 agent 的可靠性和工作流整合做好，誰就拿到下一輪的市場份額。

---

實戰建議：什麼時候用、什麼時候別用

適合用 Copilot Agent + Stacked Sessions 的場景：

• 任務定義清楚的 routine work：寫測試、改 lint error、更新文件、重構某個 function 的簽名。這類任務邊界清楚，agent 出錯的代價低，review 也容易。
• 並行的獨立任務：同時要修三個不相關的 bug？丟三個 session 讓它跑，你去喝咖啡。
• 熟悉 GitHub 工作流的團隊：PR-based 的 code review 文化如果本來就在，Copilot 的輸出物直接可以接進現有流程。

不適合的場景：

• 架構設計和高層次決策：讓 agent 決定你的 API 要怎麼設計、資料庫 schema 要怎麼建，這類任務太模糊，agent 很容易走歪。
• 強依賴的複雜任務鏈：如果 Task B 要等 Task A 的結果才能開始，而且邏輯複雜，現在的 stacked sessions 不太能優雅處理。
• 對 codebase 理解要求很高的改動：agent 對大型 legacy codebase 的理解還是有限，不要期望它能在一個有 10 年歷史的 monorepo 裡做出聰明的跨模組改動。

一個要注意的坑：PR 整合雖然方便，但要記得 review 不能走馬看花。agent 產出的 PR diff 可能看起來沒問題，但背後的邏輯有 edge case 沒考慮到。把 AI 的 PR 當成 junior 工程師的 PR 來 review，保持同樣的嚴謹度。

---

整體來說，這個更新是 GitHub 在對的方向走了一步。Stacked sessions 解決了真實的工作流痛點，PR 整合把平台優勢用上了。至於這步走得夠不夠快，在 Cursor 和 Windsurf 的競爭壓力下能不能守住市場，就不得而知了。

延伸閱讀

• Meta 也來搶 AI coding 市場了 — Muse Spark 1.1 有機會嗎
• AI Agent 跑到一半沒 token 了 — token budget 問題沒人在講，但很重要
• Coding Agent 正在改變工程、產品、設計的協作方式 — 但改變的不是你想的那個