Діагностика прихованих помилок у планувальниках фонових агентів Claude Code
Аналіз інциденту в продакшені демонструє, як фонові агенти обслуговування процесів Claude Code давали збій протягом 38 днів через відсутність змінних оточення в планувальнику завдань. Розглянуто критичні помилки автодіагностики.
Чому це важливо
Застосуйте ці перевірки для власних автономних скриптів, щоб уникнути ситуацій, коли агент проходить ручні тести, але непомітно падає у фоновому планувальнику вночі.
TL;DR
- 01Фонові планувальники часто не мають стандартних змінних оточення на кшталт HOME, що спричиняє приховані збої.
- 02Оцінюйте активність сесій агентів за максимумом із мітки lastActivityAt та часу зміни файлу транскрипту.
- 03Явно забороняйте автономним агентам створювати дублюючі скрипти-вбивці під час розслідування системних помилок.
Ключові факти
- Тривалість інциденту
- 38 днів без фіксації помилки
- Втрачені ресурси
- 138 завислих CLI-процесів, споживання ~5.5 ядер CPU
- Результат очищення
- Знижено до 30 процесів (~1 ядро)
- Помилки нормалізації ОС
- 2095 із 3062 кроків (68%) розпізнано некоректно
Пастка ручної верифікації
Під час розгортання скриптів обслуговування для довготривалих сесій Claude Code CLI логіка перевірки часто розходиться між інтерактивним терміналом і планувальником завдань. У задокументованому випадку скрипт перевірки успішно проходив у ручному режимі, але непомітно падав уночі протягом 38 днів, оскільки планувальник Windows не передавав змінну оточення $HOME.
Сім кореневих помилок агентної інфраструктури
Аналіз виявив сім критичних збоїв архітектури, про які слід пам'ятати під час налаштування фонових агентів:
- Односторонні перевірки сумісності, які взагалі ігнорувалися на цільовій ОС.
- Тести, що легітимізували баги, перевіряючи некоректні команди як допустимі.
- Помилки визначення ОС через парсинг рядків до нормалізації (68% хибних спрацьовувань, 2095 із 3062 кроків).
- Розсинхронізація раннерів, коли другий раннер записував статус поза зоною видимості зчитувача.
- Помилки редиректу bash під Windows, коли
>NULстворював реальний файл розміром 973 байти в синхронізованій папці. - Фантомні прапорці CLI, описані в інструкціях, але відсутні в коді.
- Помилкове визначення активності, коли життєздатність сесії оцінювалася лише за
lastActivityAt, а не за комбінацією зmtimeтранскрипту.
Захисні промпти для автономних завдань
Щоб уникнути конфліктів фонових процесів, системні інструкції для агентів мають прямо забороняти створення нових демонів очищення без попередньої аудиторської перевірки вже запущених завдань.
Спробуй за 2 хвилини
def is_session_alive(session_id, last_activity_at, transcript_path):
# Reconcile local state with filesystem mtime to prevent premature reaping
transcript_mtime = transcript_path.stat().st_mtime if transcript_path.exists() else 0
return max(last_activity_at, transcript_mtime)python
✓ Коли використовувати
- Застосовуйте підхід під час керування розподіленими фоновими воркерами Claude Code через планувальники завдань.
- Використовуйте для усунення аномального навантаження на процесор через завислі CLI-процеси агентів.
✕ Коли НЕ варто
- Не створюйте вторинні скрипти завершення процесів, якщо аналогічне завдання вже зареєстроване в планувальнику.
- Не покладайтеся на одиничні змінні стану в пам'яті для визначення активності сесії без перевірки файлової системи.
Що зробити сьогодні
- Перевірте фонові завдання cron та schtasks, щоб шляхи не покладалися на неявні змінні оточення на кшталт HOME.
- Оновіть логіку скриптів очищення процесів Claude, комбінуючи перевірку lastActivityAt та mtime файлу транскрипту.
- Додайте інструкції в промпти для агентів, що забороняють генерацію нових демонів до аудиту існуючих рішень.