昨天(Day 18)談的是 Executor 這層翻譯換來框架可替換的好處。今天談這件事的另一面：Executor 也可能悄悄長歪，而它長歪的方向剛好跟它原本該有的形狀相反，兩層框架的邏輯往中間那薄薄一層擠，我把這個現象叫反向三明治。

反向訊號：Executor 越寫越厚

既然 Executor 該是 20 行，那它變厚就是警訊。

具體來說，看到這些東西出現在 Executor 裡就要停下來想：

• 業務邏輯（判斷該回什麼、怎麼算價格）
• 重試策略
• 狀態管理（自己維護一份對話歷史）
• 快取

這些出現在 Executor 裡，代表邊界放錯位置。它們應該在框架內部（業務邏輯、重試）或協定層（狀態，A2A 的 Task 狀態機已經在做了）。

寫在翻譯層的東西有個共同特徵：換框架的時候它們會一起被丟掉重寫，但它們其實跟框架無關。這就是白白付的錢。

實務上怎麼守住

我自己的做法是給 Executor 設一個行數上限，超過就當成 code smell 去追。這不是嚴謹的工程標準，但它有效，因為 Executor 變厚是漸進的：每次都只多五行，每次都有理由，三個月後它變成三百行而且沒人敢動。

一個粗糙但會觸發的規則，比一個正確但不會觸發的原則有用。

反過來想：拿它當框架的評估判準

「Executor 該薄，變厚是警訊」這個判斷可以倒過來用。既然一個設計得好的框架應該讓 Executor 維持在 20 行上下，那反過來推，評估一個 agent 框架能不能進正式系統，可以先問它的輸入輸出能不能被 20 行 adapter 包起來。

包不起來，通常代表這個框架把太多假設洩漏到邊界外：也許它要求呼叫方管理某個 session 物件，也許輸出格式綁死某個 UI，也許錯誤處理需要呼叫方配合特定流程。這些都是框架挑選階段就值得推敲的風險訊號，不用等到 Executor 寫到三百行才發現。這個推論目前只在我自己手上這幾個框架上想過，還沒拿大量框架驗證過，先當一個判斷方向，不當成放諸四海皆準的規則。

收尾

Day 17 到 19 合起來：A2A server 端只要寫一個 20 行的翻譯層，那 20 行買到的是「底層框架可以隨時換掉」，而「20 行包不包得住」這件事，還能倒過來當作挑框架時的判準。