5 ошибок при запуске ИИ-агентов в продакшене: готовые решения из практики

Промпт (текстовая инструкция для модели) закрывает только верхний слой работы ИИ-агента (программы, которая сама выполняет цепочку действий). Дальше начинается обычная инженерия: контекст, память, доступы, инструменты, состояние, git, фоновые задачи. Если не проектировать каждый из этих слоёв отдельно, агент справится с короткой задачей, но начнёт сыпаться на длинной. Ниже пять ошибок, которые автор оригинального материала зафиксировал из собственной практики, и пошаговые способы их избежать.

Что понадобится

• Доступ к любой платформе для создания ИИ-агентов: Claude, ChatGPT, собственный код на Python или no-code-конструктор
• Базовое понимание git (системы контроля версий кода): что такое ветка, коммит, push
• Понимание, что такое токены (единицы текста, которыми модель измеряет объём: одно русское слово это примерно полтора-два токена)
• Время: 30 минут на чтение и адаптацию правил под свои задачи

Пошаговая инструкция: пять ошибок и как их исправить

1. Выделите память и контекст в отдельную подсистему

Пока задачи короткие, агент справляется: получил вводные, прочитал файлы, выдал результат. Но стоит задачам накопиться, контекст превращается в свалку. В одном месте остаются длинные логи, в другом снимки браузера, в третьем история диагностики, которая уже не относится к текущей задаче.

Результат: нужные решения теряются среди мусора, а фоновые задачи дорожают, потому что каждый раз стартуют с раздутым контекстом.

Конкретный пример из практики автора: в каждую изолированную фоновую задачу попадал список из более чем двухсот инструментов. Это давало около 50 тысяч токенов на один запуск ещё до начала реальной работы. А обычный вопрос «сколько потратили токенов?» запускал живой анализ десятков сессий на дорогой модели и обходился примерно в 1,35 миллиона токенов за один ответ.

Что делать:

• Сырые ежедневные заметки отправляйте в отдельные daily notes
• Долгосрочные правила и выводы помещайте в курируемую память (вручную отобранные записи, которые агент использует постоянно)
• Перед ответами по прошлым решениям пусть агент ищет нужные фрагменты через семантический поиск (поиск по смыслу, а не по точному совпадению слов), а не перечитывает всё подряд
• Тяжёлые фоновые отчёты заранее готовьте дешёвой моделью в markdown-файлы
• Основная сессия читает готовый результат, а не поднимает аналитику с нуля
• Для фоновых задач ограничивайте набор инструментов: если healthcheck нужен для пары действий, ему не нужен доступ к двумстам инструментам

# Пример структуры памяти агента (псевдокод)

memory_config:
  daily_notes: "./notes/{date}.md"        # сырые записи дня
  curated_memory: "./memory/rules.md"     # долгосрочные правила
  search_method: "semantic"               # поиск по смыслу
  background_reports: "./reports/"         # готовые отчёты
  tool_limits:
    healthcheck: ["ping", "status"]       # только нужные инструменты
    diagnostics: ["logs", "metrics"]

2. Запретите агенту переписывать git-историю без подтверждения

Когда агент работает с кодом, ветками и миграциями, рано или поздно локальная история расходится с удалённой. Человек в этот момент останавливается и разбирается. Агент без жёсткого правила может пойти коротким путём и просто перезаписать удалённую ветку через force-push.

Из практики автора: при миграции между dev, beta и prod на dev возникла цепочка проблем. Локальная master-ветка разошлась с удалённой, pull через fast-forward стал невозможен, pull в development-ветке запустил rebase (перестроение истории коммитов) и получил конфликты в шести файлах. Первый push после частичного решения всё равно отклонился, потому что коллега успел добавить коммит в ту же ветку.

Правило, которое стоит зафиксировать в системном промпте (постоянной инструкции для агента):

# Правило для агента: git-безопасность

ЗАПРЕЩЕНО:

- git push --force без явного подтверждения пользователя
- Любой rebase при наличии конфликтов без остановки

ОБЯЗАТЕЛЬНО:

- При конфликте rebase: выполнить rebase --abort, вернуться в чистое состояние, остановиться и запросить подтверждение
- При расхождении с remote: сделать обычную интеграцию (merge), а не переписывать историю
- Зафиксировать в отчёте, был ли force-push

Чеклист миграции, который автор выработал на практике:

1. Принять задачу и входные данные
2. Проверить доступ к удалённому репозиторию
3. Обновить локальные master/development
4. Проверить рабочую ветку
5. Проверить незакоммиченные изменения
6. Отправить изменения
7. Проверить pipeline, страницы и логи
8. Зафиксировать в отчёте, был ли force-push

Выглядит муторно, но только до первого случая, когда этот порядок спасёт работу. В итоге миграция автора прошла обычными merge-операциями без force-push, а все три окружения вернули HTTP 200 на проверяемых страницах.

3. Не делайте ставку на браузерную автоматизацию как основной путь

Браузерная автоматизация через VNC (удалённый рабочий стол) и CDP (Chrome DevTools Protocol, протокол управления браузером) кажется удобным способом закрыть задачи, где нет API. Открыл Chrome, перешёл на страницу, нажал кнопку, вставил текст, опубликовал.

На практике браузер оказывается одним из самых хрупких слоёв системы. Автор столкнулся с этим напрямую: задачи, которые выглядели простыми, ломались из-за обновлений интерфейсов, капч, динамической подгрузки элементов и десятков других непредсказуемых факторов.

Что делать:

• Используйте браузерную автоматизацию только как запасной вариант, когда API действительно нет
• Выносите браузерные сессии в отдельные дешёвые процессы, чтобы основная рассуждающая сессия (reasoning session) не раздувалась логами и снимками экрана
• Закладывайте в систему обработку ошибок: если элемент не найден, агент должен остановиться, а не кликать наугад

Что делать с этим прямо сейчас, по ролям

Автору на Дзене. Если вы используете ИИ-агента для подготовки контента (сбор фактуры, генерация черновиков, аналитика канала), настройте разделение памяти. Пусть агент не перечитывает всю историю переписки при каждом запросе, а работает с готовыми сводками. Это сократит расходы на токены и повысит точность ответов.

Маркетологу и предпринимателю. Если в вашей компании ИИ-агенты автоматизируют рутину (отчёты, мониторинг, публикации), проверьте два момента: есть ли у агента ограничения на опасные действия (удаление данных, перезапись) и разделена ли память на слои. Без этого расходы на API растут незаметно, а одна ошибка агента может стоить дороже месяца его работы.

Разработчику ИИ-агентов. Зафиксируйте правила git-безопасности в системном промпте до первого инцидента. Добавьте чеклист миграции из пункта 2. Ограничьте набор инструментов для фоновых задач. Эти три вещи дают измеримый результат при минимальных усилиях.

В России для экспериментов с ИИ-агентами доступны YandexGPT и GigaChat, а также открытые модели (модели с доступным исходным кодом), которые можно запускать локально. Принципы управления контекстом и памятью одинаковы для любой платформы.

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