个人 AI 工作空间为何需要“边缘常驻 + 按需沙箱”

Bibo · 个人 Agent 基础设施

不必让 Linux 一直开着，但成果应该留得住。

山行 AI

让 AI 清洗一次 CSV，只用几分钟；等你第二天再打开，结果却可能留在已经回收的容器里。反过来，为了偶尔跑一次 Python，让 Linux 一直开着，也有闲置成本。

个人 AI 工作空间要处理的，就是这两件不应绑在一起的事：随时能回来找成果，以及需要时才启动系统计算。

Bibo 给出了一种拆分：日常对话和个人空间由 Cloudflare Workers、Durable Objects 承接；真正需要操作系统工具时，再获取 Linux 沙箱。文件独立放在 R2，不随临时执行环境一起消失。

这是一套个人 Agent 基础设施的设计选择，不是所有场景都更便宜的结论。下面沿着“对话—执行—保存—再打开”的链路拆解。项目仍处于早期，没有统一成本基准测试，也没有固定月费或免费承诺。

Bibo 对话旁打开已保存的销售报告；报告明确标注为示例数据

本文看点

Bibo 不只是给对话加一个“执行代码”按钮。它把笔记、文件、任务、日历和收件箱做成独立入口，Agent 可以整理这些对象，人也能直接打开、编辑和继续处理。

概览把正在推进的任务、近期日程、笔记和待关注信息放在一起。这里的价值是让对话产生的内容回到可管理的对象，而不是只能翻聊天记录。

Bibo 概览：笔记、任务、日程和收件箱集中呈现，内容为作者演示样例

笔记是可编辑的 Markdown 文档。让 Agent 保存报告后，用户可以继续修改；任务则有完成状态、优先级、描述和时间等字段。

笔记编辑器中的销售报告，示例数据提示保留在正文中

任务列表及可编辑详情：分析结果可以转成后续行动记录

日历用于查看、管理日程；收件箱放需要关注或确认的内容。它们是已有的工作空间能力，但可编辑任务、日程不等于已经具备无人值守的定时执行系统。需要自动行动时，还要核对具体触发、权限和失败处理机制。

日历与近期安排；截图中的日程为示例

收件箱中的销售分析待确认项：保留人工判断的入口

这个说法更适合理解为：个人空间有持续可访问的入口，身份、会话和业务状态能够持久保存。它不意味着每个人都有一个永不休眠的 Worker 进程，更不意味着模型在 Cloudflare 边缘本地推理。

请求先经过 Worker，再进入单人工作空间的 Durable Object。公共 NextClaw Harness 负责 Agent 执行；Bibo 组合自己的领域工具、文件工具与系统执行工具，没有另写一套平行的 Agent 循环。当前模型调用仍发送到 DeepSeek API。

Durable Objects 保存会话和结构化状态；R2 保存文件内容；Linux 沙箱承担 OS 工作。网页与 Agent 复用同一个领域动作 owner，减少“聊天里已经完成，任务页却没有同步”的双重逻辑。

职责架构：入口、领域状态、模型网关、持久文件和按需 Linux 分开；箭头表示主要调用关系

这套分层让“打开笔记”“修改任务”不必先启动 Linux。没有系统工具调用时，执行服务不会获取沙箱；需要 Python、Shell 或命令行工具时，才走 OS 分支。

代价也很明确：这不是一台完整服务器的透明替身。运行时、文件存储和系统环境分属不同服务，开发者要处理路径、挂载、状态恢复和失败边界。

Bibo 的一个具体实现点是：网页文件页和沙箱挂载目录，对应同一份 R2 文件。mount_directory 挂载已有的持久目录，exec 可以在挂载路径里读写；不是执行完才把一个临时副本搬回网页。

这样，清洗结果可以被网页重新打开，也可以在后续对话里继续使用。文件目录还能搜索、预览和编辑，Markdown 文件可作为笔记呈现。

个人文件目录与已保存的清洗订单 CSV

另一份文件空间展示：原始订单、清洗 CSV、说明和脚本放在同一目录

这里最容易弄错的是保存位置。/workspace 是沙箱临时目录，适合 Git 仓库、依赖和安装软件；持久目录需要显式挂载。当前实现返回的挂载路径是 /mnt/bibo-data/1，不能把“写过一个文件”自动理解为“已经持久化”。

网页编辑包含文件版本检查，覆盖旧内容前会判断对象是否变化。但持久保存本身不是备份，也不是 Agent 误删后的自动撤销。重要数据仍应另留副本；最好只挂载本次任务需要的目录。

当前执行服务通过 Cloudflare Sandbox SDK 获取沙箱，默认空闲 5 分钟后休眠。同一个命名环境可以跨对话轮次复用，但保存着环境句柄，并不能证明 Linux 仍然存活。

临时系统、安装的软件、Git 和未写入持久目录的文件，在回收后不能依赖它们继续存在。需要长期成果时，保存数据和报告；需要重复执行时，还应留下脚本和可重建依赖说明。

生命周期示意：临时 OS 与持久数据分开；环境句柄不代表活进程，R2 也不代替备份

工具层不只有 exec。execution_environment 能列出环境、释放实例、启动后台进程、查看进程与日志，或续期保留租约。后台保留需要明确时长，当前范围为 1—1440 分钟，保留期间仍会计费，不能把它当作免费的常驻服务。

前台命令与整次 Agent 任务也有不同限制：源码中前台命令默认超时为 60 秒，整次任务最长 10 分钟。长工作流可能需要后台进程和租约管理，而不是反复延长一句对话。

回收失败、挂载失败、进程超时应成为可见状态。项目为已有 FUSE 挂载的恢复、进程取消和租约回收设置了处理逻辑，但这些机制仍需要在实际部署环境中验证。

作者公开的订单示例有 7 行原始记录，去掉两行完全重复项后，留下 5 笔订单、9 件商品，总额 214 元。清洗后的 CSV、说明与 Python 脚本保存在个人文件空间。

作者的线上订单清洗演示：示例数据、计算结果和执行环境信息均有说明

已展示的五笔订单金额为 36、25、56、22、75，合计 214；数量为 2、1、2、1、3，合计 9。这些数字可以从示例 CSV 复核，但这不是生产订单，也不是通用数据清洗准确率测试。

更值得看的是交付链：读文件、按整行去重、计算金额、运行 Python、保存结果和脚本、再在网页里读回。说明中记录了作者运行时读取到的 Linux 与 Python 信息，不只是模型口头说“我算完了”。

另一个示例把前 20 个斐波那契数写进文件，用来说明系统执行与文件展示可以连起来。这里保留作者的执行记录，不把它冒充为本文重新部署后的实测。

作者提供的沙箱执行记录：环境信息与保存的斐波那契结果

对于自己的数据，建议保留输入、处理脚本、输出、退出码和说明，并重新打开输出验证。仅有一段漂亮的聊天回复，不足以确认命令成功，更不足以确认结果已经落到持久存储。

个人工作空间经常要在桌面与手机之间切换。Bibo 把运行任务交给服务端管理，页面订阅同一个任务的状态；离开或刷新页面，不直接成为取消任务的动作。

手机上的对话与报告摘要，仍标明示例数据

手机任务列表：已保存的行动记录可以继续管理

但“页面回来还能查看”与“服务中断后自动恢复执行”是两件事。源码在发现中断的运行记录时，会标记失败，提示已执行操作仍保留，请先查看结果；不会悄悄重放整个任务。

这是有实际意义的取舍：一次任务可能已经写文件或创建待办，直接从头重跑会重复产生副作用。任务状态可恢复，不代表每一步执行都能无损续跑。

也不能把 10 分钟的有界任务理解为全天候后台 Agent。需要持续采集、定时触发或多天计算时，应单独设计调度、任务队列、重试和预算。

这套结构的收益来自一个假设：个人用户大部分时间在对话、读文件和管理记录，只有少部分工作需要 Linux。把系统计算按需启动，可以减少为了偶尔执行一次脚本而承担的闲置容器开销。

实际费用仍包含 Cloudflare 套餐、Workers／Durable Objects／R2 用量、沙箱资源，以及模型和可选搜索 API。没有统一测量数据，就不能写出“每月只要几元”或“比 VPS 便宜多少倍”。

可以分别记录三个维度：不触发 Linux 的日常请求；包含冷启动、执行与空闲等待的沙箱任务；同一任务中的模型与搜索调用。比较时使用相同负载，并把失败、重复调用和保留租约计入。

当前版本使用 deepseek-flash，单次调用最多 2048 个输出 token；一个 Agent 任务可以多次调用模型。额度护栏为每位用户每个 UTC 日 250 次模型调用、部署级每日 2000 次，以及每小时 100 次聊天运行；搜索另有额度。部署模板还把 basic 沙箱实例上限设为 2，命名环境多不等于计算并发无限。

250 次模型调用不是 250 条用户消息。 工具调用后的再推理、上下文总结等可能继续消耗调用。部署级上限也不是单人空间能绕过的额外额度。限次能帮助控制风险，但不能单独给出精确金额上限。

开源版本是单人私有空间，不开放公共注册，官方托管版与自部署版的账号、存储分开。部署需要支持 Sandbox／Containers 的 Workers Paid 账号、R2，以及自己的 DeepSeek API Key；联网搜索可另配 Exa。

所有者密码、模型与搜索密钥应放在 Worker Secrets，不写进 wrangler.toml 或 VITE_ 前端变量。单人登录使用签名会话与 HttpOnly／Secure／SameSite Cookie，更换密码会使已有登录失效。这不等于具备企业多租户权限体系。

模型和搜索服务商仍会收到调用所需内容。把文件放到自己的 Cloudflare 账号，并不能推出“数据永不离开你的控制范围”。沙箱能访问网络，也能修改挂载文件；隔离系统环境不等于限制了每个 Agent 动作的影响。

升级时保留 Worker、bucket 和 Durable Object migration 的身份，避免把已有数据留在另一套资源里。早期项目还应准备独立备份和恢复检查，不把截图里的“已保存”当作灾备方案。

边缘入口＋按需沙箱适合间歇使用、重视跨设备成果留存、愿意接受 Cloudflare 服务约束的个人工作空间。它把数据与系统运行分开，代价是挂载、冷启动和状态管理更复杂。

常驻 Linux／VPS更适合频繁执行、依赖长期安装环境、持续后台进程或稳定系统集成的工作。环境一致性更直接，但要承担闲置资源、安全更新、备份与运维。持续高负载时，按需方案未必更划算。

建议验证流程：先确认需求与保存位置，再验证回收、失败和费用；不代表本文已完成云端部署

试用可以从一个无敏感信息的小任务开始：

本地界面预览需要 Node.js 22.23.2 或更新版本、pnpm 9.15.1。安装后运行 pnpm dev，打开本地 5188 端口，只是无需凭据的模拟界面，不能证明真实模型与 Linux 已接通。完整能力要按项目步骤部署 Cloudflare；本地 Worker 的真实沙箱开发还需要 Docker。

这篇文章依据公开说明、截图与固定版本源码整理，没有替你创建云资源、输入生产密钥或执行线上模型任务。工程选择最终要通过自己的负载、回收测试和账单验证，而不是只看功能演示。

个人 Agent 的基础设施，至少要同时回答三个问题：平时怎样接住对话，需要时在哪里执行，执行完留下什么。

Bibo 的分层让这三个问题有了不同的承担者。聊天与业务状态不必依赖 Linux 常驻，系统工作又不被限制在纯文本里；成果通过独立文件空间留下来。它值得借鉴的是这种职责分配，至于价格、可靠性和使用边界，还要按自己的任务验证。

我是山行 AI，持续分享 AI 工具与开源项目观察。

声明

本文由山行整理自：项目（https://github.com/Peiiii/bibo）、中文项目说明（https://github.com/Peiiii/bibo/blob/main/README.zh-CN.md）、安全边界（https://github.com/Peiiii/bibo/blob/main/SECURITY.md）、原始投稿（https://github.com/ruanyf/weekly/issues/12064），如果对您有帮助，请帮忙点赞、关注、收藏，谢谢～