Actor 删除之后发生了什么Agent Substrate 快照垃圾回收现状与规划全解析【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrateAgent Substrate 是面向 Agent 的高密度沙箱执行运行时。当你删掉一个 Actor 后它留在对象存储里的快照内存 磁盘状态并不会自动消失。本文带你梳理Agent Substrate 中Actor 删除的完整流程、快照垃圾回收snapshot garbage collection现状以及 Roadmap 里规划的自动清理能力帮你彻底理解这套系统的状态生命周期。为什么删 Actor不只是删一条记录在 Agent Substrate 里一个Actor是 ActorTemplate 派生出的运行实例。它的状态分为两类内存快照Memory Snapshot进程精确的 RAM 状态工作卷 / 磁盘Working Volume容器可写层里的文件两者被打包成一个版本化快照持久化在对象存储GCS 或 S3中。也就是说每个 Actor 背后可能挂着几百 MB 甚至几 GB 的快照数据。因此删除 Actor本质上要回答两个问题控制面里的记录如何干净地移除对象存储里的快照字节如何回收Actor 删除的完整流程现状删除入口在控制面的 DeleteActor 工作流中整个过程是幂等的可分七步步骤做什么关键方法① 标记删除把 Actor 与其卷置为DELETINGensureMarkedDeleting② 终止负载通知节点上的 atelet 结束沙箱进程ensureAteletTerminated③ 解挂卷卸载外部卷ensureVolumesDetachedForDelete④ 释放 Worker把 Worker 归还到 WorkerPoolensureWorkerReleased⑤ 删卷删除 Actor 的外部卷ensureVolumesDeleted⑥ 释放快照删除对象存储里 Actor 的快照前缀ensureExternalSnapshotsReleased⑦ 收尾从数据库删除记录finalizeDeleted关键设计尽力而为 可重试。任何一步失败都会把错误返回给调用方重试而 Actor 记录会留在库里保持DELETING状态等待下次重试补齐。这正是快照垃圾回收现状的核心——清理依赖工作流被反复驱动而不是一个独立的后台 GC 进程。快照垃圾回收是怎么做的现状快照回收的具体动作在 ensureExternalSnapshotsReleased先通过 actorSnapshotStoragePrefix 算出这个 Actor 自己写过的所有对象的前缀——包括它上一次拍的快照、悬停中写到一半的快照以及崩溃时遗留的快照。再调用对象存储的 DeletePrefix把这个前缀下的对象逐个删掉并发 8。这里有一条精妙的所有权规则一个 Actor同一时间只拥有一个它自己的快照。如果快照是从某个 Tag 借来的Tag 是快照的保留锁见 架构文档 Phase 3它归 Tag 所有不会随 Actor 删除而被删。换句话说Tag 比 Actor 活得久被 Tag 固定的快照会留存。当前的边界与缺口诚实地说Agent Substrate 目前没有独立的快照垃圾回收器。清理逻辑内联在删除工作流里且源码留下了明确的 TODO// TODO: Ensure GC collects all the remaining resources if the cleanup fails.—— workflow_delete.go由此暴露出几个现实缺口⚠️失败残留若清理中途失败且不再重试对象存储里可能残留孤儿快照。⚠️无后台 GC没有周期性扫描哪些前缀已无人引用的机制。⚠️无 TTL / 保留策略快照缺少存活多久后自动回收的概念。这些正是 Roadmap 要补的部分。未来规划从 Roadmap 看垃圾回收的下一步docs/roadmap.md 里有几项直接对应当前缺口存储StoragePolicies to drive retention of old snapshots and controller(s) to do automated cleanups即引入快照保留策略并配套一个控制器做自动清理。Actor 管理ComputeAutomated Garbage Collection: Background cleanup of idle actors based on configurable TTL即按可配置 TTL对空闲 Actor 做后台自动垃圾回收。生命周期澄清Clarify the actor lifecycle, including what data is retained across which events即明确哪些事件会保留哪些数据让快照保留变得可预期。整体方向是把删除时顺带清理升级为策略驱动的、控制器化的、带 TTL 的自动 GC。新手上手如何观察一次 Actor 删除用 kubectl-ate 触发删除再观察控制面的状态流转即可。参考 架构文档 Phase 4: Deletion默认只有ACTOR_STATE_SUSPENDED或ACTOR_STATE_CRASHED状态的 Actor 可被删除。打开any_state标志后任意状态含RUNNING、PAUSED都能直接删——工作流会先终止容器、解挂卷、释放 Worker再删记录。删除成功后Actor 的快照状态即被垃圾回收。小结✅现状Actor 删除时的快照回收内联在幂等工作流里按前缀删除清理对象存储并尊重 Tag 的所有权。✅可靠性靠尽力而为 重试保证最终一致失败会停在DELETING状态等待重试。规划Roadmap 已明确要引入保留策略 后台 GC 控制器 TTL让快照垃圾回收从顺手清理走向自动治理。理解这一层你就抓住了 Agent Substrate 状态生命周期管理的关键计算资源靠 Worker 快速复用而真正的垃圾回收战场在对象存储里的快照。【免费下载链接】substrateAgent Substrate: the core system项目地址: https://gitcode.com/GitHub_Trending/substrate7/substrate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
