昨天(Day 17)講 AgentExecutor 只做雙向翻譯，進去翻譯一次、出去翻譯一次。今天講這個設計最有價值的後果。

呼叫方看不到框架

打開一次 A2A 往返拿到的 Task 物件，從頭找到尾，沒有任何欄位透露對方用什麼框架。

沒有 framework: "langgraph"，沒有 engine 欄位，連錯誤訊息的格式都是協定定義的。

所以同一個系統裡混用 LangGraph、CrewAI、ADK 是可行的，而且換框架不需要動呼叫方。這個 codelab 本身就是這樣安排的：兩隻 seller agent 底層用不同框架，orchestrator 完全不知情也不需要知情。

順著這個現象往下推：如果呼叫方完全看不到框架，那團隊之間的協作邊界也可以照這條線切。負責 orchestrator 的人不需要懂 remote agent 內部用什麼框架寫，只要對方的 Agent Card 跟 Executor 行為符合協定，兩邊就能各自升級、各自換框架而互不影響。這是我自己順著協定形狀推出來的想法，還沒有在多團隊的場景裡真的驗證過。

這是一個有名字的東西

這是 Adapter pattern 落在 agent 生態的位置，也是 Clean Architecture 講的 boundary：

協定是穩定的介面，框架是可替換的細節。

2026 年的 agent 框架生態變動很快，今天的主流明年可能沒人用。在這種環境下，把框架選擇當成「架構決策」是危險的，那會讓整個系統的壽命綁在一個套件的壽命上。今天選定的框架，很可能兩年後就要換掉，如果換框架的代價是重寫呼叫方，那每一次框架更迭都是一次系統性風險。

把它降級成「邊界後面的實作細節」，你就買到了換掉它的權利。20 行的代價換這個，划算。這也是為什麼我會把 Executor 的薄，看成一種刻意的設計選擇，而不是偷懶：它把「框架會變」這個已知的風險，提前隔離在邊界外面，讓系統的壽命不必綁在單一套件的壽命上。

小結

Executor 這一層薄薄的翻譯，換來的是呼叫方對框架的無知，而這種無知是刻意設計出來的，不是意外。但這個形狀能不能守住，取決於 Executor 有沒有偷偷變厚，這是明天的主題。