企业官网建设流程全解析

• 人工智能
• AI Agent
• Agent 沙箱
• 云原生
• 容器运行时
• 零信任

Agent Substrate（下称 Substrate）是一个默认安全（secure-by-default）的 Agent 执行运行时，其核心目标是把"数量庞大的 Actor（即 agent-like 应用实例）"映射到"数量较小的常驻 Worker"上，通过内核级的 suspend/resume 实现 10x 以上的密度提升与亚秒级激活。本文以仓库 docs/architecture.md 为骨架，结合 CRD 类型定义、gRPC 协议与工作流实现源码，完整讲解其设计动机、资源模型、系统组件、Actor 生命周期与安全模型，读完你将掌握 Substrate 如何在 Kubernetes 之上构建一套低延迟、高并发的 Actor 专用控制平面。

前置说明：docs/architecture.md开篇即注明"Much of this architecture is aspirational, and is not yet implemented"，本文所述内容以当前仓库实际代码为准，读者可对照文中给出的源码路径自行验证。

1. 概述：一个为"空闲型"负载而生的运行时

Substrate 的设计起点是一个朴素的观察：Agent 类负载具有极强的突发性（bursty）。它们绝大多数时间在等待输入或事件，收到事件后短暂处理，然后再次回到等待状态。真正干活的时间往往极短，而等待时间却可能无限长。与此同时，由于它们经常运行不可信逻辑，通常需要放进沙箱，因此往往是单租户实例，且数量极其庞大——这带来一个直接的效率灾难：大量空闲 Pod 白白占用 CPU、内存和节点配额。

Substrate 的答案是"多路复用（multiplexing）"：用一组较小的、预先启动好的 Worker Pod（即等待工作的沙箱），承载数量大得多的 Actor。其提供的核心能力包括：

• Actor 生命周期管理（create/destroy、suspend/resume）；
• 实时把 Actor 分配到 Worker；
• 将入站流量路由到对应的 Actor。

这种设计让"一个 Actor 空闲时就挂起（释放资源），事件到来时再恢复（resume）"成为可能，从而在保持低延迟的同时获得更高的密度与效率。项目定位是**低意见（low-opinion）**系统：它管理的负载不一定是字面意义上的 AI Agent，但 AI Agent 正是它为之设计的最佳示例；它不是构建 Agent 的 SDK，而是"大规模运行 Agent 的系统"。

2. 核心概念与方法

2.1 术语："Actor"

Substrate 文档刻意避免直接用"agent"一词，而是用Actor指代一个 agent-like 工作负载的实例。原因在于：很多"agent-like"负载并非真正的 AI Agent，用 Actor 一词可以更准确地覆盖这类广义负载。与 Actor 相关的术语还包括：

• Atespace：Actor 的隔离边界（命名空间），Actor 创建于某个 atespace 之内；
• WorkerPool：一组"温热"计算容量的 Kubernetes CRD，管理一批待命 Worker Pod；
• ActorTemplate：Actor 版本的不可变定义（镜像、配置、环境等），用于生成"黄金快照"；
• Worker：WorkerPool 中某个 Worker Pod 的表示（IDLE/BUSY 状态及当前托管的 Actor）；
• ate-api-server / atenet / atelet / ateom：控制平面、网络栈、节点 Supervisor 与沙箱 herder（详见第 6 节）。

2.2 将 Actor 生命周期与 Worker（Kubernetes Pods）解耦

因为很多 Agent 运行不可信代码，它们必须被放进某种沙箱。Substrate 支持多种沙箱技术，其中 gVisor 与 Kata Containers 等 micro-VM 是主流选项，而这两者恰好都支持suspend/resume语义——这正是 Substrate 功能的核心。

整体思路是：

1. Actor 空闲时挂起：释放它占用的资源；
2. 事件到来时恢复：把 Actor 重新拉起处理事件；
3. 避免经过 Kubernetes 调度器的延迟：预先启动长期运行的 Worker Pod（即等待工作的沙箱）；
4. 事件到达后分配 Worker：在 Worker 内恢复该 Actor。

由此，大量 Actor 被多路复用到少量 Worker 上，实现更高密度与效率，同时显著降低延迟。在 cmd/ateapi/internal/controlapi 目录下，可以看到workflow_resume.go、workflow_suspend.go、workflow_pause.go、workflow_delete.go、workflow_revert.go、workflow_tag.go等实现文件，它们正是这套生命周期工作流（workflow）的服务端落地。

2.3 聚焦的控制平面

Substrate 包含一个小而专注的控制平面组件，聚焦于高规模、高 QPS、低延迟的 Actor 挂起/恢复操作。而基础设施与 Worker（Pod）的供给属于低频操作，恰好契合 Kubernetes 在基础设施生命周期管理与工作负载资源隔离上的强项，因此交给 Kubernetes 控制平面负责。这种"分工"是整个架构的核心思想，详见第 5 节"与 Kubernetes 的关系"。

2.4 Agent-Aware 路由

要实现按需恢复 Actor，就必须能够拦截并检查网络流量。Substrate 因此包含一个轻量级的、substrate 感知的网络代理（atenet-router），它检查入站流量并在必要时触发 Actor 的恢复。流量路径的细节见 6.4 节。

2.5 新问题：这些方法带来的权衡

"天下没有免费的午餐"，上述方法有明确代价：

• 海量数据管理：大规模 suspend/resume 引入了庞大的状态存储问题——需要存储数以百万计 Actor 的状态，且状态可能每秒更新多次。Substrate 必须把**数据局部性（data locality）**作为一等公民考虑：事件到来时，需要知道 Actor 最新状态存在哪里，然后把事件路由过去，或把状态迁移到事件可被服务的位置。
• 生产级控制平面的构建成本：新的控制平面组件必须高可用、安全、高性能，并且与 Kubernetes 良好集成，这是不容小觑的工作量。
• 可观测性与调试难度：Actor 频繁地在 Worker 上被多路复用（挂上/取下），理解系统正在发生什么变得更困难。Substrate 需要提供健壮的监控与调试工具：把 Actor 随时间变化的指标与日志串联起来、检查挂起 Actor 的状态、追踪导致其当前状态的事件链。

2.6 尚未解决的问题

项目尚处于早期，以下问题明确已知但尚未开始解决：

• 自动扩缩容：需要按需自动扩缩 Worker 数量，Kubernetes Pod 自动扩缩可能够用、也可能不够；
• 点对点状态共享：依赖数据局部性存在数据丢失风险，可能需要某种状态共享机制来防护，并与"永久存储"方案做平衡；
• 控制平面认证/授权（authn/z）：需要确保只有被授权的用户和 Agent 能与控制平面交互（当前ate-api-server已实现调用者认证，但授权尚未实现，见 docs/authentication.md）；
• 身份与策略：Agent 的身份需求与传统工作负载身份、终端用户凭据差异很大；
• 此外还有更多尚未想到的问题。

3. North Star 指标

为保持聚焦，项目定义了三个北极星指标及目标值：

值得注意的是，项目 README（README.md）在介绍当前工程状态时给出的表述是"sub-500ms resume operations at over 500 suspend/resume activations per second"，即当前工程能力与北极星目标之间仍有差距——北极星指标是努力方向，而非已达成的事实。

4. Personas：与系统交互的四类角色

1. 集群管理员（Cluster admins）：拥有 Kubernetes 集群、对其整体健康与性能负责的人。当 Substrate 需要更多容量时，由他们管理集群自动扩缩、节点供给等。他们很可能很少甚至从不直接与 Substrate 交互。
2. Substrate 管理员（Substrate admins）：在 Kubernetes 集群中搭建并运维 Substrate 实例的人。他们清楚其运行在 Kubernetes 之上，负责为它配置 Kubernetes 资源（例如 WorkerPool）。
3. Agent 开发者（Agent developers）：把 Agent 部署到 substrate 中供用户或上层系统消费的人。他们可能需要意识到底层是 Kubernetes（部分概念以 CRD 形式存在，如 WorkerPool），也可能通过一个本身使用 Substrate 的更高层 API 间接使用。ActorTemplate 通过 substrate API（kubectl-ate）管理，而非 Kubernetes。
4. Agent 用户（Agent users）：与 substrate 中运行的 Agent 交互的人。他们可能是构建在 Substrate 之上应用的终端用户，也可能是把 Substrate 当作构建模块的上层系统。他们完全不需要感知 Kubernetes 的存在。

5. 与 Kubernetes 的关系：为什么需要专用控制平面

Kubernetes 是现代工作负载的事实标准平台，能支撑非常大规模的集群。Substrate 利用 Kubernetes 做基础设施供给与 Worker 生命周期管理（Kubernetes Pods），并构建在 Pods、Pod 自动扩缩等能力之上；同时，Substrate 提供 Agent 专用的调度与控制以达成更低延迟。使用 Kubernetes 作为底层系统，可以在所有"端到端 agentic 部署"所需的工作负载类型间保持一致的基础设施管理，并为横跨 agentic、推理与训练周期的 RL 场景提供整体性的基础设施优化。

那么，**为什么还需要一个专门的控制平面？**文档给出了四个理由：

• 空闲 Pod 依然消耗资源：Kubernetes 虽然可扩展性很强，但计算容量是有限且有真实成本的。无论是 CPU 时间、内存空间，还是每节点 Pod 数量，agent-like 负载对效率都是灾难性的；
• Kubernetes API Server 不是为百万级资源设计的：它擅长在许多控制器之间异步地调谐资源，却不擅长存储海量离散资源、或处理海量写流量；
• 调度延迟不可接受：在 Kubernetes 上调度一个工作负载需要多个异步流程收敛、多次网络跳转、镜像拉取等步骤。当 Pod 会运行数小时或数天时，"几秒内拉起一个 Pod"很棒；但对只运行几毫秒到几秒的负载，这种延迟不可接受；
• 状态管理困难：Kubernetes 提供 PersistentVolumes API 管理状态，但它不是为"数百万个卷、数据量差异巨大、以高速率挂载/卸载"的场景设计的。

因此，Substrate 用专用控制平面管理 Actor，实现高规模、低延迟控制；同时仍然依赖 Kubernetes 做 Worker Pod 等基础设施供给与工作负载隔离——这正是 Kubernetes 擅长的事。

6. 高层设计与 API 资源模型

6.1 高层工作流程（High-Level Design）

1. Substrate 管理员把 Agent Substrate 部署进 Kubernetes 集群，配置用于执行 Actor 的WorkerPool，并准备好控制平面。Worker Pod 启动，等待任务分配；
2. Agent 开发者定义一个ActorTemplate（ate API 资源），描述如何实例化该 Actor：运行哪个 OCI 镜像、需要多少内存、行为参数等。Substrate 据此为该 Actor 创建"黄金快照（golden snapshot）"，用于未来快速启动该 Actor 的实例；
3. Agent 用户（或上层系统）请求实例化一个 Actor，指定使用哪个 ActorTemplate 及其他参数。Substrate 在其控制平面存储中创建Actor 记录，跟踪该 Actor 的状态（挂起或运行中）；
4. 当针对该 Actor 实例的请求到来时，Substrate 的proxy拦截请求，查询控制平面判断该 Actor 是否在运行；若未运行，则把它分配到一个 Worker——这涉及通知节点级组件atelet把该 Actor 最近的快照恢复到该节点 Worker 中，然后请求被转发给 Actor；
5. 最终，用户（或上层系统）用完该 Actor，或它已空闲一段时间，可请求 Substrate 挂起该 Actor：拍摄快照、释放 Worker。下次请求到来时再恢复，可能落在不同的 Worker 上。

6.2 两类资源模型

Substrate 按"持久化需求"与"状态转换频率"把资源划分为两组：

（1）系统配置（声明式）

• WorkerPool（Kubernetes CRD）：定义"温热"计算容量池，管理一批已初始化、随时可接收恢复后 Actor 状态的待命 Worker Pod。可选的spec.template字段配置 Worker Pod 的节点选择（nodeSelector）、容忍（tolerations）、优先级类（priorityClass）与节点亲和（nodeAffinity）。其类型定义见 pkg/api/v1alpha1/workerpool_types.go：WorkerPoolSpec包含必填的replicas（Worker Pod 数量）、workerImage（作为 Worker 部署的 ateom 容器镜像），以及可选的template（WorkerPoolPodTemplate，其中NodeAffinity映射到 Pod 的spec.affinity.nodeAffinity）与sandboxClass（默认gvisor，可选microvm）。
• ActorTemplate（ate API 资源）：Actor 版本的不可变定义，封装了生成"黄金快照"所需的容器镜像、配置与环境。通过 substrate gRPC API（例如kubectl ate create actor-template）创建与管理，存储在控制平面状态存储中，不是 Kubernetes 对象。其 proto 定义见 pkg/proto/ateapipb/ateapi.proto：包含worker_selector（限制该模板 Actor 可用的 WorkerPool）、containers（OCI 镜像，须以 digest 固定）、volumes（DurableDir/ExternalVolume/SystemInfo/Image 四类来源）、snapshots_config（快照策略）与sandbox_config（选择沙箱运行时，必填）。
• 与之配套的还有SandboxConfig（集群级 CRD）：提供沙箱二进制（如 gVisor 的 runsc、micro-VM 的内核/固件/配置）与 pause 镜像，按架构（GOARCH）与资产名组织，通过 SHA256 内容寻址。ActorTemplate 通过sandbox_config.config_name引用它（当前必填；按类别的集群默认值已在规划中）。类型定义见 pkg/api/v1alpha1/sandboxconfig_types.go。

（2）动态实例状态（基于数据库）

• Actor：ActorTemplate 的一个具体实例。Actor 记录跟踪其全局唯一标识、物理位置（Worker IP）、当前状态（RUNNING 或 SUSPENDED）及版本相关的状态元数据；
• Worker：WorkerPool 中某个 Worker Pod 的表示，跟踪其唯一标识、当前状态（IDLE 或 BUSY）以及当前托管的 Actor（若有）。

这两类资源都存储在**高性能、低延迟的状态存储（PostgreSQL）**中以支撑实时操作。架构文档中的 UML 类图（Mermaid）完整描述了二者的关系：

6.3 双层模型的架构合理性（Architectural Rationale）

• 可扩展性（Scalability）：把百万级 Actor 的高频、高规模管理卸载到专用状态存储，避免以每秒数千次更新的流量压垮集群主控制平面；
• 延迟（Latency）：实现 100ms 级恢复需要低延迟的状态查询与原子化的 Worker 分配，绕开标准 Kubernetes API Server 的最终一致性与可变延迟；
• 治理（Governance）：把基础设施资源（WorkerPools、SandboxConfigs）保留为 Kubernetes 对象，让平台团队可以对底层基础设施应用熟悉的 RBAC、审计与策略执行；而工作负载定义（ActorTemplates）改由 substrate API 管理，由该 API 自行认证调用者（授权尚未实现，见 docs/authentication.md）。

7. 系统组件详解

7.1 控制平面（ate-api-server）

系统的"大脑"，对外暴露 gRPC API 供数据面与 CLI 管理 Actor 生命周期，实现位于 cmd/ateapi。其内部组成（对应 cmd/ateapi/internal 下的子包）：

• 状态存储（State Store）：在 PostgreSQL 存储中跟踪 Actor 到 Worker 的映射（internal/store）；
• 调度器（Scheduler）：为恢复请求选择一个就绪 Worker（cmd/ateapi/internal/scheduling/scheduling.go）；
• 工作流引擎（Workflow Engine）：编排多步骤的 Resume/Suspend 序列——锁获取、存储下载、沙箱恢复（cmd/ateapi/internal/controlapi 下的workflow_resume.go、workflow_suspend.go、workflow_pause.go、workflow_delete.go、workflow_revert.go、workflow_tag.go等）。

gRPC 服务接口定义在 pkg/proto/ateapipb/ateapi.proto 的Controlservice：包括CreateActor、UpdateActor、SuspendActor、PauseActor、ResumeActor、RevertActor、DeleteActor、CreateTag/DeleteTag/PublishTag、Worker 生命周期管理（CreateWorker、DrainWorker、DeleteWorker等）、CreateAtespace与 ActorTemplate 管理等一系列 RPC。Actor 的状态机由ActorState枚举定义：RESUMING、RUNNING、SUSPENDING、SUSPENDED、PAUSING、PAUSED、CRASHED、DELETING、REVERTING。

7.2 节点 Supervisor（atelet+ateom）

节点级子系统负责沙箱的实际执行与快照的移动：

• atelet：运行在每个节点上的轻量级 Supervisor（DaemonSet），扮演"牧羊人（Herder）"，管理一批物理 Pod 并与控制平面通信。实现位于 cmd/atelet；
• ateom：专用的沙箱 herder 容器镜像——每种沙箱类别一个（ateom-gvisor、ateom-microvm）——运行在物理 Worker Pod 内部。它为atelet提供 gRPC 接口以触发RunWorkload、CheckpointWorkload、RestoreWorkload操作。这种分离确保物理 Pod 的生命周期与沙箱化的 Agent 进程解耦。实现位于 cmd/ateom-gvisor 与 cmd/ateom-microvm；
• 生命周期管理：ateom进程调用沙箱运行时在物理 Pod 边界内做 checkpoint/restore——gVisor 用runsc，micro-VM 用 Kata + Cloud Hypervisor 栈。（注意：gVisor 后端目前需要一个带--allow-connected-on-save标志的runsc版本，以绕开 checkpoint 期间网络恢复的一个 bug。）atelet与ateom之间的协议定义见 internal/proto/ateletpb/atelet.proto：AteomHerderservice 提供Run、Checkpoint、Restore、Terminate、UploadPausedCheckpoint等 RPC；
• 存储移动器（Storage Mover）：atelet将快照流式传输到 GCS/S3，确保进程状态在集群内持久且可移植。

7.3 沙箱类别（Sandbox Classes）

WorkerPool 通过spec.sandboxClass选择沙箱类别，每个类别有对应的 ateom herder 镜像。沙箱二进制本身不烘焙进 Worker 镜像——它们与承载沙箱命名空间的 pause 镜像在运行时来自集群范围的SandboxConfig（ActorTemplate 在其 sandbox config 中命名；当前必须命名一个，按类别的集群默认值正在规划），并被钉入每个快照的 manifest 中，从而保证在运行时升级后恢复的可复现性。

• gVisor（ateom-gvisor，默认）：在runsc下运行负载以获得内核级沙箱。挂起/恢复利用 gVisor 原生的沙箱进程树 checkpoint/restore；
• micro-VM（ateom-microvm）：在 Kata Containers guest（运行于 Cloud Hypervisor VMM 之上）内运行负载。挂起/恢复捕获仅内存（memory-only）的 VM 快照，并使用userfaultfd内存按需分页在需要时恢复。容器 rootfs 写入由宿主机后端支撑：overlay 在宿主机上组装（只读 OCI 镜像 lower 层加每 Actor 可写 upper 层），通过单个 virtio-fs share 提供给 guest，因此它们消耗的是可回收的宿主页缓存而非 guest RAM；Full快照把 upper 层作为独立 tar 打包。DurableDir卷通过同一 share 传输，同样以 tar 形式打包，因此Data范围快照可在不捕获任何 guest 内存的情况下捕获它们。每个卷是 share 的一个子目录，一个 Actor 可以挂多个卷而不额外增加设备，这正是 micro-VM 类别解除了 gVisor 仍保留的单DurableDir限制的原因。

7.4 网络栈（atenet+atunnel）

负责 Actor 感知的路由与自动"再激活（re-animation）"，实现在 cmd/atenet（其internal/router即 Envoy 路由控制器）：

• Ingress 路由：atenet-router运行带ext_proc外部处理器的 Envoy。上层系统连接到路由器，并在ate-target-actor头中以<atespace>/<actor>形式提供 Actor 目标。ext_proc 调用控制平面恢复该 Actor 并解析其当前 Worker 分配。Host头仍是应用权威，不用于选择 Actor；
• Worker 隧道：解析分配后，atenet-router打开一条到 Worker 上atunnel监听器（端口 443）的认证 TLS 隧道。atunnel由ateom托管，通过 Actor 的私有 veth 接口把请求转发给活跃的 Actor。Worker Pod 的 80 端口不是直接的 Actor 入口路径；
• 任意端口入口：客户端想访问 Actor 上非默认端口（非 80）时，使用 HTTPCONNECT请求在 authority 中指定端口（例如CONNECT <actor-dns>:9090），而非单独的头或字段。atenet-router在专用监听器上终止CONNECT，并把隧道流量重新引入与普通请求相同的入口路径——因此长生命周期隧道内的每个请求仍会独立地恢复 Actor，并在 Actor 迁移 Worker 时独立地重新路由。目前只支持隧道上的 HTTP(S) 流量；非默认端口上的原始 TCP 或其他非 HTTP 协议尚不可达；
• 延迟：数据面通过绕开 Kubernetes 的最终一致性、执行原子化的物理分配，为亚 100ms 激活做了优化。

8. Actor 生命周期

8.1 生命周期时序

一个请求通过网络栈到达 Actor，若其处于挂起状态则被恢复到某个 Worker 上。架构文档给出的 UML 时序图如下：

Actor 的state按以下状态机流转（架构文档中的 UML 状态图）：

8.2 阶段一：创建（CreateActor）

用户或框架以唯一 ID 和对ActorTemplate的引用调用CreateActor：

• Actor 在数据库中以ACTOR_STATE_SUSPENDED状态注册；
• 记录被初始化：携带元数据与**黄金快照（Version 0）**引用（源自关联的 ActorTemplate）。这保证 Actor 在首次请求到来时能被瞬时"水合（hydrated）"进一个温热 Worker。

8.3 阶段二：激活（ResumeActor）

由 Gateway 处的入站请求或显式 API 调用触发：

1. 触发：Gateway 暂停请求，向控制平面查询 Actor 的位置；
2. 分配：控制平面从WorkerPool认领一个温热 Worker；
3. 水合：ateletSupervisor 与 Worker Pod 内的ateom进程协作，把 ActorTemplate 的黄金外部快照（首次运行）或 Actor 自身的外部快照（重复运行）恢复到沙箱中；
4. 状态：状态转为ACTOR_STATE_RUNNING，Actor 获得活跃的 Worker IP；
5. 响应：控制平面把 Worker 分配返回给 Gateway，Gateway 打开到该 Worker 上atunnel的认证隧道，把原始请求转发给活跃的 Actor。

8.4 阶段三：休眠（SuspendActor）

由显式SuspendActor调用触发：

1. Checkpoint：atelet指示ateom冻结进程并捕获内存+磁盘快照；
2. 持久化：atelet把快照从 Pod 流式传输到持久存储（如 GCS）；
3. 回收：物理 Worker 被擦除并归还WorkerPool；
4. 释放：该 Actor 在本次挂起前持有的外部快照从对象存储中删除。一个 Actor 同时只持有一个快照；若它借用了某个 tag 的快照则不动它——因为 tag 才是所有者；
5. 状态：状态回到ACTOR_STATE_SUSPENDED，Actor 的status.externalSnapshot指向其恢复时将使用的外部快照。

此外，快照可以被赋予tag——由 Atespace 拥有并寻址的不可变别名与保留钉（retention pin）。同一个 tag 名可以存在于不同 Atespace。tag 持有自己的外部快照副本（创建时制作），因此比创建它的 Actor 活得更久；发布（publish）后可从其他 Atespace 复用，且不改变其atespace/name地址。删除 tag 会删除那份副本；拥有 tag 的 Atespace 在 tag 被删除前无法删除。

8.5 阶段四：删除（DeleteActor）

默认情况下，只有ACTOR_STATE_SUSPENDED或ACTOR_STATE_CRASHED状态的 Actor 能从控制平面删除。开启any_state标志后，任何状态的 Actor（如RUNNING或PAUSED）都可直接删除：工作流先终止 Worker 上运行的容器、卸载已挂载的卷、释放 Worker 分配，再删除记录。删除后，Actor 的状态（即内存+磁盘快照）被垃圾回收。

9. 状态管理与持久化

Substrate 区分两种状态，当前在单个带版本号的快照中一并捕获：

1. 内存快照（Memory Snapshot）：进程的精确 RAM 状态；
2. 工作卷/磁盘（Working Volume/Disk）：写入容器可写层（即"工作记忆"）的文件。

当前实现中，内存与磁盘状态都绑定到特定版本的代码（ActorTemplate），以保证恢复期间的严格一致性。快照持久存储在Google Cloud Storage（GCS）中。该模型允许 Actor 空闲时WorkerPool中的物理计算资源被完全回收，而不会丢失任何进程或文件系统进度。

在快照语义上，协议层还定义了更细的粒度（见 pkg/proto/ateapipb/ateapi.proto 中的SnapshotContentScope）：FULL捕获进程内存、rootfs 变更与持久数据；DATA只捕获持久数据（不含进程内存与 rootfs 变更）。ActorTemplate 的snapshots_config可以分别配置on_pause（pause 时的捕获范围，默认 FULL）与on_commit（suspend 时的捕获范围，须为 on_pause 的子集），并通过on_resume配置恢复来源——COLD_BOOT（从 OCI 镜像冷启动、以快照预填 durable-dir 卷）或GOLDEN（用模板黄金快照加 Actor 自身持久数据恢复）。对应地，atelet侧的 checkpoint/restore 协议（internal/proto/ateletpb/atelet.proto）定义了SNAPSHOT_SCOPE_FULL、SNAPSHOT_SCOPE_DATA与仅用于恢复的SNAPSHOT_SCOPE_DATA_ON_GOLDEN，以及本地（LOCAL，pause 时节点本地）与外部（EXTERNAL，对象存储）两种 checkpoint 类型。

10. 安全与隔离（Defense-in-Depth）

Substrate 建立在**纵深防御（Defense-in-Depth）**模型上：

• 沙箱化执行：每个 Actor 都运行在加固的内核空间隔离层（如 gVisor）内，防止容器逃逸；
• Actor 身份：每次交互都由一个 Substrate 管理的唯一身份驱动，该身份独立于底层硬件。即使 Actor 在物理节点或代码版本之间迁移，也能保持自己细粒度的权限与安全上下文；
• 请求授权：系统目前执行身份感知路由（Identity-Aware Routing）——在 Gateway 提取并校验ate-target-actor头，确保请求只路由到已识别、已注册的 Actor。可插拔的细粒度授权策略规划在未来的里程碑中；
• 网络策略：Substrate 利用标准 Kubernetes NetworkPolicy 做连通性控制。策略可应用在WorkerPool边界，限制该池内所有 Actor 的入站/出站流量；
• 处处 mTLS（mTLS Everywhere）：所有内部系统通信（如控制平面到 Atelet）均通过短期证书的互 TLS 保护。atelet的协议注释也印证了这一点：ate-api-server与atelet之间、ateom与atelet之间的调用都以 Kubernetes Pod 身份的 mTLS 证书认证（见 internal/proto/ateletpb/atelet.proto）。

11. 相关文档与进一步阅读

• docs/api-guide.md：WorkerPool、ActorTemplate、Secrets、Volumes 的详细配置参考（含 SandboxConfig 的完整说明）；
• docs/authentication.md：可信 JWT 提供方与人类凭据的配置；
• docs/glossary.md：Actor、Atespace、ActorTemplate、WorkerPool、Worker、ate-api-server、atenet、atelet、ateom 等核心术语；
• docs/observability.md：Actor 日志、指标与分布式追踪；
• docs/egress-traffic.md 与 docs/egress-trust-bundle.md：Actor 出站协议约束与 MITM 拦截配置；
• docs/request-parking.md：路由器在 WorkerPool 饱和时停放请求的机制；
• docs/upgrade.md：在不丢失 Actor 状态的情况下逐节点滚动升级；
• docs/threat-model.md：信任边界、假设与已知风险；
• README.md：快速上手（hack/create-kind-cluster.sh、hack/install-ate-kind.sh）与各 Demo 入口；
• demos/counter/README.md：用 Counter Demo 复现"约 250 个有状态 Actor 复用到 8 个物理 Pod"的多路复用演示。

提醒：README 明确该项目仍处于早期开发阶段，尚不适合生产使用，API 几乎必然变化，现阶段不做任何向后兼容性保证——阅读与使用本文所述能力时请以仓库当前代码为准。

• 人工智能
• AI Agent
• Agent 沙箱
• 云原生
• 容器运行时
• 零信任