ИИ-агент на Claude без LangChain и RAG: когда простая архитектура выигрывает

Вокруг LLM-агентов быстро появился набор почти обязательных слов: LangChain, RAG, векторная база, graph workflow, tools, memory. Из-за этого легко забыть простую мысль: не каждой задаче нужна сложная агентная платформа. Иногда production-полезность даёт аккуратный Python-сервис с двумя промптами, несколькими внешними API и понятной логикой ветвления.

Например, агент на Claude для небольшой студии дизайна интерьера может обойтись без тяжёлого стека: чат отвечает на более лёгкой модели, генератор концепций — на более сильной, фото берутся из Pexels, а не генерируются отдельной моделью. Без LangChain, без RAG-фреймворка и без векторной базы. Такой сценарий хорошо ставит инженерный вопрос: где фреймворк помогает, а где только добавляет абстракций.

Почему не всегда нужен RAG

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

Для небольшого продукта часто достаточно:

• хорошо сформулированного системного промпта;
• явного состояния диалога;
• нескольких функций для внешних данных;
• строгого формата ответа;
• логирования запросов и ошибок;
• ручного набора тестовых сценариев.

Такой подход проще отлаживать. Если агент ошибся, понятно, где смотреть: промпт, входные данные, парсинг ответа или внешний API.

Разделение моделей по ролям

Интересная часть архитектуры — разделение задач между моделями. Необязательно всё гонять через самую дорогую и сильную модель. Лёгкая модель может вести диалог, уточнять требования и отвечать на типовые вопросы. Более мощная — генерировать концепцию, где важны структура, стиль, нюансы и качество JSON.

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

JSON как контракт

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

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

• строгая схема ответа;
• парсер с понятными ошибками;
• повторный запрос при невалидном JSON;
• логирование исходного ответа;
• тесты на типовые поломки;
• fallback-сценарий для пользователя.

Без этого агент будет хорошо выглядеть на демо и ломаться на реальных диалогах.

Кэширование и ограничения моделей

Даже простая архитектура упирается в детали конкретной модели: лимиты контекста, особенности prompt caching, стоимость токенов, latency. Если модель поддерживает кэширование системного промпта или большого неизменяемого блока, этим стоит пользоваться. Но важно понимать пороги и условия, при которых кэш реально срабатывает.

В production это влияет не только на деньги, но и на UX. Пользователь не должен ждать лишние секунды там, где ответ можно получить дешевле и быстрее.

Где подход начнёт ломаться

Минималистичная архитектура хороша, пока задача ограничена. Она начнёт трещать, если появятся:

• большой корпус знаний;
• разные источники с актуализацией;
• сложные цепочки действий;
• необходимость объяснять источники ответа;
• параллельные tool calls;
• много ролей и прав доступа;
• требования к audit trail.

В этот момент RAG, workflow-engine или агентный фреймворк могут стать оправданными. Но это должен быть ответ на реальную сложность, а не стартовая точка по умолчанию.

Практический вывод

Для небольших AI-сервисов лучше начинать с самой простой архитектуры, которую можно объяснить на одной схеме. Модель, промпт, состояние, внешние API, валидатор ответа, логирование. Если этого хватает — не нужно тащить в проект лишний слой.

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