摘要：Agent Substrate 是构建在 Kubernetes 之上的高密度有状态 Agent 调度与运行控制平面，通过将操作系统“虚拟内存超分配”的思路迁移到计算调度领域，以旁路控制平面绕开 K8s 原生调度瓶颈，实现海量逻辑 Actor 与少量物理 Worker 的两级映射。文章从诞生背景、架构设计、核心技术特性（30 倍以上资源超卖、亚秒级会话激活、有状态会话无缝迁移、生产级安全隔离、框架无关）出发，详细拆解了超分配调度的完整生命周期，包括预热初始化、激活调度、运行态管理、主动挂起、被动驱逐与迁移调度，并给出水位控制弹性策略、与传统 K8s 调度的差异，以及 WorkerPool 与 ActorTemplate 的标准生产环境配置示例。

1. 核心定位

Agent Substrate 是构建在 Kubernetes 之上的高密度有状态 Agent 调度与运行控制平面，它不负责 Agent 的业务逻辑与推理编排，而是解决大规模 Agent 部署的底层基础设施痛点：资源利用率低、调度时延高、有状态会话迁移难、不可信代码执行风险高。

简单来说：传统 K8s 面向“长运行、高负载”的微服务设计，而 Agent Substrate 面向“长生命周期、大部分时间闲置、突发高并发、强状态依赖”的 AI Agent workload 做了底层重构。

2. 诞生背景

AI Agent 生产化部署面临三大基础设施瓶颈：

• 资源浪费严重：Agent 多数时间处于等待状态（人类确认、工具调用返回、事件触发），传统“一个 Agent 一个 Pod”的模式算力闲置率极高，规模化部署成本不可接受
• 调度时延过高：标准 K8s 调度器创建 Pod 需秒级以上时延，无法满足 Agent 亚秒级激活、高频工具调用的诉求
• 安全与状态矛盾：Agent 常执行大模型生成的不可信代码，需要强隔离；但常规容器/虚拟机隔离方案又会进一步拉高启动与迁移成本

Agent Substrate 正是针对以上痛点，将操作系统"虚拟内存超分配"的思路迁移到计算调度领域，实现海量 Agent 会话的高密度复用与极速启停。

架构设计

表格

• 旁路控制平面：Substrate 控制平面独立于 K8s 标准控制平面之外，仅将 K8s 作为资源供给底座，Agent 调度不经过 K8s 原生调度器，从关键路径上消除了调度瓶颈
• 两级资源模型：上层是海量、稀疏的逻辑 Actor（Agent 会话），下层是少量、密集的物理 Worker Pod，通过超分配实现两者的映射

核心技术特性与设计亮点

1. 计算资源超分配（30x+ 超额订阅）

类比操作系统虚拟内存机制：

• 操作系统通过冷热页面置换，让程序寻址远超物理内存的地址空间
• Agent Substrate 将闲置的 Agent 会话（内存 + 文件系统全量状态）快照持久化到存储，仅将需要运行的 Agent 加载到预热的 Worker Pod 中
• 官方数据显示可实现30 倍以上的资源超卖率，大幅降低大规模 Agent 部署的算力成本

2. 亚秒级会话激活

• 维护预热的 Worker Pod 资源池，沙箱与运行环境已就绪
• Agent 激活时无需创建 Pod、拉取镜像、初始化环境，直接在现有 Worker 中恢复快照
• 端到端激活时延低于 200ms，支持高频次的事件驱动型 Agent 调用

3. 有状态会话无缝迁移

• 快照包含完整的内存状态与文件系统状态，而非仅持久化业务数据
• 闲置 Agent 可随时从一个 Worker Pod 迁移到另一个 Worker Pod，恢复后业务状态完全连续，用户无感知
• 支持基于负载的动态调度、节点维护时的平滑迁移

4. 生产级安全隔离

底层复用 GKE Agent Sandbox 的 gVisor 技术：

• 在用户态实现系统调用拦截与重实现，大幅缩小内核攻击面
• 每个 Actor 运行在独立沙箱中，跨租户、跨 Agent 无数据泄露风险
• 支持沙箱暖池，300 个 / 秒的沙箱创建速度，兼顾安全与性能

5. 框架无关与生态兼容

• 任何打包为 OCI 容器镜像的工作负载都可作为 Actor 运行
• 原生兼容 LangChain、Google Agent Executor (AX)、Claude Code 等所有主流 Agent 框架
• 兼容标准 Kubernetes 集群，可在本地 Kind、GKE 及其他合规 K8s 环境部署

核心抽象与资源模型

Agent Substrate 对外暴露两个核心自定义资源（CRD），开发者通过这两个资源完成全部配置：

1. WorkerPool

   • 定义物理计算资源池，包括 Worker Pod 的规格、数量、自动扩缩容策略
   • 对应预热的沙箱运行环境，是所有 Actor 共享的物理执行载体

2. ActorTemplate

   • 定义 Agent 工作负载的模板，包括镜像、资源配额、启动参数等
   • 基于模板可创建大量独立的 Actor 实例，每个实例拥有独立状态与生命周期

未来规划(2026-08-05，开源代码还未实现)

Agent Substrate 最重要的就是把闲置的沙箱挂起，让渡给有需要的沙箱；挂起的沙箱在需要恢复的时候，能够快速恢复，从而充分利用计算资源。

Agent Substrate 的计算资源超分配调度，本质是将操作系统虚拟内存的 “按需调页 + 冷热置换” 思想，从内存维度扩展到整个计算沙箱维度：通过旁路控制平面绕开 Kubernetes 原生调度瓶颈，让海量长生命周期的逻辑 Agent（Actor）在少量预热的物理 Worker Pod 上分时复用，依赖 gVisor 快照的极速挂起 / 恢复能力，最终实现 30 倍以上的超额订阅率。

以下从架构、模型、全流程、核心策略四个维度展开详细拆解。

一、调度架构：旁路控制平面，绕开 K8s 原生瓶颈

传统 K8s 调度器面向长生命周期 Pod 设计，端到端启动时延在秒级，且 API Server 无法承载百万级 Actor 高频的挂起 / 恢复操作。Agent Substrate 采用旁路控制平面架构，仅将 K8s 作为底层资源供给底座，所有 Actor 调度均在独立控制面完成。

核心调度组件：

• ate-apiserver：全局调度核心，以 gRPC 接口处理 Actor 创建、激活、挂起、迁移指令，维护全集群 Actor 状态元数据与 Worker 池资源视图，所有调度决策在此完成。
• atelet：节点级 DaemonSet 代理，负责本节点 Worker Pod 生命周期管理、快照本地缓存与持久化、执行 gVisor 沙箱的 checkpoint/restore 操作，是调度指令的实际执行者。
• atecontroller：声明式控制器，对接WorkerPool与ActorTemplate两个 CRD，负责 Worker 池的弹性扩缩容、黄金快照制作、模板初始化等运维操作。
• ateom-gvisor：每个 Worker Pod 内的沙箱助手，封装 gVisorrunsc能力，执行具体的内存 + 文件系统快照制作与恢复。

二、两级资源模型：超分配的底层逻辑

超分配的核心是逻辑实体与物理载体解耦，形成 “海量稀疏 Actor × 少量密集 Worker” 的两级映射：

1. 上层：逻辑 Actor 层

• 每个 Actor 对应一个独立 Agent 会话，拥有完整的内存状态、文件系统、网络上下文，生命周期与用户会话对齐（可长达数小时至数天）。
• Actor 是纯逻辑实体，不绑定任何物理 Pod，可在集群任意 Worker 上恢复运行。
• 三种核心状态：运行态（Running）、挂起态（Suspended）、待激活（Pending）。

2. 下层：物理 Worker 层

• WorkerPool定义一组预热的 Worker Pod，每个 Pod 内置多个 gVisor 沙箱槽位，沙箱内核与运行时环境始终就绪，仅缺业务状态。
• 每个沙箱槽位同一时间只能承载一个运行态 Actor，是物理资源的最小分配单位。
• Worker 池规模远小于 Actor 总数：官方 Demo 中 8 个 Worker Pod 可稳定承载 250 个有状态会话，对应 30 倍以上超卖比。

超分配核心公式：

Actor 总数 = 运行态 Actor 数 + 挂起态 Actor 数其中 运行态 Actor 数 ≤ Worker 池总沙箱槽位数

闲置 Actor 的完整状态被快照持久化到对象存储，用低成本存储置换昂贵的算力资源，这是超分配的本质。

三、超分配调度全流程

完整的调度生命周期分为 6 个核心阶段，覆盖从初始化到弹性迁移的全链路：

1. 预热初始化：黄金快照与沙箱暖池

调度前置准备，是亚秒级激活的基础：

1. 基于ActorTemplate制作黄金基准快照（Golden Snapshot）：启动一个标准 Actor 完成初始化后制作全量快照，作为同模板所有 Actor 的启动基底，避免每次从零启动容器。
2. Worker 池启动时，每个 Pod 预先初始化 N 个空 gVisor 沙箱（暖池），沙箱内核、网络栈、运行时环境全部就绪，激活时仅需恢复业务状态，无需重启沙箱本身。

2. 激活调度：事件驱动的亚秒级放置

当事件（用户消息、API 调用、定时触发）到达挂起态 Actor 时，触发激活调度：

1. 路由接入：事件通过atenet网关到达 ate-apiserver，调度器查询元数据，确认 Actor 状态与最新快照位置。
2. Worker 选择：按优先级筛选空闲沙箱槽位：
   • 优先选择本地缓存了该 Actor 最近快照的 Worker（数据局部性最优，无需跨节点拉取）
   • 其次选择负载最低、剩余资源最充足的 Worker
   • 最后考虑同可用区、网络时延最低的 Worker
3. 状态恢复：atelet 通知 Worker 内的 ateom-gvisor 执行 restore，从本地缓存或对象存储拉取 Zstd 压缩快照，恢复完整内存与文件系统。
4. 流量切流：状态恢复完成后，atenet 实时更新路由规则，将流量转发到对应沙箱，激活完成。

整个端到端激活时延低于 200ms，核心原因是完全绕开了 K8s 的 Pod 创建、调度、镜像拉取流程，仅做状态恢复。

3. 运行态管理：空闲计时与心跳保活

Actor 运行期间，atelet 持续监控沙箱 CPU 使用率、网络 IO 与业务心跳：

• 检测到 Actor 进入等待状态（等待用户输入、等待工具返回），立即启动空闲计时器。
• 高优先级任务可通过 Annotation 标记为 “不可驱逐”，确保关键流程不被打断。

4. 主动挂起调度：闲置资源回收

当空闲计时器超时（可配置，默认秒级），触发主动挂起：

1. ateom-gvisor 执行 checkpoint，捕获 Actor 完整内存镜像、文件系统增量、打开的句柄与网络连接状态。
2. 快照经压缩后，一份缓存到 Worker 本地磁盘（用于快速二次激活），一份持久化到对象存储（用于跨节点迁移）。
3. 销毁沙箱内业务进程，释放 CPU 与内存，沙箱槽位标记为空闲，可分配给其他 Actor。
4. ate-apiserver 更新 Actor 为挂起态，记录最新快照位置。

5. 被动驱逐调度：高负载下的资源腾让

当 Worker 池空闲槽位低于阈值，且有新的激活请求排队时，触发被动驱逐，强制置换闲置 Actor：

• 已进入空闲态且空闲时间最长的 Actor（LRU 算法）
• 标记为低优先级的非关键会话
• 正在运行但 CPU 利用率极低的后台 Actor
• 驱逐过程与主动挂起完全一致，确保状态零丢失，仅增加毫秒级切换开销。
• 这是超分配的核心保障：突发流量下，通过快速冷热置换保证业务不排队，用时延换容量。

6. 迁移调度：负载均衡与故障转移

• 负载均衡迁移：当个别 Worker 负载显著高于集群均值时，调度器将其上部分空闲 Actor 挂起，调度到低负载 Worker 激活，实现全局资源均衡。
• 故障转移迁移：Worker Pod 或节点异常时，ate-apiserver 秒级检测故障，将该节点所有 Actor 标记为待恢复，从对象存储拉取快照在健康节点重建，RTO 接近亚秒级。

四、超分配水位控制与弹性策略

超卖比并非固定值，而是基于实时负载动态调整：

• 低水位扩容：空闲槽位占比持续低于阈值（如 10%）、驱逐频率升高、激活时延增大时，说明超卖比过高，atecontroller 自动扩容 Worker 池副本数。
• 高水位缩容：空闲槽位占比持续高于阈值（如 30%）时，说明资源冗余，自动缩减 Worker 池规模，提升超卖比。
• 支持基于自定义指标（激活排队数、平均驱逐率、沙箱使用率）的 HPA 式弹性伸缩。

五、与传统 K8s 调度的本质差异

表格

这套调度体系的核心创新，是将云原生调度粒度从 “容器 / Pod” 细化到 “会话状态”，精准匹配了 AI Agent“长会话、低活跃、突发式” 的 workload 特征。

以下给出 WorkerPool 全局检测默认配置、ActorTemplate 业务模板级精细化配置，以及四类典型场景的调优参数，可直接基于开源版本 CRD 规范落地使用。

六、配置层级与生效优先级

Agent Substrate 的空闲检测采用三级配置体系，优先级从高到低为：

1. 实例级 Annotation：单个 Actor 实例单独覆盖，用于关键会话临时豁免
2. 模板级ActorTemplate.spec.runtime.idlePolicy：按业务模板配置，生产环境主要调优层级
3. 全局级WorkerPool.spec.detectionConfig：集群默认兜底值，未配置模板时生效

所有检测逻辑均由节点atelet执行，配置热更新无需重启 Worker 池。

七、标准生产环境完整配置示例

1. WorkerPool 全局检测默认配置

该配置定义集群级检测周期、采集粒度与兜底阈值，适用于所有未单独配置的 Actor 模板。

yaml

apiVersion: substrate.io/v1alpha1 kind: WorkerPool metadata: name: standard-worker-pool spec: replicas: 16 sandbox: gvisor detectionConfig: # 沙箱状态采集周期：百毫秒级平衡精度与节点开销 sampleInterval: 200ms # 全局默认空闲超时（未配置模板时生效） defaultIdleTimeout: 5s # 进程级检测配置 processDetection: enabled: true # 连续多少个采样周期全线程阻塞则判定空闲 consecutiveIdleSamples: 2 # 忽略的后台线程名（正则匹配），避免心跳/日志线程干扰 ignoredThreadPatterns: - ".*heartbeat.*" - ".*logger.*" - ".*gc.*" # 系统资源指标兜底配置 resourceDetection: enabled: true # 滑动窗口大小（采样周期数） windowSize: 5 # 资源阈值，全部满足且持续窗口时间则判定空闲 thresholds: cpuUsagePercent: 5 # 沙箱CPU使用率 < 5% networkPps: 10 # 每秒收发包 < 10 syscallRate: 50 # 每秒系统调用 < 50次 diskIops: 2 # 磁盘IOPS < 2 # 快照缓存策略 snapshotConfig: localCacheEnabled: true localCacheSize: 10Gi

2. ActorTemplate 业务模板级精细化配置

这是生产环境的核心调优单元，针对不同业务特性独立配置三层检测策略，实现精度与成本的平衡。

yaml

apiVersion: substrate.io/v1alpha1 kind: ActorTemplate metadata: name: customer-service-agent spec: image: registry.example.com/copilot-agent:v1.2.0 resourceQuota: cpu: 500m memory: 256Mi runtime: # 核心：空闲检测与超分配策略 idlePolicy: # 总开关：是否启用空闲挂起 suspendOnIdle: true # 最小运行保护：Actor启动后至少运行多久才允许被挂起 # 避免短任务频繁启停，防止抖动 minRunTime: 2s # ========== 第一层：业务主动钩子 ========== activeHook: enabled: true # 业务主动声明空闲后的超时时间（最快回收） # 主动钩子精度最高、零延迟，因此超时设置最短 idleTimeout: 1s # 是否启用预快照：收到空闲通知后后台提前生成增量快照 preSnapshotEnabled: true ========== 第二层：进程级阻塞检测 ========== processDetection: enabled: true # 连续全线程阻塞后的超时时间 idleTimeout: 3s # 覆盖全局的连续空闲采样数 consecutiveIdleSamples: 3 # 额外追加本业务特有的豁免线程 extraIgnoredThreads: - "metrics-exporter" ========== 第三层：资源指标兜底 ========== resourceDetection: enabled: true # 资源持续低于阈值后的超时时间（兜底，设置最长降低误判） idleTimeout: 8s # 覆盖全局阈值，业务个性化调优 thresholds: cpuUsagePercent: 3 networkPps: 5 syscallRate: 30 ========== 驱逐优先级 ========== evictionPriority: medium # low / medium / high high优先级：被动驱逐时最后被选中，保障核心业务</code></pre>

参考文献

项目主仓库 地址：https://github.com/agent-substrate/substrate

这是 Agent Substrate 的唯一官方开源仓库，所有核心实现、CRD 定义、部署脚本均在此仓库中。
官方架构文档站 地址：https://learn.agentsubstrate.dev/

对应仓库内 docs/architecture/ 目录，是官方维护的系统架构、组件交互、核心流程的权威说明，包含控制面、数据面、快照流的完整拆解。