大规模 agentic AI 工作负载正在把 Kubernetes 网络基础设施推向极限。当工作流从静态请求转向自主 agent，安全、高密度的沙箱环境成为刚需，顶级研究实验室的需求量往往达到 100 万个并发代码执行沙箱。在强化学习（RL）这类高级工作流中，极端的 Pod 频繁创建销毁意味着每分钟有成千上万个隔离沙箱在启动和关闭。要让 GPU/TPU 花时间执行模型而不是等沙箱初始化，亚秒级供给和极高的计算密度是硬性要求。GKE 的 Agent Sandbox 提供安全、轻量的隔离以支撑这类高动态环境，Agent Substrate 在其之上进一步追求更高密度与亚秒级状态恢复。

文章把矛头指向一个常被忽略的瓶颈：网络身份管理。传统做法是让自定义控制器给每个 Pod 分配独特标签（agent-id、时间戳、claim-uid）。GKE Dataplane V2 基于 eBPF 把 Pod 标签映射为数字身份来执行网络安全策略。由于 agentic 工作流为每个 Pod 生成高度唯一的标签，系统只能为每个沙箱单独分配身份，这种串行分配在更新 eBPF maps 时会短暂暂停 Pod 创建，偶尔拖慢初始化。更大的风险是触及集群级 65,536 个网络身份的上限。

Google 的解法分两条线。一是迁移高基数数据：Dataplane V2 把「标识性」数据与「功能性」元数据分开，凡是不参与 service selector 匹配或核心资源分组的字段，从 Pod 的 Labels 集合迁到 Annotations 集合。由于 Dataplane V2 只依据 labels 计算网络身份，高基数元数据移出 labels 后，就完全绕过了逐 Pod 身份生成，从根上解决身份扩展限制，且不损失可观测性。

二是Cilium 标签过滤：通过 kube-system 里的 cilium-config-emergency-override ConfigMap 配置排除规则（如 !agents.x-k8s.io/sandbox-name-hash 或 !timestamp），让 Dataplane V2 在计算安全身份时自动忽略这些动态标签。即使开发框架无意引入高基数标签，配置好排除过滤也能自动丢弃。

效果很直接：同类 agent 继续共享同一个 Cilium pod identity，保住超低延迟启动时间。避免身份线性增长、绕开 65,536 上限后，GKE 实现每秒 300 个沙箱、亚秒级延迟的创建速度。有客户通过 Agent Substrate on GKE 跨集群编排了数十万个安全环境，并在单个集群上扛住 3 万多个沙箱的并发峰值。

更进一步，Agent Substrate on GKE 原生整合了上述 Dataplane V2 建议，同时绕过 Kubernetes 调度限制。基准验证中，在 20 万 agent 规模下，它维持每秒 500 次激活，suspend/resume 延迟低于 500 ms，可直接部署在现有 GKE 集群上以降低空闲计算成本。

这篇文章指出了规模化 agent 场景中一个真实的工程瓶颈——网络身份计算，而不只是容器调度。两个优化手段（标签迁移、Cilium 排除过滤）都是明确可落地的配置改动，对正在搭建大规模 agent 基础设施的团队有直接参考意义。