OpenBot 如何落地为本地优先的持久化 AI 工作台

把一个需要持续运行的代码任务交给 AI 队友，关掉窗口再回来时，界面上还能看到这条任务，并不能证明它真的具备持久化能力。进程是否仍在运行、队列里是否保留了任务记录、生成文件是否还在、对话上下文能否恢复，以及浏览器登录会话是否延续，是五个相互独立的问题。任何一层没有通过验收，“关掉后再回来”的体验都可能只是界面残留。

OpenBot 的公开定位是一个 local-first desktop workspace，用于承载 persistent AI teammates，并支持通过专用工作区、任务队列、文件共享和浏览器控制运行 Codex、Claude 与 Grok。这套组合的关键价值不在于把所有推理都搬到本地，而在于把任务编排、工作目录和工具操作放进一个可控的桌面环境；但“本地优先”也不自动等于完全离线、自动沙箱或天然安全。本文只分析 nightly-labs/openbot，并把公开定位与需要通过源码、文档和实验确认的实现语义分开讨论。

先锁定仓库身份，别让同名项目混进结论

目标仓库是热点来源指定的 nightly-labs/openbot。本文涉及该项目功能边界时，只采用其公开描述中已经明确的信息：本地优先的桌面工作空间、持久化 AI 队友，以及 Codex、Claude、Grok、专用工作区、任务队列、文件共享和浏览器控制。

搜索结果中存在多个同名或近似项目。OpenBotX 是另一套智能体编排平台；CopilotKit 团队也出现过名为 OpenBot 的 AI 同事平台；还有面向实体机器人的自然语言控制项目。它们的架构、依赖和运行方式不能移植到目标仓库的结论中。

二手桌面 Agent 文章没有提供足以确认其与目标仓库归属一致的信息。其提到的多端接入、机器人通道、共享目录和 AgentManager，只能作为源码检索时的待核验线索，不能直接写成 OpenBot 已实现的能力。Moltbot/Clawdbot/OpenClaw 的 Gateway、Agent、SessionKey 和路由模型同样只适合用来校准分析问题，不应被当成 OpenBot 的既定实现。

分析时应把信息分成三层：第一层是仓库公开描述已经确认的产品定位；第二层是必须回到目标版本源码、README、安装清单、发布说明和配置示例核对的实现细节；第三层是本地优先架构应有的安全约束与验收建议。当前公开摘录没有展示完整安装清单，因此本文不会预写具体运行时、包管理器、目录、端口或启动命令，避免给出一套看似完整却无法复现的部署教程。

从一次长任务还原桌面工作流

依据公开描述，可以还原出一条逻辑任务链路：

用户 / 桌面界面
      │ 创建专用工作区、提交任务
      ▼
任务队列
      │ 选择执行端、调度任务
      ├──────────────┬──────────────┐
      ▼              ▼              ▼
   Codex           Claude          Grok
   执行端          执行端          执行端
      │              │              │
      └──────┬───────┴──────┬───────┘
             │              │
             ▼              ▼
       专用工作区        浏览器控制
       输入 / 输出       会话 / 下载
       生成文件         页面操作
             │              │
             └──────┬───────┘
                    ▼
              结果回写与状态更新
                    │
             应用退出或系统重启
                    │
                    ▼
          队列与上下文的恢复路径

这是一张能力关系图，不是已经确认的进程部署图。队列是否由桌面进程直接管理、浏览器控制是否运行在独立进程、执行端是否作为本地子进程启动，都需要按目标版本实现核对。可观察的任务链路至少包括：创建工作区、提交任务、进入队列、调用执行端、读取或写入文件、控制浏览器、回写结果以及重启恢复。

源码检查可以围绕职责而不是假定类名展开：

环节	应查找的实现	需要留下的证据
工作区创建	工作区标识、路径解析、配置绑定	新旧工作区实际根目录与权限
任务入队	队列数据结构、落盘位置、状态变更	入队前后任务记录与时间戳
执行端调度	Codex、Claude、Grok 的适配入口	版本、认证来源、工作目录和输入格式
文件工具	路径转换、复制、挂载或共享逻辑	实际读写路径及越界测试结果
浏览器工具	浏览器配置、会话生命周期、下载目录	使用的账户、配置目录和监听地址
结果回写	输出解析、冲突处理、错误记录	产物内容、覆盖策略和失败状态
恢复流程	启动扫描、任务重载、重复执行判断	重启后的队列快照与执行日志

专用工作区承接任务上下文

专用工作区是公开描述中明确存在的能力，但“每个执行端有独立工作区”至少可能对应三种不同含义。

第一种是目录边界：不同任务拥有不同的输入、输出和产物目录。第二种是配置边界：工作区关联提示词、工具、模型或执行端配置。第三种才是安全边界：工作区同时限制文件权限、子进程权限和网络访问。三者不能混为一谈。

源码中应确认工作区标识如何解析为真实路径，任务启动时的工作目录是什么，环境变量和凭据是否被继承，以及文件访问是否经过统一路径校验。如果不同执行端只是以不同参数指向同一目录，那么所谓“专用”主要是命名隔离；如果每个工作区使用独立低权限账户、容器或操作系统策略，隔离强度才更接近沙箱。

还要检查工作区是否允许符号链接、硬链接、挂载点或路径穿越。单纯比较字符串路径不足以阻止访问工作区外的真实文件。更稳妥的边界是：先规范化路径，再解析符号链接，最后检查真实路径是否仍位于允许根目录内；同时限制子进程的删除权限和跨目录读取能力。

队列与任务状态恢复

任务队列同样是公开定位中明确出现的能力，但“存在 task queues”不能直接推导出任务一定会可靠恢复。队列至少需要回答以下语义问题：

维度	必须确认的问题	失败后的主要风险
排序	按创建时间、优先级还是依赖关系执行	任务顺序与用户预期不一致
并发	全局、每工作区还是每代理限制	同时修改同一文件
取消	能否取消排队任务和运行中任务	取消后仍产生副作用
重试	是否自动重试，次数和退避策略是什么	重复写入或重复提交外部操作
超时	执行端无响应时何时终止	队列长期占用
崩溃恢复	重启后恢复、重排队还是标记失败	静默丢任务或重复执行
幂等性	同一任务重复投递是否产生相同结果	文件重复追加、外部操作执行两次

这里最容易被忽略的是“任务记录已经保存”和“任务仍在继续运行”之间的区别。应用退出后，后台执行进程可能随之终止；系统重启后，所有本地进程都会消失。系统能够恢复的最多只是任务记录、上下文或文件，再由恢复逻辑决定是否重新执行。

如果执行端先完成外部副作用，桌面端随后才写入“已完成”状态，那么崩溃后重试可能形成至少一次执行语义。此时应检查任务是否有唯一标识、输出文件是否原子写入、启动操作是否带幂等键，以及恢复程序如何区分“未执行”“执行中但未确认”和“已完成但未回写”。不能在没有测试证据时宣称任务“exactly once”执行。

文件与浏览器连接真实动作

文件共享与浏览器控制是权限最高的两条工具通道。公开描述确认了这两项能力，但没有说明其具体实现方式。

文件共享可能采用复制、挂载、软链接或路径映射。验收时应记录实际机制，并重点检查：

• 输入文件是复制进工作区，还是直接引用原路径。
• 输出是覆盖、合并、生成新文件还是写入固定文件名。
• 符号链接、硬链接和路径穿越能否指向工作区之外。
• 工具是否拥有删除权限，删除是否可恢复。
• 写入是否采用临时文件加原子替换，异常中断会不会留下半截文件。
• 多个任务能否同时写同一产物，冲突如何被发现。

浏览器控制的风险更高。需要追踪浏览器配置目录、Cookie 与登录状态、下载目录、页面截图、DOM 内容、键盘输入以及工具输出分别保存在哪里。如果实现使用远程调试或类似控制接口，还要检查它是否只监听环回地址，是否存在未认证访问，以及页面脚本能否借机访问其他本机服务。

浏览器控制不等于浏览器登录状态必然持久化。会话是否跨应用重启保留、Cookie 是否只在内存中、退出时是否清理，都必须通过重启实验确认。对于需要登录的任务，应优先使用独立浏览器配置，避免把个人账号、已登录后台和私人 Cookie 带入 Agent 可控环境。

Codex、Claude 与 Grok 接入同一桌面工作流

公开条目确认 OpenBot 可以运行 Codex、Claude 和 Grok，并为它们提供专用工作区。这说明三者在产品能力上被纳入同一桌面工作流，但不意味着三者采用相同认证方式、相同本地进程模型或相同数据上传范围。

部署前应分别形成执行端适配记录：

执行端	认证与版本	任务输入	输出与失败处理
Codex	记录仓库实际支持的认证方式、所需版本和凭据来源	核对工作目录、环境变量、提示词及附件如何传入	核对标准输出、错误输出、退出码、超时和限流如何回写
Claude	记录认证方式、版本约束及是否依赖外部服务	核对上下文长度处理、文件输入和取消机制	核对响应解析、中断、认证过期与重试行为
Grok	记录认证方式、版本约束及网络前置条件	核对参数格式、任务目录和工具结果回传	核对异常响应、限流、连接中断和部分输出处理

需要特别区分“本地运行某个 AI 命令行工具”和“在本地执行模型推理”。前者可能只是把客户端、工具循环或文件操作放在本机，提示词、上下文、代码片段、网页内容和工具输出仍可能发送给远端服务。是否发生外传，应通过执行端适配代码、网络策略和抓取可见的连接目标共同确认，而不能根据产品界面上运行的是 Codex、Claude 还是 Grok 作出推断。

用状态矩阵核验持久化边界

持久化能力需要按状态类别分别核验。当前资料确认了任务队列、文件共享和持久化队友等能力定位，但没有给出各类状态的存储位置、加密方式、保留期限或清理机制。部署前应按实际实现填写下面这张“状态验收表”。

状态类别	是否保存	保存位置	是否加密	恢复方式	保留期限	清理方法
应用配置	待核验	从配置解析结果确认	不得假设已加密	重新加载配置	按版本与用途确定	删除前备份并按卸载说明检查
队列记录	能力已确认，持久化语义待核验	定位实际状态存储	待核验	启动恢复或重新入队	待核验	优先归档再清理
对话与上下文	“持久化队友”定位不自动等于完整上下文落盘	待核验	待核验	重新加载或从任务恢复	待核验	区分会话、定稿和临时上下文
生成文件与工作区产物	文件共享能力已确认，生命周期待核验	实际工作区路径	依赖磁盘与工具实现	重新挂载或复制	按项目归档策略	删除前检查引用关系
浏览器会话	浏览器控制已确认，Cookie 是否持久化待核验	独立浏览器配置目录	待核验	重新加载浏览器配置	应最短化	注销账号并移除配置目录
日志与崩溃信息	待核验	文档或配置指定的日志目录	待核验	通常用于排障而非恢复任务	应设置明确期限	轮转、压缩和到期删除

矩阵中的“待核验”不是否定产品能力，而是避免把“数据默认在本地”误写成“数据已加密且生命周期可控”。如果浏览器配置、日志或队列文件包含 Cookie、提示词、源代码和凭据，仅依赖操作系统磁盘加密并不够，还要考虑应用日志读取者、备份介质和卸载残留。

重启不是唯一验收点

一次重启测试最多只能说明某份状态是否被重新加载。要区分持久化层次，应设计一组递进的故障实验。

先建立一个无敏感信息的验收任务：在工作区输入文件中写入固定标记，让执行端读取该文件并生成预期输出；如果启用浏览器，则访问一个受控测试页面并下载一个无敏感内容的文件。整个过程记录任务编号、队列状态、输入输出文件哈希、浏览器配置目录和执行端日志位置。

随后分别执行以下实验：

实验	操作	需要确认的结果
关闭窗口	关闭桌面界面但保留系统进程	明确任务是继续执行、仅保留记录，还是停止
退出应用	从系统托盘或菜单完全退出	队列记录是否仍在，恢复后是否重复产生副作用
重启系统	终止全部本地进程后重新启动	哪些状态被恢复，旧任务是否被自动重放
浏览器异常退出	强制结束浏览器进程	页面会话、下载和任务上下文分别保留什么
执行端中断	临时阻断执行端连接或终止对应进程	任务进入失败、等待还是重试，是否发生重复写入
磁盘写入失败	在隔离测试环境中制造空间不足或只读条件	是否留下半截文件，队列是否错误标记为成功

合格结果不只是“重启后还能看到任务”。还应确认恢复后的任务不会在未确认的情况下再次执行高权限操作。对有外部副作用的任务，最稳妥的策略是恢复为待人工确认，而不是自动重放。

多人共用时先拆身份与目录

多人共用机器时，专用工作区只能解决部分命名和产物冲突，不能替代用户隔离。至少要分别确认操作系统账户、Agent 或工作区身份、凭据、本地监听端口、日志访问权和文件锁。

如果多个用户共用同一个操作系统账户，他们可能读取彼此的配置、日志和浏览器状态；如果共用同一个凭据，任何一个被攻陷的执行端都可能影响其他工作区；如果多个应用实例监听同一端口，则启动结果会依赖端口竞争，而不是任务设计。严格场景应使用不同系统账户、独立配置目录和明确的端口分配；更高风险场景再考虑虚拟机或容器等更强边界，但具体隔离机制必须以 OpenBot 实际支持能力为准。

远程访问也不能沿用本机个人登录态。多人场景至少应做到一人一凭据、一工作区一审计记录，并让服务端权限与客户端权限分离。

部署先建立可复现基线

当前给出的仓库资料没有列出完整操作系统、运行时、包管理器、浏览器依赖和安装清单，因此不能直接写死 npm、pnpm、Python 或其他工具链。正确做法是从固定版本的仓库文档确认支持矩阵，并把版本、校验值和配置位置记录下来。

获取源码并记录提交号可以这样做；这一步只用于建立版本身份，不等同于已经确定安装方式：

git clone https://github.com/nightly-labs/openbot.git
cd openbot
git rev-parse HEAD

正式发行包与源码构建应分别记录：

路径	优势	必须补充的验证
仓库提供的正式发行包	安装步骤更直接，适合先建立桌面基线	来源、版本、校验值、签名或发布说明
固定提交的源码构建	更容易审计组成并复现具体提交	文档声明的工具链、锁文件、构建产物和原生依赖

如果使用发行包，可在下载它的主机上计算校验值：

shasum -a 256 <release-package>

sha256sum <release-package>

Get-FileHash -Algorithm SHA256 <release-package>

下面这份部署记录是团队自己的验收清单，不是 OpenBot 原生配置文件：

project: "nightly-labs/openbot"
commit: "<完整提交号>"
release: "<发行版本或源码构建>"
operating_system: "<仓库明确支持的系统和版本>"
runtime: "<安装清单声明的运行时及版本>"
package_manager: "<仓库指定的包管理器及锁文件>"
browser: "<浏览器组件及版本>"
executor: "<本次只启用 Codex、Claude 或 Grok 中的一项>"
workspace: "<试点工作区标识>"
local_service: "<监听地址和端口>"
credential_source: "<受控存储或环境变量>"
browser_profile: "<隔离配置目录>"
log_location: "<文档或配置指定的位置>"
rollback_artifact: "<安装包、校验值或上一版本记录>"

随后按仓库当前文档核对安装命令，不从其他 Electron、Node.js 或桌面 Agent 项目复制命令。浏览器是否需要额外组件、系统后台服务是否单独安装、是否需要图形会话、多个版本之间如何迁移，都应以目标版本的实际说明为准。

首次启动只开放最小能力

首次验收应使用低权限操作系统账户、一个专用工作区和一个执行端。先不接入真实代码库、个人浏览器配置和其他代理。

具体流程可以分为七步：

1. 按固定文档完成安装，记录完整提交号、发行包校验值和依赖版本。
2. 使用独立低权限账户启动，确认主进程、子进程和浏览器进程实际运行在该身份下。
3. 只配置一个执行端，验证认证失败、认证成功和凭据撤销三种状态。
4. 创建一个空白工作区，确认其中没有个人文档、历史任务或其他工作区产物。
5. 使用固定标记任务验证入队、执行、文件生成、结果回写和状态更新。
6. 如需测试浏览器，使用独立配置和受控测试页面，验证下载目录及页面内容回流。
7. 完成退出应用与系统重启实验，再决定是否开放更多权限。

验收任务可以使用以下固定标记：

OPENBOT_ACCEPTANCE_001

合格标准不是模型生成了相似文字，而是能够同时取得这些证据：任务进入指定队列、执行端收到正确工作目录、输出文件出现在指定工作区、浏览器操作发生在隔离配置中、工具没有写入允许范围之外的位置、退出后状态恢复符合仓库定义且没有重复副作用。

完成最小闭环后，再按“只读输入、受限写入、浏览器访问、额外网络、多个执行端、多个工作区”的顺序逐步放权。每次只改变一个权限变量，并重复同一套验收任务，才能知道风险来自配置变化还是版本变化。

常见故障按层次定位

故障排查应沿运行链路逐层缩小范围，而不是反复重装。先确认版本和进程，再确认本地状态、认证、工具权限和网络。

现象	优先检查层	需要的证据	避免的操作
安装或启动失败	操作系统、运行时、原生依赖、图形环境	安装日志、缺失依赖、实际版本	混用其他项目的安装命令
执行端认证失败	凭据来源、认证方式、版本和账户状态	认证错误、凭据标识、撤销测试	把密钥写进命令行或普通配置
任务停在队列	队列存储、锁、后台进程、磁盘状态	任务状态变化、锁持有者、启动扫描日志	直接删除状态文件
文件拒绝访问	路径解析、权限、只读挂载、符号链接	真实路径、账户、ACL 和失败码	用管理员账户掩盖路径问题
浏览器无法启动	浏览器依赖、配置目录、图形会话、端口	浏览器进程、配置路径、启动错误	复用个人主配置排障
本地端口冲突	监听地址和已有进程	端口占用者及绑定地址	随意改端口却不更新配置
网络中断	执行端连接、DNS、代理、防火墙	连接目标和失败阶段	将所有出站网络一次性放开
执行端限流	服务端配额、并发、重试策略	限流响应与重试记录	通过无限重试放大副作用

检查监听地址时，应在运行 OpenBot 的主机上使用系统工具，而不是只相信界面显示：

ss -ltnp

lsof -nP -iTCP -sTCP:LISTEN

Get-NetTCPConnection -State Listen

重点不是端口是否“本机可用”，而是它究竟绑定在环回地址，还是所有网卡地址。还需要把进程 PID 与实际用户对应起来：

ps -o user,pid,ppid,etime,command -p <PID>

如果问题只在任务执行阶段出现，再检查执行端适配；如果任务完成但产物缺失，则优先检查回写路径和权限。分层定位可以避免把认证失败误判成队列故障，也避免用重装抹掉本可用于恢复任务的现场。

权限边界要沿着执行通道逐项收紧

本地优先架构的安全配置不能只写成“注意保管密钥”。更有效的做法，是把每一种真实执行通道映射到资产、允许范围、确认点和失败后的残留状态。

下面是一份团队自有的策略示例，不是 OpenBot 原生配置格式，不能直接当作应用配置加载。真正的限制应由操作系统权限、代理、防火墙和凭据存储共同执行：

deployment:
  profile: "pilot"
  workspace_root: "<试点工作区绝对路径>"
  executor: "<单一执行端>"
  filesystem:
    write_roots:
      - "<试点工作区绝对路径>"
    allow_delete: false
    block_symlink_escape: true
  browser:
    profile: "<独立浏览器配置目录>"
    download_root: "<独立下载目录>"
    reuse_personal_profile: false
  network:
    mode: "allowlist"
    allowed_hosts:
      - "<执行端实际所需主机>"
  confirmation:
    irreversible_actions: "required"
  secrets:
    source: "environment_or_secret_store"
    redact_logs: true

凭据只留在受控存储

需要保护的资产至少包括 API 凭据、源代码、提示词、任务历史、Cookie、下载文件、日志和模型响应。凭据应优先进入仓库实际支持的受控存储机制；没有专用机制时，才考虑环境变量或独立凭据文件。

环境变量也有局限：它可能被子进程继承，也可能出现在诊断信息或崩溃报告中。因此还要限制执行器进程能够读取哪些环境变量，不把同一凭集传给不需要它的工具。不同执行端、不同工作区和不同代理应使用可独立撤销的凭据。

密钥不能写入仓库、普通工作区文件、任务提示词、命令行参数、Shell 历史或日志。部署检查时，应搜索配置文件和日志中的常见密钥前缀，但不能只靠正则扫描代替权限控制。凭据轮换应先在测试工作区验证，再逐个替换；撤销旧凭据后，还要确认任务队列不会因为缓存凭据继续执行。

文件访问限制在工作区

文件工具应被限制在一个专用低权限账户能够访问的根目录中。输入可以只读，输出写入单独子目录，删除能力默认关闭。允许共享时，应明确是单向复制、只读挂载还是双向路径映射，并记录共享清单。

必须测试符号链接、路径穿越、硬链接、文件名编码差异以及工作区之间的交叉访问。路径检查还要避免“先检查、后替换”造成的竞态：如果检查后文件链接被改变，实际写入仍可能越界。

仅划分工作区目录并不能形成安全沙箱。即使目录分开，如果执行端进程仍以同一高权限账户运行，仍可能读取其他工作区、系统凭据或浏览器配置。真正的边界需要账户、ACL、子进程权限和网络策略共同建立。

浏览器使用隔离会话

浏览器控制应使用独立配置目录或独立账户，不能复用个人日常浏览器的登录态、扩展、Cookie、下载记录和密码管理器状态。即便磁盘上的 Cookie 由浏览器加密，应用只要以同一账户启动浏览器，就可能间接取得这些能力。

受控试点应限制可访问站点和下载目录，关闭不必要的扩展与剪贴板能力。删除文件、提交表单、发送消息、付款、修改账号安全设置等不可逆动作应在执行前要求人工确认。确认不能只是一个会被提示注入绕过的页面按钮，高风险操作最好在应用之外完成。

浏览器异常退出后的恢复也需要验证。Cookie 被保留可能提升便利性，也可能扩大凭据泄露范围；不保留则意味着重新登录和任务中断。两者都应被记录为明确的产品选择，而不是偶然行为。

本地服务默认不暴露公网

本地服务即使只绑定 127.0.0.1，也不应被视为自动安全。管理界面仍需要身份认证、会话保护、来源检查和适当的跨域限制。本机上的恶意网页、错误开放的端口或权限过宽的进程，都可能成为访问入口。

确需远程使用时，应先让服务保持本机监听，再通过 VPN 或 SSH 隧道访问，并叠加独立身份认证。通用隧道形式如下，端口和主机必须替换为实际配置：

ssh -N -L 127.0.0.1:<本地端口>:127.0.0.1:<远端端口> <user>@<host>

防火墙规则应只允许必要来源。不能把桌面管理端点、浏览器调试端口或执行端代理直接映射到公网，也不能用“知道端口”作为访问控制。

外部内容按不可信输入处理

网页、仓库文件、Issue、代码注释、下载文档和工具输出都应被视为不可信输入。它们可能包含要求 Agent 读取凭据、上传文件、访问内网、修改配置或执行命令的提示注入内容。

控制方式不是简单地过滤某几个关键词，而是缩小工具权限：网页内容只能进入受控数据通道，不能直接改变系统提示；文件读取限制在工作区；网络访问采用允许列表；凭据读取与普通工具分离；不可逆动作必须由用户确认。模型输出本身也不能被视为可信命令，因为它可能受到外部内容诱导。

更新与扩展先审后装

升级前应固定应用版本、依赖版本和浏览器组件版本，审查安装脚本、依赖变更和新增权限。正式包应保存来源与校验值；源码构建应保留锁文件和对应提交号。浏览器扩展或插件的权限变化也应单独审查，不能因为主程序通过测试就默认接受。

更新流程应先在无敏感数据的测试工作区运行旧任务迁移测试，再灰度到少量工作区。保留上一版本安装包和升级前状态快照，确认回滚路径不会与新版本写入的数据格式冲突。

日志与遥测按需开启

日志至少可能包含任务提示、文件路径、命令、模型请求与响应、浏览器内容和错误堆栈。排查所需字段应按最小化原则开启，对密钥、Cookie、源代码和用户标识进行脱敏。崩溃报告也需要检查是否包含环境变量、请求正文或工作区内容。

本地优先不自动等于没有遥测，也不自动等于日志只在本机。应通过配置、运行观察和网络检查确认实际发送内容，并设置明确的保留期限。定期轮转、归档和删除日志，同时保留验证任务恢复所需的最小状态，而不是把所有历史永久留在磁盘上。

本地优先的默认数据落点与外传边界

OpenBot 的产品定位把本地工作区放在默认控制面，但几个常见推论并不成立：

产品表述	可以成立的解释	不能直接推出的结论
Local-first	默认控制、任务编排和工作区位于用户可控环境	所有推理都在本地、完全没有网络请求
Persistent AI teammates	工作流可以跨会话保留部分状态	每个任务都能断点续跑且只执行一次
Dedicated workspaces	不同执行端或任务有独立目录与配置	已具备进程、权限或网络沙箱
Browser control	Agent 可以在受控浏览器中执行动作	可以安全复用个人登录态或直接处理付款等操作

代码进入工作区后，可能被读取为任务上下文并发送给 Codex、Claude、Grok 或其他服务；网页内容也可能进入模型调用；工具输出则可能进入日志。所谓“本地保存”描述的是默认落点，不代表数据从未离开设备。

因此，离线能力要通过断网实验确认：哪些功能仍可使用，哪些执行端会立即失败，失败任务能否稍后恢复。在线执行端的数据范围则要结合适配代码和网络目的地确认。判断本地优先是否达到预期，必须同时回答“数据默认放在哪里”和“哪些内容会被主动发送出去”。

升级之前先备份再验证

升级风险不只来自新版本代码，还来自旧状态被新版本迁移后继续执行。应分别备份四类数据：

数据类别	备份重点	恢复测试	主要风险
配置	工作区绑定、执行端设置、权限策略	在隔离环境加载并比较差异	凭据或旧端点被继续引用
队列记录	完整状态快照、任务标识和状态字段	新版本读取后逐项核对	旧任务被自动重放
工作区产物	输入、输出、哈希和目录结构	恢复后确认文件完整可读	半写文件或覆盖冲突
浏览器状态	独立配置、登录状态、下载目录	验证能否安全加载和注销	Cookie 或会话泄露

“配置可迁移”“任务记录可恢复”和“旧任务可以安全继续执行”是三件不同的事。恢复队列后，应先阻止高权限任务自动继续，人工检查目标、工作目录、执行端和待执行动作，再决定是否重新投递。

升级流程还应包含凭据轮换、日志到期清理、历史任务归档和卸载残留检查。删除应用不等于删除工作区、浏览器配置、缓存和日志；卸载脚本未覆盖的目录应由资产清单单独管理。

先小范围试用再逐项开放权限

落地时仍需核验的问题至少有四个。第一，持久化是否具备可靠幂等性，仍取决于队列提交、恢复和结果回写的具体顺序；第二，专用工作区是否等同于安全沙箱，取决于进程、文件与网络权限是否同时受限；第三，本地优先能否在断网环境下工作，取决于执行端是否完全依赖远端服务；第四，浏览器控制如何避开高风险操作，需要独立会话、细粒度授权和人工确认共同完成。

更稳妥的落地顺序是从无敏感代码、单工作区、单执行端和低权限账户开始，先验证任务、文件与浏览器三条链路，再逐步开放写入、网络和多代理能力。每个阶段都保留状态矩阵、故障注入记录和回滚材料。恢复过程不会重复副作用、工作区边界通过越界测试、日志不泄露敏感资产，这三项得到验证后，local-first 才能从产品定位落实为可依赖的工程边界。