Slock 已更名为 Raft：安装、Agent 接入与常见问题

2026 年更新：Slock 已更名为 Raft。本文保留原 Slock 阶段的实际使用经验，并补充当前更名、新旧包兼容与迁移信息。由于 Raft 仍在快速迭代，涉及安装和界面的部分请以当前官方文档为准。

Slock（现已更名为 Raft）是一个用聊天界面调度本地 Agent 的工具。你把 Claude Code、Codex CLI、Gemini CLI、OpenCode、OpenCLI 等命令行工具注册进去，再在频道里 @ 它们干活、看方案、收结果。

当你同时有多个 AI 在不同任务上工作时，Slock / Raft 提供的是一个远程指挥入口：怎么分工，怎么收结果，怎么知道它们有没有跑偏。

目前产品正处于从 Slock 向 Raft 的更名过渡期：npm 上新包已发布为 @botiverse/raft 和 @botiverse/raft-daemon，旧的 @slock-ai/* 目前仍保留兼容层，旧的 slock / slock-daemon 命令仍能继续工作。

本文基于 Slock 社区数百人的真实使用经验整理。社区反馈会随版本变化，下面更偏使用方法，不当成固定产品文档。

它像一个 Agent 调度群

如果你只用一个 Agent 写代码，直接用 Claude Code 或 Codex 就够了。

Slock 最像一个 Agent 调度群。它适合这些场景：

• 你同时跑多个 Agent，需要一个聊天入口来指挥。
• 你想在手机上远程派活，让本机电脑执行。
• 你希望不同 Agent 在同一个频道里能看到部分上下文。
• 你有代码、网页、报告、非编码任务混在一起，需要随时叫不同工具处理。

它的优势是轻、快、临场感强。你可以像在群聊里喊人一样派活。

它的代价也很明显：多个 Agent 共享频道上下文时，会更费 token；如果权限和节奏没控制好，Agent 会跑太快，返工成本很高。

daemon 是它的中转站

Slock 本质上是一个消息路由层。

你在网页或 App 里发消息，消息到达电脑上运行的 daemon，daemon 再把消息转给对应的命令行工具。工具执行完后，结果经 daemon 回到聊天界面。

这个架构有三个直接后果：

1. Agent 能做什么，取决于你本机装了哪些 CLI。
2. 代码和文件还在你自己的电脑上，云端主要做消息中转和状态同步。
3. 每个 Agent 是独立进程，有自己的 session 和上下文，关掉浏览器也可以继续跑。

从 Slock daemon 到 Raft Computer：安装与迁移路径

随着产品从 Slock 更名为 Raft，机器连接方案和 npm 官方包体系也发生了演进：

1. 机器连接方案（Host Agent 连接）：

   • Slock 时期：主要通过在本机安装并启动 daemon（旧包 @slock-ai/daemon）。
   • 过渡期：推出了 @botiverse/raft-daemon 作为直接替代包。
   • 当前 Raft：网页端托管 Agent 的机器连接已转向 Raft Computer。在控制台点击 Add Computer 后，系统会根据操作系统提供 setup 命令（macOS / Linux 当前典型形式是安装 raft-computer）。
   • 安装建议：当前 Raft 新安装优先按照网页 Add Computer 提供的命令安装 Raft Computer；旧 Slock/Raft daemon 用户仍存在兼容与迁移路径，旧环境无需强制推倒重来。

2. CLI 核心包与命令别名：

   • 旧 CLI 包 @slock-ai/cli 已迁移为 @botiverse/raft，当前官方主要用于类似 External Agent 等 CLI 接入场景（npm i -g @botiverse/raft@latest）。
   • npm 官方保留了兼容别名：旧的 slock 命令是 CLI 客户端的 legacy alias；旧的 slock-daemon 才是 daemon 后台服务的 legacy alias，两者不要混淆。

Raft 当前提供 Free 和 Pro 套餐，Enterprise 尚未正式推出；具体额度与价格可能继续变化，以官网实时信息为准。

先让一个 Agent 回话

不要急着搭“AI 公司”。先确认一个 Agent 能稳定回话。

1. 连接机器。 旧 Slock daemon 环境仍可通过兼容层运行；新环境请优先按照 Raft 的 Add Computer 页面给出的当前安装命令连接机器。在网页端创建 Server，并通过 Add Computer 连接电脑，确认显示在线（绿灯）。
2. 创建第一个 Agent。 选择 Runtime，比如 Claude、Codex 或 Gemini，起名，选择运行 Agent 的 Computer，选模型，等头像旁边亮绿灯。
3. 发第一条指令。 在频道里 @ 它，让它看当前目录下有哪些文件。
4. 看 Activity 日志。 如果没反应，先看 Activity 面板，常见原因是 CLI 没装、PATH 不对、模型额度或 API key 问题。

到这里就够了。单 Agent 稳了，再加第二个、第三个。

多模型接入

现实使用里，通常不会只用一个模型。复杂推理用 Opus，批量任务用便宜模型，轻量问答用 Gemini 或国产模型，会省很多钱。

在 Slock 里，常见做法是给 Agent 配环境变量，比如 ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY。每个 Agent 可以有独立配置，互不干扰。

但 Claude Code runtime 有一个坑：Slock 启动时可能会传入固定 --model 参数，覆盖你在环境变量里设置的模型。社区里常见绕法有三种：

• 用 cc switch 切 Claude Code 配置文件。
• 用 Kimi CLI 这类对多模型更友好的 runtime。
• 直接 patch daemon 源码，让启动命令读环境变量。

如果你刚开始用，别一上来就追求完美多模型。先让一个主力 Agent 稳定跑，再逐步拆模型。

频道里别放太多人

Agent 数量超过两个后，频道就会变成核心变量。太少不方便协作，太多又会让上下文和 token 一起膨胀。

主管和执行分开

最常见的方式是设置一个“主管”Agent，用强模型理解需求、拆任务、把活分给执行 Agent。你主要和主管以及 reviewer 对话，不直接管理每个执行层细节。

这个模式的好处是，你不用记住每个 Agent 擅长什么。你告诉主管“我要一个能导出 PDF 的报表页面”，它去想谁写接口、谁写前端、谁做样式。

高风险任务先审后做

高风险任务不要直接让 Agent 动手。

先说：

给我解决方案，不许改文件。

等你看完方案，再说：

方案通过，开始改。改之前说明影响范围和回滚方式。

这一步看起来慢，但能避免 Agent 在你没想清楚时改一堆文件。

监工单独放

当你同时跑五六个 Agent，逐个看状态会很烦。可以放一个低成本“监工”Agent，定期检查哪些 Agent 卡住、报错、额度用完，必要时提醒你或重启。

社区里有人单独开一个 Slock Server 做监工，让监工和工作 Agent 的上下文完全隔离。这个思路比把所有东西塞进同一个频道更干净。

跑太快时要让它停

Agent 跑太快是个真实问题。你说“把这个功能做了”，它可能十分钟改二十个文件。等你发现方向不对，已经很难细改。

实际使用时，给它设阶段性检查点：

• 做完方案先停。
• 改完一个模块先停。
• 跑完测试先停。
• 涉及支付、删除、发帖、部署时必须停。

多 Agent 的效率来自并行，不来自无刹车。

token 贵在同频道反复读

Slock 费 token，不一定是 bug，而是多 Agent 协作的结构性成本。

Channel 默认像团队频道。一个 Agent 读消息时，可能会读同频道里其他 Agent 的对话作为上下文。如果五个 Agent 都在一个频道里，一段背景可能被反复读取多次。

比较实用的省法：

• 按项目或任务拆 Channel，不相关的 Agent 不要放一起。
• 高频轻量任务用便宜模型，比如监工不必用 Opus。
• 大任务先拆成小任务，不要让多个 Agent 同时读同一堆背景。
• 临时任务做完就收束，不要把历史聊天一直当长期上下文。
• 不要过度隔离。拆太碎会让人管理成本上升，控制 Agent 数量通常更重要。

Slock 不是省 token 工具，它省的是你管理多个 Agent 的注意力。

非编码场景

Slock 不是只能写代码。社区里有人用它查机票、看酒店、做旅游规划、生成 HTML 报表、整理网页内容，也有人准备配合语音输入，让 Agent 润色后执行。

关键不是 Slock 自己能做什么，而是本机 CLI 和工具链能做什么。Claude Code 能读网页、调 API、操作文件，这些能力透过 Slock 就变成远程可指挥的能力。

比如你在手机上发：

帮我查上海到北京明天最便宜的机票，整理成一个 HTML 报表。

Agent 在电脑上打开浏览器、搜索、比价、生成文件，再把结果发回频道。

但支付环节仍然应该手动。Agent 可以帮你填到最后一步，付款、下单、删除和提交不可逆表单，要人确认。

Raft Computer、PATH 和移动端

当前新环境通过 Raft Computer 连接机器；较早的 Slock / Raft 环境可能仍在使用 legacy daemon。旧 daemon 可以继续运行，也可以按照官方迁移流程切换到 Raft Computer。

PATH 是旧 Slock / daemon 环境里比较常见的问题。有用户遇到 Slock 识别不到 Gemini CLI，最后发现 daemon 启动时的 PATH 没包含对应目录。遇到旧环境 CLI 不识别时，先查 daemon 的实际运行环境，不要只查交互式 shell。

移动端目前可以直接使用 Raft Web，并添加到手机主屏幕。它最适合的场景不是复杂编辑，而是远程派活、查看结果和跟进 Agent 状态。Slock 阶段也曾有社区客户端等方案，但这类第三方方案变化较快，不再作为本文推荐路径。

卡住时先看 Activity

Agent 突然不回复，优先看这三个地方：

1. daemon 卡住或队列积压。 进 Activity 看日志，必要时 restart Agent 或 daemon。
2. API 额度用完或限流。 Activity 里有 429，就换模型、换账号或等 reset。
3. 任务完成但没回消息。 可能是状态同步问题，重启 Agent 一般能恢复。

其他常见问题：

• Claude Code（CC）接国产模型不生效：model 参数可能被覆盖，换 Kimi CLI、cc switch 或 patch daemon。
• mobile web 进 channel 后回不去 home：改 URL 末尾为 /home。
• 删除 Agent 后 task 卡住：删除前最好先让 Agent done 掉任务。
• workspace 图片显示 binary 或 0B：先下载本地查看。
• OpenCode agent 不识别 provider：看 daemon 检测的是不是目标配置文件。

它和 Multica 的关系

Slock 更像聊天室：即时、轻、适合随时喊 Agent 干活。你可以在频道里 @ 一个 Agent 查资料，让另一个改代码，再让第三个看日志。

Multica 更像办公室：需求会变成 issue，有负责人、交付物、状态和验收标准。如果你的工作从“临时喊一下”变成“多个任务并行推进”，Multica 会更稳。

两者不是替代关系。常见组合是：

• Slock 负责交流层和快速调度。
• Multica 负责项目任务层。
• OpenCLI 负责进入那些没有 API、但网页能操作的流程。

Slock 值不值得用，取决于你有没有真的需要同时管理多个 Agent。如果只有一个 AI，别把工具链搞复杂。如果已经有三五个 Agent 同时工作，Slock 会让指挥成本低很多。