Pod 作为工人而非代理：重新思考 Kubernetes 上 AI 代理的部署单元

随着 AI Agent 数量增长，一系列问题浮现：如何隔离不同 Agent、如何为每个 Agent 提供独立身份、如何执行访问和网络策略、如何观察单个 Agent 的行为，以及多租户下 Agent 的归属。这些是 Agent 平台问题，而非 Kubernetes 问题，尽管答案需要在 Kubernetes 上表达。

一种直接的方法是将每个 Agent 作为一等的 Kubernetes 工作负载，拥有自己的 Pod、Service 和 ServiceAccount。kagent 最初在单个运行时中运行多个 Agent，后来采用了这种方法，以获得进程和容器隔离、ServiceAccount 身份、网络和准入策略、按 Agent 归因的日志指标追踪，以及 Kubernetes 原生的调度和资源管理。kagent 随后通过 Kubernetes Agent Sandbox 项目增加了更强的隔离支持。

然而，Agent 的行为与这些抽象所设计的微服务不同。Agent 可能仅在接到任务时唤醒，运行几秒或几分钟后闲置，因此为每个潜在 Agent 保留专用 Pod 是浪费的。Agent 还可能生成子 Agent 并行执行子任务，代表用户行动，并在等待人工批准时无限期暂停。Pod 是优秀的执行环境，但不一定是短时突发工作的正确生命周期抽象。

另一种方法是在 Kubernetes 之上引入控制平面。Google 在 Agent Sandbox 和 Agent Substrate 公告中引入的 Agent Substrate 采用了这种方法，kagent 也支持它。Agent Sandbox 提供隔离的执行环境，而 Agent Substrate 管理逻辑 Agent 如何放置到 Worker 上并在 Worker 之间移动。Kubernetes 继续管理 Pod、Service、网络、存储和计算，而上层管理 AI 角色的生命周期和放置。其抽象与平台工程师熟悉的概念对应：WorkerPool 类似 NodePool，Worker 类似 Node，ActorTemplate 类似 Pod 的声明式规范。

在 Agent Substrate 模型中，Kubernetes 只感知 WorkerPool 和 ActorTemplate；Worker 和 Actor 存在于 Agent Substrate 自己的 CLI 和 API 中，每个 Worker 映射到一个 Pod。Actor 是“扮演”AI Agent 的逻辑单元，在工作到达时被调度到 Worker 上，并根据生命周期需求被挂起、恢复或移除。这使得一个固定的长期运行 Pod 池能够支持比每个 Agent 一个持续运行 Pod 多得多的逻辑 Agent。Pod 成为执行 Worker，而不是 Agent 的部署模型。

这种变化的影响超出了调度效率。Sun 认为，如果 Actor 可以在任何 Worker 上运行，身份可能属于 ActorTemplate、命名空间、租户和版本，而不是 Pod 或 Service。访问控制、网络策略和运行时权限可能也需要在模板级别表达，并支持按 Actor 覆盖。一旦执行不再与 Pod 一一对应，所有权、配额和计费将更难推理，可观测性必须跟随逻辑 Agent，将日志、追踪和审计记录与 Actor 关联，无论它被调度到哪里。

这一切都不会取代 Kubernetes，它仍然是大规模微服务和推理工作负载的行业标准平台。开放的问题更窄：Pod 已经证明自己是执行环境，但它是否还应继续作为 AI Agent 的部署、身份和生命周期单元？这正是 Agent Substrate 通过 kagent 探索的问题。Google 的 Kubernetes Podcast 随后在其每周新闻综述中介绍了 Sun 的文章。