如何在几台服务器上高效运行数百个AI智能体而不破产

通常情况下，使用Kubernetes是可预测的：一个服务——一个pod（好吧，或者一个ReplicaSet）。但当我们进入AI智能体的世界时，熟悉的模式就会崩溃。想象一下，你有数千个智能体，每个都在内存中保存着对话上下文、环境变量和文件系统状态。它们大部分时间什么都不做——只是等待用户命令或事件。为每个智能体在K8s中分配一个完整的pod成本很高：控制平面会直接被这么多对象压垮，而集群资源也会被浪费。

Google团队（虽然该项目标记为非官方）推出了Agent Substrate。这是一个允许仅用几个物理pod就能"同时处理"数百个活动智能体会话的系统。

标准方法的问题

在Kubernetes中，创建pod不是即时操作。你需要更新etcd中的状态、等待调度器、拉取镜像，然后启动容器。对于交互式智能体来说，延迟几秒钟就已经太长了。此外，当智能体"休眠"时，你希望释放它的资源，但当它醒来时，需要立即恢复所有文件和内存中的变量。

Agent Substrate通过actor和worker的概念解决了这个问题。Actor就是你的应用程序（智能体），而worker是长期运行的pod-shell。该系统将大量actor映射到一个小型的worker池中。

项目的主要特性

即时会话迁移

这听起来像魔法，但实际上是基于gVisor实现的。当智能体不活跃时，Substrate会对其状态（包括内存）进行快照并保存。一旦请求到来，系统会找到一个空闲的worker并在那里"解压"快照。激活时间不到一秒。

无需hack的状态保存

你不需要为智能体做的每件小事痛苦地配置外部数据库，也不需要挂载缓慢的网络驱动器。整个状态，包括RAM内容和本地文件，都会被完美保存。如果智能体当时正在终端中写代码或在内存中持有数据数组，休眠后它会完全从中断的地方继续。

疯狂的 multiplexing

在演示视频中，作者展示了250个有状态的actor如何仅用8个pod就能容纳。这提供了数十倍的资源节省。对于构建AI代理平台或开发服务（如Claude Code）的人来说，这是降低云账单的直接途径。

底层原理

该项目使用Go编写，并与Kubernetes生态系统紧密集成，但它将actor管理从K8s控制平面的关键路径中移出。

主要组件包括：

• ateapi：系统的核心，管理actor的生命周期。
• atelet：节点上的守护进程，负责编排快照和状态传输。
• atenet：处理流量路由，使请求到达正确的worker——即所需actor当前"唤醒"的位置。
• gVisor (runsc)：提供隔离并启用进程检查点。

顺便说一句，该项目完全与框架无关。无论你使用的是LangChain、Claude Code还是自定义Python脚本——只要它被打包为OCI容器，Substrate就能运行它。

快速开始

如果你已经安装了Go、Docker和kubectl，可以通过在本地试用该系统。开发人员准备了脚本，可以在几分钟内启动集群和演示环境。

git clone https://github.com/google/agent-substrate.git
cd agent-substrate
./scripts/setup.sh

之后，你可以使用标准的Kubernetes API调用actor。系统会自动判断是否需要唤醒它以及将请求路由到哪里。

现在值得尝试吗

该项目处于"非常早期开发"阶段。这意味着API肯定会发生变化，不保证向后兼容性。现在用于生产还为时过早，但对于研发部门以及设计LLM服务基础设施的人来说，这是必须研究的。

如果你需要运行数千个用于代码执行的隔离沙箱，或者大量必须记住上下文的AI助手，Agent Substrate提供了一条比尝试将原生Kubernetes扩展到无限更优雅的路径。

视频展示了系统实时处理actor的情况。

项目团队在CNCF Slack（频道#substrate-users和#substrate-dev）中积极交流，并每周召开会议。显然，这个项目背后有虚拟化和容器化方面的专业知识。至少，这是一个扩展K8s能力以处理特定工作负载的绝佳范例。