- 10 min read

【AIOps】Kubernetes 原生的 AI Agent 框架：kagent 完整解析

深入解析 kagent —— 一個 CNCF Sandbox、基於 Google ADK 的 Kubernetes 原生 AI Agent 框架。帶你看懂它的三大核心支柱、生態系元件，以及如何透過 Human-in-the-Loop 讓 AI 成為受控的自動化夥伴。

AI AI Agent Kubernetes kagent MCP A2A AIOps CNCF Observability LLM

如果你已經用過 HolmesGPT、也研究過 A2A 協議，你可能會有個疑惑：「這些 AI Agent，到底要怎麼在我的 Kubernetes 叢集裡跑起來？」

傳統的做法是自己串 LLM API + Tools + 工作流程引擎，但那跟「自己用 bash 模擬 K8s Operator」的痛苦程度差不多。今天介紹的主角 kagent，就是在回答這個問題 —— 它是一個以 Kubernetes 為基礎、CNCF Sandbox 級別的 AI Agent 框架，讓你用「原生 K8s 的方式」定義、部署、管理你的 AI Agent。

kagent 在官網上的 Vision：

Bringing Agentic AI to cloud native.

為什麼 kagent 與眾不同？

真正的 Cloud-Native

kagent 不只是「跑在 K8s 上的 AI」，它是用 K8s 的語言來定義 AI：

  • Agent-based（取代 Scripts）：每個 AI Agent 都是一個 K8s Custom Resource（CR），不是一個 Cron Job Shell Script
  • Define with K8s CR：用你已經熟悉的 kubectl apply -f 部署 Agent
  • CNCF Sandbox Project：已有雲原生社群背書，不是一個週末 Side Project

標準化通信

kagent 對協議的支援是認真的：

  • 整合 A2A（Agent-to-Agent）：Agent 之間的協作與任務委派
  • 整合 MCP 工具：透過 Model Context Protocol 接入任意外部工具與資料來源

生態與觀測性

  • 支援主流與在地 LLMs（Multi-LLM）：不鎖定單一模型廠商
  • 開箱即用的可觀測性（Built-in Observability）：原生整合 OpenTelemetry，不是事後外掛

kagent 三大核心支柱：Tools、Agents、Framework

Tools

Tools 是 kagent Agent 的「雙手」 —— 負責做那些你不想又不得不做的指令苦力：

特性說明
MCP 標準函數所有 Tool 都以 MCP 協議對外暴露
預載功能內建查看 Pod logs、Metrics 指標查詢等常用 K8s 操作
可擴充性支援從 Tool Registry 接入更多自訂功能

Agents

Agents 是 kagent 的「大腦」 —— 不是那種你問它「Pod 掛了怎辦」，它只會回你「建議你查看日誌」的廢話機器人：

  • 自主運行：具備任務規劃、執行與分析能力，可串聯多項操作
  • A2A 團隊協作：由「規劃代理（Planner Agent）」分派任務給多個「執行代理（Executor Agent）」
  • 靈活調度：根據任務需求，彈性配置調用哪些 Tools 與使用什麼 LLM

Framework

Framework 是 kagent 的「骨架」，讓你有多種方式整合：

  • 多元介面：支援 UI 操作或聲明式（Declarative）YAML 配置
  • 開發底層：基於 Google ADK（Agent Development Kit） 框架構建，繼承其成熟的 Agent 編排能力

kagent 生態系：五個元件如何分工

kagent 不是一個單體工具，而是一個由五個相互配合的子專案組成的生態系：

kagent 生態系架構圖

Kagent Github：https://github.com/orgs/kagent-dev/repositories

實戰：打造你的專屬 AI Agent

kagent 打造 Agent 的思路，是把複雜的 Agent 工程分解成四個明確的構建要素：

1. 定義角色靈魂（System Prompts）

透過 System Prompt 賦予 Agent 特定的人格、專業背景與工作目標。例如：你可以定義一個「只負責查障礙、不做任何修改」的 Read-Only SRE Agent，或一個「精通資料庫調優」的 DBA Agent。

參考文件：System Prompts — kagent 官方文件

2. 賦予能力（Skills）

定義自訂 Skills，讓 Agent 具備調用外部 API、執行程式碼或查詢資料庫的能力。Skills 是比 System Prompt 更具體的「授權清單」，精確控制 Agent 能做什麼。

參考文件：Skills 範例 — kagent 官方文件

3. 整合專業知識庫（Doc2Vec）

把你的 Runbook、技術文件、架構說明整合進 Agent，讓它具備特定領域的知識，避免 LLM 在陌生領域「信心滿滿地瞎猜」。這個能力就是 RAG（Retrieval-Augmented Generation）的工程化實作。

參考文件：Doc2Vec 範例 — kagent 官方文件

4. 安全與人機協作（Human-in-the-Loop）

在涉及寫入、刪除等敏感操作前，加入人類確認機制 —— AI 提案，人類把關。

參考文件：Human-in-the-Loop 範例 — kagent 官方文件

Human-in-the-Loop：讓 AI 成為受控的協作夥伴

這是 kagent 最讓人安心的設計。當我們把 AI 接入真實的生產環境，「Agent 會不會誤刪 Production 的東西？」是所有人的第一個問題。

kagent 提供了兩種人機協作機制：

工具審核（Tool Approval）

在 Agent 的 YAML 定義中，透過 requireApproval 欄位標記哪些 Tools 需要人工審核：

tools:
  - type: McpServer
    mcpServer:
      name: kagent-tool-server
      kind: RemoteMCPServer
      apiGroup: kagent.dev
      toolNames:
        - k8s_get_resources        # read-only，直接執行
        - k8s_describe_resource    # read-only，直接執行
        - k8s_apply_manifest       # 破壞性操作，需要審核
        - k8s_delete_resource      # 破壞性操作，需要審核
      requireApproval:
        - k8s_apply_manifest
        - k8s_delete_resource

當 Agent 嘗試調用被標記的 Tool 時，系統會暫停並在 UI 上顯示該操作的詳細內容，讓人類選擇「核准」或「拒絕」。

詢問使用者（ask_user Tool）

當指令模糊或需要更多資訊時，Agent 不會自己猜，而是透過 ask_user tool 主動向使用者收集必要資訊。

例如，使用者說「幫我砍掉 simple-web-server deployment」，Agent 不會直接執行，而是反問：

  • 「請問 simple-web-server deployment 位於哪個 Namespace？」
  • 「您確認要刪除 simple-web-server deployment 嗎？此操作將導致該服務停止運行，且無法自動復原。」

這個體驗有點像是訓練了一個非常盡責的新人 —— 它絕對不會自作主張亂刪東西，但也不會因為問太多問題而被 fire。

換句話說：它聰明到知道自己不夠聰明。

一個完整案例：「自動修復 Pod 崩潰」的五步協奏

把所有元件串在一起，我們來看一個具體的端對端場景：

情境：Kubernetes 叢集中，一個 Pod 意外崩潰了。

步驟 1：事件偵測（khook）— Kubernetes 觸發 PodRestart 事件，khook 監聽到此事件。

步驟 1：事件偵測

步驟 2：觸發決策（kagent）— khook 根據預設規則，將事件上下文發送給「SRE Agent」。

步驟 2：觸發決策

步驟 3：知識檢索（doc2vec）— Agent 遇到不熟悉的報錯，查詢 doc2vec 預處理好的技術文件（RAG），獲取處理建議。

步驟 3：知識檢索

步驟 4：獲取工具資訊（kmcp）— kagent 透過 kmcp 管理的通道，確認現有哪些可用的 MCP 工具伺服器。

步驟 4：獲取工具資訊

步驟 5：執行行動（tools）— Agent 決定執行「查看日誌」和「修改配置」，呼叫 tools Repo 中定義好的 Kubernetes 接口，最終修復問題。

步驟 5：執行行動

整個過程從偵測到修復，可以完全不需要人工介入，打造一個真正具備自癒能力的 Kubernetes。

可觀測性：從「黑盒」到「玻璃盒」

多 Agent 協作帶來了一個新的可信任危機：你完全不知道 AI 做了什麼決策、為什麼這樣做。

傳統的可觀測性工具（Prometheus、Grafana、Jaeger）擅長回答「系統發生了什麼」，但面對 AI Agent 的決策鏈，它們沉默了 —— 你看得到 HTTP 500，卻看不到是哪個 Agent 做了什麼判斷導致這個結果。

kagent 對這個問題的回答是：可觀測性必須是原生（Native），而不是事後外掛（Addon）。

OpenTelemetry 原生整合

kagent 與 A2A 協議都原生支援 OpenTelemetry，這意味著 Agent 的每一個決策、每一次工具調用，都會自動產生標準化的 Trace：

  • Trace ID 跨 Agent 串聯：一個任務從 khook 觸發、到 kagent 決策、到 tools 執行，整條鏈路共用同一個 Trace ID，讓你在 Jaeger 或 Grafana Tempo 中一眼看穿跨 Agent 的完整調用路徑
  • 標準 OTLP 格式導出：無需安裝專屬 plugin，直接接入現有的雲原生監控基礎設施
  • A2A 通訊審計：Agent 之間的每次任務委派都留有審計紀錄，AI 的決策過程從「不可被審計的黑盒」變成「可回溯、有邏輯脈絡的玻璃盒」

適合誰使用 kagent？

  • 已有 Kubernetes 環境，想導入 AI 自動化
  • 正在評估 AIOps 工具，想要與現有 K8s 工作流整合
  • 想要 Multi-Agent 架構但不想自己造輪子
  • 請不起 SRE，但請得起 kagent

小結

kagent 做的事情，說穿了就是：把「AI Agent 的工程複雜度」轉換成你已經熟悉的 Kubernetes 操作。你不需要學一個全新的 DSL，不需要另外維護一個獨立的 Agent 平台 —— 用 kubectl apply，你就能部署一個具備 RAG 知識庫、Human-in-the-Loop 審核、A2A 多代理協作的生產級 AI Agent。

這讓我想到一段幾乎一模一樣的歷史。

2013 年 Docker 出現之前，「部署應用程式」是一場沒有終點的環境地獄：開發機跑得起來、測試機掛了、Production 爆了、然後沒人知道為什麼。每個團隊都有自己的土法煉鋼 —— 自己寫腳本、自己管依賴、自己維護一套「反正別人動了會壞」的神秘部署流程。

Docker 做的不是讓應用程式「跑得更快」，而是定義了一個標準的打包和執行介面。當這個介面成為共識，Kubernetes 接著出現，把「如何調度這些標準單元」也標準化了。此後整個雲原生生態爆發：Helm、Argo、Istio、Prometheus……每一個工具都能假設底層是標準的 Kubernetes，專心在自己的問題領域發力。

kagent 正在對 AI Agent 做同樣的事。

在 kagent 之前，把 AI Agent 接進 Kubernetes 是另一場地獄：自己串 LLM SDK、自己管 Tool 呼叫、自己處理狀態、自己搞 A2A —— 每個團隊又是一套土法煉鋼。kagent 把這一切定義成標準的 Kubernetes Custom Resource，讓你用 kubectl apply -f 部署 Agent，就像當年用 docker run 啟動容器一樣自然。

當這個介面成熟，接下來的生態系爆發可以想像：專為特定領域打造的 Agent Registry、開箱即用的 SRE Agent Helm Chart、跨組織共享的 A2A Agent Mesh……

我們現在站的位置，大概就是 2015 年 Kubernetes 剛釋出、所有人都在說「這東西好像很厲害但也太複雜了吧」的那個時間點。

你知道後來發生了什麼。

如果你對雲原生 AI Agents 有興趣，kagent 絕對值得花半天時間跑跑它的 Getting Started。

延伸閱讀

kagent 相關

相關工具比較

想更深入了解 kagent 背後的協議？

← 返回 Blog