GitHub Copilot App 平行 Agent 教學：Worktree 是什麼？怎麼同時跑多個開發任務

GitHub 官方帳號在 2026 年 9 月 28 日再次介紹 Copilot app 的平行 Agent 功能：同一個專案可以同時開多個 session，每個 session 保有自己的工作區與脈絡，分別處理開發、測試或檢查工作。

這項功能最吸引人的地方，是不用等第一個 Agent 做完，才開始第二件事。不過，「同時執行」不等於「自動協作」。Git worktree 能避免多個 Agent 直接覆蓋同一份工作目錄，卻不會替你解決需求衝突、測試失敗、重複實作與最後的程式審查。

我的判斷是中性偏多。已經會拆任務、看 diff 並執行測試的開發者，值得用兩個低風險任務試跑。如果需求仍然模糊，或多個任務都會修改同一組核心檔案，平行化只會讓問題更快堆積。

本文會解釋 worktree 如何隔離 Agent、三種 session mode 怎麼選、哪些工作適合平行，以及新手如何用一個小型實驗判斷它是否真的省時間。

GitHub Copilot app 的平行 Agent 到底怎麼運作？

GitHub Copilot app 是一款獨立桌面應用程式，把多個 AI 開發工作流、GitHub issue、pull request（PR，提交給團隊審查與合併的程式變更）、持續整合檢查與 review 集中在同一個介面。官方文件列出的支援系統包括 macOS、Linux 與 Windows，並表示所有 Copilot 方案都能使用。公司或學校帳號仍可能受組織管理員政策限制。

在 app 裡，一個 session 可以理解成一項從開始到完成的工作。你可以讓第一個 session 加入篩選功能，第二個 session 做無障礙檢查，第三個 session 執行測試。每張 session 卡片都有自己的對話、任務狀態與工作區，可以各自選擇模型、推理強度與執行模式。

這與在同一個聊天視窗連續丟三個要求不同。獨立 session 會把不相干的對話脈絡分開，Agent 不必在每次切換任務時重新理解你正在做什麼，也比較不會把 A 功能的假設帶進 B 功能。

Git worktree 是什麼？為什麼能減少 Agent 互踩？

一般 Git 專案通常只有一個工作目錄。切換分支前，如果目前還有未完成的修改，你可能得先提交、暫存或放棄變更。當兩個 Agent 同時操作同一個目錄，更容易彼此覆蓋檔案，或讓其中一個 Agent 讀到另一個 Agent 尚未完成的程式。

Git worktree 可以讓同一個 repository，也就是同一份程式版本庫，同時擁有多個工作目錄。每個 worktree 綁定自己的 branch，Agent A 修改功能分支時，Agent B 可以在另一個目錄執行檢查，不必反覆切換分支或複製整份 repository。

GitHub Copilot app 會替 session 管理這些工作區。官方操作文件顯示，建立 session 時可以選擇 new working tree、local repository 或 cloud sandbox。若目標是讓多個 Agent 同時改程式，new working tree 才是最容易保持隔離的選項。直接使用 local repository，仍可能碰到你手上的未提交變更。

這層隔離的真正價值，是讓多個工作流不會在檔案層面直接踩在一起。它不是自動合併器。兩個 branch 若都改到相同邏輯，最後仍可能發生 merge conflict，或出現檔案能合併、行為卻互相矛盾的情況。

三種 session mode 怎麼選？Interactive、Plan、Autopilot 差在哪？

GitHub Copilot app 目前提供三種 session mode。它們控制的是 Agent 能自主前進到什麼程度，不代表程式品質的高低。

我的選擇順序會從風險開始，而不是從速度開始。需求還有不確定性時，用 Plan 先確認範圍。需要邊看結果邊判斷時，用 Interactive。只有完成條件明確、錯誤容易復原，而且已有自動測試時，才把工作交給 Autopilot。

Quick Chat 則是另一種用途。官方文件說明，它適合腦力激盪、詢問程式架構或探索方案，不會建立專用 branch 或 worktree。只想問問題時用 Quick Chat，比為每個疑問都開一個正式 session 更省管理成本。

哪些任務適合平行？哪些會讓衝突更嚴重？

平行 Agent 最適合「輸入與驗收清楚，而且彼此低重疊」的工作。等待時間能被真正重疊，最後也容易分別檢查成果。

不適合平行的任務，通常不是技術太難，而是彼此相依太深。例如兩個 Agent 同時重構同一個資料模型、一起修改登入權限，或在需求尚未定案時分頭建立前後端。即使 worktree 沒有檔案衝突，最後也可能產生不同命名、不同資料結構與互不相容的假設。

判斷方法很簡單：如果第二項工作必須持續等待第一項工作的最新決定，它們就不是真正能平行的任務。先把共同介面、資料格式與驗收條件定好，再分開執行，通常比同時開更多 session 更有效。

新手怎麼開始？先用兩個低風險任務測試

GitHub 官方 beginner guide 建議先同時開兩個小任務。我會把第一次實驗再縮得更具體，避免一開始就把整個功能拆給多個 Agent。

1. 選一個已有測試、能在半天內完成的小型 repository。
2. 第一個 session 選 new working tree，請 Agent 補一個低風險功能，例如新增排序選項。
3. 第二個 session 也使用獨立 working tree，請 Agent 只做測試補強或無障礙檢查。
4. 在 Prompt 中寫清楚允許修改的目錄、不可碰的檔案、完成條件與必跑指令。
5. 兩邊完成後，分別查看 diff、測試結果與 Agent 的工作摘要，再決定是否建立 PR。
6. 一次只合併一個 branch，合併後重新跑完整受影響測試，再處理下一個。

第一次測試不要只記錄「Agent 花了幾分鐘」。也要記錄你花多少時間說明需求、修正方向、review 程式、處理衝突與重跑測試。平行化若只是把等待時間換成更長的審查時間，總交付速度並沒有真的改善。

Worktree 能隔離檔案，但不能替你解決 4 個風險

1. 需求與架構衝突

Worktree 只能讓檔案修改分開。兩個 Agent 仍可能對同一個產品需求做出不同解讀，或各自建立一套相似元件。開始前要先鎖定共同介面、資料格式、不得修改的範圍與驗收標準。

2. 成本同時增加

多個 session 會同時使用模型、工具與運算資源。等待時間可能縮短，但 AI credits、API 費用與 cloud sandbox 資源不會因此免費。應該比較每一個「通過驗收的成果」花多少總成本，而不是只看 Agent 的執行速度。

3. Review 變成新瓶頸

GitHub Copilot app 會集中顯示變更、PR、CI 與 review 狀態，方便人員檢查，但它不會替合併結果背書。當三個 Agent 同時完成工作，開發者也會同時收到三份 diff。若團隊沒有優先順序與 review 上限，排隊位置只是從寫程式移到審查。

4. 權限與資料風險

官方文件區分 working tree、local repository、local sandbox 與 cloud sandbox。Sandbox 是限制 Agent 執行環境、檔案、網路與憑證存取的隔離區。Cloud 與 local sandbox 目前仍標示為 public preview，功能可能變動。

如果 session 能使用 MCP server、外部工具、部署憑證或公司內部資料，就要逐一限制可用權限。使用自備模型金鑰時，Prompt、程式脈絡與回覆會直接送到所選模型供應商，資料處理政策也必須另外審查。

GitHub Copilot 平行 Agent 值得用嗎？

對已經能把工作拆成獨立變更、並有自動測試與 review 規則的個人開發者或小團隊，我認為值得試。Copilot app 把 worktree、session context、GitHub issue、PR 與 CI 放在同一個介面，確實能降低手動建立工作區與反覆切換工具的摩擦。

但它不會讓所有開發工作自動變快。真正決定成果的仍是任務能否獨立、完成條件能否測量，以及團隊是否有能力吸收同時產生的多份變更。若每個 session 都需要你頻繁救火，增加 Agent 數量只是在放大管理成本。

最實際的判斷方式，是挑 5 至 10 個真實小任務，比較導入前後的總交付時間、人工 review 時間、重工次數、CI 失敗率與 AI credits。只有等待時間下降，且後面四項沒有明顯惡化，平行 Agent 才算真的提高生產力。

GitHub Copilot App 平行 Agent 常見問題

GitHub Copilot app 跟 GitHub Desktop 一樣嗎？

不一樣。GitHub Desktop 主要管理 repository、branch、commit 與 pull request。GitHub Copilot app 則以 Agent session 為核心，讓使用者分派任務、選擇模型與模式、檢查變更並追蹤 PR 流程。兩者都會使用 Git，但工作重點不同。

每個 session 都一定會建立 Git worktree 嗎？

不一定。官方操作頁顯示，建立 session 時可以選 new working tree、local repository 或 cloud sandbox。若要同時讓多個 Agent 修改同一個專案，選擇獨立 working tree 比直接共用 local repository 更容易保持隔離。

Worktree 能完全避免 merge conflict 嗎？

不能。它可以避免 Agent 同時直接改到同一個工作目錄，但兩個 branch 若修改相同程式，合併時仍可能出現衝突。即使 Git 能自動合併，也仍要檢查兩份變更在行為上是否相容。

平行 Agent 一定比單一 Agent 快嗎？

只有能獨立執行的工作，才容易縮短等待時間。若任務彼此高度依賴，或最後需要大量人工整合，平行執行可能增加總工時與模型成本。

新手應該直接使用 Autopilot 嗎？

不建議從高風險任務開始。先用 Plan 確認做法，或用 Interactive 觀察 Agent 怎麼修改。等完成條件、測試與復原方式都很明確，再把低風險工作交給 Autopilot。

結語：先證明兩個 Agent 能合作，再考慮擴大

GitHub Copilot app 把平行 Agent 從手動管理多個終端機與 worktree，整理成較容易操作的桌面工作流。它的價值不在畫面同時跑多少機器人，而在每項工作都能保有獨立 branch、工作區與 context，再把結果帶回 GitHub 的 PR 與 CI 流程。

對新手來說，先讓兩個 session 分別處理低重疊、可驗證的任務，比一次開五個 Agent 更合理。當你能穩定判斷哪個成果可以合併、哪個應該退回，而且總交付時間確實下降，再逐步增加平行工作數量。

資料來源

• GitHub 官方 X：在 Copilot app 同時執行多個 agents
• GitHub Blog：Run several agents at once
• GitHub Docs：About the GitHub Copilot app
• GitHub Docs：Working with agent sessions
• GitHub Docs：Responsible use of GitHub Copilot Agents