📌 项目地址：agent-substrate/substrate | ⭐ 2,853 颗星 | 🔧 Go | 📜 未标注
先说结论
agent-substrate/substrate，Go 写的，2853 星，Apache-2.0 协议。它是给 Agent 跑生产环境用的执行运行时，核心卖点是两条：
一，省资源。Agent 这种程序有个特点：大部分时间在等，真正干活的时间很短。但传统容器给每个实例独占一份内存和 CPU，闲着也占着。Substrate 的思路是把大量 “actor”（你要跑的 Agent）映射到少量常驻 “worker” 上，谁闲了就挂起谁，资源让给别人。官方数据是密度比标准容器运行时高 10 倍，Demo 里 250 个有状态 actor 只用了 8 个物理 Pod，超额订阅超过 30 倍。
二，挂起恢复要快。挂起一个 Agent 再恢复，整个过程低于 500ms，单机每秒能处理 500 次以上的挂起/恢复。这意味着”临时把闲置 Agent 收起来”这件事的成本低到可以随便做。
为什么快
恢复一个 actor 不是重启进程。Substrate 做的是全状态快照：内存里的工作状态、文件系统，全都在挂起时保存，恢复时原样放回去。对 Agent 来说，等于睡了一觉醒来什么都不记得丢失。
恢复时还可以”传送”：actor 可以恢复到池子里任意一个空闲 worker 上，不必回到原来那台。README 里管这叫 Actor Teleport。
隔离方面默认就是零信任：内核级和网络级隔离都是原生的，沙箱技术支持 microVM 和 gVisor 两种，生命周期操作（create/destroy、suspend/resume）在这两种沙箱上是统一的 API。
和 Kubernetes 的关系
Substrate 不是替代 K8s，是盖在它上面的。基础设施供给、worker 的生命周期管理都交给 K8s，worker 就是普通 Pod，还用上了 Pod 自动伸缩。Substrate 自己负责的是 agent 级别的调度和流量路由，目标是比 K8s 原生调度更低的延迟。
官方还给了一个理由：用 K8s 做底座，同一套基础设施能同时管 Agent、推理、训练这些工作负载。对 RL 场景（训练和 Agentic 循环来回切）来说，统一管理比拼凑几套系统划算。
定位要说清楚
它不是构建 Agent 的 SDK。怎么写 Agent 它不管，它管的是怎么把成千上万个 Agent 跑起来、跑得省、跑得快。README 说自己是 “low-opinion” 系统：跑的东西不必非得是 AI Agent，任何“大部分时间闲置、偶尔需要快速唤醒”的有状态程序都合适。
怎么试
需要一个 K8s 集群。README 指向仓库里的 demos/counter/README.md，照着做就能复现”250 个 actor 跑 8 个 Pod”的演示。这里没有内联命令，具体步骤以那个文档为准。
还有官方视频：https://www.youtube.com/watch?v=ZEzkCFJkzjY
几个要留意的
README 开头就写了：这不是 Google 官方支持的产品，也不参与 Google 开源软件漏洞奖励计划。想提生产环境的话，安全审计和稳定性都得自己扛。
Star 数 2853，项目还年轻。它的思路（挂起恢复 + 高密度多路复用）确实切中了 Agent 基础设施的一个真问题，但成熟度需要时间验证。适合先在自己的集群里跑 Counter Demo，看看那 30 倍超额订阅是不是真的。