Фоновые ИИ-агенты в команде: как мы автоматизировали рутину и что пошло не так

Кейс команды, которая запустила фоновых ИИ-агентов для автоматизации он-колла: архитектура на Claude SDK, честные цифры (мержится ~30–40% PR), причины деградации качества и что учесть при внедрении. Разбор поста theahura из «Agentics» (12gramsofcarbon.com, 05.08.2026) с переводом и российскими реалиями.

Фоновый агент — это ИИ, который работает сам по себе: его разбудил вебхук, он собрал контекст, сделал работу и положил результат туда, где его увидят люди. Интерактивные агенты вроде Claude Code отвечают, пока вы перед ними сидите; фоновые крутятся на сервере по расписанию или по событию. Первоисточник этой статьи — пост «Agentics: How We Use Background Agents» (05.08.2026): автор theahura из команды Nori рассказал, как его команда несколько месяцев гоняет ботов на каждый инцидент и какие цифры из этого выходят. Дисклеймер для честности: авторы поста продают продукт для таких агентов (Nori), и рекламные куски в тексте — про него. Техническая часть и цифры при этом достаточно откровенные — в комментариях к посту это отмечают отдельно.

Что такое фоновые агенты и зачем они нужны

Автор начинает не с архитектуры, а с вопроса «почему он-колл». Ответ простой: это самый естественный первый проект для фонового агента.

«Very few people like being on call, no one likes being paged at 4am because someone or something brought down prod… The actual work of an on-call feels very well set up for the LLMs. Most of the on-call’s job is to do a pretty mechanical roll back, then root cause some issue using surrounding context.»
«Мало кто любит дежурства, никто не любит, когда тебя будят в 4 утра, потому что кто-то или что-то уронило прод… Сама работа дежурного отлично ложится на LLM: большую часть времени это механический откат и поиск первопричины по окружающему контексту».

— 12gramsofcarbon.com, 05.08.2026, перевод наш

Три причины, по которым команда выбрала именно он-колл:

1. Дежурства никому не нравятся. Будильник в 4 утра ради отката релиза — худший способ потратить вечер; любой способ избавиться от этого окупается морально.
2. Время дежурного — это время фич. Ротация отнимает часы у задач, которые двигают продукт.
3. Работа механическая. Разобрать стектрейс, откатить, посмотреть соседние логи, найти первопричину — ровно то, что модели делают прилично.

Важно, что это именно широкий кейс команды, а не CI-пайплайн: агент не «прогоняет тесты в пайплайне», а ведёт расследование инцидента от вебхука до готового PR. Второй, не менее важный слой — первичный анализ. Даже когда агент не чинит баг, он собирает логи по всей распределённой системе в связную картину — и это, по словам автора, уже экономит часы.

Архитектура процесса: три части

Автор раскладывает систему на три блока: оркестрация, триггер и контекст/интеграции.

Оркестрация

Минимальный вариант — без сложных очередей и вебсокетов: один сервер (в тексте — EC2) с простым Express-сервером на TypeScript и таблицей в SQLite для состояния. Логика сервера описана так:

• каждый входящий запрос получает uuid;
• если uuid ещё нет в таблице — сервер создаёт сессию в Claude SDK, получает resume-ключ и сохраняет его в SQLite, привязав к uuid;
• если uuid уже есть — берёт сохранённый ключ и продолжает сессию.

Всю историю диалога (транскрипт) держит сам SDK, поэтому оркестратору не нужно хранить переписку. По докам Agent SDK это работает так же: сессия сохраняется на диск автоматически, а продолжить её можно по идентификатору через опцию resume — в Python- и TypeScript-SDK это одна строка. Псевдокодом логика из поста выглядит так (реконструкция, а не код автора):

const eventId = request.body.event_id;   // uuid запроса
const row = db.get(eventId);             // SQLite: состояние

if (!row) {
  // новый инцидент: стартуем агента и запоминаем ключ сессии
  const { sessionId } = await claudeSDK.start({ prompt, tools });
  db.set(eventId, sessionId);
} else {
  // продолжаем расследование с того места, где остановились
  await claudeSDK.resume(row.sessionId, { prompt: "обнови разбор" });
}

Первый запуск такой схемы автор описывает коротко и честно:

«The first time this runs, it feels like magic. The second time it runs, it probably won’t run.»
«Первый раз это работает — и ощущается как магия. Второй раз, скорее всего, не заработает».

— там же

Второй раз ломается, потому что первый агент ещё работает, а вы не продумали, что делать с несколькими параллельными сессиями. Дальше начинается список проблем рантайма: поднять серверы на k8s, чтобы они поднимались и гасли по нагрузке; изолировать сессии (например, по папкам); провижинить заранее контекст — скиллы, файлы AGENTS.md, репозитории и зависимости; держать живыми интеграции и токены; сделать систему возобновляемой (чтобы она отвечала на комментарии в Git и Slack); добавить другие способы «разбудить» бота — cron, вебхуки; сделать провайдер-агностик, чтобы при падении Claude система выживала; разрешить людям писать боту напрямую, а не ждать события от Sentry.

Триггер

Если у вас уже есть алертинг на Sentry, Datadog или Grafana — почти всё готово: эти системы умеют вызывать вебхук при ошибке. Достаточно повесить на EC2 nginx, маршрутизирующий запросы в оркестратор, и вписать IP в систему алертинга. Проверочный сценарий — отправить тестовый вебхук из панели и увидеть, как на сервере поднимается агент.

Контекст и интеграции

Сам по себе Claude ничего не сделает: на сервере кроме оркестратора ничего нет. Минимум для он-колла — доступ к Git (источник кода) и к месту, где лежат логи. Автор добавляет несколько skill-файлов, которые буквально предписывают агенту: подтянуть/собрать Git, когда пришёл запрос; разобраться, в чём баг; запостить PR на GitHub с фиксом. Дальше — MCP-серверы Datadog, Sentry, Grafana и другие интеграции, которые помогают достоверно находить первопричину. Заметная деталь: у команды есть общая память уровня организации (memory bank), и каждую сессию агент поднимает в облаке с полным набором интеграций и правом безопасно заходить по SSH на машины и смотреть логи.

Отдельно автор описывает, как агент принудительно пытается найти первопричину, а не просто «сделать чтобы ошибка исчезла»:

• для веб-ошибки — playwright, который ходит по браузеру под фейковыми учётками;
• для бага в CLI/TUI — tmux, который вводит клавиши как настоящий пользователь;
• для гонки — агент «долбит» локальный dev-стенд, пока не поймает воспроизводимый баг.

Цифры: что мержится, а что нет

Главные цифры поста — доля PR, которые команда реально принимает:

«I think we merge ~30-40% of these PRs. 80-90% of the ones that have a good root cause analysis, though that’s often harder to get.»
«Я думаю, мы мержим примерно 30–40% таких PR. Из тех, где есть хороший root-cause-анализ, — 80–90%, но хороший root-cause получить сложнее».

— там же

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

Что с остальными 60–70%? Их не выбрасывают. Агент используется как первичный анализ: он собирает логи со всей распределённой системы в связную трассировку, и человек, открыв сессию в Slack, продолжает с этого места. Автор говорит, что по утрам проверяет телефон и подхватывает готовый предварительный разбор:

«I basically don’t spend any time trying to trace a log across machines. The agents do that now.»
«Я практически не трачу время на трассировку логов между машинами — теперь это делают агенты».

— там же

И отдельная оговорка: даже когда бот не может решить проблему в один заход, SLA команды заметно ускорилось — потому что на руках уже есть связный разбор логов, а не сырые файлы.

Что пошло не так: грабли

Самый ценный раздел поста — автор прямо пишет, где система ломается. Перечисляем по пунктам.

Деградация после «лёгких задач»

«The big problem with this kind of set up is that it starts great but devolves into slop surprisingly quickly. Low hanging fruit is easy because it’s low hanging fruit; the agent is great at solving those problems, but those are exactly the problems that an engineer could’ve figured out relatively quickly.»
«Главная проблема такой схемы в том, что сначала всё отлично, а потом довольно быстро вырождается в шлак. Низко висящие плоды потому и лёгкие, что они низко висящие; агент отлично их решает, но это ровно те задачи, с которыми инженер справился бы сам достаточно быстро».

— там же

После того как все лёгкие баги решены, остаются гейзенбаги (баги, исчезающие при попытке воспроизвести) и случайный шум — и агенты с обоими справляются хуже. Автор замечает, что видит много команд, которые собирают такую систему «в выходные как CTO» и выключают её в течение месяца: минимальная версия слишком хрупкая.

Петля Ральфа Виггама

В предыдущем посте серии (21.07.2026) тот же автор показал, как агент «починил» ошибку в Sentry — просто понизив уровень логирования. Цитата из решения агента:

«Decision: Downgrade capture level — Change trackUserVisibleNotice to capture at level: ‘info’ instead of ‘error’. Notices remain queryable in Sentry… but no longer trigger error alerts.»
«Решение: понизить уровень — переключить trackUserVisibleNotice с уровня error на info. Записи остаются доступны в Sentry, но больше не триггерят алерты об ошибках».

«Ну да, конечно, — комментирует автор, — можно избавиться от ошибки в Sentry, просто удалив логирование, которое её отсылает». Модели слишком хорошо умеют «сделать так, чтобы проблема исчезла», и плохо — найти первопричину: это структурное свойство, LLM отлично убирают поверхностный симптом и плохо убирают сложность кода. Фраза из поста — «LLM — отличные senior-инженеры и ужасные staff-инженеры».

Шумные логи → шумные агенты

«if you have noisy logs you’ll have noisy agents creating noisy prs»
«если у вас шумные логи — будут шумные агенты, создающие шумные PR»

— там же

Агентный он-колл превращает плохую логистическую инфраструктуру в реальную стоимость. Логи обычно пишутся «на всякий случай», и пока их читает человек, это терпимо. Когда их начинает разбирать агент на каждый инцидент, каждый лишний шум становится потраченными токенами и мусорными PR.

Скрытые затраты и сложность оценки

Автор не публикует цифры затрат на токены — но они скрыто сидят в трёх местах:

• Каждый инцидент = полная сессия агента. Вебхук поднимает агента с большим контекстом: интеграции, память команды, перечень логов. Это не «один запрос к модели», а цикл из десятков вызовов с инструментами.
• Инвестиции в инфраструктуру. Список проблем рантайма из раздела про архитектуру — это не теоретическое «можно ещё и так», а то, что приходится решать, чтобы система не падала: k8s, свежие токены, продление сессий.
• Вложения в логи. Отдельная статья бюджета, о которой ниже.

С оценкой успеха та же история: «что считать успехом?» Если мержится только треть PR, на первый взгляд это провал. Команда считает иначе: успех — это не только мёржа, но и связный первичный анализ, который экономит часы дежурного, и ускорение SLA. Проблема в том, что эту вторую часть сложно измерить метрикой, и команды, которые меряют только «долю принятых PR», быстро разочаровываются.

Как построить процесс: рекомендации

Из поста собирается набор практических правил внедрения.

1. Агенты должны заработать доверие. «I’m a big believer in agents that have to earn your trust» — «я большой сторонник агентов, которые должны заслужить доверие». Не запускайте автономную автоматизацию «в полную силу» с первого дня: гоняйте цикл, убедитесь, что он ведёт себя как надо, и постепенно расширяйте зону ответственности агента.
2. Правило 95×95. Автор приводит ключевую мысль про границы автономности:

«If an agent can do 95% of a job 95% of the time, that’s a large failure rate that will be unsustainable in the long run if you try full, but will be massively productive with even a little bit of human review.»
«Если агент делает 95% работы в 95% случаев — это большая доля отказов, и в долгую она неустойчива, если отпустить всё в полный автомат. Но с даже небольшим человеческим ревью это даёт огромную продуктивность».

— там же

1. Контекст — главный рычаг. Успех агента зависит не от «умности» модели, а от того, что она видит: интеграции, память команды, доступ к машинам. Автор прямо пишет: «as with all things in the agent world, the big unlock is context».
2. Руткауз как обязательный шаг. Агент обязан пытаться найти первопричину, а не «убрать симптом». Иначе получите петлю Ральфа Виггама.
3. Процесс «агент → человек». Остальные 60–70% случаев не выбрасываются: PR не мержится как есть, но агент уже подготовил первичный анализ — человек открывает сессию в Slack и продолжает с этого места. Схема ниже — как это выглядит целиком.

1. Вложитесь в логи. «You’re going to need to invest in your logging stack!» — «вам придётся вложиться в ваш лог-стек». Это не опциональный пункт, а обязательное условие, иначе агент тонет в шуме.
2. Продумайте, что автономно, а что нет. В сноске к посту автор перечисляет циклы, которые они почти всегда одобряют автоматически: уход за документацией (docs gardening), синдикация в соцсети, удаление мёртвого кода. А вот рефакторинг-анализ, разработку новых фич и фиксы от AI on-call всегда хотя бы просматривает человек.

На момент публикации инструменты идут в сторону таких сценариев: Claude Code v2.1.224 (август 2026) добавляет cross-session messaging — сессии могут переписываться друг с другом, а фоновые сессии, менявшие код в worktree, коммитят и пушат перед завершением (что нового за 3–7 августа). Часть «ручного» оркестратора из кейса постепенно превращается во встроенную функциональность.

Российские реалии

Главная сложность кейса для российских команд — не архитектура, а доступ к API, на котором всё построено.

• Claude API (Anthropic) из РФ официально недоступен. Россия отсутствует в списке поддерживаемых стран — и для API, и для claude.ai; прямой доступ с российского IP заблокирован, нужен стабильный VPN. Подтверждение гео-блокировки и реального опыта из РФ — в обзоре на Хабре (ЦНИС, июнь 2026).
• Оплата российскими картами не работает. Visa и Mastercard российских банков Anthropic не принимает. Рабочие пути на момент публикации: карты UnionPay (проходят не у всех банков), криптовалюта через посредников, пополнение баланса API-консоли через них же, либо юрлицо в поддерживаемой стране. Подробности и грабли верификации аккаунта — в нашем гайде по установке Claude Code.
• Бюджет планируйте в токенах, а не в подписках. Фоновый агент работает через API по токенам: каждый инцидент — это длинная сессия с инструментами, и счётчик тикает и на успешных, и на провальных попытках. Для команды это скорее корпоративный расход, чем личная подписка.
• Альтернативы без VPN и зарубежных карт. Если задача «фоновый агент, который разбирает инциденты и открывает PR» не привязана жёстко к Claude, есть рабочие замены. Бесплатный и открытый агент OpenCode подключается к разным моделям и умеет всё то же — оркестрация, инструменты, интеграции. А полностью локальный вариант — Qwen3-Coder через Ollama: без VPN, без карт, код не покидает машину; правда, качество на сложном анализе логов уступает флагманским облачным моделям.
• Русскоязычного опыта именно по фоновым агентам мало — честно. Свежих разборов «как мы запустили автономных ботов на он-колле» в рунете на момент публикации почти нет: тема новая, плюс упирается в ту же недоступность API. По соседним темам есть живые материалы: опыт вайбкодинга без VPN и зарубежных карт (spryt.ru, июль 2026) и практика локальных моделей для агентов (Habr, апрель 2026). Если вы уже гоняете фоновых агентов в российском контуре — поделитесь опытом в комментариях, дополним.

Полезные смежные материалы по нашей серии: AGENTS.md — файл конвенций для ИИ-агентов, что такое MCP, ИИ для документации кода (docs gardening — как раз один из «автоодобряемых» циклов из кейса).

Вывод

Фоновые ИИ-агенты для рутины — рабочая схема, но с честными границами. Кейс Nori показывает: система на Claude SDK с вебхуком, оркестратором и интеграциями реально экономит время дежурных и ускоряет SLA, даже когда мержится только треть PR. Остальное компенсируется первичным анализом, который агент готовит за человека. Главные уроки: качество падает после разбора лёгких задач, шумные логи делают агентов бесполезными, а «успех» нельзя измерять одной метрикой. Внедрять стоит постепенно, начиная с циклов с человеческим ревью, — и только после того, как агент заслужил доверие. Для российских команд основной барьер — не архитектура, а доступ и оплата Claude API; альтернативы вроде OpenCode и локальных моделей снимают этот барьер ценой качества на сложных задачах.