Grok Bot 好用但费 token？不如让它指挥 omp 干活

先认识两个角色。

Grok Bot 是跑在云端电脑上的桌面助手。你跟它对话，它能查资料、连外部服务、定时做事、开浏览器、动桌面，还能帮你管一堆本地工具。强项是「什么都能接」，短板也明显：它习惯自己一步步推理、调工具、带着长上下文往前走，token（大模型的计费单位）烧得快。

omp 是装在本机（或助手那台电脑）上的命令行 AI 编程助手。它擅长在终端里读写文件、跑命令、改代码、做批量处理。它不占 Grok Bot 那套会话上下文，还能接你自己的模型接口，比如我家里那台 Mac mini 上自己搭的 omni-router（一个自建的模型入口）。

简单说：Bot 适合指挥和验收，omp 适合动手干活。这篇讲的就是我怎么把两者拆开用、省 token 的一点实操。

Grok Bot 很强，但真的太费 token

用了一阵子，我的体会是：它什么都能接。查东西、连外部服务、跑流程、定时任务、开浏览器、动桌面，功能确实强。

但每次用，心里都有点打鼓，贵。

原因不难理解。它做一件事，往往要自己拆步骤、自己调工具、自己看结果、再决定下一步。每一步都是一次推理，每次工具调用都是一来一回，上下文还越滚越长：上一轮的原始内容，下一轮还得再带一遍。一件本来不算难的事，被老老实实走了十几轮，token 就这样没了。

我的判断是：浪费多半不在「它干得不好」，而在于这些活本来不需要一个会推理的大家伙亲自上手。真正需要它的，是判断和调度；真正费它的，是动手。

一、原则：能交给本机 omp 的，先交给 omp

我把分工定成三条：

• Grok Bot 负责分派和验收：说清要什么、验收标准是什么、产物放在哪。
• omp 负责执行：真正动手的部分，在本机跑完。
• 结果回到 Bot：它只做核对、判断、决定下一步。

这样，Bot 的上下文里留下的是「任务描述 + 结论」，而不是整个干活的中间过程。省下来的，正是那些原本要被反复带进上下文的原始材料和试错记录。

二、具体怎么做（我现在的流程）

1. 先切任务。 拿到一件事，先问自己：这活需要「想」，还是只是「做」？需要反复权衡、需要人来定的，留给 Grok Bot。机械但量大的，比如批量改文件、整理汇总、格式转换、跑脚本、按规则核对，直接丢给 omp。

2. 交接时说清四件事。 目标、输入在哪、验收标准、产物放哪。这四件事写不清楚，Bot 就要来回追问，追问也是 token。写清楚了，omp 一次就能跑到位，Bot 只花很少的话把活派出去、把结果收回来。

3. 让 Bot 每次汇报工作量对照。 我要求它每完成一项工作，末尾附一行：这件事「我做了多少 / omp 做了多少」。不图好看，图的是能看见。哪类活一直是 Bot 在硬扛，看一眼就知道，下次就能挪走。omp 自己也有用量统计命令，愿意对账的时候可以再核一遍。

4. 把重推理挪到你自己的模型额度上。 omp 支持接自定义模型端点。在本机的模型配置里加一个 provider，填入自己的接口地址（OpenAI 兼容接口即可），omp 就会走你指定的模型。意思很直接：那些量大、重复、不需要顶级模型的活，让它们落在你自己的额度上，而不是全压在 Grok Bot 身上。

5. 本机其他 CLI 也能用，但默认 omp 优先。 同一台机器上，OpenCode、Codex、agy 这些也都能接进来，各有擅长的场景。我的默认还是 omp：够用、清楚、少切换。只有碰到它明显不合适的事，才换别的。

6. 别为了省，把流程拧成麻花。 分工是为了少烧 token，不是为了把自己变成调度员。一件事如果拆开交接的成本比它本身还高，就让 Bot 直接做完，别折腾。

三、哪些适合交给 omp，哪些别硬塞

适合交给 omp 的：

• 批量文件处理：改格式、换命名、合并拆分、批量替换。
• 读代码、改代码、跑测试这类要在本机反复动手的活。
• 长材料的整理与汇总：把一堆原始内容压成一段结论再交回去。
• 需要反复试错的机械活：几次不行就再试，不必占用 Bot 的上下文。
• 只要产物、不需要对话过程的活。

别硬塞给 omp 的（这几样还得 Bot 自己来）：

• 连接器：外部服务的授权与收发，是 Bot 的通道，omp 走不了。
• 例行任务：定时触发的那些安排，本身就是 Bot 在管。
• 它的浏览器和桌面：需要登录态、需要点来点去的会话，还是它自己上。
• 必须靠整段会话上下文才能做的判断：中间过程本身就是答案的一部分时，别切出去。

一句话：动手的活往外挪，需要通道和身份的活留里面。

四、小结

Grok Bot 值钱的地方是判断和调度，不是替你把每个文件改一遍。

把动手的部分交给本机 omp，Bot 只做分派和验收，每一项工作后让它报一句「我做了多少 / omp 做了多少」，再把自己模型额度接上。这四件事做完，你会第一次看清钱花在哪。

下一步就一件：从你每天固定让 Bot 干的那几件事里，挑出最机械的一件，今天交给本机 omp 跑一遍，然后在末尾看那行工作量对照。

五、可复制提示词：让 Grok Bot 自己装 omp 并合理分工

如果你想这么用，可以把下面整段发给你的 Grok Bot（按你的实际地址改一处即可）：

请在你的本机安装并配置 omp，并按以下规则长期执行。

【网络与模型】 我已把你的机器接进我的私有网络。因此 omp 可以通过内网访问我家中 Mac mini 上的 omni-router LLM，不必走公网。 请把 omp 的默认模型接到该服务，例如： - API Base URL：http://<你的内网地址>:20128（若需 /v1 按 omp 要求补上） - 模型名：omni-go（provider/model 按 omp 配置习惯写成可用形式） - API Key：使用我提供的密钥（不要把完整密钥打回聊天）

装好后用一次极简问答实测（例如只回复 OK），确认通了再继续。

【硬规则：omp 优先】 1. 每接到任务，先判断 omp 能不能完成。 2. 能 → 把完整、可自洽的任务交给 omp；你只做分派与验收，不要自己把重活干完。 3. omp 搞不定（需要你的连接器、例行任务、你自己的浏览器/桌面、或必须依赖本会话上下文）→ 你再接手。 4. 同一台机器上若还有 OpenCode、Codex、agy，仅作 omp 不适合时的备手；默认仍 omp。

【验收与汇报】 每项工作完成后，用一两句话汇报：你做了多少，omp 做了多少。不要只报「完成了」。

【边界】 不要把密钥写进会公开的文件；不要假装已写入/已安装。内网不通或 omni-router 不可达时，如实说明并给出下一步，而不是改走未经我同意的公网通道。

先汇报：omp 是否已安装、版本号、模型探测是否成功、默认分工规则是否已写入你的长期偏好。