企业官网建设流程全解析

Rakazo终极拆解：如何让每个机器人拥有独立Linux桌面的Computer运行时架构

【免费下载链接】rakazoOpen-source Grok Bot alternative. Choose your own model and sandbox.项目地址: https://gitcode.com/gh_mirrors/ra/rakazo

Rakazo 是一个开源的 Grok Bot 替代品，核心理念是"AI 队友归你所有"：模型、密钥、沙箱都由你自己选择。而它最硬核的设计之一，就是让每个机器人（Bot）都拥有独立的 Linux 桌面——独立的屏幕、独立的浏览器配置、独立的文件空间。本文带你完整拆解 Rakazo 的 computer 运行时架构，搞懂它背后的多屏调度、沙箱抽象与持久化机制。

整体架构：Agent 与 Computer 彻底分离

Rakazo 在设计上刻意把两层运行时拆开了：Agent 运行时（对话、推理、工具调用）跑在 Rakazo 自己的 API/Worker 进程里；Computer 运行时（屏幕、终端、文件）则运行在可插拔的沙箱后端里。两者的通信链路是：

chat/API -> Pi agent 会话 -> Rakazo computer 工具 -> SandboxProvider -> Docker / E2B / Daytona / Box / desktop / fake

这里有一个关键事实：Pi（Agent 执行内核）不是安装在 E2B 或任何沙箱里运行的，它始终在 Rakazo 服务端。内置的桌面工具是普通的 Pi 工具，不依赖任何特定模型或 MCP，所以任何通过 Pi 暴露的模型都能调用。唯一的要求是：要操作屏幕，模型必须能看懂截图这类图像工具结果。

这套边界的详细约定写在官方文档 docs/computer-runtime.md 中，值得作为第一份阅读材料。

两种计算机模式：Team Computer 与 Private Computer

Rakazo 为每个工作区默认提供一台Team Computer，同时支持完全隔离的Private Computer：

• 🤝Team Computer（共享模式）：团队里的机器人共享同一台计算机的文件和已安装工具。每个 Bot 默认工作在自己的bots/<bot-id>/目录下，刻意要共享的成果放在shared/。注意：这些目录只是工作组织方式，不是安全边界——每个 Bot 都能访问整台工作区的文件。
• 🔒Private Computer（独占模式）：整台计算机的整个工作区就是这一个 Bot 的家，工作负载互相不信任时用这种模式。

一句话经验法则：需要隔离，就开多台 Computer，而不是一台机器里"靠目录自觉"。

核心机制：每个 Bot 一个 X 显示 + 持久浏览器配置

这是全文最值得展开的部分。在支持图形界面的 Computer 上，Rakazo 给每个活跃的团队 Bot 分配：

• 独立的 X 显示（X display）：每个 Bot 看到一块"自己的屏幕"；
• 独立的 Chrome 进程 + 持久配置（Profile）：Profile 按 Bot 身份建立索引，登录态、Cookie、浏览历史完全独立；
• 绝不清空或合并：Profile 永远不会从另一个 Bot 克隆、合并，或在桌面释放时被删除。两个 Bot 的修改都会保留；即使 Bot 重新打开时换了显示槽位，用的还是它原来的 Profile。

多 Bot 并发靠一套**围栏式数据库租约（fenced lease）**协调：不同 Bot 可以同时操作各自的桌面，但同一个 Bot 同一时间只有一个桌面驱动。屏幕租约协调的是工具调用，而不是机器内部互相不信任的进程。

还有一个省电设计：桌面栈是懒加载的——只有当 Bot 真正用到图形工具时才启动桌面。没有 Bot 用图形界面时，就不会有空跑的 Chrome。默认没有"桌面数量上限"，一台 Computer 可以容纳 100 个以上 Bot 的 Profile；并发桌面数只受内存、CPU、进程数和可用调试器端口的物理限制。Docker 运营者可以用SANDBOX_TEAM_SCREEN_LIMIT设置硬性上限，超出时返回MULTI_SCREEN_UNAVAILABLE，但 shell 和文件工具依然可用。

屏幕网关：一个端口服务所有桌面

你可能以为每开一块屏就要多暴露一个端口，Rakazo 反着来：所有桌面共享同一个带令牌保护的屏幕网关，因此无论多少 Bot 桌面都不需要发布更多端口。细节包括：

• 查看（view）与控制（control）使用两套独立的、可撤销的 WebSocket 能力；
• 每个能力绑定一个唯一的本地 Unix socket，显示槽位被回收后，旧连接不可能被误导向下一位"住户"；
• 拆除（teardown）前先断开客户端，失败则保留槽位等待重试；
• 人类与 Agent 的输入可以共存于不同的屏幕。点击Take control会给用户发放该 Bot 屏幕的独占控制租约；若 Bot 正在执行或持有运行中任务，接管会被 409 拒绝（提示"先停止机器人"）。

网关在容器内的实现是 noVNC + websockify，令牌插件挂载在view-target文件上，相关源码见 start.sh。

沙箱后端：Docker、E2B、Daytona、Box 共用一套契约

SandboxProvider是 Rakazo 的后端抽象边界，任何后端只需实现四组能力：

1. 生命周期：provision / reconnect、stop、destroy；
2. 桌面：观察（截图）、有序批量操作、用户输入、实时屏幕会话；
3. 执行：机器内运行命令；
4. 文件：list/read/write + 完整工作区导入导出。

各后端的差异化实现：

• 🐳Docker：最完整的本地方案。桌面生命周期命令与其他后端完全一致，且额外实现了pageBrowser契约，让模型能通过browser_navigate、browser_snapshot、browser_act三个工具直接驱动可见的 Chromium 标签页——不需要任何托管浏览器服务或 API Key。
• ☁️E2B：基于@e2b/desktop处理生命周期、shell、文件和端口 URL，每个 Bot 桌面走同一套 Linux 运行时。
• 📦Daytona：数据库里只存 provider 类型和不透明的providerRef——这只是加速路径而非持久数据。机器丢失或换 provider 时，通过 provider 无关契约重建并恢复工作区。
• 📬Box：使用官方 TypeScript SDK，机器创建/恢复时noEnv: true，两小时 TTL 在活跃期间续期；共享运行时在 Box 上创建每 Bot 显示，通过受保护的host <port> --private路由暴露，而非默认桌面 API。

各后端的源码入口：docker-sandbox.ts、e2b-sandbox.ts、daytona-sandbox.ts、box-sandbox.ts。

Docker 桌面镜像里装了什么

Rakazo 的 Computer 镜像基于debian:bookworm-slim，是一个精心裁剪的"可用桌面"：

镜像以 uid 1000 无特权用户运行，运行时无法再安装系统软件——想要更重的工具链应通过可复现的镜像或安装脚本来表达，这正是后文"换后端"能成立的原因。完整定义见 infra/sandboxes/computer/Dockerfile。

持久化：便携工作区是唯一的持久边界

Rakazo 把"什么会丢、什么不会丢"划得非常清楚：

• 会持久：便携 Computer 工作区（含bots/、shared/、.browser-profiles/下的浏览器 Profile）+ 持久 Home 下的 uv 工具环境与命令垫片；
• 不会持久：工作区之外安装的系统包（如 apt 依赖）。一次性 OS 镜像不是磁盘快照，换机器就没了。

工作区在三个边界点被 checkpoint 到AgentHomeStore（DATA_DIR/homes/<computer-home-key>）：

1. 运行完成或失败时；
2. 显式停止前；
3. 空闲挂起前。

新机器或替换机器在使用前会先导入最近一次存储的工作区。导出远程工作区前，后端会先让桌面浏览器"静默"，保证 Profile 数据库和登录态被一致拷贝；只有.browser-profiles里的临时缓存/锁文件被排除。生产部署需把DATA_DIR放在 Rakazo 自有的持久卷上并加密、异地备份。这套机制让"未来从 E2B 迁到 Daytona"变成一件可以实际操作的事，而不是试图翻译厂商私有 VM 快照。

终端与文件窗口：看得见的操作历史

Web 和桌面端的 Computer 视图在屏幕上方有一个 dock，可以从里打开终端和文件浏览器：

• 💻终端展示 Bot 在计算机上做过的每件事（实时和历史）：shell命令（脱敏后 + 输出尾部）、write_file/attach_file/open_path/launch_app（各一行，含写入大小或错误）。只读工具如read_file不记录；
• 📁文件浏览和文本预览在计算机停止时也能通过存储的工作区进行；窗口可见时目录会定期自动刷新，Bot 的每次改动无需重开即可看到；下载和上传则需要计算机处于运行状态。

安全边界与运维：租约、更新与恢复

几个容易被忽略但很关键的细节：

• 容器即安全边界：CDP（Chrome 调试协议）只绑定容器 loopback 接口，不作为主机端口发布；
• 更新与恢复是持久化后台作业：Computer 级预留（reservation）会在操作期间排除新的执行租约、停止、接管和空闲挂起；进度独立于 provisioning fence 存储，报告的是真实生命周期阶段而非估算百分比；
• 崩溃恢复：停止心跳 10 分钟的 Worker 被标记为 interrupted 并持续保留预留；若 Worker 永久消失，服务器属主需在确认 Worker 与 provider 操作已停止后，才能用 server-owner 专属的Release computer动作释放。仅凭一个陈旧心跳，永远不足以授权接管。

多 Bot 桌面的并行性由回归测试保证：Docker 回归测试会在隔离容器（禁用网络 + 假浏览器状态）中验证并行 Chrome 桌面访问不同站点、独立 Cookie、释放后的 Profile 持久化、传输拆除以及槽位复用后旧 view/control 令牌被拒绝，测试文件见 team-desktops.docker.test.ts。

本地跑起来：从零到一块屏幕

想亲手验证这套架构？最快的路径是 clone 仓库后按自托管指南启动 Docker 栈：

git clone https://gitcode.com/gh_mirrors/ra/rakazo cd rakazo

本地 Docker Computer 默认开启，打开 Web 端创建一个 Bot，让它执行任何需要浏览器的任务，右侧就会出现它的专属 Linux 桌面——就像上文截图里 Chief 正在打开的 Google 首页那样。自托管细节见 docs/self-host.md，可选远程沙箱（E2B / Daytona / CreateOS / Box）的配置见 docs/self-host-sandbox-providers.md。

小结

Rakazo 的 computer 运行时架构可以用四句话概括：

1. 分离——Agent 推理在服务端，桌面操作在沙箱，中间是干净的SandboxProvider契约；
2. 隔离——每 Bot 一个 X 显示、一个 Chrome Profile、一套围栏租约，状态永不串号；
3. 可插拔——Docker、E2B、Daytona、Box 共享同一套生命周期命令，换后端只需恢复工作区；
4. 可持久——便携工作区是唯一持久边界，checkpoint 时机明确，迁移不依赖厂商快照。

这套设计让"每个机器人一台自己的 Linux 桌面"不是一句营销口号，而是一套有契约、有测试、有恢复路径的工程实现。

【免费下载链接】rakazoOpen-source Grok Bot alternative. Choose your own model and sandbox.项目地址: https://gitcode.com/gh_mirrors/ra/rakazo