6 月 24 日，谷歌雲官宣將 A2A（Agent-to-Agent）協議捐贈給了 Linux 基金會，訊息一齣引發了 AI 行業地震。這份包含智慧體互動協議、SDK 和開發者工具的開源禮包，背後站著亞馬遜、微軟、思科等科技巨頭組成的“全明星”陣容。
Google Cloud 副總裁兼商業應用平臺總經理 Rao Surapaneni 表示：“透過與 Linux 基金會和領先的技術提供商合作，我們將在值得信賴的開放治理框架下，實現更具創新性和價值的 AI 功能。”
在外界看來，谷歌雲捐贈開源 A2A 的決策有點耐人尋味。在 Reddit 平臺，有評論認為谷歌這麼做是對 Anthropic MCP 協議、OpenAI 函式等競品的戰略應對，但同時也揭示了行業共識：智慧體經濟需要共建底層規則。
也有使用者認為，MCP 已經起飛了，A2A 才開始追趕。
甚至有人厭倦了谷歌，認為 A2A 不會成功。
在 A2A 協議引發熱議的同時，MCP 已經在企業級市場悄然生根。與 A2A 側重智慧體間通訊不同，MCP 解決的是更基礎的問題：如何讓 AI 模型安全高效地呼叫現實世界中的工具和服務。就像人類需要螺絲刀才能擰螺絲，AI 智慧體需要 MCP 才能操作企業 API、資料庫等數字工具。
那麼，開發一款 MCP Server 關鍵環節有哪些？在接入企業內部系統時 MCP Server 需要做哪些適配工作？MCP 協議與 A2A 協議的區別是什麼，未來發展方向在哪裡？
為了解答上述問題，我們採訪了騰訊雲資深產品技術專家汪晟傑和騰訊雲資深後端技術專家郭偉，聽他們深入剖析 MCP 技術的核心邏輯與未來趨勢。
郭偉：我們可以從兩個場景來分析。對於企業內部，尤其是從事 SaaS 業務的企業來說，它們本身已經擁有眾多 API。在這種情況下，關鍵在於如何將現有的 API 轉換為 MCP 服務，並對外提供服務，尤其是向外部的 Agent 提供服務。這種轉換的核心在於將 API 的協議出口轉換為 MCP 協議。
在這一過程中，最為關鍵的是對 MCP 中包含的各種工具進行詳細描述。這包括工具的功能、引數的作用以及輸入輸出的具體內容。只有這樣，代理或關聯的大模型在獲取到 MCP 服務後，才能清楚地知道何時以及如何使用該服務。
簡而言之，核心要點在於：一是將現有的 API 轉換為 MCP 協議；二是在轉換過程中，詳細描述工具的功能和使用方法。由於這只是一個介面轉換的過程，因此耗時相對較短，一天內可以完成幾個介面的轉換。對於原本就提供 SaaS 服務 API 的企業來說，這是一個相對簡單的過程。 還有一種從零開始的情況。
例如，一些創業者可能有一些想法，希望透過 MCP 服務，尤其是結合大模型或代理的場景來實現。在這種情況下，邏輯與前面提到的類似，但創業者需要首先明確其核心業務邏輯，即他們希望透過 MCP 服務向外界提供什麼樣的服務。
一旦明確了業務邏輯，創業者就可以跳過 API 開發的步驟，直接將 MCP 工具暴露給外部使用。這種情況下，創業者需要從頭開始構建業務邏輯，而沒有現成的 API 可以利用。從耗時角度來看，業務邏輯的開發是最耗時的部分。
在 MCP 服務開發過程中，除了業務邏輯外，還需要花費更多時間撰寫工具描述。這是因為一個好的描述能夠讓代理清楚地瞭解如何使用 MCP 服務。此外，創業者可能還需要針對不同的模型進行測試，例如 DeepSeek 或千問等，以找到最適合的描述方式，然後才能正式釋出。
汪晟傑：如果客戶內部已經有一套對服務或 API 的處理體系，那麼最好的辦法是儘量保持原狀。我們只需將最外層的介面進行轉換，將 API 對接到 MCP，這應該是最合理的方式。儘量不要干預企業內部的治理生態，因為其內部的運維、安全以及一系列流程可能已經執行得相當成熟。核心問題在於我們自身企業對外的 SaaS 能力，如何讓 Agent 更好地發現和使用這些能力，這主要取決於我們如何編寫工具的描述。
在完成服務對接後，可能會出現執行效果不如預期的情況。這並非因為其他問題，而是更多地在於模型以及工具描述的準確性。以 DeepSeek 為例，在早期版本中，工具的發現和支撐需要我們公司提供的描述儘可能精確，包括輸入輸出和使用方式的描述。這是一個需要花費時間磨合的過程。
郭偉：在實際應用中，我們確實遇到了一些相容性問題，尤其是在與不同型別的人工智慧模型進行整合時。例如，國內的大語言模型在處理中文內容方面表現得非常出色。如果我們的 MCP 主要面向國內的大模型或相關代理進行開發和使用，那麼使用中文來編寫工具描述是可以接受的。然而，如果是針對國外的大模型，我們通常會推薦使用英文來編寫工具描述，因為這是主要的差異所在。
在我看來，使用各種模型進行多次測試是非常必要的。目前，國外和國內的大模型在工具規劃能力上仍然存在一些差異。例如，某些在特定領域表現優異的模型，如 Claude，在處理程式碼相關服務時規劃能力較強，因此使用這些模型可能會更加簡單。我們需要根據具體的應用場景和領域進行選擇和磨合。例如，對於開發類的 MCP，Claude 可能會表現得更好；而對於其他型別的 MCP，如查詢天氣或烹飪相關的服務，GPT 可能會更加適用。
汪晟傑： 目前我的感受是，解決這一問題的關鍵在於，要進行儘可能多的測試。無論是我自己使用，還是為他人提供服務，我都傾向於進行多次測試，以觀察不同情況下的表現。
在測試過程中，我會選擇不同的大模型，並準備一些固定的輸入和輸出來進行驗證。因為在開發 MCP 時，我們自己也是使用者，通常會從使用者的角度出發，將請求傳遞給大模型。大模型會將這些請求轉化為具體的使用者意圖，然後呼叫 MCP。
經過大模型處理後的使用者意圖往往已經比較明確，因此在測試 MCP 時，我們可以準備幾種不同的輸入，透過不同的大模型來觀察輸出結果，從而調整工具的描述。本質上，清晰的描述與模糊的描述之間存在很大差異，清晰的描述能夠更好地讓系統理解我們的意圖。
從第一性原理出發，首先需要關注的是 API 的設計。API 應該是正交的，即每個 API 的功能應該是獨立且高內聚的，而不同 API 之間則應儘量解耦。以人類的視角來看，一個設計合理的 API 應該是清晰且易於理解的。這是第一步，也是避免 API 功能重疊或混淆的基礎。例如，我們不能讓一個 API 的功能可以透過另一個 API 實現相同的效果，必須確保 API 之間的功能劃分明確。
其次，是關於描述的問題。在設計 API 時，我們需要明確初衷，清晰地說明每個 API 的用途、何時使用以及預期輸出。例如，如果我們要查詢使用者的非敏感資料，必須明確告知使用者何時可以發起請求，以及我們將提供什麼樣的資料。不能含糊其辭，比如僅僅將介面命名為“查詢使用者資料”，尤其是當存在多個類似介面時，如“查詢使用者手機號”或“查詢使用者在某地的手機號”等，這種命名方式可能會讓人感到困惑。
因此，在確保 API 正交的前提下，我們需要儘可能清晰地描述每個 API 或工具的使用場景、使用方式以及預期輸出。這實際上是一種架構思維在人工智慧領域的體現。
我們可以這樣理解：如果一個 API 能讓人類使用者感到清晰易懂，那麼大模型大機率也能更好地理解和使用它。
郭偉：確實是這樣。如果描述不夠清晰，模型在執行任務時就會出現大量的預測或嘗試。從 MCP 後臺可以看到，這種情況下會產生大量錯誤。有些錯誤非常明顯，比如當 MCP 需要完成特定功能，明確所需輸入和輸出時，如果描述不清晰，大模型可能會隨意生成一個使用者 ID 或其他資訊進行嘗試。通常情況下，這會導致報錯，提示某些內容不清晰。模型在收到反饋後，會嘗試用正確的方式重新訪問。
這種情況下，通常會反映出我們自己的 MCP 主控器存在問題。簡單來說，我們可以通過後臺監控訪問失敗率來發現問題。如果訪問失敗率很高，尤其是出現 400 類錯誤，這說明介面的填寫可能存在問題，MCP 可能不夠友好。
這時我們會採取一些改進措施。因為我們清楚輸入和輸出的具體要求，所以在出錯時能夠快速定位問題所在，並對描述進行最佳化，使其更加清晰。例如，早期在使用 MCP 時，如果描述不夠好，大模型在 Github 嘗試提交 issue 時可能會隨意生成一個倉庫 ID，這通常會導致 404 等錯誤。但透過不斷迭代和最佳化描述，這些錯誤會逐漸減少。
一旦描述得到改進，線上效果會很快顯現，400 類錯誤會明顯減少。 在金融等對即時響應要求較高的行業場景中，資料傳輸和處理的時效性至關重要。
今年 3 月，MCP 釋出了一個新版本，支援“Streamable HTTP”的協議。這個協議有三個特點：首先，它是一個有狀態的協議，可以選擇有狀態或無狀態；其次，它能夠實現伺服器端的主動通知；最後，它支援流式輸出。回到高響應場景，通常介面在服務端是透過條件語句（如 if）實現的，當資料端發生變化時，會透過回撥或長連線的方式將資料傳遞到服務端。
對於 MCP 來說，這個新協議能夠實現類似的效果。當 API 服務收到最新的變更資料或需要即時展示的資料時，可以透過狀態管理和伺服器端通知機制，讓 MCP 客戶端快速接收到訊息。目前，流式輸出的應用場景還比較少，大家都在探索中。
未來可能會在 Agent 與 Agent 之間即時通訊的場景中出現這種需求。目前，大家還在探索如何在接入新資料來源時自動感知並進行配置。雖然 MCP 協議支援這一功能，但具體的使用方式還在探索中。這種機制類似於早期的訊息推送，就像手機上將訊息從後臺推送到 App 一樣。
汪晟傑： 一般來說，大家都是透過 Agentic 的方式來完成這項工作。例如，在訓練過程中，我們會將訓練任務作為一個 agent 來進行統一規劃，而將每個任務的具體執行交給 MCP 來完成。本質上，這和過去我們在訓練過程中執行指令碼的方式類似，只是現在我們將指令碼轉化為 MCP 的形式。
MCP 執行一段時間後會產生結果，然後將結果反饋給 Agent，Agent 再根據這些結果進行進一步的判斷和決策。
簡單來說，我們把過去需要人工執行的任務，透過指令碼的形式轉化為 MCP 來實現自動化。然而，在訓練過程中，例如一批批地訓練資料，無論是用於預訓練還是後訓練，這些過程本身是無法透過 MCP 進行干預的。從任務開始到結束，雖然最終可以透過 MCP 進行簡單的測試以驗證效果，但整個過程的自動化是透過將人工操作轉化為 Agentic 過程來實現的。
在這個過程中，Agent 技術是不可或缺的。從某種意義上說，人本身也可以被視為一個 Agent，而 MCP 則是工具。
郭偉：對於一個 Agent，從簡單角度來看，它實際上可以被理解為提示詞、工具、大模型以及儲存的結合。在構建 Agent 時，我們首先需要從第一性原理出發，就像人類處理任務一樣，明確目標和任務的拆解，這對應於 prompt。
其次，我們需要確定在執行任務過程中需要哪些工具，這些工具可能包括指令碼或 API。
最後，在儲存方面，情況可能會相對複雜。對於知識類或相關性極強的知識，我們需要考慮長期儲存的解決方案；而對於短期儲存需求，我們可以利用快取機制來解決這些問題。至於大模型的選擇，這取決於具體的應用場景。例如，在開發類任務中，像 DeepSeek 或 Claude 這樣的模型可能是合適的選擇。
而在其他場景下，可能需要根據具體需求選擇不同的模型。這實際上取決於我們對人工智慧行業的瞭解程度。完成這些準備工作後，我們就可以快速地開發一個 Agent。
目前市面上有許多現成的框架可供選擇，例如谷歌推出的 Google Agent Development Kit (ADK)，微軟的 AutoGen 框架，以及基於圖結構的 LangGraph 框架等。這些框架為我們提供了豐富的選項，我們可以根據具體需求自行選擇和使用。
汪晟傑： 如果由人來完成這項任務，那麼本質上是基於預定義的流程來操作。而如果交給機器，也就是 Agent 來完成，那麼它將基於整體的判斷來進行任務拆解與協作。
可以從幾個角度來考慮。首先，如果任務可以用人來完成，並且流程比較清晰，那麼最好儘量使用一些開發工具將這些流程固化下來，讓人工來操作。這是一種既經濟實惠又高效的方法。其次，如果發現人工操作比較麻煩，但任務確實可以清晰地描述出來，包括在各種情況下應該如何處理，雖然人工完成起來比較費勁，但仍然可以完成，那麼在這種情況下，可以考慮使用 Agent。
不過，使用 Agent 的代價可能是成本稍高，且速度較慢，因為 Agent 的每一步都需要向大模型詢問下一步該如何操作，而大模型每次理解任務都需要時間。相比之下，人工操作可能一次性就能高效完成，並且速度更快。
我的觀點是，對於容易解決的任務，最好由人工來完成；而對於難以解決的任務，則可以考慮使用 Agent。例如，當遇到一個任務時，需要選擇使用哪些知識庫，先根據相關性來篩選知識庫，然後再檢視結果。在這種需要進行深度思考的情況下，人工操作慢，而 Agent 在這種複雜任務中可能更有優勢。但如果任務的步驟可以明確地分解為第一步、第二步、第三步等，那麼就沒有必要每次都讓 Agent 去逐步拆解任務，因為這樣成本較高。
總結起來就是，這是一個需要權衡的問題，並沒有一個絕對的標準。通常來說，如果任務可以清晰地交代清楚，並且相對簡單，那麼最好由人工來完成。尤其是對於開發類任務。對於訓練任務，因為很多內容都是固化的，如果沒有進行 A/B 測試等複雜操作，Agent 可以快速搞定。最簡單的方式就是使用一個固化的 workflow 來執行任務。
郭偉：MCP 本身的標準並非旨在直接解決資料治理的問題。它是一類工具，用於解決特定型別的問題。例如，如果企業的目標是透過 MCP 解決內部治理問題，那麼首先需要明確的是，如果由人來解決這個治理問題，應該如何操作。想清楚這一點後，就可以將散落在各處的資料以及其他相關資源進行整合，形成一些對內的介面。
這些介面可以轉化為 MCP 的一部分，以便於使用者在進行查詢或進一步對外展示時，能夠實現資料的聚合。MCP 本身無法直接解決資料整合的問題，仍然需要一箇中臺或者統一的接入層來打通散落在各處的資料。透過 MCP，將這些資料整合後提供 SaaS 服務。MCP 的作用在於，如果使用者想要進行資料治理，而這些治理工作是可以被描述並由 AI 完成的，那麼就可以將這些治理工具轉化為 MCP。交給大模型的前提是，這些工作是人能夠完成的。
大模型本質上是對人類行為的模仿，是對人類能力的一種泛化。只有人類能夠完成的任務，大模型才有可能去執行。
郭偉：從實際應用的角度來看，如果一個模型已經具備了某種能力，並且這種能力隨著時間的推移不斷增強，例如其規劃能力等，那麼對於一個已經存在的大模型，我們通常只需要進行一次適配，基本就能滿足需求。當然，未來如果該模型推出了新的版本，我們可以評估是否可以進一步最佳化，以更好地利用這個大模型。這通常是我們的經驗之談。
如果出現了一個全新的模型，比如行業突然出現了一個類似 GPT 那樣具有巨大影響力的模型，那麼我們就需要自己進行適配了。但是一般的經驗是，一旦完成適配，後續就無需頻繁地進行調整。我們只需關注該模型的升級動態，因為通常情況下，隨著模型的不斷最佳化，其效果會越來越好。
郭偉：我認為應該從幾個層面來考慮這個問題。首先，對於隱私資料，我們應儘量避免透過 MCP 的方式提供，例如手機號、銀行密碼等敏感資訊。一旦這些資訊透過 MCP 提供出去，一方面會被使用者獲取，另一方面也可能出現在與大模型聊天的上下文中。在執行任務時，大模型可能不僅會呼叫一個 MCP 工具，還可能呼叫其他工具。如果有一個 MCP 服務描述中提到獲取手機號或銀行卡號，大模型會直接將這些資訊傳遞過去。因此，第一個要點是敏感資料絕對不能放在上下文中，也不能作為輸入或輸出來使用，這是基本原則。
其次，對於非敏感資料的授權使用，可以透過現有的身份驗證和授權機制，如 OAuth 2.0 或 OpenID Connect，來管理使用者許可權。企業可以在使用者透過單點登入（SSO）後，利用現有的許可權模型來約束使用者對 MCP 服務的訪問，確保資料的安全使用。
郭偉：從本質上講，MCP 和以往的函式呼叫並無二致。如果以前的函式呼叫主要服務於 OpenAI，那麼 MCP 則是面向所有人開放的。本質上，這可以看作是一個通用介面與專用介面的問題。但它們都可以被統稱為模型所需的工具。
在這種情況下，我覺得沒有必要糾結於 MCP 或函式呼叫，因為無論是哪種方式，工序描述本身都是必須書寫的，這是無法迴避的。在與大模型互動時，我們需要明確告知模型在何種情況下使用內建的 MCP，以及何時呼叫其他功能。這種工作量是客觀存在的。我們應更多地關注工具描述本身該如何撰寫，而不是糾結於誰來寫或何時寫。
汪晟傑：MCP 主要解決的是工具層面的問題，而 A2A 則側重於生態層面的構建。對於大語言模型來說，它們在過去只能進行基於知識的問答。然而，隨著 Agent 技術的出現，這些模型開始能夠接觸物理世界，並透過工具來執行各種任務。但這些任務往往是單一的，這就引出了一個問題：世界上是否只需要一個 Agent 就足夠了？顯然，答案是否定的。每個 Agent 都有其特定的目標和明確的提示詞，當用戶給出特定輸入時，Agent 會返回一個特定的輸出，這個輸出可以是一段文字、一張圖片或其他形式的內容。這就是 Agent 的使命。
MCP 的作用在於為這些具有特定使命的 Agent 提供必要的工具。從 A2A 的角度來看，其核心在於促進不同 Agent 之間的相互通訊和相互發現。例如，一個團隊的負責人想要承接一個裝修專案，他需要到人才市場尋找各種工種的工人。A2A 透過為每個 Agent 提供一個“名片”（agent card），明確每個 Agent 的能力、作用以及訪問方式，使得每個 Agent 都能清楚地展示自己的功能，並將其放置在各自的伺服器上，供所有人訪問和了解。
A2A 的另一個重要作用是實現不同框架的 Agent 之間的通訊。目前，無論是谷歌、微軟等大公司，還是開源社群，都提供了各種 Agent 框架。A2A 的目標是讓這些不同背景的 Agent 能夠相互協作，就像不同學校畢業的人最終都要進入職場一樣。在這個過程中，AtoA 提供了一個平等的協議，使得 agent 們能夠進行有效的通訊和協作。 此外，還存在一些特殊的工具，它們既是 Agent，又是 MCP。這與人類社會中的某些角色類似，它們的輸入是自然語言，輸出是某種作品，但它們以工具的形式展現。在這種情況下，它們既是 MCP，又是 Agent，但與 A2A 相比，還是存在明顯的差異。這些工具更強調執行能力，而不是規劃能力。
總的來說，MCP 和 A2A 在生態層面有不同的側重點。MCP 專注於解決個人工具的問題，而 A2A 則致力於構建一個能夠促進 Agent 之間協作的社群或團體。
郭偉： 我們肯定有這樣的計劃。目前，我們主要專注於開發類工具，例如程式碼開發。從產品研發流程來看，包括產品設計、程式碼開發以及最後的程式碼漏洞檢測等環節，這些流程本身就非常適合多 Agent 協作。當我們擁有多個 Agent 時，如何實現更好的通訊就成了我們選擇框架時需要考慮的問題。在這種情況下，A2A 是一個比較好的選擇。從我們的角度來看，我 們不僅不排斥，而且非常願意接受這種生態。
汪晟傑：從產品層面來看，我們首先從 MCP 的角度進行規劃。我們計劃將騰訊自身的一些產品、雲廠商提供的基礎設施以及開源元件整合到 MCP 中，使其成為一個強大的工具集合。我們的目標是在 AI 場景下輔助並提高軟體開發的效率，甚至讓 AI 承擔一些重複性工作，而人類只需對最終結果進行確認。
為了實現這一目標，我們需要模仿人類在開發過程中使用的工具，因此 MCP 將包含與研發、設計、需求分析等相關的一系列工具和技術。這就是 MCP 為我們帶來的價值。 在企業環境中，工具並非孤立存在，而是被共享使用的。企業團隊通常有一套自己的研發規範、第三方業務系統以及與其他工具和內部產品的對接。這些工具本身可以被視為智慧體，因為不同的產品也會整合大模型，並具備自己的邏輯。例如，企業可能有一些核心程式碼庫的理解，專門用於資料分析和採集。在實際業務中編寫程式碼時，我可能是一個編碼智慧體，而我可能需要與其他智慧體協作。
A2A 本質上是一種帶有協作流程的感知，人類在其中扮演代理的角色，對智慧體的輸出進行確認。例如，我開發的一個 A2A 智慧體如果要參與到 A2A 協議中，就需要讓兩個智慧體之間能夠交換身份或約定，使資料能夠流通，從而發生協作。這樣，我們就可以將協作範圍擴大，而不僅僅侷限於本地工具。我可以透過服務發現的方式找到企業中的其他智慧體，並與它們協作，使整個流程更加廣泛。
以我們正在開發的 IDE 為例，它本身就是一個多智慧體架構。設計階段可以透過 Figma 等工具進行元素提取，而這些提取並非完全基於規則，而可能是一種智慧體，能夠理解元素的核心點。在生成程式碼之前，它會進行資料清洗，將元件轉換為前端可理解和使用的約定語言。這些語言並非 HTML，因為 HTML 是一種設計性語言。當資料到達前端輸入點時，它與我交換的協議不僅僅是 HTML，還可能是圖形之間的結構、跳轉、色號色系以及前端所需的框架元件。這些設計元素由智慧體提供，編碼智慧體拿到這些元素後，基於研發規範和流程，生成可以直接部署到前端工程庫的程式碼。這個程式碼生成後可以直接執行，並提供一個預覽地址。
如果過程中出現失敗或需要調整需求的情況，可能會有一個需求智慧體介入，可能來自 GitHub 或需求單。如果程式碼沒有按需求或設計執行，研發智慧體會將問題反饋給設計智慧體或需求智慧體，進行協作調整。例如，設計不符合前端元件規範或元件庫，可能需要調整按鈕大小等。這就是兩個智慧體之間的協作，最終可能需要人類進行確認。 目前，A2A 還處於初級階段，智慧體之間更像是孤島，只能進行有限的交換。A2A 已經提供了一個開放協議，允許交換必要的資訊，但要實現我之前提到的反思、對抗協作和互補，以及最終的人類確認，還有很長的路要走。
像 Manus 和 Cloud Code 這樣的新產品也在嘗試多智慧體協作，但目前仍處於初期階段。目前比較好的邏輯是少量的 A2A 發生，甚至是一個為主為輔的 A2A 發生。多智慧體協作還在探索階段，目前更傾向於有主次區分的協作。許多大廠，都在強調主計劃的重要性。
主計劃的本質是讓單體智慧體變成多體智慧體，子智慧體服務於主智慧體。主智慧體不直接執行任務，而是進行任務分配。它也會有一些思維鏈，然後子智慧體根據這些思維鏈來決定是呼叫雲端資源執行程式碼，或呼叫其他智慧體的相關 MCP，例如設計資源或文件，以理解研發規範或設計規範。然後將這些資訊傳遞給下一個子智慧體，即編碼智慧體，讓它生成程式碼。
在這個過程中，可能還需要一個環境，子智慧體會幫助自己搭建環境。這也就是 Cursor 最近流行的 Background Agent 的概念，Cloud Code 也在討論這個問題。所以我認為目前的軟體架構仍然類似於 Master-Slave 模式。
汪晟傑：MCP 可以被視為一個較小的子集，它將呈現多樣化的發展趨勢。預計大約 80% 的核心軟體都將推出自己的 MCP。MCP 本質上是一個埠，供大模型呼叫。接下來，Agent 的發展方向無疑是朝著多智慧體的方向前進，但會變得更加可控。在這個過程中，人類的角色需要被明確界定。目前，這套協議尚未完善，尤其是在明確人類在過程中扮演的角色方面。它更多地強調了 Agent 之間的協議。
在我看來，目前的情況可能是存在兩層結構，但這兩層中可以包含多個 Agent。這並非只有兩個 Agent 的簡單結構，而是可以有多個 Agent，但必須有一個主 Agent 和若干子 Agent 來執行任務。從短期來看，這種結構是比較可控的。人類的角色相對簡單，主要是對計劃進行驗證和確認。如果主 Agent 生成的計劃不符合要求，人類可以進行反思和修正。甚至在主 Agent 生成計劃之前，可以讓人類進行一次確認。之後的執行過程可以無需干預，但在計劃階段，人類需要進行最終的把控。 然而，即便只是這一點，要實現產品的極致體驗也極具挑戰性。因為大模型本身具有隨機性和機率性，如何讓其結果收斂到我們期望的範圍內是一個難題。我們不能僅僅依賴於 master/slave 模式的可控性，花費大量時間讓模型不斷反思和嘗試，最終卻可能得到一個不符合預期的結果。
這就好比僱傭了一個表現不佳的員工，我們需要不斷讓他重新規劃和修正，這不是我們想要的結果。如何讓 agent 本身具備更強的計劃思考能力，也是大模型需要考慮的問題。這涉及到大模型的推理能力和思考能力的持續增強，需要與模型層面進行深度融合。
同時，在產品層面也需要進行創新，以便在大部分推理過程之外，還能利用人類的最終干預來提升效果。在這方面，我們已經進行了一些嘗試。
郭偉：我想對 MCP 再做一些補充說明。我之前認為未來 MCP 的發展肯定是大規模的，但之前大家的反應相對比較慢。我認為其中一個較大的原因在於之前的協議並不完善，沒有采用類似 Stream HTTP 的方式。因此，之前存在很多問題，從企業端來看，這些問題之前是難以解決的。然而，在今年 3 月 26 日版本更新之後，這些問題正在逐步得到解決。對於企業來說，現在可以更快速地將內部的 SaaS 能力透過 MCP 的方式釋放出來。
從生態角度來看，這可能是一個更加快速且更容易的過程。其次，MCP 目前還有一個比較重要的特點是安全可信問題。例如，我們自己也在運營 MCP 市場，因此在選擇 MCP 工具時，我們會有一些比較嚴格的標準。畢竟，如果使用者使用了我們提供的工具後出現問題，他們肯定會找我們騰訊。
在業界，無論是使用我們的市場還是其他市場，使用者都需要設法判斷工具的安全性。但實際上，使用者很難做出準確判斷，因為 MCP 的很多內容已經黑盒化，包括內部邏輯和提示詞描述等。比如，我之前舉的例子，如果我是一個駭客，自己做一個 MCP 服務，並在工具描述中寫一些不良內容，如要求使用者提供手機號或銀行卡資訊等，使用者可能完全不知情。
未來，我認為行業可能會出臺一些安全措施，幫助使用者發現 MCP 服務的問題，從而使這個行業能夠更加健康地發展。
點選底部閱讀原文訪問 InfoQ 官網，獲取更多精彩內容！