大家好，我是Tony Bai。

随着大语言模型（LLM）与应用场景的深度融合，AI 正在从单纯的“聊天对话框”快速演进为具备长期运行、自主工具调用和复杂任务编排能力的 AI Agent（智能体）。

在生产环境中，这些 Agent 展现出与传统微服务截然不同的负载特征：它们是高度非线性的、需要频繁执行不可信代码（如动态生成的 Python 脚本）、在等待人类确认（HITL，人类在环）时长期处于闲置状态，同时又会在瞬时产生极其高频的子秒级（Sub-second）工具调用。

传统的容器和虚拟机调度架构（如标准的 Kubernetes）面对这种数以百万计、高密度、长生命周期但又极度高并发的“智能体负载（Agentic Workflows）”时，在隔离安全性、调度时延与算力浪费上面临严重的物理局限。

针对这一工程痛点，Google 在 Google I/O '26 大会上给出了其深思熟虑的系统级回应。这并非一个单一工具的发布，而是一套分层解耦的云原生 Agent 堆栈的整体亮相。

Google 定义的“三层 Agent 堆栈”，其中包含了：

1. 应用运行时（Agent Runtime）：开源项目 Agent Executor（AX），专注于可靠的状态编排、连接恢复与执行审计。

2. 高密度计算与调度层（Compute Plane）：开源项目 Agent Substrate，专注于海量闲置 Agent 的极速挂起/恢复与去中心化控制平面调度。

3. 安全隔离层（Sandbox Layer）：已正式商用的 GKE Agent Sandbox，基于 gVisor/MicroVM 技术，提供低时延、强隔离的运行沙箱。

本文将拆解这一套以 Agent 为负载单元的新型云原生抽象层，揭示 Google 是如何重新定义大模型时代的分布式系统底座的。

架构解密：从基础设施到应用层的“三层 Agent 堆栈”

要理解这一套复杂的系统，我们需要像拆解传统 TCP/IP 协议栈一样，将其自底向上划分为四个物理层级：

层级	代表组件	核心职责	技术关键点
应用层 (Application)	开发者业务应用	实现具体的业务逻辑与场景交互	提示词工程、知识库构建
运行时层 (Runtime)	Google AX 、Antigravity	状态一致性管理、连接恢复、安全审计、轨迹分支（Forking）	单写入者架构、事件持久化日志、MCP 标准协议
计算与调度层 (Compute Plane)	Agent Substrate	解决高密度并发、超低延迟的冷启动、高频子秒级工具调用对 K8s 控制面的冲击	快速挂起与恢复（Suspend & Resume）、独立控制面
沙箱隔离层 (Sandbox/IaaS)	GKE Agent Sandbox 、Kubernetes	提供不可信代码的强物理隔离、Standby 算力缓冲池	gVisor、Pod 快照技术、Standby 缓冲池

这种分层解耦的系统设计，标志着 AI 应用开发正式告别了“框架包揽一切”的单体混沌状态，进入了精细化、高可用的系统工程时代。

底层解局：Agent Substrate 与 Sandbox 是如何解决物理局限的？

传统的 Kubernetes 是为了支撑长期运行、状态相对稳定的“微服务（Microservices）”而设计的。如果直接将数百万个 Agent 部署为普通的 K8s Pod，系统会迅速面临崩溃：

• 内存与算力浪费：许多 Agent 处于非激活状态（等待人类输入或调度触发），如果让它们的 Pod 持续在线，会产生天文数字的算力账单。

• 控制面过载：数百万个 Agent 产生的子秒级内部工具调用，如果全部经过传统的 K8s API Server 进行调度和授权，会直接导致 K8s 控制平面瘫痪。

• 安全防线脆弱：Agent 具有动态执行解释型代码（如本地运行一段临时生成的 Python 来计算数据）的本能，一旦逃逸，将危害宿主机安全。

为此，Google 联合 GKE 团队和 Kubernetes 社区，推出了 Agent Substrate 与 Agent Sandbox：

1. 基于 gVisor 的强物理隔离（Ironclad Security）

GKE Agent Sandbox 默认集成了开源的安全容器沙箱 gVisor。

它在不可信的 Agent 应用代码与 Linux 内核之间插入了一个名为 Sentry 的用户态内核。所有 Agent 试图执行的系统调用（Syscalls）都会在用户态被拦截、审计并安全执行。这确保了即便 Agent 生成的代码带有恶意，也绝无可能穿透容器逃逸到宿主机上，实现了生产级的“Secure-by-design”。

2. Pod 快照技术与冷启动消除（Reduce Idle Compute & Low Latency）

为了消灭 Agent 闲置时的算力浪费，Agent Substrate 引入了 Pod 快照技术（Pod Snapshots）：

• 主动挂起（Suspend）：当一个 Agent 进入休眠或长时等待状态时，Agent Substrate 捕获其完整的运行状态并制作快照，释放其占用的物理 CPU 与内存资源。

• 瞬时恢复（Resume）：当事件触发或用户响应时，系统通过集成的 温水池（Warm Pool） 技术，利用快照快速恢复运行。

根据 Google Cloud 的官方测评，GKE Agent Sandbox 能够在每秒启动 300 个沙箱的高并发压力下，保证 90% 的分配在 200 毫秒内完成。这几乎抹平了传统安全容器长达数秒的冷启动时延，真正做到了“随用随起，用完即挂”。

图：GKE 引入的高性能温水池与 Pod 快照技术

应用层编排：Google AX 如何行使“指挥官”职责？

在底层的 Agent Substrate 提供了极致的物理隔离与快速调度能力后，位于上层的 Agent Executor (AX) 运行时则真正扮演起了“状态与业务编排指挥官”的角色。

AX 的核心设计并不是去触碰模型细节，而是通过 Single-Writer 架构 和 Durable Execution（持久化执行） 来保障 Agentic 循环的绝对可靠：

1. 轨迹分支（Trajectory Branching）与分支克隆（Forking）

在复杂决策中，开发者往往希望 Agent 能像写代码一样，在某个关键节点“分叉（Fork）”去尝试多条不同的规划路径，在评估各路径的优劣后再做最终合并。

由于 AX 底层维护了强一致性的持久化事件日志，它原生提供了 ax fork 功能：

ax fork \
  --src-conversation 38460323-9a78-41cb-8991-022b0ff2c19c \
  --dest-conversation e5e26e38-53a2-4f22-b1cb-ae867357df83 \
  --src-seq 12

开发者可以直接在指定的事件序列号（--src-seq 12）处，克隆出一条全新的、独立的执行轨迹（Trajectory）。这让 AI 在多路径探索、蒙特卡洛树搜索（MCTS）等高级推理算法中的应用变得异常简单和标准。

2. 会话一致性（Session Consistency）

在多客户端并发控制或分布式协作中，多个进程可能同时试图更新同一个 Agent 的会话状态。AX 的单写入者（Single-Writer）架构通过统一的序列号控制机制，彻底避免了因并发竞争（Race Conditions）导致的状态脏写与损坏。

统一的工程视角：Go 的系统级胶水作用

如果我们仔细观察这套三层架构，会发现一个极具工程美学的现象：

1. 最底层的 Kubernetes 与 GKE Sandbox：由 Go 语言统治。

2. 中间层的 Agent Substrate 与 AX：同样是由 Go 语言构建（github.com/google/ax 和 github.com/agent-substrate/substrate）。

3. 最上层的 Agent 应用与框架：则可以使用 Python（如 LangChain、ADK）来尽情发挥，当然如果你依然要使用Go，比如adk-go，来开发Agent应用也是非常棒的选择。

这一架构再次印证了我们在 AI 系统工程中的理性认知：运行时底层是系统级工程（System Engineering），应用层是模型算法工程（Algorithm Engineering）。

Go 语言在这里扮演了不可替代的“系统级胶水”角色：它将高密度调度、gRPC 双向流、持久化快照以及隔离沙箱等硬核的系统级原语，封装成极其简单易用的 CLI 和 API，让上层的应用开发者能够专注在 Prompt 与模型逻辑上。

小结

在看完 Google 发布的这一套以 Agent 为第一公民的云原生计算底座后，作为软件工程师，我们应该感到无比的兴奋。

大模型确实降低了写业务逻辑代码的门槛，甚至让“AI 自动编程”成为可能。但正如 Google 资深软件工程师 Tim Hockin（Kubernetes 的共同创始人之一）和 Brandon Royal 的联手探索所展示的那样：如何在大规模、高密度、异构的物理硬件集群中，保障这些 AI 智能体安全、高效、廉价地运转，是一个极其深邃、且刚刚拉开序幕的分布式系统课题。

• 谁来设计高密度的内存挂起与快照算法？

• 谁来在网络边界保障 gVisor 沙箱的安全网络策略？

• 谁来在 AX 层面设计多 Agent 协作时的数据一致性协议？

这些问题，AI 无法自己解决，它需要那些真正懂得底层计算机制、网络协议和系统调度的优秀工程师。

随着大模型和 Agent 的普及，软件工程正在经历一场从“单机时代”迈向“网格化 Agent 集群时代”的伟大战役。掌握这一套新型基础设施设计哲学与开发范式的架构师们，正在迎来属于他们的、前所未有的黄金时代。

资料链接：

• https://x.com/rakyll/status/2057129537553785093

• https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate

• https://cloud.google.com/blog/products/ai-machine-learning/agent-executor-googles-distributed-agent-runtime

• https://github.com/agent-substrate/substrate

• https://github.com/google/ax

• https://github.com/kubernetes-sigs/agent-sandbox

---

✍️ 今日的深度思考题：

当底层的 GKE Sandbox 能够将 Agent 启动时延压低至 200 毫秒以内、且支持自动挂起时，你会如何重新设计你的多 Agent 编排逻辑？这会给你的服务器算力账单带来怎样的改变？

欢迎在评论区留下你对这一套“Agent 时代 K8s 抽象层”的看法，我们共同探讨云原生的未来！

---

如果本文对你有所帮助，请帮忙点赞、推荐和转发！

点击下面标题，阅读更多干货！

-  霸榜 GitHub 一周！Google 开源 ADK for Go，彻底终结 AI“炼丹”时代？

- 大洗牌！Google 内部确认：Go 正取代 C++，成为 AI Agent 时代的“通用语言”

- Google官宣：Go实现的Antigravity CLI上位

-  实战解剖：Kubernetes 是如何管理数百个依赖的？

- AI 时代，软件大师们为什么都倒戈向 Go 和 Rust 了？

- 如果服务器悄悄“猝死”，你的系统还能活几秒？揭秘分布式集群的“续命”保底机制

- 现实世界的法则 —— 分布式系统的定义、模型与核心挑战

---

🔥 还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理

• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw

• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线

• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估

• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码👇，开启从 0 开始构建Agent Harness 的实战之旅。