kagent — Kubernetes 原生 AI 代理框架
在 Kubernetes 中构建、部署和管理 AI 代理，利用 MCP 工具集成云原生生态。
证据显示：RBAC 配置支持命名空间范围（ci.yaml 中 rbac.namespaces），表明有最小权限意识；但未提供用户确认机制，数据流透明度有限（仅提及 OpenTelemetry 追踪），敏感数据处理未明确，依赖安全有 SECURITY.md 和 CI 测试，外部影响有 e2e 测试，回滚有升级测试，来源归属有贡献者列表。扣分：用户确认缺失，数据流细节不足，敏感数据未详述。
证据显示：CI 包含单元测试、e2e 测试、升级测试，自一致性较好；依赖可用性有 go.sum 和 package-lock.json，但未提供依赖可用性保证；失败消息有 CI 日志输出，但未提供用户可见的错误消息。扣分：依赖可用性未明确，失败消息不充分。
证据显示：README 明确目标用户为 Kubernetes 开发者，场景包括多种 LLM 提供商和 MCP 工具；能力边界有架构描述，但未明确限制；触发精度有 CRD 定义，但未详述；环境适配有 Helm 和 Docker 支持。扣分：能力边界和触发精度不够详细。
证据显示：信息架构清晰（README 有目录），安装说明有链接，命名稳定（CRD 命名），示例和 FAQ 有链接，已知限制未明确，许可证为 Apache-2.0，版本控制有 CI 和升级测试，维护责任有贡献指南。扣分：已知限制未列出，版本变更日志未提供。
证据显示：输出可用性有 UI 和 CLI，边际价值高（Kubernetes 原生），成本效益有 CI 测试但未提供性能数据。扣分：成本效益缺乏数据。
证据显示：声明有文档链接，但未提供独立验证；跨来源佐证有 CI 和测试，但未提供外部验证；事实与推断分离未明确。扣分：可验证性不足。
- 用户确认机制缺失，可能影响安全审批流程。
- 敏感数据处理细节不足，需审查密钥管理。
- 已知限制未列出，可能隐藏潜在问题。
这个 Agent 能做什么，适合哪些场景？
kagent 是一个 Cloud Native Computing Foundation（CNCF）项目，提供 Kubernetes 原生框架，用于构建和运行 AI 代理。它将代理和工具以 Kubernetes 自定义资源（如 Agent 和 ToolServer）表示，支持 OpenAI、Anthropic、Google Vertex AI 等多种 LLM 提供商。架构包括四个核心组件：Controller、UI、Engine 和 CLI。Engine 基于 Google 的 ADK（Agent Development Kit）执行代理，UI 提供可视化管理界面，CLI 支持命令行操作。kagent 强调声明式、可扩展、可观测和可测试性，支持 OpenTelemetry 追踪。
kagent 作为一个 Kubernetes 控制器运行，监听自定义资源（如 Agent、ModelConfig、ToolServer），并根据这些资源创建必要的 Kubernetes 资源（如 Pod）来运行代理。每个 Agent 定义系统提示词、工具集和 LLM 配置，通过 ModelConfig 连接不同的 LLM 提供商。代理可通过 MCP 服务器调用工具，内置工具涵盖 Kubernetes、Istio、Helm、Argo、Prometheus、Grafana、Cilium 等。UI 提供 Web 界面来管理代理和工具，CLI 允许使用类似 kubectl 的命令。所有操作通过 Kubernetes API 进行，支持 OpenTelemetry 追踪以监控代理行为。
- 平台工程师希望在 Kubernetes 集群中声明式地部署和管理 AI 代理，使用 kubectl 工作流。
- 运维团队需要利用代理自动执行 Kubernetes 集群操作，如故障排查、资源优化，通过 MCP 工具集成 Prometheus 和 Grafana 数据。
- 开发者想要构建自定义 AI 代理，利用已有的云原生工具（如 Istio、Helm）作为工具集，并通过 YAML 定义代理。
- 团队需要可观测的 AI 代理，希望集成 OpenTelemetry 追踪来监控代理执行过程。
- 组织希望采用 CNCF 项目，获得社区支持，并参与贡献。
这个 Agent 有哪些优点和局限？
- Kubernetes 原生，利用 CRD 和 kubectl，易于集成到现有集群工作流。
- 支持多种 LLM 提供商（OpenAI、Anthropic、Vertex AI 等），通过 ModelConfig 灵活切换。
- 内置 MCP 服务器，提供针对 Kubernetes、Istio、Helm 等云原生工具的开箱即用工具。
- 声明式定义代理和工具，便于版本控制和 GitOps。
- 支持 OpenTelemetry 追踪，提供可观测性。
- 需要 Kubernetes 集群作为运行时，增加了基础设施要求。
- 相对较新，处于活跃开发阶段，可能不稳定。
- 依赖 Google ADK 作为执行引擎，引入特定依赖。
- 文档主要在外部网站，本地 README 信息有限。
- 自定义工具开发需要了解 Kubernetes 自定义资源。
如何安装或部署这个 Agent？
安装指南位于 https://kagent.dev/docs/kagent/introduction/installation。通常需要 Kubernetes 集群和 kubectl。可以使用 Helm 或直接应用 YAML 清单。具体步骤未在 README 中详细说明，建议参考官方文档。
如何使用这个 Agent？
安装后，使用 kubectl 应用自定义资源定义（CRD）来创建 Agent 和 ToolServer。例如，定义一个 Agent 的 YAML 文件，指定 system prompt、LLM 配置（通过 ModelConfig 引用）和工具集。然后使用 CLI 或 UI 进行管理。快速入门指南见 https://kagent.dev/docs/kagent/getting-started/quickstart。
这个 Agent 与同类方案有什么区别？
README 未明确比较其他 AI 代理框架，但提到了 'AI agents' 领域，可能与其他代理框架如 Dapr Agents 或 LangChain 存在竞争，但未具体提及。