Slock 使用指南：安装 daemon、接入 Agent 与常见问题

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

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

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

它像一个 Agent 调度群

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

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

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

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

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

daemon 是它的中转站

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

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

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

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

Slock 目前免费，商业模型还没完全明确。社区普遍觉得之后会收费，但当下仍然适合尝试。

先让一个 Agent 回话

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

1. 装 daemon。 在准备跑任务的电脑上安装并启动 daemon，在网页端新建 Server，添加 Machine，确认显示在线。
2. 创建第一个 Agent。 选择 Runtime，比如 Claude、Codex 或 Gemini，起名，选模型，等头像旁边亮绿灯。
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 可以帮你填到最后一步，付款、下单、删除和提交不可逆表单，要人确认。

daemon、PATH 和移动端

daemon 需要在每台机器上安装和更新，这是目前比较明显的摩擦点。有人把 daemon 注册成 macOS LaunchAgent，远程 launchctl restart；也有人让主设备的 Agent ssh 到其他机器更新 daemon。

PATH 也常见。有用户遇到 Slock 识别不到 Gemini CLI，最后发现 daemon 启动时的 PATH 没包含对应目录。遇到 CLI 不识别，先查 daemon 的启动环境，不要只查 shell。

移动端方面，Slock 没有统一官方 App，但 mobile web PWA 已经能用。安卓有第三方客户端，iOS 需要自己编译。它最适合的移动场景不是复杂编辑，而是远程派活、看结果、让 Agent 先跑起来。

卡住时先看 Activity

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

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

其他常见问题：

• 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 会让指挥成本低很多。