把 AI Agent 做进 Kubernetes 的 CRUD：kagent 3.5k Star 背后的设计思路和真实边界

器匠·开发者工具内容创作者 2026-08-21 2717 阅读

Cloud Native Agentic AI 观察报告：把 AI Agent 做进 Kubernetes 的 CRUD，这事到底成不成

2025年3月，Solo.io 在 KubeCon Europe 上开源了一个项目，思路很直接：能不能把管理 Pod/Service/ConfigMap 的那套思路，平移到 AI Agent 上去？16个月后，这个叫 kagent 的项目进了 CNCF Sandbox，拿到了 3,556 颗星、716 个 Fork、100+ 贡献者。最新版本是 v0.10.0-rc3，发布于 2026 年 8 月 18 日——还在活跃迭代。

这到底是一个什么项目，适合谁，不适合谁？我们把官方文档、GitHub 代码、Releases、竞品对比全部过了一遍，给出一个尽量客观的判断。

kagent 是什么：不是另一个 AI 编程框架，而是 Agent 的运行时

看到 kagent 这个名字，容易误以为它是 LangChain/CrewAI 那种应用层框架——给你一堆 Prompt 模板和工具调用链，让你写 Python 代码构建 Agent 逻辑。这不是 kagent 在做的事。

kagent 的核心思路是：把 Agent 做成 Kubernetes 的第一类资源（CRD），用 kubectl apply 部署，用 Controller 管理生命周期，用 YAML 声明式配置。你写的不再是一段 Python 脚本，而是一份 Agent 清单文件。

这个类比是理解 kagent 最快的路径：

Pod ↔ Agent：Pod 是跑容器的最小调度单元；Agent CRD 是跑一个 LLM 推理循环的最小调度单元
Service ↔ ToolServer：Service 把后端 Pod 暴露成网络入口；ToolServer 把 MCP 协议下的工具集（K8s API、Prometheus、Helm）暴露成 Agent 可调用的入口
ConfigMap ↔ Session：ConfigMap 注入运行时配置；Session 持久化对话状态
Operator ↔ Controller：Operator 监听 CRD 做状态调和；kagent Controller 监听 Agent/ToolServer/Session 做生命周期管理

这意味着如果你已经熟悉 kubectl、RBAC、Helm、Prometheus 这套 K8s 生态，kagent 的上手曲线几乎为零。你不需要学一套新的 Agent 编程框架，只需要会用 kubectl。

技术架构：两层分离，Python/Go 双引擎

kagent 的架构分控制面和数据面两层。

控制面是纯 Go 写的 Controller，监听四种 CRD（Agent、ToolServer、Session、ModelConfig），负责创建/更新/删除 Agent 对应的 K8s Deployment 和 Service。这是 Solo.io 的老本行——他们也是 Istio 的创始团队，做 Kubernetes Controller 是他们的核心能力。

数据面是 Agent 推理循环的运行时分两种引擎：

Python ADK（默认）：基于 Google ADK，启动约 15 秒，资源占用偏高，但生态完整，适合写 Prompt 和工具链比较重的场景
Go ADK（高性能）：启动约 2 秒，内存占用低，适合”小 Agent 大量并发”场景

两个引擎之间通过 A2A 协议（Agent-to-Agent，Google 2025 年发布的开放协议）通信，多 Agent 编排不是用胶水代码搭出来的，而是协议层保证的。

状态持久化默认用 PostgreSQL，监控用 OpenTelemetry + Prometheus，与 K8s 生态完全对齐。最新版本（v0.10.x）正在引入 Substrate 支持，可以做到 Agent 亚秒级挂起/恢复，据官方博客说 8 个 Pod 可以跑 250 个 Agent。

谁在用：落地场景的实测数据

根据官方博客和社区分享，目前已经有人在生产环境跑 kagent，场景集中在：

Kubernetes 集群自动化运维：Pod CrashLoopBackOff 故障排查，从人工 30 分钟缩短到 2 分钟
Argo MCP Server 集成：用 kagent 管理 Argo Workflow 的触发和状态查询
GCP Terraform Agent：在 K8s 上跑 Terraform 操作，多环境并发
Canary Deployment 自动化：用自然语言触发金丝雀发布，Agent 自动执行 10%→25%→50%→100% 的渐进式流量切换
Discord 实时问答：A2A 协议串联多个 Agent，一个负责查文档，一个负责格式化，一个负责发送

还有一个值得注意的动向：v0.9.1（2026年5月）增加了 Bedrock Claude 支持（AWS）和 sidecar 容器模式，说明团队在往多云方向走，不只是 GCP。

kagent vs. 其他框架：不是在同一个赛道上比较

主流 Agent 框架的选择逻辑是这样的：

LangChain / LangGraph：单 Agent 逻辑构建能力强，但把部署和运维完全甩给开发者。适合在 kagent 之上用 LangChain 写 Agent 逻辑，再用 kagent 做生产部署——两者是互补关系，不是替代关系
CrewAI：上手简单，适合 2~5 个 Agent 的简单协同场景，但在生产级可靠性、审计、RBAC 方面不如 kagent
AutoGen：微软出品，研究属性更强，2025 年 kagent 从 AutoGen 切换到了 Google ADK，原因未公开说明，但社区猜测与多 Agent 协议（A2A）的成熟度有关
Orloj：另一个走声明式路线的框架，但不需要 K8s，适合不用 K8s 但需要 Agent 级别治理（Token 预算、工具级权限、审计追踪）的团队。kagent 的治理模型依赖 K8s RBAC，粒度相对粗
Temporal：做持久化工作流的，不是纯 Agent 编排，但可靠性设计值得参考。适合需要 Agent 任务失败重试、幂等执行的场景

如果你的团队完全基于 Kubernetes、Agent 主要操作 K8s 资源和云原生服务、RBAC 够用，kagent 是最自然的选型。如果你在受监管行业（金融、医疗），需要 Agent 级别的 Token 预算和工具级权限控制，Orloj 可能更合适。

适合谁 / 不适合谁

适合的场景：

已经跑在 Kubernetes 上的团队，Agent 要操作集群资源（Pod、Service、ConfigMap、Prometheus）
需要用 GitOps 方式管理 Agent 配置（YAML 版本控制、kubectl apply 回滚）
需要多 Agent 协同（至少 2 个以上 Agent 互相调用）
需要和现有 K8s 监控/告警体系打通

不适合的场景：

单体应用、不上 K8s 的团队——引入 kagent 的复杂度远超收益
只是想跑一个对话机器人——用 Dify、Coze 或者直接调 API 更省事
对 LLM API 有严格合规要求的金融/医疗场景——目前 kagent 的审计体系依赖 K8s audit log，粒度不够细
完全离线（Air-gapped）的环境——目前依赖外部 LLM API（虽然可以接 Ollama，但云厂商特性用不了）

项目边界说明：它不做什么

kagent 明确不做的几件事：

不提供 Agent 逻辑的编写框架：Prompt怎么写、工具怎么定义，交给 LangChain/CrewAI/ADK。kagent 是部署和运维层
不提供开箱即用的 SRE Agent：HolmesGPT、k8sgpt 这类现成 SRE Agent 是”应用层”，kagent 是”运行时层”——它们可以跑在 kagent 上面，不是替代关系
不解决 LLM API 可用性问题：如果你的 LLM API 本身不稳定，kagent 不会帮你解决，但它提供了 Agent 级别的断点续算和会话持久化

可执行的下一步建议

想试 kagent？建议按这个路径走：

第一步：本地起一个 kind 集群，跑官方 Quickstart

brew install kagent
export OPENAI_API_KEY="sk-..."
kagent install --profile demo
kagent dashboard

30 分钟可以跑起来一个带 Web UI 的 Demo Agent

第二步：试试 Go ADK 引擎（比 Python 启动快 7 倍）
在 Agent CRD 的 spec 里指定 runtime: go，看自己的场景是否适用

第三步：接入一个 MCP 工具
kagent 支持 MCP Server，接入 Prometheus 或 K8s API 比手写工具链简单得多

第四步：如果你的团队有 Orloj 或 Temporal 在用，评估一下 Agent 治理需求——K8s RBAC 是否够用，是否需要 Agent 级别的 Token 预算和工具权限控制

参考资料

GitHub 仓库：https://github.com/kagent-dev/kagent
官方文档：https://kagent.dev/docs
v0.9.1 Release Notes：https://kagent.dev/blog/kagent-v0-9-1-release
Substrate 架构说明：https://kagent.dev/blog/the-future-of-kagent
Orloj vs Kagent 竞品对比：https://www.orloj.dev/blog/orloj-vs-kagent
2026年 Agent 编排平台横评：https://www.orloj.dev/blog/top-5-agent-orchestration-platforms
稀土掘金中文实战解读：https://juejin.cn/post/7638000682114498570
CSDN 深度实战：https://blog.csdn.net/weixin_42260382/article/details/163450441
CNCF Sandbox 页面：https://www.cncf.io/sandbox/

评论区

0 条评论

登录后可评论。