打 GitHub API 問 kagent 的最新 release，releases/latest 回的是 v1.0.0-alpha14，2026 年 10 月 16 日當天才發出來。版號自己寫著 alpha。同一個 repo 的穩定線，10 月 2 日才剛發完 v0.10.3。

Latest 會落到 alpha 頭上，原因在一個欄位：從 alpha1 到 alpha14，14 個 release 的 prerelease 全部是 false。GitHub 的 API 文件寫明，latest 取的是最近一個非 prerelease、非 draft 的 release，tag 名稱裡有沒有 alpha 不在條件裡。所以任何照 releases/latest 抓版本號的腳本，現在拿到的都是一個 alpha。

這個小落差剛好是一條線頭。往回拉，會拉出 kagent 這一年多最主要的一件事：它一直在改自己的宣告式 API，而 v1.0 是改得最大的一次。

kagent 的 README 第一句是這樣寫的：

kagent is a Kubernetes native framework for building AI agents.

下面另一句：「kagent is a Cloud Native Computing Foundation project.」它在 CNCF 是哪個成熟度層級，README 沒寫，我也沒去查，這篇就不寫。2026 年 10 月 16 日查 GitHub API，Apache-2.0 授權，4,033 顆星、841 個 fork，contributors API 分頁數下來是 206 個帳號（沒扣掉 bot），release 一共 185 筆，最後一筆就是當天的 alpha14。

我手上的東西全是 GitHub API 吐出來的：repo 資料、release 列表、README，加上十份 release note 的前段。kagent 沒裝過、叢集上沒跑過，原始碼和文件網站也沒翻。所以下面每講到一個功能，都只代表「release note 有這一行」。日期一律照 GitHub 記的 UTC 時間，換成台灣時間，有幾版會跨到隔天。

先把 agent 當成一種資源

kagent 的出發點，用 Kubernetes 的人一聽就懂：既然 Deployment、Service 都是寫一份 YAML 交給 controller 去收斂，agent 為什麼不行。README 的描述是，agent 透過 RemoteMCPServer 這種資源連到 MCP server，內建的 MCP server 帶了 Kubernetes、Istio、Helm、Argo、Prometheus、Grafana、Cilium 這些工具；controller 對外開 gRPC、A2A 和 MCP 三種 API。

這個選擇的好處很直接。agent 變成叢集裡的一個物件，可以進 GitOps、可以被 RBAC 管、可以跟其他資源一起 kubectl apply。代價也很直接，而且要一段時間才會浮出來：你的 YAML 是跟 controller 簽的一份合約。合約上的欄位名稱，只要改一次，所有照舊合約寫的人都得跟著改。

kagent 的版本史，幾乎就是這份合約的修訂史。

kagent 的版本時間線（依 GitHub release 發佈日，取證 2026-10-16）

2025 年 1 月 21 日

repo 建立。

2025 年 3 月 4 日～14 日

最早的 release v0.0.2、v0.0.3 在 3 月 4 日同一天發出，0.0.x 一路發到 3 月 13 日的 v0.0.19。3 月 14 日發 v0.1.0，release note 是空的。

2025 年 5 月 2 日

v0.3.0，第一批列在 Breaking Changes 底下的 CRD 欄位改名。

2025 年 7 月～10 月

v0.4.0（7/8）bump A2A；v0.5.0（8/6）加 ADK 支援；v0.7.0（10/29）把 KMCP 整合拆開，加上 HITL。

2026 年 3 月～9 月

v0.8.0（3/23）Go 程式碼拆成 api、core、adk 三個模組；v0.9.0（4/22）agent sandbox；v0.10.0（9/4）sandbox 接上 substrate。

2026 年 9 月 18 日～10 月 16 日

v1.0.0-alpha1 帶進 API v2 的設定 CRD，之後連發到 alpha14。同一段時間，v0.10.2、v0.10.3 繼續在修穩定線。

2025 年 3 月：十天發完一串 0.0.x

repo 在 2025 年 1 月 21 日建立，42 天後才有第一個 release。然後節奏突然變快：v0.0.2 和 v0.0.3 同一天，3 月 4 日；3 月 7 日已經到 v0.0.9；3 月 13 日到 v0.0.19。十天裡 17 個 0.0.x。隔天 3 月 14 日發 v0.1.0，release note 一個字都沒有。

所以「v0.1.0 帶來了什麼」，我答不出來，GitHub 上也沒有答案。能確定的只有時序：建 repo 之後安靜了一個多月，然後十天內把版號從 0.0.2 推到 0.1.0。0.1.x 接著發到 4 月 20 日的 v0.1.16，4 月 23 日 v0.2.0，5 月 2 日 v0.3.0。

v0.3.0：第一次改合約

v0.3.0 的 release note 有一段 Breaking Changes，列了四件事：

Agent 的 tools 底下有一種型別叫 inline，改名成 builtin，它底下的 provider 改成 name。Agent 的 modelConfigRef 改成 modelConfig。ModelConfig 的 APIKeySecretName 改成 APIKeySecretRef。helm 的預設 provider 設定，改成支援 openai 以外的 provider。

單看每一條都很小。換個比喻比較好懂：這像公司把請款單上的「廠商名稱」欄改叫「供應商」，「附件編號」改叫「附件連結」。表單本身變好了，名字更準。可是倉庫裡每一張照舊格式填的單子，都得有人一張一張改過再送。Kubernetes 的 YAML 就是那疊單子，而且它們通常散在好幾個 repo、好幾條 GitOps pipeline 裡。

APIKeySecretName 改成 APIKeySecretRef 這條，光看名稱就是從「放一個名字」變成「放一個參照」。為什麼這樣改，release note 沒寫；不管理由多好，代價都由所有既有使用者付。

同一版還有一行「support nested agents (agent-as-tool) from UI」，agent 可以把另一個 agent 當工具用。這條是加功能，沒有破壞誰。

中間那一年：接上別人的協定，拆掉自己的東西

接下來一年，release note 的關鍵字開始換成別家的名字。

2025 年 7 月 8 日的 v0.4.0，release note 裡有一行「bump-a2a-0.2.0」，句子是截斷的，我只能確認這個片語在裡面。8 月 6 日的 v0.5.0 有「feat(all): add support for ADK」。ADK 的全名在那一行沒寫，我沒有去翻 PR 確認它指的是哪一套，所以這裡只寫 ADK 三個字母。這個名字後來越長越大：2026 年 3 月 23 日的 v0.8.0，Go 程式碼重整成 api、core、adk 三個模組；同一版的 Declarative Agent CRD 多了一個 runtime 欄位，讓你選 Go 還是 Python。

這段期間也有東西被拆掉。2025 年 10 月 29 日的 v0.7.0 有一行「Decouple KMCP integration」，把 KMCP 的整合拆開；2026 年 4 月 22 日的 v0.9.0 有一行「Replace GORM + AutoMigrate with golang-migrate + sqlc」，原本用 GORM 加 AutoMigrate 管資料表的做法整個換掉。為什麼拆、拆的時候碰到什麼，release note 的標題沒說，我也不替他們猜。GORM 那一條至少看得出方向：資料表遷移從程式自己 AutoMigrate，換成獨立的 migration 工具加上 sqlc。很多專案長大以後都會走這條路，只是每走一次，升級說明就要多寫一段。

v0.9.0 還有兩行跟後面有關：「feat: agent sandbox support」和「Add sandbox network allowlists for Go and Python」。agent 開始有自己的沙箱，沙箱有網路白名單。同一版還有「OIDC proxy auth」。

v0.10.0 的週期拉得最長：2026 年 6 月 29 日發 beta1，經過 beta11、rc1 到 rc6，9 月 4 日才正式發。兩個多月。release note 裡有「enable sharing of chat sessions」，有「substrate support for BYO and python runtimes for SandboxAgent CR」，有兩行 bump agent substrate 到 0.0.7、0.0.8，還有一行「add claude ACP sandbox target」。substrate 是另一個元件，它自己的 repo、版本和歸屬我都沒查，這裡只記錄 kagent 的 release note 提到它。

9 月 18 日之後，兩條線一起跑

v0.10.0 發出去 14 天後，9 月 18 日，v1.0.0-alpha1 出來了。這一份 release note 裡有三行，讀起來跟之前完全是兩個量級：

add API v2 configuration CRDs
add AgentTemplate preparation and immutable revisions
add minimal API v2 controller runtime

同一份還有「add upstream A2A gRPC runtime servers」、「support fetching skills from S3」，以及三行 harness：「Initial Claude Code Support」、「Initial Codex Support」、「add BYO A2A harness」。

v0.3.0 是在既有的合約上改幾個欄位名。alpha1 是另開一份新合約：新的設定 CRD、新的 controller runtime、AgentTemplate 加上不可變的 revision。這些東西之間怎麼接，harness、substrate、sandbox 在 v1.0 裡各站在哪一層，我只看過 release note 的標題，沒讀文件和原始碼，講不出架構圖。光看標題就夠說明一件事：v1.0 是一次 API 換代。

然後是節奏。alpha1 在 9 月 18 日，alpha13 在 10 月 13 日，25 天發了 13 個，10 月 9 日和 10 月 13 日都是一天兩版。10 月 16 日再補一個 alpha14，算下來 28 天 14 個。中間的 alpha5（9 月 27 日）加了「explicit Agent definitions and Sessions」和「SandboxTemplate and Sandbox contracts」；10 月 13 日的 alpha13 有一行「replace application env vars with explicit schemas」，原本靠環境變數傳的設定，改成明確的 schema。到第 13 個 alpha，合約本身都還在長新條款。

穩定線也沒有停：v0.10.1 在 9 月 8 日，alpha1 出來之後還有 v0.10.2（9 月 23 日）、v0.10.3（10 月 2 日）。兩條線並行，穩定線收修補，新線換 API。

回到開頭那個欄位。alpha 的 prerelease 都是 false，所以 GitHub 的 Latest 標籤掛在 alpha14 身上，v0.10.3 反而沒有。對只看 repo 首頁的人，這是小事；對那種「每天抓 releases/latest、有新版就升」的自動化，大約每兩天就會把一份還在改條款的新合約推進叢集。

我的做法會是：現在要在共用叢集上用 kagent，版本釘死在 v0.10.x，自己抓版本的腳本不要用 releases/latest，改成明確列版號，或者過濾掉 tag 名含 alpha 的。v1.0 的 alpha 只放在拿來看新 API 長什麼樣、隨時可以砍掉重建的叢集。

從零開始的人例外。手上還沒有任何 v0.x 的 YAML 要遷移，alpha 期間先熟悉 API v2，可能比先學一套馬上要換掉的 v0.10 合約划算，代價是每兩三天就可能碰到欄位變動。等 v1.0.0 正式版出來、release note 寫清楚 v0.x 的 Agent CRD 怎麼遷過去，上面這套做法就該整個重想。

正式版要回答的那一題

v0.3.0 那次改名，release note 用一段 Breaking Changes 交代了四條。v1.0 是另開一份合約，量級完全不同。alpha 的 release note 我只讀了 alpha1、alpha5、alpha13 三份，每份都只讀前段，裡面列的是新增的 CRD、runtime 和 harness；遷移路徑有沒有寫在後段，我沒讀到，不能說有，也不能說沒有。

所以 v1.0.0 正式版發出來那天，我第一個要找的是這一行：手上那疊 v0.10 的 YAML，要怎麼變成 API v2。如果那一行寫得出來，kagent 就跨過了宣告式 API 最難的那道坎；如果寫不出來，v0.10.x 這條穩定線大概還得再修很久。

參考來源