Прод-агент на Claude без LangChain и RAG: архитектура за 712 строк для студии интерьеров

Независимый разработчик опубликовал на Хабре подробный разбор архитектуры продакшн-агента на Claude, созданного для небольшой студии дизайна интерьера. Вся система умещается в один файл main.py на 712 строк кода и два системных промпта — никакого LangChain, никаких RAG-фреймворков и векторных баз данных.

Из каких компонентов состоит агент

Роли двух моделей Claude разделены чётко по типу задачи. Чат-интерфейс работает на Claude Haiku 4.5: модель быстро отвечает на вопросы клиентов, уточняет запрос и ведёт диалог. За генерацию дизайн-концепций отвечает Claude Sonnet 4.6: он превращает пожелания клиента в структурированное описание интерьера. Фотографии для визуализации концепций берутся из библиотеки Pexels — это существенно дешевле и быстрее, чем генерировать изображения через DALL-E.

Ключевые параметры решения:

• Claude Haiku 4.5 — диалог с клиентом: быстро и экономично
• Claude Sonnet 4.6 — генерация структурированных дизайн-концепций
• Pexels API — подбор фотографий вместо DALL-E
• Один файл main.py, 712 строк кода, два системных промпта
• Никаких оркестраторов, векторных баз, фреймворков поверх API

Выбор такой архитектуры не случаен. Для студии с ограниченным бюджетом и небольшим потоком клиентов полноценный RAG-стек — избыточная инженерия. Haiku обходится дешевле в диалоге; Sonnet подключается только там, где нужна структурированная творческая генерация. Нет смысла решать проблему масштаба, которой ещё нет.

Какие грабли встретились в работе?

Первый неочевидный момент — порог кэширования промптов у Claude Haiku 4.5. Кэш контекста включается только от 4096 токенов. Если системный промпт короче этого порога, каждый запрос считается новым — кэширование не работает совсем. При интенсивной нагрузке это заметно влияет и на стоимость запросов, и на задержку ответа.

Второй нюанс — поведение Sonnet 4.6 при структурированном выводе. Модель иногда оборачивает JSON-ответ в дополнительный текстовый блок вместо того, чтобы вернуть чистый JSON. Стандартный `json.loads()` в таком случае падает с ошибкой. Автор опробовал несколько стратегий парсинга и остановился на простой обёртке с fallback-логикой — это надёжнее, чем ловить JSON регулярными выражениями.

«Это не гайд от эксперта — скорее дневник развилок.

Я постарался честно написать, почему принял каждое решение», — объясняет разработчик.

Отдельного внимания заслуживает логика разделения моделей. Автор пробовал обрабатывать всё одной моделью, но быстро убедился: Haiku стоит использовать там, где важна скорость и стоимость, а Sonnet — там, где нужно качество структурированного вывода. Попытка сэкономить, гоняя генерацию концепций через Haiku, дала заметно худший результат.

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

Разработчик честно обозначает границы своего решения. Один файл на 712 строк нормально работает для MVP и небольшой студии, но при масштабировании возникнут проблемы:

• При росте клиентской базы понадобится хранение истории диалогов — без векторной базы или внешнего хранилища не обойтись
• Если студия захочет принимать и анализировать фотографии от клиентов, потребуется мультимодальный пайплайн
• Логирование агента в файл — не вариант при нескольких параллельных пользователях и реальной нагрузке
• По мере роста промпты сложнее тестировать и версионировать в одном файле

Главный вывод, который делает автор: для задачи с узкими и чёткими границами «без RAG» — это не ленивое решение, а осознанный архитектурный выбор. Фреймворки решают реальные проблемы масштаба, но создают и новые: сложность, зависимости, инфраструктурный overhead. Если проблема ещё не возникла, не стоит создавать её ради инструмента.

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

Публикация показывает: Claude API достаточен для боевого агента без вспомогательных фреймворков, если задача достаточно конкретная. Для разработчиков, начинающих строить агентов на Claude, это честный разбор реальных граблей — порог кэша у Haiku 4.5, парсинг JSON у Sonnet 4.6, осознанное распределение задач между моделями разного уровня.