Koog：JVM 团队终于有了更顺手的 AI Agent 框架

AI Agent 工具这两年非常多，但大多数示例默认你在 Python 或 TypeScript 里工作。问题是，大量企业服务并不在这两条栈上：核心后台是 Java/Kotlin，移动端是 Android，内部平台跑在 Spring Boot 或 Ktor，CI/CD、监控、权限、日志都已经围绕 JVM 建好。

JetBrains 的 Koog 正好切到这个空位。它是一个 Kotlin-based AI Agent Framework，面向 JVM、JS、WasmJS、Android、iOS，提供工具调用、复杂工作流、MCP、记忆、向量检索、模型切换、OpenTelemetry 和 Spring/Ktor 集成。它最适合的不是快速玩 Demo，而是把 Agent 作为 JVM 应用的一部分长期维护。

为什么 JVM 团队需要自己的 Agent 框架

如果团队已经有一套成熟后端，把 Agent 单独做成 Python 微服务当然可行，但会引入新的部署、权限、日志、依赖、异常处理和人员技能成本。Agent 真要进入生产流程，必须接已有的认证、审计、配置和服务治理。

Koog 的价值是降低这层缝合成本。Kotlin DSL 让工具、流程和业务对象留在同一个语言环境里；Spring Boot/Ktor 集成让 Agent 可以复用已有服务边界；OpenTelemetry 支持让它更容易进入现有观测体系。

最小落地路径

不要一上来做“全能员工”。建议按三步走：第一，把 Koog 接入一个内部只读查询场景；第二，把查询结果和模型回答打日志；第三，再用图工作流拆出人工确认和异常分支。

dependencies {
    implementation("ai.koog:koog-agents:0.5.0")
}

一个最小 Agent 可以先只回答内部文档问题，或者只解释某个业务对象状态。工具越少，越容易验证框架是否适合团队。

工具设计比 prompt 更重要

企业场景下，Agent 可靠性主要来自工具边界，而不是系统提示词。每个工具都应该有明确输入输出、权限要求、超时、错误码和审计信息。比如“查询订单状态”比“访问数据库”安全得多；“生成退款建议”比“执行退款”更适合作为第一阶段能力。

Koog 支持自定义工具和 MCP 工具。MCP 适合把外部能力标准化接入，Kotlin 原生工具适合贴近业务域模型。两者最好分层使用：业务关键工具放在本服务内，通用工具走 MCP。

图工作流适合复杂业务

很多 Agent 失败，是因为流程被塞进了一段长 prompt。Koog 的 graph workflows 可以把行为拆成可观察节点：分类、检索、调用工具、生成草稿、人工确认、最终输出。对于客服、审批、研发助手、数据分析助理，这比单个 chat loop 更像工程系统。

结论

Koog 值得 JVM 团队关注。它不是要替代 LangChain、Mastra 或 OpenAI Agents SDK，而是给 Kotlin/Java 生态一个更贴近自身工程实践的 Agent 入口。真正用好它，关键不是先接最多模型，而是先把只读工具、图工作流、观测和权限边界做扎实。