在CNCF博客文章中，Lin Sun探讨了kagent项目，提出Pod可能仍是智能体的执行单元，但不再适合作为部署、身份标识或生命周期的单元。随着智能体数量的增长，需要解决的问题包括隔离、身份标识、访问控制、网络策略和可观测性等。Agent Substrate通过引入控制平面来解决这些问题，而Kubernetes继续管理Pods、Services、网络、存储与计算。这种转变意味着Kubernetes将不再直接管理AI智能体的生命周期，而是通过上层的控制平面来处理这些细节。
--91likeyou---
另一种方法是停止将每个智能体视为 Kubernetes 工作负载，而是在 Kubernetes 之上引入一个控制平面。Agent Substrate就采用了这种做法。谷歌在其Agent Sandbox和Agent Substrate公告中介绍了它。kagent 也提供对此的支持，详见kagent的Agent Substrate集成指南。
Agent Sandbox 提供了隔离的执行环境，而 Agent Substrate 负责管理逻辑智能体如何被放置到 Worker 中并支持在 Worker 之间进行迁移。Kubernetes 继续管理 Pods、Services、网络、存储与计算，而上层则管理 AI Actor 在执行 worker 上的生命周期与放置。它的抽象与平台工程师熟悉的概念类似：WorkerPool类似于 NodePool，Workers对应 Nodes，而ActorTemplate对应 Pod 的声明式规范。
Kubernetes 只关心 WorkerPools 和 ActorTemplates，而 Workers 和 Actors 存在于 Agent Substrate 自己的 CLI 与 API 中，每个 Worker 映射到一个 Pod。Actor，即“充当”AI 智能体的实体，是在有工作到来时调度到 Worker 上的逻辑单元，并可以根据生命周期需求被挂起、恢复或移除。这样，就允许固定池内长期运行的 Pod 支撑其更多的智能体，远远超过为每个智能体都运行独立持续 Pod 时的逻辑智能体。Pod 成为执行 worker，而非智能体的部署模型。
其影响范围不仅局限于调度效率。Sun 认为，如果 Actor 可以在任意 Worker 上运行，那么它的身份标识更可能属于 ActorTemplate、命名空间、租户和版本，而非归属于 Pod 或 Service。访问控制、网络策略与运行时权限也可能需要在模板级别进行表达，并支持按照 Actor 进行覆盖。一旦执行不再与 Pod 一一对应，归属权、配额与计费会更难以跟踪，而可观测性必须跟随逻辑智能体，将日志、追踪与审计记录与 Actor 的调度位置关联起来。
这并没有否定 Kubernetes 在规模化微服务与推理工作负载方面的行业地位。需要讨论的是一个更细分的问题，那就是，在 Pod 被证明是优秀的执行环境之后，它是否还应该继续作为 AI 智能体的部署、身份识别与生命周期单元。Agent Substrate 通过 kagent 正在探索这个问题。随后，Kubernetes Podcast from Google在其每周新闻摘要中也报道了 Sun 的文章。
查看英文原文：Pods as Workers, Not Agents: Rethinking the Deployment Unit for AI Agents on Kubernetes
🔥 热词：#Kubernetes · #Pod · #将Pod作为worker而非智能体 · #在Kubernetes上重新思考AI智能体的部署单元 · #在一篇CNCF博客文章中 · #Lin · #Sun介绍了kagent项目的工作 · #认为