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, portNone): proc subprocess.Popen( cmd, shellTrue, stdoutopen(f/data/workspaces/agent-001/scratch/{name}.log, w), stderrsubprocess.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 协作这些等基础稳了再往上加。我见过太多项目一上来就搞复杂编排结果地基没打牢跑两天就崩。稳扎稳打比什么都强。