LangChain في الإنتاج: شرح Habr AI لماذا تنتقل الأنظمة متعددة الوكلاء إلى Python الخالص

На Habr AI вышел подробный разбор того, почему production-мультиагентные системы не всегда выигрывают от LangChain. Автор описывает стек на чистом Python и показывает, где универсальные LLM-абстракции перестают экономить время и начинают ломать предсказуемость.

Где ломается абстракция

Главная претензия к LangChain в статье — обещание «переключить модель одной строкой» почти никогда не работает так же просто в реальном сервисе. На практике даже модели одного провайдера ведут себя по-разному: дорогая версия стабильно возвращает JSON, а более дешёвая начинает менять ключи, забывать системные инструкции и путаться в few-shot примерах. Если к этому добавить другого провайдера вроде YandexGPT, то ломается уже не только формат ответа, но и сами категории, на которых завязана downstream-логика.

«Абстракция вредна, когда она делает вид, что разные вещи одинаковы.»

Из этого вытекает и вторая мысль: фоллбек между OpenAI и YandexGPT — это отдельная инженерная задача, а не галочка в конфиге. Для каждого агента нужны отдельные промпты, единая схема валидации и тестовый набор реальных обращений. В описанной системе порог допуска для резервного провайдера — 85%, а результат любого вызова проходит через Pydantic-схему до отправки клиенту. Поверх этого автор выносит провайдеров в Protocol-интерфейсы, чтобы общее поведение было единым, а различия в промптах, авторизации и форматах оставались явными.

RAG без магии Отдельный блок статьи посвящён RAG, где «три строки кода» тоже быстро заканчиваются.

Смена embedding-модели без переиндексации базы знаний, по сути, обнуляет смысл векторного поиска: запросы и документы оказываются в разных пространствах, а система формально продолжает работать, просто находя не те куски текста. То же самое происходит с изменением chunk size: старые документы нарезаны одним способом, новые другим, и качество поиска превращается в лотерею, которую пользователь замечает раньше команды. Поэтому в production, по версии автора, важнее не удобный chain, а полный контроль над retrieval-конвейером.

Когда ответ уходит реальному клиенту, команде нужно видеть не только красивый итоговый текст, но и всю дорогу до него: какой фильтр применился, какие чанки попали в контекст, какие были score и почему один документ победил другой. Без этой прозрачности отладка превращается в угадайку, а проблемы всплывают уже после жалоб пользователей. score и метаданные каждого чанка кандидатов, которые не прошли отбор фильтрацию по продукту, клиенту или сценарию обновление базы знаний без простоя ## Контроль важнее агента Самым хрупким местом автор называет tool calling.

Модель может выбрать не тот инструмент, передать неправильные параметры или вовсе отказаться от вызова и уверенно сгаллюцинировать ответ. В статье это объясняется на простом примере: пользователь спрашивает про личное расписание, а агент идёт не в CRM, а в базу знаний и отдаёт общее описание курса. Попытка чинить такие ошибки одними промптами часто приводит к новым edge cases, потому что модель принимает решения вероятностно, а не детерминированно.

Из-за этого в собственной архитектуре автор переносит критичную маршрутизацию из LLM в rule-based классификатор, а модель оставляет только для неоднозначных случаев. Поверх него стоят явные контракты у агентов, отдельные клиенты для CRM и базы знаний, типизированные ответы, retry для временных сбоев и эскалация на человека, если валидный результат так и не получен. Дополнительный аргумент — безопасность: чем меньше фреймворк и его транзитивные зависимости, тем ниже attack surface и тем проще понять, что именно защищает систему.

Итоговая система работает на FastAPI, напрямую использует провайдерские SDK, ChromaDB и Bitrix24 API, а не общий orchestration-layer. В open-source версии у проекта около 4500 строк кода, 170 тестов и 84% покрытия. Это больше ручной работы, чем в сценарии с готовым фреймворком, но зато каждый шаг можно логировать, воспроизвести и проверить отдельно.

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

Что это значит

Разбор Habr AI хорошо фиксирует сдвиг в LLM-разработке: фреймворки по-прежнему удобны для прототипов и демо, но в production ценность смещается к явным контрактам, валидации и наблюдаемости. Чем больше у системы провайдеров, интеграций и бизнес-рисков, тем труднее прятать различия за одной абстракцией и тем важнее контролировать каждый стык вручную.