Koog：JetBrains 出品的 Kotlin 原生 AI Agent 框架，跨平台與容錯是重點

Koog 要解決的問題：JVM 世界缺少的 Agent 基礎設施

多數 AI Agent 框架以 Python 為中心，Java 與 Kotlin 開發者往往要繞道或自行拼接 HTTP 呼叫、工具定義與對話管理。Koog 直接填補這個空位。它是一個以 Kotlin 撰寫的框架，目標是讓開發者用慣用的 Kotlin DSL 或 Java API 建立具備工具呼叫、多步驟工作流與使用者互動的 Agent。從 README 的描述來看，它鎖定的不是研究原型，而是「可預測、容錯、企業就緒」的生產環境。換句話說，Koog 想當 JVM 生態的 LangChain 或 Semantic Kernel，但更強調 Kotlin Multiplatform 的跨平台能力。如果你是 Android 工程師或後端使用 Spring Boot 的團隊，Koog 提供了一條不必離開 JVM 的路。

核心機制：從 PromptExecutor 到圖形工作流

Koog 的運作核心是 AIAgent 類別，搭配一個 promptExecutor。快速範例中，AIAgent 接受 MultiLLMPromptExecutor 與一個 OpenAILLMClient 實例，然後呼叫 agent.run() 傳入使用者訊息。這個設計把「執行 prompt 的元件」與「Agent 本身的邏輯」分開。MultiLLMPromptExecutor 暗示它可以在同一個 Agent 內切換不同 LLM，而不會丟失對話歷史。這是 README 強調的功能之一。除此之外，Koog 提供「圖形工作流」來設計複雜行為，這表示 Agent 的流程不是單純的迴圈，而是可以定義節點與轉移的圖。搭配「模組化功能系統」，開發者可以組合不同能力，而不是被迫使用一體適用的架構。這種組合方式讓 Koog 有彈性，但也意味著學習曲線比單一函式庫高。

取得與執行：Gradle 與 Maven 的實際設定

要開始使用 Koog，最直接的方式是透過 Maven Central 加入依賴。以 Gradle Kotlin DSL 為例，你需要在 build.gradle.kts 中加入 implementation("ai.koog:koog-agents:1.2.0")，以及 implementation("ai.koog:koog-agents-additions:1.2.0-beta")。後者的版本帶有 beta 標記，這是一個需要注意的訊號。Maven 使用者則改用 koog-agents-jvm 與 koog-agents-additions-jvm 兩個 artifact。環境需求是 JDK 17 以上，Kotlin 專案則需要明確設定 Kotlin 2.3.10 以上版本。README 也列出相依的 kotlinx-coroutines 1.10.2、kotlinx-serialization 1.10.0 與 kotlinx-datetime 0.7.1。快速範例中，你需要先設定 OPENAI_API_KEY 環境變數，然後建立 OpenAILLMClient。整體流程與一般 Kotlin 函式庫無異，沒有特殊的建置步驟。

容錯與恢復：Agent 狀態持久化的真實價值

Koog 的 README 強調內建重試機制與 Agent 持久化，後者可以在特定執行點恢復 Agent 狀態。這對長時間運行的任務很重要。假設一個 Agent 正在處理多步驟的資料分析，中途 LLM 服務逾時或程式崩潰，有了持久化就能從最後一個檢查點繼續，而不是從頭開始。這在企業環境中是關鍵需求。不過，README 沒有說明持久化的儲存後端是什麼，是檔案系統、資料庫還是可插拔介面。這是一個需要查閱 API 參考文件才能確認的細節。另外，「智慧型歷史壓縮」功能試圖在長對話中節省 token，但壓縮策略的具體演算法與可調參數也未在 README 中揭露。這些功能的實際效果，必須在真實專案中驗證，不能只看功能清單。

生態整合：Spring Boot、Ktor 與 MCP 的意義

Koog 定位為企業就緒，因此它內建與 Spring Boot 和 Ktor 的整合。這代表你可以把 Agent 嵌入現有的 Web 服務，而不是獨立運行。同時，它支援 Model Context Protocol (MCP) 工具，讓 Agent 可以呼叫外部 MCP 伺服器提供的工具。這是一個重要的標準化方向，因為 MCP 正在成為工具整合的共通語言。另外，Koog 也實作 Agent Client Protocol (ACP)，讓 Agent 能與標準化的客戶端應用溝通。這些協定支援表示 Koog 不是封閉系統，而是試圖融入更大的 AI 工具生態。對於已經採用 MCP 的組織，Koog 可以降低整合成本。但要注意，這些整合的成熟度在 1.2.0 版本中是否已達生產等級，README 並未給出保證。

可觀測性與 LLM 切換：維運面的考量

Koog 內建 OpenTelemetry exporter，並支援 W&B Weave 與 Langfuse 這兩個觀測平台。這對生產環境的除錯與監控是加分項。你可以追蹤 Agent 的執行過程、token 使用與延遲，而不必自行埋點。另一個特色是「LLM 切換」，你可以在對話中途更換模型供應商，例如從 OpenAI 換到 Anthropic，而不會失去既有歷史。這在成本控制或供應商備援上很有用。但切換的實際機制，例如歷史格式如何轉換，README 只說「無縫適應」，細節需要看文件。對於依賴單一 LLM 的簡單應用，這個功能可能用不上，但對於多供應商策略的企業，它提供了一個具體的切入點。

限制與替代方案：Koog 不適合誰

Koog 最大的限制在於它綁定 Kotlin/JVM 生態。如果你的團隊主要使用 Python，Koog 幾乎沒有吸引力，因為 Python 的 AI 生態系（如 LangChain、LlamaIndex）更成熟。即使是 JVM 使用者，如果只是要寫一個簡單的 LLM 呼叫，Koog 的抽象可能過度設計。另外，koog-agents-additions 仍標為 beta，表示部分功能尚未穩定。Koog 的替代方案有 LangChain4j，它同樣針對 Java 生態，但更輕量，且不強調 Kotlin Multiplatform。如果你需要跨平台（Android/iOS），Koog 的 Kotlin Multiplatform 支援是獨特賣點，LangChain4j 沒有對應能力。但若你的目標只在 JVM 後端，LangChain4j 可能更簡單。此外，Spring AI 也是另一個 Java 原生選項，與 Spring Boot 整合更深。選擇的關鍵在於你的部署目標與團隊語言。

授權與維護成本：Apache 2.0 與 JetBrains 背書

Koog 採用 Apache 2.0 授權，這對商業使用友善，沒有 copyleft 限制。它目前標記為 JetBrains 的 incubator 專案，這意味著它還在孵化階段，API 可能變動。版本 1.2.0 是 stable 版本，但 koog-agents-additions 仍是 beta，這顯示核心與附加模組的成熟度不同。維護成本方面，Koog 依賴 Kotlin 2.3.10 以上版本，以及多個 kotlinx 函式庫。升級 Kotlin 版本時，Koog 的相容性需要驗證。JetBrains 的 YouTrack 作為 issue tracker，表示有正式的 bug 回報管道。但作為 incubator 專案，你必須接受可能的 breaking changes，尤其是在 1.x 階段。如果你需要長期穩定，可能要等它脫離 incubator，或者自行鎖定版本並準備遷移成本。

編輯結論

Koog 適合已經使用 Kotlin 或 Java 的團隊，特別是需要把 Agent 部署到 Android、iOS 或瀏覽器的專案，因為它提供統一的 Kotlin Multiplatform API。不適合只想快速呼叫 LLM API 的簡單腳本，也不適合依賴 Python 生態系的團隊。採用前應先確認你需要的平台目標是否完整支援，例如 WasmJS 的成熟度，以及 koog-agents-additions 仍標為 beta 的模組是否影響你的功能。若你的應用需要長時間執行的 Agent 狀態恢復或多 LLM 無痛切換，Koog 的設計值得測試。

官方來源

1. JetBrains/koog on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases