Lin Sun 在 CNCF 博客上介绍了 kagent 项目。他的核心观点是：Pod 适合当 AI 智能体的执行环境，但不应再充当部署、身份标识或生命周期的管理单元。当智能体数量激增时，我们需要在 Kubernetes 之上加一层 Agent Substrate 控制平面，让 Pod 回到 Worker 的位置。
Pod 为什么会成为智能体部署的瓶颈
智能体和传统微服务完全是两码事。微服务常驻，智能体却可能突然冒出来、跑几十秒就消失，还会派生出子智能体。如果每个智能体都独占一个 Pod，那么身份、网络策略、配额都得按 Pod 来管，启动和回收的成本会被成倍放大。kagent 项目讨论的正是这个细分问题：Pod 适合当执行环境，但不再适合当部署、身份和生命周期的管理单元。
硬塞进 Pod 的代价
最直接的办法，是把每个智能体都当成一个 Kubernetes 工作负载：分配独立的 Pod、Service、ServiceAccount。隔离、认证、策略控制、原生调度，这些好处确实都有。但坏处同样明显：智能体突发性强、运行时间短、还会派生子智能体，这和常驻的微服务根本不是一回事。为每个智能体开一个 Pod，就像为每趟短途出行都买一辆车，资源浪费太严重。
- 隔离：Pod 级隔离是干净，可数量一多，开销就直线上升。
- 身份：每个智能体都要 ServiceAccount，权限管理变得极其琐碎。
- 调度：Kubernetes 调度器擅长长时间稳定负载，面对大量短生命周期对象并不高效。
- 资源：固定池里跑常驻 Pod，逻辑上却可能只有少数智能体在活动，CPU 和内存大量闲置。
Agent Substrate：在 Kubernetes 之上加一层“翻译”
另一种思路是让 Kubernetes 继续管基础设施，但在上面加一个 Agent Substrate 控制平面。Kubernetes 还是管 Pod、Service 这些资源，Agent Substrate 则负责逻辑智能体的放置、迁移、暂停和恢复。换句话说，Pod 不再代表智能体本身，而是变成了执行 Worker。
这套抽象和 Kubernetes 长得很像：WorkerPool 对应 NodePool，Worker 对应 Node，ActorTemplate 对应 Pod 的声明式规范。Worker 映射到 Pod，Actor 才是真正跑 AI 智能体逻辑的单元。Actor 可以按需调度、挂起、恢复或移除。固定池里长期运行的 Pod，能承载远超 Pod 数量的逻辑智能体。打个比方：100 个常驻 Pod 的池子，每个 Pod 同时处理 10 个 Actor，逻辑上就能支撑 1000 个智能体，而不需要真的启动 1000 个 Pod。
身份、权限、网络、计费都要“上移”
一旦智能体不再和特定 Pod 绑定，原来挂在 Pod 上的那些东西就得搬家。身份标识、访问控制、网络策略、配额计费、可观测性，都要转移到模板、命名空间、租户、版本这些更高维度的对象上。智能体被调度到哪个 Worker，这些属性就跟到哪。这有点像把“员工身份”从工位上解绑：不管坐哪个工位，工牌、权限、项目归属都跟着人走。
这样一来，多租户归属也好处理了。每个租户的逻辑智能体可以在共享 Worker 池里运行，但权限和计费按租户维度隔离。平台团队不用再为了一个临时智能体去单独建命名空间、配网络策略。
Kubernetes 没被否定，Pod 只是换了个角色
这套观点并不是说 Kubernetes 不行了。微服务和推理工作负载在 Kubernetes 上依然很稳。kagent 讨论的只是 AI 智能体的部署单元这一件事。Pod 从“智能体的家”变成“智能体跑腿的 Worker”，Kubernetes 依然是底层调度和资源管理的核心。对于正在规划企业上云、准备用云服务器ECS跑 Kubernetes 的团队，这个变化值得提前了解。找 易枫顺 - 阿里云官方旗舰级代理商 这类阿里云代理商，可以帮你把 K8s 集群、ECS 资源池和上层智能体调度一起规划好。阿里云优惠和阿里云代金券通常能让前期验证成本更低。
这篇讨论随后也被 Kubernetes Podcast from Google 的每周新闻摘要收录，可见它确实踩中了社区关心的节点。
FAQ
Q: 每个 AI 智能体都单独跑一个 Pod，问题在哪？
A: 智能体短命、突发、还会派生子智能体。单独 Pod 虽然隔离好，但资源浪费大，身份和权限管理也很琐碎。固定池 + Worker 模型可以让少量 Pod 支撑大量逻辑智能体。
Q: Agent Substrate 和 Kubernetes 是什么关系？
A: Kubernetes 管 Pod、Service 等基础设施，Agent Substrate 在 Kubernetes 之上管逻辑智能体的放置、迁移和生命周期。Pod 变成执行 Worker，Actor 才是真正跑智能体逻辑的单元。
Q: 身份和权限怎么处理？
A: 智能体不再绑定特定 Pod 后，身份标识、访问控制、网络策略、配额计费都上移到模板、命名空间、租户、版本等维度，再跟着逻辑智能体的调度位置动态关联。
Q: 这个思路对微服务有影响吗？
A: 没有。Kubernetes 在微服务和推理负载上依然可靠。这个讨论只针对 AI 智能体的部署单元，Pod 的角色变了，但 Kubernetes 的底层地位没变。
关于易枫顺
深圳市易枫顺网络科技有限公司是阿里云官方旗舰级代理商。提供云服务器ECS、云数据库RDS、对象存储OSS等阿里云全系产品官方特惠折扣与代金券申请，以及多云成本优化、企业上云一站式服务。客服热线：19520841949 - 易枫顺
来源：InfoQ
