來源：騰訊技術工程、infoQ、原力注入

自 OpenAI 于 2023 年發布函數調用功能以來，我一直在思考如何構建一個開放的智能體與工具使用生態系統。隨著基礎模型愈發智能化，智能體與外部工具、數據和 API 的交互能力卻日益碎片化：開發者需要為智能體運行的每個系統和集成對象，實現具有特殊業務邏輯的智能體程序。

通信協議是AI Agent加速落地的核心基礎設施之一。Anthropic推出的MCP已逐步確立其作為AI Agent連接外部工具的標準協議地位，而Google最新發布的A2A則聚焦于打破智能體協作壁壘，推動跨Agent協同體系的構建。作為AI Agent時代最受關注的兩大通信規范，它們的安全性直接關乎AI Agent的安全邊界，任何安全問題都可能引發AI Agent被劫持與數據泄露等連鎖風險。

什么是 MCP？

MCP 是一種開放協議，使系統能夠以跨集成通用化的方式為 AI 模型提供上下文。?該協議定義了 AI 模型如何調用外部工具、獲取數據以及與服務交互。具體示例如下，展示了 Resend MCP 服務器如何與多個 MCP 客戶端協同工作。

Example MCP Workflow

這個理念并不新鮮；MCP從 LSP（語言服務器協議）中汲取了靈感?。在 LSP 中，當用戶在編輯器中輸入時，客戶端會查詢語言服務器以獲取自動補全建議或診斷信息。

MCP 的突破性在于其以代理為中心的執行模型：LSP 主要是反應式的（基于用戶輸入響應 IDE 的請求），而 MCP 旨在支持自主 AI 工作流。基于上下文，AI 代理可以自主決定使用哪些工具、使用順序以及如何串聯工具鏈來完成任務。?MCP 還引入了人機協同能力，允許人類提供額外數據并批準執行流程。

而在2025年4月9日，谷歌云正式發布了Agent2Agent（A2A）協議，這是首個專為AI代理互操作性設計的開放標準。按Google的說法，A2A協議與MCP是互補而不替代關系，A2A負責解決Agent間的通信問題，MCP解決的是Agent與工具間的通信問題。

2.2 MCP的安全缺陷

由于設計之初MCP協議主要是用于AI Agent調用本地工具或調用權威廠商提供的MCP服務，同時也沒有過多考慮安全相關風險，2024年11月發布的初代MCP協議及主流MCP服務實現上仍然存在以下安全缺陷：

1.信息不對稱
AI模型能夠看到工具描述的全部內容，包括隱藏在注釋或特定標簽中的細節，而在用戶看到的AI Agent的前端界面出于簡潔考慮往往只顯示工具的基本功能描述，忽略了那些可能包含惡意指令的內容。

2.缺乏上下文隔離

當AI Agent連接多個MCP服務器時，所有可用工具的描述信息都會被加載到當前的會話上下文中。這意味著來自惡意MCP服務器的工具描述可以影響來自可信MCP服務的工具行為。

3.大模型安全防護不足

當前的大模型被訓練為盡可能精確地理解并遵循給定的指令，包括MCP提供的工具描述。然而，模型往往缺乏針對惡意指令的批判性思維能力，特別是當這些指令被巧妙地偽裝成工具的"必要前置條件"或"實現細節"時，同時即使開發者在prompt中加入了安全防護相關指令，攻擊者也可以通過各類層不出窮的越獄攻擊手法繞過。

4.版本控制與更新機制不足

MCP協議缺乏嚴格的版本控制和更新機制，使得所謂的"地毯式騙局"（Rug Pulls）成為可能。惡意的MCP服務可以在用戶初次安裝并啟用后，在遠程服務器上靜默修改工具描述加入惡意指令，且MCP客戶端無法及時感知并要求用戶二次確認。

5.安全隔離與檢測機制不足

MCP官方文檔沒有明確建議用戶在Docker或沙箱環境中安裝MCP服務，同時第三方MCP市場也沒有對MCP代碼安全性進行檢查，用戶非常容易安裝帶有后門或漏洞的MCP服務。

6.授權認證機制不完善

對于一些有敏感數據讀取（如查DB、讀文件）、敏感功能操作（如執行系統命令）功能的接口，MCP并沒有在官方文檔中明確強制要求開發者進行授權認證，這樣可能導致部分暴露在公網上的MCP服務被入侵或未授權使用。

2.3?Google A2A協議安全性分析

不同于MCP的使用場景（大部分是由Agent開發者自己本地部署或使用市場上開源的MCP服務，其代碼和實現是相對透明的），Google A2A要解決的是不同黑盒中Agent間的安全通信與信任問題，Google宣稱其在安全性設計層面采取默認安全設計：

企業級認證和授權	支持OAuth授權，確保只有授權代理可以訪問和交互。
OpenAPI兼容	與OpenAPI方案保持一致兼容在header中使用Bearer Token認證
訪問控制（RBAC）	確保代理只能執行其授權的操作，細化對Agent能力訪問權限管理。
數據加密	支持加密數據交換，保護敏感信息在傳輸過程中的安全性。
授權方案持續優化	計劃在AgentCard中增加更多授權機制，例如直接整合可選憑證進一步提升安全性。

其中的關鍵實現是AgentCard，這個是一個公開的元數據文件，描述了AI代理的功能、技能、端點URL和身份驗證要求，可以通過URL路徑?http://{remote_agent_address}/.well-known/agent.json?訪問。AgentCard允許代理在不了解彼此的情況下，通過讀取對方的AgentCard來識別對方的能力和訪問權限，從而實現安全的協作。

?

當前熱門的應用場景

借助適當的 MCP 服務器組合，用戶可將每個 MCP 客戶端轉變為"萬能應用"。通過Slack MCP 服務器?實現 Slack 通訊功能，利用Resend MCP 服務器?完成郵件發送，或通過Replicate MCP 服務器?進行圖像生成。

以代碼編輯器光標為例：雖然其本質是代碼編輯工具，但作為優質 MCP 客戶端，終端用戶既可通過Slack MCP 服務器?將其改造為 Slack 客戶端，也能利用Resend MCP 服務器?實現郵件發送功能，或通過Replicate MCP 服務器?進行圖像生成。更強大的應用方式是在單個客戶端集成多個服務器以解鎖新流程：用戶可安裝前端?

UI 生成服務器?從光標直接生成界面原型，同時調用圖像生成 MCP 服務器為網站創建主視覺圖。

除光標外，當前大多數用例可歸納為兩類：要么是以開發者為中心、本地優先的工作流，要么是使用大語言模型客戶端構建的全新體驗。

不同的場景導致了兩種 Agent 模式在技術上的不同選擇

兩種 Agent 模式的實現存在差異，原因多種多樣：

• 通用 Agent 需要具備獨立的云端運行環境，而本地 Agent 則部署于本地 IDE 中，因此它們所采用的工具不盡相同。

• 本地 Agent 由于需與人類操作同步，故重視執行效率，力求迅速向用戶提供反饋，并盡快完成交付。

• 相比之下，通用 Agent 可以支持異步交付，對延遲的要求不那么嚴格，其流程可被分解得更為細致，能夠調用更多工具進行多次驗證以獲取中間結論。同時，鑒于它是異步交付，必須確保一定水平的交付質量，因而需要盡量考慮周全后再執行。

• 本地 Agent 的產品與 IDE 緊密結合，這意味著其任務不會無限制地擴展，相對而言較為簡化。

• 通用 Agent 使用的工具種類不受限，而本地 IDE 中的 Agent 由于受限于 PC 設備，任意安裝新工具可能會引發用戶關于隱私或安全性的擔憂。

• 作為異步模式的一部分，通用 Agent 必須達到一定程度的確定性，在執行過程中不斷自我反省和總結，這會帶來執行效率的降低

但通用 Agent 會遇到一些挑戰

通用 Agent 實施上會遇到的挑戰

盡管我們現在可以看到市場上有很多標榜為通用 Agent 的產品，但實際上能夠處理通用或復雜任務的并不多。這些產品要么不夠通用，要么無法應對復雜的任務。我認為這主要是由于工程和技術模型兩個方面所面臨的挑戰。

通用 Agent 在工程上的挑戰

? 第一Agent 的大腦如何構建

其實當初我們看到 Devin 時，我們首先想到的是 Web IDE 的架構。我們認為，在瀏覽器中開啟的任務應當由后臺的一個獨立容器來處理。這一想法立即讓我聯想到了 Web IDE 的架構。

具體任務在一個環境中執行。在這個環境中，有一個“大腦”負責知識的引入、工具的使用、知識的壓縮以及模型的驅動。“大腦”的重要性體現在以下幾個方面：

• 它具備任務規劃與執行能力，可以被視為通用 Agent 的 '大腦'，負責管理整個任務流程，將復雜的任務分解成可以由子 Agent 執行的小任務。

• 它能夠進行反思和重新規劃。有時，某種實現方案可能走入死胡同，或模型堅持一條走不通的道路，“大腦”需識別這些問題并重新規劃其他路徑。

• 它能夠識別并選擇使用各種工具，例如通過瀏覽器打開網頁、操作終端、文件的創建、刪除、編輯等，以及在線搜索等。

• 它具有識別、正確壓縮記憶、引入新知識及學習的能力，如將先前成功完成的任務歸納為經驗，在面對類似任務時再次應用這些經驗。

• 內置 IDE 功能通常也是必要的，這使得用戶可以在 Agent 中調整生成內容的信息，盡管這不是強制性的要求。

• 并行處理子任務，通用 Agent 可以同時運行多個子任務，從而加速任務的完成。

?第二 如何評估通用 Agent

通用 Agent 的性能受到 Engine、模型、各種 Prompt、工具篩選等方面的影響。在評估時，對于那些不確定性強的內容，我們需要進行模擬，并通過控制變量的方法找出關鍵的優化點。因此，建立一個能夠發現實現使用環境中問題的環境變得很重要只有通過評測我們才能明確改進的方向。

過去，在大規模模型的訓練和評估中，通常采用的是以 Query 和 Answer 為核心的評價方式。

這種評測集的特點通常是易于實施和評估的，比如 Pass @ 1 或者 EM、ES 等評估策略，通常是一組標準化的測試數據（輸入 - 輸出對），用于量化模型在特定任務上的表現。其目的在于提供統一的評估標準，以便橫向比較不同模型的能力（如準確性、穩健性和泛化能力）。例如 GLUE（自然語言理解）、MMLU（多學科知識）、HumanEval（代碼生成）等。有些評測集，如 SWE-Bench，則設置了若干實際世界中的編程問題供智能體解決。

然而，這類評測集僅能用于評估與編碼相關的智能體能力，而無法全面反映通用型智能體的綜合能力。因為在很多情況下，僅僅評估最終結果并不合理，因為智能體產生的輸出往往不是標準化的，例如在一個需求調研任務中，我們難以通過產出直接判斷智能體的質量，或這種評價本身就是主觀的。此外，評測的另一目的還在于優化整體設計架構，單純的結果評估很難揭示問題究竟出現在規劃階段、記憶階段還是工具選擇階段。

當然，評估過程本身也充滿挑戰，因為智能體的執行過程是動態變化的，由模型驅動，每次生成的計劃不盡相同，所用工具也可能有所差異，因此嚴格對比變得困難。即便我們嘗試評估過程細節，比如具體進行了哪些規劃步驟，使用了多少步驟，這些數據的具體意義仍不易解釋清楚。因此，針對通用型智能體產品的評測是一項行業難題，或許需要引入人工評估的方式，甚至為展示其通用性，還需構建多種突發場景來考察其應對能力，這些都是需要考慮的因素。

?第三 如何解決處理長步驟下的記憶問題

人在面對復雜問題時，盡管也是逐步推進，但在每完成一步后，往往會無意識地對信息進行壓縮處理。例如，在理解一段復雜的代碼邏輯時，你不必記住讀過的每一個字符；相反，你會大致掌握其內容，然后轉向其他文件。這樣，你就能夠持續處理新任務。當后續任務需要之前的具體信息時，再回過頭來查閱細節。這就是人類如何通過信息壓縮與提取來管理信息的方式，這一能力同樣適用于 Agent。

Agent 的記憶機制分為兩類：短期記憶和長期記憶，它們分別應對不同的需求。

在處理復雜任務時，由于模型的上下文長度受限，即便未來模型的上下文容量得以擴展，仍需依賴信息壓縮功能。過多的信息可能會導致關鍵點被忽略，因此短期記憶中的信息壓縮有助于提煉出核心要點。Devin 產品的界面設計體現了這種壓縮能力，即在每個步驟完成后展示壓縮后的記憶摘要，而不是詳盡記錄每項操作，以便為后續步驟提供概要參考。

但是，單純地通過壓縮也有其局限性，因為模型壓縮可能會忽視某些對復雜任務至關重要的細節信息，例如我們在測試的時候發現 Agent 生成一組用戶名和密碼，然后轉頭就忘了，這就考驗了解決問題的工程技術能力。

如前所述，通用 Agent 應該擁有反思與學習總結的能力，這也是模型與 Agent 之間的區別之一。Agent 在學習過程中不斷進步，并掌握處理新任務的方法，因此 Agent 或許具有規模效應——使用者越多，它就越智能。這種能力的具體表現就是“長期記憶”。每當用戶完成一項任務后，我們可以讓模型整理出一份可供日后參考的經驗數據。這樣，在 Agent 遇到新問題時，可以調取這些經驗來指導模型如何應對，從而實現了某種形式的長期記憶。Devin 則是通過 Knowledge 的方式來進行存儲，例如，在執行某項任務的過程中，通過對模型輸出進行校正，生成了一份可利用的知識。

不過，這種處理方式仍然顯得相當粗獷。主要是因為，一種知識在一個特定情境中可能非常有效，但在另一個情境下卻未必如此。例如，牛頓力學在宏觀和低速的世界里表現得極為出色，然而當速度接近光速時便不再適用；同樣地，抗生素能夠有效地殺死細菌，但對于病毒則無能為力。因此，將成功的經驗固化為固定的“Agent 心智”，實際上也限制了模型的能力。如何根據具體的情境來甄別并利用這些經驗，并且恰當地掌握這一平衡點，本身就是一項重大的技術挑戰。

模型的挑戰

工程上的挑戰其實還是能夠克服的，畢竟有大量可借鑒的產品，我們也可以通過各種方法和產品手段來避免一些問題。然而，對于“模型驅動”的 Agent 產品來說，模型能力方面的挑戰更為艱巨。當前，幾乎所有開發通用 Agent 產品的公司都將 Claude Sonnet 視為首選模型，因為除此之外，其他模型都無法很好地推動復雜任務的解決，模型能力的欠缺是我們比較擔心。

模型的指令跟隨能力不足

復雜的任務之所以復雜，在于判斷與限制條件多，約束多，對模型的要求也隨之增多，通常會組合成一個極其復雜的 Prompt，模型能遵循的指令越多，它能處理的問題就越復雜。然而，除 Claude 系列外，其他模型往往難以達到這一標準。

部分模型存在不遵循指令的情況，而且非常普遍，例如我明確告訴他不要轉義

但代碼還是轉義了

? 模型的長上下文能力

主要體現為當噪音信息變多時，找到關鍵信息、理解能力會變弱。

某模型放入過多額外信息時生成的流程圖，可以看到許多中間步驟被模型忽略了。

某模型僅保留關鍵信息時生成的流程圖，如果去除掉一些細節信息，模型就能找出更完整的鏈路。

復雜的任務之所以顯得復雜，要么是因為其上下文本身就很長，例如 代碼，或者在執行長步驟任務時，需要記憶更多上下文信息。對于復雜任務，特別是涉及幾十甚至上百步的任務而言，把握住長上下文中關鍵的信息至關重要。

? 模型的推理規劃和反思能力

推理與規劃能力是通用 Agent 解決復雜問題的關鍵。這種能力使得智能體能夠分析問題、制定解決方案的步驟，并在執行過程中進行調整。Devin 在產品上會先為任務制定一個計劃，然后向用戶展示執行規劃的步驟。

而在我們執行任務的過程中遇到變化時， Devin 會調整他的計劃。這與人類相似，在完成一項復雜的任務時，人們通常也無法一開始就制定出一個完美的計劃，而是會在實施過程中不斷進行調整。

這個圖反應了，Agent 存在的挑戰不僅僅是一次性就把事情做好，而是在一個長鏈路任務下需要具備反思和的能力

• Agent 難以從錯誤的長軌跡中恢復（Difficult to recovery in long trajectory）

  • 在任務執行過程中，智能體可能選擇了錯誤的動作序列，導致偏離正確軌跡

  • 智能體需要回顧并修正之前的錯誤動作，以完成任務

  • 圖中左側展示了智能體在錯誤軌跡中浪費時間（例如開錯門、走錯路徑），最終未能獲得獎勵

• Agent 也容易陷入局部循環（Stuck into Loops）

  • 智能體可能在某些狀態中反復執行相同的動作，陷入局部循環，無法探索新的可能性

  • 圖中右側展示了智能體重復執行“打開廚房門”的動作，未能有效推進任務

  • 智能體需要跳出局部循環，探索更多可能的動作以完成任務

推薦書籍：
《分布式商業生態戰略：數字商業新邏輯與企業數字化轉型新策略》

作者：思二勛

書籍介紹：
本書從新時代的新市場和新趨勢出發，如：元宇宙、Web 3.0、資產數字化、反壟斷、要素市場化配置、非同質化通證（non-fungible token，NFT）等，以企業數字化轉型為核心，以區塊鏈等數字化技術為基本點，以場景為基本面，勾勒了數字化時代分布式商業演化的新趨勢，以及其對企業經營管理的影響，提出了數字化時代企業數字化轉型的新策略和分布式經營管理的低成本、高效率發展方案。