把一隻現成的 agent 變成 A2A server，要寫多少 code？

答案是一個 class，大約 20 行。它叫 AgentExecutor。

它做的四件事

AgentExecutor 是雙向翻譯層，職責可以拆成四步：

1. 從協定的請求物件挖出使用者輸入(context.get_user_input())
2. 用底層框架吃得下的格式呼叫它(LangGraph 的 ainvoke、CrewAI 的 kickoff、ADK 的 runner)
3. 把框架的輸出包成協定的 artifact，推進 event queue
4. 再推一筆狀態事件標記 completed

就這樣。進來翻譯一次，出去翻譯一次。

其餘的誰做

剩下的全部由 SDK 提供：

• HTTP 伺服器
• JSON-RPC 請求解析
• Task 狀態機(submitted → working → completed)
• Agent Card 的路由與供應

這個分工是我覺得 A2A 設計得好的地方。它把「所有人都要做而且做法一樣」的部分收進 SDK，只留下「每個人都不一樣」的那一小塊給你寫。

為什麼這個形狀重要

因為它意味著你的 agent 不需要為了支援 A2A 而改寫。

原本的 LangGraph graph 不動，原本的 CrewAI crew 不動，原本的 ADK agent 也不動。你只是在外面包一層 20 行的轉接頭。

這跟很多框架的做法相反。有些框架要你「用我的方式定義 agent」，然後才提供互通能力，結果是採用它的成本等於重寫。A2A 走的是反方向：協定只管邊界長什麼樣，邊界裡面隨便你。

一個判準

這件事可以反過來拿來評估框架。

評估一個 agent 框架能不能進正式系統，先問它的輸入輸出能不能被 20 行 adapter 包起來。

包不起來，表示它把太多假設洩漏到邊界外：也許它要求呼叫方管理某個 session 物件，也許它的輸出格式綁死某個 UI，也許它的錯誤處理需要呼叫方配合。這些都是未來換掉它時要付的錢。

明天

Executor 這個形狀還有一個更有意思的後果：呼叫方拿到的 Task 物件裡，沒有任何欄位透露對方用什麼框架。這代表什麼、以及 Executor 寫太厚是什麼警訊，明天講。