rakazo
elie222/rakazo加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
图：Rakazo Web 端的 Agent Computer 视图，机器人运行在独立的图形化沙箱中
想象这样一个周一早晨：你打开电脑，发现昨晚给它派的两项任务已经做完了——一个把上周客户反馈整理成了带图表的报告发到邮箱，另一个在测试环境里复现了一个只在夜间出现的崩溃，附上了完整日志和最小复现步骤。你没有半夜起来盯着一段命令行，也没有去改任何配置文件去"唤醒"它。
这不是某个演示视频里的桥段，而是 elie222/rakazo 想解决的核心问题。2026 年下半年，随着 xAI 的 Grok Bot、Meta 的 Muse、OpenAI 的 Dots 这类"托管型 AI 助手"相继发布，行业里出现了一个共同的产品形态：一个有名有姓的 AI 队友（bot），有自己独立的对话、记忆、日程和一台专属的电脑。区别在于——这些托管产品的电脑在厂商云上，模型是厂商指定的，你只是租客。
Rakazo 走的是完全相反的路：Apache-2.0 开源、你自己部署、你自己带模型 Key、机器人自己有一台可以真实操作浏览器的 Linux 图形桌面。截至 2026 年 10 月 21 日，它在 GitHub 上已经收获 5023 星、906 个 fork，126 位贡献者，从 2026 年 8 月 13 日创建至今不到三个月。
先说清楚"持久化队友"和"一次性问答"的区别。传统 ChatGPT 式的对话是无状态的：窗口一关，上下文就没了；任务只能在你盯着的时候推进。而 Rakazo 定义的 bot 是一个持续存在的身份——它有自己的线程（thread）、自己的记忆（memory）、自己的例行程序（routines，用可读的 Markdown 编写）、自己的历史记录，以及自己的一台"计算机"。
这个产品理念在仓库的 VISION.md 里写得非常清楚："Rakazo exists so that people can own AI teammates that persist, use computers, and finish work beyond a single chat."（Rakazo 的存在，是为了让人们拥有能持续存在、能使用计算机、能在单次聊天之外完成工作的 AI 队友。）文档里还专门强调，把 bot 降格成"提示词预设"或"孤立的一次性任务"，是违背产品目标的。
技术上的支撑是"计算机"这个抽象。一个 bot 的"计算机"不是抽象的工具调用，而是一台真实的机器：可以打开浏览器、访问终端、读写文件、操作图形桌面。Rakazo 把计算机分为两类——Team Computer（同一信任域内的 bot 共享文件、已安装工具和一套签入状态的浏览器身份）与 Private Computer（完全隔离，用于敏感文件和独立身份）。这种设计直接对应了真实团队的"共享工位"与"独立工位"。
如果要用一个生活化的比喻，Rakazo 更像是你招了一个实习生，然后给他配了一间有电脑的工位。
你告诉他：这个同事叫什么、做什么工作、每周一早上要给我交一份周报。实习生自己会写周报、写完放到共享目录（Artifacts），遇到需要你签字的事会停下来问你。你不需要教他用电脑，也不需要半夜检查他干到哪了——他下班了，明早会带着成果回来。
而 Grok Bot、Muse、Dots 这类托管产品，像是你把活外包给了一家远程公司：对方派人、给你交付，但人是谁、用什么电脑、数据存在哪，你说了不算。Rakazo 的核心主张是：外包你没法签字。
这个类比也解释了为什么 Rakazo 的第一动作是"面试"（interview）。README 里提到"a new bot interviews you"——创建 bot 时它会先跟你确认自己的角色理解，并主动问出还缺什么信息。CHANGELOG 里记录了这条设计背后的原因："A newly created bot's thread opened empty and stayed silent until given real work, so a misread title/description/instructions went unnoticed until it cost a run."（新建 bot 的线程原本是空的、一直沉默，直到你给它派了真实工作才暴露问题，导致角色理解错误白跑一轮。）现在创建时会自动排入一轮开场，让 bot 先复述它如何理解自己的职责。
图：Rakazo 的机器人管理视图，bot 拥有独立的记忆与例行程序
Rakazo 的 infra/sandboxes/computer/Dockerfile 是全仓技术含量最高的文件之一。它从 debian:bookworm-slim 出发，用多阶段构建编译了一个叫 xcapture.c 的 C 库（链接 X11/Xext/Xdamage/Xfixes/Xtst/libpng），实现屏幕捕获能力——这是让模型"看见"桌面操作结果的技术前提。运行阶段装入了 Xvfb、X11VNC、Fluxbox 窗口管理器、Chromium、noVNC、websockify、ImageMagick、xdotool、wmctrl，以及中文字体（fonts-noto-cjk）。
也就是说：bot 看到的是一个真桌面——它有窗口、有图标、有浏览器，能截图给自己看，能用 xdotool 敲键盘。这跟"调用一个 search API"是完全不同的能力层级。
沙箱提供方是可插拔的：本地 Docker（默认）、E2B、Daytona、CreateOS、Boat、Railway，以及"信任的本地计算机"。packages/adapters/src/ 目录下有 451 个 TS 文件，其中能直接看到 e2b-sandbox.ts、daytona-sandbox.ts、createos-sandbox.ts、boat-sandbox.ts、docker-sandbox.ts、railway-sandbox.ts 等并列实现——同一个接口背后六种完全不同的基础设施。
模型层用的是 Pi（AGENT_RUNTIME: pi），支持 OpenAI、Anthropic、Google、OpenRouter、Vercel AI Gateway、OpenAI 兼容端点，以及本地服务（Ollama、LM Studio、llama.cpp、MLX）。每个 bot 可以挂不同模型——便宜的模型做例行分诊，强模型做写作分析，这种成本结构在托管产品里是做不到的。
packages/memory/src/index.ts 里的 MarkdownMemoryStore 是个有意思的设计：记忆以 Markdown 文档形式存储在 Postgres 里（memoryDocument 表，带 revision 版本号和乐观并发冲突检测 MEMORY_REVISION_CONFLICT_ERROR），并且声明了 markdownPortable: true 能力——记忆可以导出、迁移。配套的还有 honcho-memory-provider.ts（Honcho 记忆后端）和本地 Supermemory 方案。
bot 可以在越过你设定的边界时暂停等授权，所有动作落进你自己保留的审计日志。这在自托管场景是刚需——毕竟 bot 手里握着能操作浏览器的真实凭据。
语音支持自带 Key 的 ElevenLabs、OpenAI、Cartesia、Fish Audio，可以语音回复、语音输入，甚至打电话给 bot。集成层包含 Composio、Pipedream Connect、用户自装的 Treg、远程 MCP 服务器、以及 OpenAPI 文档源，还能挂 Slack、WhatsApp、Telegram、iMessage、飞书/Lark（飞书走 /api/v1/messaging/webhook/lark Webhook 入口）。
Web 端、Electron 桌面端、Expo 移动端（iOS/Android）都是同一套 API 的客户端。桌面端首次运行会问你：在这台电脑上跑，还是连接已有服务器。选"这台电脑"的话，桌面端会自己用 Docker Compose 把整套栈拉起来（注意它用 45173 端口，正是为了能和开发时的 5173 共存）。UI 已支持 12 种语言：英、德、韩、土、印地、葡、简中、西、俄、法、希伯来、荷。
Rakazo 提供了三种部署方式，门槛差异很大：
路径 A：官方镜像一键装（推荐，最省事）
mkdir -p rakazo && cd rakazo &&
curl -fsSLO https://raw.githubusercontent.com/elie222/rakazo/main/infra/compose/install-images.sh &&
bash install-images.sh
只要 Docker Engine 26+、Compose 插件、curl、OpenSSL。不需要克隆仓库，不需要装 Node。脚本会下载 docker-compose.images.yml、自动生成带随机密钥的 .env、拉取 ghcr.io/elie222/rakazo/app 与 /computer 镜像（多架构 amd64+arm64），然后启动。打开 http://127.0.0.1:5173 注册账号，第一个注册用户自动成为部署所有者。
路径 B：源码开发
需要 Node.js 22.22.2+/24.x/26+（明确不支持 23.x 和 25.x）、pnpm 9、Docker。流程是 pnpm install → pnpm db:generate → pnpm db:migrate → pnpm sandbox:build → pnpm dev。这是标准的 pnpm workspace + Turbo monorepo。
路径 C：Railway 一键部署
仓库里带了 railway.json 和 infra/railway/，README 上有 Railway 部署按钮，填邮箱和 API Token 即可。托管版 Rakazo Cloud（app.rakazo.com）也处于 Beta。
这是最容易踩坑的地方。自托管 Rakazo 实际上要跑五个东西：Postgres、API 进程、Graphile Worker 进程、Web 应用、sandbox supervisor，再加上每个活跃 bot 一个装满图形桌面和 Chromium 的容器。
而 Graphile Worker 的队列是存在 Postgres 里的（WAKEUP_DRIVER=graphile），所以不需要 Redis，也不需要第二个数据存储——但反过来，停掉 Postgres，所有定时 bot 动作立刻全停。
每个 Docker 计算机的默认配额是 RAKAZO_COMPUTER_MEMORY=2g 和 RAKAZO_COMPUTER_CPUS=2（含 swap 上限）。第三方评测（SSD Nodes, 2026-10-10）明确指出：早期 Beta 版本说 2 vCPU / 4GB 够用（前提是 E2B 承担桌面），但现在如果用本地 Docker 沙箱，4GB 只是地板而非目标值，多 bot 常驻建议从 8GB 起步。
这是我觉得这个项目最被低估的部分：
169.254.169.254 这类云元数据地址——在云主机上，这个地址会把实例凭据交给 bot 运行的任何东西。项目用 DOCKER-USER 链实现这一限制，脚本是 infra/compose/restrict-computer-egress.sh。rakazo_app 独立登录角色 + 行级安全（RLS），迁移用 owner 角色执行。1. 项目仍标注 Beta，且自我认知很诚实。 尽管已经发布带版本号的 release，README 和官网仍写 "Rakazo is in beta"。第三方评测的措辞是"treat this as a working setup rather than a finished appliance"（把它当作一个能跑起来的配置，而不是一个完成的成品）。
2. 商业利益与中立性之间存在张力。 仓库的 AGENTS.md 里有一条非常罕见的自我约束："Never include business metrics such as analytics, traffic, click-through, conversion, signup, revenue, or star-growth numbers"——即便在 PR 描述和提交信息里也不允许出现星标增长、转化率这类数字。这既是操守，也是信号：作者同时在运营托管版 Rakazo Cloud，开源版与商业版之间天然存在张力，尽管官方承诺"托管服务不得成为自托管核心的隐藏依赖"。
3. 竞品对比页面本身带有营销属性。 官网的 alternatives/ 页面把 Rakazo 放在第一位，对比对象包含 Hermes Agent、OpenClaw 等。值得注意的是该页面的措辞相当克制——明确写了"这不是评分、不是基准测试、也不主张在每个任务上最好"，甚至专门写了一段"如果你需要能编译进自己 Python 服务的库，那这三个都不是那种库"。这种自我设限反而增加了可信度。
4. 资源开销不是可以忽略的。 每个 bot 一个完整图形桌面容器（Chromium + X11 + 窗口管理器），多 bot 并行时内存压力显著。1GB VPS 方案基本不可行。
5. 依赖的外部模型服务依然要花钱。 自托管软件本身免费（无 seat fee），但模型 API、语音 API、远程沙箱（E2B/Daytona/Railway 都是计量计费）都要付费。Treg 集成还额外要求：将其嵌入托管产品对外转售需要书面协议。
6. 生态与文档门槛。 self-host.md 长达 8.9 万字符，.env.example 有 1.9 万字符、上百个环境变量。这对自托管用户是双刃剑——自由度极高，但首次配置的心智负担不低。RAKAZO_COMPUTER_EGRESS、SANDBOX_CONTROL_VIA_LOOPBACK 这类开关不看文档基本猜不到用途。
7. 依赖特定 Node 版本线的硬约束。 明确不支持 23.x / 25.x，这类"故意不支持"的约束在实践中会制造摩擦。
Rakazo 短短两个多月的增长曲线，恰好印证了 2026 年下半年"个人 AI 代理"赛道的爆发。同期的竞品名单本身就说明了问题：Grok Bot（xAI）、Meta Muse、OpenAI Dots、Instinct、Hark Pro——五家托管型产品同期出现，而 Rakazo、OpenClaw、Hermes Agent 代表了另一条路线：开源自托管。
在这个赛道上，Rakazo 的差异化有三个层次：
第一，"聊天即管理界面"。 官方对比页的核心论点是：Rakazo 跑起来之后就是聊天——和 Grok Bot 一样，你建好 bot 后就在聊天里管理它。例行程序是可读的 Markdown，记忆可查可导出，审批在对话中完成。没有"配置漂移"——这一点比"技术上更强大"更重要。
第二，"计算机"作为一等公民。 大多数 Agent 框架把工具调用抽象成 JSON schema，而 Rakazo 给 bot 的是一台真的带显示器的机器，能看见自己在做什么。这个选择让"让 agent 干一份需要登录网站的工作"从不可能变成可能。
第三，无主控原则（No hosted vendor required）。 架构上强制所有外部服务（模型、沙箱、记忆、语音、集成）都在 provider-neutral 接口之后可选。packages/adapters/ 下的 451 个文件、每个 provider 一套离线一致性测试（conformance tests），就是这个原则的物理体现。
它对行业的实际意义：它把"AI 队友"这个概念的实现成本从"一个团队半年 + 持续烧云费用"降到了"一条 curl 命令 + 一个 API Key"。这直接扩大了能自托管 AI 代理的人群——从只有大厂有资源的团队，扩展到任何愿意自己扛一台 VPS 的开发者。
最后一点观察：Rakazo 选择了 Apache-2.0（而 Hermes Agent、OpenClaw 选 MIT），且贡献者结构里 elie222 个人贡献 643 次、cursoragent 171 次——这是一个高度依赖单一核心作者的项目。它的工程规范（AGENTS.md 里的每一条约束）写得比大多数公司的架构文档都细，这既是优点，也说明关键知识的集中度相当高。对于考虑引入的团队，这是一个需要纳入评估的风险项。
Rakazo 是一个工程完成度显著高于其"Beta"标签的自托管 AI 代理平台。它的架构决策（图形化真实沙箱、Markdown 可携带记忆、provider-neutral 适配层、严格的出口隔离）体现了对"自托管"这个场景的深度理解，而不只是把一个云端 Agent 框架套上 Docker。
适合：需要在自有基础设施上运行长期 AI 任务、要求模型与数据自主可控、并愿意投入运维精力的团队。 不适合：追求开箱即用无运维、单机 1GB 预算、或需要开箱即用的企业级 SLA 的场景。 观望理由：Beta 状态、高度集中的维护者、以及开源版与托管版之间需要持续观察的边界。
上手建议：先用 install-images.sh 在一台 8GB 以上的机器上跑通默认 Docker 沙箱路径，把"注册账号 → 连接模型 → 建第一个 bot → 派一个真实小任务"跑完一遍，再决定是否需要 E2B/Railway 等远程沙箱和公网 HTTPS 部署。
数据来源：GitHub API（仓库信息、目录树、贡献者、文件内容）、仓库 README / VISION.md / AGENTS.md / CHANGELOG.md / docs/self-host.md、官网 rakazo.com、第三方评测 SSD Nodes（2026-10-10）。数据采集与报告生成时间：2026-10-21。