Levix's zone

今天的 AI 智能体 能解决特定任务，但在没有自定义粘合代码的情况下，它们无法相互交接工作。每次交接都是一次临时补丁。
當今的 AI 智能體雖能完成特定任務，但缺乏自定義粘合代碼就無法相互交接工作。每次任務傳遞都像是一次臨時補丁。

为了解决这个问题，谷歌最近发布了 Agent2Agent (A2A) 协议，这是一个微小的开放标准，允许一个智能体发现、认证并从另一个智能体流式传输结果。无需共享提示上下文，无需定制 REST 端点，也无需反复实现身份验证。
為了解決這一問題，谷歌近期發布了 Agent2Agent（A2A）協議 —— 一個輕量級的開放標準，允許智能體相互發現、認證並傳輸結果。無需共享提示上下文，無需定制 REST 端點，也無需反復實現身份驗證。

该规范刚刚出炉，后续可能还有诸多调整，但它朝着构建更健壮、更可组合的智能体工作流迈出了坚实一步。
該規範剛剛出爐，後續可能還有諸多調整，但它朝著構建更健壯、更可組合的智能體工作流邁出了堅實一步。

如果你想知道为什么智能体需要网络级标准、A2A 解决方案如何运作，以及运行 A2A 的安全保障措施，请继续阅读。
如果你想知道為什麼智能體需要網絡級標準、A2A 解決方案如何運作，以及運行 A2A 的安全保障措施，請繼續閱讀。

为什么我们需要 Agent2Agent 协议
為什麼我們需要 Agent2Agent 協議#

现代应用已经在协调多个 "副驾驶"：一个负责起草 Jira 工单，另一个处理 Zendesk 工单分类，第三个则优化营销文案。
現代應用已經在協調多個 "副駕駛"：一個負責起草 Jira 工單，另一個處理 Zendesk 工單分類，第三個則優化營銷文案。

但每个 AI 代理都运行在自己的框架中，当你要求它们协作时，你又回到了复制粘贴 JSON 或搭建临时 REST 桥接的老路。（说实话：在代理之间复制粘贴提示词，就像现代版的给自己发 draft-final-final_v2 压缩包邮件。）
但每個 AI 代理都運行在自己的框架中，當你要求它們協作時，你又回到了複製粘貼 JSON 或搭建臨時 REST 橋接的老路。（說實話：在代理之間複製粘貼提示詞，就像現代版的給自己發 draft-final-final_v2 壓縮包郵件。）

模型上下文协议 (MCP) 只解决了部分难题。MCP 让单个代理能公开其工具模式，使 LLM 可以安全调用功能。但当该代理需要将整个任务移交给提示上下文之外的同伴时，问题就出现了。MCP 在服务发现、身份验证、进度流式传输和富文件交接方面保持沉默，迫使团队不得不搭建自定义微服务。
模型上下文協議 (MCP) 只解決了部分難題。MCP 讓單個代理能公開其工具模式，使 LLM 可以安全調用功能。但當該代理需要將整個任務移交給提示上下文之外的同伴時，問題就出現了。MCP 在服務發現、身份驗證、進度流式傳輸和富文件交接方面保持沉默，迫使團隊不得不搭建自定義微服務。

以下是实践中出现痛点的地方：
以下是實踐中出現痛點的地方：

• 不稳定的交接： DIY 的 "交接"JSON 中哪怕多出一个字段，就可能导致整个链条中断。
  不穩定的交接：DIY 的 "交接"JSON 中哪怕多出一個字段，就可能導致整個鏈條中斷。
• 安全僵局： 每个内部代理都自带一套认证方案；安全团队拒绝为未知端点授权。
  安全僵局：每個內部代理都自帶一套認證方案；安全團隊拒絕為未知端點授權。
• 供应商锁定： 部分 SaaS 提供商仅通过私有 SDK 开放智能体接口，将用户绑定在特定云平台或框架中。
  供應商鎖定：部分 SaaS 提供商僅通過私有 SDK 開放智能體接口，將用戶綁定在特定雲平台或框架中。

这就引出了 Agent2Agent (A2A) 协议。它可视为基于 JSON-RPC 构建的轻量开放层，仅定义最核心要素 —— 用于发现的智能体名片（Agent Card）、任务状态机，以及流式消息或工作产物 —— 使得任何客户端智能体都能与远程智能体直接协商，无需探查提示词或私有代码。
這就引出了 Agent2Agent（A2A）協議。它可視為基於 JSON-RPC 構建的輕量開放層，僅定義最核心要素 —— 用於發現的智能體名片（Agent Card）、任務狀態機，以及流式消息或工作產物 —— 使得任何客戶端智能體都能與遠程智能體直接協商，無需探查提示詞或私有代碼。

(^A2A use case example from Google’s announcement post.)
（源自 Google 公告中的 A2A 应用场景示例）

A2A 并非取代 MCP，而是构建在其之上，填补了阻碍实际应用落地的 "智能体间协作" 空白。将智能体比作办公室员工：MCP 为他们提供员工手册、传真机和文件柜；A2A 则让他们能在休息室自由交谈。
A2A 並非取代 MCP，而是構建在其之上，填補了阻礙實際應用落地的 "智能體間協作" 空白。將智能體比作辦公室員工：MCP 為他們提供員工手冊、傳真機和文件櫃；A2A 則讓他們能在休息室自由交談。

A2A 的目标很简单：让 多智能体协同 变得常规化而非高风险，同时为框架和供应商保留底层创新的空间。
A2A 的目標很簡單：讓多智能體協同變得常規化而非高風險，同時為框架和供應商保留底層創新的空間。

角色基础：客户端代理与远程代理
角色基础：客户端代理与远程代理#

在我们完整了解 A2A 交互流程前，明确区分这两个角色会很有帮助。
在我們完整了解 A2A 交互流程前，明確區分這兩個角色會很有幫助。

客户端代理#

这是驻留在您技术栈内部的组件 —— 可能是 Genkit 中的函数、LangGraph 节点，甚至是 n8n 工作流。它会发现远程智能体的服务卡，判断能否满足声明的认证方式，然后通过发送类似 createTask 的 JSON-RPC 消息来创建任务。
這是駐留在您技術棧內部的組件 —— 可能是 Genkit 中的函數、LangGraph 節點，甚至是 n8n 工作流。它會發現遠程智能體的服務卡，判斷能否滿足聲明的認證方式，然後通過發送類似 createTask 的 JSON-RPC 消息來創建任務。

从此刻起，客户端就充当任务的监督者：监听状态事件、转发远程端请求的后续输入，最终收集产出物供下游使用。
從此刻起，客戶端就充當任務的監督者：監聽狀態事件、轉發遠程端請求的後續輸入，最終收集產出物供下游使用。

远程智能体#

可以将其视为一个恰好支持 A2A 协议的专用微服务，可能运行在 Cloud Run、Lambda 或裸金属 VPS 上。一旦接收任务，它就会承担繁重工作 —— 无论是查询向量数据库、微调模型还是导出 PDF。
可以將其視為一個恰好支持 A2A 協議的專用微服務，可能運行在 Cloud Run、Lambda 或裸金屬 VPS 上。一旦接收任務，它就會承擔繁重工作 —— 無論是查詢向量數據庫、微調模型還是導出 PDF。

在执行过程中，它会持续返回 TaskStatusUpdate 和 TaskArtifactUpdate 事件。关键在于远程端无法反转连接关系：它可以向客户端请求更多输入（ status: input-required ），但永远不会成为调用方。
在執行過程中，它會持續返回 TaskStatusUpdate 和 TaskArtifactUpdate 事件。關鍵在於遠程端無法反轉連接關係：它可以向客戶端請求更多輸入（ status: input-required ），但永遠不會成為調用方。

单向通信#

• 仅客户端发起 JSON-RPC 请求。
  僅客戶端發起 JSON-RPC 請求。
• 仅远程端更新任务状态。
  僅遠程端更新任務狀態。
• 任一方均可在出现问题时终止数据流，但清理工作（如删除临时文件）由远程端负责。
  任一方均可在出現問題時終止數據流，但清理工作（如刪除臨時文件）由遠程端負責。

一个很好的思维模型是 "前台与后台" 的关系。客户端就像前台，负责接收新订单和传达具体要求；远程端则是厨房，埋头工作直到菜品完成。（缺点也同样真实：如果远程端搞砸了舒芙蕾，客户端仍得保持微笑并赠送甜点。）
一個很好的思維模型是 "前台與後台" 的關係。客戶端就像前台，負責接收新訂單和傳達具體要求；遠程端則是廚房，埋頭工作直到菜品完成。（缺點也同樣真實：如果遠程端搞砸了舒芙蕾，客戶端仍得保持微笑並贈送甜點。）

明确了这些分工后，我们可以深入研究实现安全交接的数据结构和安全机制。
明確了這些分工後，我們可以深入研究實現安全交接的數據結構和安全機制。

A2A 的定位：位于 MCP 之上，与您的编排器并列
A2A 的定位：位於 MCP 之上，與您的編排器並列#

当人们初次接触 A2A 时，常会问："等等，MCP 不是已经涵盖代理工具了吗？" 差不多 —— 但不完全。
當人們初次接觸 A2A 時，常會問："等等，MCP 不是已經涵蓋代理工具了嗎？" 差不多 —— 但不完全。

通过各层级的快速对比可以清晰区分：
通過各層級的快速對比可以清晰區分：

• 单个智能体内部（提示层级）： 此处智能体需要模式定义以便其模型调用工具。这属于 MCP 范畴：JSON 模式、函数名称、参数验证及提示注入防范。
  單個智能體內部（提示層級）：此處智能體需要模式定義以便其模型調用工具。這屬於 MCP 範疇：JSON 模式、函數名稱、參數驗證及提示注入防範。
• 智能体之间（网络层级）： 当智能体需要将整个任务移交同伴时，MCP 在服务发现、身份验证或流式产物传输方面无能为力。这个空白正是 A2A 通过智能体卡片、任务和状态事件填补的领域。（更多关于智能体系统与协调器的内容）
  智能體之間（網絡層級）：當智能體需要將整個任務移交同伴時，MCP 在服務發現、身份驗證或流式產物傳輸方面無能為力。這個空白正是 A2A 通過智能體卡片、任務和狀態事件填補的領域。（更多關於智能體系統與協調器的內容）
• 流程内部（工作流层级）： LangGraph、CrewAI 和 AutoGen 等框架在内存中串联步骤。它们擅长单机上的短链操作，但一旦需要跨越网络边界 —— 或混合不同语言和供应商方案 —— 你就离开了它们的沙盒，进入了 A2A 的领域。
  流程內部（工作流層級）：LangGraph、CrewAI 和 AutoGen 等框架在內存中串聯步驟。它們擅長單機上的短鏈操作，但一旦需要跨越網絡邊界 —— 或混合不同語言和供應商方案 —— 你就離開了它們的沙盒，進入了 A2A 的領域。

可以这样理解：
可以這樣理解：

• MCP 是单个微服务内部的 API 契约。
  MCP 是單個微服務內部的 API 契約。
• A2A 是微服务之间的 HTTP 通信层。
  A2A 是微服務之間的 HTTP 通信層。
• LangGraph 等工具是决定何时调用每个微服务的工作流引擎。
  LangGraph 等工具是決定何時調用每個微服務的工作流引擎。

在大规模应用中，大多数实际系统最终会同时使用这三种方式。一个 LangGraph 流程可能先调用内部 Python 代理（进程内），然后通过 A2A 协议将任务转交给第三方金融代理，而该金融代理可能依赖 MCP 来触发其内部深处的电子表格导出工具。
在大規模應用中，大多數實際系統最終會同時使用這三種方式。一個 LangGraph 流程可能先調用內部 Python 代理（進程內），然後通過 A2A 協議將任務轉交給第三方金融代理，而該金融代理可能依賴 MCP 來觸發其內部深處的電子表格導出工具。

明确这些边界划分能避免重复劳动：既不必为每个 MCP 工具都添加自定义认证，也不会让 A2A 协议超负荷解析它本不该处理的提示模板。
明確這些邊界劃分能避免重複勞動：既不必為每個 MCP 工具都添加自定義認證，也不會讓 A2A 協議超負荷解析它本不該處理的提示模板。

厘清层级关系后，我们就可以深入探究通信格式本身 —— 包括代理卡片、任务状态机，以及消息和工件如何在数据流中传输。
釐清層級關係後，我們就可以深入探究通信格式本身 —— 包括代理卡片、任務狀態機，以及消息和工件如何在數據流中傳輸。

A2A 交互协议剖析
A2A 交互協議剖析#

如果你能想象在亚马逊上购买一本书的场景，就已经理解了 A2A 协议传输的四种数据形态。
如果你能想象在亞馬遜上購買一本書的場景，就已經理解了 A2A 協議傳輸的四種數據形態。

请看：
請看：

您的亚马逊流程
您的亞馬遜流程

A2A 原语
A2A 原語

包含内容
包含內容

产品列表页： 您可以浏览查看在售商品，了解支付选项
產品列表頁：您可以瀏覽查看在售商品，了解支付選項

智能体卡片（ /.well-known/agent.json ）
智能體卡片（ /.well-known/agent.json ）

代理 ID、描述信息、能力列表、支持的身份验证方法、可选的加密签名
代理 ID、描述信息、能力列表、支持的身份驗證方法、可選的加密簽名

订单确认 / 发票： 点击 "立即购买"，获取订单 ID
訂單確認 / 發票：點擊 "立即購買"，獲取訂單 ID

任务（通过 createTask 创建）
任務（通過 createTask 創建）

task_id 、输入载荷、当前状态
task_id 、輸入載荷、當前狀態

物流状态通知： "订单已打包"，"正在派送中"，"今日送达"
物流狀態通知："訂單已打包"，"正在派送中"，"今日送達"

消息（ TaskStatusUpdateEvent ）
消息（ TaskStatusUpdateEvent ）

角色（ agent 或 client ），文本，可选小文件
角色（ agent 或 client ），文本，可選小文件

门口包裹： 您购买的商品
門口包裹：您購買的商品

制品（ TaskArtifactUpdateEvent ）
製品（ TaskArtifactUpdateEvent ）

类型化负载： TextPart 、 FilePart 或 DataPart
類型化負載： TextPart 、 FilePart 或 DataPart

逐步结账#

1. 浏览列表： 客户端获取一次代理卡片。如果 "功能"（能力）和 "结账"（认证）符合要求，则继续操作。
   瀏覽列表：客戶端獲取一次代理卡片。如果 "功能"（能力）和 "結帳"（認證）符合要求，則繼續操作。
2. 下单： 客户端发送一个 createTask JSON-RPC 请求（类似点击 "立即购买"）。远程代理会回复一个 task_id ，即您的工作订单号。
   下單：客戶端發送一個 createTask JSON-RPC 請求（類似點擊 "立即購買"）。遠程代理會回覆一個 task_id ，即您的工作訂單號。
3. 监控追踪邮件： 远程通过服务器发送事件流传输消息： pending 、 processing ，可能还有 input-required （"需要签名" 的时刻）。客户端可通过 addInput 响应，就像更新配送指令一样操作。
   監控追蹤郵件：遠程通過伺服器發送事件流傳輸消息： pending 、 processing ，可能還有 input-required （"需要簽名" 的時刻）。客戶端可通過 addInput 響應，就像更新配送指令一樣操作。
4. 接收包裹： 当状态变为 completed 时，Artifact 事件会交付有效载荷 —— 可能是 PDF 报告、PNG 资源、JSON 数据或任何承诺的内容。
   接收包裹：當狀態變為 completed 時，Artifact 事件會交付有效載荷 —— 可能是 PDF 報告、PNG 資源、JSON 數據或任何承諾的內容。
5. 完成闭环： 如果任务失败或被取消，远程端会将其标记为 failed 或 canceled ，且不会交付任何产物（就像亚马逊会退还未完成的订单款项）。
   完成閉環：如果任務失敗或被取消，遠程端會將其標記為 failed 或 canceled ，且不會交付任何產物（就像亞馬遜會退還未完成的訂單款項）。

通过这种交互框架，你可以理解为何 A2A 协议保持极简规范：它只定义每个买家（客户端）和卖家（远程端）必需的核心要素 —— 目录、订单、追踪、交付 —— 而将 "仓库内部细节"（模型提示、工具架构）留给 MCP 或卖家选择的其他机制处理。
通過這種交互框架，你可以理解為何 A2A 協議保持極簡規範：它只定義每個買家（客戶端）和賣家（遠程端）必需的核心要素 —— 目錄、訂單、追蹤、交付 —— 而將 "倉庫內部細節"（模型提示、工具架構）留給 MCP 或賣家選擇的其他機制處理。

A2A 协议中的安全性、可观测性与治理
A2A 協議中的安全性、可觀測性與治理#

A2A 协议保持了简洁的线缆规范，但生产系统仍需三层防护与可视化保障。
A2A 協議保持了簡潔的線纜規範，但生產系統仍需三層防護與可視化保障。

确保握手安全#

• 签名代理卡片： 为卡片添加 JSON Web 签名（JWS）并发布签名者的公钥。客户端会 "固定" 该公钥；若有人在传输过程中替换卡片，签名验证将失败且呼叫会被终止。"兄弟信我" 可不是真正的安全策略。
  確保握手安全：為卡片添加 JSON Web 簽名（JWS）並發布簽名者的公鑰。客戶端會 "固定" 該公鑰；若有人在傳輸過程中替換卡片，簽名驗證將失敗且呼叫會被終止。"兄弟信我" 可不是真正的安全策略。
• 认证方式选择： 演示通常使用简单的 Bearer 令牌，但您可升级为双向 TLS 认证（就像无需手势的加密握手），或接入公司的单点登录流程。
  認證方式選擇：演示通常使用簡單的 Bearer 令牌，但您可升級為雙向 TLS 認證（就像無需手勢的加密握手），或接入公司的單點登錄流程。
• 运行时策略： 远程代理可在模型运行前拒绝过大的或存在风险的载荷。常见的防护措施类似："仅接受小于 5MB 的 JSON 或 PNG 文件"（这与 MCP 中的 Zod 模式验证非常相似）。
  運行時策略：遠程代理可在模型運行前拒絕過大的或存在風險的載荷。常見的防護措施類似："僅接受小於 5MB 的 JSON 或 PNG 文件"（這與 MCP 中的 Zod 模式驗證非常相似）。

查看代理所见#

每个状态或工件事件已自带时间戳 task_id 和可选的追踪头信息。将您的 A2A 客户端封装在 OpenTelemetry 中间件中，即可开箱即用地获得端到端跨度 —— 无需手动处理 JSON。
每個狀態或工件事件已自帶時間戳 task_id 和可選的追蹤頭信息。將您的 A2A 客戶端封裝在 OpenTelemetry 中間件中，即可開箱即用地獲得端到端跨度 —— 無需手動處理 JSON。

将这些跨度数据接入您的可观测性堆栈，就能在客户察觉前回答 "下午 3 点哪个远程代理变慢了？" 的问题。
將這些跨度數據接入您的可觀測性堆棧，就能在客戶察覺前回答 "下午 3 點哪個遠程代理變慢了？" 的問題。

信任，但要验证#

目前，A2A 远程设备的发现过程需要自行配置：
目前，A2A 遠程設備的發現過程需要自行配置：

• YAML 文件 为内部团队使用（ registry.yaml 已提交至代码库）。
  YAML 文件 為內部團隊使用（ registry.yaml 已提交至代碼庫）。
• Vertex AI 目录： 勾选 “发布”，Google 会将卡片托管在私有目录中。
  Vertex AI 目錄： 勾選 "發布"，Google 會將卡片托管在私有目錄中。
• 新兴公共枢纽： LangChain 和 Flowise 社区正在构建类似 npm 风格的注册中心，但目前尚未形成全球统一的 "认证徽章" 体系。
  新興公共樞紐： LangChain 和 Flowise 社區正在構建類似 npm 風格的註冊中心，但目前尚未形成全球統一的 "認證徽章" 體系。

在这些枢纽成熟之前，大多数企业会像对待 SaaS 供应商那样管理第三方智能体：包括安全问卷审查、软件物料清单 (SBOM) 提交以及严格的网络访问范围限制。
在這些樞紐成熟之前，大多數企業會像對待 SaaS 供應商那樣管理第三方智能體：包括安全問卷審查、軟件物料清單 (SBOM) 提交以及嚴格的網絡訪問範圍限制。

A2A 如何缩小攻击面相比 MCP#

MCP 将所有工具架构以自然语言提示形式暴露，因此注入攻击和参数篡改成为日常需要防范的问题。
MCP 將所有工具架構以自然語言提示形式暴露，因此注入攻擊和參數篡改成為日常需要防範的問題。

A2A 将所有底层细节隐藏在远程防护墙之后；客户端仅能看到高级任务和受限产物。虽然仍需信任远程代码，但您的提示信息永远不会暴露在风险中，从而彻底消除了一整类漏洞攻击的可能性。
A2A 將所有底層細節隱藏在遠程防護牆之後；客戶端僅能看到高級任務和受限產物。雖然仍需信任遠程代碼，但您的提示信息永遠不會暴露在風險中，從而徹底消除了一整類漏洞攻擊的可能性。

这一切的核心要点是：对你发布的内容进行签名，固定你信任的对象，追踪每一跳路由，并保持合理的负载限制。有了这些防护措施，A2A 协议的风险不会高于调用一个行为规范的 REST 服务 —— 而且当你明天添加新代理时，它会灵活得多。
這一切的核心要點是：對你發布的內容進行簽名，固定你信任的對象，追蹤每一跳路由，並保持合理的負載限制。有了這些防護措施，A2A 協議的風險不會高於調用一個行為規範的 REST 服務 —— 而且當你明天添加新代理時，它會靈活得多。

A2A 愿景与当前现实
A2A 願景與當前現實#

梦想#

• 浏览 “智能体商城”。 您打开 CoolAgentMall.dev，搜索 “税务合规”，就能看到带有星级评分和签名证书的在线智能体。只需点击一下，即可将 URL 添加到您的私有注册表中 —— 无需 SDK，无需密钥。
  瀏覽 “智能體商城”。您打開 CoolAgentMall.dev，搜索 “稅務合規”，就能看到帶有星級評分和簽名證書的在線智能體。只需點擊一下，即可將 URL 添加到您的私有註冊表中 —— 無需 SDK，無需密鑰。
• 拖拽式链式操作。 在 Flowise（或 n8n）中，您只需将绿色的 Tax-Check（A2A）模块拖到 "生成发票" 之后，点击运行，就能看到返回的 JSON 数据流已包含正确的管辖区域代码 —— 您无需编写任何胶水代码。
  拖拽式鏈式操作。在 Flowise（或 n8n）中，您只需將綠色的 Tax-Check（A2A）模塊拖到 "生成發票" 之後，點擊運行，就能看到返回的 JSON 數據流已包含正確的管轄區域代碼 —— 您無需編寫任何膠水代碼。

现实情况（2025 年 5 月）#

• 已有约 50 家供应商宣布支持，但大多数智能体仍处于 "私信获取演示" 阶段。
  已有約 50 家供應商宣布支持，但大多數智能體仍處於 "私信獲取演示" 階段。
• LangGraph、CrewAI 和 AutoGen 的适配器已趋完善；Flowise 和 n8n 仍处于社区测试版阶段。
  LangGraph、CrewAI 和 AutoGen 的適配器已趨完善；Flowise 和 n8n 仍處於社區測試版階段。
• 目前尚无公开注册中心 —— 各团队依赖 registry.yaml 文件或 Vertex AI 的私有目录。
  目前尚無公開註冊中心 —— 各團隊依賴 registry.yaml 文件或 Vertex AI 的私有目錄。
• 很少有代理商会提供签名卡服务，而速率限制或计费上限通常需要自行开发中间件来实现。
  很少有代理商會提供簽名卡服務，而速率限制或計費上限通常需要自行開發中間件來實現。
• 性能数据仅供参考；谷歌参考服务器在本地测试中每跳增加约 30 毫秒延迟。
  性能數據僅供參考；谷歌參考伺服器在本地測試中每跳增加約 30 毫秒延遲。

A2A 协议已准备好用于原型设计和内部工作流程，但对于消费级应用和受监管的技术栈而言，在注册机制和安全标准完善之前仍需额外保障措施。
A2A 協議已準備好用於原型設計和內部工作流程，但對於消費級應用和受監管的技術棧而言，在註冊機制和安全標準完善之前仍需額外保障措施。

何时采用 A2A 协议（以及何时不采用）
何時採用 A2A 協議（以及何時不採用）#

适用场景#

• 跨厂商工作流： 当您的产品经理智能体需要调用另一家公司的财务预测智能体时，A2A 协议为它们提供了共享的握手认证、授权及数据流传输机制，同时确保核心提示词不被暴露。
  跨廠商工作流：當您的產品經理智能體需要調用另一家公司的財務預測智能體時，A2A 協議為它們提供了共享的握手認證、授權及數據流傳輸機制，同時確保核心提示詞不被暴露。
• 安全敏感的黑箱系统： 供应商不会共享其模型提示，但会公开经过签名的智能体卡片。您仍可获得清晰的合约以及任务级别的审计追踪。
  安全敏感的黑箱系統：供應商不會共享其模型提示，但會公開經過簽名的智能體卡片。您仍可獲得清晰的合約以及任務級別的審計追蹤。
• 混合技术栈与多语言协作： TypeScript 前端可以调用 Python 数据科学代理，反之亦然，因为只有 JSON-RPC 在网络上传输。
  混合技術棧與多語言協作：TypeScript 前端可以調用 Python 數據科學代理，反之亦然，因為只有 JSON-RPC 在網絡上傳輸。
• 需要进度更新的长时间运行任务： 构建流水线、PDF 渲染、数据导出 —— 通过服务器发送事件流式传输状态和产物，而非轮询自定义 REST 端点。
  需要進度更新的長時間運行任務：構建流水線、PDF 渲染、數據導出 —— 通過伺服器發送事件流式傳輸狀態和產物，而非輪詢自定義 REST 端點。

可能有些过度设计#

• 所有流程运行在单一进程中： 如果整个流程都在所选编排器内部完成，直接使用框架的内存调用即可。
  所有流程運行在單一進程中：如果整個流程都在所選編排器內部完成，直接使用框架的內存調用即可。
• 微型辅助脚本： 一个仅调用单个 OpenAI 函数的 cron 任务无需发现或流式处理功能，直接 API 调用更为轻量。
  微型輔助腳本：一個僅調用單個 OpenAI 函數的 cron 任務無需發現或流式處理功能，直接 API 調用更為輕量。
• 一次性数据提取： 对于延迟和通信量不重要的每周导出，简单的 REST 端点更易于监控。
  一次性數據提取：對於延遲和通信量不重要的每週導出，簡單的 REST 端點更易於監控。
• 模式复杂、提示简单的工具： 当主要需求是验证提示中的复杂参数时，单独使用 MCP 就是合适的层级。
  模式複雜、提示簡單的工具：當主要需求是驗證提示中的複雜參數時，單獨使用 MCP 就是合適的層級。

当任务跨越网络边界且您关注信任、实时进度或后续替换新专业代理时，请选择 A2A 协议。如果已有完善文档记录的 API 能满足需求，或者您的整个技术栈可以运行在贴在显示器上的树莓派上时，则无需使用它。
當任務跨越網絡邊界且您關注信任、實時進度或後續替換新專業代理時，請選擇 A2A 協議。如果已有完善文檔記錄的 API 能滿足需求，或者您的整個技術棧可以運行在貼在顯示器上的樹莓派上時，則無需使用它。

A2A 协议并非为模型增添新的魔法，而是提供可靠的安全握手机制，让您现有的智能体能够相互连接、交换任务并保持清晰可追溯的审计记录。
A2A 協議並非為模型增添新的魔法，而是提供可靠的安全握手機制，讓您現有的智能體能夠相互連接、交換任務並保持清晰可追溯的審計記錄。

注册表的故事仍需要自行搭建，目前许多智能体还停留在私有演示阶段，但这些基础设施已足够支撑原型开发和内部工作流。
註冊表的故事仍需要自行搭建，目前許多智能體還停留在私有演示階段，但這些基礎設施已足夠支撐原型開發和內部工作流。

减少胶水代码，专注更有价值的工作。
減少膠水代碼，專注更有價值的工作。