一句话看懂：围绕 AI 智能体在 Kubernetes 上的部署方式，业界开始从“一个智能体一个 Pod”转向“Pod 只作为执行 Worker、上层平台管理智能体生命周期”的新思路，kagent 等项目正在验证这一模式。
事件核心：发生了什么
CNCF 博客作者 Lin Sun 撰文介绍了 kagent 项目的工作，核心观点是：Pod 仍然是 AI 智能体的优秀执行环境，但不再适合作为部署、身份标识或生命周期的单元。随着智能体数量增长，隔离、身份标识、访问控制、可观测性以及多租户归属等问题会集中浮现，这些属于智能体平台层面的问题，需要在 Kubernetes 上表达答案。
kagent 最初采用“每个智能体作为一级 Kubernetes 工作负载”的方式，为每个智能体配备独立的 Pod、Service 和 ServiceAccount，并支持进程与容器隔离、继承 Kubernetes 身份认证与网络策略。但问题在于，智能体的行为与常驻微服务不同：智能体可能只在被分配任务时唤醒，运行几秒或几分钟后进入空闲；也可能产生子智能体并行执行子任务，或在等待人工批准时无限期暂停。为每个潜在智能体保留专用 Pod 会造成资源浪费。
为此，kagent 转向了 Google 在 Agent Sandbox 和 Agent Substrate 公告中提出的方案：在 Kubernetes 之上引入一个控制平面。Agent Sandbox 提供隔离执行环境，Agent Substrate 则管理逻辑智能体（Actor）如何被放置到 Worker 中，并支持在 Worker 之间迁移。Kubernetes 继续管理 Pod、Service、网络、存储与计算，而上层管理 AI Actor 的生命周期与放置。该抽象与平台工程师熟悉的概念对应：WorkerPool 类似 NodePool，Workers 对应 Nodes，ActorTemplate 对应 Pod 的声明式规范。每个 Worker 映射到一个 Pod，Actor 则是在有工作到来时被调度到 Worker 上的逻辑单元，可按需挂起、恢复或移除。这样，一个固定池内长期运行的 Pod 可以支撑远多于传统方式的逻辑智能体。
为什么重要
这一讨论触及 AI 基础设施层的核心假设：Kubernetes 上成熟的抽象都是为微服务设计的，而 AI 智能体的运行模式与微服务有本质差异。智能体是突发型、短时、可挂起的工作负载，而非持续在线的服务。将 Pod 降级为“执行 Worker”而非“部署单元”，意味着平台层需要新增一层抽象来管理智能体的身份、生命周期、资源归属和可观测性。
Lin Sun 指出，如果 Actor 可以在任意 Worker 上运行，其身份标识更可能归属于 ActorTemplate、命名空间、租户和版本，而非 Pod 或 Service。访问控制、网络策略与运行时权限也需要在模板级别表达，并支持按 Actor 覆盖。一旦执行与 Pod 不再一一对应，归属权、配额与计费会更难跟踪，可观测性必须跟随逻辑智能体，将日志、追踪与审计记录与 Actor 的调度位置关联。这些问题直接影响多租户场景下的成本核算与安全审计，是 AI 智能体规模化落地必须解决的一环。
这一探索并未否定 Kubernetes 在规模化微服务与推理工作负载方面的行业地位，而是提出了一个更细分的问题：在 Pod 被证明是优秀执行环境之后，它是否还应该继续作为 AI 智能体的部署、身份识别与生命周期单元。Kubernetes Podcast from Google 也在其每周新闻摘要中报道了这篇文章，说明这一讨论已进入主流关注范围。
对用户/开发者/创作者的影响
对于正在 Kubernetes 上部署 AI 智能体的平台团队和开发者，这一思路提供了一条更节省资源的路径：不需要为每个潜在智能体预留独立 Pod，而是通过 WorkerPool 与 ActorTemplate 的方式，让多个逻辑智能体共享一个固定资源池。这意味着在同样的集群规模下，可以支撑更多智能体实例，降低基础设施成本。
对于使用开源工具或云服务的团队，kagent 对 Agent Substrate 的集成提供了一种可参考的实现方式。如果这套抽象成为社区共识，未来平台工程师在规划智能体平台时，可能需要把身份、策略、可观测性的设计单位从 Pod 上移到 Actor 层，这也意味着现有的监控、日志和计费系统需要适配新的追踪粒度。
值得关注的后续
第一，kagent 的 Agent Substrate 集成是否会在真实的多租户生产环境中得到验证，尤其是资源复用率与隔离强度之间的平衡。第二，Kubernetes 社区是否会推出与 ActorTemplate 对应的原生或标准化抽象，或者由 CNCF 项目（如 kagent）形成事实标准。第三，云厂商是否会跟进类似的能力，将“Worker 池 + Actor 调度”作为托管服务提供，这将直接影响企业采购 Kubernetes 平台时的选型判断。目前公开信息显示，这一方案尚处于探索阶段，实际落地效果与性能数据有待进一步披露。
来源：InfoQ CN
