Google把6個(gè)回調(diào)藏了3年，開(kāi)發(fā)者發(fā)現(xiàn)后成本直降40%

去年有個(gè)數(shù)據(jù)挺有意思：某團(tuán)隊(duì)把ADK代理部署到QA環(huán)境后，產(chǎn)品經(jīng)理和測(cè)試組同時(shí)投訴——太慢，太貴。開(kāi)發(fā)者回頭一查，發(fā)現(xiàn)Gemini調(diào)用次數(shù)比預(yù)期多了3倍，單次會(huì)話延遲飆到8秒以上。

問(wèn)題不在模型，在 orchestration（編排）層的「觀測(cè)盲區(qū)」。Google ADK 提供了6個(gè)回調(diào)鉤子（callback hooks），分別卡在代理執(zhí)行前后、模型調(diào)用前后、工具執(zhí)行前后。但文檔里一筆帶過(guò)，多數(shù)開(kāi)發(fā)者直到成本失控才想起這回事。

回調(diào)鉤子本質(zhì)上是把「確定性邏輯」從代理體內(nèi)抽出來(lái)，扔到更輕量的執(zhí)行層。比如格式校驗(yàn)、狀態(tài)更新、審計(jì)日志——這些不需要LLM推理，卻占了大量token和等待時(shí)間。

從8秒到200毫秒：一個(gè)具體案例

我的項(xiàng)目里有7個(gè)子代理：project、anti-patterns、decision、recommendation、audit、upload、merger、email。前5個(gè)是LLM代理，后3個(gè)對(duì)接外部API。

最初我把所有邏輯塞進(jìn)prompt，讓Gemini-3.1-Flash-Lite自己拆、自己判、自己合。本地測(cè)試時(shí)只關(guān)心正確性，性能？「后面再說(shuō)」。結(jié)果QA環(huán)境暴露真相：每次會(huì)話要調(diào)Gemini 12-15次，其中40%的調(diào)用其實(shí)在干「合并JSON」「檢查字段完整性」這種臟活。

重構(gòu)方案：在project、anti-patterns、decision、recommendation、merger這5個(gè)代理里植入回調(diào)鉤子。

具體改動(dòng)：

? before_agent_callback：預(yù)加載項(xiàng)目上下文，避免重復(fù)查詢(xún)數(shù)據(jù)庫(kù)

? before_model_callback：攔截簡(jiǎn)單判斷，直接走規(guī)則引擎，跳過(guò)LLM

? after_model_callback：標(biāo)準(zhǔn)化輸出格式，減少下游代理的解析負(fù)擔(dān)

? after_agent_callback：異步寫(xiě)審計(jì)日志，不阻塞主流程

效果：LLM調(diào)用次數(shù)從15次壓到6次，平均延遲從8.2秒降到1.8秒，token成本下降約41%。

香港開(kāi)發(fā)者的小麻煩

有個(gè)細(xì)節(jié)可能幫到人。Gemini在香港不可用，但項(xiàng)目需要部署到亞太節(jié)點(diǎn)。我的解法：強(qiáng)制走Vertex AI通道。

環(huán)境變量這么配：

GEMINI_MODEL_NAME="gemini-3.1-flash-lite-preview"

GOOGLE_CLOUD_PROJECT="你的項(xiàng)目ID"

GOOGLE_CLOUD_LOCATION="global"

GOOGLE_GENAI_USE_VERTEXAI=T

最后一行是關(guān)鍵。T代表true，強(qiáng)制啟用Vertex AI后端，繞過(guò)區(qū)域限制。代價(jià)是多一層網(wǎng)絡(luò)跳轉(zhuǎn)，延遲+80ms左右，但合規(guī)。

依賴(lài)鎖定也做了嚴(yán)格處理。企業(yè)級(jí)部署最怕「本地能跑，線上崩了」：

npm i --save-exact @google/adk

npm i --save-dev --save-exact @google/adk-devtools

--save-exact 鎖死版本號(hào)，開(kāi)發(fā)機(jī)和生產(chǎn)機(jī)字節(jié)級(jí)一致。另外裝了marked做Markdown轉(zhuǎn)HTML，nodemailer對(duì)接MailHog做本地郵件測(cè)試——這些在回調(diào)里高頻觸發(fā)，穩(wěn)定性必須保證。

回調(diào)不是萬(wàn)能藥，用錯(cuò)地方會(huì)反噬

見(jiàn)過(guò)一個(gè)反例：某團(tuán)隊(duì)在before_model_callback里塞了重試邏輯，模型超時(shí)后自動(dòng)換備用key。聽(tīng)起來(lái)合理，實(shí)際埋雷——回調(diào)執(zhí)行沒(méi)有超時(shí)保護(hù)，備用key也卡死時(shí)，整個(gè)代理hang住，沒(méi)有日志，沒(méi)有告警，排查花了6小時(shí)。

我的原則：回調(diào)里只放「確定能完事」的操作。任何可能阻塞、可能拋異常、可能依賴(lài)外部狀態(tài)的邏輯，要么扔給獨(dú)立服務(wù)，要么干脆留在代理里讓LLM兜底。

審計(jì)代理（Audit Trail）就是個(gè)典型。它對(duì)接Cloud Storage寫(xiě)日志，理論上可以塞在after_agent_callback里。但我選擇拆成獨(dú)立代理，通過(guò)事件總線異步觸發(fā)——寫(xiě)失敗就失敗，不影響主流程，后臺(tái)補(bǔ)錄就行。

回調(diào)鉤子的真正價(jià)值，是把「觀測(cè)性」從事后排查變成事前攔截。成本、延遲、審計(jì)，這三件事在ADK里被設(shè)計(jì)成同一套機(jī)制，但文檔沒(méi)告訴你該怎么拆。我的建議是：先畫(huà)調(diào)用鏈，標(biāo)出每個(gè)節(jié)點(diǎn)的「LLM必要性」——凡是規(guī)則能Cover的，往回調(diào)里遷。

目前ADK的回調(diào)生態(tài)還在早期，社區(qū)里多是零星案例。Google官方示例偏重功能演示，缺少生產(chǎn)環(huán)境的邊界處理。如果你也在用ADK做企業(yè)級(jí)部署，回調(diào)鉤子的超時(shí)策略、錯(cuò)誤降級(jí)、冪等設(shè)計(jì)，你是怎么處理的？