Perplexity Computer 的巧思：把长任务做成可暂停的会话，再把权限留在会话外

把一个任务交给 AI，真正难的部分不是让它开始工作，而是让它在几个小时后仍然知道自己做到哪一步、为什么停下来，以及拿到过哪些权限。Perplexity Computer 的产品页把它定义为一个「general-purpose digital worker」：用户描述一个目标，Computer 拆成任务和子任务，调用子 agent 去浏览、研究、写作、编码或连接外部工具，工作可以持续数小时甚至数月。12

真正有意思的地方不在「它能调用很多模型」，而在 Perplexity 给这类长任务加了两层产品边界：第一层管理任务的生命周期，允许会话暂停、恢复和分叉；第二层管理任务的能力边界，让凭证和网络访问留在执行环境之外。前者解决「中断后还能不能接着做」，后者解决「给了它权限以后，最坏会扩散到哪里」。

普通聊天的基本单位是消息。Perplexity Computer 把基本单位换成了一次持续运行的任务：Computer 可以建立多个子 agent 并行处理工作，用户离开页面后，任务仍然在云端继续。官方产品页甚至把「后台任务与持续监控」列为独立能力，允许用户设置重复任务，让 Computer 持续执行。2

官方示例里，一个目标会展开成「Running tasks in parallel」以及多个正在加载的 Skills。它不是把一条更长的回答塞回聊天框，而是把工作拆成能独立推进的执行单元。2

Perplexity 为这套任务模型配套的底层产品叫 SPACE。短任务使用一次性的沙盒，任务完成后，沙盒和里面的内容都会销毁；需要跨越重启或长时间运行的任务，则被包进一个 session。这个 session 可以暂停、恢复，也可以从当前状态分叉出多个沙盒。3

这里最巧的细节是「上下文随工作走」，而不是让同一个沙盒永远活着。SPACE 用 rolling snapshot 保存完整的 session 状态，包含运行中的内存和文件，官方说明里提到快照频率最高可到每分钟一次，并且可以回到一周前的状态。用户离开的是一个可恢复的工作对象，不是某台必须一直在线的机器。3

这改变了 agent 产品里「继续」的含义。继续一个任务，不只是把历史消息重新塞给模型，而是恢复它已经建立的文件、运行状态和工作位置。分叉也不再需要用户先复制材料、重新描述目标，再手动比较两份结果。需要测试另一条路径时，直接从已有 session 分出一条新路，原来的状态仍然保留。

代价同样具体。要让这件事成立，产品必须维护 session 状态、快照、分支关系和多个执行后端之间的调度，用户也要面对「当前状态到底是哪一份」的判断。SPACE 的控制平面会追踪沙盒状态，决定何时建立新沙盒、何时结束任务；这说明「可恢复」不是一个撤销按钮，而是一整套持续运行的状态管理。3

长任务一旦能读文件、跑代码、访问浏览器和连接第三方服务，用户面对的就不再是「模型会不会答错」，而是「一次错误操作能带走什么」。Perplexity 的处理方式，是把沙盒默认当成不可信环境，分别控制网络、凭证、租户隔离和加密存储。

官方 SPACE 说明写得很明确：凭证不会进入沙盒，而是在 agent 真正需要连接某个服务时，由沙盒外部临时传入；出站网络流量也在节点层控制，受感染的 agent 默认不能访问任务范围之外的资源。沙盒内部运行在隔离的 Firecracker microVM 里，只有 Space Daemon 与控制平面通信。3

这是一种比「请用户相信模型」更可操作的信任设计。产品没有把所有权限一次性塞给 agent，再要求模型自觉；产品把能力拆成可撤回的外部服务。即便任务持续很久，执行环境也不应该因此获得一组永久可见的钥匙。

在 Personal Computer 中，这个边界被翻译成用户能看见的控制点：敏感动作需要用户批准，每个 session 都有完整审计轨迹，还有可以立即停止工作的 kill switch。官方还把文件创建描述为发生在 secure sandbox 中，并强调动作可审计、可逆。45

计划预览和运行中的成本显示，是这套权限设计在产品界面上的另一面。Perplexity 的更新日志说明，长任务或高消耗任务会先生成结构化计划，等待用户批准、调整范围或要求重写；独立评测 DataCamp 在一次八个工具的并行研究测试中记录到，Computer 在执行前展示计划和信用估算，运行中还可以暂停单个子 agent。76

这套设计并没有消除监督，只是把监督从「盯着每一步点击」换成「在几个高价值节点做决定」。DataCamp 的那次实测耗时 7 分 59 秒、使用 225.71 credits，研究表格基本可用，但推荐 memo 仍需要人工清理约 30 分钟；评测者还指出，信用消耗会随任务拆解而变化，重复运行同一提示词也可能得到不同的子 agent 计划。6

这正是「权限隔离」的现实代价：用户少做了一些机械操作，却要更认真地处理批准、成本、连接器和最终检查。产品如果只给一个自动执行按钮，用户很难判断 agent 现在拥有的能力；如果把计划、运行状态、审计和停止入口放在同一条工作路径上，用户至少知道什么时候该放手，什么时候必须接管。

Perplexity Computer 最值得借鉴的设计，不是把更多模型和工具装进一个入口，而是给 agent 任务补上了两个过去常被省略的对象：一个能暂停、恢复、分叉的 session，以及一组不跟着 session 一起永久暴露的权限。

这套方法适用于任何要运行数小时的 AI 工作流。先把恢复单位设计清楚，再把权限设计成外置、临时、可审计。这样用户交出去的不是一段无法追踪的自动化，而是一项随时能暂停、能回到旧状态、也知道怎样收回控制权的工作。