国产成人91精品,国产在线视频在线观看,99成人综合久久精品亚洲直播秀

根據谷歌的官方文檔： A2A 協議促進了“客戶端”和“遠程” AI Agent 之間的通信。簡單來說，“客戶端” AI Agent 創建任務并與“遠程” AI Agent 溝通，期望執行某些工作或返回數據。

第三、A2A 架構設計

? ? 1、能力發現：所有實現 A2A 的 AI Agent 都通過“Agent Card”公開其能力目錄。這有助于其他 AI Agent 發現給定 AI Agent 實現的潛在有用功能。? ?

2、任務管理：通信協議，時代短期和長期任務變得更容易。它幫助通信中的 AI Agent 保持同步，直到請求的任務完成并返回答案。這很重要，因為有些 AI Agent 可能需要很長時間來執行工作，而且目前沒有統一標準如何等待這種情況發生。? ?

3、協作：AI Agent 可以相互發送消息以傳達上下文、回復、工件或用戶指令。? ?

4、用戶體驗協商：這是一個很有趣的功能。它允許協商數據返回的格式，以符合用戶界面的期望（比如：圖像、視頻、文本等）。通過 A2A 公開的 AI Agent 的發現是一個重要話題。谷歌建議使用統一的位置來存儲組織的“Agent Card”。比如：

https://<DOMAIN>/<agreed-path>/agent.json

這并不意外，因為谷歌將處于最佳位置，能夠索引全球所有可用的 AI Agent，可能創建一個類似于當前搜索引擎索引的全球 AI Agent 目錄。我喜歡 A2A 強調無需重新發明輪子，并且建立在現有標準之上：?

1、該協議建立在現有、流行的標準之上，包括：HTTP、SSE、JSON-RPC，這意味著它更容易與企業日常使用的現有 IT 堆棧集成。? ?

2、默認安全?– A2A 旨在支持企業級身份驗證和授權，與 OpenAPI 的身份驗證方案相當。

MCP 架構設計

MCP（模型上下文協議）是由 Anthropic 定義的一個開放協議，標準化應用程序如何為大語言模型（LLM）提供上下文。更具體地說，它試圖標準化基于 LLM 的應用程序與其他環境集成的協議。在 AI Agent 系統（Agentic Systems）中，上下文可以通過多種方式提供：

1、外部數據：這是長期記憶的一部分。

2、工具：系統與環境交互的能力。

3、動態提示詞：可以作為系統提示詞（System Prompt）的一部分注入。

第一、為什么要標準化？

目前，AI Agent 應用的開發流程很混亂：? ??

1、有許多 AI Agent 框架存在細微差異。雖然看到生態系統蓬勃發展令人鼓舞，但這些細微差異很少能帶來足夠的價值，但可能會顯著改變你的代碼編寫方式。? ??

2、與外部數據源的集成通常是臨時實現的，并且使用不同的協議，即使在組織內部也是如此。對于不同公司來說，這顯然是如此。???

3、工具在代碼庫中以略微不同的方式定義。如何將工具附加到增強型 LLM 上也是不同的。目標是提高我們創新 AI Agent 應用的速度、安全性以及將相關數據帶入上下文的便利性。

第二、MCP 架構設計

1、MCP Host：使用 LLM 為核心并希望通過 MCP 訪問數據的程序。? ?

2、MCP Client：與 MCP Server 保持1:1連接的客戶端。? ?

3、MCP Server：每個 MCP Server 都通過標準化的模型上下文協議公開特定功能的輕量級程序。? ?

4、Local Data Sources：你計算機上的文件、數據庫和服務，MCP Server 可以安全訪問。? ? 5、Remote Data Sources：通過互聯網可用的外部系統（比如：通過 API），MCP Server 可以連接到這些系統。

第三、通過 MCP 分離控制責任

MCP Server 公開三個主要元素（Prompts、Resoures、Tools），這些元素是有意設計的，以幫助實現特定的控制分離。

1、Prompts 提示詞被設計為用戶控制的。后端的程序員可以公開特定的提示詞（適用于與后端服務公開的數據交互），這些提示詞可以注入到使用 LLM 的應用程序中，并暴露給給定應用程序的用戶。

2、Resoures 資源被設計為應用程序控制的。Resources 資源是任何可以被利用 LLM 構建的應用程序使用的數據（文本或二進制）。應用程序的程序員（通常是 AI 應用開發工程師）負責將這些信息編碼到應用程序中。通常，這里沒有自動化，LLM 不參與此選擇。

3、Tools 工具被設計為大模型控制的。如果我們賦予應用程序如何與環境交互的代理權，我們使用 Tools 工具來實現這一點。MCP Server 公開一個端點，可以列出所有可用 Tools 工具及其描述和所需參數，應用程序可以將此列表傳遞給 LLM，以便它決定哪些 Tools 工具適用于手頭的任務以及如何調用它們。

A2A + MCP 協同架構設計

第一、A2A + MCP 協同架構設計

谷歌說得很清楚：AI Agent 應用需要 A2A 和 MCP。我們推薦用 MCP 來處理工具，用 A2A 來處理 AI Agents。這話啥意思呢？我們來看看一個涉及多個 AI Agent 系統架構。

MCP 里的組件：? ?

1、MCP Host：這里有意思了，和 A2A 結合后，MCP Server 就是 AI Agent。? ?

2、MCP Client。? ?

3、MCP Server。? ?

4、Local Data Sources。? ?

5、Remote Data Sources。

A2A 這邊：? ?

6、AI Agent（MCP Host）會通過 A2A 協議來實現和通信，這個協議能實現：

安全協作：MCP 沒有身份驗證功能。[更新：最近 MCP 在身份驗證方面有了很多改進。
任務和狀態管理。
用戶體驗協商。
能力發現：和MCP工具類似。

谷歌建議，MCP 主要用于把傳統的數據系統（MCP Resources）和 API（MCP Tools）跟基于 LLM 的應用整合起來，而 A2A 則負責 AI Agent 之間的通信。我確實覺得，往后發展，大家會越來越傾向于把平臺暴露成 AI Agent，而不是 MCP Server，所以 MCP 在第5點的重要性會逐漸降低。

第二、通過 MCP 進行 AI Agent 發現

谷歌甚至建議通過 MCP Server Resources 來暴露 A2A AI Agent。

1、網格（Mesh）中的每個 AI Agent 都可以通過 MCP Client 連接到一個專門的 MCP Server，并瀏覽 Resources 目錄來發現其他可用的 AI Agent。建議通過這些 MCP Resources 來暴露 Agent Cards。? ?

2、發現之后，AI Agent 之間會繼續利用 A2A 協議進行通信。話說回來，如果我們朝著通過全球索引進行 AI Agent 發現的方向發展，MCP 在這里的重要性也會降低，甚至可能會消失。

長期來看，A2A 會不會取代 MCP？

第一、MCP 會不會逐漸變得不重要？

其實，一直以來，人們都在尋找一種方法，能讓大量的 AI Agent 之間互相連接，還能和傳統的系統連接。之前有人提到過無頭瀏覽器（headless browsers），但現在看來，開放的通信協議可能才是未來的方向。我覺得，這也是為什么有人說 MCP 是“新的 HTTP 時刻”（雖然可能有點夸張）。

以下的想法是基于一些假設的：

開放的通信協議會把新世界的 AI Agent 整合在一起。
成為領先的協議是有好處的。
這兩種協議都會繼續發展，可能會擴大它們的責任范圍。

第二、MCP 和 A2A 有一些相似之處

在 AI Agent 協議方面，兩者都有明顯的相似性，用戶可以選擇多種方式來構建他們的 AI Agent 應用，并將它們展示給世界。

隨著 MCP 的迅速流行，公司把 MCP Server 作為他們產品的一部分變得很常見，這樣開發者就可以輕松地把這些平臺的內容整合到他們自己的基于 LLM 的應用中。

然而，MCP 在推廣過程中遇到了一些問題。

這個協議最大的缺點之一就是缺乏安全性和身份驗證。如果你想安全地展示一個遠程的 MCP Server，你需要在基本實現上做一些調整。
- Tools 工具可以描述任何東西，包括其他 AI Agent。不幸的是，MCP 沒有實現任何可以讓 AI Agent 通過工具進行適當通信的機制（比如狀態/上下文交換、長期任務支持等）。

這可能是谷歌通過 A2A 進入協議競爭的一個切入點，因為它解決了上述問題。

我總覺得 Anthropic 對 MCP 的規劃比現在看到的要大，包括把多個 AI Agent 連接在一起。現在，A2A 的出現可能已經關上了向這個方向發展的大門。

從長遠來看，AI Agent 的世界會是什么樣子呢？