VS Code 團隊工程經理呂鵬（Penn）分享了 VS Code 在 AI 智能體整合方面的最新進展。從 2025 年 2 月推出 Agent 模式以來，團隊已發展出本地前台、後台、雲端三種智能體類型，並正在探索如何統一管理這些多元化的智能體會話。本次對談深入探討了大型程式碼庫面臨的專案就緒度、程式碼審查瓶頸，以及如何將 AI 工作流融入日常開發實踐。

原影片連結：https://www.bilibili.com/video/BV11zkVBHED3

影片重點

• VS Code 已推出自訂智能體、完整 MCP 支援、規劃模式等大量 AI 功能
• 團隊將智能體分為三類：本地前台（互動式）、後台（非干擾式）、雲端（完全自主）
• 七月引入 Coding Agent 整合，可從 GitHub Issue 觸發智能體自動處理問題
• Copilot CLI 已整合至 VS Code，統一各類智能體體驗
• 大型專案（如 VS Code 本身）需要「專案就緒度」設定才能有效使用後台/雲端智能體
• AI 生成程式碼的審查成為新瓶頸——人類反而成了流程中最慢的環節
• 工作流優化是持續演進的過程：從手動指令到共享工具再到自訂代理
• 設計規範文件可同時作為開發計畫和測試計畫，是團隊協作的核心

詳細內容

[00:00] 講者介紹與功能概覽

呂鵬（Penn）是 VS Code 團隊的工程經理，2016 年加入團隊，先後負責 Monaco 編輯器、VS Code 與 GitHub 整合、原生 Notebook 功能等開發。近年來深度投入 AI 整合與 Copilot 工作。

自 2025 年 2 月推出智能體模式以來，VS Code 已陸續推出自訂智能體、完整規格 MCP 支援、規劃模式等功能。Penn 和 Ben 的小團隊重點聚焦在智能體與智能體會話管理領域。

[01:03] Coding Agent 整合與統一智能體體驗

七月份，VS Code 引入了 Coding Agent 整合功能。使用者可以在 github.com 上建立 Issue，智能體會代為處理該問題，或在 GitHub Action 中遠端修復漏洞。當使用者返回 VS Code 時，可以瀏覽和審查修改內容，並與智能體互動協作。

下一步是將 Copilot CLI 整合到 VS Code，統一智能體體驗。透過與 Codex 擴充功能的整合，使用者可以使用各種類型的代理——無論是雲端版本、終端介面、後台運行還是前台運行。

[01:49] 三種智能體類型的定義

隨著多種不同類型的代理出現，管理它們成為新挑戰。世界正從「單一代理同步運行在前台」轉向「可管理多種類型代理的大規模並行代理會話」時代。團隊將智能體分為三類：

本地/前台智能體：就是每天在側邊欄使用的那個。它需要響應迅速、具備互動性，使用者期待快速回應，不想等十分鐘才得到回覆。

後台智能體：更像是「這是任務和上下文，你去執行吧」的模式。它不會干擾當前的編輯器和終端，不會不斷詢問權限，需要一定程度的自主行動能力。它仍在同一台機器運行，可存取已設定的 MCP 服務器。完成後會發送通知提醒使用者查看結果。

雲端智能體：運行更隔離，完全在雲端遠端運行，可從任何地方啟動。典型工作流程是在 Issue 上觸發，也可以在離開電腦前將活躍的前台任務發送至雲端繼續運行。

[05:51] 統一視圖管理的挑戰

最初本地代理、後台代理和雲代理都在聊天編輯器中，但各類代理行為不同，造成使用者困惑。這推動團隊思考如何提供統一的視圖管理，同時讓使用者理解各類代理有不同的預期和能力。

[06:35] 專案就緒度問題

對 VS Code 這樣擁有數百萬行程式碼的大型專案，讓後台或雲端智能體有效運作需要仔細的專案設定。例如，要在後台代理中執行測試（單元測試、整合測試、冒煙測試），加上 Playwright 這樣的 MCP 服務器來啟動瀏覽器和截圖，都需要確保 MCP 服務器生成的內容不僅供人類查看，還要供代理審查和迭代。

如果專案未正確設定就推送到後台，可能得不到好結果——甚至運行結束後程式碼仍無法編譯。團隊認為可以透過定義 Hook、技能（Skill）、Prompt 規則或工作流程來降低使用門檻，提高後台和雲端代理的成功率。

[08:56] 代理產物的展示挑戰

目前 VS Code 在每次會話後會展示程式碼更改，但程式碼並非唯一的產物。例如使用代理運行測試可能花費 20-30 分鐘，過程中產生的截圖和推理過程也很重要。Penn 表示他不會百分之百信任代理的輸出，仍想瀏覽推理過程和關鍵截圖。目前 VS Code 工作台還沒有很好的方式展示這些非程式碼產物。

[09:51] 大型專案的程式碼審查困境

對於個人小型專案，Penn 不太介意 AI 生成的程式碼——如果不好用，撤銷重寫也只需一小時。但 VS Code 是龐大的開源產品，對程式碼品質、架構預期和程式碼異味都有很高要求。

想像一下：VS Code 每月有三千個 Issue，其中很多是 Bug。如果搭建完美的自動化流水線——分析程式碼庫、找出根本原因、進行修改、編譯驗證——每月可能產出大量 PR。但這時，人類成了流程中的審查瓶頸。這正是 VS Code 團隊需要在工具層面解決的問題，讓開發者既能保持創意和專注關鍵路徑，又能有效地與代理協作。

[11:36] 工作流優化的演進模式

Penn 分享了他個人在工作流優化上的持續演進。最初需要明確的程式碼規範指令，因為代理常常忘記遵循。但隨著模型越來越智能，它已能自行讀取 package.json、執行 npm install、處理 Node 版本問題。

他觀察到一個模式：先與代理協作完成前台工作，觀察代理犯了哪些錯誤，如果自己不斷重複同樣的糾正，就將其提取為共享工具。一個五步流程可以變成自訂代理、技能（Skill），或加上 Hook。這是一個從「觀察痛點」到「結構化工具」的持續優化循環。

[13:04] 設計規範作為活文件

Penn 傾向於將規劃保存為文件文件，作為「活文件」（Living Document）使用。當團隊為 VS Code 構建功能時，從一個 Issue 開始，列出常見場景和使用方式，成為團隊的北極星指引。

現在他將這些規範交給代理自主工作，最終希望另一個代理也能測試功能。有趣的是，同一份設計規範既是開發計畫，也可以轉變為測試計畫——讓代理驗證變更是否按步驟正確執行。這種「自然語言規範即計畫即測試」的模式在小型專案中效果顯著，但對中大型專案仍需要更多思考。

[14:24] 多代理並行與持續學習

Penn 提到現在可以同時運行多個代理會話。之前只能運行一個時，他的策略是在同一對話中不斷加入新提示。現在支持並行異步運行多個代理後，後台機制的核心在於隔離性——防火牆隔離、環境隔離、甚至設備隔離。

最後，Penn 強烈鼓勵大家親身嘗試，將 AI 智能體融入日常工作流程，感受其中的「小摩擦」，然後反饋給團隊以改進產品。

我的想法

這場對談讓我印象最深的是 Penn 提出的「人類成為瓶頸」這個觀點。當 AI 代理能夠自動分析 Bug、修改程式碼、通過測試時，反而是人類的程式碼審查速度跟不上了。這是一個有趣的角色反轉——過去我們擔心 AI 不夠好，現在卻要思考如何在保證品質的前提下加速人類的審核流程。

三種智能體類型（本地/後台/雲端）的分類框架非常實用。這不僅是 VS Code 的設計思路，也為所有開發者提供了一個思考如何分配 AI 任務的心智模型：需要即時互動的用前台代理，定義明確的任務用後台代理，完全自主的長時間任務用雲端代理。

另一個值得關注的是「專案就緒度」的概念。這提醒我們，光有強大的 AI 工具還不夠，專案本身的基礎設施（測試覆蓋率、MCP 配置、CI/CD 流程）才是決定 AI 代理能否有效工作的關鍵。對於想充分發揮 AI 代理能力的團隊，投資在專案的可自動化程度上可能比選擇哪個 AI 模型更重要。