ADK Go 1.0 把 Agent 拉進正式環境

Google 剛把 Agent Development Kit for Go 1.0 推上來。這版離 Go 誕生 19 年，時間點很有意思。Google 不是在做玩具，是把 AI Agent 當正式軟體在處理。

這件事很現實。Agent 只要一個工具呼叫失敗，整條流程就可能歪掉。模型會亂掰，API 會逾時，外部服務也可能卡住。Google 這次的方向很明確，就是讓開發者能追蹤、控制、部署。

ADK Go 1.0 到底加了什麼

先講白的，這版不是只加幾個 API 而已。它把觀測、恢復、審核和協作，直接塞進框架裡。對做後端的人來說，這種東西比花俏 Demo 實用太多。

核心專案放在 ADK Go GitHub repository。裡面有 SequentialAgents、ParallelAgents、LoopAgents。意思很直白，就是你可以用串行、平行、循環三種方式組 Agent 流程。

Google 這次也把不少正式環境會用到的東西補齊。像是 tracing、plugins、YAML 設定、人工確認、A2A 協作。這些東西看起來零散，但放在一起就很像一套能上線的骨架。

• 原生 OpenTelemetry 整合
• 插件系統可放 logging、retry、security filter
• 敏感工具支援人工確認
• YAML 可直接定義 agent
• 支援 Agent2Agent 協定

我覺得這個方向很合理。Agent 最大的問題，從來不是會不會講話，而是能不能穩定做事。Google 這次就是在補那個落差。

OpenTelemetry 讓 Agent 不再黑箱

Agent 難 debug，這件事大家都懂。因為它不是固定流程。你很難只看一段 log，就知道問題出在 prompt、工具、網路，還是模型自己亂想。

ADK Go 1.0 直接接上 OpenTelemetry。這代表你可以把模型呼叫、工具執行、流程節點都做成 span。對已經有觀測系統的團隊來說，這很省事。

如果你本來就用 Cloud Trace，那更順。Agent 的行為可以跟其他服務一起看。出了問題，不用靠猜。你可以直接一路追下去，看是哪一步爆掉。

"We are thrilled to continue that legacy of high-performance engineering with the launch of Agent Development Kit for Go 1.0." — Google Developers Blog

這句話其實很有畫面。Google 想講的是，Go 不只是寫 web service 的工具。它現在也能拿來做需要追蹤和稽核的 AI 系統。

對工程團隊來說，這很重要。因為一個能 trace 的 Agent，才有機會進入正式環境。不能觀察，就很難維運。不能維運，就只能停在 demo。

插件和人工審核，才是能上線的重點

很多人看到 Agent 框架，第一個反應是：又一個包 prompt 的東西。老實說，這種懷疑很正常。因為太多框架只會秀功能，卻沒處理風險。

ADK Go 1.0 的插件系統，算是比較務實的做法。你可以把 retry、logging、policy check 拆成獨立插件，不用硬塞進主流程。這樣一來，Agent 行為比較好管，也比較好測。

Google 也示範了 Retry and Reflect 這種插件。工具失敗後，系統可以把錯誤回饋給模型，再試一次。這對那些常呼叫外部 API 的 Agent 很實用，因為真實世界本來就常出包。

更實際的是人工確認。對標成 RequireConfirmation 的工具，Agent 會先停下來，等人按同意。這種設計很適合金流、資料刪改、權限變更這類敏感操作。

• retry 可減少手動重跑流程
• logging 讓每一步都能查
• 人工確認可擋住高風險操作
• policy 與業務邏輯分開比較乾淨

這裡我想吐槽一下。很多團隊做 Agent，最後都把 prompt、規則、工具、例外處理混成一坨。那種東西後面一定很難維護。Google 這版至少有在拆層次。

YAML 和 A2A，讓多團隊合作比較不痛

另一個很實際的更新，是 YAML 設定。你不用每次改一點點都重新寫 Go 程式。很多 Agent 的角色、工具、子代理，其實都可以先放到設定檔。

這對產品團隊很有感。因為有些調整只是改文案、換工具、調流程。這種事不該每次都走完整開發流程。YAML 至少能把改動成本壓低。

Google 也強調跨語言一致性。Go、Java、Python 都能用差不多的方式定義 Agent。這對大公司很重要，因為不會只有一個語言在跑。現實是，後端、資料、平台團隊常常各用各的。

再來是 A2A。這是 Google 的 Agent2Agent 協定。它的重點不是炫技，而是讓不同語言的 Agent 可以比較穩地交換事件和回應。

• YAML 能減少樣板碼
• 子代理不用一直重寫
• A2A 可處理事件順序
• 回應聚合交給框架做

如果你做過多服務整合，就知道這種細節有多煩。少一點 glue code，專案就少一點爛尾風險。

Go 為什麼適合拿來做 Agent

Go 的優勢一直很明顯。編譯快、部署簡單、並行好用。對後端工程師來說，這些都是每天會碰到的痛點。ADK Go 1.0 只是把這些優勢搬到 Agent 世界。

Python 還是很強，尤其在原型開發。可是一到正式環境，很多團隊就會開始在意部署、觀測、權限和服務邊界。這時候 Go 就很順手，因為它本來就是拿來做基礎設施的。

Google 這次的節奏也很明顯。它不是只推模型，而是把開發工具、觀測系統、協定和安全流程一起補上。這代表它看的是整個 Agent 堆疊，不只是模型呼叫本身。

你可以把它想成一個訊號。Google 在說，Agent 不該只是聊天機器人。它應該像一般服務一樣，有 trace、有 policy、有審核，也能跨語言協作。

我覺得這會影響不少團隊的技術選型。以前大家可能先用 Python 試水溫。現在如果最後要進正式環境，Go 會更像一個合理選項。

這波變化其實在補產業缺口

AI Agent 這兩年很熱，但很多產品卡在同一個問題。Demo 很順，正式上線就開始漏風。原因很簡單，因為 Agent 本質上就是一串不完全可預測的決策。

產業現在最缺的，不是更多會聊天的模型，而是能管流程的框架。你要能看見每一步發生了什麼，也要能把高風險動作卡住。這才是企業會買單的地方。

Google 的做法，某種程度上是在跟市場講：別再只看 prompt。真正值錢的是整套運行系統。這套系統要能跑、能查、能回滾，也要能跟現有後端接起來。

如果你在做內部助理、客服流程、查詢 Agent、或半自動化工作流，這版 ADK Go 值得看。它不是最炫的方案，但很像會真的用到的工具。

接下來可能怎麼走

我的判斷很直接。接下來 6 到 12 個月，Go Agent 的重點會從「能不能做」變成「能不能管」。誰能把觀測、審核、協作做得更順，誰就比較容易進正式環境。

如果你現在已經有 Go 後端，我會建議先看 ADK Go 1.0。先挑一個低風險流程試。像是查資料、內部摘要、工單分流。不要一開始就拿去碰金流，真的沒必要。

說到底，這版最有價值的地方，不是它讓 Agent 更會講話，而是它讓工程師比較敢把 Agent 放進系統裡。這件事，才是產品團隊真正會在意的。

如果你要我給一個具體預測，我會說：接下來一年，會有更多 Go 團隊把 Agent 當成一般服務來管。問題不是要不要做，而是你要怎麼把它管好。