Мониторинг Codex-агентов: четыре сигнала, которые реально о чём-то говорят

«Процесс запущен» — это не ответ

Codex-агент, работающий уже два часа, может находиться в трёх совершенно разных состояниях. Он может двигать работу вперёд, перемалывая рефакторинг и трогая файл раз в несколько минут. Он может крутиться в цикле — перечитывать одни и те же файлы, задавать одни и те же вопросы, жечь токены без движения. Или он может ждать rate limit — технически живой, но не производящий ничего.

Любой обычный инструмент мониторинга — htop, systemctl status, uptime-пинги — для всех трёх случаев скажет одно и то же: процесс жив. Этот ответ хуже, чем бесполезен, потому что заставляет думать, что всё хорошо, тогда как два из трёх исходов означают, что вы платите ни за что.

Мониторинг кодинг-агента — задача другого рода, чем мониторинг веб-сервера. Ниже — сигналы, которые мы смотрим в Office Claws, зачем они нужны и что каждый из них говорит такого, чего не скажет ps aux.

Сигнал 1: активность — что агент делает прямо сейчас

Самое полезное, что можно знать про работающего агента, — думает ли он сейчас, печатает ли, простаивает. Не «логировал ли он строку за последние пять минут» — это запаздывающий индикатор. Речь о живом состоянии: идёт ли поток токенов, читает ли он файл, ждёт ли команду шелла.

В Office Claws у каждого агента есть стол в пиксельном офисе, и персонаж за этим столом находится в одном из трёх анимированных состояний: идёт, печатает или отдыхает. Эта анимация — не украшение. Она живая проекция реального состояния агента, питаемая тем же RPC-стримом, что и активити-фид. Взглянули на офис — и без чтения логов знаете, кто из агентов реально работает, а кто простаивает.

Текстовые аналоги тоже работают. Codex CLI на ходу отдаёт события — вызовы инструментов, чтения файлов, ходы модели. Tail по этому потоку событий скажет то же, что спиннер, только в терминале. Важно отличать «процесс жив» от «процесс что-то делает».

Сигнал 2: выход — меняются ли файлы на самом деле

Агент, который «печатает» в терминале, но не менял ни одного файла тридцать минут, не работает. Он беседует сам с собой. Это самый частый режим сбоя на долгих задачах — модель уходит в дискуссию с собственным блокнотом, не производит диффов, и час горит, пока никто не замечает.

Дешёвый способ ловить: вотч на рабочее дерево.

# 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

Если это число — ноль три окна подряд на задаче, которая должна производить диффы, агент завис. Прервите его, обобщите, что он успел узнать, и перезапустите с более узким промптом. Оставлять его бежать дальше — почти всегда потеря.

Смежный сигнал — каденция коммитов. Мы просим наших билдер-агентов коммитить после каждого логического изменения. Агент, который час не коммитил на задаче, начавшейся со «срефактори эти 20 файлов», о чём-то вам говорит — обычно о том, что задача была недоспецифицирована.

Сигнал 3: стоимость — токены, сообщения и обрыв rate limit

Подписочный Codex (ChatGPT Plus или Pro) не биллит по токенам, но ставит лимит на сообщения в скользящем окне. Codex по API биллит по токенам без потолка. Обоим важен объём, по разным причинам.

Подписочный случай — опасный для мониторинга, потому что агент с rate limit выглядит работающим. Процесс жив, терминал открыт, CLI ждёт. Но каждый новый запрос идёт с троттлингом, и ничего не возвращается. Без индикатора rate limit вы не узнаете ничего, пока не глянете на выход и не увидите шесть часов пустоты.

Остаток сообщений мы показываем прямо в активити-фиде Office Claws — когда счётчик падает ниже 10%, бейдж агента становится янтарным. То же самое можно повесить в любом сетапе: Codex CLI отдаёт заголовки лимита, и маленький скрипт на jq умеет кинуть нотификацию, когда остаток пересекает порог.

Сигнал 4: застревание — тихий сбой

Сложнее всего ловить класс сбоев, когда агент технически производит выход, но не продвигается. Три их формы встречаются регулярно:

• Read-loop. Агент читает одни и те же пять файлов раз за разом, каждый раз чуть иначе их резюмируя, ничего не пишет. Траты токенов реальны, прогресс — ноль
• Спираль test-fix-test. Агент гоняет тесты, видит падение, «чинит» его так, что появляется новое падение, снова гоняет тесты — бесконечно. Каждый цикл даёт дифф, поэтому наивный мониторинг выхода это не ловит
• Шторм ретраев на rate limit. Агент упёрся в потолок, ретраит каждые несколько секунд, бесконечно логирует «retrying...». CPU низкий, память низкая, логи бегут, ничего не происходит

Общий признак всех трёх — повторение. Лог здорового агента — последовательность разных действий: прочитать этот файл, потом тот, потом записать другой, потом запустить команду. Лог застрявшего агента — одни и те же три строки, переплетённые час. Самая простая алярмa, которая это уверенно ловит, — метрика «уникальных вызовов инструментов за последние 20 минут». Если ответ — двойка или тройка, агент в цикле.

Как Office Claws показывает эти сигналы

Всё перечисленное реализовано в десктоп-приложении в этом месяце:

• Активити-фид — живой поток каждого вызова инструмента, чтения файла, команды и хода модели от каждого агента, сведённый в одну панель
• Состояния пиксельного офиса — идёт / печатает / простаивает, питаются от RPC-стрима с VPS агента
• Лог-стрим — полный stdout/stderr по каждому агенту, со скроллбэком, с фильтром по агенту
• Rate-limit бейджи — цветной индикатор у агента, когда остаток сообщений падает ниже порога
• Детектор простоя — агенты, не производившие выхода в конфигурируемом окне, помечаются в офисе; анимация персонажа переключается на idle, бейдж стола становится жёлтым

Смысл не в том, что без Office Claws это недоступно. Смысл в том, что именно эти четыре сигнала и должен показывать дашборд кодинг-агентов, и любой самодельный сетап, в котором одного из них нет, пропускает соответствующий режим сбоя.

Что мониторить не стоит

Три вещи, которые кажутся важными и обычно не являются:

1. CPU и память на VPS. Сессия Codex CLI ест ~200МБ RAM и почти не трогает CPU — работа идёт в модели, не на дроплете. Если у вас агент забивает CPU — что-то не так с вашим кодом, а не с агентом
2. Uptime сети. Tailscale переподключается сам. Тридцатисекундный разрыв не повлияет на идущую сессию агента. Алерт на это — только шум
3. «Всё ещё работает спустя N часов» как сигнал успеха. Время выполнения само по себе — ловушка: застрявший агент счастливо проработает 24 часа. Сшивайте время с выходом — тогда появляется смысл

Минимальный самодельный сетап

Если не используете 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. Распарсите последние 20 минут event-лога Codex, посчитайте уникальные вызовы инструментов
2. Посчитайте файлы, изменённые в /repo за последние 20 минут
3. Прочитайте заголовок rate limit из самого свежего API-ответа
4. Если unique-tools ≤ 2 и files-changed = 0 два окна подряд — дёрните вебхук

Вот и всё. Сорок строк шелла, один крон, один вебхук туда, где вы читаете уведомления. Грубовато, но ловит три режима сбоя, которые важны. Пиксельный офис выглядит приятнее, но решает ту же задачу.

Однострочная версия

Мониторинг кодинг-агента — не про то, жив ли процесс, а про то, движется ли работа. Активность говорит что-то делает, выход — что-то производит, стоимость — может продолжать, застревание — реально ли прогрессирует. Смотрите все четыре. По отдельности не верьте ни одному.

По теме

• How to Run Multiple Codex Agents at Once — мониторинг усложняется пропорционально числу агентов
• Long-Running Codex Tasks — почему ночным задачам нужны все четыре сигнала, а не только uptime
• Cutting AI Agent Costs — сигнал стоимости подробнее, включая когда переключаться с Plus на Pro