Agent持久工作环境实战：Cloud Computer的Workspace与Sandbox设计

1. 从 Manus 2.0 的 Cloud Computer 说起：Agent 为什么需要一个“持久工作环境”

Manus 2.0 这次把 Cloud Computer 推到台前，其实戳中了很多做 Agent 的人心里那根刺。过去一年我折腾过不少 Agent 项目，从最简单的单轮工具调用，到多 Agent 协作、带记忆的长期任务，踩过的坑基本都指向同一个问题：Agent 的“脑子”越来越聪明，但它的“身体”一直是临时的。每次任务启动，它都像被扔进一个刚格式化过的房间，做完事房间就被拆掉，下次再来一切归零。Cloud Computer 想解决的，就是这个“身体”的持久化问题。

先把概念说清楚。这里说的 Cloud Computer，不是我们平时远程登录的那台云主机，而是给 Agent 用的一个持久化云端工作空间。它包含几个关键部分：一个长期存在的文件系统（Workspace）、一个可以反复启动和挂起的运行环境（Sandbox）、以及一套让 Agent 能读写文件、执行命令、调用工具的接口层。你可以把它理解成给 Agent 配了一台“永远不关机、随时能回来接着干”的电脑。Manus 2.0 把它作为核心能力推出来，背后的判断很明确：Agent 的进化方向不是单次任务做得更漂亮，而是能像人一样在同一个环境里持续积累、持续工作。

为什么这件事重要？我举个自己遇到的真实场景。之前做一个自动整理行业资讯的 Agent，流程是每天抓取、清洗、归类、生成摘要、推送到指定位置。单次跑没问题，但问题是它没有“昨天”的概念。今天抓到的内容和昨天重复了，它不知道；上周已经归档过的来源，它这周又当成新来源处理；生成摘要时想引用历史数据，它只能重新去抓一遍。整个系统看起来在自动运行，实际上每天都在从零开始。这就是典型的“无持久工作环境”的 Agent，能力被死死锁在单次会话里。

Cloud Computer 带来的改变，本质上是把 Agent 从“无状态函数”变成“有状态进程”。有状态意味着几件事：第一，文件系统持久，Agent 写下的中间结果、下载的资料、生成的草稿，下次还能找到；第二，运行环境持久，装过的依赖、配过的环境变量、跑过的服务，不用每次重来；第三，上下文可以外化，不必把所有记忆都塞进模型的上下文窗口，而是落到磁盘上按需读取。这三点加起来，才让 Agent 真正具备“持续工作”的可能。

热搜词里有个词很值得玩味：failed to start claude's workspace。这说明什么？说明大量用户已经在尝试让 Agent 拥有 workspace，但卡在了启动环节。workspace 这个概念本身不新，VS Code 早就有 workspace，各种 IDE 也有，但把它作为 Agent 的持久工作环境来用，是最近才被认真对待的事。Manus 2.0 的 Cloud Computer 之所以值得单独拿出来讲，是因为它把 workspace、sandbox、持久化这几件事打包成了一个对 Agent 友好的整体方案，而不是让开发者自己去拼。

这篇文章我打算按实际落地的思路来写。先拆清楚 Cloud Computer 到底由哪些部分组成、每部分解决什么问题；再讲怎么给 Agent 搭一个能持久工作的环境，包括目录结构、状态管理、沙盒隔离这些实操细节；然后聊并发和安全这两个绕不开的硬骨头；最后把我踩过的坑和排查经验整理出来。适合正在做 Agent 开发、被“每次都要重来”折磨过的朋友，也适合刚入门想搞清楚 Agent 架构到底该怎么设计的人。不管你现在用的是哪家框架，这套思路都能直接借鉴。

2. Cloud Computer 的核心构成：Workspace、Sandbox 与状态层怎么配合

2.1 Workspace：Agent 的“硬盘”和“桌面”

Workspace 是 Cloud Computer 里最容易被低估的部分。很多人以为它就是个放文件的目录，其实它是 Agent 的长期记忆载体。一个设计良好的 Agent Workspace，至少应该包含这几类内容：输入区（待处理的任务、抓取回来的原始数据）、工作区（中间产物、临时文件、脚本）、输出区（最终交付物）、状态区（记录任务进度、已处理标记、配置信息）、知识区（沉淀下来的可复用资料）。这五块分开，是为了让 Agent 在读写时边界清晰，不至于把临时垃圾和重要成果混在一起。

我自己的习惯是给每个 Agent 项目建一个固定的根目录，比如/workspace/agent-name/，下面按功能分子目录。这样做的好处是，当 Agent 需要“回忆”某件事时，它不需要去翻整个磁盘，而是按约定路径直接定位。比如要查昨天处理到哪了，直接读state/progress.json；要引用历史资料，去knowledge/里找。路径约定本身就是一种低成本的结构化记忆。

这里有个关键点：Workspace 的持久化不等于把所有东西都留着。我见过有人把 Agent 跑出来的每一个中间文件都永久保存，结果几个月后目录膨胀到几十万个小文件，检索慢、备份难、清理更痛苦。正确做法是分层保留：状态文件和知识沉淀长期保留，中间产物按时间或任务批次定期清理，原始输入按需归档。可以在 Workspace 里放一个清理脚本，让 Agent 自己定期执行，这也是持久环境该有的“自我维护”能力。

2.2 Sandbox：能反复启动、随时挂起的运行环境

Sandbox 解决的是“执行”的问题。Agent 要干活，就得能跑命令、装依赖、起服务。如果每次任务都新开一个干净沙盒，那和没有持久环境区别不大。Cloud Computer 的思路是让 Sandbox 可以挂起和恢复：任务做到一半，把环境状态存下来，下次接着跑，装过的依赖还在，跑着的进程可以恢复，临时文件也还在原位。

这背后的技术选择值得说一下。实现沙盒持久化常见有几条路：一是容器快照，把整个文件系统状态打包，恢复时还原；二是虚拟机快照，隔离更彻底但更重；三是基于文件系统的分层叠加，只记录变化层。Manus 2.0 具体用哪种没有完全公开，但从它对“持久工作环境”的强调来看，核心诉求是恢复成本要低、状态要完整。对开发者来说，选型时要想清楚：你的 Agent 任务周期有多长？如果只是几分钟的短任务，沙盒持久化收益不大；如果是几小时甚至跨天的大任务，那持久沙盒就是刚需。

注意：沙盒持久化会带来状态漂移问题。今天装了一个库的 1.0 版本，明天恢复环境时如果依赖源更新了，可能装成 1.1，行为就不一致了。解决办法是把依赖版本锁死在配置里，恢复时按锁定版本重建，而不是重新解析。

2.3 状态层：让 Agent 知道“我是谁、我做到哪了”

状态层是 Workspace 和 Sandbox 之间的粘合剂。它记录的不只是文件，还有任务级的状态：当前在做什么、做到第几步、哪些子任务完成了、哪些失败了、下一步该干什么。没有状态层，Agent 恢复环境后面对一堆文件也不知道从哪继续。

我通常用两种方式实现状态层。轻量方案是用一个 JSON 或 SQLite 文件，记录任务 ID、步骤、时间戳、结果摘要。重量方案是引入一个专门的状态管理服务，支持并发读写和事务。对大多数个人项目和小团队来说，SQLite 足够了，它单文件、无需额外服务、支持并发读，写的时候加个锁就行。关键是要让 Agent 在每一步操作后都更新状态，而不是等任务结束才写。这样即使中途崩了，恢复时也能从最后一个成功步骤继续。

状态层还有一个容易被忽略的作用：审计和复盘。Agent 跑完一个长任务后，你可以通过状态记录回看它每一步做了什么、花了多久、在哪卡住。这对优化 Agent 行为特别有价值。我有个习惯，每次 Agent 任务结束后，把状态记录导出成一份简短报告，看看哪些步骤耗时异常、哪些工具调用失败率高。坚持一段时间后，Agent 的整体效率能提升不少。

3. 给 Agent 搭一个能持久工作的环境：从目录结构到恢复策略

3.1 目录结构设计：让路径本身成为约定

搭持久环境的第一步是把目录结构定下来。我的做法是固定一套模板，每个 Agent 项目都按这个来，这样 Agent 的代码里可以硬编码路径，不用每次动态发现。下面是我常用的结构：

/workspace/ agent-name/ inbox/ # 待处理输入 work/ # 中间产物 outbox/ # 最终输出 state/ # 状态文件 progress.json config.json knowledge/ # 沉淀资料 scripts/ # 可复用脚本 logs/ # 运行日志 tmp/ # 临时文件，可随时清空

这套结构的好处是职责分明。Agent 启动时先读state/progress.json，看有没有未完成任务；有的话从work/里找中间产物，接着干；没有的话从inbox/取新任务。输出统一放outbox/，方便外部系统对接。knowledge/是长期积累区，Agent 可以往里写总结、索引、常用数据，下次直接读。

提示：tmp/目录要明确标记为可清理。我见过 Agent 把重要中间结果写在 tmp 里，结果清理脚本一跑全没了。约定好哪些目录是易失的，哪些是持久的，能避免很多意外。

3.2 环境初始化与依赖锁定

持久环境不等于永远不重建。沙盒可能因为各种原因需要重新拉起，这时候环境初始化脚本就很重要。我的做法是维护一个setup.sh，里面写清楚要装什么、配什么、初始化哪些目录。关键是依赖版本要锁定，不能写pip install requests，要写pip install requests==2.31.0。Python 项目用requirements.txt加pip freeze生成锁定文件，Node 项目用package-lock.json，系统级依赖用版本号固定。

初始化脚本还要处理“幂等”问题。也就是说，脚本跑一次和跑十次结果应该一样。装依赖前先检查是否已装，建目录前先判断是否存在，配环境变量前先看是否已配。这样即使沙盒恢复时部分状态还在，脚本也不会出错。我踩过的坑是：初始化脚本没做幂等，沙盒恢复后重复执行，把已有配置覆盖了，导致 Agent 行为异常。后来加了判断逻辑才稳定。

3.3 任务恢复策略：从哪断的从哪接

持久环境最大的价值体现在任务恢复上。一个跑了三小时的任务，如果因为网络抖动或沙盒重启中断，没有恢复策略就得从头再来，时间和资源都浪费了。我的恢复策略分三层：任务级恢复、步骤级恢复、操作级恢复。

任务级恢复最简单：状态文件里记一个task_status，值是running、paused、done、failed。Agent 启动时先看这个，如果是running或paused，就尝试恢复。步骤级恢复更细：每个大步骤开始前写一条记录，完成后更新状态。恢复时从最后一个未完成步骤开始。操作级恢复最细，适合关键的单次操作，比如下载大文件、调用付费接口，操作前记状态，成功后标记，恢复时跳过已成功的。

实际用下来，步骤级恢复性价比最高。任务级太粗，恢复后可能重复很多工作；操作级太细，状态写入频繁，开销大。步骤级刚好平衡。实现上，我会在 Agent 主循环里加一个checkpoint()函数，每个步骤结束时调用，把当前进度写进state/progress.json。恢复时读这个文件，跳到对应步骤。

3.4 日志与可观测性：持久环境不能是黑盒

环境持久了，Agent 在里面干了什么就更需要记录。没有日志，恢复时你不知道之前发生了什么，出问题也难排查。我的做法是每个 Agent 操作都写结构化日志，至少包含时间戳、操作类型、输入摘要、输出摘要、耗时、是否成功。日志按天切分，放logs/目录，保留最近 30 天，更早的归档压缩。

结构化日志的好处是可以直接分析。比如我想知道哪个工具调用最慢，grep 一下日志按耗时排序就行。想知道失败率，统计success=false的比例。这些数据对优化 Agent 很有用。我还会在日志里记录每次恢复的事件，这样能看出环境稳定性如何。如果恢复频繁，说明沙盒或网络有问题，需要针对性解决。

4. 并发、隔离与安全：持久环境绕不开的三道坎

4.1 多任务并发时 Workspace 怎么不打架

持久 Workspace 一旦支持并发，问题就来了：两个任务同时写同一个文件怎么办？一个任务在读，另一个在删，怎么保证一致性？我的经验是按任务隔离目录，每个任务实例有自己的子目录，比如work/task-{id}/，任务之间不共享可写区域。共享的只有knowledge/这种只读或追加写的区域。

对于必须共享的资源，用锁来协调。文件锁、数据库锁都行，关键是粒度要合适。锁太粗，并发上不去；锁太细，管理复杂。我一般对状态文件加文件锁，对知识库用追加写模式避免冲突。还有一个技巧是写时复制：任务要修改共享文件时，先复制一份到自己的目录，改完再合并回去。这样读操作不受影响，写操作也不会互相覆盖。

注意：并发写同一个 SQLite 文件在高频场景下会锁等待。如果 Agent 并发度高，考虑换成支持并发写的存储，或者把状态按任务分库，减少竞争。

4.2 Sandbox 隔离：一个任务崩了不能拖垮全部

持久沙盒如果所有任务共用一个，一个任务把环境搞坏了，其他任务全遭殃。所以隔离很重要。常见做法是每个任务一个沙盒实例，任务结束或挂起时保存状态，下次恢复。这样隔离彻底，但资源开销大。另一种是共享沙盒但用命名空间隔离，比如容器里的不同用户、不同目录，开销小但隔离性弱一些。

选哪种取决于任务性质。如果任务之间依赖冲突严重，比如一个要 Python 3.8 一个要 3.11，那就必须分开沙盒。如果依赖基本一致，只是数据不同，共享沙盒加目录隔离就够了。我自己的项目里，长任务用独立沙盒，短任务共享沙盒，平衡资源和隔离。

4.3 Agent 安全：持久环境放大了风险

持久环境让 Agent 能长期访问文件系统和执行命令，这本身就把安全风险放大了。几个必须注意的点：权限最小化，Agent 只能访问自己 Workspace 内的路径，不能碰系统目录；命令白名单，危险命令如rm -rf /、curl到未知地址要拦截；网络出口限制，只允许访问必要的域名；敏感信息隔离，密钥、令牌不放在 Workspace 里，用环境变量或专门的密钥管理。

我踩过的一个坑是：Agent 在 Workspace 里存了 API 密钥，结果日志里不小心打出来了。后来改成密钥只通过环境变量注入，日志里做脱敏处理。还有一次，Agent 执行了一个从网上抓来的脚本，脚本里有恶意命令。从那以后，所有外部脚本先审查再执行，或者放在受限沙盒里跑。持久环境意味着这些风险会长期存在，不能掉以轻心。

5. 实操中常见的坑与排查经验

5.1 环境启动失败：从 workspace 报错说起

热搜里那个failed to start claude's workspace和workspace discovery fail，我遇到过类似情况。表现是 Agent 启动时找不到 Workspace，或者找到了但初始化失败。常见原因有几个：路径配置错了、权限不够、依赖没装全、状态文件损坏。排查顺序我一般是：先看日志里报的具体错误，再手动进沙盒检查路径是否存在、权限是否正确，然后跑一遍初始化脚本看哪步失败。

有个隐蔽的坑是路径大小写。Linux 区分大小写，Windows 不区分。如果 Workspace 路径在配置里写的是Workspace，实际目录是workspace，在 Linux 上就找不到。我统一用小写路径命名，避免这个问题。还有符号链接问题，如果 Workspace 是软链接，某些沙盒环境可能解析不了，尽量用真实路径。

5.2 状态不一致：恢复后 Agent 行为异常

恢复环境后 Agent 行为异常，多半是状态不一致。比如状态文件说任务在第三步，但第三步的中间产物被清理了；或者依赖版本变了，代码跑不通。解决办法是恢复时做一致性检查：读状态文件，验证对应步骤的产物是否存在、依赖版本是否匹配。不匹配就回退到上一个一致的状态，或者重新执行该步骤。

我还会在状态文件里存一个环境指纹，记录关键依赖的版本、Workspace 的结构哈希。恢复时对比指纹，不一致就触发重建。这样能及早发现漂移，避免 Agent 带着错误状态继续跑。

5.3 资源泄漏：持久环境也会“越用越慢”

持久环境用久了，可能出现磁盘满、内存涨、进程堆积。我遇到过 Agent 跑了一周后沙盒磁盘满了，原因是日志和临时文件没清理。后来加了定期清理任务，每天凌晨清理tmp/和过期日志。内存泄漏则多来自长期运行的服务进程，解决办法是定期重启或加监控，内存超阈值就重启。

还有一个容易忽略的是文件句柄泄漏。Agent 频繁打开文件不关闭，时间长了句柄耗尽。写代码时用with语句或确保close()调用。这些细节在短任务里不明显，持久环境里就会暴露。

5.4 常见问题速查表

这张表是我自己排查时总结的，实际遇到问题先对照，能省不少时间。每个问题的根因往往不止一个，按顺序排查效率最高。

6. 我对 Agent 持久工作环境的一点实际体会

折腾了这么多 Agent 项目，我越来越觉得持久工作环境不是锦上添花，而是 Agent 从“玩具”走向“工具”的分水岭。没有持久环境，Agent 再聪明也只能做一次性任务，做完就忘，下次重来。有了持久环境，它才能积累、迭代、真正帮你分担长期工作。Manus 2.0 把 Cloud Computer 作为核心推出来，方向是对的，剩下的就是工程细节的打磨。

最后分享一个小技巧：给 Agent 的 Workspace 加一个README.md，让 Agent 自己维护，记录这个环境里有什么、怎么用、最近做了什么。每次 Agent 启动时先读这个文件，相当于给自己一个“工作交接”。这个习惯我坚持了几个月，Agent 恢复后的“迷茫期”明显缩短了。环境是死的，但让 Agent 学会和环境对话，它才真正活起来。