昨天結束在一個畫面上：agent 註冊成功、狀態 ENABLED、分享給所有人、有 icon，前台看得到它。問它話，回「回答問題時發生錯誤，請稍後再試」。

這種訊息什麼都沒說。所以不要猜，去量。

順帶補一個細節：昨天講的那個註冊錯地方的 app，完整 id 是 test-enterprise-app_1785400201537，底下其實掛著 gateway 跟 registry，只是那個 org 缺 Cloud Identity customer id，開不出前台，所以那一小時忙的是一個連前台都打不開的目標。這個對照值得記住，因為它說明「有 gateway」不等於「用得起來」，跟今天要講的「沒有 gateway」是同一類問題的兩種長相。

一筆決定性的證據

我照 Day 28 的第三步撈 Cloud Run 日誌，時間窗抓在我提問的前後二十分鐘：

• 三筆 GET /.well-known/agent.json 200，那是我自己 curl 測試的
• 零筆 POST

零筆 POST 的意思是：Gemini Enterprise 從頭到尾沒有往我的服務發出任何請求。

這一筆量測直接把整個問題的範圍砍掉一半。錯不在我的 agent，也不在 A2A 的實作、agent card 的格式或託管方式。它連打都沒打。

我很喜歡這種證據，因為它不需要解讀。有請求或沒請求，不是程度問題。

這也是我把 Day 28 那三步診斷順序寫下來的原因：如果我當時繼續調 sharingConfig 或 icon，永遠不會撈到這條日誌，因為那些欄位跟「對方有沒有打進來」完全無關。三筆 GET 兩百跟零筆 POST 放在一起看，意義完全不一樣。前者證明我的服務活著、路由沒問題；後者證明問題不在服務端這一側。兩件事合起來，懷疑範圍收斂到剩下一個方向：GE 那端根本沒有嘗試對外連線。

那 GE 為什麼不往外打

把兩個 engine 的 JSON 拉出來 diff，答案就出來了：

沒有 gateway、沒有 registry，GE 沒有對外的出口。跟我用 Cloud Run 還是 Agent Runtime、用 A2A 還是 ADK，完全無關。

那補上 gateway 就好了吧

我也是這樣想的。然後撞到牆。

gcloud services enable networkservices.googleapis.com --project=<GE 專案>

用辦這個 GE 租戶的帳號執行，回 AUTH_PERMISSION_DENIED，訊息是「does not have permission to access projects instance ... (or it may not exist)」。

改走 REST 建 gateway、以及 PATCH agentGatewaySetting，兩者都回 403 SERVICE_DISABLED。

小結

到這裡，量測已經把問題釘死在一個很窄的範圍：agent 本身沒問題，服務端有回應能力，GE 也確實看得到這張卡，唯獨缺了對外的 gateway 跟 registry，而補上它的兩條路都被權限擋下來。這不是「差一點設定沒調對」，是連嘗試的權限都沒有。

回頭看整個過程，真正省時間的不是猜對答案，是先把「有沒有請求進來」這種可以直接量到的事實確認掉，再往下一層追。如果順序反過來，先假設是 agent card 格式錯了，或是託管方式不對，會在完全不相關的地方繞很久，因為那些假設沒有一個是能被三十分鐘內量出來的。明天講這個權限缺口到底卡在哪一層，以及這 30 天走下來，這條判準能帶走什麼。