不到百萬級，看不見 MCP 的真實(shí)問題：創(chuàng)始人親述這瘋狂的一年

整理 | Tina

一年前，MCP 還只是一個(gè)“把模型連到工具”的開源協(xié)議；一年后，它已經(jīng)沖進(jìn)了一個(gè)很少有協(xié)議能抵達(dá)的位置：事實(shí)標(biāo)準(zhǔn)。

在這場一年狂飆的親歷者之一——MCP 聯(lián)合創(chuàng)作者、核心維護(hù)者 David Soria Parrra 看來，最戲劇性的分水嶺發(fā)生在四月前后：當(dāng) Sam Altman、Satya Nadella、Sundar Pichai 先后公開表態(tài)，Microsoft、Google、OpenAI 都將采用 MCP，“大客戶”突然從 Cursor、VS Code 擴(kuò)散到整個(gè)行業(yè)。

這一年，MCP 從本地 “桌面玩具”，一路演進(jìn)到遠(yuǎn)程 server、認(rèn)證機(jī)制、面向企業(yè)可用的 OAuth 重構(gòu)，再到 11 月引入 long-running tasks，把深度研究、甚至 agent-to-agent 交互變成協(xié)議的一等公民。David 的總結(jié)很直接：“這一年真的非常瘋狂。”

這段對談里，David 也很坦率地復(fù)盤了 MCP 這一年的取舍：做對的，是死磕標(biāo)準(zhǔn) HTTP；踩坑的，是把關(guān)鍵能力做成了‘可選項(xiàng)’，結(jié)果客戶端大多不實(shí)現(xiàn)，雙向能力被削掉。

更現(xiàn)實(shí)的問題是擴(kuò)展性：規(guī)模一上來，多實(shí)例、多 Pod 下同一段交互可能打到不同機(jī)器，不得不用 Redis 之類的共享存儲來“拼狀態(tài)”，請求量到百萬級就開始吃力：“當(dāng)規(guī)模一上來，這件事一點(diǎn)都不好玩。”“一些公司——比如 Google、Microsoft——他們在用 MCP 的時(shí)候，規(guī)模已經(jīng)大到我不能公開具體數(shù)字，但可以說是百萬級請求。到了這個(gè)量級，這就真的成了一個(gè)問題。”

以下是播客內(nèi)容整理，略有刪節(jié)：

1 MCP 的一年：從發(fā)布到行業(yè)事實(shí)標(biāo)準(zhǔn)

主持人：要不你先簡單講講 MCP 的發(fā)展情況，以及之前為什么決定把它捐贈給基金會？接下來我們再系統(tǒng)回顧 MCP 這一年的演進(jìn)，然后再請基金會的其他負(fù)責(zé)人加入，聊一些更宏觀的內(nèi)容。

David Soria Parrra（MCP Co-creator）：如果回到一年前，MCP 剛發(fā)布的時(shí)候，其實(shí)誰都沒想到它會在這一年里迎來如此瘋狂的增長。

老實(shí)說，這一年感覺像過了一個(gè)世紀(jì)。一開始是在感恩節(jié)和圣誕節(jié)前后，很多開發(fā)者開始自發(fā)地用 MCP 搭東西。隨后，像 Cursor、VS Code 這樣的“大客戶”開始出現(xiàn)。

真正的拐點(diǎn)出現(xiàn)在四月左右——當(dāng)時(shí) Sam Altman、Satya Nadella、Sundar Pichai 等人陸續(xù)公開表示，Microsoft、Google、OpenAI 都會采用 MCP。那是一個(gè)非常明顯的“分水嶺”。

與此同時(shí)，我們也一直在推進(jìn)協(xié)議本身的演進(jìn)。

最初，MCP 幾乎只支持本地使用：你在桌面上跑一個(gè) MCP server，通過本地 stdio 和客戶端通信。但到了今年三月，我們開始推進(jìn)“遠(yuǎn)程 MCP server”——也就是如何通過網(wǎng)絡(luò)連接 MCP，并且第一次引入了認(rèn)證機(jī)制。到了六月，我們又對這套認(rèn)證方案進(jìn)行了比較大的修訂，尤其是為了讓它真正適用于企業(yè)場景。

我們非常幸運(yùn)，在三月到六月這段時(shí)間里，有真正做 OAuth 標(biāo)準(zhǔn)的行業(yè)專家，直接參與進(jìn)來，幫我們把一些關(guān)鍵細(xì)節(jié)“拉正”。我們也在這段時(shí)間里大量投入在安全最佳實(shí)踐上。

到了 11 月底，我們發(fā)布了新一輪重要版本，引入了長時(shí)間運(yùn)行任務(wù)（long-running tasks）這一關(guān)鍵原語，用來支持深度研究類任務(wù)，甚至是 agent-to-agent 的交互。

現(xiàn)在的感覺是：MCP 的基礎(chǔ)已經(jīng)非常扎實(shí)了。接下來還有一兩個(gè)關(guān)鍵原語和可擴(kuò)展性問題需要解決，然后協(xié)議整體會進(jìn)入一個(gè)相對穩(wěn)定的階段。

說實(shí)話，這一年真的非常瘋狂。

主持人：你剛剛提到 agent-to-agent，那是不是也涉及 A2A 協(xié)議？在 Agentic AI Foundation 成立時(shí)，有沒有討論過把其他協(xié)議也納入進(jìn)來？

David：老實(shí)說，這幾乎是必然會發(fā)生的討論。我們當(dāng)然討論過市場上其他協(xié)議，比如一些支付協(xié)議之類的東西。但在決定成立基金會時(shí)，我們有兩個(gè)非常明確的原則：

第一，我們想從小開始。這是 Anthropic 第一次參與開放源代碼基金會，一切都是新的。我們希望先在一個(gè)相對可控的范圍內(nèi)學(xué)習(xí)如何把這件事做好，并且和 OpenAI、Block 一起，把基金會的節(jié)奏掌控住。

第二，在協(xié)議層面，我們非常在意“事實(shí)標(biāo)準(zhǔn)（de facto standard）”。目前來看，真正已經(jīng)具備廣泛采用度的協(xié)議，只有 MCP。其他協(xié)議還沒有“走到那一步”。當(dāng)然，如果未來某個(gè)協(xié)議發(fā)展到那個(gè)階段，并且在功能上是互補(bǔ)的，我們是完全開放的。

在應(yīng)用層，我們會更靈活；但在協(xié)議層，我們不希望一個(gè)基金會里同時(shí)維護(hù)五個(gè)做同一件事的通信協(xié)議。

主持人：你現(xiàn)在在基金會和 MCP 之間，是不是有點(diǎn)“戴兩頂帽子”？

David：確實(shí)如此，但我主要精力仍然在 MCP 上。基金會本質(zhì)上是一個(gè)“保護(hù)傘”，它最重要的作用是保證項(xiàng)目的中立性。至于基金會預(yù)算怎么用、辦什么活動，這些相對來說反而是“比較枯燥”的部分。

在 MCP 的技術(shù)治理上，其實(shí)并沒有發(fā)生本質(zhì)變化。我依然是核心維護(hù)者，繼續(xù)推動協(xié)議演進(jìn)。

另外，我也會參與基金會的技術(shù)指導(dǎo)委員會（TSC），負(fù)責(zé)判斷：哪些項(xiàng)目適合進(jìn)入基金會？它們是否被良好維護(hù)？是否有真實(shí)采用？是否具備長期價(jià)值？

我們不希望基金會變成一個(gè)“項(xiàng)目垃圾場”。我知道有些基金會最終會落得什么下場。

主持人：這一年 MCP 發(fā)布了四次規(guī)范更新，節(jié)奏非常快。尤其是三月和五月那次，引入了 HTTP Streaming 和認(rèn)證。要不要給大家系統(tǒng)梳理一下？

David：HTTP Streaming 那次更新非常關(guān)鍵，也是用戶呼聲最高的一次。我們在 11、12 月就已經(jīng)意識到：下一步一定是遠(yuǎn)程 MCP，而遠(yuǎn)程就繞不開認(rèn)證。

MCP 的一個(gè)特點(diǎn)是：它在每一層都非常“有主見（prescriptive）”。比如，在客戶端和服務(wù)端互不認(rèn)識的情況下，認(rèn)證該怎么做，我們希望只有“一種正確方式”。

三月版本里，我們做了一版認(rèn)證方案。現(xiàn)在回頭看，它“還行”，但確實(shí)有問題。說白了，是我對企業(yè)認(rèn)證場景理解不夠。MCP 的一個(gè)核心優(yōu)勢，是它的社區(qū)：當(dāng)我不懂的時(shí)候，會有真正懂的人站出來幫我。

主持人：三月那版認(rèn)證，主要問題出在哪？

David：OAuth 里有兩個(gè)核心角色：

• 身份提供方（Authorization Server / IdP）：發(fā)放 token

• 資源服務(wù)器（Resource Server）：接收 token 并給相應(yīng)的資源作為回報(bào)

在第一版 MCP 認(rèn)證規(guī)范里，我們把這兩個(gè)角色合并進(jìn)了 MCP server。對于創(chuàng)業(yè)公司來說，這沒問題：你自己有賬號體系，把 MCP server 直接綁在用戶賬號上，完全可用。但在企業(yè)環(huán)境里，這根本行不通。企業(yè)幾乎總是有一個(gè)中央身份系統(tǒng)（比如 Google 登錄、企業(yè) SSO），用戶每天早上只感知到“我登錄了一次”，但背后其實(shí)是 IdP 在工作。

所以在六月的規(guī)范中，我們做了一個(gè)關(guān)鍵調(diào)整：明確把 MCP server 定義為資源服務(wù)器，和身份系統(tǒng)解耦。我們對“怎么拿 token”依然有建議，但不再強(qiáng)行綁定在 MCP server 里。同時(shí)，也補(bǔ)齊了動態(tài)客戶端注冊等細(xì)節(jié)。

主持人：那 agent 代表用戶去操作，比如幫我用 Linear、Slack，這個(gè)問題現(xiàn)在解決了嗎？

David：OAuth 本身是一個(gè)非常“以人為中心”的協(xié)議。它只定義：如果你沒有 token，該怎么拿 token。一旦你有 token，后面就只是把它放進(jìn) Bearer Token 里而已。

我們目前并沒有對 agent-to-agent 或 agent 代表用戶的認(rèn)證方式做強(qiáng)約束。在企業(yè)內(nèi)網(wǎng)、封閉環(huán)境里，大家已經(jīng)可以通過 workload identity 等方式做到。但如果客戶端和服務(wù)端彼此不認(rèn)識，我們目前還沒有一個(gè)“完美方案”。

主持人：你們從本地服務(wù)器（比如基于 stdio 的方案），一路演進(jìn)到可流式的 HTTP。在這個(gè)過程中，有哪些經(jīng)驗(yàn)教訓(xùn)值得分享？有沒有什么后悔的地方，或者對其他人有什么建議？

David：關(guān)于傳輸層這件事，其實(shí)有一個(gè)討論，從過去幾年一開始就從未停過。

就在最近兩天，我們還在 Google 的辦公室里，和一群來自 Google、Microsoft、AWS、Anthropic、OpenAI 的資深工程師坐在一起，專門討論：到底需要做什么，才能把這件事真正、徹底地打牢？

回到今年三月，當(dāng)時(shí)我們希望引入一種新的傳輸方式，它能夠盡量保留我們在標(biāo)準(zhǔn) IO（stdio）里擁有的很多特性。因?yàn)槲覀儺?dāng)時(shí)——而且直到今天我依然堅(jiān)信——MCP 不只是為了簡單的請求 - 響應(yīng)，它還應(yīng)該支持 Agent。而 Agent 天生就是某種程度上“有狀態(tài)”的，它需要在客戶端和服務(wù)器之間進(jìn)行一種長期存在的通信。

所以，我們一直在尋找一種具備這些特性的方案。我們當(dāng)然也研究過一些替代方案，比如 WebSocket。但在實(shí)踐中，我們發(fā)現(xiàn)，要真正把一個(gè)可靠的雙向流（bidirectional stream）做好，其實(shí)會遇到很多問題。

于是我們就在思考：有沒有一種“中間態(tài)”？這種中間態(tài)需要滿足兩個(gè)條件：一方面，它要足夠簡單，適合那些最基礎(chǔ)的使用場景——比如用戶只是想提供一個(gè)工具；另一方面，它又必須能夠在需要的時(shí)候，升級成一個(gè)完整的雙向流，因?yàn)槟憧赡苷娴臅龅侥欠N復(fù)雜的 Agent 之間相互通信的場景。正是在這樣的背景下，可流式 HTTP（streamable HTTP）誕生了。

事后回看，我覺得我們有些地方做對了，也有些地方做錯(cuò)了。

做對的地方在于：我們非常堅(jiān)定地只依賴標(biāo)準(zhǔn) HTTP。但做錯(cuò)的地方在于：我們讓太多事情對客戶端來說是“可選的”。比如，客戶端可以連接服務(wù)器，并打開一個(gè)從服務(wù)器返回的流，但它并不是必須這么做。而現(xiàn)實(shí)情況是——幾乎沒有客戶端會這么做，因?yàn)檫@是可選的。結(jié)果就是，很多雙向能力實(shí)際上被“抹掉”了。

于是，一些功能，比如elicitation（征詢）和sampling（采樣），對服務(wù)器來說就變得不可用。原因很簡單：服務(wù)器沒有一個(gè)打開的返回流；而客戶端在實(shí)現(xiàn)時(shí)會想，“這已經(jīng)滿足我產(chǎn)品的最小可用版本（MVP）了，我沒必要再多做這些。”

這最終成了一個(gè)問題。我覺得這是一個(gè)非常明確的教訓(xùn)。

第二個(gè)教訓(xùn)來自于協(xié)議設(shè)計(jì)本身。

我們設(shè)計(jì)的這套傳輸協(xié)議，要求服務(wù)器端持有一定的狀態(tài)。如果你只有一臺服務(wù)器，這當(dāng)然沒問題。但一旦你要做水平擴(kuò)展——比如跑在多個(gè) Pod、多個(gè)容器里——問題就來了。

設(shè)想這樣一個(gè)流程：一次 tool call，然后是一次 elicitation，再接著是 elicitation 的結(jié)果返回。很可能，這幾個(gè)請求會打到不同的服務(wù)器實(shí)例上。那你就必須想辦法，讓這幾臺服務(wù)器把這些信息“拼”在一起。現(xiàn)實(shí)中，這往往意味著你需要某種共享狀態(tài)機(jī)制：Redis、Memcached，或者別的什么共享存儲，總之你需要一個(gè)地方，能夠讓這些服務(wù)器共享狀態(tài)。

從技術(shù)上說，這當(dāng)然是可行的。我們在 PHP 應(yīng)用、Python 應(yīng)用里早就見過類似的模式。但說實(shí)話，當(dāng)規(guī)模一上來，這件事一點(diǎn)都不好玩。

而且我們也知道，一些公司——比如 Google、Microsoft——他們在用 MCP 的時(shí)候，規(guī)模已經(jīng)大到我不能公開具體數(shù)字，但可以說是百萬級請求。到了這個(gè)量級，這就真的成了一個(gè)問題。

于是我們現(xiàn)在坐在這里，不斷地問自己：如何在協(xié)議的下一次演進(jìn)中，做到這幾件事？

• 對簡單的 MCP Server 來說，仍然盡可能簡單；

• 在需要的時(shí)候，允許完整的雙向流；

• 同時(shí)，還要具備良好的可擴(kuò)展性。

我覺得，我們正在逐步找到正確的解法，但這件事本身真的很復(fù)雜。

因?yàn)榻裉斓拇蠖鄶?shù)技術(shù)選擇，其實(shí)都非常極端：要么你做一個(gè)很簡單的東西，比如 REST；要么你直接上“全雙工”的方案，比如 WebSocket、gRPC。而我們需要的，其實(shí)是兩者同時(shí)存在。

2 在巨頭之間“做標(biāo)準(zhǔn)”是什么體驗(yàn)？

主持人：和這么多頂級公司一起做標(biāo)準(zhǔn)，是什么感覺？在那樣的場合，大家都是資深人士，每個(gè)人都有自己的觀點(diǎn)。誰來做最終決定？

David：真的太有意思了。我能和業(yè)內(nèi)最頂級的工程師一起工作。通常我們的目標(biāo)是盡量達(dá)成共識。現(xiàn)實(shí)情況是，從技術(shù)角度講，最終拍板的人是我，但說實(shí)話，這更多是一種形式上的存在。

真正重要的事情在于：我們努力把討論不斷收斂，明確哪些是真正大家都認(rèn)可的問題，哪些是暫時(shí)還存在分歧的問題，然后在這些邊界之內(nèi)，去構(gòu)建我們能做到的最佳解決方案。

這個(gè)過程需要時(shí)間，需要大量迭代，但說真的，這件事本身非常有意思。因?yàn)槟隳芸吹絹碜圆煌镜摹⒎浅＊?dú)特的問題形態(tài)。你甚至能從問題本身，看出一家公司的“性格”——比如 Google 面臨的問題和 Microsoft 就完全不同，而這些差異，很大程度上來自他們各自構(gòu)建系統(tǒng)的方式。同樣，Anthropic 的問題看起來也和 OpenAI 的問題不一樣。

但我最喜歡的一點(diǎn)在于：有時(shí)候你會突然意識到，自己正坐在一個(gè)房間里，周圍全是彼此競爭的公司，但大家卻在一起構(gòu)建同一件東西。

我在開源世界已經(jīng)待了大概 25 年了，我真的非常熱愛這種狀態(tài)。當(dāng)一個(gè)標(biāo)準(zhǔn)真正運(yùn)轉(zhuǎn)起來時(shí)，這就是理想狀態(tài)。而且這些人都非常優(yōu)秀，我從每一位同行身上都學(xué)到了很多。所以我非常感激，自己能處在這樣的位置。

主持人：這聽起來有點(diǎn)像 IETF 的標(biāo)準(zhǔn)制定流程？你們有沒有討論過，這種“私下的小圈子”運(yùn)作方式，和更傳統(tǒng)的標(biāo)準(zhǔn)組織之間的差異？

David：這是個(gè)很有意思的問題。某種程度上，它確實(shí)有點(diǎn)像 IETF，但也有明顯不同。

IETF 是一個(gè)完全開放的論壇，任何人都可以參與。它的結(jié)果是——不是因?yàn)榭桃馊绱耍恰芭既坏亍薄麄€(gè)流程非常依賴共識，因此速度也相對較慢。

但這種慢，在很多方面其實(shí)是優(yōu)點(diǎn)。因?yàn)橐坏?biāo)準(zhǔn)定下來，基本上是不可逆的。比如你看看 OS 2.1 規(guī)范，它已經(jīng)制定了三四年，到現(xiàn)在都還沒完全結(jié)束。這就是 IETF 標(biāo)準(zhǔn)化的節(jié)奏：這些事情本來就會花非常非常長的時(shí)間。

我認(rèn)為這對某些領(lǐng)域是好事，但在 AI 領(lǐng)域，目前的變化實(shí)在太快了，你幾乎被迫要選擇一個(gè)更小的核心群體。因此我們選擇把 MCP 運(yùn)作成一個(gè)非常傳統(tǒng)的開源項(xiàng)目：有一個(gè)大約 8 人的核心維護(hù)者小組，基本上由他們來做最終決策；其他人可以提供輸入、提出建議，而且很多變更并不是來自核心維護(hù)者，但決定權(quán)在他們手里。

這是一種折中方案：一部分是共識驅(qū)動，一部分則是帶有一點(diǎn)“技術(shù)獨(dú)裁”的意味。如果你想要快速前進(jìn)，這種模式在當(dāng)前階段對 MCP 來說是合理的。

主持人：那你們是如何平衡模型能力演進(jìn)與協(xié)議設(shè)計(jì)之間的關(guān)系的？畢竟 Anthropic 和 OpenAI 都在做大量后訓(xùn)練（post-training），讓模型更擅長工具調(diào)用；這會不會影響你們對協(xié)議形態(tài)的偏好？反過來，協(xié)議是否也會反向影響模型訓(xùn)練？

David：老實(shí)說，我不敢說自己對研究側(cè)的所有事情都 100% 熟悉——我更多是產(chǎn)品背景。但從我了解的情況來看，協(xié)議確實(shí)會在一定程度上影響后訓(xùn)練，比如我們在模型卡中會使用MCP Atlas，確保模型在面對真實(shí)世界中大量存在的工具時(shí)，能正常工作。

但從另一個(gè)角度講，協(xié)議的底層原語，其實(shí)很少直接被模型能力的提升所驅(qū)動。我們更像是在預(yù)期模型能力將會呈指數(shù)級增長，因此在協(xié)議中，依賴了一些你可以通過訓(xùn)練不斷強(qiáng)化的機(jī)制。

舉個(gè)更具體的例子。很多人都討論過 MCP Server 的上下文構(gòu)建問題。因?yàn)?MCP 打開了通往大量工具的大門，如果你天真地把所有工具一次性塞進(jìn)上下文窗口，那只會造成嚴(yán)重的膨脹。

這就好比把所有技能、所有 Markdown 文件一次性丟進(jìn)上下文里，結(jié)果當(dāng)然會一團(tuán)糟。

但我們其實(shí)從一開始就知道，可以采用一種叫做漸進(jìn)式發(fā)現(xiàn)（progressive discovery）的方式：先給模型一小部分信息，讓模型在需要的時(shí)候，再主動請求更多信息。

這本質(zhì)上是一個(gè)通用原則。

而這里正是我們這些“大模型公司”具備的一點(diǎn)前瞻性所在——我們知道，如果愿意，是完全可以通過訓(xùn)練，把這種能力系統(tǒng)性地強(qiáng)化出來的。模型在原理上已經(jīng)能做到這些事情了，訓(xùn)練只是讓它做得更好。任何支持工具調(diào)用的模型，都可以做到這一點(diǎn)；只是如果你專門為此訓(xùn)練過，它的表現(xiàn)會更好。所以在這個(gè)層面上，協(xié)議設(shè)計(jì)和模型訓(xùn)練是相互配合的。

但歸根結(jié)底，漸進(jìn)式發(fā)現(xiàn)這種機(jī)制，本身就內(nèi)生于任何具備工具調(diào)用能力的模型之中。

主持人：這也引出了“上下文腐爛（context rot）”的問題。還有 MCP 和所謂 “code mode” 的討論——比如有人會說，“Anthropic 提倡 code mode，而 MCP 又是 Anthropic 做的，那是不是說明 code mode 才是正確方向？”

David：首先澄清一下，官方博客其實(shí)從來沒用過 “code mode” 這個(gè)詞，那是大家后來叫出來的。我們內(nèi)部更常說的是 “programmatic MCP”，但本質(zhì)上討論的是同一件事。

關(guān)鍵在于：MCP 是應(yīng)用和服務(wù)器之間的協(xié)議，模型本身在技術(shù)上并不直接參與 MCP。所以問題其實(shí)變成了：應(yīng)用拿到一堆工具之后，該怎么用？你可以用最樸素的方式：把工具直接暴露給模型，讓模型逐個(gè)調(diào)用。但你也可以更“創(chuàng)造性”一點(diǎn)：模型非常擅長寫代碼，那如果我們把這些工具當(dāng)成 API，交給模型生成一段代碼，讓它提前把多個(gè)調(diào)用組合好，再在一個(gè) sandbox 里執(zhí)行呢？

本質(zhì)上，模型原本就會做這樣的組合：調(diào)用 A → 拿結(jié)果 → 回到推理 → 調(diào)用 B → 再組合成 C。你只是讓模型提前優(yōu)化了這個(gè)過程，把它編譯成一段可執(zhí)行代碼而已。

而 MCP 的價(jià)值并沒有因此消失：

• 認(rèn)證（authentication）仍然由 MCP 處理；

• 接口是為語言模型設(shè)計(jì)的；

• 工具是可發(fā)現(xiàn)的、自文檔化的。

這些能力依然存在。你只是換了一種使用方式而已。所以當(dāng)有人說，“那 MCP 是不是就沒用了？”我其實(shí)挺困惑的。它不是沒用，而是被用在了不同的層次上。

隨著模型和基礎(chǔ)設(shè)施逐漸成熟——比如你可以默認(rèn) AI 應(yīng)用都有 sandbox 執(zhí)行環(huán)境——你確實(shí)可以玩出更多有意思的花樣。但這并不意味著，一個(gè)把模型連接到外部世界的協(xié)議就失去了價(jià)值。

我個(gè)人更愿意把這種變化，看作一種優(yōu)化，說得直白一點(diǎn)，就是token 級別的優(yōu)化。

3 MCP 有沒有競爭對手

主持人：這正好可以引出 skills。skills 是一個(gè)相對較新的概念。我之所以提到它，是因?yàn)樵谖夷X子里，它和漸進(jìn)式發(fā)現(xiàn)、預(yù)置代碼腳本這些概念是連在一起的。而且 skills 還能生成 skills，本身就很有意思。很多人試圖把 MCP 和 skills 放在對立面來比較，顯然它們并不重疊，但你是怎么看待這個(gè)問題的？

David：是的，我同意。我覺得有意思的點(diǎn)就在于：它們并不重疊。它們解決的是不同的問題。

我覺得 skills 非常棒，而且你知道的，我認(rèn)為 skills 最核心的出發(fā)點(diǎn)之一，就是漸進(jìn)式發(fā)現(xiàn)（progressive discovery）這個(gè)原則。但我也認(rèn)為，“漸進(jìn)式發(fā)現(xiàn)”這種機(jī)制，其實(shí)是通用于你能用模型做的幾乎任何事情的——它不是 skills 獨(dú)有的。

那 skills 到底提供什么？它提供的是某一類任務(wù)的領(lǐng)域知識（domain knowledge）：比如你應(yīng)該如何做事、如何表現(xiàn)，模型應(yīng)該如何扮演一個(gè)數(shù)據(jù)科學(xué)家，或者如何扮演一個(gè)會計(jì)之類的角色。

但 MCP 提供的，是你能對外部世界采取的真實(shí)動作的連接性（connectiveness）——也就是你能執(zhí)行哪些實(shí)際操作、如何把這些操作真正連到外部系統(tǒng)上。

所以我認(rèn)為它們在某種意義上是正交的（orthogonal）：skills 給你的是更“縱向”的能力——偏領(lǐng)域、偏角色、偏方法論；而 MCP 給你的是更“橫向”的能力——偏連接、偏動作、偏“給我那個(gè)具體操作”。

當(dāng)然，skills 也可以執(zhí)行動作。它能執(zhí)行動作，是因?yàn)槟憧梢栽诶锩娣糯a和腳本，這當(dāng)然很棒。但這里有兩個(gè)關(guān)鍵點(diǎn)，我覺得很多人容易忽略。

第一，你需要一個(gè)執(zhí)行環(huán)境（execution environment）——也就是你需要一臺機(jī)器來跑這些代碼。是的，你需要“機(jī)器”。這在很多場景下完全沒問題：比如你在本地跑一個(gè)東西（像 Cloud Code 之類），那我們就可以討論 CLI；在這種你確實(shí)擁有執(zhí)行環(huán)境的場景里，這套方式就非常合理，也很好用。

或者，如果你有一個(gè)遠(yuǎn)程執(zhí)行環(huán)境，那同樣也說得通。但即便如此，你在這條路徑上仍然得不到認(rèn)證（authentication）這一塊能力。所以我認(rèn)為 MCP 帶來的關(guān)鍵價(jià)值之一，就是它把認(rèn)證這件事補(bǔ)齊了——這是 skills 本身不提供的那部分。

第二個(gè)點(diǎn)是：你不必去處理“外部方的持續(xù)變化”。舉個(gè)例子，如果你接的是一個(gè) Linear 的 MCP server，那么對方可以持續(xù)改進(jìn)它，而你不需要在自己的 skill 里去處理這些變化——它不是被“固定在某個(gè)時(shí)間點(diǎn)”的。

第三個(gè)點(diǎn)是：你其實(shí)不一定需要一個(gè)本地的執(zhí)行環(huán)境，因?yàn)閳?zhí)行環(huán)境在某種意義上是“在別處”的——它在服務(wù)器端。也就是說，執(zhí)行發(fā)生在 MCP server 那邊。

因此，如果你在構(gòu)建的是一個(gè) Web 應(yīng)用，或者一個(gè)移動應(yīng)用，這些特性在某些方面會更契合、更好用。

所以整體來看，我認(rèn)為它們大多數(shù)時(shí)候都是正交的。并且我確實(shí)看到過一些很酷的落地方式：人們用 skills 去探索不同的功能、不同的角色（比如會計(jì)、工程師、數(shù)據(jù)科學(xué)家），然后再用 MCP servers 把這些 skills 連接到公司內(nèi)部真正的數(shù)據(jù)源上。我覺得這是一個(gè)非常有趣的模型，也最接近我理解和看待它們關(guān)系的方式。

主持人：所以 MCP 是連接層？

David：我會說是通信層。是的，通信層。

主持人：從架構(gòu)上講我很好奇：MCP client 是放在每個(gè) skill 里面，還是大家共享一個(gè) client？比如共享 client 還能發(fā)現(xiàn) skills 之類的。

David：我們是共享的方式。我覺得從技術(shù)上你確實(shí)更想走“共享更多”的方向——共享越多，你能做的事情就越多：比如做 discovery（發(fā)現(xiàn)）、做連接池（connection pooling）、做自動發(fā)現(xiàn)，甚至你可以讓 skill 只用很“松散”的方式描述它想要什么，然后系統(tǒng)去你有權(quán)限訪問的 registry 里幫你找一個(gè)合適的 MCP server。

這些能力只有在 shared 的架構(gòu)里更容易做出來。當(dāng)然，最終兩種方式都能工作，只是這仍然是一個(gè)值得繼續(xù)實(shí)驗(yàn)的方向。

4 Anthropic 怎么用 MCP？

主持人：我想強(qiáng)調(diào)一下，可能很多人都沒意識到——你剛才一直說“我們怎么做怎么做”，但實(shí)際上我覺得外界并不理解 Anthropic 內(nèi)部到底有多大規(guī)模地在 dogfood MCP。我也是看了 John Welsh 的演講才真正理解，他說：“我們有一個(gè) MCP gateway，一切都要走這個(gè) gateway。”你能多講講這個(gè)嗎？

David：當(dāng)然。我們內(nèi)部兩種都用：skills 用得很多，MCP servers 也用得很多。因?yàn)槟阋尨蠹液苋菀撞渴?MCP，你需要和公司內(nèi)部的 IdP（身份系統(tǒng)）打通之類的東西。所以我們?yōu)樽约憾ㄖ崎_發(fā)了一個(gè) gateway。

你只需要把 MCP server 部署起來，剩下的都是內(nèi)部應(yīng)用、內(nèi)部系統(tǒng)在用。有些東西“技術(shù)上”算外部系統(tǒng)，但因?yàn)樗鼈儧]有提供第一方 MCP server，我們就自己做了。比如我們有一個(gè) Slack 的 MCP server——我特別愛用。它可以讓 Claude 幫我總結(jié) Slack。

我們內(nèi)部還有很多類似的用法：例如我們每半年（或者一年兩次）會做一次員工調(diào)查，問大家對公司、對未來、對 AI、對安全等議題的感受。我們也有一個(gè) MCP server 支持這件事，然后你可以圍繞結(jié)果問很多問題，這非常有趣。

主持人：這些都是你們團(tuán)隊(duì)維護(hù)的嗎？

David：不是。我們維護(hù)的是 gateway。但有意思的地方在于：MCP 從一開始的想法就是——在我們開源之前，它源自一個(gè)很現(xiàn)實(shí)的困境：公司增長太快了。我在研發(fā)工具、開發(fā)者工具這一側(cè)，增長速度一定跟不上業(yè)務(wù)擴(kuò)張。那我怎么做一個(gè)東西，讓大家能“自己為自己構(gòu)建工具”？

這就是 MCP 的起源故事。

所以你現(xiàn)在回頭看，一年之后發(fā)生的事情，正好就是我們當(dāng)初想要的：大家真的在為自己構(gòu)建 MCP servers。

我甚至可能完全不知道 Anthropic 內(nèi)部 90% 的 MCP servers，因?yàn)樗鼈兛赡茉谘芯繄F(tuán)隊(duì)里，我看不到；或者人們就是自己做給自己用，我也不會被同步到。

主持人：那它們是自己 host 嗎？還是有遠(yuǎn)程托管？

David：基本上大家只需要一條命令啟動，它就會在一個(gè) Kubernetes 集群里跑起來。算是“半托管”的形態(tài)。對任何大公司來說，這類平臺基礎(chǔ)設(shè)施都很重要。外部也有一些平臺會幫你做這件事，但從安全角度，我們傾向于自己做。

不過外界也有類似的產(chǎn)品。比如有人做了一個(gè)叫 fast MCP 的東西——Jeremiah 他們做的 fast MCP cloud，有點(diǎn)像這樣：兩條命令，你就能跑起一個(gè) MCP server 實(shí)例，支持 HTTP 流式傳輸。

很多企業(yè)還會用類似 LiteLLM 這樣的東西做 gateway：你甚至可以啟動標(biāo)準(zhǔn) IO 的 server，把它接到 gateway 上，然后由 gateway 來處理認(rèn)證等“所有麻煩的部分”。所以落地路徑其實(shí)很多。

但我認(rèn)為你真正想要的“理想基礎(chǔ)設(shè)施”是：讓部署變得極其瑣碎、極其簡單——比如“一條命令”啟動一個(gè)原本只是 stdio 的 MCP server，然后它瞬間變成一個(gè)帶有 HTTP streaming、并且集成了認(rèn)證的遠(yuǎn)程 MCP server。最終開發(fā)者只需要做“標(biāo)準(zhǔn)部分”，其他復(fù)雜部分都由平臺替你完成。

主持人：我很喜歡你把這個(gè)點(diǎn)講出來，因?yàn)楹芏嗳藭苯影堰@套思路拿回公司里落地。否則替代方案就是：混亂、重復(fù)造輪子、各自重建一遍。順便 shout out Jeremiah——我還邀請他來我在紐約的峰會做一個(gè) fast MCP 的 workshop。他寫過一篇很棒的博客，說我們看到的 MCP 使用，很大一部分其實(shí)都發(fā)生在企業(yè)內(nèi)部。

David：是的，我們也觀察到同樣的現(xiàn)象：在大型企業(yè)內(nèi)部，你幾乎到處都能看到 MCP。它的增長速度，比你想象得快得多——因?yàn)樗鄶?shù)都在企業(yè)內(nèi)部發(fā)生，外界根本看不見。

5 Registry 怎么演化？

主持人：說到 discovery，你們推出了官方 registry。然后又出現(xiàn)了各種 registry 公司、gateway 公司。現(xiàn)在官方 registry 里甚至出現(xiàn)了“自動把自己的 MCP server 放進(jìn)官方 registry”的子 registry。你們是不是需要更多 registry？你從推出 registry 這件事上學(xué)到了什么？你覺得未來會怎么演化？

David：我們看到很多不同的 registry 冒出來。我們一直覺得，生態(tài)確實(shí)需要一種類似npm / PyPI（MPM）的模式：有一個(gè)更中心化的地方，任何人都可以把 MCP server 發(fā)布上去。

這就是官方 registry 最初的出發(fā)點(diǎn)。

但我們同時(shí)也想推動：至少整個(gè)生態(tài)要有一個(gè)共同的標(biāo)準(zhǔn)，讓不同 registry 之間能“說同一種語言”。因?yàn)槲覀冋嬲雽?shí)現(xiàn)的世界是：模型可以從 registry 里自動選擇一個(gè) MCP server，安裝它，用在當(dāng)前任務(wù)上——像魔法一樣。

要做到這一點(diǎn)，你需要一個(gè)標(biāo)準(zhǔn)化接口。我們很早就開始和 GitHub 團(tuán)隊(duì)合作（大概四月份），但后來我被別的事情分走了注意力，比如認(rèn)證，去集中解決那塊了。

我希望看到的方向是：未來會有一個(gè)“官方 registry”，任何人都可以往里放 MCP server。它的角色就像 npm ——而 npm 也有完全相同的問題：任何人都能發(fā)布，你并不知道該信誰、不該信誰；會有供應(yīng)鏈攻擊。這是公共 registry 的基本屬性。

所以我們才提出了子 registry（sub-registries）的概念：像 Smithery 這類服務(wù)可以在官方 registry 之上做過濾、做精選、做策展（curate）。我們希望生態(tài)最終能形成這樣的結(jié)構(gòu)。

我們現(xiàn)在還沒完全到那個(gè)狀態(tài)，但正在往那個(gè)方向走。比如 GitHub 的 registry 是“策展式”的，同時(shí)它和官方 registry 講的是同一種格式。

最終我們想要的是：作為一家企業(yè)，你可以有一個(gè)內(nèi)部 registry——它基于官方 registry 的鏡像，再加上你自己的私有 MCP servers；它是你信任的來源，同時(shí)它暴露的 API 和官方 registry 一樣。這樣無論是 VS Code 還是其他客戶端，只要指向你的內(nèi)部 registry，就可以順暢工作。

主持人：這很有意思，因?yàn)?npm 在某種意義上更像一個(gè)“下載網(wǎng)關(guān)”。我其實(shí)不太會去 npm 做發(fā)現(xiàn)，我更多是在別處看到包，然后再去 npm 安裝。你覺得 registry 的核心是 discovery 嗎？還是 agent 會用別的方式完成發(fā)現(xiàn)？

David：我認(rèn)為 discovery 在模型世界里會更重要。這里和 npm 的差別在于：

我們是在做一個(gè)AI-first的東西，我們可以假設(shè)：有一個(gè)聰明的模型，它“知道自己想要什么”。

這在過去是不存在的。如果你今天重新設(shè)計(jì)現(xiàn)代包管理系統(tǒng)，并且把模型當(dāng)作核心，你可能會做出類似的交互：“這是我想做的事，你自己決定裝哪些包，我不在乎，反正把事情做成就行。”這就是它的類比。

但再次強(qiáng)調(diào)：公共 registry 不應(yīng)該直接讓模型這么做，因?yàn)楣?registry 很容易變成一個(gè)“垃圾場”。你應(yīng)該在一個(gè)可信、被策展過的 registry 上做這種自動化選擇。

主持人：我很喜歡你那句話——模型知道自己想要什么。因?yàn)楝F(xiàn)在很多人都有一個(gè)夢想：agent 能用 MCP 目錄去發(fā)現(xiàn)新的 server，自己安裝自己使用。這聽起來非常 AGI。如果真能跑通當(dāng)然很牛，但也可能跑不通。要做到這一點(diǎn)，到底需要什么？

David：我覺得需要兩件事：

第一，你需要一個(gè)好的 registry 接口。

第二，你需要真的去為這個(gè)目標(biāo)做工程、做實(shí)驗(yàn)，看看什么可行、什么不可行。

你肯定需要信任等級（trust levels）。你可能還需要簽名（signatures）。我有一個(gè)想法——不確定會不會真的做——比如：你可以附帶來自不同模型提供商的簽名，表示他們掃描過這個(gè) MCP server，并且愿意為它背書：

• “Anthropic 的簽名：這些 tool descriptions 是安全的”

• “OpenAI 的簽名：我們認(rèn)為這些是可信的”

然后你就可以基于這些簽名自行決策。這有點(diǎn)像分布式代碼簽名——不過也不完全分布式，本質(zhì)上可能還是中心化的。但我認(rèn)為這是你最終會需要的一類機(jī)制。

不過最先跑通的場景，可能反而是企業(yè)內(nèi)部：企業(yè)會用私有 registry，本身就帶有隱含信任。就像他們今天已經(jīng)在用私有 npm / 私有 PyPI 一樣，他們也會用私有 MCP registry。在這種環(huán)境里，你天然有 trust，然后就可以開始做搜索和自動選擇。我們自己其實(shí)就有內(nèi)部 registry：當(dāng)你通過 John 那套基礎(chǔ)設(shè)施啟動一個(gè) MCP server，它就會被注冊進(jìn)去。所以我們也需要在內(nèi)部繼續(xù)做實(shí)驗(yàn)。

6 Sampling：理想很美，但客戶端不配合

主持人：你今年在倫敦辦了一些活動，你看到什么好的 sampling 用例了嗎？

David：還沒有特別多。我從 sampling 這件事學(xué)到的一點(diǎn)是：人們想在 sampling 的過程中使用一些“只在 sampling 時(shí)出現(xiàn)”的工具——這些工具并不是 MCP server 暴露出來的那套工具。但我們之前沒有能力做到這一點(diǎn)。在這次迭代里我們剛修復(fù)了這個(gè)問題，所以我們希望未來能看到更多 sampling 用例。偶爾會有一些 MCP server 在用 sampling，但不多。

尤其是當(dāng) MCP servers 從“本地為主”走向“遠(yuǎn)程為主”，在遠(yuǎn)程場景里，通常更好的選擇可能是直接提供 SDK：你完全控制它、自己部署，甚至還可以收費(fèi)。

而在本地場景里，sampling 的價(jià)值更大：因?yàn)槟闶窃诮o很多人分發(fā)一個(gè)東西，你并不知道他們用的是哪個(gè)模型、哪個(gè)應(yīng)用（可能是 VS Code，也可能是 Claude Desktop），這種情況下 sampling 才更有意義。

但現(xiàn)在的問題是：客戶端基本都不支持 sampling。所以 sampling 這件事讓我挺沮喪的——我仍然覺得這是個(gè)很強(qiáng)的想法，但你知道的，有時(shí)候你總得贏一些、也得輸一些。

主持人：但你們也在升級它，我還是很期待。有點(diǎn)奇怪——如果采樣這件事做對了，它某種意義上會變成真正的 agent-to-agent 協(xié)議。

David：是的。

主持人：你看到的大多數(shù)用例還是偏“數(shù)據(jù)消費(fèi)”嗎？我自己的 MCP 用法也 mostly 是拿上下文、拿數(shù)據(jù)。最多的 action 可能就是更新一下 Linear 任務(wù)狀態(tài)。你見過很復(fù)雜的“用 MCP 做動作的工作流”嗎？還是大家基本都在用它做上下文？

David：大多數(shù)人確實(shí)是用它做上下文，這占了絕大多數(shù)。畢竟它的名字就叫 Model Context（模型上下文）。順便說一句，OpenAI 的 Nick Cooper 經(jīng)常跟我說——而且他說得對——MCP 這個(gè)名字可能取錯(cuò)了，它確實(shí)會讓人感覺用途被“限制”了。

我看到的主要還是數(shù)據(jù)用例。也有人把它用于 deep research，一些更復(fù)雜的 agent 暴露出來，但并不普遍。deep research 這種自定義研究用例不算罕見，但除此之外，大多數(shù)還是數(shù)據(jù)、以及圍繞數(shù)據(jù)的深度研究。

現(xiàn)在你還會看到一個(gè)新方向：通過 MCP UI（未來我們可能叫 MCP Apps / MCPI）暴露 UI 組件。我覺得這非常有前景，也非常有意思。現(xiàn)在在一些 chat apps 里已經(jīng)能看到不少類似實(shí)踐。

7 Tasks：為長時(shí)間、異步 agent 操作而生的新原語

主持人：我很好奇，因?yàn)槿绻蠖鄶?shù)用例是“上下文”，你們做 tasks 這個(gè)原語，就好像大家暫時(shí)還沒怎么用它。你們設(shè)計(jì) tasks 的出發(fā)點(diǎn)是什么？你期待它怎么被用起來？

David：我們做 tasks，是因?yàn)楹芏嗳藖碚椅覀冋f：“我們真的需要長時(shí)間運(yùn)行的操作——也就是 agents。”

他們想要那種“深度研究任務(wù)”，可能一小時(shí)才完成；甚至可能一天都跑不完。過去人們會很別扭地用 tools 去實(shí)現(xiàn)這類事情——工具本質(zhì)上就是 RPC 接口，理論上你能湊出來，但很快就會變得別扭：模型需要理解“我得去輪詢、我得去拉取”，體驗(yàn)很差，也不是一等公民（first-class primitive），限制很多。

但這類訴求太普遍了：大家都想要長時(shí)間運(yùn)行的 agents。GitHub issue 里，大公司也一直在說“我們需要 long-running operations”。所以我們覺得必須做點(diǎn)什么。

現(xiàn)在 tasks 剛剛落地到 SDK，還需要落地到客戶端，然后我們才會看到更廣泛的使用。但我非常確信：自定義研究類任務(wù)會大量用上它，其他場景也會逐步跟進(jìn)。

主持人：我對 tasks 非常看好。我覺得任何編排系統(tǒng)或協(xié)議都得有 sync 版本和 async 版本。

David：完全同意。

主持人：在 tasks 的設(shè)計(jì)上，有沒有哪些重要分岔點(diǎn)？比如本來有兩條路，你們選了其中一條。

David：討論非常多。有人提議：tasks 其實(shí)就是“異步 tools”，做成一個(gè)新的 tool primitive 就行。

但對我來說，我的試金石（litmus test）一直是：如果未來我想把 Claude Code 或任何 coding agent 當(dāng)作一個(gè) MCP server 暴露出來，那么 tasks 必須能支撐這種形態(tài)。

純粹的異步工具調(diào)用做不到這一點(diǎn)。你需要一種操作方式：它能夠在長時(shí)間運(yùn)行的過程中返回中間結(jié)果。理想狀態(tài)下，你會想暴露這樣的東西：“我通過調(diào)用這個(gè)工具、那個(gè)工具、還有那個(gè)輸入，得到中間產(chǎn)物……最后得到結(jié)果。”這才是你希望一個(gè)長任務(wù)能夠表達(dá)的。

tasks 現(xiàn)在還沒完全做到這一步，但它的設(shè)計(jì)是“足夠通用”的，未來可以支持這種更豐富的表達(dá)——這就是最核心的約束。

另一個(gè)關(guān)鍵約束是：我們不希望 tasks 成為 tools 的復(fù)制品 ——只是語義稍有不同。我們希望它是一個(gè)更抽象的概念：你通過一次帶元數(shù)據(jù)的 tool call 來創(chuàng)建一個(gè) task，然后系統(tǒng)自動創(chuàng)建并管理這個(gè) task。所以task 更像一個(gè)“容器（container）”：它描述了一段從開始到結(jié)束的異步過程，而我們當(dāng)前用 tool call 作為觸發(fā)方式。

這樣的抽象會打開很多未來可能性。所以我覺得，真正的設(shè)計(jì)目的是讓實(shí)現(xiàn)變得更抽象。（雖然）實(shí)現(xiàn)起來很復(fù)雜，但也最終被解決了，因?yàn)閺?fù)雜性會被 SDK 吞掉：SDK 會幫你實(shí)現(xiàn)細(xì)節(jié)，在開發(fā)者視角里，它就是一個(gè) async 調(diào)用，然后返回結(jié)果。

主持人：聽起來會和很多異步 RPC 框架有點(diǎn)重疊，比如 JS 世界的 tRPC、或者各種 protobuf 體系。

David：是的。從接口風(fēng)格來說，它很像經(jīng)典的操作系統(tǒng)接口：你創(chuàng)建一個(gè) task，然后不斷 pull（輪詢）直到它完成。

然后我們下一輪會做一個(gè)優(yōu)化——這次沒來得及做：你不用每隔幾分鐘 / 幾小時(shí)去 pull，server 可以回調(diào)你（發(fā)事件、webhook 之類的）告訴你“我完成了”。

這是優(yōu)化，但核心接口始終是：客戶端可以 pull。這也很像操作系統(tǒng)里的一些文件系統(tǒng)操作：客戶端輪詢是一種最通用、最可靠的基線能力……

你可以一直 pull（輪詢）：文件變了嗎、文件變了嗎……但你也可以用現(xiàn)代一些的內(nèi)核接口，比如 inotify 之類的通知機(jī)制，或者 io_uring 之類的方式，它會告訴你：哦，我完成了——很好，文件變了。

主持人：我學(xué)到一個(gè)“騷操作”——server 可以一直把 HTTP 連接掛著，等它做完了再斷開；連接斷開本身就成了一個(gè)信號，告訴后端“完成了”。

David：對，但我們不一定想這么做。因?yàn)樗赡芤軒滋欤乙膊恢绖e人會怎么處理這種連接。

主持人：這其實(shí)挺不負(fù)責(zé)任的，但確實(shí)很酷。老實(shí)說，tasks 真的很有意思——我們在做 Devin API、以及 Cognition 那些東西時(shí)，也基本被迫“重新發(fā)明”過類似機(jī)制。這也很有代表性：每個(gè)人最終都會需要某種 long-running operation。而當(dāng)你在調(diào)用一個(gè) agent 時(shí)，你同樣需要這個(gè)能力。

David：是的。但對我們來說，有一個(gè)有意思的點(diǎn)是：MCP 一直在做的事情，是把大家“此刻正在嘗試做的東西”封裝起來；我們并不想強(qiáng)行規(guī)定一年后大家“應(yīng)該怎么做”。因?yàn)槲覀儾恢溃覀儾活A(yù)測未來。

我們做 tasks，是因?yàn)榇蠹艺f：我們現(xiàn)在就需要它。實(shí)際上我們六個(gè)月前就需要它了。于是我們說，好吧，那現(xiàn)在就是動手的時(shí)候了。

我們不想做那種“預(yù)測未來”的協(xié)議，所以才努力讓協(xié)議保持相對最小化。雖然也有人會覺得：現(xiàn)在協(xié)議里的 primitive 已經(jīng)太多了。

8 超長任務(wù)與上下文壓縮

主持人：一個(gè)小問題。假設(shè)是超級長的任務(wù)，過程中會來回傳很多消息。Anthropic 在上下文壓縮（或者叫 compaction）這件事上算是領(lǐng)先者之一，其他實(shí)驗(yàn)室也在做類似事情。那這種場景怎么處理？我們是不是就無狀態(tài)地把上下文截?cái)嘁矝]關(guān)系？你需要保留“全過程完整日志”嗎？還是說刪掉就刪掉了？

David：不需要。你看，我們現(xiàn)在這個(gè)行業(yè)還是非常早期，我們一直在學(xué)習(xí)：模型到底需要什么、不需要什么。

甚至到今天，有些 agent 已經(jīng)開始在跑了幾輪之后丟棄 tool call 的結(jié)果，因?yàn)樗辉傩枰恕Ｎ矣X得這非常好。所以除了 compaction 之外，我覺得你還會看到更好的機(jī)制：更清楚地理解“該保留什么、不該保留什么”。比如對一個(gè)長時(shí)間異步任務(wù)，你可能會這樣：某段時(shí)間模型確實(shí)需要看到全部過程，但當(dāng)你拿到最終結(jié)果之后，你就把其他東西都丟掉。

你甚至可以調(diào)用一個(gè)更小的模型——比如 Haiku ——讓它來判斷：這些內(nèi)容里哪些該保留？告訴我。也可能最“AGI build”的方式就是：讓模型自己決定它需要保留什么。所以你會看到兩種世界并存。

我們現(xiàn)在還沒有唯一答案，因?yàn)榇蠹胰栽诿鳌ompaction 是一個(gè)很好的階段性方法，但它也不會是最后一步。

實(shí)際上，如果你更認(rèn)真地思考：你能訓(xùn)練模型在這里做什么，我覺得會有更好的方式。但這些都和“你如何獲取上下文”是相互獨(dú)立的。

我一直把 MCP 看作一個(gè)應(yīng)用層協(xié)議：它只負(fù)責(zé)“你如何獲得上下文”。至于“你如何選擇上下文”，那是應(yīng)用層問題——所有 agent 應(yīng)用最終都會面對。

未來會有很多技術(shù)路徑。一年前所有人都會說：RAG 才是答案；現(xiàn)在大家又說 RAG 好像“死了”。我們開始用模型、用 compaction。至于一年后會怎樣，我也不知道。

主持人：我還有個(gè)問題：你怎么看 MCP servers 在未來的定位——它們是給開發(fā)者用來構(gòu)建 AI 應(yīng)用的？還是一個(gè)面向 AI 消費(fèi)者、讓他們把各種服務(wù)“插上就能用”的協(xié)議？我覺得很多人會把它理解錯(cuò)：他們說“我有 REST API，為什么還需要 MCP？”在我看來，MCP 可能并不是“給開發(fā)者用的”，而是給使用 AI 工具的人，用來把東西插進(jìn)去的。

David：我經(jīng)常被拿來和 REST API 比。這個(gè)對比挺有意思的，因?yàn)檫@里其實(shí)有兩個(gè)問題：第一，REST 并不告訴你認(rèn)證該怎么做。第二，你們已經(jīng)在跟我抱怨 “tool bloat（工具膨脹）” 了，但你們有沒有看過平均一個(gè) OpenAPI spec 有多長？你把那個(gè)塞進(jìn)模型里，膨脹只會更嚴(yán)重——實(shí)際上會糟得多。

更有意思的是，當(dāng)人們嘗試一比一映射時(shí)，模型經(jīng)常會有點(diǎn)迷糊：你會有“按名字搜索、按 ID 搜索、按某字段搜索”等等，突然冒出五個(gè)長得很像的工具，模型就會問：你到底要用哪個(gè)？我也不知道了。所以這是個(gè)關(guān)于 REST vs MCP 的小插曲。

但我確實(shí)希望 MCP 生活在一個(gè)更“消費(fèi)者導(dǎo)向”的世界：這是使用者應(yīng)該知道的能力。我想要的世界是：你打開應(yīng)用，直接說“做這件事”，它就把事情做完——它在底下自動連到合適的服務(wù)。MCP 是幕后細(xì)節(jié)；開發(fā)者需要知道它，因?yàn)檫@是通信通道；但對最終用戶來說，你只需要拿到結(jié)果、把任務(wù)完成。

坦白講，我更喜歡一個(gè)世界：沒人需要知道 MCP 是什么。比如我媽如果要用 Claude，她不應(yīng)該知道 MCP 是啥。但我認(rèn)為 MCP 的重點(diǎn)確實(shí)是：讓外部服務(wù)“可插拔”。在這個(gè)意義上，它更偏消費(fèi)者側(cè)。當(dāng)然開發(fā)者也有用例：他們作為 builder 要構(gòu)建這些東西；而且我也仍然很愛我的 Playwright MCP server。

主持人：我很好奇你說的 MCP Apps / UI。現(xiàn)在每個(gè)客戶端——比如 ChatGPT——都有自己的一套渲染方式。所以如果我習(xí)慣了某個(gè)產(chǎn)品的 MCP app，但換到另一個(gè)地方，它可能就是另一個(gè)版本、另一種策展方式，體驗(yàn)會很不一樣。我想知道你怎么看：尤其現(xiàn)在 OpenAI 也進(jìn)了基金會，你覺得會不會形成統(tǒng)一結(jié)構(gòu)？讓大家按同一個(gè)標(biāo)準(zhǔn)來？

David：這里有兩個(gè)影響源：一方面，MCP UI（或者 MCPY）作為項(xiàng)目本身已經(jīng)存在一段時(shí)間了，它有很多很好的想法。OpenAI 也吸收了其中一些想法，并做了不少改進(jìn)。更重要的是：我們?nèi)芮霸?MCP 博客上剛宣布——我們正在和他們一起做一個(gè)共同標(biāo)準(zhǔn)。

我們的目標(biāo)是回到一個(gè)世界：你為一個(gè)平臺開發(fā)一次，就可以在所有平臺用；或者說“一次構(gòu)建，到處運(yùn)行”——你在 ChatGPT 里能用，也可能在 Claude、在 Goose、或任何實(shí)現(xiàn)了該標(biāo)準(zhǔn)的程序里用。

而這件事的核心驅(qū)動力是：現(xiàn)代 AI 應(yīng)用幾乎一切都是文本交互，這沒問題，也挺好；但有些事情，人類就是更擅長用視覺來做。

最典型的例子：選飛機(jī)座位。如果讓你用純文本選——“這里有 25 個(gè)座位可選”——誰愿意這么干？你根本不知道這些座位在機(jī)艙圖上是哪里。你當(dāng)然想要一個(gè) UI：你能點(diǎn)著選；而模型也能在這個(gè) UI 上導(dǎo)航、交互；并且你作為人類也能同時(shí)交互。這就是我們想要的方向：做更豐富的界面。純文本界面確實(shí)有天然限制。

你會在音樂制作等場景看到這種需求；你也會看到品牌方非常在意界面呈現(xiàn)。購物也是一個(gè)極好的例子：購物行業(yè) 20 年的 A/B 測試，研究“怎么把東西賣給你”最有效——購物界面其實(shí)非常復(fù)雜。所以我們需要一種方式，把這些熟悉的復(fù)雜 UI 展示給用戶，讓用戶能交互。這就是 MCP Apps 最終要做的事。

主持人：技術(shù)方向上是 iframe？

David：對，是 iframe。本質(zhì)上你通過 MCP resource 提供原始 HTML，把它放進(jìn)一個(gè) iframe，然后通過一個(gè)明確的接口用 postMessage 和外部通信。

因?yàn)槭?raw HTML，而且不是加載外部內(nèi)容，你如果愿意，理論上可以提前做安全分析。同時(shí) iframe 也天然能提供比較清晰的隔離邊界，讓外部應(yīng)用在一個(gè)安全邊界內(nèi)與之交互。

主持人：iframe 在瀏覽器里用了很多年。我唯一擔(dān)心的是 CORS……我太討厭 CORS 了，而 iframe 總會遇到 CORS 問題。

David：是的，但這里理論上不加載任何外部內(nèi)容——至少我們不希望它這么做。當(dāng)然，未來我們可能會不停迭代，五年后可能會出現(xiàn)一堆 CORS header 之類的復(fù)雜東西。但現(xiàn)在我們還是從小做起：純 raw HTML，最好不要有外部引用，這樣就不會碰到那些問題。

主持人：那能繼承宿主應(yīng)用的樣式嗎？

David：不能。iframe 里你得把樣式內(nèi)聯(lián)進(jìn)去。

主持人：這聽起來很小，但 UI 團(tuán)隊(duì)會非常在意。大家會希望它看起來像 ChatGPT。

David：完全同意。品牌方和設(shè)計(jì)師會非常非常在意。這也是我們需要解決的問題：先把東西推出去，讓大家用起來，然后基于真實(shí)使用方式迭代。這也正是為什么我覺得長期來看它不應(yīng)該一直是 iframe。我不知道最終解決方案是什么，但我們可能需要一種“新的 iframe”，它允許一定的“滲透性 / 可融合性”。

主持人：我覺得這挺合理。另一條路可能就是“AGI build”的方式：給它一個(gè) tool 說“給我樣式”，模型再去問宿主應(yīng)用“我應(yīng)該長什么樣”。

主持人：那 MCP app 應(yīng)不應(yīng)該知道自己被嵌在哪個(gè)父應(yīng)用里？比如父應(yīng)用也暴露工具給模型調(diào)用，對吧？那是不是需要一個(gè)標(biāo)準(zhǔn)接口讓父應(yīng)用把樣式傳下去？

David：可能是。這個(gè)問題很大。我得去問問團(tuán)隊(duì)。我自己并不在最底層細(xì)節(jié)里，我更多是站在整體方向上。

主持人：這對我來說有點(diǎn)意外。我以前從沒關(guān)注 MCP UI，結(jié)果你們突然都采納了。我就想：好吧，那看來它已經(jīng)是 MCP 的一部分了——它讓 MCP 從純后端議題，變成了前端議題。

David：需要說明的是：技術(shù)上它是 MCP 的一個(gè)擴(kuò)展（extension），它不是 MCP 核心的一部分。這更多是治理層面的區(qū)分。

如果你是一個(gè)能渲染 HTML 的客戶端，你可以考慮實(shí)現(xiàn)它；但就算你不實(shí)現(xiàn)，你仍然是一個(gè) MCP client。現(xiàn)實(shí)是：很多 CLI agent 根本渲染不了 HTML，所以它們永遠(yuǎn)不會實(shí)現(xiàn)。這沒問題。

主持人：還有其他類似的擴(kuò)展嗎？

David：我們可能會在金融服務(wù)方向做一些擴(kuò)展。比如一年后，你可能會看到這樣的世界：客戶端會有某種“認(rèn)證 / 資質(zhì)”，并得到一個(gè)簽名——證明它是“金融服務(wù) MCP 客戶端”，然后向 server 出示這個(gè)證明，server 才允許連接，因?yàn)樗揽蛻舳藭袷貧w因（attribution）等法律合同要求。

類似的機(jī)制也會出現(xiàn)在 HIPAA（醫(yī)療健康數(shù)據(jù)）這類場景：當(dāng)你面對公共 server 和公共 client，同時(shí)還要處理敏感數(shù)據(jù)時(shí)，你必須提供一些保證。

主持人：這不是 OAuth 的一部分嗎？

David：不一定。舉個(gè)例子：假設(shè)客戶端同時(shí)裝了五個(gè) MCP servers，其中有一個(gè)是醫(yī)療 server。這個(gè)醫(yī)療 server 可能會要求：在這個(gè) session 里，你不允許使用其他 MCP servers，因?yàn)槲医o你的數(shù)據(jù)不能泄露到任何地方。你必須保證它不會跑出去——因?yàn)檫@是 HIPAA 數(shù)據(jù)、或者金融數(shù)據(jù)。這是一個(gè)很典型的約束：你不希望自己的社保號、健康數(shù)據(jù)不小心出現(xiàn)在別的地方。

9 加入 Linux 基金會會不會分心？

主持人：我們接下來會切到 AAIF ，最后，有沒有什么行動號召？比如招人、或者呼吁大家參與 MCP spec？

David：最重要的還是——每天都去用 MCP 去構(gòu)建：去做真正好的 MCP servers。我們看到很多很一般的 MCP servers，也看到一些非常非常優(yōu)秀的。把 server 做好、把用法做扎實(shí)，這很關(guān)鍵。

第二點(diǎn)，我們是一個(gè)相當(dāng)開放的社區(qū)，按傳統(tǒng)開源方式運(yùn)作：本質(zhì)上取決于大家愿意投入多少時(shí)間和精力。所以你可以通過很多方式參與：給反饋、在 Discord 里交流、給點(diǎn)子；也可以幫我們做 SDK，比如 TypeScript SDK、Python SDK。我們也一直在找新的 SDK——比如我們有 Go SDK 在推進(jìn)，但我們沒有 Haskell SDK。如果你是 Haskell 開發(fā)者，你也許可以來寫一個(gè)（笑）。

總之，可以做的事情很多。不要低估“參與社區(qū)”本身的價(jià)值。當(dāng)然也別忘了去構(gòu)建：現(xiàn)在機(jī)會太多了，尤其是我們對 progressive discovery 的理解更成熟了，對 code mode 的理解也更成熟了——接下來會出現(xiàn)一代新的客戶端、一代新的 server，我非常期待大家去做出來。

主持人：我最后一個(gè)問題，是想讓大家直接聽你說。我能感受到你的能量，我也對你們做的事情非常興奮。但很多人對 MCP 加入 Linux 基金會有點(diǎn)焦慮：他們會說，“這是不是意味著 Anthropic 分心了？”你能回應(yīng)一下嗎？

David：我很喜歡你問這個(gè)問題。我完全理解大家為什么會這么想，但事實(shí)恰恰相反。Anthropic 的投入和承諾沒有變：我們還是同一批人在做 SDK，我們的產(chǎn)品仍然高度依賴 MCP。我還是 MCP 的核心維護(hù)者。技術(shù)上什么都沒變。

基金會真正帶來的核心變化只有兩點(diǎn)：第一，它讓整個(gè)行業(yè)確信：MCP 會永遠(yuǎn)開放，永遠(yuǎn)不會被拿走。歷史上確實(shí)有公司把開源項(xiàng)目又變回專有。協(xié)議領(lǐng)域也有很多專有例子——比如 HDMI。你看 HDMI 在 Linux 上的那些問題。HDMI 2.1 的 HDMI Forum 不愿意讓 AMD 開發(fā) HDMI 2.1 的開源 Linux 驅(qū)動——真的，有些資料你可以去查。

所以行業(yè)里很多人會盯著這些風(fēng)險(xiǎn)。基金會的意義就是：現(xiàn)在 MCP 歸屬一個(gè)中立實(shí)體，它會一直開放。你可以使用 “MCP” 這個(gè)名字，也不會有人因?yàn)樯虡?biāo)去起訴你。這會給生態(tài)巨大的信心：它是中立的、可持續(xù)的。

第二點(diǎn)，如果說我最驕傲的是什么：我覺得我們已經(jīng)在行業(yè)里為“開放標(biāo)準(zhǔn)”定下了基調(diào)。現(xiàn)在我們可以利用這個(gè)勢能，在一個(gè)中立空間里建立社區(qū)：讓大家把真正做得好、維護(hù)得好、長期可靠的項(xiàng)目放進(jìn)來，成為基金會的一部分。

而且我們的門檻會很高：項(xiàng)目必須維護(hù)得很好。我們不想、也不會把基金會做成“分心”或“甩包袱”的地方。對我們來說，MCP 仍然是產(chǎn)品核心、仍然超級重要；Anthropic 的承諾和投入一如既往。

https://www.youtube.com/watch?v=z6XWYCM3Q8s

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點(diǎn)，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產(chǎn)業(yè)落地，從技術(shù)前沿到行業(yè)應(yīng)用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結(jié)全球技術(shù)先鋒，拆解真實(shí)生產(chǎn)案例、深挖技術(shù)與產(chǎn)業(yè)落地痛點(diǎn)，探索前沿領(lǐng)域、聚焦產(chǎn)業(yè)賦能，獲取實(shí)戰(zhàn)落地方案與前瞻產(chǎn)業(yè)洞察，高效實(shí)現(xiàn)技術(shù)價(jià)值轉(zhuǎn)化。把握行業(yè)變革關(guān)鍵節(jié)點(diǎn)，搶占 2026 智能升級發(fā)展先機(jī)！