Grok Bot源码分析

国庆有时间研究技术，就体验了一下上个阶段很火的Grok Bot，之所以说上个阶段，是因为现在大家讨论比较的火是Meta的Muse、OpenAI dots。

背景

其实早在龙虾时期，公司就有类似的Grok Bot的项目，其大体的实现方式就是给用户提供一个独立的VPS（只是我支持windows、MacOS和Linux），然后里面都运行着龙虾，但早期的龙虾问题很多，所以总会遇到各种小问题，导致产品不好用。

而这几天，我花了100刀买了Grok Bot，深入使用后，感觉很好用，除了偶尔因为网络问题，无法链接Grok Bot computer，导致一些需要我配合登录的操作无法执行，而感到不顺外，都很好用。

那新的问题就是，Grok Bot是怎么实现的？

一开始的猜测就是跟我之前的项目类似，在提供给用户的Linux中运行着一个操作当前PC的AI服务，比如我之前就是运行着龙虾，然后外部的Server通过与这个AI服务交流从而实现操作Linux的效果。

经研究，Grok Bot也出现了之前Claude Code一样的问题，就是将code source map不小心发布出去了，所以我们可以看到官方具体的实现，不用去猜：https://github.com/b-nnett/grok-bot-0.18-reconstructed

基础架构

首先，最基本的架构设计跟我们猜的类似，在提供给用户的 Linux 中，会运行着一个 sand-host 进程，它是 Agent 运行时负责执行工具，执行Shell， 管理文件的进程。其作用就类似于龙虾进程。

具体流程是这样的：

用户在 Electron 开发的 Grok bot 页面上输入message，比如：打开你computer中的chrome，登录x.com，然后抓取第一页的twitter数据，为了方便描述，将这段message定义成 msg A。

Msg A其实很典型，它要求grok bot要链接上computer，然后打开chrome，然后访问x.com，然后就会遇到登录问题，登录时，我的x又设置了验证码，所以又要收验证码，然后登录后，再去拿数据，是个典型的流程。

Msg A会从 Electron 的 renderer 层传到到 Electron main ，然后 Electron main 会使用 Chromium Service 机制 创建 出名为 Coordinator 的 Node 进程（utility process），Coordinator 是调度computer和AI完成目标的核心进程。

没有使用Node原生的child_process.fork方法创建新警察，而使用Chromium Service的机制创建新进程是因为Chromium的MessagePort可以直接和Electron的renderer UI层建立跨进程通信这样在维护上就会方便点。

此外，没有让 Coordinator 在 Electron main 上，而是创建出一个独立的进程，是为了避免。Coordinator 代码发生内存崩溃、异常的时候，不会影响到整个 Electron 。这样子窗口就不会闪退，然后还能捕获到 Coordinator 的退出事件，然后通过 Electron 里面再去重启 Coordinator。

Coordinator 会通过 WebSocket / JSON-RPC 将消息发生到 远程 Linux 中 send-host 进程里，send-host 进程会启动一个 GatewayServer监听1340端口。

coordinator 通过 createGatewayConnector 连接 box，拿到 gatewayUrl、gatewayToken（鉴权）、vncUrl（使用vnc协议展示远程Linux桌面。（当然Grok Bot也直接使用本地docker，我们不讨论这种情况）

Linux使用的是 Anysphere 官方发布的镜像 public.ecr.aws/k0i0n2g5/cursorenvironments/universal:sand-box-latest ，Anysphere就是开发cursor的公司。

Linux上的send-host中的Gateway 收到Msg A后，会交给 SandAgentRunner，runner会跑循环，每一轮循环：组 prompt（系统提示 + box 说明 + 工具清单）→ StreamAttempt 发推理 → 拦截 tool call → 执行 → 结果回写 transcript → 再推理，直到没有 tool call。

具体是怎么执行的？

主要基于 box-exec-daemon 进程，这个进程默认又send-host进程创建，可以处理 Shell 命令、读取内容、文件管理等基础系统操作，如果需要操作Chrome或自动点击GUI，那么会分配给BrowserUse和ComputerUse。

BrowserUse使用playwright（通过Chrome的CDP去链接）去自动化，会快照当前网站的DOM树，然后定位原生，然后进行操作。

ComputerUse主要就是截图，然后计算像素级的位置，然后实现click、drag、键盘输入等，输入完，在截图进行对比，整个流程在Grok bot中被叫做 see-act-verify循环，那要实现稳定的 computer use，其核心就是每一个应用它的桌面分辨率和大小都是固定的，这样子才不会出现定位偏移的问题。

回到Msg A，那么就会分配给BrowserUse，然后一直跑SandAgentRunner循环，直到模型认为当前工作完成了。

因为我 Msg A 中其实要求他登录x，但他是不知道验证码的，所以需要我配合，此时模型会调用 request_box_help工具，然后endTurn当前的循环，调用这个工具后，会将sessino.box-handoff-started事件同步会Electron，从而让Electron在UI上弹出交互的button。

此时你可以直接在Electron UI上填写内容，比如填验证码，此时新Msg会发到Linux，此时BrowserUse会继续自动化，但很多登录页面，UI是会变动的，此时会出现BrowserUse发现之前快照的DOM定位不到页面中的input框了（Google登录页面就是这样）。

你还可以直接通过VNC去访问Linux，直接人为手动填写，从而完成验证。

我们可以在最新的Grok Bot的Linux上验证一下

# sand-hostpgrep -af host-main  # 看 1337 端口是谁在监听（daemon 固定绑 127.0.0.1:1337） ss -tlnp | grep 1337  

从图可以看出 Linux 上确实有 sand-host 和 box-exec-daemon。

然后这里细节其实很多，因为用户可以开多个 bot 去使用，但只有一台电脑。那这个时候就会涉及到竞争状态的问题。那在源代码中呢，他们在不同的地方都设计了不同的锁去避免竞争状态，做的很细。

此外，在发送消息的时候，也考虑了可能会出现网络波动，导致消息发不过去的状态。也做了重试等各种业务上的逻辑，很细。

可以看出一个好用的产品并不是在技术上有多么的高深，本质这些技术都是比较朴素的。核心还是从业务上去推导，将业务上可能会出现的问题通过常见的技术方案去解决，这样你的产品才会感觉好用。

结尾

Grok Bot 还有很多实现值得继续深挖学习：

1.多个bot拉的群，整个agent流程是怎么处理的

2.超长时间任务是如何在工程上保证稳定执行的，中断了怎么恢复

各有兴趣可以进一步进行分析。