每天審200個PR、每月3000個Issue？智能體開始并行寫代碼，人類可能成最薄弱環(huán)節(jié)

翻譯 | 核子可樂

策劃 | Tina

編輯 | 蔡芳芳

Visual Studio Code 已成為現代軟件開發(fā)領域最具影響力的工具之一。而隨著 AI 輔助編程時代的來臨，VS Code 也開始引領軟件編寫方式的深刻變革。

行業(yè)巨變的當下，編程的本質也正在快速轉變，開發(fā)者與工具的交互方式已經發(fā)生明顯變化：AI 不再只是提供代碼補全，而是逐漸參與到開發(fā)流程的更多環(huán)節(jié)中。從最早的代碼補全實驗，到 ChatGPT 出現后引發(fā)的新一輪界面設計與交互探索，VS Code 團隊也在不斷調整編輯器的設計思路。作為微軟 VS Code 團隊的工程經理，Kai Maetzel 見證并參與了這一轉變的全過程。

在本期 Software Engineering Daily 播客中，Kai Maetzel 與主持人 Kevin Ball 回顧了 VS Code 的發(fā)展歷程，并分享了團隊在 AI 編程、智能體開發(fā)以及開發(fā)者工具設計方面的實踐與思考。例如，如何在代碼補全中平衡提示頻率與開發(fā)者體驗，如何設計能夠與 IDE 深度協作的智能體，以及在智能體開發(fā)逐漸興起的背景下，開發(fā)工具可能出現的演進方向。

以下為完整的訪談內容，經 InfoQ 翻譯并進行了不改變原意的編輯：

主持人（Kevin Ball，現任 Mento 工程副總裁）：Kai，歡迎參加本期節(jié)目。咱們就從你的背景經歷說起吧，包括你領導 VS Code 團隊的整個歷程。

Kai Maetzel：其實我的職業(yè)生涯起步很早。我的第一份實習工作就在 DevTools 開發(fā)工具部門，之后也一直深耕于此。十年前我加入微軟時，正是看中了 VS Code 項目的發(fā)展?jié)摿Α敃r團隊就預見到，它一定能在市場上引發(fā)轟動。從零起步到現在，我們的用戶群體已達 4400 萬。

主持人：記得 VS Code 剛推出那會，我還想著“怎么又來了款 IDE？”結果它最終席卷了整個市場。

Kai Maetzel：這么想也正常，這可是個根深蒂固的市場—— 編輯器歷史悠久，IDE 多種多樣。但我們所有人似乎又都很糾結，總覺得已有的編輯器不夠讓人滿意。比如“這個功能用這個做超級快，那個功能用那個做效果不錯，麻煩的是啟動太慢，界面又太花哨"等等，反正是各有問題。我們真正要做的就是尋找中間的黃金平衡點。

也就是說，我們面對的實質上是這樣一個問題：一端是輕量化編輯器，另一端則是功能完備的集成開發(fā)環(huán)境。二者中間的平衡點在哪里？這正是我們努力探索的方向，好在 VS Code 確實精準命中了靶心。

1 AI 補全如何改變代碼編輯體驗

主持人：一點沒錯，而且你們已經領先了一段時間。但如今科技行業(yè)正經歷劇變，編寫代碼的本質似乎正在快速轉變。我特別想深入探討你們對此的思考路徑。初步將 Copilot 引入 VS Code 肯定只是起點。那么 VS Code 究竟經歷了怎樣的旅程，才引領我們進入這個智能編碼的新世界？

Kai Maetzel：當人們回顧歷程時，很容易忘記一路走來自己的認知和心境發(fā)生了哪些變化。短短六個月之前我們對于編程本質的認識，跟當下相比已經天差地別。前幾天跟其他人交談時，對方提到“60 天前”，結果我震驚地回應說“啊？我以為那已經是大半年前的事了。”一切都發(fā)展得太快了，感覺時間都被壓縮了似的。

首先向大家交代相關背景：最初我們 VS Code 團隊是和 GitHub Next 團隊合作的。GitHub Next 本質上屬于內部研究部門，他們和 OpenAI 關系密切——AI 智能感知建議功能就是由此誕生的。

其他領域對 AI 的應用早有嘗試，所以我們做的也不完全是新鮮事。比如把同類功能集成在代碼輔助之類的模塊當中，加上一個星標來說明：“這部分是 AI 建議，其余部分則來自語言服務器等。”這是第一階段的思路，但后來我們意識到必須改變這種模式，必須構建全新的用戶界面。于是我們開始全力推進 Ghost Text 的開發(fā)。

我們很早就實現了多行代碼補全功能，但很快發(fā)現無人使用——因為大家不想打斷編碼流程去審閱代碼。于是我們決定倒退一步，轉而追求“更精簡的補全方案”。補全功能的整個演進歷程基本就是這樣推進。隨后，ChatGPT 橫空出世。

ChatGPT 發(fā)布后不久，我們就在 VS Code 團隊內部發(fā)起了一場黑客馬拉松，四天時間盡情用這些新模型和新方法打造我們認為可行的東西。這段經歷非常有趣，也很快讓我們明白：這種能力絕不能只是附加在工具邊緣，它必須真正融入工具本身。

AI 必須滲透到每個細節(jié)。以 VS Code 的命令面板為例：當你輸入內容時，優(yōu)秀的 AI 應當智能解析真實意圖而非字面含義，同時又必須在“用戶堅持字面輸入”與“避免過度猜測”之間找到平衡點。當然，此外還有性能考量。VS Code 的每個環(huán)節(jié)都突然變得至關重要，比如 AI 響應不夠快等問題。但有一點已經非常明確，AI 必須成為核心體驗的一部分。

對我們來說，后續(xù)的討論也非常有趣。當時 GitHub Copilot 已是成熟品牌。VS Code 本身無需登錄即可啟動，但使用 GitHub 功能則需要登錄。GitHub 早已具備計費體系等完整生態(tài)，更擁有成熟的品牌認知。該如何平衡擴展功能與核心功能的邊界耗費了我們相當長的時間。

聊天功能也涉及諸多問題。不僅要考慮可用模型種類，更要評估這些模型的實際能力——例如能處理多少上下文窗口等。初創(chuàng)公司思考這些問題的方式，與成熟盈利企業(yè)的思路截然不同。

微軟當然有自己的考量。例如我們花了很長時間才說服團隊：“必須采用更大上下文窗口，4K 窗口根本無法高效工作。”初期面臨的都是這類前所未有的挑戰(zhàn)，對整個公司來講都算相當陡峭的學習曲線了。

好在隨著時間推移，我們逐漸摸索出方向。我們不敢說已經找到了終極正確的路線，但應該算是掌握了核心要義。回顧過去一年，我們推出了編輯功能，推出了名為 NES 的標簽頁切換模型。我們構建了智能體循環(huán)，將 GitHub Copilot 編碼智能體等云智能體整合進來，現在還有 Copilot CLI。所有這些都被集成到 VS Code 界面中，通過智能體會話視圖實現協同。目前我們正積極優(yōu)化智能體會話視圖，希望進一步完善其使用體驗。

類似這樣的變化可以說一刻不停。與此同時，競爭格局在轉變，模型能力也是一日千里。現在最重要的不僅是能力本身，更涉及運行時長、響應速度——比如首次生成 token 的時間。在用戶逐步掌握使用技巧的過程中，該如何在恰當時機采用最優(yōu)模型組合？這是個動態(tài)性極強的領域。

主持人：確實如此。這里我想多聊幾句，你提到從最初探索高級標簽補全（AI 驅動而非僅依賴語言服務器）時，就必須權衡展示程度與開發(fā)者調整空間的關系。那該留多少空間讓開發(fā)者自行修正方向？

我認為 AI 模型的精妙之處在于能構建意圖驅動的界面——既能預判用戶操作意圖加速引導，又可能出現判斷失誤。因此我很好奇，隨著你們逐步疊加這些功能（從聊天式編程到智能體編程等技術演進），要如何把握這個關鍵平衡點：“我們能為你做很多事，但如何確保每個環(huán)節(jié)都是正確的選擇？”

Kai Maetzel：首先得承認，這確實是個尚未解決的問題。沒想到吧，這事兒現在還懸著呢。咱們以標簽補全功能為例，比如 NES（下一條編輯建議），始終存在兩個核心問題：應該向用戶展示什么內容？應該以怎樣的頻率展示？用戶實際采納提示的概率又有多高？用戶主動忽略提示的概率呢？這一切共同構成了操作空間。正如先前討論的，我們得在編輯器與 IDE 之間尋找平衡點。

我們先確定思路的兩個極端：一端是立即向用戶展示模型提出的全部建議，此時接受率絕對值會持續(xù)攀升，但用戶的煩擾感也會同步加劇。因此必須精確把握提示頻率——到底要以怎樣的頻率向用戶展示建議？其中用戶未主動拒絕而默認接受建議的比例又是多少？要想精準把握這種顯性接受與顯性拒絕的平衡點，必須得持續(xù)進行精細調校。因為用戶會逐漸形成預期——初次使用 NES 的用戶與資深用戶也將具有截然不同的認知。

用戶的打字速度等因素也有影響。例如等待多長時間才顯示建議？慢速打字者可能經常被模型建議打擾，而快速打字者則因建議遲遲不出現而焦躁——他們希望一氣呵成地輸入。只需按 Tab 鍵確認輸入——因為他們能預判模型的預測結果。這需要持續(xù)優(yōu)化。我們通過精細的儀表板追蹤各項指標，反復調整參數后進行 5% 用戶測試，觀察實際交互行為的變化。

增加顯示內容是否帶來正向 / 負向效果？用戶按 Esc 鍵的頻率如何？這些數據非常有趣。例如上次統計顯示 Esc 鍵使用率僅約 3%，但詢問用戶時他們卻堅稱“我的 Esc 鍵都按冒煙了”——數據卻證明事實并非如此。這確實非常耐人尋味。因為歸根結底，開發(fā)者的幸福感至關重要。這種幸福感源于多重因素：你對生產力的感知、思維的流暢度、專注程度以及煩擾程度等。要真正實現這一點，需要持續(xù)不斷的優(yōu)化過程。

主持人：完全同意。作為資深 Vim 用戶，我必須說一句：用 VS Code 的時候確實感覺總在按 Esc。

Kai Maetzel：沒錯，感知跟現實就是會有錯位。

主持人：有個疑問——你提到不同打字速度或經驗水平會影響體驗。那調整這些參數時，變化是面向全局的嗎？你們有沒有設計自適應系統？比如打字速度快的人能獲得更快速的補全？具體如何實現？

Kai Maetzel：目前主要還是全局設置。但我們正在研究如何將打字速度編碼到模型輸入中，使其能真正考慮這個因素。

主持人：明白了。實際應用的仍然是全局模型，但打字速度將成為基于用戶特征開發(fā)的輸入參數。很有意思。那么你提到的特征空間里，打字速度是否代表用戶的新手程度，或是某種以特定方式編碼的用戶特征？

Kai Maetzel：我們目前還沒找到能準確體現用戶經驗水平的好辦法。工作區(qū)倒是個重要參考指標，但它未必能揭示用戶是否初次接觸該特定工作區(qū)。要建立完整的用戶畫像相當復雜，因為我們每個人在瀏覽不同倉庫時都會經歷不同階段。比如打開 Rust 倉庫時，我可能比瀏覽 TypeScript 倉庫時速度更慢、更謹慎。在理想狀態(tài)下，這些因素也應納入我們的設計考量——雖然目前尚未實現，但我們正在思考這些方向。

2 從聊天式編程到智能體開發(fā)

主持人：除了編輯建議功能外，你們在探索基于聊天的開發(fā)模式乃至日益普及的智能助手循環(huán)開發(fā)模式時，在交互性方面又做了哪些權衡取舍？

Kai Maetzel：這么說吧，最初所有工具（包括我們自己的）的聊天界面都很精致。你看著它們會感嘆：“哇，這功能真厲害！”但實際使用體驗又達不到這份預期。

主持人：太對了，我用 AI 也有這種感覺。

Kai Maetzel：我們耗費數年優(yōu)化流程，比如將某項交互從 3 秒縮短到 2 秒。我們所做的一切，都是為了讓用戶保持流暢狀態(tài)。但在進入聊天界面時，理想情況下回答生成也需要 20 秒，有時甚至可能耗費幾分鐘。

用戶忍受這種延遲的唯一理由，就是最終結果要比自己操作更快更好。這就是甘愿承受些許折磨，只為換取更優(yōu)結果。這正是我們開展此類聊天交互時的初始基準。但不知道大家有沒有感覺到，現在的情況已經悄然改變了。

首先，我們擁有更快速的模型了，人們也發(fā)展出不同的交互模式。例如：一種模式是使用高速模型進行研究。你主動去嘗試，通過交互摸索目標方向。在完成這種主動研究之后，我們已經大致明確了需求，能將其轉化為合理的提示詞，再交給后臺智能體執(zhí)行——這是第一種模式。

另一種思路，或者說行為模式則幾乎與此相反：人們會說"不，我要運行多個探索性異步智能體。我只給出大致目標，具體方案由它們負責制定。"這種方式耗時較長，通常采用體量更大、速度較慢的模型生成方案。把初步成果稍作調整后，再切換到速度更快的實現模型。之所以這樣做，是因為你深知 AI 無法全程精準執(zhí)行，需要人工介入輔助。完成 90% 之后，再手動處理剩余的 10% 完全可行。畢竟從 92% 推進到最后 8% 的差異并不顯著，正因為如此，人們才愿意接受不夠精密的模型。

很明顯，這兩種工作模式截然不同：一種追求同步性、速度、探索與思考的全程掌控；另一種則采用交互式推進——先完成初步構思，再進行委托與復核。前者由于最初就已明確行動方向，后續(xù)復核時需要調整和變更的部分會更多。而另一種模式中，模型負責代理決策，我則協助執(zhí)行，這使得整體復核工作量大幅減少——二者的差異頗為耐人尋味。

你提到的這種權衡確實存在——交互性與非交互性的取舍。我們實現了多種定制智能體模式：例如純詢問模式（僅執(zhí)行指令而不作修改）、自定義編輯模式（可限定修改范圍）以及智能體模式。我們正在探索一種新的交互模式，希望模型或智能體變得高度可控。當你要求“修改這個文件”時，它只會修改目標文件，而不會去修復其他五個文件導致編譯錯誤——因為控制權完全掌握在你手中。

但關鍵在于，這種模式必須極其快速。我們已經在規(guī)劃模式下發(fā)布了規(guī)劃智能體。其中存在各種權衡取舍，且我們始終在持續(xù)學習。但這就像開發(fā)工具的傳統困境——不同類型的開發(fā)者有不同需求和偏好，必須為每個人提供恰當的工具組合，讓他們找到舒適的工作狀態(tài)。

主持人：讓我們深入探討一下，你剛剛提到這些不同模式的可操控性存在明顯差異，對吧？Sonnet 喜歡編輯所有文件，它就是喜歡交流，其他模型則不然。但你們在智能體框架中做了大量工作，特別是如何定義這些智能體。能不能再具體聊聊？編碼工具可以說是當下最先進的智能體，那你們要如何構建？定義這類智能體（如詢問智能體）的技術棧是什么？

Kai Maetzel：這才是核心所在，而且我估計你已經聽到過不少答案了。智能體循環(huán)其實沒那么復雜。就像你給它一堆工具，再教它如何使用這些工具。大多數操作指南其實都包含在工具說明里，有時也會另行說明。每種模型都有特定傾向，分別對應不同的提示詞指引。

比如有些模型需要你明確告知“請定期向用戶更新進度”，而另一些模型在收到此類指令時會終止循環(huán)——Codex 就是典型案例，它在需要向用戶更新時會主動停止。雖然存在這些差異，但大模型的核心原理始終如一。接下來你需要明確指導智能體。其中一個有趣的難題在于：任務到哪一步才算是完成？在哪個時間點可以判定任務結束？以上便是整個流程的基礎框架。

當你調用自定義智能體時，我們允許你定義該智能體可使用的工具集。這些工具可能來自不同來源：VS Code 內置工具、用于定義工具的擴展程序，甚至可以安裝 MCP 服務器，總之工具集相當龐大。

因此在自定義代理文件中，你可以明確指定必須提供的具體工具。之后就是我們慣用的受 Markdown 啟發(fā)的語法。你可以通過它定義智能體的具體操作方式。很多人見過 Claude Skills 的實現形式，其實所有定義都具有高度可比性，這種特性很關鍵。它本質上是個 Markdown 文件，可引用其他指令文件來指定工具的使用規(guī)則和適用場景。

例如你可以這樣寫：“我已經在工作區(qū)里，說明我定義好了所有環(huán)境。我希望你使用測試運行工具，而不是手動執(zhí)行 npm run tests 或 cargo test 之類的命令。” 有時候需要明確說明這些要求，但有時模型也會自行推斷——比如假設你的測試用例有誤。有趣的是，那是我第一次意識到模型竟能如此智能。它們幾乎重寫了測試用例來確保結果為真。雖然實現方式有些晦澀，但核心邏輯很明確：我當時開心得不得了，因為所有測試都順利通過了。你也可以提出明確的要求，比如：絕不觸碰測試文件，那邊確定沒問題。重構時或許需要調整，但斷言本身不可更改。規(guī)則就是這么簡單明了。

但實際投入大量工作后，我們又開始思考：“工具使用需要多少操作指引？需要提供多少指導？”整個評估體系需要在其中發(fā)揮關鍵作用——具體運行了哪些評估指標？運行多少次？運行頻率如何？如何準確評估結果？整個過程跟其他領域截然不同。

比方說，我們會運行行業(yè)標準的 SWE 基準測試作為評估指標之一。我們不僅關注問題解決率——畢竟解決率只是從 A 到 B 的過程，這個過程可能極其混亂。我們關注的是從 A 到 B 的速度。你實際調用了多少工具？達到目標時消耗了多少 token？是否調用了我們認為應該用到的工具？

以終端工具為例：若作為后臺智能體運行，你完全可以使用該工具完成任務，這無可厚非。但若在 VS Code 中作為前臺智能體運行，用戶期望在發(fā)現測試失敗時，能直接在測試資源管理器中定位失敗項并點擊查看。此時就該啟用該工具。若存在監(jiān)視任務，就不該耗費大量輪次去推測如何構建名為“監(jiān)視任務”的項目，因為肯定是要的。我們會在實際運行后對這類評估做對比。此外還有后續(xù)微調工作：詞匯替換、工具分類歸檔等操作，這些細節(jié)也會切實影響最終效果，背后需要投入大量工作。

主持人：沒錯，這個看似簡單的封裝器內部其實暗藏玄機。我想深入探討幾個點。首先如你所說，不同模型間似乎存在傾向差異——比如調用工具的方式、與用戶交互的頻率等。我的界面只有個簡單的模型切換器，實際操作完全不可見。你們是否針對不同模型定制工具描述、核心代理指令等細節(jié)，以確保行為一致性？具體實現機制是怎樣的？

Kai Maetzel：我們的項目有兩種狀態(tài)：當前運行狀態(tài)和短期期望狀態(tài)。畢竟我們是開源項目，你可以直接查看代碼庫。比如在 VS Code 運行時，我們的日志視圖會完整記錄模型調用過程，每個細節(jié)都清晰可見。你甚至能通過具體詞匯進行驗證——這在日常使用中就能體現。

當前階段，我們?yōu)槊總€模型家族都設計了特定提示詞，有時還會進一步精細化。有時我們會更細致地對模型版本進行說明。我們會嚴格區(qū)分 GPT5、GPT5 Codex、GPT5.1 Codex。由于迭代速度極快，我習慣稱其為五代而非 5.1 版。但從行業(yè)角度看，不同模型在主提示詞文件生成時確實存在差異。隨后我們會根據具體模型選擇適配的工具、補充額外指令等等。

我們還嘗試定制工具描述之外的指令，只是目前尚未實現——我們還沒有編碼模型能明確指出“這種工具描述在特定模型中效果更佳”。但我們已經多次討論過這個問題了，只是始終未能推進到“即將實現”的階段。在最近的迭代計劃中，我們再次提起這個話題，我強調：‘十二月初發(fā)布時應該可以做到’，即實現模型特異性工具描述——通過提示詞文件覆蓋默認設置，明確指示“當此工具出現時應采用該描述”。

3 智能體如何理解代碼：上下文與工具

主持人：另一個細節(jié)是為智能體構建上下文的方式——比如在特定倉庫環(huán)境中操作時，需要處理哪些元素。除了工具之外，還有人會預先注入不同長短的上下文信息。這可能不僅限于系統提示詞，還包含大量附加內容。你認為應該如何正確地向智能體呈現信息，使其從一開始就朝著正確方向發(fā)展，而不是完全依賴按需調用工具？

Kai Maetzel：這里有幾個關鍵點，我就先從工具說起吧。如今大多數模型都是用特定工具集訓練的，所以開箱即用就掌握了一套工具。比如 GPT 模型必須具備應用補丁功能，字符串模型則擁有字符串替換功能。這類基礎工具是它們各自必備的。于是新的問題來了：在這些基礎工具之外，模型的泛化表現能達到什么水平？

說到這里，工具的重要性已經非常明確了。同時我們還需考慮上下文：當前提示詞在何種環(huán)境中執(zhí)行？是前臺智能體還是后臺智能體？這是第一個問題，關注的是工具在提示詞中如何具體呈現。再者，假設我們手頭有若干 MCP 服務器。有些服務器僅配備一、兩款工具，而另一些則搭載數十種工具。多數模型對提示詞中能夠容納的工具數量存在限制——通常是 128 項。除此之外，還需要考慮實際投入的 token 數量。

對于那些使用頻率極低或僅在特定場景下啟用的工具，你愿意消耗多少 token？我們的解決方案是：將 MCP 服務器提供的所有工具進行虛擬分類，每個分類都作為獨立工具存在。我們將這些工具交給模型。當模型決定調用某個虛擬工具時，我們便立即將其展開。但權衡取舍也隨之而來，因為一旦展開……

主持人：KV 緩存等資源就馬上被耗盡了。

Kai Maetzel：正是如此。某些模型支持將這項操作置于提示詞末尾，而另一些則不支持。此時必須立即做出權衡，這也正是大量評估測試介入的環(huán)節(jié)——你需要在所有不同配置下運行測試。這涉及優(yōu)化決策的權衡，比如： “即便緩存偶爾失效一兩次，長期來看仍可接受”，或者你認為“其實可以使用更長的提示詞”，因為能讓緩存命中率提高到 87%（或其他數值），這樣的價值交換可以接受。

這種權衡取舍在其他上下文部分也同樣存在，根本不存在真正穩(wěn)定的狀態(tài)。當然也有一些相對穩(wěn)定的要素——比如用戶身份、用戶運行的倉庫環(huán)境。但問題在于：關于項目本身，究竟需要提供多少信息？

比如我們設置了這樣的前綴，表達 "這差不多就是用戶眼中看到的項目形態(tài)”，這還算是合理的 token 消耗。但在此之上還有動態(tài)包含的內容——當存在 AGENTS.md 文件時，我們會執(zhí)行自定義指令，這些指令支持多種定制方式、處于特定位置。在自定義指令文件開頭可以聲明適用范圍，通過通配符模式指定“某個測試文件夾中的 TypeScript 文件”這類具體應用場景。

此外還有另一種機制，可以明確描述自定義指令適用的具體語言環(huán)境。我們會收集這些規(guī)則并將其納入提示詞系統。我認為這個過程最具價值，因為它確保用戶能自主掌控代碼庫的 AI 預處理程度。只要用戶的預處理質量夠好，智能體就能極快定位目標位置，明確起點與搜索范圍。

主持人：或許我們可以聊聊智能體組件與 IDE 本身的交互機制。你之前提到過幾個實例：若智能體在前臺運行，應使用能連接 IDE 組件的工具，確保其在正確環(huán)境中運行而不再依賴終端。但您向智能體公開的 IDE 接口范圍有多大？如何區(qū)分智能體引發(fā)的變更與人工操作引發(fā)的變更？

Kai Maetzel：關鍵在于你如何與它交互，對吧？最直接的方式就是在 VS Code 中運行一個前臺智能體。這個前臺智能體具備豐富的功能集：它能監(jiān)控終端操作，讀取終端選定內容，還能運行工具、監(jiān)視任務等等。我們還為其配備了專業(yè)編輯工具，能夠在特定時間點運行快照功能，這樣就能向你展示所有彼此關聯的差異對比。我們?yōu)榍芭_智能體準備了相當豐富的工具集。

而后臺智能體則截然不同，我們?yōu)槠涮峁┑墓δ艽蠓啞槭裁匆獏^(qū)別對待？首先，若在前臺運行智能體，用戶自然期待其響應速度要快。這涉及交互體驗，畢竟沒人愿意枯坐兩分鐘而無所事事，大家都希望快速獲得結果，對吧？同時還要確保這些操作，本質上正確反映你希望執(zhí)行的擴展行為。

但當你把任務移到后臺運行時，顯然希望它在任何情況下都別搞亂你的 UI 狀態(tài)。我們之前多次提到測試運行器的例子，你絕不希望它干擾到測試運行器，更不希望它擅自打開終端導致鼠標突然點擊錯誤位置，對吧？

你實際使用的工具集各不相同。云端智能體又是另一種模式。后臺智能體仍在本地設備運行，所以會受到合蓋操作影響；而云端智能體則不然。關鍵在于：該智能體實際運行于何種容器化環(huán)境？你使用的具體項目是什么？它能否在該容器中成功構建？能否在容器內執(zhí)行測試？有時候可以，有時候會出問題，諸如此類。所以云智能體為此配備的工具明顯更為精簡。不好意思有點跑題了，能不能再復述一下問題？

主持人：我的問題其實是：您如何看待這些交互？雖然已經解釋了很多，但這讓我產生一個疑問——不同工具的公開程度差異，究竟會多大程度影響智能體的執(zhí)行效果？試想同一條提示詞在 IDE 環(huán)境、后臺智能體和云環(huán)境中的呈現，可能導致截然不同的編碼行為。

Kai Maetzel：我認為模型選擇對實際結果的影響更大。我們真正想做的是在用戶體驗與智能體成功之間取得平衡。正如我們所說，終端工具能執(zhí)行終端命令，能實現很多功能。你無需編輯器來重定向輸入并輸出注釋。有了編輯器，它就能向文件系統執(zhí)行寫入。

要讓智能體成功完成從 A 到 B 的任務，其實并不需要一大堆工具。當然，差異也是客觀存在的。例如，行業(yè)可能發(fā)布待辦事項工具以實現智能體長期運行、自我組織等功能。但若深入思考，你會發(fā)現實現成功其實并不需要太多工具——這是其一。

當我們將智能體置于前臺并賦予更多工具時，智能體跟環(huán)境的相關度就會更高。例如，我們可以向智能體提議“或許可以安裝這個擴展以提升用戶體驗”。但在 VS Code 里，我們會提供現成的工具。比如你搭建新項目時，會說“我想完成這項任務，請幫我創(chuàng)建這個工作區(qū)”。或者你發(fā)出指令，但沒安裝對應的 Go 擴展。這時智能體會主動提示： “順便提醒，需要安裝 Go 擴展嗎？”這本質上是根據用戶所處環(huán)境提供適配體驗的差異。

這其實也會影響你與智能體的交互方式。對于后臺智能體，我并不希望有太多交互。在這種場景下，我需要上下文隔離，甚至希望它能在沙箱環(huán)境中運行，這樣就不會被工具調用打擾——比如必須手動批準工具調用這類操作。但對于前臺智能體，情況則完全不同——用戶往往尚未明確具體操作目標，至少在我的觀察到中存在大量這類使用場景。人們討論代碼時，通常會進行選擇性操作，比如“幫我修改這部分”，這類指令通常很簡短。

有時用戶會啟動 NES 開始修改，卻中途放棄，轉而切換到前臺說“幫我補全”。這種情況需要快速響應，即僅處理當前文件中的剩余部分。或者當用戶創(chuàng)建新測試用例時，這些測試用例生成通常耗時不長。當然，還是要具體情況具體分析。但多數時候流程很簡單：先把任務推入后臺，稍后回來復盤。而現在更常見的作法是立刻處理，當場運行測試且隨即復盤。這樣能杜絕作弊行為，確保測試不會預先適應實際行為模式。

這兩種交互模式有著顯著差異。前臺化測試的本質是短時交互行為——討論代碼、標記代碼、收集所需上下文，這些操作都高度依賴代碼本身。而后臺智能體則不同，你必須在啟動測試時就做到精準定位，結束后若需復盤也僅是補充性操作。兩者對準備程度和預期效果的要求截然不同。

我想強調的是：說起代碼討論，指的是那些確實關注代碼的用戶，比如需要指導軟件架構、推行特定模式等工作的項目。而另一種情境則是，你壓根不在意代碼形態(tài)，而純粹以結果為導向。順便說一句，這些界限在同一個項目中也會來回轉換。

主持人：完全同意。我只關注核心架構，至于這個工具嘛……隨它去吧，我不在乎。

Kai Maetzel：沒錯，正是如此。有趣的就在這里。我認為整個行業(yè)可能還沒充分討論過：如何讓代碼庫具備 AI 就緒性？以我們的項目為例，最初的代碼提交距今已經十年往上，我們隨后在此基礎上持續(xù)迭代。要讓代碼庫具備 AI 兼容性，必須重新審視核心抽象層——這些基礎架構絕不能隨意更改。只有在系統明確提示后，才有必要加以修改。

但正如你所說，還有些外圍組件更加靈活性。比如某些工具，你可能只想在特定場景下使用。而現在，工具的應用已經越來越泛化。你甚至可能直接提交提示詞文件來生成新工具。這完全是兩種不同的概念。現在我們需要思考什么不可觸碰，什么屬于外圍領域，哪些需要關注，哪些可以忽略。大多數人非常喜歡用測試驅動開發(fā)來處理這類問題。測試對我而言就是實現環(huán)節(jié)的提示詞文件，這種模式極具靈活性，而且不同用戶的處理方式差異很大。

主持人：我很好奇，當我們討論這些不同的操作模式，以及我們在不同模式間流轉時，如何將它們串聯起來？我舉個例子，很想聽聽你的見解。我大多采用交互式工作模式：邊思考邊實踐，突然靈光乍現、想到一種可能效果很好的處理方式。

這時我會啟動預先定義的研究型提示詞。我會啟動后臺智能體，下達指令“去我的代碼庫中研究這種方案的實現效果，用 Go 語言寫份分析報告。”它會自動執(zhí)行任務，而我繼續(xù)推進主線工作。隨后我需要將結果提取回交互模式——目前我只能通過分支之類的方式實現。但我好奇 IDE 是否存在某種機制，比如把想法注入棧中，然后隨時彈出到交互式環(huán)境里。

Kai Maetzel：這里涉及的思考方式是不一樣的。而且有意思的是，我們有個原型設計，雖然還沒實現，但類似的討論也出現過——主要是關于何時切換回后臺智能體或者云智能體的問題。你的情況類似，因為這取決于輸出結果。我關注的是云智能體生成了什么，你關注的則是查看分析結果、需要審閱哪些內容等等。

你的思路是：啟動任務后，總會有需要返回處理的節(jié)點。因此需要系統發(fā)出“已準備就緒，可供審閱”的提示信號。但有趣的是，單純查看有時候還不夠，可能需要涉及全面調查。比如以交互的形式確認“已準備就緒，可前往查看”。隨后還需反饋：“已經實際執(zhí)行，結果確實良好”。所有這些環(huán)節(jié)的結果都要明確可控。

仔細想想，這跟現有技術也差不多。比如郵件管理工具之類，它們的特性都相當相似。我們產品的獨特之處在于：在與聊天窗口等交互時，雖然可以清理掉顯示內容。但你始終清楚后臺任務的位置，知道哪些已準備就緒可供查看。你不需要查看運行了什么、操作了什么，就能確定自己需要的結果已經生成完畢。

我剛才提到過一套原型設計方案，就是將這類提示直接置于標題欄頂端——它能以覆蓋層的形式實時彈出，你只需瞥一眼就能獲取信息。這是一套以提示信息為中心的布局方案。不確定我描述的這個界面最終是否采用，但無論采用何種方案，這種“周邊感知”功能絕對不可或缺，能夠實時提示其他任務已準備就緒。

當然還會有其他平替方案，畢竟我們常常過于專注于自身工具，忘記查看提示信息。但這里的核心邏輯始終不變：在需要協助時，直接點選即可。集成工具和其他工作環(huán)境會明確告知：我們與你智能體間已經建立 Slack 頻道。它還會在完成后自動彈出提示。這套方案將會無縫融入你的其他工作流程。

這方面其實很值得深入探討。有些操作需要在 IDE 里處理，有些需要通過 github.com 通過 GitHub 實現。但這種場景邊界并不重要。如果將智能體視為參與者，那其實已有許多為參與者量身定制的工具。因此我們需要拓寬解決這類問題的思維方式。

4 未來 IDE：安全、擴展與開發(fā)模式演進

主持人：非常贊同。這正好引出下一個話題——Visual Studio Code 一直以高度可擴展性、插件為核心、開放性著稱。在 AI 這個新領域下，這些特性將如何體現？是否需要做出調整？之前你提到了 MCP 服務器，這確實是交互的一種方式。這個領域是否也在發(fā)生變化？

Kai Maetzel：其中很多部分是存在交集的。一方面，過去要為 VS Code 添加新功能就必須編寫擴展程序，但現在也許可以直接調用大模型執(zhí)行部分操作。之前提到，只要提供自定義提示詞文件就能實現某項功能，據此啟動后臺研究智能體。現在我們既能添加自定義提示詞文件，又能在 IDE 交互模式下直接操作。若再配合鍵盤快捷鍵支持，瞬間就實現了無需編寫擴展的全新可擴展性。

這又要分開來看，某些場景仍需依賴擴展程序，但另一些場景下，你無需編寫擴展程序便已擁有高度靈活性。這本身就改變了可擴展性的定義。而 MCP 服務是近期出現的新概念，而且很有意思，因為 MCP 規(guī)范的覆蓋范圍極廣。但最有趣、最常用的特性，是它能實現工具調用功能。這相當于提供了完整的工具托管環(huán)境。

關于這個問題，某些方面的答案已經非常明顯，目前做斷言還為時過早。比如 Anthropic 前段時間就剛發(fā)布了相關觀點，是關于程序化調用 MCP 工具的討論。但在我看來，我們本質上還是在創(chuàng)建不同的 API。問題在于：為何不直接將其歸入 API？普通 API 與 MCP 服務器之間何必要刻意區(qū)分？很明顯，二者正在逐漸融合。MCP 就是你發(fā)布的另一種 API，僅此而已。這樣定義才合乎邏輯。

但必須承認，智能體的自主性會帶來更嚴重的安全影響。你需要思考如何實際控制這些智能體：允許哪些行為，禁止哪些行為，身份管理、智能體權限設置等所有環(huán)節(jié)都需納入考量。當前我們的做法是為部分場景創(chuàng)建沙箱環(huán)境。

但變化已經開始發(fā)生。語言這個東西理解空間很大，提到“7 號上下文”可能是要引用這部分信息，也可能想表達“7 號上下文有問題”。我舉個例子：你正在注冊網站，頁面上滾動顯示 Markdown 文件。雖然可以設置數據清理機制，但任何機制都可能被繞過。現在，你有一個 MCP 服務器能自動檢索這些文檔片段，將其放入提示詞中，之后它就開始構建并執(zhí)行代碼等等。因為整個過程會自主執(zhí)行，就必須關注數據源污染的可能。你可能得控制所有入口點，但這又會大大影響用戶體驗。

主持人：確實是這樣。本質上，所有大語言模型都是另一種形式的計算行為——它們采用詞匯編程而非傳統編程。因此任何 MCP 服務器都在向你的設備注入運行代碼。你信任它嗎？你信任所有能向其中注入內容的人嗎？

Kai Maetzel：沒錯。這正是核心問題所在。以 VS Code 為例，我們實際采用的工具審批機制會高度關注輸入 / 輸出環(huán)節(jié)。你剛才提到的正是這個環(huán)節(jié)：“你是否同意執(zhí)行這條命令？”如果 MCP 服務器在本地運行，那一般采取本地操作的形式。它可能安裝軟件包，可能會使用 UVX 或者 NPX 命令。

一旦你同意執(zhí)行這個命令，那么本次會話、本次調用中該如何處理？是否存在特定模式的命令需要批準？要做好這類配置還有很大空間。在此之后發(fā)起調用，假設指向的是遠程 MCP 服務器，那表達的就是允許調用該服務器。

但現在，算出來的響應結果將以摘要形式或原始形式寫入聊天歷史記錄。我當時就想："這該怎么辦，難道真要審查所有返回的內容？"這不現實，但又不得不做，最好是采用專門的安全模型來執(zhí)行此類監(jiān)控。總之新的難題再來了。

而且這還只是單向聊天。如果進一步轉到終端執(zhí)行命令時，難道要每條終端命令都請求許可？比方說在執(zhí)行之前，先讀懂這個終端命令的含義。如果終端命令確實安全，就執(zhí)行它。同時也要賦予用戶控制權。比如企業(yè)環(huán)境中的用戶可能需要考慮哪些工具無需每次顯式授權即可調用，這跟我們在云端租用的虛擬機上運行特定場景的情況截然不同。

主持人：那我就好奇了，這是否意味著未來所有開發(fā)都將轉移到容器或虛擬機內部進行？

Kai Maetzel：如果把邏輯推演到底，我認為你的猜測很有道理。但即便如此，仍需管控容器的輸入輸出。比如獲取網頁時——比如當你說“我需要最新版本的 Node”時，系統就會立即在終端執(zhí)行安裝命令。

我們都希望確保安全，希望能夠關上大門。但我的觀點是，即便將這些內容封裝在容器中，問題依然存在，只是這里可以更有效地控制環(huán)境。但我們仍需思考如何打造良好的用戶體驗，如何讓這一切變得清晰易懂等等。先澄清一點，我們之前討論的所有問題，都只限于涉及一、兩個后臺智能體。但現在需要將這個數量乘以 100，那問題性質就截然不同了。我們必須全面解決這些問題。

以云端智能體為例，假設你在 GitHub 上整理代碼，將大量問題分配給 Copilot，或者啟用了自動分類功能。你會說：“幫我對某些問題進行自動分類。”之后你收到這些 PR 請求，接著需要審核這些 PR。審核五到十條還好，具體取決于規(guī)模。但如果每天要審核 200 條的話……

主持人：過去這半年，我審核的代碼量多到記不清了。簡直荒謬，太瘋狂了。我正好引出了我想在最后探討的方向——咱們這期訪談也差不多快結束了——你認為未來一、兩年間，這個領域會如何發(fā)展？咱們別展望太遠，因為正如你強調的，變化實在太快。但 VS Code 以及整個代碼編寫管理生態(tài)會怎樣？我這么說是因為，或許我們真正要做的不是編寫代碼，而是管理代碼的生成或編寫過程。你認為未來會如何發(fā)展？有哪些新事物即將出現？

Kai Maetzel：我不敢說自己能預見兩年后的景象，因為我們可能很快就會抵達某個意想不到的境地。但隨著對交互模型這一活躍研究領域的探索，我希望能嘗試不同實現方式，觀察用戶實際接受度。比如使用比例如何變化。初期用戶會頻繁使用 Tab 鍵切換，如今比例明顯下降。當然，這取決于用戶經驗水平和代碼實現的具體環(huán)節(jié)。正如你所說，有些功能是絕對不可觸碰的禁區(qū)，而其他部分則存在靈活性。所有這些因素都在影響交互模型的設計。

這種變化會始終存在，但我們終將找到解決方案。不同領域會涌現出各種新思路。我認為核心問題在于如何有效利用智能體。這同樣是個難題，因為人們總說“我們可以并行運行多個智能體”。沒錯，但關鍵是在哪種場景下使用？以 VS Code 項目為例，到時候我們每月可能得處理 3000 個問題。

主持人：這里說的是兩年后的情況，對吧？

Kai Maetzel：差不多，每月 3000 個問題已經非常夸張了，這還是僅基于人工處理的情況。現在加入 AI 后，這個數字必然要提升。那么并行處理能力能提升多少？因為存在不同執(zhí)行模塊，作為團隊成員，每人可以負責一部分作為專屬任務，每個標簽下可以運行多個智能體，這沒問題。但若要創(chuàng)建新功能，而非在后臺運行多個任務，那復雜度就完全不同了。因為按步驟一、二、三線性推進更容易理解，而“步驟 1 之后還有 2A、B、C、D”這種分支邏輯明顯要復雜得多。

主持人：這會觸及認知上限的。

Kai Maetzel：完全正確。作為人類，哪怕能保證產出代碼都擁有良好質量，我們也幾乎是整個鏈條中最薄弱的環(huán)節(jié)。這種趨勢已然顯現，關于如何真正駕馭這種級別的并行性，我認為還有很多工作要做。

我認為這是最終必然要面臨的局面，想想現實世界中那些大規(guī)模的運維場景：當你需要進行變更時，比如要引入某個新的垂直功能，卻發(fā)現它實際涉及數十個倉庫、不同服務的部署，以及各種相關環(huán)節(jié)。這種情況下，你幾乎必然要制定計劃，類似項目規(guī)劃，還需要部署智能體。其中一種方案是采用單倉庫模式，僅運行一個智能體。

但更可能的情況是保持分布式架構，多數項目都更需要這樣的處理方式。此時需要部署多個智能體實例，由主智能體向其他智能體分配任務。這些智能體在運行時需要相互通信，需要匯報當前位置。匯報內容不能再是簡單的 Markdown 文檔，可能需要追溯到“真正的變更追蹤器”、“關聯問題列表”等環(huán)節(jié)，甚至需要在規(guī)劃看板上查看才能理解全貌。

這涉及諸多環(huán)節(jié)，而人始終是鏈條中最薄弱的環(huán)節(jié)。成功關鍵在于透明度，比如智能體的實際進展如何等等。我認為這個領域還有大量工作需要推進。還有另一個方面，這也是我個人最困擾的點：人們總愛夸大其詞說“現在隨時隨地都能編程。” 沒錯，想到創(chuàng)意就用手機輸入發(fā)送，快速查看原型效果，確實存在這類場景。

但這只是替代方案，而且只是換了個平臺。我不太理解不用筆記本電腦，偏要用手機或者其他移動設備，到底有多大的意義。或許語音功能在這方面能發(fā)揮重要作用，但就個人來講，我絕不會在手機上審查代碼。

主持人：沒錯，我正想說，快速檢驗原型效果是很棒，但在手機上審查代碼實在痛苦。

Kai Maetzel：沒錯。我再聊最后一點。其實仔細想想也不意外，我們喜歡創(chuàng)造性工作，但哪些環(huán)境更適合發(fā)揮創(chuàng)造力？我發(fā)現我們仍停留在非常傳統的協作模式。我們當然可以和 AI 助手建立 Slack 頻道進行互動，但更重要的是，人類真正喜歡的是哪種方式？我們喜歡圍著儀表板協作，聚在一起共同完成任務，桌面上則擺放著材料供我們討論時翻閱。這類場景該如何復現？

大家還記得微軟曾推出過的 Studio PC 吧，屏幕很大而且可以平放。現在你可以用類似設備在屏幕上繪圖，尤其在 UI 開發(fā)時，直接在屏幕上勾勒設計方案，邊畫邊問智能體： “這個元素該往這邊挪點，你覺得怎么樣？”突然間，你就成了絕對的交互中心，人類最喜歡這種被關注的感覺了。這種交互能釋放大量多巴胺。它還能通過語音、多模態(tài)輸入等方式獲得強大的 AI 支持。這個過程可以涉及代碼，也可以不涉及，只是在幕后確實由代碼來支撐。總之這種體驗會非常好，我能清晰預見這種模式。未來我們也必將看到更多類似應用涌現。

主持人：我覺得這是個絕佳的切入點。

https//softwareengineeringdaily.com/2026/01/06/vs-code-and-agentic-development-with-kai-maetzel/

聲明：本文為 InfoQ 前線整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

OpenClaw 出圈，“養(yǎng)蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態(tài)迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發(fā) / 運維流程并形成穩(wěn)定收益。

針對這一系列挑戰(zhàn)，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態(tài)實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業(yè)如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。