将Pod作为worker而非智能体：在Kubernetes上重新思考AI智能体的部署单元

在一篇 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 "