原文連結： MCP 共同創辦人談 LLM 創新的下一波浪潮
Yoko Li： 我必須在這裡問這個問題。你如何定義代理（agent）？
David Soria Parra： 我不會深入討論這個。
你認為什麼是代理？
Yoko Li： 你怎麼做到的？我認為它是一個多步驟的 LLM 推理鏈。對我來說非常簡單。
David Soria Parra： 好的，是的，我無法完全贊同。對我來說，代理可能更像這個詞本身所含的「代理權」（agency）的意思。所以是某種能進行自主協調、自主解決任務的東西，通常任何多步驟的事情對我來說，目前都已經像是個代理了。當它執行了兩個步驟，並且對第一個步驟做出反應時，它基本上就是一個代理，因為它現在對自己正在做的事情擁有一些代理權。歡迎回來。
Podcast Narrator/Host： a16z AI podcast 節目。好久不見，但我們再次帶來另一場關於快速發展的 AI 領域的精彩討論。這次的主題是 MCP，即模型情境協定（Model Context Protocol），它一直是今年討論的主要話題，因為它意味著通過將模型連接到任意數量的新工具、數據集和外部應用程式，來開闢新的 LLM 使用案例和活躍行為。今天來談論這個話題的是 a16z Infra 合夥人 Yoko Li 和 Anthropic 的 David Soria Parra，他與同事 Justin Spahr Summers 共同創建了 MCP。在其他議題中，Yoko 和 David 討論了 MCP 的起源故事、早期和流行的使用案例、仍需完成的重要工作（例如圍繞身份驗證），以及執行某些類型工作流程的正確抽象層級是什麼。
什麼是 MCP？
David Soria Parra： 所以 MCP 首先，它是一個開放協定，這句話本身並沒有太多含義。但它真正試圖做的是，它試圖以這樣一種方式來構建 AI 應用程式，使得它們可以被原始開發團隊之外的任何人通過這些 MCP 伺服器進行擴展，並真正將您關心的工作流程、您想做的事情帶到這些 AI 應用程式中。為此，它就像一個協定，僅定義了您作為開發者為該整合部分和那些 AI 應用程式所構建的任何東西，它們之間如何相互通信，這就是它的本質。這是一個非常枯燥的規範。但是，它所能實現的，至少在我最好的設想中，是類似於當前 API 生態系統的東西，但用於 LLM 與某種形式的情境提供者或任何形式的代理進行互動。
Yoko Li： 是的，我非常喜歡與 API 生態系統的類比，因為它給了人們一個關於生態系統如何演變的心智模型。感覺 API 剛出現時，它是對一組可以在不同伺服器和服務上執行的操作的抽象。
以前，您可能需要不同的規範來查詢 Salesforce 與查詢 HubSpot。現在您可以使用類似定義的 API 結構描述來執行此操作。不完全相同，因為每個人定義查詢參數的方式都不同。然後，當我今年早些時候看到 MCP 並用它構建一些東西時，非常有趣的是，它幾乎感覺像是代理與 LLM 互動的標準介面。就像，代理想要執行哪些它以前從未見過的操作？它需要什麼樣的情境來實現這些事情？當我嘗試時，它超級強大。我不再需要為每個客戶端構建一個工具。我現在可以只為發送電子郵件等功能構建一個 MCP 伺服器，然後我在 Cursor、Cloud Desktop、Goose 上都使用它。
所以很好奇，我想知道幕後故事是什麼？當你第一次意識到，哦，我們需要一個這樣的協定時，是什麼啟發了你？你是如何創造它的？
MCP 的起源故事
David Soria Parra： 是的，謝謝你，我想這是一個有趣的問題。我認為所有這類型的想法，它們從來都不是在真空中產生的。我大約一年前加入了 Anthropic，差不多就是一年前，我主要致力於如何更有效地在內部使用 Claude 來加速我們自身發展。
作為其中一部分，我思考的一個原始想法是，我不可能為每個人建立他們特定的工作流程、特定的東西，但我需要讓他們能夠為自己建立，因為他們最了解自己需要什麼，以及他們想要建立的工作流程和代理性位元如何融入他們的系統，融入他們工作的生態系統中。這是其中一個方面。第二個方面是，當時我同時使用 Cloud Desktop，它非常棒，其成品（artifacts）能讓你很好地將事物視覺化。但它有一個限制，基本上除了文字框之外，沒有任何互動。你還不能加入 Google 文件或類似的東西。同時，我還使用一個程式碼編輯器，它也很棒，因為它可以存取我所有的程式碼，並可以存取所有這些很酷的東西，但它無法像 Cloud Desktop 那樣漂亮地將任何東西視覺化。我對於不斷地從 Cloud Desktop 複製東西到編輯器，然後再複製回來感到非常沮喪。我想，這兩個應用程式之間需要一種更好的方式。
然後，如果你把這兩件事放在一起看：我需要某種方式讓人們能夠建構一些東西，像是某種形式的 API。但同時，我也希望這能在多個應用程式中運作，比如程式碼編輯器。對我來說，是 Z 程式碼編輯器，我非常喜歡它，還有 Cloud Desktop，這顯然是我最喜歡的桌面應用程式。你就會思考如何解決這個典型的 M 乘 N 問題：我有 M 個客戶端，需要 N 個供應商。答案就是為此制定一個協定。對於這類問題，答案一直都是協定。過去有很多模式都符合這種情況。這就是我如何想到，嘿，我真的很希望能有一個協定，讓我可以告訴 Claude、告訴 Z、告訴 Cursor 我關心的工作流程以及我從中遺漏的東西，因為我是一名開發者，我想為此而建構，我知道如何為此而建構。就讓我去做吧。這確實是這方面的起源，那只是一個想法。我把這個想法告訴了一個叫做 Justin Spar Summers 的人，他是 MCP 的共同創造者，他非常喜歡這個想法，認為這是一個好主意，並且是原型化初始版本、真正使其在 Anthropic 產品方面運作起來的關鍵人物之一，並在使之成為 Anthropic 最初的一個相當大的項目中扮演了非常重要的角色。是的。所以我們基本上共同創造了這個，直到我們在 2024 年 11 月將其公開。
最初的 MCP 伺服器與客戶端
Yoko Li： 我喜歡這個。我喜歡這裡的創意夥伴關係，然後有了框架或協定。我不得不問，這有點像雞生蛋、蛋生雞的問題。你是先創建了可以使用協定實現的實例，還是你先有了協定的想法？如果你創建了具體的實例或範例，那麼第一個 MCP 伺服器或客戶端是什麼？
David Soria Parra： 是的，這是非常好的觀察。這是一個非常典型的雞生蛋、蛋生雞問題。我們內部通常的做法，而且 Justin 在這方面非常出色，就是非常快速的原型製作。所以我們確實經歷了幾週非常密集的原型撰寫。非常簡單，就像一些簡單的東西，主要只是為了演示。我們最早寫的一個是 Puppeteer 伺服器。也就是控制 Chrome 實例的能力。這樣做的原因之一是它是一個非常活躍的過程。螢幕上會發生一些事情，讓人們驚嘆。這就是你想讓人們達到的效果。你會想，我如何說服人們這裡有很多可能性。嘿，我可以控制你的瀏覽器，我可以做你以前做不到的事情。而且是 Claude 在做，不是你手動在做。但在我們做這些的同時，我們也在完善這個概念，我們花了很多時間討論，我不會說是爭論，但絕對是進行了有趣的論述，關於某些你想放入和排除的原始元素。
在最初的幾週內，事情的運作方式發生了很多變化。再者，我認為 Justin 當時寫的第一個 MCP 客戶端，他把它寫進了 Cloud Desktop，我把它寫進了 Z。所以這幾乎是同時發生的。然後我認為我們真正為自己擁有的第一個實用 MCP 伺服器是那些非常枯燥的伺服器之一，比如 GitHub 整合或類似的東西，只是為了幫助我更好地完成我的工作。比如一個 Postgres 伺服器。沒有什麼超級有趣、超級有創意的。只是你會想到去做的最明顯的事情。
MCP 伺服器與客戶端的有趣實作
Yoko Li： 我會說你的例子超級有創意，因為你不能真的讓代理為你做任何事。最近我看到一個 giblification 過程的例子。有人有一個 MCP 伺服器，控制瀏覽器要求模型生成 giblified 圖片，這樣他們就不需要實作 API 端點了。這讓我大開眼界。
David Soria Parra： 非常酷。
那非常好。
Yoko Li： 是的，我想除了你最初的幾個使用案例之外，既然你可能已經看過社群中所有的 MCP 客戶端伺服器，那麼你見過哪些 MCP 伺服器或客戶端最有趣的實作？
David Soria Parra： 我喜歡人們發揮創意的時候。我認為人們建立許多非常合理且直接的整合是很棒的。
再次強調，像是 Postgres 伺服器、GitHub 伺服器、Asana 伺服器等等。但我真正喜歡的是發揮創意。我想其中一件讓我發笑的事情是，很早以前，大約在聖誕節前後，這個人把 Claude 和 Claude Desktop 連接到他們的 Amazon 帳戶，然後讓 Claude 購買他們的聖誕禮物。我一直覺得這太搞笑了。既有趣又有創意。
Yoko Li： 那是如何實作的？它有付款功能嗎？
David Soria Parra： 我忘了確切的細節，但我想是 Playwright 或 Puppeteer 控制瀏覽器的某種組合。但它是刻意圍繞著我想從 Amazon 購買或選擇的一組禮物而建立的。所以我非常喜歡這類東西。我也喜歡看到你的摩斯密碼 MCP 伺服器。我喜歡這類東西。他就像， playful，與科技互動。很多很多年前，我是德國當地駭客空間和這類組織的活躍成員。我喜歡人們與科技互動並嘗試創造東西的創意方式。所以每次我看到這類組合，它們都非常美好。我們稍後會再談到這個，對吧？像是人們在 Unity 和 Blender 中處理合成器。但其中顯然也有有趣、有意思的科技部分。我認為 Jetbrains 做得非常好，他們有一個可以控制其 IDE 的 MCP 伺服器。那是一個更複雜的設定，我喜歡那部分。然後還有一些我甚至沒有想過的領域。有一位頗有名氣的 YouTuber 叫做 Laurie，他是一位逆向工程師，他們使用 Claude 協助逆向工程一些檔案，並使用了 MCP。我覺得那很酷，因為有些東西，沒有人會首先將逆向工程工具內建到他們的桌面應用程式中，但那個人可以自己去建構它，因為他們當然有這個能力和技能。
所以這就是我喜歡的那種東西。
Yoko Li： 我就是喜歡當一個協定能夠解鎖長尾效應，而且這個長尾效應非常長的時候。因為就像你說的，沒有人會把它當作第一方功能來建構，但現在每個人都可以為某個特定需求建構軟體。
David Soria Parra： 是的，我其實有點好奇，你自己有哪些覺得相當有趣且好玩的例子？
Yoko Li： 是的，有一個是我做的。這其實是一個非常實用的案例，有時候我寫程式寫得太投入，會忘了吃晚餐。所以很自然地，我先生會傳訊息給我。他會問：「妳在哪裡？回家吃晚餐嗎？」然後我就用了最近的 MCP。
David Soria Parra： 我有。
Yoko Li： 嗯，這是它的另一個美妙之處，因為使用同一個 MCP 伺服器，你可以透過輸入不同的提示來解鎖截然不同的體驗。所以我沒有寄電子郵件給他，而是請 Cursor 代理程式：「你能否傳簡訊給我先生，號碼是這個，並解釋我們為什麼晚餐遲到了？」因為 Cursor 代理程式正在做大部分的編碼工作。我只是在審查，然後我傳簡訊給我先生，那是一個我先生也可以回覆的號碼。所以這是一個非常實用的案例。
David Soria Parra： 這是一個很好的使用案例。
Yoko Li： 對。
像是，我們卡在這裡了。我無法解決這個錯誤。
我為那個代理感到很抱歉。
David Soria Parra： 我喜歡這個。這太有創意了。這簡直就是人們使用它時會感受到的那種小小的魔力。是的。
Yoko Li： 然後那個摩斯密碼的例子，做起來非常好玩。起因是 Twitter 上有人問，我希望程式碼代理在我完成任務時通知我，因為有時候需要五到十分鐘。
所以我想，有什麼非常有趣的方式讓它與人類溝通呢？顯然，你可以發簡訊，可以播放一些音樂，但我們家裡有很多 Philips Hue 智慧燈泡。所以我想，代理要如何才能存取我的區域網路呢？因為它在同一個 IP 下，我就可以控制我的燈光。那你如何透過摩斯密碼與燈光溝通呢？所以我那週學了一下摩斯密碼。除錯起來很費勁，像是，什麼是長音，什麼是短音，間隔是多少？
所以最後的體驗是 Cursor 或是像 Cloud Desktop，當它完成任務時，它會開始一段摩斯密碼序列，用摩斯密碼說出它必須說的話，然後你只需要仔細聆聽或觀看。所以那做起來很有趣。那週，我們家有三隻貓，牠們都嚇壞了，因為燈光一直開開關關。另一個例子，你知道，自從我開始以開發者的身份使用 MCP 後，我回顧了我以前純粹為了好玩而做的專案，思考如何用 MCP 客戶端的方式重寫它們，這樣我就可以插入任何 MCP 伺服器。舉個例子，去年，我做了一個 Raspberry PI 貓咪旁白專案，用 Raspberry PI 的鏡頭偵測我的貓是否跳上廚房流理台，然後它會旁白貓在做什麼，或者對貓大叫。所以我目前正在把那個代理迴圈轉換成一個 MCP 客戶端。這樣它就可以使用 11Labs 的 MCP 伺服器來對貓大叫，然後就解鎖了像這樣全新的例子。我就是喜歡在一旁建構和玩耍。
David Soria Parra： 我需要那個版本給我的狗。
Yoko Li： 我稍後寄一台 Raspberry PI 給你。現在大多數的 LLM 對於在裝置上運行來說還是太大了，所以我仍然需要呼叫 Cloud 或其他模型來實現。但事實上，我現在可以讓貓咪偵測器具有擴展性，這對我來說非常有趣。所以現在我不僅可以呼叫 11Labs MCP 來對貓大叫，我發現 MCP 一個被低估的功能是，客戶端可以將不同的工具呼叫串聯起來。所以它不僅可以使用 11Labs 來抓貓，還可以寄電子郵件給我，告訴我貓在做什麼。
所以，說到未被充分利用的協定功能，現在大多數人都在用工具呼叫來實作 MCP 伺服器，但我們知道還有很多其他功能有待解鎖。所以，很好奇你的想法。你覺得有哪些未被充分利用的功能，人們應該開始嘗試？
MCP 中未被充分利用的功能
David Soria Parra： 是的，這是一個有趣的問題，因為當你在創建一個規範時，你腦海中會有所有這些使用案例，你會以一種非常原則性的方式思考它，然後從中產生一組你希望人們使用的原語。然後現實會打擊你，人們會以非常不同的方式使用它。
我想顯然人們會像你說的那樣用它來製作工具，但我認為有兩到三件事我真的覺得未被充分利用，而且我希望人們能更多地使用它們，但我認為有一個問題，特別是圍繞著客戶端的初期支援。但我真正喜歡協定中的一件事，其實是一個命名得很差的功能，叫做取樣（sampling），因為當你讀到這個名字時，它做什麼相當令人困惑。
Yoko Li： 你正在取樣它做了什麼。
David Soria Parra： 是的。所以當你真正思考你在嘗試做什麼時，這就很有道理了。所以，取樣是什麼呢？這是一種讓 MCP 伺服器說「我想呼叫一個 LLM，但因為我是一個 NCP 伺服器，我不知道客戶端正在使用的這個 DLLM 是什麼」的方式。我可以帶上我自己的 SDK，但這樣我就把自己綁定到那個 SDK 上了，那可能是一個 Anthropic SDK，也可能是一個 OpenAI SDK，但現在我期望使用者提供 OpenAI API 金鑰或 Cloud API 金鑰，這真的不太好。而且他們可能在 Cursor 中使用不同的模型。
所以取樣（sampling）是一種讓 MCP 伺服器回頭向客戶端詢問的方式，嘿，你能否用目前選定的模型給我一個完成（completion），像是從 LLM 取樣？這就是名字的由來，然後再回傳給我。這樣我就可以製作 MCP 伺服器，去摘要 Reddit 貼文或摘要任何我想做的事情，甚至擁有它們自己的代理循環（agentic loops）。但 LLM 推理的控制者仍然是客戶端。所以這裡有很多。我認為這才是真正酷的地方，你可以建立這些非常豐富的 MTP，遠遠超出工具呼叫的範疇，並且讓它們完全獨立於模型，這才是它的真正用途。如果我們稍後以正確的方式組合它們，這會有很多很酷的特性，但這並不是我希望看到更多人使用的功能之一。但同樣，這取決於客戶端是否很好地支援這個功能，或者根本不支援。所以我希望更多的客戶端能支援它，然後更多的人可以建立它，並建立這些更豐富的東西，超越單純的工具呼叫，成為代理循環、摘要位元等等。所以是的，這是其中一個功能。
深入探討：Sampling 機制
Yoko Li： 這太有趣了。我想，一個我一直想用你提到的這個取樣模型來建立的非常具體的例子，其實是程式碼審查代理。在這種情況下，我會想建立一個進行程式碼審查的伺服器，但它可能希望 LLM 來完成這個有效的語法，因為它不想引入自己的 LLM。所以這感覺像是一個非常自然的切入點。客戶端需要做些什麼才能支援這個功能呢？
David Soria Parra： 他們只需要去做。顯然，某些客戶端不想這樣做是有原因的，特別是那些擁有固定訂閱的客戶端可能會，你知道，可能更不願意這樣做，因為，你知道，它突然變成了一個 API。但除此之外，我認為這只是客戶端支援和優先順序的問題。顯然，客戶端支援人們所做的事情，所以他們主要專注於工具呼叫。有太多事情在發生了。需要添加的規範，以及所有 MCP 領域的繁重工作，實際上都非常刻意地放在客戶端，因為我們預期客戶端的數量遠少於伺服器。因此，我們希望讓建立伺服器變得非常簡單。結果，所有我們可以轉移到 CL 的複雜性都轉移到了客戶端。因此，建立一個真正優秀、完全符合規範的 MCP 客戶端是很困難的，而在 MCP 伺服器端使用任何你想要的功能都非常簡單。所以就像他們只是稍微落後了一點，這可能需要時間。對於其中一些來說，從他們處理推理的一般方式來看，這可能根本沒有意義。但歸根結底，這只是時間問題，等待並觀察有些人會去實現它。事情就是這樣，對吧？
Yoko Li： Sampling 是一個如此有趣的概念，至少當我第一次看到它的時候，我感覺，哦，這太強大了，因為客戶端和伺服器之間的界線不再是物理上的，而更像是邏輯上的。
所以技術上來說，你可以寫一個伺服器，用另一個同時也是伺服器的客戶端進行取樣。我知道這描述起來有點複雜，但你能否舉個例子說明如何最好地使用這種鏈接的伺服器-客戶端組合？以及這與取樣有何關聯？
鏈接伺服器與客戶端的組合
David Soria Parra： 是的，我想你提到了一個非常有趣的點。有趣的是，我們在很早的階段就自己建立了。所以我們有你描述的東西的原型。我稍後會詳細說明這個原型，實際上在我們向公眾發布之前就有了。但你描述的是，你採用一個應用程式，它是一個 MCP 伺服器，向一個 MCP 客戶端暴露工具，但同時，在那個 MCP 伺服器內部，你也在使用一個 MCP 客戶端。所以你也可以向下使用其他 MCP 伺服器。於是你有這個小程序，它同時是一個 MCP 客戶端和一個 MCP 伺服器。我對此的看法是上游和下游連接。
現在你可以無限期地串聯這些東西。無限期地做可能不太實際，但你絕對可以考慮幾個鏈接，甚至可以進一步創建出完整的圖形。你可以很快地設想出這樣的世界：有一個 MCP 伺服器，它有一個代理循環，協調著兩三個其他的 MCP 伺服器，它們的工具執行一個非常好的代理循環。然後你可以將這個由三四個伺服器組成的實體提供給像 Cursor 這樣的客戶端。我認為這是一個非常有趣的概念，感覺非常有代理性，特別是如果你還使用了超越工具呼叫的其他原語，例如資源或提示，這些基本上是 MCP 伺服器可以向上和向下暴露的額外數據流或數據。我認為這樣你實際上可以模擬相當豐富的互動。我很想看到人們更多地嘗試這個，並使用例如像 Pydantic AI 或 LangChain 這樣的 AI 框架來建立客戶端向上、客戶端向下、伺服器向上的連接，然後改變這些東西，看看會發生什麼。然後你就突然自由了，你可以對用戶說，嘿，你希望這個代理控制哪五個 MCP 伺服器？你可能有一個非常通用的代理循環，人們可以去實驗，他們突然可以將，你知道的，貓咪監控軟體連接到一個同時也會說，你知道的，電子郵件、WhatsApp 等等的代理。
對。正如你之前提到的，使用 LLM 進行這些協調任務具有很大的潛力。因此，你可以使用你描述的技術，相當快速地構建這些複雜的系統，這些複雜的代理圖。
資源 (Resources) 與提示 (Prompts)
Yoko Li： 是的，既然你也提到了資源（resource）和提示（prompts），這是規範中另外兩個功能強大但目前未被充分利用的功能，我真的認為這些是 MCP 的潛力股。你是否想簡要解釋一下，開發者如何利用資源，以及提示在其中作為一個概念是什麼？
David Soria Parra： 是的，我可以。是的，很樂意這麼做。當我們思考 MCP 時，需要理解的一點是，MCP 專注於你所暴露的原語如何與另一方互動，通常是使用者，但也可能是代理。而提示（Prompts）則是由使用者驅動的，例如，使用者明確地將其添加到呼叫的上下文中。所以提示是人們可以插入的模板。但有趣的一點是，一方面，它們可以是靜態模板，例如，如何使用這個 MCP 伺服器的範例，但它們也可以非常動態。它們在底層也可以是 API 呼叫。例如，我們有一個 MCP 伺服器暴露了提示，該提示從像 Sentry API 這樣的服務下載堆疊追蹤。所以現在它進入了提示。但我作為另一端的人類，我說我想要這個進入上下文。現在，我不是讓模型決定，而是我決定。這就是提示與工具之間的區別。而資源（Resources），另一方面，它們非常獨特，因為資源只是數據塊。例如，它們可以非常容易地用來向 MCP 客戶端模擬一個檔案系統。在這個描述的使用者驅動、模型驅動的互動模型中，工具是模型驅動的，提示是使用者驅動的，而資源則介於兩者之間，由應用程式驅動，無論那可能意味著什麼。因此，一個應用程式，例如 Cursor，可以選擇說一個資源可以被添加到代理中，類似於你可以將檔案添加到代理中。
但它也可以，例如，做一些事情，像是先將資源攝取到一個 RAC 系統中，然後再進行檢索。對吧。因為這些資源可能是任意長的。所以我們早期在 MTP 中思考的一件事是，你是否真的需要在其中建構檢索功能？我們得出的結論是，嘿，如果客戶端控制檢索部分，資源就可以直接進入這個檢索系統。它可以這樣使用。而如果，你知道，如果你想在伺服器端做，你會使用一個工具。但所以這些是我認為人們還沒有真正理解的區別。它們也像是，這些東西相當豐富。你知道，在新的規範中，工具和資源都可以是音訊，它們可以是圖像。
Yoko Li： 對。
David Soria Parra： 所以人們可以做很多事情。你知道，你可以將你目前的螢幕截圖作為資源暴露出來。我認為這些事情為 MCP 提供了更多有待探索的使用案例。但我理解人們使用工具，因為這是最顯而易見的做法。
Yoko Li： 這是一個非常有趣的觀點。當我第一次看到資源時，我幾乎感覺像是一種思維轉變。
傳統上，作為一名開發者，我總是認為資源應該在客戶端。所以客戶端會暴露資源並在本地查詢它。但在這種情況下，幾乎像是 MCP 伺服器正在暴露一個檔案系統，客戶端可以查詢。
David Soria Parra： 是的。
Yoko Li： 很好奇你對這個模型的想法。你是如何決定它是伺服器端還是客戶端的事情？這對傳輸層意味著什麼？
傳輸層的考量
David Soria Parra： 所以對於，我想最初的模型是像 MCP 一樣，我如何在這些不同的使用者互動模型中提供情境？因此，資源的需求其實很自然地產生了，像是，我實際上如何讓一個本身無法存取本地檔案系統的 MCP 客戶端，但我又想賦予它存取本地檔案系統的能力。現在回顧一下歷史，回到 2024 年 7 月、8 月，Cloud Desktop 還沒有存取權限。你可以上傳檔案之類的。但將檔案系統加入其中並不像現在這麼自然，類似於我們內部可能擁有的一些代理。所以感覺很自然地需要類似的東西。這就是它最初的起源，這些伺服器應該如何提供情境。所以有一些是這樣的。現在談談傳輸層。MCP 最終是獨立於傳輸的，這對我們來說非常重要。所以最初的日期是來自於本地使用案例，我想要使用標準 I/O，它有很多好處，MCP 伺服器的生命週期由客戶端自動控制。它可以做很多事情，但這也意味著你只是，你不能真正說話。技術上你可以說 HTTP，但實際上你說的是類似於基於行的東西，比如說你說的是像 JSON RPC 這樣的東西。這在很大程度上受到了語言伺服器協定（Language Server Protocol）的啟發，它非常非常相似。
它有一個有趣的特性，我如今對此有些矛盾，因為它有一些缺點，並且需要某些在更傳統的 API（如 HTTP 層）中可能會更好的東西，但它仍然允許人們同時在其他傳輸方式上實作 MCP。如果你願意的話。你知道，我曾在 Facebook 工作了 10 年，在那裡你內部使用這些 Thrift RPC 機制，所有的安全基礎設施都是圍繞這個建立的，你可以直接在這個基礎上建立 MCP，而不需要任何改變。你只需要做一個不同的傳輸，雙方仍然會很高興。我的意思是，這就是為什麼。這是我們選擇它的原因之一，因為它的靈活性，部分原因也是因為它是從標準 I/O 到 HTTP 的一個演進。
MCP 的驗證機制
Yoko Li： 是的，這太有趣了。與許多正在建構 MCP 的開發者交流後，最常被問到的問題之一是，我該如何驗證 MCP，包括從客戶端到伺服器，以及從伺服器到工具。是的，我知道有很多很棒的方法可以實現這一點。規範也在不斷發展。所以我想知道，你對 MCP 周圍的驗證機制將如何發展有什麼看法？
David Soria Parra： 哦，這是一個非常有趣且深入的話題。我認為有趣的一點是，每個人都想要授權。我想很明顯，目前人們實際使用的實作方式是本地 MCP 伺服器，也就是透過環境變數給我一個 API 金鑰或某種形式的令牌。這雖然可用，但並不算完美。特別是對於遠端伺服器的情況，這是不可能的。所以我們在規範的早期部分有關於授權的內容，它只是使用 OAuth。這方面有一些需要注意的地方，我們正在與原始的 OAuth 作者和該領域的專家密切合作，以確保其順利進行。但我認為會有。最初的重點是如何驗證使用者，這可能與代理之間如何互動和相互驗證有所不同，但目前還不確定。目前我們想解決的是使用者和人類伺服器的問題。為此，我們會以最佳方式使用 OAuth 規範，因為事實證明，當你在原語和其他層面進行創新時，你會希望在其他所有方面盡可能保持傳統。但授權所做的，當然是它促成了一組截然不同的 MCP 伺服器，因為它促成了遠端的 MCP 伺服器，這些伺服器綁定到公司帳戶，真正由專業服務為你提供你已訂閱的服務。你可以想像。我想 PayPal 就有一個 MCP 伺服器，例如。
你可以看到我想使用這個 MCP 伺服器。我用我的 PayPal 帳戶登入，現在我可以使用這個 MCP 伺服器，而且我已經獲得授權，這開啟了這個我認為在我們日常生活中將非常重要的公司和企業生態系統。同時，你知道，MCP 仍然保留著它最初為開發者所具有的那種自下而上的駭客精神。但就像，授權是邁向這個更豐富的、專業開發的 MCP 伺服器生態系統的關鍵一步。歸根結底，我。
Yoko Li： 我想，當我們談論驗證（auth）時，有兩個層面。一個是認證（authentication），也就是你是否能存取這個東西。另一個是授權（authorization），也就是你被授權存取哪些範圍。這非常有趣，因為我看到這些概念散佈在 MCP 的不同層面。例如，你可以限定對某些資源的存取範圍，比如說我只能存取這個特定資料夾的資源。然後顯然還有第三方驗證，從伺服器到所有 API 供應商。
當涉及到認證與授權時，你是如何思考的？
你希望從外部的驗證供應商那裡看到什麼？
在讓開發者生活更輕鬆方面，什麼最需要幫助？
David Soria Parra： 這是一個很好的區分。好問題。我想我們目前主要關注的是授權。也就是說，我是否被允許存取這個資源？因為這是人們想要的。我們不一定。而且我還沒有看到很多關於認證部分的用例，比如我是哪個身份，我是誰，以及誰是，還有其他相關部分。
我想這會在稍後出現，關於誰代表誰行事。
尤其在代理的世界裡，這將會很重要。但目前，我們一次解決一個問題，先解決最大的障礙。對吧。也就是目前，我如何才能存取某個需要某種形式授權的東西，而我必須做到這一點。所以這就是我們正在解決的問題。因此，我認為目前的重點是百分之百放在授權上。然後我想，從那裡開始，我們未來可能會討論認證、身份以及這些方面的問題。現在對於所有供應商來說，幸運的是，很多大型供應商正在做的事情是，與我們互動，告訴我們每個人都有的共同點是什麼，我們可以以此為基礎，讓開發者對此感到安全。而不是說，哦，你只能用這個供應商的服務，然後跟我們談談。你願意實施什麼？在這個代理的世界裡，授權方面可能缺少哪些東西。幸運的是，他們正在這樣做。目前正在進行的授權規範制定是由 Microsoft、Okta、AWS 在安全和身份方面的非常積極參與的人員共同推動的。
所以，會議室裡已經聚集了正確的人選，他們在很多方面都比我更適合協助我做出這些決定，因為我並非身份和授權方面的專家。所以我只是想聽取更多該領域專家的意見，告訴我正確的做法是什麼，這樣我們才能一起解決這個問題。這才是我真正希望人們做的。對吧？是的。
MCP 在創意領域的應用
Yoko Li： 太棒了。我喜歡這種社群驅動的開發和迭代，以及這個規範。每次我查看 MCP 的規範時，都會有數百個問題。所以我非常敬佩你們日復一日地整理這些問題。另一個我想深入探討的話題，我們之前稍微談到過，就是在創意領域，MCP 是如何運作的，以及有哪些使用案例？因為今天我們看到的大多數客戶端都非常注重開發者。這在新技術的採用週期中非常自然，因為開發者，我們知道如何配置它，我們知道如何放入 JSON blob。但最近我開始看到非常有趣的酷炫使用案例，涉及更多創意工具，如 Blender，你現在可以用文字創建 3D 模型。然後你可以在 Unity 實例周圍使用 MCP 伺服器，你可以擁有自己的合成器，等等。你見過或最興奮、希望人們多加建構的頂級創意使用案例有哪些？
David Soria Parra： 我其實很好奇你稍後的看法，因為你是一個非常有創意的人。
但對我來說，這回到了我喜歡 MCP 的原因：這種彌合你關心的世界和你關心的生活之間差距的能力。所以當我看到，例如 Blender MCP 伺服器，我認為這是最初幾個大型伺服器之一，或者有一個是某人將 Claude 連接到 Ableton，我只是覺得這非常迷人且非常酷，因為一方面，我對 LLM 實際上如此擅長此事感到驚訝。
而且你會感到驚訝，因為這是 LLM 你在沒有 MCP 的情況下永遠不會看到的一面。但另一方面，我只是喜歡連接這些工具的創造力，然後真正從中獲得一些有用的東西。當然，這是一個創作過程。而且你知道，這比其他的更好。作為一個有創造力的人，每個藝術家都希望擁有控制權。LLM 和 MCP 並沒有給你這個，但它給了你一組不同的介面來處理某些事情。我認為嘗試如何描述，例如，一個 3D 環境，是非常有趣和有創意的。而且我認為這是一件非常獨特的事情，因為一個在 Blender 中工作的環境藝術家可能從未有過用語言真正表達自己的能力。甚至可能，你知道，你如何寫一首詩並將其轉換為 3D 環境？這超級有趣。然後當然你想回到 Blender，因為你需要控制。但我認為這是一個非常有趣的練習和實驗，我認為它能幫助創作者以不同的方式看待事物，如果有的話。是的。然後當然，你知道，我，我喜歡合成器。我，你知道，我自己是個糟糕的音樂家，但我喜歡它們。我的意思是，我喜歡人們例如用 Claude 在實體合成器上編程音色的這個想法。這對我來說簡直太迷人了，Claude 能做到這一點，但同時看到人們想到將 LLM 連接到世界上一個能發出聲音的實體東西，也非常酷。
所以我喜歡那部分。但我很好奇你對此的看法，因為你是一個非常有創意的人，你是如何看待這個的。
Yoko Li： 你知道，我一直在思考很多，大致上和你提到的客戶端輸入有關。今天輸入主要是文字。所以我們描述我們想看的東西，但我們知道文字和動作或視覺效果從來不是一對一的。所以用文字描述一個起始模板非常酷，但之後的迭代必須由藝術家的選擇來決定。例如，我是 Procreate 的重度使用者。然後在 Procreate 中，你並不是真的描述你想看的東西，你只是畫出你想看的東西。其中很多是由我大腦中的潛在空間控制的。像是我的大腦並不是在描述我應該畫什麼。對。那不是我的模型運作的方式。它更像是控制肌肉來決定如何畫這條曲線的弧度。什麼顏色對我來說好看。所以在某種程度上，我幾乎覺得 MCP 客戶端嚴重地決定了整個體驗會是什麼樣子。例如，如果客戶端傳送一些貝茲曲線到伺服器，然後讓伺服器決定，這對你來說看起來好看嗎？
這並不是我們經常看到的。所以今天，程式碼或語言的輸入非常普遍。但未來，我想知道如果每個設計工具都變成 MCP 客戶端，我們會有什麼樣的體驗。
David Soria Parra： 我不知道。我完全不知道這會是什麼樣子，但我認為這是一個非常有趣的思考練習。
代理的終極溝通機制
Yoko Li： 是的。這裡有一個關於代理的哲學問題，基於我們剛才談論的一切，那就是，你認為代理的終極溝通機制或模式是什麼？一方面我們有自然語言，另一方面我們有程式語言。我的意思是，技術上我們可以將世界上所有的問題都框架化為一種程式語言，如果該語言支援的話。然後另一方面，我們有像素、螢幕截圖，有時還有影片作為輸入模式。
根據您在 MCP 伺服器和客戶端互動中所見，您認為哪種抽象層級是為代理提供所有必要情境的最佳方式或絕佳方式？
David Soria Parra： 我想是的。
是的，如此有趣，如此有趣的一點。我想是的。
我想我不知道是答案的一部分，但我認為真正的答案是可能有一組。兩者可能都有其優點。我認為程式語言是代理之間非常好的互動模式，因為關於密集的數學，但你知道，語法形式略有不同，其意圖非常非常清晰，並且在某種程度上受到約束，程式語言就是這樣。然後是非常自由形式的，你知道，自然語言。我個人認為僅僅自然語言是不夠的。這是我個人的看法。兩者的結合可能是正確的，我想。所以，我沒有真正的答案，因為我覺得現在判斷還為時過早，我想看到這個領域再探索一下。所以我，當我觀察這個領域的發展時，我覺得現在判斷正確的抽象層級是什麼還為時過早。但我認為像 MCP 這樣的東西讓人們能夠實驗不同的事物。當然還有其他現有的語言框架和這個領域的其他一些東西讓人們能夠實驗。但我認為還需要進行更多的實驗才能真正理解實際的通用抽象應該是什麼樣子。如果你在 MCP 會留存下來並持續存在的假設下思考 MCP，正如我所希望的那樣，MCP 已經存在了兩三年，用於工具呼叫。所以我們以前已經看過很多這樣的互動了。
我們有一個比較通用的抽象概念，但我認為對於代理程式來說，我們現在還處於太早的階段，無法看出它會是什麼樣子。但我同意你的觀察，有這麼多不同的模態和不同的選項，就像。而且我剛才只談到了文字方面，對吧？你已經提到了像素和其他位元。所以我認為有這麼多有趣的溝通空間。誰知道呢，也許模型真的喜歡透過視訊串流來談論事情。我們不知道，也許，也許在動物模態中。我們最終得到的只是到處都是視訊串流，因為它們就喜歡看事物的視訊圖片。
Yoko Li： 這太有趣了，你知道，這些模態在我做很多隨機的副專案時互相滲透。其中一個叫做 AI Tamagotchi。所以它基本上是一個 AI 驅動的、有狀態的 Tamagotchi。所以 Tamagotchi 不再只是吃一樣東西，它可以要求 10、20、50 樣東西，任何 LLM 狀態允許它做的。我意識到的一件事是，我可以使用現在大多數的模型來生成 ASCII 藝術，甚至是 ASCII 動畫。然後當我思考這個問題時，幾乎感覺像是一個視覺任務，但像語言模型仍然生成一系列的符號。
然後如果我把任務交給，比如說一個擴散模型，它並不是真的生成一個符號，而是生成像素。所以問題是，生成一系列圖像或一系列 ASCII 字元來製作像這樣的動畫，哪種方式更好？
所以它真的。
David Soria Parra： 你發現了什麼？你對此有何看法？
Yoko Li： 我其實認為 ASCII。對於這些有狀態的、非常可預測的動畫序列，我目前其實更傾向於語言模型。感覺這就像是，你知道，一種我沒想到會奏效的模式，但它確實奏效了，因為預測下一個符號，結果也適用於預測下一個 ASCII 字元。
David Soria Parra： 有很多事情，如果你思考一下，你知道，像是 Transformer 模型和注意力機制，你知道，它們會適合。像是這些序列性的東西，用它來生成可能效果不錯。是的，敏銳的觀察。
Yoko Li： 是的。然後有趣的是，我嘗試了很多不同的生成任務。它最擅長生成貓。這就是為什麼我在網路上搜尋。ASCII 貓在數據集中真的很有代表性。
這其實把我，我們的代理聊天，帶到了另一個比較高層次的問題。
MCP 的未來：解決什麼與不解決什麼
當你思考 MCP 的未來時，你想解決什麼問題，你想繼續發展什麼，你不想解決什麼？因為感覺很多事情都可以是 MCP 規範的問題。對吧。你可以實作 RAC，你可以實作資料庫，你可以實作世界上任何東西。所以我想，你是如何思考的，你想繼續執行哪些事情，以及你覺得哪些任務根本不屬於規範應該處理的範圍？
David Soria Parra： 是的，這是一個非常好的、非常有趣的問題。我想每個制定規範的人都會面臨這類問題，你必須堅持自己的立場，專注於你想擅長的領域，而不是試圖包山包海，什麼都想嘗試。我想對於 MTP，有幾件事。我想 MTP 目前的部分有演進空間，我認為在授權和其他相關部分有非常清晰的演進路徑。但然後我想，在代理方面可能還有一些更多的抽象空間。但這是一個信念度還很低的觀點，因為我再次回到，我需要再觀察一段時間，而且我覺得我真的想探索這個領域。
Yoko Li： 我想在這裡問個問題。你如何定義一個代理（agent）？
David Soria Parra： 是的，我不會深入討論這個。
你認為呢？你認為什麼是代理？
Yoko Li： 我不知道。我認為它是一個多步驟的 LLM 推理鏈。對我來說非常簡單。
David Soria Parra： 好的。是的，好的。我想我可以接受這個說法。我可以接受這個說法。我想對我來說，代理可能更像是這個詞本身所含的「代理權」（agency）的意思。所以是某種能進行自主協調或自主解決任務的東西，通常任何多步驟的事情對我來說，目前都已經像是個代理了。當它執行了兩個步驟，並且對第一個步驟做出反應時，它基本上就是一個代理，因為它現在對自己正在做的事情擁有一些代理權。所以我認為，歸根結底，對我來說，大部分是這樣。但是關於代理的定義有很多，所以我認為在這方面有潛力可以思考。我認為 MCP 在某種程度上處於有利位置，因為它允許這些圖形。我認為 MCP 內在間接促成的一些圖形片段也可以是動態的，我認為這是它一個非常有趣和獨特的部分。所以也許在代理方面會有一些進展，我還不太確定，但這絕對是我會關注的事情。除此之外，我認為目前其餘的都只是演進，像是串流和其他基於模態的方式。我認為 MCP 還有其他有趣的方面，比如像這樣的功能如何潛在地適應其他非純文字模型的模型類型？我認為這是一個長遠來看有趣的問題。所以這對於視訊、音訊、圖像等等會是什麼樣子？我不知道這是否有用例，或者類似的東西。而且那不一定是 MCP。
但我認為思考不同的模態是一個有趣的問題。但是，是的，再次強調，我認為大部分情況下是模態。如果演進，那麼，你知道，也許有一個很大的「也許」，一個很大的問號，關於我們是否需要更多用於代理的支援，或者代理是否已經可以很好地用 MCP 的抽象來表達。再次強調，這又回到了實驗。
Yoko Li： 那聽起來像是一個非常有趣的實驗。
David Soria Parra： 這確實很有趣。是的。
單一代理與多代理協作
Yoko Li： 我經常嘗試重構我的程式碼，然後嘗試將單一代理重構為多個代理，例如五個代理。我指的只是多次呼叫來決定鏈上的事情。然後有趣的是，大多數時候，對於我嘗試做的任務，都非常簡單，你知道，發送一封電子郵件或 ping 某人，以及非常長的交易工作負載。單一代理運作得非常好。所以我自己還沒有遇到過需要多個代理協作的用例。這像是一個非常複雜的任務。但你對此有何看法？你覺得我們會深入研究單一代理，就像。這幾乎像是一個技術細節，像是帶有 LLM 的單一呼叫圖。還是你覺得會是多個流程協同工作？
David Soria Parra： 對我來說，其中一個觀察是，我認為代理的差異性與其說是任務的不同，不如說是信任邊界的差異。如果你有一個旅行代理，它需要存取你的銀行帳戶或類似的東西，那麼在信任邊界方面可能會有一些有趣的點，這正是協定希望介入的地方，而不是僅僅使用相同的框架或其他東西。所以我確實覺得會有一些基於這些信任邊界的組合性，因為你最終可能會想使用你的銀行為代理提供的任何介面，而不是其他任何東西。
所以這裡有一個界線，這個需要與其他東西互動。所以這些事情會發生在世界上一些需要更多信任的部分。我想除此之外，要看這些會如何發展就有點棘手了。我完全可以理解一個單一代理或代理框架會非常強大。但是，再次強調，對於非開發者的用戶來說，可組合性，能夠更換東西的能力，我認為在某種程度上會非常有用。而且我認為還有一個問題是，是否會有兩三個元代理來驅動其他 MCP 形式的組件，或者所有東西都會非常專業化，然後，你知道，你讓開發者來建構這些不同的代理。所以這是一個有點複雜的問題，我會把它歸結為實驗。但就我目前的使用案例而言，很多這些單一代理、少量互動就能完成我需要的所有事情。但然後我。我想這和你說的類似。但我們也還處於非常非常早期的階段。對。真的在探索代理，而模型正處於這些東西變得非常強大的階段。所以我們拭目以待一年後會是什麼樣子。但再次強調，我認為信任邊界是一個我會關注的有趣點。然後是一個代理如何代表另一個代理在這些方面行動？我認為那裡可能需要協定。
社群貢獻與協作
Yoko Li： 太棒了。太棒了。嗯，我想最後一個問題。我從第一天起就非常喜歡 MCP 作為一個開放協定。因此，你們聚集了一個龐大的社群，大家都在貢獻、提供建議。
當您思考 MCP 下一階段發展最需要幫助的地方時，您能否多談談您認為哪些方面需要更多貢獻者？人們如何聯繫您？人們如何就規範或其他與規範相關的事項進行協作？
David Soria Parra： 是的，我想就貢獻而言。目前我們將其作為一個非常傳統的開源專案來運作。所以我們尋找的是維護、協助、撰寫問題、審查問題、審查 PR、撰寫 PR 的人，並與我們這些維護者建立信任，希望能長期幫助我們。所以我們尋找的是那些只想在社群中活躍的人，無論是由公司驅動還是個人驅動，對我們來說都無所謂。所以這很大一部分是去處理 Python SDK 的問題，在那裡幫助人們，去重新實作一些錯誤，看看它們是否真的是問題，並獲取更詳細的資訊，在必要時審查 PR，可能更好地撰寫 PR 並修復錯誤。我認為這些都是很好的起點。
當涉及到規範本身時，門檻會更高一些，標準也會更高。所以在這方面，如果你能解決一個非常具體的需求，或者為其撰寫一份非常詳細的 RFC，那可能會在那裡放一段時間，如果你是一家公司，你可能會為此爭取一些支持，然後一起來找我們，我認為這會很有幫助。所以我認為這些都是很好的起點。所以它的運作方式非常像一個傳統的專案。我們正在研究更具可持續性的長期治理模式，更像是共識驅動的模式。所以我們將朝著這個方向努力。
但是，是的，除此之外，就來幫忙寫程式碼吧。規範本身有點難以處理，但除此之外，你知道，如果你有強烈的意願，也儘管去做。然後，是的，建立信任。你知道，我們有很多人在幫助我們。你知道，例如 Pydantic 的人，他們在 Python SDK 方面做得非常出色。Microsoft 的人在授權規範方面做得非常出色。Okta 的人和 AWS 的人也是如此。所以已經有很多事情在發生了。我們有一些社群貢獻者，我真的非常感謝他們。所以，是的，就去幫忙，和我們一起工作。這就是我們目前最需要的。
Yoko Li： 這太棒了。我非常享受這次對話。這次聊天內容包羅萬象，從 Tamagotchi 到貓咪監控應用程式，再到 MCP 協定及其未來發展，真的非常有趣。非常感謝 David 抽出時間，下次再聊。
Podcast Narrator/Host： 就這樣，又一集節目結束了。感謝您收聽到底。如果您喜歡這一集，請務必給予評分、評論並在您的朋友和同事間分享這個 podcast。並請繼續收聽更多關於代理和其他精彩內容的討論，我們保證，以及更多與 AI 領域創辦人和建構者的深度訪談。