MCP與A2A成為熱點：企業AI Agent如何連線工具、系統與其他智慧體？

先分清兩個協議分別解決什麼問題

MCP採用客戶端與伺服器架構，伺服器可以暴露工具、資源和提示模板，讓AI應用以統一方式發現和呼叫能力。例如查詢訂單、讀取知識庫、建立工單或獲取資料庫結構。它關注的是“一個Agent如何獲得上下文並使用工具”。

A2A面向獨立智慧體之間的互操作，支援能力發現、任務狀態、訊息、產物、流式響應和長任務通知。它關注的是“不同Agent如何瞭解彼此能力、委派任務並交換結果”。兩者可以配合使用，不是互相替代。

• Agent到工具、API和資源：優先考慮MCP
• Agent到Agent的跨團隊或跨平臺協作：考慮A2A
• 簡單內部呼叫：現有API和訊息機制可能已經足夠
• 協議只解決連線標準，不自動解決業務語義和質量

企業落地不應繞過現有API與整合治理

企業已經存在API閘道器、服務匯流排、主資料、許可權平臺和審計體系時，MCP伺服器應建立在這些能力之上，而不是直接把資料庫或核心系統裸露給模型。協議適配層負責把現有服務轉化為Agent可理解的工具描述，同時保留原有鑑權、限流和審計。

對於沒有穩定API的遺留系統，應先評估介面改造、只讀資料服務或受控自動化方案。讓Agent直接模擬人工點選雖然能快速驗證，但長期穩定性、可審計性和變更成本通常較差。

工具設計質量決定Agent是否可靠

工具名稱、描述、輸入結構和返回結果都會影響模型的選擇。一個“操作訂單”的大工具往往邊界模糊，更穩妥的方式是拆分查詢訂單、建立草稿、校驗庫存、提交審批等能力，併為高風險動作設計明確確認。

返回內容應儘量結構化，包含狀態、錯誤碼、可追蹤ID和必要依據。工具必須具備冪等、超時、重試、限流和失敗補償機制，避免Agent重複呼叫造成重複下單、重複通知或資料汙染。

• 一個工具只承擔清晰、可描述的業務動作
• 輸入引數使用嚴格Schema和業務校驗
• 查詢與寫入分離，高風險寫入增加審批
• 返回結果同時服務於模型判斷和人工排查

授權必須繫結目標資源並遵循最小許可權

遠端MCP和A2A服務進入生產環境後，應使用HTTPS和成熟身份協議。訪問令牌需要驗證簽發方、受眾、有效期和許可權範圍，不能把上游令牌未經校驗直接傳給下游系統，也不能用一個長期金鑰覆蓋所有使用者和工具。

A2A的Agent Card會描述身份、能力、服務地址和認證要求。公開目錄只暴露必要資訊，包含內部技能、地址或敏感能力的擴充套件卡片需要認證訪問。跨組織協作還要明確資料傳輸、儲存和責任邊界。

多Agent系統需要目錄、編排和全鏈路可觀測

當Agent數量增加後，企業需要維護能力目錄、版本、負責人、執行狀態和依賴關係。編排層決定任務由誰執行、如何傳遞上下文、什麼時候並行、何時請求人工輸入，以及失敗後如何回退。

每次跨Agent任務應使用統一追蹤ID，記錄任務狀態、訊息、工具呼叫、產物、成本和耗時。否則當最終結果出錯時，很難判斷問題來自模型、工具、網路、許可權、業務規則還是另一個Agent。

推薦的落地順序：先工具化，再協作化

多數企業不需要從第一天就建設複雜的多Agent網路。更合理的順序是先梳理高價值業務能力，用標準API或MCP形成受控工具；再建立單Agent工作流和評測；當職責確實需要跨系統、跨團隊或跨供應商委派時，再引入A2A。

最終驗收應關注任務成功率、許可權正確性、可追蹤性、故障恢復和業務收益，而不是接入了多少協議或建立了多少Agent。