主持人：
Kevin，歡迎來到我們的節目。

Kevin Scott：
不用謝。

主持人：
謝謝你來。一件很有意思的事是，我去年也訪問過你。你當時說了兩件非常重要的事情。一個是——代理（agents）將會無處不在。

主持人：
你說的這件事真的成真了，而且來得非常快。還有一件事，我注意到去年你特別強調「規模定律」（scaling laws），對吧？

主持人：
當時你展示了很多圖表，說我們正在建造大規模基礎設施，訓練更大的模型，而且每兩年性能就會有一次飛躍。但今年，你的重點似乎更多放在「代理網絡（Agentic Web）」上。發生了什麼變化？從去年到今年，我們學到了什麼？

Kevin Scott：
是的，我覺得發生了很多變化。其中一件事是，去年很多人還處在一種懷疑狀態中，他們在懷疑「規模定律」是否還能繼續有效。而事實上，我們年復一年已經證明，它們依然有效並且運作良好。所以現在已經不再需要向人們重複這一點了。

Kevin Scott：
另一件事，說實話，是模型的推理能力已經超前於我們實際應用這些模型的方式。我最近一直在談一個概念，叫做「能力懸空」（capability overhang）。

我認爲，我們整個行業現在需要共同努力，去彌合模型實際能做的事情和我們交付給用戶的產品之間的差距。這也是爲什麼在今年的 Build 大會上，「規模定律」不像去年那麼吸引人的原因之一。

Kevin Scott：
還有一點我們發現了：隨着過去一年代理數量的爆發式增長，以及用戶在這些代理中花費時間的增加，我們意識到，除了「推理能力」之外，還有很多其他方面的問題需要解決，才能讓代理真正變得有用。這也是我今天在 Build 大會主題演講中提到的重點之一：我們需要更好的代理記憶系統。

Kevin Scott：
目前的代理記憶受限於許多方面，它們更像是一次性的、事務性的——你用它完成某個任務，期間記憶是連貫的，但這個記憶很可能會在下次交互時完全消失，這就使得我們很難將更復雜的任務委託給它們。

Kevin Scott：
而且還有一個核心問題：如果代理要變得有用，它們就必須能夠替你採取行動，能夠使用工具，在系統中作出改變，訪問豐富多樣的信息源。

要實現這些，我們需要一個生態系統，它應當像互聯網那樣：如果你是信息源，你已經有了網站、有了 API，那麼你必須弄清楚怎麼把這些資源接通，讓代理能與之通信，並且要讓各方的激勵機制協同一致，使他們願意參與到這個「代理網絡」中來。

Kevin Scott：
所以我認爲這才是今年最大的故事——我們看到了真正進展的曙光，比如 MCP 這樣的超級簡單、開放協議，在代理網絡中扮演的角色就像 HTTP 在互聯網中一樣。還有像 NL Web 這樣的標準，它在「代理網絡」中扮演的角色，就類似 HTML 在網頁世界中的作用。

Kevin Scott：
我覺得你將會看到這些系統越來越多地採用簡單、可組合、可層疊的結構，開放社區將會非常活躍，最終推動代理真正實現能力的落地。

主持人：
那我總結一下我聽到的意思：現在我們已經有了代理（agents），而且它們開始真正發揮作用了，對吧？而要讓這些代理變得強大，它們就需要訪問權限。

主持人：
它們需要能夠訪問互聯網上的各種資源、你電腦上的內容，等等類似的信息。也就是說，你基本上需要建立起一套協議和流程，來讓代理可以訪問這些東西，對吧？

主持人：
所以你現在關注的是整個技術堆棧的不同層級——比如說運行時層面，你們在那兒構建記憶系統、其他組件；然後還有像 MCP（memory coordination protocol）這樣的協議，它能把代理連接到更廣闊的互聯網世界，從而獲取信息，讓信息流入代理系統中。

主持人：
那我想問一下，**這件事對微軟來說爲什麼重要？**你們希望在這個生態系統裏扮演什麼樣的角色？

Kevin Scott：
嗯，我覺得這裏面有兩點，也可能是三點特別重要。

第一點是，我們自己在做代理。而我們做的這些代理要對用戶真正有用，就必須解決這些底層問題。就算你把範圍縮小到企業級代理，作爲微軟的 CTO，我一直在推動的一件事就是：我希望我們公司內部所有系統都採用統一的標準協議，能和我們內部構建的代理對話。

Kevin Scott：
這樣我們才能避免把整個世界暴露在所謂「康威定律」（Conway’s Law）之下。你知道，康威定律是軟件架構裏一個非常有趣的現象。

康威說，一個系統的結構往往會反映出開發該系統的組織結構，比如編譯器的階段數通常由負責這些部分的團隊數量決定。

主持人：
沒錯。

Kevin Scott：
所以你想象一下，如果你在微軟這樣的大公司內部開發東西，你肯定不希望你造出來的代理，其結構完全是按照你的組織結構拼出來的。

但現實中如果你沒有通用的協議和標準服務，這樣的「組織圖產品」就會反覆出現。作爲工程師，看到那種低效開發場景，真的很讓人抓狂。

Kevin Scott：
但我認爲，更重要的是，如果你真正去想象代理能夠做什麼、普通用戶希望它們變得多有用——你就會發現，我們需要像當年互聯網興起時那樣的一系列變革再次發生。我現在就能看到這一幕的雛形，比如 MCP 協議，它就是一個非常好的例子。

Kevin Scott：
它是一個非常簡單但關鍵的協議，解決了一個非常重要的問題——不僅是爲那些構建代理和平台基礎設施的人服務，也同樣幫助了系統的最終用戶，讓他們的體驗變得更加有用。它還爲那些服務提供方提供了機會，比如有人可能會說：「我也想參與到這個新型的大網絡裏來。」

但現在的問題是，很多人以前知道怎麼去連接某個服務、怎麼構建服務，但如今他們面對的是一群代理，坐在那裏思考：「我該怎麼把我的系統接進來？這對我到底意味着什麼？」

Kevin Scott：
甚至從商業模式的角度來說，他們也會想：我爲什麼要接入這個系統？它對我到底有什麼價值？

所以第二點就是——我們希望讓自己構建的代理變得更有用。

Kevin Scott：
第三點是，作爲一家平台型公司，這一點甚至比我們自己要寫的代理更重要。微軟已經在構建平台技術這條路上深耕了五十年，我們想要確保，當這個全新的「超級網絡」興起時，我們能夠幫助解決其中出現的問題。

主持人：
是啊，看到你們現在在 MCP 上投入這麼多，並把它整合進整個 Windows 系統，真的很酷，很厲害。這讓我想到一個問題——我最近聽到一些人在討論 MCP，他們開始關注它的安全模型問題。

主持人：
我很好奇你是怎麼看這個問題的。因爲你前面提到過很多 MCP 技術棧和互聯網技術棧之間的類比。而我們知道，互聯網是有一套完整的安全機制的，比如「同源策略」（Same-Origin Policy），它確保了網站在執行代碼時只能操作自己域名下的數據，對吧？但 MCP 目前似乎還沒有類似的機制。所以你覺得，什麼樣的安全模型才是適合 MCP 的？

Kevin Scott：
嗯，說實話，我也不敢說我完全知道什麼才是「正確」的安全模型。但 MCP 有一點很有趣，就是它的設計極其簡潔明瞭，這其實使得整個社區可以相對容易地就這個問題達成共識。

Kevin Scott：
我們在企業層面上確實有很多非常重視的需求，我們也和 MCP 團隊合作得很好，正在推進相關工作。

Kevin Scott：
比如說，我們需要讓代理具有「身份」——這樣我們才能建立起權限系統。你可以定義：某個代理是代表某個用戶在操作，然後它就有權訪問系統中某些資源。

Kevin Scott：
甚至代理本身可以主動查詢多個系統，然後說：「這是我想完成的一件事，要實現這件事，我需要訪問以下這些系統。那我需要獲得哪些權限才能做這件事？」

Kevin Scott：
它可以向被委託給它的用戶請求授權，說：「你能不能給我訪問這些資源的權限，這樣我才能替你完成你交代的任務？」是或否。

然後系統管理員也需要有權限來審查，比如：「我是否允許這些操作發生？」所以，這整個流程雖然並不「簡單」，但其實在 MCP 架構上實現起來是可行的、邏輯清晰的。

Kevin Scott：
而關鍵在於：我們應該以開放的方式來做這件事。我們並不希望這些機制是專屬於微軟代理或微軟系統的——我們真正需要的是讓它像互聯網一樣運作的生態系統。

主持人：
對我來說，這其實是個很有意思的問題。我覺得現在圍繞 AI 的發展，有兩種可能的模式或者「市場路徑」（Go-to-Market）正在浮現，而你們微軟似乎都在關注這兩個方向。

一種是所謂的「垂直一體化」模式，在這種模式下，你控制模型、應用、整個上下游——一切都在你手中。

主持人：
而這種模式的一個好處是：安全性可以得到很強的保障。就像蘋果的 App Store 或 iPhone 模式，你可以在多個層面上強制安全策略。

但另一種則是「開放模型」——你犧牲一部分控制權和安全性，但能換來更強的創新活力，因爲沒有中心化的權威機構去限制開發者。

所以我想問的是，你們在微軟是怎麼思考要走哪條路的？你們是怎麼做出這個決策的？

Kevin Scott：
是的，你看，這確實是很多人現在在討論的一個核心問題——但我覺得，那可能是一個僞命題（false dichotomy）。

你知道，在這些開放系統中，它們的特點是「無需許可」（permissionless）。這種開放式創新的能力，確實帶來了巨大的優勢。對我個人來說，現在最讓我興奮的一件事就是：你可以不經任何人批准就去創新、去構建產品，不需要別人給你發許可，不需要通過什麼中介流程才能把你的作品推向世界。

你不再需要通過一堆複雜的守門人機制，在你這個有想法的人與那些可能真正從中受益的人之間設下重重阻礙。

Kevin Scot：
我覺得我們這幾年建立起來的那些「中間層」，其實並沒有爲最核心的兩方帶來多少價值：一邊是辛辛苦苦做出東西的人，另一邊是願意爲這些成果付出注意力、金錢或其他資源的用戶。

這就是爲什麼我對開放系統特別興奮，也正是我們在做戰略選擇時的重要原因之一。

Kevin Scott：
但我也認爲，在這些系統中，其實是有辦法實現強健安全性的。我們可以藉助 AI 本身的一些能力，構建出更智能的安全模型。

比如說，你運行的代理可以照顧到你個人的安全需求——哪些信息你願意分享，哪些你不願意；它還能做風險評估。

我舉個實際例子：今天早上我正準備上臺演講的時候，突然收到一堆郵件，因爲我是我妻子的備用安全賬戶。

有人在她賬戶上嘗試篡改兩步驗證（2FA）設置。我第一反應是發短信給她，而不是發郵件——因爲我擔心她的郵箱可能已經被未經授權的第三方訪問了。

Kevin Scott：
我發信息問她：「你是不是在改配置？」她回覆：「是的，是我。」

所以你可以想象，如果有一個代理可以接入你多種通信渠道，監測到這種異常行爲，並調用各種資源進行「三角校驗」，判斷這些行爲到底是合法的還是非法的，那將是非常有用的。

所以我認爲，兩種模式是可以共存的。並不是說非得二選一——就像你剛才設想的那樣。

主持人：
這很有道理。我還有一個特別好奇的問題是——現在看來，軟件工程正在發生根本性變化，對吧？

而你是一個在軟件工程領域深耕多年的老兵，我覺得你也很重視「工藝」本身——製作事物的技藝。

我們剛才聊到你平時做陶藝、做包，喜歡親手參與制作的過程。我覺得很多人對「用代理寫代碼」有點牴觸，覺得這樣會削弱那種「手工打造」的感覺，雖然我並不完全同意這個觀點。

但我還是很想知道，作爲一個真正關心編程工藝的人，你怎麼看待未來的「代理編程」？

Kevin Scott：
我先說一句，我真的很欣賞「我的人」——我這裏說的「我的人」，指的是廣義的創作者群體。

包括軟件工程師、機械工程師、木工、陶藝師等等這些人。我們都是從零或者原材料開始創造新東西的人。

Kevin Scott：
如果你真的熱愛你的工作，你一定會對怎麼做、用什麼工具、用什麼材料、如何組合這些細節有非常強烈的主張。這是你成爲真正優秀從業者的必備條件。

但有趣的是——人們的觀點五花八門。

正如你剛才提到的，我做這行已經很久了——我寫第一個程序的時候只有 12 歲，也就是說我編程已經有 41 年了。

Kevin Scott：
如果你在一個領域堅持得夠久，你就會看到：這並不是過去四十年來軟件開發第一次經歷巨大變革。每次這種變革發生時，人們都會對其含義有非常強烈的反應。

但現實是，人們是有選擇權的。

我現在仍然喜歡用文本編輯器。說實話，我可能不該說這個，因爲我們公司做了 Visual Studio Code（笑），但我就是一個老古板——我還在用 vim。

Kevin Scott：
至少我會用 vim，但我最愛的還是那種古早的編輯器。我就是不願意換別的工具。

儘管我知道，這在某種程度上已經降低了我的效率，但我還是出於「自主選擇」的理由堅持使用它。

但在我做的其他項目中，比如不管是軟件還是其他東西，有時候我也會說：「這裏的重點不是怎麼做，而是我要達成的目標。」

所以我會選擇最強大、最方便的方式去實現它——不管別人會不會因此嘲笑我。

Kevin Scott：
這種情況無處不在。比如我當木工的時間幾乎跟我寫程序一樣久。

我還記得我十幾歲那會兒，圈子裏最大的話題是：「你如果用了電動工具，你還算是真正的木工嗎？」

「真正的木工只用手工工具！」

Kevin Scott：
今天這種爭論仍然存在，不過換成了：「你用了 CNC（計算機控制的數控工具），你還算真正的木工嗎？」

我覺得這種討論本身就很有意思，但最終大家做出不同選擇，是因爲他們的價值觀不同。

如果你更重視過程，你可能會做出完全不同的選擇；而如果你更看重結果，你就可能用別的方式。

主持人：
我覺得類似「你算不算是真正的木工」「你是不是個真正的程序員」這種問題，說到底其實是在說：「只有按照我成長時的方式去做，你才是真正的XXX。」這其實是一種有偏見的說法。

Kevin Scott：
對，是這樣。但現實是——這個世界的情況太多樣化了，對吧？

所以我要說的是：我絕不會告訴任何人不要對自己的技藝有強烈的主張。你儘管有你的堅持，那很好！

但如果說我有什麼建議的話（這不是命令，只是我個人發現有用的建議），那就是——當工具發生變化時，要保持開放的心態。

Kevin Scott：
我都數不清多少次了，有些新的技術出現在其他「非軟件」的創作領域，我一開始都會下意識地抗拒——比如說我當時對 3D 打印機完全提不起興趣，我拖了很久才去學怎麼用它們。

現在我真的後悔了，因爲它們幾乎對我做的所有事都非常有用。出於種種複雜的原因，我沒有讓自己產生好奇心，這是我自己的問題，也確實有點奇怪。

所以我的建議就是：保持好奇，去嘗試。如果某樣東西適合你，那就用它；如果不適合，也無妨。

主持人：
沒錯。那麼你怎麼看「軟件工程代理（software engineering agents）」的未來？

會不會出現那種「一個代理統治一切」的局面？還是說我們會同時使用很多具有不同風格的代理？你認爲這個生態系統會如何發展？

Kevin Scott：
我認爲將來一定是有很多不同類型的代理。這是好事。

我們當然會在 GitHub Copilot 以及我們正在開發的 GitHub Agent 上非常努力，希望成爲很多開發者首選的工具，因爲我們想讓它真的對大家有用。

但要說全世界的開發者都統一使用某一個工具來完成工作中的關鍵部分，我認爲那不現實。

Kevin Scott：
成爲一個開發者的樂趣之一，就是你有權選擇工具。你可以嘗試各種東西，做一些看起來「非理性」的事，也可以選擇完全理性的方式。

這是我在過去四十年程序員生涯中始終觀察到的一件事：人們不斷更換自己的工具。總是在變化。

主持人：
那你有沒有想過：這些代理會在哪些維度上有所不同？

Kevin Scott：
我覺得最關鍵的區別，可能會出現在產品設計者的思維方式上。

現在我看到最有意思的一些初創公司，他們並不是靠搞出一套全新的基礎設施來創新的；他們創新的方式是：他們對某個用戶問題的理解，比任何人都更深入。

然後他們基於現成的基礎設施，或做些微調，就能以世界級水準來解決那個問題。這種方式，才是我們現在真正需要的。

Kevin Scott：
這也會推動代理多樣性的形成——哪些代理被用來解決什麼問題，最終都會受到這個維度的驅動。

而且說實話，現在你更容易對用戶的問題形成這種「細緻入微的理解」，也更容易拿起各種工具嘗試去解決這些問題。

所以我們會看到大量公司、團隊去打造各種東西來嘗試解決不同的需求。

Kevin Scott：
哪怕在「軟件開發工具」這個領域都已經開始瘋狂了——過去一年冒出來的工具簡直數不過來。

而且這些工具都挺有趣的，各有各的特點。

對於像我們這樣的軟件工具開發公司來說，這確實壓力很大，因爲你要應對那麼多創新和變化。

但從技術角度來看，這真的太有意思了。

我們發現：只要你對用戶的需求有某種細膩的認知，就總會有人願意嘗試你的解決方案。尤其是那些有高容忍度和高興趣度的用戶。

主持人：
是啊。我們時間快到了，但我還有個問題。

假設一年之後我們又在 Build 大會上坐下來聊，你覺得：現在的一些熱門話題或大問題，一年後會變得不再重要？而一年後什麼會成爲真正重要的討論焦點？你有哪些預測？

Kevin Scott：
我覺得現在那些還在堅持說「這項技術還沒準備好」的人——比如說：「我試過了，但稍微有點貴」或者「功能上還差一點點」——如果他們把這些當作不行動的藉口，那他們很快就會被遠遠甩在後面。

因爲這些問題都會隨着時間變得微不足道：技術每年都會變得更便宜、更強大。

Kevin Scott：
我覺得在 2025 年，這個觀點其實已經不需要「遊說」了。過去確實有很多人大聲說：「技術進展很快就會停滯，大家都會失望。」

雖然現在還有人這麼說，但我覺得已經沒什麼人認真聽他們的了。畢竟你聽這些「唱衰者」的話，又能獲得什麼呢？你是在賭失敗，而「賭失敗」和「賭樂觀」之間的成本差異，其實非常大。

Kevin Scott：
我認爲接下來我們會看到，人們用代理去解決的問題會越來越複雜、越來越有雄心。同時，「代理網絡」會越來越完整，連接越來越充分；模型的推理與規劃能力也會變得更強。這將促使我們從現在的「同步交互」模式，進入到一個更強的「異步交互」時代。

Kevin Scott：
現在的交互方式是：你坐下來，想着要完成一件事，然後給代理發出指令，等它返回一個結果，然後你基於那個結果再操作。

但到了明年，你可能會看到這樣的使用方式：「嘿，去幫我搞定這件事。」

然後代理會花時間去處理：它會調用很多外部系統，它會去整合信息，它會反覆迭代，它會不斷處理、彙總、推進，最後，在一個非即時但有深度的時間之後，代理會告訴你：「我已經幫你推進到這一步了，接下來輪到你了。」

主持人：
聽起來真是我想活在的未來。

Kevin Scott：
我也這麼想，真心的。

主持人：
好吧，Kevin，非常感謝你今天來參加節目。真的非常精彩的談話。

Kevin Scott：
很高興能和你聊這場對話，我也非常享受，謝謝你邀請我來。