胡伟煌 – Agent Substrate

Kubernetes-Notes: Agent Substrate 架构解析

Sat, 31 Oct 2026 18:30:00 +0000

Agent Substrate 不是用来开发 Agent 的框架，而是用来安全、高密度地运行 Agent 和 Sandbox 的基础设施运行时。

项目地址：agent-substrate/substrate（GitHub）

它主要解决一个问题：如果一个平台要为大量用户分别创建独立的 AI Agent 执行环境，如何同时实现安全隔离、状态持久化、快速唤醒和资源复用？

结合 Kubernetes 的视角，可以把它理解为：在 Pod 和容器之上，为有状态、间歇性运行的 Agent 增加一层专用的调度与执行管理系统。

1. 为什么需要 Agent Substrate？

传统 Kubernetes 部署通常是一个应用对应一个或多个 Pod。但 AI Agent 的工作模式有些特殊：

用户发起任务后，Agent 执行推理、调用工具或运行代码。
调用大模型、等待用户输入时，Agent 可能长时间处于空闲状态。
Agent 往往需要保留运行时内存、文件系统和会话状态。
Agent 执行的代码可能不可信，需要严格的安全隔离。

如果每个用户的 Agent 都长期占用一个独立的 Pod，就可能浪费大量资源；如果任务到来时才创建 Pod，又可能引入调度和启动延迟。

1.1. 核心思路：Actor 与 Worker 解耦

这里最重要的是两个概念：

Actor：逻辑上的一个 Agent 实例，具有自己的身份、状态和生命周期。
Worker：实际承载 Actor 的执行资源，通常由预先启动的 Kubernetes Pod 提供。

多个 Actor 可以共享一组 Worker 的计算资源，但同一时刻实际执行的 Actor 仍然需要相应的执行容量。空闲 Actor 可以被挂起并保存状态，需要继续执行时再恢复。

这与传统的“一份 Agent 对应一个长期运行的 Pod”是不同的资源管理模型。

1.2. 核心组件与 Kubernetes 对应关系

从源码和架构文档来看，Agent Substrate 的主要组件可以这样理解。

组件 / 概念	作用	Kubernetes 视角
`ActorTemplate`	定义 Actor 的运行镜像、资源及运行参数	类似工作负载模板，但不是 Deployment
`Actor`	一个具体的、有状态的运行实例	不等于 Pod，生命周期独立于 Worker
`WorkerPool`	管理可用于执行 Actor 的 Worker 容量	类似执行资源池
`Worker`	真正承载沙箱执行环境	通常由 Kubernetes Pod 承载
`Atespace`	Actor 的租户与命名空间边界	类似逻辑租户隔离，不能简单等同于 Namespace
`ate-api-server`	处理 Actor、Worker 生命周期等控制请求	专用控制面
`atelet`	节点级监督、快照和状态迁移	类似节点 Agent / DaemonSet
`atenet`	负责网络路由与代理等功能	类似专用数据面与网络控制组件
`kubectl-ate`	通过命令行管理 Substrate 资源	类似 `kubectl` 的扩展工具

注意：这些是帮助理解的类比，不代表它们与 Kubernetes 原生资源一一对应。

可以把它理解为：

ActorTemplate 决定“这个 Sandbox 运行什么”。
Actor 决定“这是哪个用户或任务的独立运行实例”。
WorkerPool 决定“实际执行资源从哪里来”。
SandboxConfig 决定“使用哪个沙箱运行时版本”。
Snapshot 决定“挂起后如何保留和恢复状态”。

2. Substrate的部署架构

从部署视角看，可以分成五层：

层次	主要组件	作用
API 与控制面	ate-api-server	Actor 生命周期、调度、快照编排
Kubernetes 管理层	atecontroller、CRD	将 WorkerPool 等资源转换成实际 Kubernetes 工作负载
节点管理层	atelet	节点上的 Worker 管理、镜像准备、快照传输
Sandbox 执行层	Worker Pod、ateworker/ateom、gVisor 或 MicroVM	真正运行 Actor
网络与存储层	atenet、atunnel、PostgreSQL、对象存储	请求转发、身份认证、状态和快照持久化

2.1. 部署的k8s 工作负载

下面是按组件整理的部署清单。具体 Pod 数量、容器组合和名称会随版本、安装选项变化。

工作负载	K8s 类型	部署位置
ate-api-server	Deployment	ate-system
atecontroller	Deployment	ate-system
atelet	DaemonSet	ate-system
atenet	Deployment / 相关代理工作负载	ate-system
podcertcontroller	Deployment	证书控制器命名空间
ate-idp-server	Deployment	ate-system
PostgreSQL	StatefulSet 或外部数据库	ate-system 或外部
Worker	Deployment 管理的 Pod	Worker 节点
ateom / ateworker	Worker 内部容器	Worker Pod
atunnel	Worker 内部网络服务	Worker Pod
Object Store Plugin	Sidecar	相关组件 Pod

这里有个容易误解的地方：ateom、atunnel 不一定是独立的 Kubernetes Deployment，它们属于 Worker 内部的运行组件。Object Store Plugin 也可能以 Sidecar 方式运行，而不是单独部署一个集群级服务。

2.2. 外部基础设施依赖

除了 Substrate 自身组件，还需要准备外部基础设施。

依赖	作用	是否必要
Kubernetes	承载所有组件和 Worker Pod	必须
PostgreSQL	保存 Actor、Worker 等控制面状态	必须
对象存储（GCS/S3）	保存 Actor 快照、模板快照	持久化快照场景必须
节点本地存储	缓存运行时资源、快照文件	需要
gVisor 或 MicroVM 环境	提供 Sandbox 隔离运行时	必须至少选择一种
Pod 证书能力	提供内部身份认证和 mTLS	按部署版本和配置要求
凭据提供服务	为 Actor 的出站请求注入受控凭据	按功能配置

这里尤其要区分 PostgreSQL 和对象存储：

PostgreSQL 保存的是 Actor 的元数据和状态，不是 Actor 的完整内存。
对象存储保存的是 Actor 的快照文件。
atelet 负责节点与对象存储之间的快照传输。

官方架构还包含 Object Store Plugin，用来为快照上传、下载和资源缓存提供统一的对象存储接口。

2.3. 实际部署顺序

从零部署时，我建议按以下依赖顺序理解。

准备 Kubernetes 集群

准备节点、网络、存储、证书 API，以及 Worker 所需的运行时能力。
准备外部基础设施

部署 PostgreSQL、对象存储、IAM / Workload Identity 等。
部署 Kubernetes 扩展能力

安装 Substrate CRD、证书相关组件、podcertcontroller。
部署控制面

安装 ate-api-server、atecontroller。
部署节点管理组件

安装 atelet DaemonSet。
部署网络组件

安装 atenet、Router、相关隧道和代理能力。
创建 WorkerPool

选择 gVisor 或 MicroVM，配置 Worker 数量和资源。
创建 ActorTemplate

配置 Actor 镜像、资源限制、快照存储位置等。
创建 Actor 并验证

创建 Actor，验证启动、访问、Suspend、Resume。

3. 核心组件及功能

2.1 控制面组件【ate-api-server】

这是 Substrate 的核心控制面，主要负责：

提供 gRPC API，供 CLI、上层 Agent 平台调用。
创建、删除和管理 Actor。
管理 ActorTemplate、Atespace、Tag 等资源。
维护 Actor 与 Worker 的映射关系。
选择可用 Worker，完成 Actor 调度。
编排 Actor 的 Suspend、Resume、Checkpoint、Restore。
进行 API 身份认证和权限校验。

它的内部主要包含三个逻辑部分：

内部模块	功能
State Store	保存 Actor、Worker 状态及映射关系
Scheduler	选择可用 Worker
Workflow Engine	编排 Actor 暂停、恢复等多步骤操作

部署形态： Kubernetes Deployment。

它不直接运行 Agent，也不直接操作底层 Sandbox，而是通过节点管理组件协调执行。

2.2 Kubernetes Controller【atecontroller】

这是 Substrate 与 Kubernetes 之间的桥梁。

主要负责：

Watch Substrate 定义的 Kubernetes CRD。
监听 WorkerPool 的创建、修改和删除。
根据 WorkerPool 配置创建或更新 Kubernetes Deployment。
维护 Worker Pod 的期望状态。

例如，创建一个 WorkerPool：

apiVersion: ate.dev/v1alpha1
kind: WorkerPool
metadata:
  name: gvisor-pool
spec:
  replicas: 10

Controller 负责将它转换为实际运行的 Worker Pod。

部署形态： Kubernetes Deployment。

注意：ActorTemplate 并不是 Kubernetes CRD，它通过 Substrate API 管理；WorkerPool 才是 Kubernetes 侧管理的资源。

2.3 节点管理组件【atelet】

atelet 是运行在 Kubernetes Node 上的节点级管理进程。

它主要负责：

监听和管理当前节点上的 Worker。
准备 Sandbox 需要的镜像和运行时资源。
组装 OCI Bundle。
调用 Worker 内部的管理进程执行 Sandbox 启动。
协调 Actor 的 Checkpoint 和 Restore。
将快照上传到对象存储，或从对象存储下载快照。
管理节点本地的 Sandbox Asset Cache。

它是整个数据面的重要执行协调者。

部署形态： Kubernetes DaemonSet。

也就是说，符合调度条件的每个 Node 都会运行一个 atelet。

2.4 Worker 内部管理组件【ateom / ateworker】

这是运行在 Worker Pod 内部的 Sandbox 管理进程。

不同版本和文档中使用过 ateworker、ateom 这些名称。当前架构文档使用 ateom 描述这一层的职责。

它主要负责：

接收 atelet 下发的操作。
创建和管理 Actor 对应的 Sandbox。
调用底层 Sandbox Runtime。
执行 RunWorkload、CheckpointWorkload、RestoreWorkload。
管理 Actor 的网络连接。
通过内部网络服务 atunnel 转发 Actor 流量。

它与 atelet 的关系是：

组件	所在位置	主要职责
atelet	Kubernetes Node	管理节点上的 Worker，协调生命周期和快照
ateom	Worker Pod 内	具体操作 Sandbox，驱动运行时
atunnel	Worker 内部网络服务	接收经过认证的流量并转发给 Actor

部署形态： Worker Pod 内的容器或管理进程，具体由 WorkerPool 选择的 Sandbox 类型决定。

2.5 Sandbox Runtime

Substrate 需要真正提供隔离执行环境的底层 Runtime。

目前主要有两种运行时实现：

2.5.1. gVisor

使用用户态内核提供系统调用隔离。
由 runsc 执行 Sandbox 的创建、Checkpoint 和 Restore。
相比完整虚拟机，运行开销通常更低。
是 Substrate 默认使用的隔离运行时之一。

2.5.2. MicroVM

使用轻量级虚拟机提供隔离。
当前实现使用 Cloud Hypervisor。
Worker 需要具备相应虚拟化能力。
适合需要更强虚拟化隔离边界的场景。

对应的 Worker 管理程序包括：

ateworker-gvisor
ateworker-microvm

注意：不能直接把普通 runc 容器当作 Substrate 已支持的 Sandbox Runtime。Substrate 的设计依赖运行时支持的 Checkpoint/Restore 能力。

2.6 网络组件【atenet】

atenet 是 Substrate 的网络组件集合，负责 Actor 流量入口、路由和网络隔离。

主要包括：

组件	功能
atenet-controller	管理网络相关配置和代理工作负载
atenet-router	Envoy 网关，接收 Actor 请求并进行路由
atunnel	Worker 内部隧道服务，将请求转发到 Actor

其中 atenet-router 是一个非常重要的组件。

例如，上层 Agent 平台访问某个 Actor：

POST /execute HTTP/1.1
Host: agent.example.com
ate-target-actor: demo/my-agent

路由过程：

Router 识别请求中的 Actor 标识。
调用 ate-api-server 查询 Actor 状态。
如果 Actor 已暂停，则触发 Resume。
Control Plane 分配 Worker。
atelet 和 Worker 内部管理进程恢复 Actor。
Router 与 Worker 的 atunnel 建立认证隧道。
atunnel 将请求转发到 Actor。

这样，上层应用不需要知道 Actor 当前在哪个 Worker 上。

2.7 身份认证组件【podcertcontroller】

这是 Kubernetes Pod 证书签发控制器。

主要负责：

为 Substrate 组件提供短期证书。
为组件提供可验证的身份。
支持内部服务之间的 mTLS 通信。
为 Actor 运行环境提供身份认证基础。

部署形态： Kubernetes Deployment 或相应控制器工作负载。

此外，还有：

ate-idp-server

负责提供 OpenID Connect Discovery 文档和 JWKS 公钥信息，供依赖方验证 Actor JWT。

它与 podcertcontroller 不是同一个东西：

podcertcontroller：解决 Pod 及内部组件的证书身份问题。
ate-idp-server：提供 JWT 验证所需的身份提供方元数据。

Kubernetes-Notes: 部署 Substrate Sandbox

Sat, 07 Nov 2026 10:30:00 +0000

本文主要描述在已经部署好 Agent Substrate 的 Kubernetes 集群上执行的完整示例。

先创建一个简单的 HTTP Sandbox Actor，验证完整链路：

Atespace → WorkerPool → ActorTemplate → Actor → Resume → 访问 → Suspend

这里有一个容易忽略的地方：Atespace、ActorTemplate、Actor 是通过 Substrate API 管理的逻辑资源，不是 Kubernetes CRD；WorkerPool 和 SandboxConfig 才是 Kubernetes 资源。因此不能全部使用 kubectl apply 创建。

0. 检查 Substrate 是否部署正常

先检查核心组件：

kubectl get pods -n ate-system
kubectl get crd | grep -E 'workerpools|sandboxconfigs'

检查 Substrate CLI：

kubectl ate get atespaces
kubectl ate get workers

如果本地还没有 kubectl ate：

go install github.com/agent-substrate/substrate/cmd/kubectl-ate@latest

注意：CLI 版本尽量与集群部署的 Substrate 版本保持一致。

1. 创建 Atespace【租户】

先创建 Kubernetes Namespace：

kubectl create namespace demo-space

现在创建 Substrate 逻辑隔离空间：

kubectl ate create atespace demo-space

查看：

kubectl ate get atespace demo-space

#示例
ATESPACE       NAME            TEMPLATE                  STATE                 WORKER POD                    WORKER IPS   VERSION   AGE
demo-space   ate-demo-actor   ate-demo/demo-template   ACTOR_STATE_RUNNING   ate-demo/demo-68c995676b-f7tmn   1.1.1.1     3         39h

注意这里有两个同名对象：

对象	所属系统	作用
Namespace `demo-space`	Kubernetes	WorkerPool 等 K8s 资源的命名空间
Atespace `demo-space`	Substrate	Actor 的逻辑隔离空间

它们不是同一个对象，只是为了方便示例使用了相同名称。注意执行ate的参数指定atespace 是用参数-a而不是-n。

2. 创建 WorkerPool【资源池】

这是创建 Actor 之前最重要的准备工作。

WorkerPool 是 Kubernetes CRD，负责提供可以承载 Actor 的 Worker Pod。可以理解为资源池。

创建 workerpool.yaml：

apiVersion: ate.dev/v1
kind: WorkerPool
metadata:
  name: demo-pool
  namespace: demo-space
  labels:
    workload: demo-agent
spec:
  replicas: 2

  # 必须使用与当前 Substrate 部署版本匹配的 Worker 镜像
  workerImage: <你的 ateworker-gvisor 镜像>

  sandboxClasses:
    - name: gvisor

  template:
    resources:
      limits:
        cpu: "2"
        memory: 2Gi
      requests:
        cpu: 500m
        memory: 2Gi

这里的 workerImage 不能随意填写。应该使用你当前 Substrate 安装时使用的 ateworker-gvisor 镜像，确保版本一致。

应用：

kubectl apply -f workerpool.yaml

检查：

kubectl get workerpool -n demo-space

kubectl get pods -n demo-space -w

预期有两个 Worker Pod 逐渐变成 Running。

WorkerPool 有几个重要概念：

配置	含义
replicas	预热 Worker 的数量
workerImage	Worker 内部管理程序的镜像
sandboxClasses	支持的 Sandbox Runtime
template.resources	Worker Pod 的资源配置
metadata.labels	供 ActorTemplate 的 workerSelector 选择

这里要特别注意：WorkerPool 的资源限制决定 Worker 可承载的容量；ActorTemplate 的资源限制决定单个 Actor 申请的资源。两者不是同一个概念。

3. 创建 ActorTemplate【Sandbox模板】

ActorTemplate 用来定义 Actor 运行什么程序、使用什么资源、使用什么 Sandbox Runtime，以及如何保存快照。

这一步需要准备一个容器镜像。

这里推荐直接使用一个自己构建的 HTTP 服务镜像，假设它具有以下行为：

容器启动后监听 80 端口。
GET /readyz 返回 HTTP 200。
GET / 返回 Hello from Agent Substrate。
工作目录为 /workspace。

假设你的镜像为：

registry.example.com/agent/demo-server:v1

创建 actor-template.yaml：

metadata:
  atespace: demo-space
  name: demo-template

# 选择前面创建的 WorkerPool
workerSelector:
  matchLabels:
    workload: demo-agent

containers:
  - name: agent
    image: registry.example.com/agent/demo-server:v1

    ports:
      - containerPort: 80

    wakeupProbe:
      httpGet:
        path: /readyz
        port: 80

    volumeMounts:
      - name: workspace
        mountPath: /workspace

resources:
  limits:
    cpuMillicores: 1000
    memoryBytes: 1073741824

snapshotConfig:
  storageLocation: gs://YOUR_BUCKET/agent-substrate/demo-space/

sandboxConfig:
  sandboxClass: SANDBOX_CLASS_GVISOR
  configName: gvisor-default

volumes:
  - name: workspace
    durableDir: {}

需要替换：

registry.example.com/agent/demo-server:v1：替换成你自己的镜像。
gs://YOUR_BUCKET/...：替换成当前 Substrate 对象存储插件支持的快照存储路径。这里沿用官方 GCS 示例；如果你部署的是其他存储后端，要使用对应支持的 URI。
gvisor-default：确保集群里存在对应的 SandboxConfig。

关于几个关键字段：

字段	作用
metadata.atespace	ActorTemplate 所属的 Atespace
metadata.name	模板名称
workerSelector	选择具有对应标签的 WorkerPool
containers	Actor 内部运行的容器
resources	Actor 的资源申请
wakeupProbe	恢复后判断服务是否就绪
snapshotConfig	配置快照策略和存储位置
sandboxConfig	选择 Sandbox Runtime
durableDir	Actor 独立的持久化数据目录

这里使用 durableDir，是为了让 /workspace 中的数据能够在 Actor Suspend/Resume 后保留。

关于快照：当前示例重点是持久化工作目录。如果你还要求进程内存状态也恢复，需要根据当前 Substrate 版本配置相应的完整内存快照策略。

官方 Counter Demo 提供了完整的 gVisor、DurableDir 和内存快照配置，可以作为进一步参考 substrate/demos/counter。

创建模板：

kubectl ate create actor-template -f actor-template.yaml

查看：

kubectl ate get actor-templates -a demo-space

查看具体模板：

kubectl ate get actor-template demo-template \
  -a demo-space \
  -o yaml

# status 输出
status:
  goldenSnapshotStatus:
    goldenTag:
      atespace: ate-golden
      name: 0afe4a06-1432-424e-9e9c-ca60bb991a17
    takeGoldenSnapshotAt: "2026-10-31T11:34:52.168080494Z"

注意

ActorTemplate 创建后，Substrate 默认会创建 Golden Snapshot。Golden Snapshot 是模板的初始快照，不是你创建的每个 Actor 的独立快照。

需要等待模板初始化完成，再创建 Actor。检查模板状态以及 Golden Tag 是否已经生成。

4. 创建 Actor【sandbox逻辑实例】

现在终于可以创建 Actor 了。actor 是sandbox的逻辑实例，类似一个轻量型虚拟机，初始化是未开机状态。

kubectl ate create actor my-agent-001 \
  -a demo-space \
  --template demo-template

这里：

参数	含义
my-agent-001	Actor 名称
-a demo-space	Actor 所属 Atespace
--template demo-template	使用哪个 ActorTemplate

查看 Actor：

kubectl ate get actors -a demo-space

查看具体 Actor：

kubectl ate get actor my-agent-001 \
  -a demo-space \
  -o yaml

这里要注意：

创建 Actor 并不等于立即启动 Actor。

CreateActor 主要是在 Substrate 控制面注册一个逻辑 Actor，真正分配 Worker 和恢复 Sandbox 需要执行 Resume，或者通过 Router 的请求触发自动恢复。

5. 启动 Sandbox【Resume Actor】

执行：

kubectl ate resume actor my-agent-001 \
  -a demo-space

这时候 Substrate 会完成大致如下流程：

kubectl ate resume actor

查看 Actor 状态：

kubectl ate get actor my-agent-001 \
  -a demo-space \
  -o yaml

查看 Worker：

kubectl ate get workers

# 输出
NAME                                   POOL                   STATE                 ACTORS   CPU   MEMORY    POD                                                              AGE
978b42b3-8bed-4b8c-a1b0-957c5b343f76   demo-pool        WORKER_STATE_ACTIVE   0/1      0/1   0/2Gi     ate-demo-pool/demo-pool-68c995676b-2nrvm             39h
009b30f6-e170-43a0-9b5d-7cfe236e9e9f   demo-pool        WORKER_STATE_ACTIVE   1/1      1/1   1Gi/2Gi   ate-demo-pool/demo-pool-68c995676b-f7tmn             39h
fef5851c-52b1-4805-b7b0-c86af3d53143   demo-pool        WORKER_STATE_ACTIVE   0/1      0/1   0/2Gi     ate-demo-pool/demo-pool-68c995676b-kcwnz             39h

你应该能看到一个 Worker 被分配给 demo-space/my-agent-001。

6. 通过 Router 访问 Actor

Substrate 不要求你直接访问 Worker Pod IP。

通过 atenet-router 访问：

先转发 Router：

kubectl port-forward \
  -n ate-system \
  svc/atenet-router 8000:80

另外打开一个终端：

curl -i \
  -H "ate-target-actor: demo-space/my-agent-001" \
  http://localhost:8000/

预期：

HTTP/1.1 200 OK

Hello from Agent Substrate

这里最重要的是：

ate-target-actor: demo-space/my-agent-001

它告诉 Router 应该把请求路由到哪个 Actor。

Router 不需要知道 Actor 当前在哪一个 Worker Pod 上。

7. 暂停sandbox【Suspend Actor】

这是 Substrate 最值得验证的功能。

先在 Actor 工作目录中创建一个文件：

# 这里假设你的 demo-server 提供了文件操作接口
# 或者通过你自己的 Actor 命令接口写入文件

然后暂停 Actor：

kubectl ate suspend actor my-agent-001 \
  -a demo-space

查看状态：

kubectl ate get actor my-agent-001 \
  -a demo-space


# 示例
ATESPACE       NAME             TEMPLATE               STATE                   WORKER POD   WORKER IPS   VERSION   AGE
demo-space   ate-demo-actor   ate-demo/demo-template   ACTOR_STATE_SUSPENDED   <none>                    5         39h

此时 Actor 应该进入 SUSPENDED 状态，并释放原来占用的 Worker。

kubectl ate get workers
# 输出
NAME                                   POOL                   STATE                 ACTORS   CPU   MEMORY    POD                                                              AGE
978b42b3-8bed-4b8c-a1b0-957c5b343f76   demo-pool        WORKER_STATE_ACTIVE   0/1      0/1   0/2Gi     ate-demo-pool/demo-pool-68c995676b-2nrvm             39h
009b30f6-e170-43a0-9b5d-7cfe236e9e9f   demo-pool        WORKER_STATE_ACTIVE   0/1      0/1   0/2Gi   ate-demo-pool/demo-pool-68c995676b-f7tmn             39h
fef5851c-52b1-4805-b7b0-c86af3d53143   demo-pool        WORKER_STATE_ACTIVE   0/1      0/1   0/2Gi     ate-demo-pool/demo-pool-68c995676b-kcwnz             39h

再次访问：

curl -i \
  -H "ate-target-actor: demo-space/my-agent-001" \
  http://localhost:8000/

Router 会触发 Actor 恢复，然后将请求转发到新的执行位置。

你可以再查看：

kubectl ate get actor my-agent-001 \
  -a demo-space \
  -o yaml

kubectl ate get workers

这就完成了 Actor 的创建、启动、访问、暂停和恢复。

8. 完整创建流程汇总

如果前面的准备工作都完成了，后续日常创建 Actor 主要就是下面这些命令：

# 1. 创建 Kubernetes Namespace
kubectl create namespace demo-space

# 2. 创建 WorkerPool
kubectl apply -f workerpool.yaml

# 3. 创建 Atespace
kubectl ate create atespace demo-space

# 4. 创建 ActorTemplate
kubectl ate create actor-template -f actor-template.yaml

# 5. 等待 Golden Snapshot 就绪
kubectl ate get actor-templates -a demo-space

# 6. 创建 Actor
kubectl ate create actor my-agent-001 \
  -a demo-space \
  --template demo-template

# 7. 启动 Actor
kubectl ate resume actor my-agent-001 \
  -a demo-space

# 8. 查看 Actor
kubectl ate get actor my-agent-001 -a demo-space

# 9. 查看 Worker
kubectl ate get workers

# 10. 暂停 Actor
kubectl ate suspend actor my-agent-001 \
  -a demo-space

# 11. 删除 Actor
kubectl ate delete actor my-agent-001 \
  -a demo-space

参考：

https://github.com/agent-substrate/substrate/tree/main/demos