在一篇CNCF博客文章中，Lin Sun介绍了kagent项目的工作，认为 Pod 可能仍然是智能体的执行单元，但不再适合作为部署、身份标识或生命周期的单元。
随着智能体数量的增长，会出现熟悉的问题，那就是，如何在智能体之间实现隔离、每个智能体如何获得身份标识、如何执行访问与网络策略、如何观察单个智能体在做什么，以及在多租户场景下确定谁拥有智能体。这些更多是智能体平台层面的问题，而不是纯 Kubernetes 的问题，尽管答案需要在 Kubernetes 上进行表达。
一种直接的方法是将每个智能体作为一级 Kubernetes 工作负载，配备自己的 Pod、Service 和 ServiceAccount。最初，kagent 将许多智能体运行在单个运行时中，便采用了这种方式。它提供了进程与容器隔离，可以接入现有认证授权的 ServiceAccount 身份，可以应用 Kubernetes 网络与准入策略机制，支持按智能体归属日志/指标/追踪以及原生的 Kubernetes 调度与资源管理。kagent 随后又通过Kubernetes Agent Sandbox项目实现了更强的隔离支持。
它的问题在于，智能体的行为与微服务是不同的，而上述这些抽象都是针对微服务而设计的。与需要持续可用的服务不同，智能体可能只有在分配任务时才会被唤醒，运行几秒或几分钟后进入空闲，因此为每个潜在智能体保留专用 Pod 会很浪费。智能体还可能产生子智能体以并行执行子任务、代表用户执行操作，或者在等待人工批准时无限期暂停。Pod 是优秀的执行环境，但并不一定是处理这种短时突发工作负载的正确生命周期抽象。
另一种方法是停止将每个智能体视为 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
