agent-substrate/substrate

解决什么问题

把 AI Agent 跑大规模会遇到两个互相拉扯的需求：Agent 执行的是不受信任、可能被提示词注入的代码，需要强隔离；但 Agent 大部分时间都在等模型、等工具、等人，一个 Agent 常驻一个沙箱就是纯烧钱。团队通常要么一个容器一个 Agent 然后账单爆炸，要么共享基础设施，结果被攻破的 Agent 能摸到凭证和邻居。Agent Substrate 把每个 actor 都当成不受信任对象，把大量有状态的 actor 映射到少量热 worker 池上，空闲就快照换出、有请求再恢复。

有什么不同

和普通 Kubernetes Pod、一 Agent 一容器方案不同，Substrate 明确不支持裸 Linux 容器，每个 actor 都跑在 gVisor 或 Cloud Hypervisor microVM 里，项目宣称可实现 10x–30x 的超分。和直接用 gVisor 或 Firecracker 相比，它多了一层有主见的管理面：actor 可在 worker 间迁移，内存和文件系统状态完整持久化，每个 actor 有 SPIFFE 身份，出口网关在沙箱外注入凭证，工作负载手里永远没有可泄漏的密钥。比较有意思的设计是把策略放在可替换的出口网关上做执行点，而不是在 Agent 内部做护栏，思路与常见的 in-agent guardrail 相反。README 明确说这是运行时不是 Agent SDK，文中的 >1500 次激活/秒、<400ms 恢复都是项目自述数据。

适合谁

已经用 Kubernetes、需要在一批共享节点上托管大量并发、多数时间空闲、彼此敌对的 Agent 或 MCP server 的平台/基础设施团队，尤其是合规上不允许 Agent 接触真实凭证的场景。已经在用 ADK、LangChain、kagent 或 agent executor 的团队可以把它当现成的沙箱层。只做单个 Agent 的开发者、或没有 K8s 运维能力的小团队应当继续用普通容器或托管 Agent 运行时，否则只是多引入一个控制面和一堆新的故障模式。

上手成本

开发环境快速开始需要 Go、kubectl、Docker，脚本会拉起 kind 集群、PostgreSQL 和存储。生产要求 Kubernetes 最新稳定版和上一个次版本，节点需支持 gVisor 或 microVM；单机跑超过约 1000 个沙箱时还需调大内核邻居表。项目 pre-1.0，不保证向后兼容，API 和行为可能大改；贡献指南坦言团队当前聚焦核心系统，外部 PR 可能长时间无人 review。许可为 Apache-2.0，安装入口只有仓库里的 hack 脚本，README 没给现成命令。

点评

这是一个很新的项目（2026 年 5 月创建，约 160 天），已有 5.7k star，单月涨约 2.4k，冲进 Go 月榜第 19 名，说明发布势头很强。但 Hacker News 上只有 3 个帖子、最高 2 分零评论，外部审视还很弱。与 Google 系生态的集成和 CNCF Slack 频道是真实的投入信号，但不等于已有生产验证。如果你的 Kubernetes 上要跑不受信任的 Agent，值得认真评估；否则建议等 1.0 API 稳定后再看。