app/agent.py 連授權宣告帶兩個範例函式大約 70 行，agent 本體的定義只有這一段：

MODEL = "gemini-3.6-flash"

root_agent = Agent(
    name="root_agent",
    model=Gemini(
        model=MODEL,
        retry_options=types.HttpRetryOptions(attempts=3),
    ),
    instruction="You are a helpful AI assistant designed to provide accurate and useful information.",
    tools=[get_weather, get_current_time],
)

app = App(
    root_agent=root_agent,
    name="app",
)

四個參數：名字、模型、指令、工具清單。沒有 YAML，沒有註冊表。

這個簡潔本身是一個設計決定。我以前用過的一些 agent 相關工具，光是把一個 agent 掛起來，就要先寫一份 YAML 描述它的角色、能力、路由規則，再交給一個獨立的載入器去解析。這裡整個定義就是一個 Python 物件的建構子呼叫，四個參數直接對應四件事：name 是識別，model 是決策引擎，instruction 是行為設定，tools 是能力清單。少了中間那層宣告檔，代價是這四個參數裡有兩個看起來只是設定值，實際上各自牽動一層不會馬上想到的行為，這篇剩下的篇幅就在講這兩個地方。

模型層的重試，跟流程層的重試不一樣

retry_options=types.HttpRetryOptions(attempts=3) 這行值得看清楚它管什麼。

它是 HTTP 層的重試，處理連線失敗、429 之類的傳輸問題。它不處理「答得不好所以重寫一次」。

我在 LangGraph 那幾篇會講 conditional edge 做的重試，那個是在流程圖上繞回上游節點，判斷條件是你寫的 Python，例如 score 不達標且 retry_count < 3。兩種重試在不同層，解決不同問題。

把它們混在一起想會做出很怪的設計，例如用 HTTP 重試次數去控制內容品質。那不會有用，因為第一次呼叫成功回傳一個爛答案，對 HTTP 層來說是 200，不會觸發任何重試。

這個誤會的根源，我猜是因為兩種重試字面上長得很像：都叫 retry，都有次數上限。但它們綁定的失敗訊號完全不同。HTTP 層的重試綁的是傳輸層訊號，連線中斷、逾時、伺服器回 5xx 或限流的 429，這些在應用邏輯跑起來之前就已經發生；流程層的重試綁的是自己定義的業務訊號，例如一個評分函式判斷輸出不合格。HttpRetryOptions 拿不到，也不該拿到「答案好不好」這種語意層的資訊。想在模型層做內容重試，是問錯了問題。

Agent 外面還有一層 App

第一次看我以為 App 是多餘的包裝。它不是。

App 有自己的 name，而這個 name 會出現在 A2A 的路由路徑上。我在 Day 9 curl 到的 card 端點是：

/a2a/app/.well-known/agent-card.json

那個 app 就是 App(name="app") 來的。改掉它，別的 agent 抓卡的路徑也跟著變。這種「設定值變成 URL 的一部分」的欄位，改之前要先想清楚誰在打它。

我對這個設計的猜測是：Agent 描述的是「這個 agent 怎麼想」，App 描述的是「這個 agent 怎麼被外部找到」，兩種完全不同的關注點。把兩者分開，Agent 本身可以維持跟外部世界無關，App 才是知道自己會被掛在哪個路徑上的那一層，這也解釋了為什麼 name 放在 App 上面：路由是 App 的職責。我沒去翻 ADK 內部的路由實作驗證過，先標成未查證。

小結

這篇看起來只是把 agent.py 的十幾行程式碼念一遍，但兩個容易被忽略的地方就藏在裡面。下一篇接著看剩下兩個參數，instruction 為什麼只是一個字串卻決定了整個 agent 的行為，以及換模型這件事實際要付出什麼代價。