文章目录
如果每个 Agent 都需要一台始终运行的电脑，平台上保留的 Agent 越多，闲置资源就越多。可是，一个等待下周继续工作的 Agent，并不需要在这几天里不断进行推理或占用活跃的工具环境。
brazosd 把“长期存在”与“持续运行”分开考虑。工作记录和数据需要保存，执行推理与工具的资源则可以有自己的生命周期。
先分清三种不同的东西
会话是工作持续发生的上下文，一次运行是 Agent 正在处理某轮任务的过程，沙箱则是执行代码和工具的隔离环境。三者相互关联，但并不相同。
| 层次 | 保存或执行什么 | 生命周期的含义 |
|---|---|---|
| 会话与持久记录 | 对话、执行记录、已保存状态 | 提供继续工作的依据 |
| Agent 运行 | 当前一轮推理和工具协调 | 可以开始、等待、结束或中断 |
| 工作沙箱 | 程序、依赖与工作文件 | 按需要创建、休眠和恢复 |
表格可以左右滑动
因此，浏览器关闭不等于云端运行结束，运行结束也不等于所有文件消失。明确这些边界，平台才能分别管理交互、任务与资源。
“无状态”指执行者，不是没有记忆
无状态运行时容易让人误解为 Agent 每次都失忆。它实际强调的是：关键的工作状态不应只保存在某个执行进程的内存里。
可以把执行者理解为接班的工作人员。只要任务记录、材料和已完成步骤有可靠归属，下一位执行者就能够据此继续处理，而不必永远由同一个进程守着工作。
brazosd 使用持久的会话、运行和事件记录组织 Agent 工作；实时传输让界面看到进度。实时连接负责及时传递，持久记录负责保留依据，两者承担不同职责。
这并不能自动保证所有任务都能从任意位置无损恢复。外部操作是否已经成功、哪些动作可以重试，仍需根据具体任务设计。
沙箱可以睡眠，资料仍需有归属
当前沙箱生命周期区分浅睡眠和深睡眠。浅睡眠暂停现有环境；深睡眠建立检查点并释放远端沙箱，后续再按恢复流程准备环境。
恢复不能被理解为所有进程、内存、登录状态和网络连接都保证回到原样。沙箱快照主要面向文件系统状态，工作应当能够重新检查环境、启动程序并从持久材料继续。
云盘文件、应用数据库与沙箱也有各自的生命周期。恢复一个工作环境不会自动把外部数据库回滚到同一时刻；如果应用需要一致的业务恢复点，就必须另外设计数据恢复方案。
可靠恢复还要面对重复执行
假设程序已向外部系统提交一笔操作，却在记录结果之前失去连接。重新执行时，系统不能仅凭“没有看到成功消息”就断定操作没有发生。
这类问题需要幂等性：同一个业务请求即使重试，也应尽量避免产生重复结果。可以用业务唯一标识、结果查询和明确的事务边界来处理；具体方法取决于目标系统支持什么。
所以，可恢复的 Agent 系统不仅要保存聊天记录，还需要清楚地记录执行状态，理解外部副作用，并在结果不确定时核对事实。休眠解决资源管理，可靠执行解决业务正确性，两者必须一起设计。
为什么这影响平台的经济性
把长期数据与活跃计算分开，平台可以保留大量等待中的工作，而不必让每份工作始终占用同等运行资源。任务密度与活跃程度因此有机会被分别管理。
但休眠不等于所有成本归零。文件、检查点和数据库仍可能占用存储，模型调用、网络和重新启动也有费用或延迟。实际经济性要看资源分配、活跃时间和真实用量。
对非技术读者而言，关键不是“永远在线”的宣传，而是系统能否在需要时恢复工作，并以可理解的方式管理等待成本。
为主动 Agent 和云操作系统提供基础
主动 Agent需要在事件到来时开始工作；UnoZ OS需要让应用和文件超越某一台电脑的寿命。两者都依赖工作状态与执行资源的分离。
这种架构让 Agent 更接近一个持续可用的系统角色：任务有归属，数据能延续，执行环境在需要时参与。它的可靠性来自状态管理与恢复设计，而不只是把一个程序保持运行。