A2A 通訊協定合約
A2A 通訊協定合約定義了在 Amazon Bedrock AgentCore 執行期中實作agent-to-agent通訊的需求。本合約會指定 A2A 伺服器必須實作的技術需求、端點和通訊模式。
如需範例程式碼,請參閱在 AgentCore 執行期中部署 A2A 伺服器。
通訊協定實作要求
您的 A2A 伺服器必須實作這些特定的通訊協定需求:
-
傳輸 :透過 HTTP 的 JSON-RPC 2.0
- 啟用標準化agent-to-agent通訊 -
工作階段管理:平台會自動新增工作階段隔離的
X-Amzn-Bedrock-AgentCore-Runtime-Session-Id標頭 -
客服人員探索:必須在
/.well-known/agent-card.json端點提供客服人員卡
容器需求
您的 A2A 伺服器必須部署為符合下列規格的容器化應用程式:
-
主機 :
0.0.0.0 -
連接埠:
9000- A2A 伺服器通訊的標準連接埠 (不同於 HTTP 和 MCP 通訊協定) -
平台 :ARM64 容器 - 與 Amazon Bedrock AgentCore AWS 執行期環境相容時需要
路徑需求
/ - POST
用途
接收 JSON-RPC 2.0 訊息,並透過代理程式的功能進行處理,透過 A2A 通訊協定訊息完成傳遞 InvokeAgentRuntime API 承載
使用案例
根端點有幾個主要用途:
-
Agent-to-agent之間的通訊和協同合作
-
多步驟代理程式工作流程和任務委派
-
客服人員之間的即時對話體驗
-
工具調用和功能共用
要求格式
A2A 伺服器預期 JSON-RPC 2.0 格式的請求:
Content-Type: application/json { "jsonrpc": "2.0", "id": "req-001", "method": "message/send", "params": { "message": { "role": "user", "parts": [ { "kind": "text", "text": "Your message content here" } ], "messageId": "unique-message-id" } } }
回應格式
A2A 伺服器會以包含任務和成品的 JSON-RPC 2.0 格式回應進行回應:
Content-Type: application/json { "jsonrpc": "2.0", "id": "req-001", "result": { "artifacts": [ { "artifactId": "unique-artifact-id", "name": "agent_response", "parts": [ { "kind": "text", "text": "Agent response content" } ] } ] } }
/.well-known/agent-card.json - GET
用途
為客服人員探索和功能公告提供客服人員卡中繼資料
使用案例
客服人員卡端點有幾個主要用途:
-
多代理程式系統中的代理程式探索
-
功能和技能公告
-
身分驗證需求規格
-
服務端點組態
回應格式
傳回描述代理程式身分和功能的 JSON 中繼資料:
Content-Type: application/json { "name": "Agent Name", "description": "Agent description and purpose", "version": "1.0.0", "url": "https://bedrock-agentcore.region.amazonaws.com/runtimes/agent-arn/invocations/", "protocolVersion": "0.3.0", "preferredTransport": "JSONRPC", "capabilities": { "streaming": true }, "defaultInputModes": ["text"], "defaultOutputModes": ["text"], "skills": [ { "id": "skill-id", "name": "Skill Name", "description": "Skill description and capabilities", "tags": [] } ] }
/ping - GET
用途
驗證您的 A2A 伺服器是否正常運作並準備好處理請求
回應格式
傳回狀態碼,指出代理程式的運作狀態:
-
Content-Type:
application/json -
HTTP 狀態碼:
200適用於運作狀態不良、適當的錯誤碼
{ "status": "Healthy" }
status 為必要項目,且為 Healthy或 之一HealthyBusy。當狀態為 時HealthyBusy,執行階段工作階段會保持運作狀態。
可能會包含選用time_of_last_update欄位 (以秒為單位的 Unix 時間戳記),以報告status上次變更的時間。
警告
請勿在每個 ping 上time_of_last_update將 設定為目前時間。在每個 ping 上推進的時間戳記會發出持續狀態變更,防止閒置工作階段逾時永遠觸發 — 然後工作階段會保留到 ,MaxLifetime並可以耗盡工作階段配額。如果您省略 欄位,平台會自行追蹤狀態變更。如果您使用 Bedrock AgentCore 開發套件,則會為您處理 ping 回應。
身分驗證要求
A2A 伺服器支援多個身分驗證機制:
OAuth 2.0 承載權杖
對於 A2A 用戶端身分驗證,請在請求標頭中包含承載字符:
Authorization: Bearer <oauth-token> X-Amzn-Bedrock-AgentCore-Runtime-Session-Id: <session-id>
SigV4 身分驗證
程式設計存取也支援 Standard AWS SigV4 身分驗證。
錯誤處理
A2A 伺服器會傳回標準 JSON-RPC 2.0 錯誤回應與 HTTP 200 狀態碼,以維持通訊協定合規:
| JSON-RPC 錯誤代碼 | 執行時間例外狀況 | HTTP 錯誤代碼 | JSON-RPC 錯誤訊息 |
|---|---|---|---|
|
-32501 |
ResourceNotFoundException |
404 |
找不到資源 - 請求的資源不存在 |
|
-32052 |
ValidationException |
400 |
驗證錯誤 - 無效的請求資料 |
|
-32053 |
ThrottlingException |
429 |
超過速率限制 - 請求太多 |
|
-32054 |
ResourceConflictException |
409 |
資源衝突 - 資源已存在 |
|
-32055 |
RuntimeClientError |
424 |
執行期用戶端錯誤 - 如需詳細資訊,請檢查您的 CloudWatch 日誌 |
錯誤回應範例:
{ "jsonrpc": "2.0", "id": "req-001", "error": { "code": -32052, "message": "Validation error - Invalid request data" } }
OAuth 身分驗證回應
OAuth 設定的代理程式遵循 RFC 6749 (OAuth 2.0)
401 未授權 - 缺少身分驗證
HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{ESCAPED_ARN}/invocations/.well-known/oauth-protected-resource?qualifier={QUALIFIER}"
注意
SigV4-configured代理程式傳回 HTTP 403 時發生錯誤ACCESS_DENIED,且不包含WWW-Authenticate標頭。