Agent Substrate：在 Kubernetes 之上做高密度代理调度的早期系统
Agent Substrate：核心系统。 Agent Substrate 是一个构建在 Kubernetes 之上的系统，它管理类似代理的工作负载，以实现比 Kubernetes 单独提供的更高的规模和效率，并且延迟更低。
秒懂
- 它是什么？
- Agent Substrate 是一个构建在 Kubernetes 之上的代理运行时，用 suspend/resume 和资源超卖把大量空闲代理塞进少量 Pod。它目前处于早期开发阶段，API 不稳定，适合评估而非生产。
- 适合谁用？
- 适合以下团队采用：需要运行大量有状态、长时间空闲的代理，且能接受 Kubernetes 作为底层依赖的开发者。不适合生产环境，因为项目明确声明 API 几乎必然变化，且不保证向后兼容。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Go（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题：代理的空闲时间被浪费了
大多数代理应用并不持续占用 CPU。它们等待用户输入、等待工具响应、等待下一个任务。Agent Substrate 的出发点就是利用这个空闲特性。它把大量有状态的“actor”映射到少量准备好的“worker”上，通过 suspend 和 resume 在亚秒级切换。文档给出的演示是 250 个有状态 actor 复用 8 个物理 Pod，超卖比例超过 30 倍。这不是给那些需要持续计算的工作负载设计的，而是给那些大部分时间处于等待状态的代理设计的。如果你运行的是批处理任务或长时间满载的计算，这个系统不会给你带来收益。
工作机制：actor、worker 与 Kubernetes 的分工
系统把应用抽象为 actor，把运行环境抽象为 worker。actor 代表一个代理实例，包含状态、内存和文件系统。worker 是实际运行 actor 的 Pod。Agent Substrate 的控制平面负责把 actor 分配到 worker 上，并在需要时挂起或恢复。挂起时，actor 的完整状态被保存为快照，包括易失性内存和文件系统。恢复时，快照被加载到另一个可用的 worker 上。Kubernetes 负责 worker 的供应和生命周期管理，也就是 Pod 的创建和自动扩缩。Agent Substrate 则负责代理级别的调度，这部分 Kubernetes 原生不提供。文档强调它构建在 Pod 和 Pod 自动扩缩之上，而不是替代它们。
沙箱技术：gVisor 与 microVM 的一致性操作
系统支持多种沙箱技术，包括 microVM 和 gVisor。它声称对所有沙箱类型提供一致的生命周期操作。这意味着无论底层是哪种沙箱，创建、销毁、挂起、恢复的接口都是一样的。文档特别提到它通过 gVisor 在内核级别管理标准 OCI 容器，因此可以承载任何技术栈构建的代理。这解决了代理框架碎片化的问题。ADK、LangChain、Claude Code、CodeX 都可以作为 actor 运行。MCP 服务器也可以部署为 actor，为 LLM 提供持久的工具。但要注意，沙箱本身有性能开销，gVisor 和 microVM 都不如原生容器快。你需要自己权衡隔离性和性能。
快速上手：真实命令与配置步骤
开发环境需要 Go、kubectl 和 docker。项目用脚本自动管理 kind 和其他依赖。首先创建集群和本地 registry，执行 hack/create-kind-cluster.sh。然后安装系统组件，执行 hack/install-ate-kind.sh --deploy-ate-system。接着安装 counter 演示，执行 hack/install-ate-kind.sh --deploy-demo-counter。安装 kubectl 插件，执行 go install ./cmd/kubectl-ate。创建 atespace 和 actor，命令是 kubectl ate create atespace demo，然后 kubectl ate create actor my-counter-1 -a demo --template=ate-demo-counter/counter。最后需要端口转发网络服务，但 README 被截断，具体命令未知。这些命令表明系统通过 kubectl 插件与 Kubernetes 交互，ate 是核心控制平面的名字。
框架无关与生态：不只是 AI 代理
文档强调这是一个低意见系统。它不要求工作负载必须是 AI 代理，只是代理是最典型的用例。它也不是代理 SDK，不帮你构建代理逻辑，只负责运行它们。生态方面，Google 的 Agent Executor 项目展示了如何构建在 Agent Substrate 之上。这暗示了系统的定位：作为基础设施层，而不是应用框架。框架无关性来自对 OCI 容器的支持，任何能打包成容器的应用都可以作为 actor。但这也意味着你需要自己处理代理的编排逻辑，系统只提供生命周期和调度。
真实局限：早期状态与兼容性风险
项目明确声明处于早期开发阶段，不适合生产使用。API 几乎保证会变化，不提供向后兼容保证。这意味着你今天写的配置明天可能失效。支持的 Kubernetes 版本只有最新稳定版和上一个次要版本，如果你运行的是较旧的集群，可能无法使用。文档还特别注明这不是 Google 官方支持的产品，也不参与 Google 开源漏洞奖励计划。这些限制对生产环境是致命的。如果你需要一个稳定的基础，这个项目目前不是选择。它更适合那些愿意跟踪每周更新、参与社区讨论的早期采用者。
替代方案：直接使用 Kubernetes 原生能力
最直接的替代方案是使用 Kubernetes 原生 Pod 加上水平自动扩缩。Kubernetes 本身可以管理 Pod 的生命周期，自动扩缩可以根据 CPU 或自定义指标调整副本数。但 Kubernetes 不提供 suspend/resume 操作，也不做代理级别的调度。如果你需要挂起和恢复，原生方案需要你自己实现状态快照和恢复逻辑。另一个思路是使用无服务器容器平台，它们也提供按需启动和停止，但通常不保留内存状态。Agent Substrate 的差异在于它保留了完整的内存和文件系统状态，并且恢复时间在亚秒级。如果你的应用可以接受冷启动延迟，无服务器平台可能更简单。
维护与升级成本：每周会议与持续变更
项目维护活跃，有每周社区会议和 Google Group。但这意味着你需要持续关注变更。文档明确说 API 会变，所以升级成本可能很高。你需要跟踪每次发布，更新配置和代码。许可证是 Apache-2.0，这是宽松许可证，允许商用和修改，但你需要保留版权声明。由于项目非常年轻，贡献者可能会频繁改变设计方向。如果你打算长期使用，需要准备投入时间跟进。如果你只是评估，可以先用 counter 演示验证基本功能，再决定是否深入。
编辑结论
适合以下团队采用：需要运行大量有状态、长时间空闲的代理，且能接受 Kubernetes 作为底层依赖的开发者。不适合生产环境，因为项目明确声明 API 几乎必然变化，且不保证向后兼容。在评估时，先验证三件事：你使用的 Kubernetes 版本是否为最新稳定版或上一版本；你是否能接受 gVisor 或 microVM 带来的性能开销；你是否愿意参与每周社区会议并跟踪 API 变更。如果你的代理负载空闲率不高，或者你需要稳定的长期 API，那么直接使用 Kubernetes 原生 Pod 加水平自动扩缩可能更合适。Agent Substrate 的价值在于把代理的空闲时间转化为资源收益，但这个收益只有在负载特征匹配时才成立。
社区笔记