1. 从 Manus 2.0 的 Cloud Computer 说起：Agent 为什么需要一个"持久工作环境"
Manus 2.0 这次把 Cloud Computer 推到台前，其实戳中了很多做 Agent 的人心里那根刺。过去一年我陆陆续续搭过七八个不同形态的 Agent 项目，从最简单的单轮工具调用，到带记忆、带多步规划、带子 Agent 编排的复杂系统，踩过的坑基本都指向同一个根因：Agent 的"聪明"程度，往往不是被模型能力卡住的，而是被它的运行环境卡住的。
你想想看，一个 Agent 要完成"帮我把这份季度报告整理成 PPT，顺便把数据图表重画一遍，再发到团队频道"这种任务，它需要什么？需要能读写文件、能跑代码画图、能调用外部接口、能在多轮之间记住自己干到哪了、中途失败了还能接着干。这些能力里，模型只负责"决策"，剩下的全得靠环境兜底。而传统那种"一次请求、一次响应、进程结束就啥都没了"的沙盒，根本撑不起这种长链条任务。
Cloud Computer 这个概念，说白了就是给 Agent 配一台"永远在线、状态不丢、随时能接着干"的云端工作机。它不是一个简单的容器，而是一个持久化的工作环境（Persistent Workspace）：文件系统是活的，进程可以常驻，会话状态能跨轮次保留，Agent 今天没干完的活，明天唤醒它还能从断点继续。这跟过去那种"每次调用都从零开始"的 stateless 沙盒，是两种完全不同的物种。
这篇文章我想聊的不是 Manus 一家的产品评测，而是借这个标题，把"Agent 进化为什么需要持久工作环境"这件事拆开讲透。适合谁看？如果你正在做 Agent 开发、正在纠结沙盒选型、或者被"Agent 跑一半挂了状态全丢"折磨过，那这篇应该能帮你少走点弯路。我会从架构思路、核心细节、实操落地到问题排查，一层层往下扒，尽量把能抄的作业都给你摆出来。
2. 内容整体设计与思路拆解：持久工作环境到底解决了什么
2.1 传统沙盒的三个致命短板
先说说为什么老的方案不够用。我早期做 Agent 的时候，用的是那种"请求进来开一个临时容器，任务结束容器销毁"的模式。听起来很干净，实际上问题一堆。
第一个短板是状态易失。Agent 执行一个多步任务，比如先爬数据、再清洗、再分析、最后出图，中间任何一步因为超时或者异常中断，整个容器一销毁，前面所有中间产物全没了。下次重试又得从第一步爬数据开始，既浪费算力又浪费时间。我遇到过最离谱的一次，一个数据清洗任务跑了四十分钟，最后一步写文件时容器被回收，四十分钟白干。
第二个短板是环境冷启动慢。每次开新容器都要重新装依赖、拉镜像、初始化运行时。如果 Agent 任务本身只需要几秒钟，但环境准备要三十秒，那这个开销就完全不可接受了。尤其是高频调用的场景，冷启动成本会指数级放大。
第三个短板是无法承载长驻进程。有些 Agent 任务需要起一个后台服务，比如跑一个本地的向量检索服务、开一个临时的 Web 服务给用户预览、或者维持一个长连接去监听某个事件流。临时容器根本没法让这些进程活过单次请求的生命周期。
2.2 Cloud Computer 的核心设计哲学
Cloud Computer 的思路正好反过来：把环境当成一个长期存在的"工作台"，而不是一次性的"消耗品"。这个工作台有几个关键特征。
首先是持久化文件系统。Agent 在这个工作台里创建、修改、删除的所有文件，都会真实落盘并保留下来。这意味着 Agent 可以像人一样"昨天写了一半的稿子，今天打开接着写"。文件系统成了 Agent 的外部记忆载体，比塞进上下文窗口的 token 靠谱得多——毕竟上下文有长度限制，而磁盘可以很大。
其次是常驻运行时。工作台里可以跑常驻进程，Agent 可以启动一个服务然后过一会儿再回来查它的状态。这就打开了非常多玩法，比如让 Agent 起一个数据处理管道，边跑边监控，出问题了自己修。
第三是会话与状态可恢复。Agent 的执行上下文、变量、中间结果都能被序列化保存，任务中断后可以从检查点恢复。这一点对长任务至关重要，相当于给 Agent 装了个"存档"功能。
第四是资源隔离与安全边界。虽然环境是持久的，但每个用户、每个任务之间必须有严格的隔离，不能让 A 的 Agent 摸到 B 的文件。这通常靠虚拟化或者轻量级沙盒技术来实现，既要隔离又要保证性能，是个不小的工程挑战。
2.3 为什么说这是 Agent 进化的必经之路
我个人的判断是，Agent 的能力上限，很大程度上取决于它能"记住多少、操作多少、坚持多久"。持久工作环境同时放大了这三个维度。
记忆维度上，文件系统 + 持久状态让 Agent 的"工作记忆"从几万 token 扩展到几乎无限。操作维度上，常驻进程让 Agent 能做的事从"一次性计算"扩展到"持续运营"。坚持维度上，断点恢复让 Agent 能扛住长任务，不会因为一次抖动就前功尽弃。
打个比方，传统沙盒里的 Agent 像是一个每次上班都被清空工位的临时工，而 Cloud Computer 里的 Agent 像是一个有固定工位、有抽屉、有存档的老员工。后者能积累、能沉淀、能处理复杂项目，前者只能打零工。这就是为什么我说，Agent 要从"玩具"进化成"工具"，持久工作环境是绕不过去的一关。
3. 核心细节解析与实操要点：把持久工作环境拆开看
3.1 文件系统持久化：Agent 的外部记忆
文件系统持久化是持久工作环境的地基。实现上，通常有两种路子：一种是给每个工作区挂一个独立的持久卷，容器重启后卷还在；另一种是把文件系统做成网络存储，多个计算节点都能挂载。
我实测下来，对于单 Agent 场景，独立持久卷最简单直接。你只需要在创建沙盒时指定一个 volume，之后所有写入都落在这个卷上。Agent 重启后重新挂载同一个卷，文件原封不动。对于多 Agent 协作场景，网络存储更合适，但要注意并发写入的一致性问题，最好加个文件锁或者用版本控制来协调。
这里有个实操要点：目录结构要提前规划好。我一般会约定几个固定目录，比如/workspace/input放输入、/workspace/output放产出、/workspace/scratch放临时文件、/workspace/state放状态快照。Agent 按约定往里写，后续无论是人工排查还是程序读取，都能快速定位。没有约定的目录结构，跑几天就乱成一锅粥，找文件全靠 grep。
注意：持久卷虽然方便，但一定要设配额和清理策略。我见过 Agent 疯狂写日志把磁盘写满，导致整个工作区不可用的情况。给每个工作区设个软上限，超了就告警或者自动归档旧文件。
3.2 常驻进程管理：让 Agent 能"开服务"
常驻进程是持久工作环境区别于普通沙盒的关键能力。Agent 可以启动一个进程，然后不阻塞地继续干别的，过一会儿再回来查这个进程的状态。
实现上，通常需要一个进程管理器来托管这些常驻进程，负责启动、监控、重启、日志收集。Agent 通过一个控制接口来操作进程，比如"启动一个 Python 服务监听 8080 端口"、"查一下这个进程还活着没"、"把它停掉"。
我踩过的一个坑是僵尸进程。Agent 启动的进程如果没被正确回收，会一直占着资源。所以进程管理器必须能追踪进程树，父进程退出时把子进程一起清理掉。另外，常驻进程的日志要单独收集，不然 Agent 排查问题时看不到输出，等于瞎猜。
还有一个细节是端口管理。多个常驻进程可能抢同一个端口，需要一个端口分配机制，给每个进程分配独立端口并记录映射关系。我一般会让 Agent 启动服务时声明"我需要一个端口"，由环境统一分配，而不是让 Agent 自己写死端口号。
3.3 状态快照与断点恢复：给 Agent 装存档
断点恢复是长任务的生命线。核心思路是：在任务执行的关键节点，把 Agent 的完整状态（包括执行位置、变量、文件系统差异）序列化保存下来。任务中断后，从最近的快照恢复，继续往下跑。
状态快照的粒度是个权衡。太粗，恢复后要重做的多；太细，快照本身开销大。我的经验是，按"逻辑步骤"打快照，比如每完成一个子任务就打一次，而不是按时间或者按代码行。这样恢复的语义最清晰，重做成本也可控。
快照内容一般包括：Agent 的对话历史、当前执行计划的进度、工作区文件系统的增量、常驻进程的状态。恢复时，先把文件系统还原到快照点，再重建进程，最后把 Agent 的上下文恢复到对应位置。
提示：快照不是万能的，有些状态没法序列化，比如正在进行的网络连接、内存里的临时对象。设计 Agent 逻辑时，要尽量把关键状态显式地落到文件或者数据库里，别藏在内存里，否则快照恢复后会丢。
3.4 安全隔离：持久不等于不设防
环境持久了，安全边界反而更重要。因为工作区里可能长期存着敏感数据，一旦隔离没做好，风险比临时沙盒大得多。
隔离一般分几层。计算隔离靠虚拟化或者轻量级沙盒，保证不同工作区的进程互不可见。文件隔离靠独立的存储卷和权限控制，保证 A 摸不到 B 的文件。网络隔离靠网络策略，限制工作区能访问的外部地址，防止 Agent 被诱导去访问不该访问的地方。
我特别想强调的是网络出口管控。Agent 在持久环境里长期运行，如果网络完全放开，一旦被恶意输入诱导，可能做出危险操作。我的做法是默认拒绝所有出站，只放行白名单里的地址，需要访问新地址时显式申请。虽然麻烦点，但安全得多。
4. 实操过程与核心环节实现：从零搭一个持久工作环境
4.1 环境准备与基础选型
假设我们要自己搭一个简化版的持久工作环境，给 Agent 用。基础选型上，我推荐用容器技术做隔离，用持久卷做存储，用进程管理器做常驻进程托管。
先准备一台有足够磁盘和内存的机器。磁盘建议 SSD，因为 Agent 频繁读写文件，IO 性能直接影响体验。内存看并发量，单工作区预留 2G 起步比较稳妥。
基础镜像我一般基于一个精简的 Linux 发行版，预装 Python、Node、常用命令行工具。镜像不要太大，否则冷启动慢。我实测下来，把镜像控制在 500M 以内，启动能压到几秒。
# 拉取基础镜像并创建工作区目录 mkdir -p /data/workspaces/agent-001/{input,output,scratch,state} docker volume create agent-001-vol4.2 工作区初始化与目录约定
工作区创建后，第一件事是把目录结构建好，并写入一份约定说明，让 Agent 知道该往哪写。
# 初始化工作区目录结构 cd /data/workspaces/agent-001 cat > README.md << 'EOF' # 工作区约定 - input/ 输入文件放这里 - output/ 最终产出放这里 - scratch/ 临时文件，可随时清理 - state/ 状态快照，勿手动修改 EOF这份 README 看着简单，但作用很大。Agent 每次启动先读它，就知道工作区的规矩。我试过不给约定，结果 Agent 把产出和临时文件混在一起，清理时误删了重要结果，血的教训。
4.3 启动常驻进程并托管
接下来演示怎么让 Agent 启动一个常驻进程。假设我们要起一个简单的 HTTP 服务，供 Agent 后续查询状态。
# process_manager.py 简化版进程管理 import subprocess import json import os PROCESS_REGISTRY = "/data/workspaces/agent-001/state/processes.json" def start_process(name, cmd, port=None): proc = subprocess.Popen( cmd, shell=True, stdout=open(f"/data/workspaces/agent-001/scratch/{name}.log", "w"), stderr=subprocess.STDOUT ) registry = load_registry() registry[name] = {"pid": proc.pid, "port": port, "cmd": cmd} save_registry(registry) return proc.pid def load_registry(): if os.path.exists(PROCESS_REGISTRY): return json.load(open(PROCESS_REGISTRY)) return {} def save_registry(reg): json.dump(reg, open(PROCESS_REGISTRY, "w"))这个简化版做了三件事：启动进程、记录 PID 和端口、把注册表落到 state 目录。这样即使管理器重启，也能从注册表恢复对进程的追踪。实际生产环境还要加健康检查、自动重启、进程树清理，但核心逻辑就是这个。
4.4 状态快照的实现
快照这块，我用一个简单的方案：把工作区的文件系统差异和 Agent 上下文分别存下来。
# 用 rsync 做文件系统快照（增量） rsync -a --delete /data/workspaces/agent-001/ \ /data/snapshots/agent-001/snap-$(date +%s)/ # Agent 上下文单独存 JSON cat > /data/snapshots/agent-001/context-latest.json << 'EOF' { "step": 3, "plan": ["爬数据", "清洗", "分析", "出图"], "current": "分析", "variables": {"rows": 12000, "cleaned": true} } EOF恢复时，先把文件系统 rsync 回去，再读 context JSON 把 Agent 状态还原。这个方案土是土了点，但胜在简单可靠，小规模场景完全够用。规模大了再上专门的快照系统。
4.5 参数选择与容量估算
搭环境时，几个关键参数得算清楚。磁盘容量：按单任务平均产出 100M、保留 30 天、每天 50 个任务算，大概需要 150G，留一倍余量就是 300G。内存：单工作区常驻进程按 512M 算，加上 Agent 运行时 1G，预留 2G 比较稳。并发数：看机器核数，一般一个工作区占 0.5 核，16 核机器跑 30 个并发工作区问题不大。
这些数字不是拍脑袋，是我实际跑下来总结的经验值。当然具体还得看任务类型，计算密集型的要往上调，IO 密集型的可以往下压。
5. 常见问题与排查技巧实录：那些年踩过的坑
5.1 工作区启动失败类问题
做 Agent 开发的人，大概率都见过类似"failed to start workspace"的报错。这类问题排查起来其实有套路。
先看虚拟化支持。有些环境需要开启虚拟化平台才能跑沙盒，如果宿主机的相关功能没开，工作区根本起不来。这个在 Windows 上尤其常见，需要在系统设置里把虚拟化相关选项打开。排查时先确认底层虚拟化能力是否可用。
再看资源是否够。磁盘满了、内存不够、端口被占，都会导致启动失败。我一般会先df -h看磁盘，free -m看内存，ss -tlnp看端口占用，三板斧下去基本能定位。
最后看镜像和依赖。镜像拉取失败、依赖版本冲突，也会让工作区起不来。这种情况看启动日志最直接，日志里一般会写明卡在哪一步。
5.2 状态丢失与恢复异常
状态丢失是最让人头疼的问题。常见原因有几个：快照没打成功、恢复时文件系统没还原干净、Agent 上下文和文件系统不一致。
我的排查顺序是：先确认快照文件是否存在且完整，再确认恢复流程有没有报错，最后对比恢复后的文件系统和快照记录是否一致。如果发现 Agent 上下文说"分析已完成"但文件系统里没有分析结果，那就是快照和上下文没对齐，需要重新设计快照的原子性。
注意：快照和上下文最好在同一个事务里保存，要么都成功要么都失败。分开保存很容易出现"文件存了但上下文没存"或者反过来，恢复时就错乱了。
5.3 常驻进程失控
常驻进程跑飞了，是另一个高频问题。表现是进程占满 CPU、内存泄漏、或者疯狂写日志把磁盘写爆。
我的应对策略是三重保险：一是给每个进程设资源上限，超了就限制；二是定期健康检查，不健康就重启；三是日志轮转，单个日志文件超过一定大小就切分归档。这三招下去，基本能兜住大部分失控情况。
还有个隐蔽的坑是孤儿进程。父进程被杀了，子进程还在跑。解决方法是启动进程时用进程组，杀的时候杀整个组。Linux 下可以用setsid让进程独立成组，清理时按组杀。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决思路 |
|---|---|---|---|
| 工作区启动失败 | 虚拟化未开/资源不足/镜像问题 | 查虚拟化能力、资源占用、启动日志 | 开启虚拟化、释放资源、修复镜像 |
| 状态恢复后数据错乱 | 快照与上下文不一致 | 对比快照和上下文记录 | 快照与上下文原子化保存 |
| 常驻进程占满资源 | 内存泄漏/死循环 | 看进程资源占用和日志 | 设资源上限、健康检查、日志轮转 |
| 孤儿进程残留 | 父进程退出未清理子进程 | 查进程树 | 用进程组管理，按组清理 |
| 磁盘写满 | 日志或临时文件堆积 | 查磁盘占用大头 | 设配额、日志轮转、定期清理 |
5.5 几个独家避坑心得
第一个心得：给工作区加"心跳"。Agent 定期往 state 目录写一个心跳文件，外部监控看到心跳停了就知道 Agent 挂了，可以触发恢复。这个简单机制能大幅提升系统的可观测性。
第二个心得：文件操作尽量原子化。写文件先写临时文件再 rename，避免写到一半崩溃留下半截文件。Agent 恢复时读到半截文件，很容易做出错误判断。
第三个心得：别把状态藏在内存里。我早期图省事，把 Agent 的中间状态放在内存变量里，结果一恢复全没了。后来强制要求所有关键状态必须落盘，虽然麻烦，但可靠性提升了一个量级。
第四个心得：定期做恢复演练。别等真出事了才第一次用恢复流程，平时就定期模拟中断、走一遍恢复，把流程跑顺。我见过太多团队恢复脚本写了但从没测过，真出事时发现根本跑不通。
6. 从 Cloud Computer 看 Agent 架构的演进方向
聊到这儿，我想再往大了说一层。Cloud Computer 这类持久工作环境的出现，其实反映了 Agent 架构的一个根本转变：从"无状态函数"走向"有状态服务"。
早期的 Agent 更像一个函数，输入问题输出答案，中间过程不保留。这种模式简单，但能力天花板低。现在的 Agent 越来越像一个长期运行的服务，有自己的工作空间、自己的记忆、自己的任务队列。这种转变带来的不只是能力提升，还有一整套工程范式的变化。
比如并发处理。有状态服务扛并发比无状态函数难得多，因为状态要隔离、要同步、要一致。我处理并发时一般用"一个工作区一个 Agent 实例"的模式，实例之间通过消息队列通信，避免共享状态带来的复杂性。这样虽然资源开销大点，但逻辑清晰，不容易出诡异的并发 bug。
再比如可观测性。无状态函数出问题好排查，有状态服务出问题往往牵一发动全身。所以持久工作环境必须配套完善的日志、指标、追踪体系。我一般会给每个工作区打上唯一 ID，所有日志和指标都带上这个 ID，排查时按 ID 一捞，全链路就出来了。
还有生命周期管理。工作区不能只创建不销毁，得有完整的生命周期：创建、使用、休眠、唤醒、归档、销毁。休眠和唤醒尤其重要，不活跃的工作区休眠掉释放资源，需要时再唤醒，能大幅降低成本。我实测下来，加了休眠机制后，资源成本能降一半以上。
回到 Manus 2.0 的 Cloud Computer，它本质上就是在做这些事：给 Agent 一个持久、隔离、可恢复、可观测的工作环境。这个方向我觉得是对的，因为 Agent 要真正干活，就必须有个像样的"工位"。没有工位的 Agent，永远只能打零工，干不了正经项目。
最后分享一个我自己的体会：搭持久工作环境，别一上来就追求大而全。先把文件持久化和状态快照这两个最核心的能力做扎实，让 Agent 能"记住"和"恢复"，这就解决了 80% 的痛点。常驻进程、多 Agent 协作这些，等基础稳了再往上加。我见过太多项目，一上来就搞复杂编排，结果地基没打牢，跑两天就崩。稳扎稳打，比什么都强。
