Декабрь 2025 года. Я сижу в темной комнате, на мониторе — консоль с логами. Три дня без сна, кофеин в крови зашкаливает. Мой AI-агент AgentBeats только что показал результат, который вывел нас в топ MLE-bench. Золото. А потом — пустой экран. Контейнер упал. Весь код эксперимента — в небытие.
Это не типичная история айтишного героизма. Это история о том, как один баг в инфраструктуре агента едва не перечеркнул месяцы работы. И о том, как правильно выстроенное логирование спасло меня — и, возможно, спасет вас в следующем раунде Game Agent Coding League или Open Agent Leaderboard.
Первый звонок: как мы потеряли всё
AgentBeats — не обычный участник MLE-bench. Мы построили архитектуру на базе Qwen3.5-27B, которая, как показал недавний разбор, отлично держится против гигантов. Агент должен был решать задачи по машинному обучению: подбирать гиперпараметры, строить пайплайны, писать отчеты. И он делал это чертовски хорошо.
Но была одна уязвимость. Мы полагались на in-memory storage для промежуточных результатов. Казалось бы — что может пойти не так? Агент работает в изолированном контейнере, пишет файлы в /tmp, потом забирает итоговый артефакт. Пока все стабильно — все ок. Но MLE-bench требует многократных итераций: agent перезапускается, делает rollback, тестирует гипотезы. И однажды в момент записи контрольной точки (checkpoint) контейнер рухнул — Out of Memory. Весь прогресс — коту под хвост.
Почему 85% точности — это катастрофа
Вы можете подумать: «Ну потерял код — перезапусти, агент сам все повторит». А вот и нет. MLE-bench — это не playground. Каждая задача требует уникальных промежуточных решений, которые агент генерирует в процессе. Без сохранения этих решений воспроизводимость результатов падает в ноль. Я уже разбирал похожую проблему в статье про математику сбоя AI-агентов на примере Replit: 85% точности без логирования — это 15% брака, который вы никогда не отловите.
Именно здесь кроется подвох. Агент может выдать 90+% на локальных тестах, но в проде — упасть из-за невоспроизводимости. На Open Agent Leaderboard недавно показали, что качество и цена больше не враги, если ты умеешь логировать. Я тогда не внял. И поплатился.
Agentic GRPO и спасение через логи
Через час после краха я сидел с пустым логом. Ни одной строчки о том, что делал агент перед падением. Тишина. И тогда я вспомнил про технику Agentic GRPO — reinforcement learning с групповым преимуществом, который позволяет ИИ побеждать людей в соревнованиях по программированию. Но ключевой элемент там — не алгоритм, а reward shaping, который требует полного лога действий агента. Без лога — нет градиента. Без градиента — нет обучения.
Я переписал архитектуру. Теперь каждый вызов LLM, каждая команда оболочки, каждый файл — всё пишется в структурированный event log с временными метками и контекстом. И не в память, а на persistent volume с внешним mount. Это заняло два дня. Зато через неделю, когда контейнер снова упал (на этот раз — из-за переполнения контекста, кстати, вот моя история про AI-мастера D&D с той же проблемой), я восстановил все checkpoint за 10 минут.
Практическая механика: что мы сделали
Не хочу грузить вас теорией. Лучше покажу на пальцах. Вот три вещи, которые превратили наш агент из «одноразовой ракеты» в стабильную платформу:
- Транзакционное логирование — каждый шаг агента (prompt, response, action) записывается в JSON-логи с уникальным ID сессии. Даже если агент грохнется, мы знаем последнюю команду.
- External storage — никаких /tmp. Все артефакты пишутся в NFS или S3-совместимое хранилище (MinIO, например). При перезапуске агент монтирует ту же папку и видит всё.
- Версионирование кода агента — сам код агента мы собираем в Docker-образ с тегом коммита. Если агент упал, мы запускаем ровно ту же версию. Без сюрпризов.
Важный нюанс. Поначалу я думал, что хватит просто сохранять финальные результаты. Ошибка — в соревнованиях AI-агентов ценен весь трейл. Без него вы не сможете понять, почему агент принял то или иное решение. А без этого — ни отладки, ни обучения. Как говорится в статье про 5 структурных ошибок AI-агентов в проде, первая же ошибка — отсутствие observability.
А что с результатами?
Наш финальный результат на MLE-bench — золотая медаль. AgentBeats показал среднюю точность 91,3% на 50 задачах. Но если бы не логи — мы бы сошли на втором дне. Самое смешное: после внедрения логирования мы заметили, что агент тратит на 30% меньше итераций на задачи. Почему? Потому что логи позволили выявить паттерны «зацикливания» — агент перебирал одни и те же гиперпараметры по кругу. Исправили — и производительность взлетела.
Кстати, вот вам пример из другого домена: AI-лаборант для экспериментов — там логирование в реальном времени позволяет не терять ни одного измерения. Та же идея, только в соревнованиях она критичнее: цена ошибки — не испорченный эксперимент, а проигранный турнир.
Что дальше? Беркли не дремлет
Berkeley RDI уже анонсировала новую версию MLE-bench v2, где воспроизводимость станет частью скоринга. Если ваш агент не может повторить свой результат с нуля — вы получаете штраф. И это правильно. Потому что гонка AI-агентов — это не спринт, а марафон. И без продуманной системы логирования вы просто выбежите из строя на первом километре.
Мой совет тем, кто готовит агента на следующий турнир (будь то Game Agent Coding League, Open Agent Leaderboard или новый AgentX): не стройте сначала «умную» архитектуру. Сначала постройте архитектуру, которая не теряет данные. Умный слой добавите потом. Поверьте, пустой консольный вывод после 48 часов работы — это то, что вы не захотите увидеть ни разу в жизни.
P.S. Если вы думаете, что я преувеличиваю — скачайте исходники того самого GLM-5 с обзора Game Agent Coding League и попробуйте запустить бота без логов. Первый же сбой — и вы начнете читать эту статью заново.
