Agent Substrate 架构解析：面向百万级 Agent 沙箱的高密度挂起/恢复执行运行时

人工智能AI AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载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 术语ActorSubstrate 文档刻意避免直接用agent一词而是用Actor指代一个 agent-like 工作负载的实例。原因在于很多agent-like负载并非真正的 AI Agent用 Actor 一词可以更准确地覆盖这类广义负载。与 Actor 相关的术语还包括AtespaceActor 的隔离边界命名空间Actor 创建于某个 atespace 之内WorkerPool一组温热计算容量的 Kubernetes CRD管理一批待命 Worker PodActorTemplateActor 版本的不可变定义镜像、配置、环境等用于生成黄金快照WorkerWorkerPool 中某个 Worker Pod 的表示IDLE/BUSY 状态及当前托管的 Actorate-api-server / atenet / atelet / ateom控制平面、网络栈、节点 Supervisor 与沙箱 herder详见第 6 节。2.2 将 Actor 生命周期与 WorkerKubernetes Pods解耦因为很多 Agent 运行不可信代码它们必须被放进某种沙箱。Substrate 支持多种沙箱技术其中 gVisor 与 Kata Containers 等 micro-VM 是主流选项而这两者恰好都支持suspend/resume语义——这正是 Substrate 功能的核心。整体思路是Actor 空闲时挂起释放它占用的资源事件到来时恢复把 Actor 重新拉起处理事件避免经过 Kubernetes 调度器的延迟预先启动长期运行的 Worker Pod即等待工作的沙箱事件到达后分配 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 挂起/恢复操作。而基础设施与 WorkerPod的供给属于低频操作恰好契合 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 指标为保持聚焦项目定义了三个北极星指标及目标值指标含义目标激活延迟Activation Latency从收到唤醒事件到 Agent 可接收流量的时间95 百分位100ms规模Scale单集群内可支撑的 Agent 总数含活跃与空闲10 亿吞吐Throughput单集群内每秒可处理的唤醒事件数1000 个/秒值得注意的是项目 READMEREADME.md在介绍当前工程状态时给出的表述是sub-500ms resume operations at over 500 suspend/resume activations per second即当前工程能力与北极星目标之间仍有差距——北极星指标是努力方向而非已达成的事实。4. Personas与系统交互的四类角色集群管理员Cluster admins拥有 Kubernetes 集群、对其整体健康与性能负责的人。当 Substrate 需要更多容量时由他们管理集群自动扩缩、节点供给等。他们很可能很少甚至从不直接与 Substrate 交互。Substrate 管理员Substrate admins在 Kubernetes 集群中搭建并运维 Substrate 实例的人。他们清楚其运行在 Kubernetes 之上负责为它配置 Kubernetes 资源例如 WorkerPool。Agent 开发者Agent developers把 Agent 部署到 substrate 中供用户或上层系统消费的人。他们可能需要意识到底层是 Kubernetes部分概念以 CRD 形式存在如 WorkerPool也可能通过一个本身使用 Substrate 的更高层 API 间接使用。ActorTemplate 通过 substrate APIkubectl-ate管理而非 Kubernetes。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 DesignSubstrate 管理员把 Agent Substrate 部署进 Kubernetes 集群配置用于执行 Actor 的WorkerPool并准备好控制平面。Worker Pod 启动等待任务分配Agent 开发者定义一个ActorTemplateate API 资源描述如何实例化该 Actor运行哪个 OCI 镜像、需要多少内存、行为参数等。Substrate 据此为该 Actor 创建黄金快照golden snapshot用于未来快速启动该 Actor 的实例Agent 用户或上层系统请求实例化一个 Actor指定使用哪个 ActorTemplate 及其他参数。Substrate 在其控制平面存储中创建Actor 记录跟踪该 Actor 的状态挂起或运行中当针对该 Actor 实例的请求到来时Substrate 的proxy拦截请求查询控制平面判断该 Actor 是否在运行若未运行则把它分配到一个 Worker——这涉及通知节点级组件atelet把该 Actor 最近的快照恢复到该节点 Worker 中然后请求被转发给 Actor最终用户或上层系统用完该 Actor或它已空闲一段时间可请求 Substrate 挂起该 Actor拍摄快照、释放 Worker。下次请求到来时再恢复可能落在不同的 Worker 上。6.2 两类资源模型Substrate 按持久化需求与状态转换频率把资源划分为两组1系统配置声明式WorkerPoolKubernetes CRD定义温热计算容量池管理一批已初始化、随时可接收恢复后 Actor 状态的待命 Worker Pod。可选的spec.template字段配置 Worker Pod 的节点选择nodeSelector、容忍tolerations、优先级类priorityClass与节点亲和nodeAffinity。其类型定义见 pkg/api/v1alpha1/workerpool_types.goWorkerPoolSpec包含必填的replicasWorker Pod 数量、workerImage作为 Worker 部署的 ateom 容器镜像以及可选的templateWorkerPoolPodTemplate其中NodeAffinity映射到 Pod 的spec.affinity.nodeAffinity与sandboxClass默认gvisor可选microvm。ActorTemplateate API 资源Actor 版本的不可变定义封装了生成黄金快照所需的容器镜像、配置与环境。通过 substrate gRPC API例如kubectl ate create actor-template创建与管理存储在控制平面状态存储中不是 Kubernetes 对象。其 proto 定义见 pkg/proto/ateapipb/ateapi.proto包含worker_selector限制该模板 Actor 可用的 WorkerPool、containersOCI 镜像须以 digest 固定、volumesDurableDir/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动态实例状态基于数据库ActorActorTemplate 的一个具体实例。Actor 记录跟踪其全局唯一标识、物理位置Worker IP、当前状态RUNNING 或 SUSPENDED及版本相关的状态元数据WorkerWorkerPool 中某个 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为恢复请求选择一个就绪 Workercmd/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 节点 Supervisorateletateom节点级子系统负责沙箱的实际执行与快照的移动atelet运行在每个节点上的轻量级 SupervisorDaemonSet扮演牧羊人Herder管理一批物理 Pod 并与控制平面通信。实现位于 cmd/ateletateom专用的沙箱 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 用runscmicro-VM 用 Kata Cloud Hypervisor 栈。注意gVisor 后端目前需要一个带--allow-connected-on-save标志的runsc版本以绕开 checkpoint 期间网络恢复的一个 bug。atelet与ateom之间的协议定义见 internal/proto/ateletpb/atelet.protoAteomHerderservice 提供Run、Checkpoint、Restore、Terminate、UploadPausedCheckpoint等 RPC存储移动器Storage Moveratelet将快照流式传输到 GCS/S3确保进程状态在集群内持久且可移植。7.3 沙箱类别Sandbox ClassesWorkerPool 通过spec.sandboxClass选择沙箱类别每个类别有对应的 ateom herder 镜像。沙箱二进制本身不烘焙进 Worker 镜像——它们与承载沙箱命名空间的 pause 镜像在运行时来自集群范围的SandboxConfigActorTemplate 在其 sandbox config 中命名当前必须命名一个按类别的集群默认值正在规划并被钉入每个快照的 manifest 中从而保证在运行时升级后恢复的可复现性。gVisorateom-gvisor默认在runsc下运行负载以获得内核级沙箱。挂起/恢复利用 gVisor 原生的沙箱进程树 checkpoint/restoremicro-VMateom-microvm在 Kata Containers guest运行于 Cloud Hypervisor VMM 之上内运行负载。挂起/恢复捕获仅内存memory-only的 VM 快照并使用userfaultfd内存按需分页在需要时恢复。容器 rootfs 写入由宿主机后端支撑overlay 在宿主机上组装只读 OCI 镜像 lower 层加每 Actor 可写 upper 层通过单个 virtio-fs share 提供给 guest因此它们消耗的是可回收的宿主页缓存而非 guest RAMFull快照把 upper 层作为独立 tar 打包。DurableDir卷通过同一 share 传输同样以 tar 形式打包因此Data范围快照可在不捕获任何 guest 内存的情况下捕获它们。每个卷是 share 的一个子目录一个 Actor 可以挂多个卷而不额外增加设备这正是 micro-VM 类别解除了 gVisor 仍保留的单DurableDir限制的原因。7.4 网络栈atenetatunnel负责 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头仍是应用权威不用于选择 ActorWorker 隧道解析分配后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的引用调用CreateActorActor 在数据库中以ACTOR_STATE_SUSPENDED状态注册记录被初始化携带元数据与**黄金快照Version 0**引用源自关联的 ActorTemplate。这保证 Actor 在首次请求到来时能被瞬时水合hydrated进一个温热 Worker。8.3 阶段二激活ResumeActor由 Gateway 处的入站请求或显式 API 调用触发触发Gateway 暂停请求向控制平面查询 Actor 的位置分配控制平面从WorkerPool认领一个温热 Worker水合ateletSupervisor 与 Worker Pod 内的ateom进程协作把 ActorTemplate 的黄金外部快照首次运行或 Actor 自身的外部快照重复运行恢复到沙箱中状态状态转为ACTOR_STATE_RUNNINGActor 获得活跃的 Worker IP响应控制平面把 Worker 分配返回给 GatewayGateway 打开到该 Worker 上atunnel的认证隧道把原始请求转发给活跃的 Actor。8.4 阶段三休眠SuspendActor由显式SuspendActor调用触发Checkpointatelet指示ateom冻结进程并捕获内存磁盘快照持久化atelet把快照从 Pod 流式传输到持久存储如 GCS回收物理 Worker 被擦除并归还WorkerPool释放该 Actor 在本次挂起前持有的外部快照从对象存储中删除。一个 Actor 同时只持有一个快照若它借用了某个 tag 的快照则不动它——因为 tag 才是所有者状态状态回到ACTOR_STATE_SUSPENDEDActor 的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 区分两种状态当前在单个带版本号的快照中一并捕获内存快照Memory Snapshot进程的精确 RAM 状态工作卷/磁盘Working Volume/Disk写入容器可写层即工作记忆的文件。当前实现中内存与磁盘状态都绑定到特定版本的代码ActorTemplate以保证恢复期间的严格一致性。快照持久存储在Google Cloud StorageGCS中。该模型允许 Actor 空闲时WorkerPool中的物理计算资源被完全回收而不会丢失任何进程或文件系统进度。在快照语义上协议层还定义了更细的粒度见 pkg/proto/ateapipb/ateapi.proto 中的SnapshotContentScopeFULL捕获进程内存、rootfs 变更与持久数据DATA只捕获持久数据不含进程内存与 rootfs 变更。ActorTemplate 的snapshots_config可以分别配置on_pausepause 时的捕获范围默认 FULL与on_commitsuspend 时的捕获范围须为 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以及本地LOCALpause 时节点本地与外部EXTERNAL对象存储两种 checkpoint 类型。10. 安全与隔离Defense-in-DepthSubstrate 建立在**纵深防御Defense-in-Depth**模型上沙箱化执行每个 Actor 都运行在加固的内核空间隔离层如 gVisor内防止容器逃逸Actor 身份每次交互都由一个 Substrate 管理的唯一身份驱动该身份独立于底层硬件。即使 Actor 在物理节点或代码版本之间迁移也能保持自己细粒度的权限与安全上下文请求授权系统目前执行身份感知路由Identity-Aware Routing——在 Gateway 提取并校验ate-target-actor头确保请求只路由到已识别、已注册的 Actor。可插拔的细粒度授权策略规划在未来的里程碑中网络策略Substrate 利用标准 Kubernetes NetworkPolicy 做连通性控制。策略可应用在WorkerPool边界限制该池内所有 Actor 的入站/出站流量处处 mTLSmTLS Everywhere所有内部系统通信如控制平面到 Atelet均通过短期证书的互 TLS 保护。atelet的协议注释也印证了这一点ate-api-server与atelet之间、ateom与atelet之间的调用都以 Kubernetes Pod 身份的 mTLS 证书认证见 internal/proto/ateletpb/atelet.proto。11. 相关文档与进一步阅读docs/api-guide.mdWorkerPool、ActorTemplate、Secrets、Volumes 的详细配置参考含 SandboxConfig 的完整说明docs/authentication.md可信 JWT 提供方与人类凭据的配置docs/glossary.mdActor、Atespace、ActorTemplate、WorkerPool、Worker、ate-api-server、atenet、atelet、ateom 等核心术语docs/observability.mdActor 日志、指标与分布式追踪docs/egress-traffic.md 与 docs/egress-trust-bundle.mdActor 出站协议约束与 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 AgentAgent 沙箱云原生容器运行时零信任【免费下载链接】substrateAgent Substrate: the core system项目地址https://gitcode.com/GitHub_Trending/substrate7/substrate点击查看免费下载相关推荐Agent Substrate Sandbox Demo 实战指南在 Kubernetes 上构建可挂起/恢复的有状态沙箱执行环境Agent Substrate Sandbox Demo 实战指南在 Kubernetes 上构建可挂起/恢复的有状态沙箱执行环境 本文档深入讲解 Agent人工智能AI AgentAgent 沙箱云原生容器运行时零信任在 KubeRay 中使用 Ray Agent Sandbox 实现沙箱化代码执行与按轮挂起/恢复在 KubeRay 中使用 Ray Agent Sandbox 实现沙箱化代码执行与按轮挂起/恢复 本指南完整演示如何在 GKE gVisor 环境下人工智能分布式训练强化学习任务调度模型推理服务后端Agent Substrate 路线图深度解读从核心架构决策到高密度 Agent 运行时演进方向Agent Substrate 路线图深度解读从核心架构决策到高密度 Agent 运行时演进方向 Agent Substrate 是一个面向大规模 Agent人工智能AI AgentAgent 沙箱云原生容器运行时零信任创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考