躺在沙发上指挥 Claude Code：OpenClaw 远程开发实战

下班回家不想开电脑？掏出手机发条飞书消息，就能查看 Claude Code 进展、发指令让它继续、任务卡住了还能自动收到告警。

这不是概念 demo，是我跑了一段时间的日常。 

离开电脑后，任务就失控了

我的开发环境分两层：笔记本做轻开发，重度任务扔在服务器上的 CentOS 虚拟机。Claude Code 和 Codex 承担了大量编程工作，效率很高——前提是我坐在电脑前。

一旦离开工位，问题就来了：

• SSH 回去？需要电脑和 VPN，太麻烦

• 放个 nohup 等结果？出问题也看不到

• 每隔几小时回去检查？浪费时间

核心痛点不是"远程操控"——ssh + tmux 也能做到一部分。真正缺的是感知恢复：不用主动去检查任务状态，系统会告诉你什么时候该关注。

我的远程编程环境正好和 OpenClaw 部署在同一台服务器上。OpenClaw 作为多 Agent 网关，天然就是连接 IM 和服务器的桥梁。基于它，我搭了一套完整的远程管理方案——coding-remote skill。

脚本做脏活，AI 做判断

传统 AI Agent 方案有两个极端：纯提示词不稳定、容易遗漏；纯脚本死板、无法理解用户意图。

这个方案走的是混合架构：

• 7 个 Shell 脚本（约 300 行）：列出任务、采集状态、检测异常、发送指令、写入告警——确定性 I/O，又稳又快

• LLM 提示词：理解用户意图（"看看 revkit"→定位到 claude:1）、解释状态数据、评估风险、自然语言转安全指令

举个例子：列出所有 tmux session 中的 CC 进程，Shell 一行命令搞定。但"用户说的 revkit 指的是哪个 session"——这件事没法写死规则，必须靠 LLM 理解上下文。

反过来，让 LLM 去调 tmux 命令采集数据，容易因为输出格式变化而出错；让 Shell 脚本去判断告警是否该发、怎么解释给用户，又太死板。

确定性的系统 I/O 交给脚本，理解意图和生成判断交给 LLM。两者各司其职。

四个核心能力

📌 列出任务：有哪些 Claude Code 在跑？

自动检测三种运行方式：tmux 中的 CC、SSH 终端直接运行的 CC、Codex 活跃 session。一条消息看到所有任务。

📌 查看状态：revkit 进展怎么样？

自动采集终端输出、对话轨迹、git 变更，自动检测异常——429 / 配额耗尽 / 审批卡住 / 30 分钟无活动——全部标记出来。

📌 发送指令：让它继续干活

"继续任务"——SDE agent 会了解上下文，帮你补充指令，并将自然语言转为安全指令，通过 tmux send-keys 或 PTY 写入发送。

这里的安全指令不是简单的"把用户原话发过去"。LLM 会在转发前做一层包装：明确任务范围（"只修改 revkit 模块，不要动其他文件"）、添加禁止项（"不要执行 git push"）、设定停止条件。这层包装确保了远程操控不会因为一句话的歧义而跑偏。

📌 主动告警：任务暂停了，你知道

这是整套方案里最有价值的部分。CC 在服务器上跑，你不在电脑前时，任务暂停了怎么办？靠人盯着不现实。

告警怎么推到飞书

告警系统是一条三段链路：

第 1 段：CC 停止时自动触发 stop-alert.sh。脚本通过 stdin 拿到 CC 传入的 reason 字段，分类处理：

• 429 / quota / rate_limit → critical 级告警

• approval / permission / bypass → warning 级告警（审批卡住）

• manual / paused / stop → warning 级告警（手动模式）

• 空 reason → 自动读取 trajectory 文件判断：最后一次 assistant 消息是否被 429 截断？是否在 manual mode？还是正常完成？

正常完成的任务归类为 task_completed，带任务摘要，不打扰。

第 2 段：告警文件写入 ~/.claude/alert/pending/ 后，由 cc-alert-unified.sh 处理。系统 crontab 每 2 分钟执行，包含两个检测场景：

• 场景 A — pending 文件投递：读取 pending 目录的 JSON 文件，POST 到 OpenClaw 内置 webhook，成功后移入 notified 归档

• 场景 B — TMUX 审批卡住检测：直接扫描 tmux 每个 pane 的输出，匹配审批提示。即使 stop hook 因竞态未写入 pending，这一层也能兜底捕获

第 3 段：OpenClaw 网关接收 webhook 请求后路由到飞书群消息。Bearer token 鉴权，走 localhost，不经过公网。

去重方面：同一 session + 同一告警类型 60 分钟内不重复写入 pending；TMUX 检测场景同一 pane 同一类提示 30 分钟内不重复推送。

不挑运行方式，三种模式全覆盖

Claude Code 不跑在 tmux 里（SSH 直接 claude 命令）同样可用：

• 状态查看：trajectory 文件是 CC 自动写的，不受 tmux 影响，直接读文件即可

• 发送指令：通过 /dev/pts/N 直接写入终端，原理是往 CC 所在的伪终端写入字符，等同于键盘输入

• 告警：hook 同样触发，和 tmux 模式完全一致

Codex 也支持——没有 tmux 和 trajectory 文件，但有独立的数据体系（rollout .jsonl + history.jsonl + session_index.jsonl），同样实现三套指令。

tmux / SSH 直连 / Codex CLI，不管你习惯怎么用 CC，这套工具都适配。

踩坑记录

⚠️ 坑 1：set -e 让 Stop hook 静默失败

最初 stop-alert.sh 使用 set -euo pipefail。当 CC 的 trajectory 文件尚未完整写入时，grep/jq 返回非零导致脚本直接退出。CC 将非零退出码视为 hook 失败，告警文件不会生成，用户毫无感知。

修复：去掉 -e，加 trap ... EXIT 兜底。确保 hook 回调永远 exit 0。

⚠️ 坑 2：审批提示的非标准格式

TMUX 检测依赖 grep "Do you want to proceed?"。但 CC 有些版本的审批提示是其他变体。需要持续关注 CC 更新后的提示格式变化。

⚠️ 坑 3：去重粒度

太激进：有新用户输入后不应该去重。太宽松：同一个 429 错误重复推送 10 次刷屏。当前方案：同一 session + 同一告警类型 60 分钟窗口；检测到新的用户交互后允许重新告警。

⚠️ 一次端到端排障

有一次 CC 审批卡住了，但飞书没通知。排查发现链路断了三处：Stop hook 因 set -e 静默失败→pending 无文件；TMUX 检测确实捕获到了→调用了 webhook；webhook 返回 200→但到飞书的投递配置缺失，消息未送达。

修了退出码，补齐了 webhook 配置，全链路才真正贯通。基于上报链路的告警系统，端到端测试比单点测试重要得多。

5 步部署，16 行配置

整套部署不依赖外部服务，所有组件都在你自己的服务器上：

1. 服务器安装 Claude Code + tmux（Codex 可选）

2. coding-remote skill 放入 SDE workspace（含 9 个脚本）

3. ~/.claude/settings.json 添加 Stop + StopFailure hook 配置——两个 hook 共约 16 行 JSON，配置一次永久生效

4. 系统 crontab 加一条每 2 分钟执行的条目 → 脚本检测无告警文件时毫秒级退出，零开销

5. 在飞书群 @SDE 即可使用——不需要额外 app，不需要记住命令，问就行

最后

这套方案把"本地开发"和"远程管理"打通了。靠的不是什么新框架，就是 OpenClaw + Claude Code hooks + 系统crontab的组合。

实际效果：

• 随时看：不用 SSH，飞书消息就能查任务状态

• 远程控：发指令继续干活，task context 自动保持

• 自动告警：任务暂停会通知，不用一直盯终端

• 零空跑：无告警时 crontab 门控跳过，不消耗 token

离开电脑后怎么管理 AI 编程任务？不需要换更强的工具，给现有工具加上感知和通知的能力就行。脚本做脏活，LLM 做判断，IM 做入口——三层拼起来，远程 AI 开发就通了。