在CNCF博客文章中，Lin Sun探讨了kagent项目，提出Pod可能仍然是智能体的执行单元，但不再适合作为部署、身份标识或生命周期的单元。随着智能体数量的增长，需要解决的问题包括隔离、身份标识、访问与网络策略、观察单个智能体的行为以及多租户场景下的智能体归属问题。这些问题更多地涉及到智能体平台而非纯Kubernetes层面。智能体的行为与微服务不同，且它们可能只在分配任务时被唤醒，运行后进入空闲状态。因此，为每个潜在智能体保留专用Pod会显得不经济。另一方面，Pod是优秀的执行环境，但不一定适用于处理短时突发工作负载。一种解决方案是在Kubernetes之上引入控制平面，如Agent Substrate，它通过kagent支持这一点。这种方法允许逻辑智能体被放置在Worker中，并支持Worker之间的迁移。Kubernetes继续管理Pods、Services、网络、存储与计算，而上层则管理AI Actor的生命周期和放置。这种抽象与平台工程师熟悉的概念类似：WorkerPool类似于NodePool，Workers对应Nodes，而ActorTemplate对应Pod的声明式规范。Kubernetes只关心WorkerPools和ActorTemplates，而Workers和Actors存在于Agent Substrate的CLI与API中，每个Worker映射到一个Pod。

--91likeyou---

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项目的工作 · #认为