监控 Codex 智能体：真正有价值的四个信号

「进程在跑」不是一个有用的回答

一个已经运行两小时的 Codex 智能体，可以处在三种截然不同的状态。它可能正在推进工作，咬着一次重构、隔几分钟动一个文件；也可能在打转——反复读同几个文件、反复问同样的问题、在烧 token 却没往前走；还可能在等 rate limit，技术上活着，但什么都没产出。

任何常规的监控工具——htop、systemctl status、uptime 探针——对这三种情况给出的回答都一样：进程在线。这个回答比没用还糟，因为它会让你以为一切正常，而三种结局里有两种其实是「你花钱什么也没买到」。

监控一个编码智能体和监控一台 Web 服务器，是两种不同的问题。下面是我们在 Office Claws 里关注的信号，以及为什么它们重要、每一个分别说出了 ps aux 说不出的哪件事。

信号 1：活动——智能体「此刻」在做什么

关于一个正在跑的智能体，最有用的一件事是知道它当下是在思考、在打字，还是在闲着。不是「过去五分钟有没有写过日志」——那是滞后指标。要看的是实时状态：token 流在走吗、它正在读文件吗、在等一条 shell 命令吗。

在 Office Claws 里，每个智能体在像素办公室都有自己的工位，坐在工位上的角色处于三种动画状态之一：行走、打字 或 空闲。这个动画不是装饰——它是智能体真实状态的实时投影，由驱动活动流的同一个 RPC 流喂进来。瞥一眼办公室，不用读日志就能知道谁在真干活，谁在停着。

基于文本的等价物同样管用。Codex CLI 在运行时会发出事件——工具调用、文件读取、模型轮次。对这个事件流做 tail，效果和一个 spinner 一样，只不过是在终端里。关键是区分「进程活着」和「进程在做事」。

信号 2：产出——文件到底在不在变

一个在终端里「打字」但三十分钟没改过任何文件的智能体，其实没在工作。它只是在跟自己聊天。这是我们在长任务上最常见的失败模式——模型陷进自己和 scratchpad 的讨论里，不出 diff，悄悄烧掉一小时都没人察觉。

便宜的抓法：盯着工作树。

# On the VPS, log file changes every minute
while true; do
  find /repo -type f -newer /tmp/last-check 2>/dev/null | wc -l
  touch /tmp/last-check
  sleep 60
done

如果对一个本该出 diff 的任务来说，这个数字连续三个窗口都是零，那么智能体就是卡住了。把它打断，总结它学到的东西，然后用一个更收紧的 prompt 重新开始。继续让它跑下去，几乎总是在浪费。

一个相关信号：提交节奏。我们要求 builder 智能体在每一个逻辑变更之后提交。一个从「重构这 20 个文件」开始、已经一小时没提交的智能体在告诉你一些事——通常是这个任务本身规格不够清楚。

信号 3：成本——token、消息和 rate limit 悬崖

订阅制 Codex（ChatGPT Plus 或 Pro）不按 token 计费，但对滚动窗口内的消息数有上限。API 模式 Codex 按 token 计费、没有上限。两边都在意用量，只是原因不同。

订阅这种情形对监控才是最危险的，因为一个被 rate limit 的智能体看起来还在跑。进程在线、终端开着、CLI 在等。但每一个新请求都被 throttle，什么也不回来。没有一个 rate limit 指示器，你要一直等到看到产出、然后发现六小时一片空白时才会察觉。

在 Office Claws 的活动流里我们直接显示剩余消息数——数字跌破 10% 时，智能体的徽章会变成琥珀色。同样的逻辑可以接进任何一套 setup：Codex CLI 暴露了 limit header，一小段 jq 脚本就能在剩余数越过阈值时触发一条通知。

信号 4：卡住状态——无声的失败

最难抓的一类失败是：智能体在技术上一直有产出，但其实没有进展。我们经常看到三种形态：

• 读循环。 智能体把同样五个文件反复读，每次总结略有不同，却什么也不写。token 烧得实实在在，进度是零
• test-fix-test 螺旋。 智能体跑测试、看到失败，「修」得又引入新的失败，再跑测试，如此无限。每一轮都产出一个 diff，所以纯粹监视产出的做法抓不到
• rate limit 重试风暴。 智能体撞到上限，每隔几秒就重试，无穷无尽地打印「retrying...」。CPU 低、内存低、日志在滚、什么也没发生

三种情况的共同迹象都是重复。健康智能体的日志是一连串不同动作——读这个文件、再读那个、然后写另一个、再跑某条命令。卡住智能体的日志，是同样三行在一个小时里交替出现。一个能稳定抓到这个的最简单告警，是「最近 20 分钟内唯一工具调用数」这项指标。如果答案是 2 或 3，智能体在打转。

Office Claws 是怎么把这些信号呈现出来的

本月起，桌面端里上面这几条都已经落地：

• 活动流 — 每个智能体的每一次工具调用、文件读取、命令、模型轮次，实时汇到一个面板
• 像素办公室状态 — 行走 / 打字 / 空闲，由智能体所在 VPS 的 RPC 流驱动
• 日志流 — 每个智能体完整的 stdout/stderr，带滚屏回放，可按智能体过滤
• rate limit 徽章 — 当剩余消息数跌破预警阈值，智能体会有一个对应颜色的指示
• 空闲检测 — 在一个可配置的时间窗内没有产出的智能体会在办公室里被标记；角色动画切到 idle，工位徽章变黄

重点不是说只有用 Office Claws 才能得到这些。重点是：这四个信号就是一个编码智能体仪表盘应该展示的东西——任何自建的方案，只要漏掉其中一个，就一定会放过对应的那种失败。

什么不值得监控

有三件事看起来应该重要，实际上通常不重要：

1. VPS 的 CPU 和内存。 一个 Codex CLI 会话大约吃 200MB 内存、几乎不动 CPU——工作发生在模型里，不在 droplet 上。如果你的智能体把 CPU 打满，那是你代码的问题，不是智能体的
2. 网络 uptime。 Tailscale 会自己处理重连。30 秒的掉线不会影响一个正在跑的智能体会话。对此告警只会制造噪音
3. 「跑了 N 小时还活着」当成功信号。 运行时长单独看就是陷阱——一个卡住的智能体能开开心心跑 24 小时。把运行时长和产出绑在一起看，才有意义

一套最小自建 setup

如果不用 Office Claws，又想要等价物——最短路径是这样：

# /etc/systemd/system/codex-watch.service (simplified)
# Logs activity, tracks file changes, alerts on stuck state
 
*/5 * * * * /opt/codex-watch/check.sh >> /var/log/codex-watch.log

在 check.sh 里：

1. 解析 Codex 事件日志最近 20 分钟的内容，数一下唯一工具调用的数量
2. 数一下最近 20 分钟内 /repo 下被修改的文件数
3. 读一下最近一次 API 响应里的 rate limit header
4. 如果 unique-tools ≤ 2 且 files-changed = 0 连续两个窗口都成立，就打一个 webhook

就这些。四十行 shell、一条 cron、一个指向你看通知那边的 webhook。粗糙，但抓得住真正重要的那三种失败模式。像素办公室看起来更好看，但解的是同一个问题。

一句话版

监控一个编码智能体，不在于进程是否活着，而在于工作是否在动。活动说明它在做事，产出说明它在出东西，成本说明它还跑得下去，卡住状态说明它是不是真的在往前走。四个都看。单独哪一个都别全信。

延伸阅读

• How to Run Multiple Codex Agents at Once — 智能体越多，监控越难
• Long-Running Codex Tasks — 为什么通宵任务需要的是四个信号，而不是只看 uptime
• Cutting AI Agent Costs — 成本信号的细节，包含 Plus 何时该换成 Pro