从零到智能体生成器：在笔记本电脑上运行 kagent
内容提要
本文介绍用开源项目 kagent 在 Kubernetes 上构建“智能体生成器”：智能体是 YAML 自定义资源，由控制器转为运行 Pod。作者使用本地模型 qwen3-coder:30b，通过工具白名单、人工审批和 RBAC 三重防护，让智能体根据自然语言描述生成并部署新智能体。文末指出身份、成本与治理才是真正难点，需在智能体前加治理层。
延伸解读
本地模型选型：为什么小模型容易失败
文章指出，通过工具调用生成合法的 Kubernetes 清单比普通对话更难。作者实测 qwen2.5:7b-instruct 会自创工具块格式，qwen2.5:14b-instruct 有时不调用 apply 工具，而 qwen3-coder:30b-a3b 每次都能正确完成。这提醒读者：若想复现该实验，模型能力是首要门槛，不能随意替换为更小的模型，否则可能无法稳定生成可用的 Agent 资源。
三重防护：提示词之外的硬约束
文章强调提示词只是请求，不是保证。真正的保障来自三层：工具白名单只暴露三个工具，模型无法调用删除等危险操作；人工审批在应用清单前暂停，让人看到即将创建的内容；RBAC 限制工具服务器的 ServiceAccount 只能写 agents.kagent.dev。作者还举例，即使模型写错工具服务器名称，控制器也会拒绝，说明这些硬约束比提示词更可靠。
实验的边界：安全与治理的缺失
作者明确说明该实验默认使用不安全的认证模式，所有请求视为同一用户，且仅通过本地端口转发访问。这适合笔记本电脑，但不适合共享集群。文末指出，身份、成本和治理才是真正难点：没人知道谁请求了智能体、模型调用花了多少钱、是否该批准其存在。因此建议在智能体前加一层治理层，例如 agentgateway，而不是把治理塞进每个智能体内部。
Q&A
kagent 是什么？它如何把智能体变成 Kubernetes 资源？
kagent 是一个 CNCF Sandbox 项目，它把 AI 智能体作为 Kubernetes 自定义资源来运行。你编写一个 Agent 资源，包含系统提示、模型和工具列表，应用后控制器会将其转换为一个运行中的 Pod，并通过 A2A 协议通信。
在笔记本电脑上运行 kagent 智能体生成器需要哪些前置条件？
需要 Docker、kind、kubectl、helm、jq 和 Ollama（或使用 Claude、OpenAI 等提供商的 API Key）。无需克隆仓库，所有文件都从头创建。
为什么作者推荐使用 qwen3-coder:30b 模型而不是更小的模型？
因为通过工具调用编写有效的 Kubernetes 清单比聊天更难。小模型如 qwen2.5:7b-instruct 会发明自己的工具块格式，qwen2.5:14b-instruct 有时会礼貌回答而不调用 apply 工具。而 qwen3-coder:30b-a3b 在每次运行中都能正确完成。
kagent 智能体生成器如何确保安全？有哪些防护措施？
有三重防护：1) 工具白名单：模型只能看到三个工具（k8s_apply_manifest、k8s_get_resources、k8s_get_resource_yaml），其他工具不可见；2) 人工审批：调用 k8s_apply_manifest 时运行暂停，需用户批准；3) RBAC：工具服务器的 ServiceAccount 只有只读权限加上对 agents.kagent.dev 的写权限，无法创建其他资源。
如何通过命令行（不使用 UI）与 kagent 智能体生成器交互？
每个 kagent 智能体都是控制器上的 A2A 端点。你可以转发控制器端口（如 8083），然后发送 JSON-RPC 请求。例如，用 curl 发送 message/send 方法，包含用户消息。如果返回状态为 input-required，表示等待审批，需发送包含 decision_type: approve 或 reject 的后续消息。
文章指出构建智能体生成器后，真正的难点是什么？
真正的难点是身份、成本与治理。在本地实验中，所有请求都是同一用户，无法知道谁请求了智能体、模型调用成本归属哪个团队，以及智能体是否应该存在。因此需要在智能体前加一个治理层，例如 agentgateway，来处理认证、授权和可观测性。
