将Pod作为worker而非智能体：在Kubernetes上重新思考AI智能体的部署单元
Pod仍然是AI智能体优秀的执行环境，但不再适合作为部署、身份标识或生命周期的单元；应当引入Agent Substrate等上层控制平面，将Pod视为执行worker，由上层管理智能体（Actor）的生命周期与身份，以解决隔离、身份、资源效率等问题。
现状：每个智能体作为独立Pod的问题
最初，kagent等项目将每个智能体作为一级Kubernetes工作负载，配备独立的Pod、Service和ServiceAccount，以利用Kubernetes的隔离、安全、可观测性和调度能力。
直接方法提供的优势
- 进程与容器隔离
- ServiceAccount身份
- 网络与准入策略
- 按智能体归属的日志/指标/追踪
- 原生调度与资源管理
kagent初始采用此模式，后通过Kubernetes Agent Sandbox项目增强隔离。
暴露的问题
- 隔离不足
- 身份标识混乱
- 策略执行困难
- 多租户归属模糊
- → 平台级问题
随着智能体数量增长，出现熟悉的问题：隔离、身份标识、访问与网络策略执行、单智能体可观测性、多租户所有权归属——这些是智能体平台层面的问题，而非纯Kubernetes问题。
智能体与微服务的本质差异
| 属性 | 微服务 | 智能体 |
|---|
| 运行模式 | 持续可用，长时间运行 | 仅在有任务时唤醒，运行几秒至几分钟，然后空闲 |
| 资源消耗 | 需专有Pod长期驻留 | 为每个潜在智能体保留专用Pod浪费严重 |
| 行为特性 | 无子任务生成 | 可产生子智能体并行执行、代表用户操作、无限期等待人工批准 |
Pod是为微服务设计的抽象，无法高效处理智能体短时突发、带子任务和暂停恢复的工作负载。
“Pod是优秀的执行环境，但并不一定是处理这种短时突发工作负载的正确生命周期抽象。”
—— Lin Sun，kagent项目作者
方案：Agent Substrate——Pod作为Worker
在Kubernetes之上引入智能体控制平面，将Pod降级为执行worker，而智能体（Actor）作为逻辑单元由上层管理生命周期与放置。
核心抽象对比
WorkerPool ≈ NodePool，Workers ≈ Nodes，ActorTemplate ≈ Pod的声明式规范
Kubernetes只管理WorkerPools和ActorTemplates，Workers和Actors存在于Agent Substrate的CLI/API中。
每个Worker映射到一个Pod，Actor在有工作到来时调度到Worker上，可被挂起、恢复或移除。固定池内长期运行的Pod能支撑远超自身数量的逻辑智能体，显著提升调度效率。
“Agent Sandbox提供隔离执行环境，Agent Substrate管理逻辑智能体如何被放置到Worker中并支持迁移。”
—— Google，Agent Sandbox与Agent Substrate公告
影响与展望
当Actor可在任意Worker上运行，其身份标识应属于ActorTemplate、命名空间、租户和版本，而非Pod或Service。访问控制、网络策略与运行时权限需在模板级别表达，并支持按Actor覆盖。
需重新设计的能力
归属权、配额与计费跟踪更困难；可观测性必须跟随逻辑智能体，将日志、追踪与审计记录与Actor调度位置关联。
执行不再与Pod一一对应，运维模式需相应调整。
“这并没有否定Kubernetes在规模化微服务与推理工作负载方面的行业地位。需要讨论的是一个更细分的问题：Pod是否还应该继续作为AI智能体的部署、身份识别与生命周期单元。”
—— Lin Sun，kagent项目作者
综合公开信息整理