Проблемы ИИ-агентов в продакшене: почему фреймворки не решают главных задач

При запуске ИИ-агентов в продакшене команды часто тратят недели на выбор фреймворка. LangChain или CrewAI? AutoGen или OpenAI Agents SDK? Однако опыт эксплуатации десятков агентов для платящих клиентов показывает: выбор фреймворка — это отвлекающий фактор. Фреймворк оркеструет вызовы LLM, и любой из них справляется с этой задачей.

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

Агент вызывает один и тот же инструмент 200 раз за 4 минуты. Причина — неоднозначные данные от нижестоящего сервиса, из-за которых LLM принимает решение повторять попытки бесконечно. Счет за API вырастает с нескольких долларов в день до сотен.

Без обнаружения циклов на уровне исполнения проблема часто замечается только после того, как бюджет уже потрачен. Хуже того — без журнала аудита нельзя даже определить, какой именно агент вызвал аномалию.

VPS перезагружается ночью для установки патчей ядра. Каждый агент, находившийся в середине задачи, теряет всё состояние. Наутро агент поддержки не помнит вчерашние тикеты, исследовательский агент забывает контекст расследования, агент конвейера перезапускается с нуля.

Это не проблема фреймворка. Это проблема отсутствия персистентного слоя памяти, способного переживать сбои, перезагрузки и повторные развертывания.

Клиент сообщает, что агент предоставил неверную информацию три дня назад. При попытке отладки выясняется: нет записи о том, что агент видел, какие решения принял и какие инструменты вызывал. Фреймворки не являются инструментами наблюдаемости — они не логируют цепочки принятия решений.

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

При масштабировании до 15 агентов, работающих совместно, двое из них могут иметь противоречивые представления об одном и том же клиенте. Причина — изолированная память каждого агента. Клиент получает два разных ответа в одном разговоре в зависимости от того, какой агент ответит первым.

Общая память между агентами в одной команде — обязательное условие для согласованной работы.

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

1. Фреймворк — оркестрация вызовов LLM. Использовать тот, который знает команда. Это самый дешевый и заменяемый слой.

2. Персистентная память — слой, определяющий, является ли агент прототипом или продуктом. Обеспечивает непрерывность работы при сбоях.

3. Обнаружение петель — механизм на уровне исполнения, отслеживающий повторяющиеся вызовы и останавливающий агента до взрывного роста счета.

4. Журнал аудита — запись каждого решения агента с цепочкой хэшей для воспроизводимости и доказательной базы.

5. Общая память — единое пространство контекста для агентов, работающих в одной команде.

6. Отслеживание затрат — мониторинг расхода бюджета в разрезе каждого агента.

На рынке существует несколько решений, закрывающих отдельные потребности:

• Память: Mem0, Zep, Letta — персистентные хранилища контекста для агентов.
• Наблюдаемость: Helicone, LangSmith — инструменты для мониторинга и трассировки вызовов.

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