VS Code Agent Merge 公開預覽：PR 工作流解析

快速解答

Microsoft 於 2026 年 9 月 2 日發布 Visual Studio Code 1.136，其中最值得關注的 AI 工作流更新之一，是進入公開預覽的 Agent Merge。

Agent Merge 的定位不是再多一個「幫你寫程式」功能，而是接手第一版程式碼完成之後最容易拖慢團隊的那一段流程：處理 Pull Request 審查意見、修復失敗檢查、解決合併衝突、重新執行工作流，直到 PR 接近可合併狀態。

GitHub 又在 9 月 4 日的 Copilot 每週更新中再次強調 Agent Merge，並把它和 VS Code 的 Agent session 管理能力放在同一組更新裡。

TowCue 認為真正值得關注的，不是「AI 可以自己合併程式碼」，而是 AI 自動化的邊界正在從產生程式碼向更複雜的PR 完成循環延伸。

這有機會減少大量重複性工作，但也帶來一個更重要的問題：哪些錯誤可以交給 Agent 自動修，哪些情況仍必須由人來判斷？

如果你正在建立 Agent 工作流，可以搭配 TowCue 的 AI Agent 最佳實踐指南、工作用 AI 工具選擇指南，以及 GitHub Copilot 模型淘汰檢查清單一起閱讀。

Agent Merge 實際可以做什麼？

VS Code 將 Agent Merge 描述為一個把 Pull Request「推過終點線」的循環。

啟用後，Agent 可以持續處理：

PR review feedback
失敗的 CI / checks
merge conflicts
重新執行 workflows
在修復後再次檢查，直到 PR 達到可合併條件

目前此功能仍是預覽狀態，透過 chat.agentMerge.enabled 設定開啟，並可從 VS Code 的 Agents 視窗為特定 session 啟用。

這個差異很重要。Agent Merge 不只是 autocomplete、inline edit，也不是一次性的 coding agent。它開始進入程式碼已經提交到 review 與 CI 系統之後的流程。

為什麼這比多一個 Coding Benchmark 更值得關注？

大部分 AI 編程展示都集中在軟體交付的前半段：寫功能、修 Bug、產生 patch。

但真實團隊裡，第一版程式碼完成後仍有大量工作：

reviewer 要求修改
測試失敗
lint 或 typecheck 阻擋 build
branch 與 main 發生偏移
出現 merge conflict
CI 重新執行
又進入下一輪 review

每一步本身可能只需要幾分鐘，但它們會造成大量 context switching。

Agent Merge 嘗試自動處理這個重複循環。因此它真正可能節省的，不一定是「寫程式的時間」，而是把一個方向已經確認的 PR 推到可合併狀態時，需要多少次人工介入。

這是一個不同的生產力指標。

哪些工作最適合先交給 Agent Merge？

明確、重複性的審查意見

當 reviewer 的要求非常清楚時，Agent Merge 最有機會發揮價值，例如：

重新命名不清楚的變數
補一個缺少的 test
修正 error handling
收窄 type
修正 formatting / lint
同步更新文件

這類工作的「意圖」已經確定，主要成本只是執行。

原因清楚的 CI failure

如果失敗原因可以從 log 中明確看到，而且可以重現，例如 type error、測試 regression、lint 問題或明確的依賴錯誤，Agent 很適合先嘗試修復。

意圖明確的 merge conflict

部分衝突只是機械性的，例如一個 branch 改了 helper 名稱，另一個 branch 修改了 call site。

但衝突修復仍需要比 lint 更高的審查強度，因為「語法正確」不代表「商業邏輯正確」。

哪些情況應保留強人工審批？

TowCue 不建議把 Agent Merge 當成取消 release judgment 的理由。

以下工作至少在初期應維持明確人工 review：

security-sensitive changes
authentication / authorization
payment 與 billing
destructive database migration
production infrastructure configuration
大型 dependency upgrade
模糊的產品需求
測試失敗是因為「正確行為」本身還沒有共識
兩個 branch 的衝突代表不同商業邏輯

可以用一句話區分：

當目標已經明確時，Agent 很擅長執行；當「目標到底應該是什麼」仍有爭議時，人仍然是核心。

最大的隱性風險：把「CI 變綠」誤當成「軟體正確」

一個 PR 可以變成 merge-ready，但不代表它真的正確。

如果只要求 Agent「讓 CI 通過」，可能有很多方法：

修正 implementation
修改 test
弱化 test
改 configuration
suppress warning
移除會失敗的 path

只有部分做法真正保持了原始需求。

因此 Agent Merge 最重要的控制，不只是功能開關，而是任務周圍的 acceptance criteria 是否清楚。

在讓 Agent 長時間自動修復前，團隊最好先寫清楚：

哪些行為不可改變
哪些檔案或系統不得觸碰
是否允許修改 tests
是否允許更新 dependencies
Agent 最後必須回傳哪些驗證證據
哪些動作一定要人工確認

這與 TowCue 在 AI Agent 最佳實踐指南裡建議的邊界設定原則一致。

一個低風險的 Agent Merge 測試方式

不要第一天就拿關鍵 production PR 來測。

第一步：選擇範圍小、可逆的 PR

優先測 maintenance、內部工具、小 Bug 修復，而不是支付、登入或關鍵資料流程。

第二步：保留人工 merge gate

可以先讓 Agent 處理 review feedback 和 CI，但最後的 merge approval 維持人工。

第三步：記錄人工介入率

每個 PR 至少記錄：

Agent 正確處理了多少 review comments
修復了多少 CI failures
人需要 redirect 幾次
是否意外修改 tests 或需求
final diff 是否膨脹得不必要

第四步：與原工作流比較

不要只看 token。

更重要的是比較：完成時間、人工注意力、context switching 次數，以及最終 regression。

如果 Agent 多花一些 compute，卻少掉四次切換工作上下文和兩輪人工修 CI，整體成本仍可能下降。

第五步：按「任務類型」擴大，而不是一次全面開啟

五個簡單 PR 成功，不代表所有 PR 都適合自動化。優先擴展到失敗模式、風險程度相似的 PR。

Agent Merge 只是 VS Code 更大方向的一部分

VS Code 1.136 同時加入多個 Agent 管理能力：

Chat sessions：整理相關對話，顯示哪些 session 需要注意
Agent session notifications：Agent 完成或需要輸入時通知
Multi-root workspaces 實驗功能：讓 Agent session 橫跨多個資料夾
Agent Host：讓持久 Agent session 能跨 VS Code 視窗運作

把這些功能放在一起看，方向非常清楚：VS Code 正在從「一個 AI 助手回答一個 prompt」的 IDE，變成管理多個長時間 Agent session 的控制台。

Agent Merge 特別重要，是因為它把 Agent 與真正決定工作能不能上線的 review / CI / merge 流程接了起來。

誰最值得現在開始測？

Agent Merge 特別適合：

PR 數量很高的團隊
已經使用 coding agents 做 implementation 的開發者
自動測試與 CI 完整的 repository
review feedback 大量且重複的團隊
經常花時間 shepherd 小型 PR 通過所有 checks 的 maintainer

相反，如果 repository 測試覆蓋很弱、ownership 不清楚、review 判斷高度主觀，那 Agent Merge 的價值就會低很多。

Agent 自動化越深，周圍的工程系統就越需要提供清楚的訊號。

TowCue 觀點

Agent Merge 比「model picker 又多了一個模型」更值得工作流使用者關注。

AI 編程的新瓶頸正在從：

「模型能不能寫出程式碼？」

變成：

「系統能不能把工作從 implementation 推過 review、validation、repair 到 merge，而且不增加更多 supervision 成本？」

VS Code 與 GitHub 很明顯正在自動化後半段。

TowCue 不會一開始就開啟最大自主權。我們更建議先把 Agent Merge 當成PR repair assistant：

先讓它修明確 feedback
再讓它修可重現的 CI failure
每次修改都要求驗證證據
最終 merge 保持人工
只有在 intervention rate 與 regression rate 都可接受後，再增加自主權

如果這套流程有效，真正的生產力提升不是「AI 多寫了多少行程式碼」，而是少了多少卡住的 PR，以及從 implementation 到 merge 之間少了多少次人工打斷。

VS Code Agent Merge 公開預覽：AI Agent 開始接手 PR 審查、CI 與衝突修復