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

Автор материала, не являясь профессиональным разработчиком, за несколько рабочих дней создал ИИ-агента для небольшой студии дизайна интерьера. Студия состоит из одного дизайнера, одновременно ведущего три-четыре проекта. Основная проблема на входе — клиенты пишут в WhatsApp поздно вечером, и к утру часть уже уходит к конкурентам из-за отсутствия ответа. Вторая боль — клиенты часто не могут сформулировать свои пожелания, приходят на встречу без идей.

Из этих двух проблем родились две сущности. Первая — чат-агент, который мгновенно отвечает на типовые вопросы об услугах, тарифах и сроках, а затем мягко переводит разговор на встречу с дизайнером. Вторая — эндпоинт /brief: клиент заполняет короткую форму, и на выходе получает три заметно разных концепции интерьера — с палитрой, материалами, мебелью, светом и четырьмя фотографиями из Pexels на каждую. Генератор не заменяет дизайнера, а готовит первую встречу: клиент приходит уже с пониманием, какое направление ему откликается.

Техническое решение минималистично: стек состоит из Claude Haiku 4.5 для чата и Claude Sonnet 4.6 для генерации концепций, FastAPI на Railway для бэкенда, Pexels API для подбора фото и статичного фронта на VPS. Весь код умещается в один файл main.py на 712 строк, два промпта и четыре эндпоинта. Разработчик сознательно отказался от LangChain, LlamaIndex, векторных баз и RAG-фреймворков. Причина — тщательный анализ задачи показал, что эти инструменты избыточны. Оркестрация цепочек не требуется, так как у системы одна линейная цепочка: сообщение → один запрос к LLM → ответ. RAG для тарифов и услуг не нужен, поскольку весь контент студии помещается в 2,5 тысячи токенов системного промпта и меняется редко (тарифы — раз в квартал, услуги еще реже). Векторная база не нужна: история диалога короткая (5–10 сообщений), услуг всего семь, а проектов у дизайнера около 30 в год. Агент-роутер с тулами также излишен: чат не обращается к внешним системам, а у /brief есть только один жестко привязанный тул (поиск фото в Pexels), который не выбирается агентом.

Автор отмечает, что данный подход имеет границы применимости. Он начинает ломаться, когда появляются три и более параллельных цепочек, требуется реальный роутинг между моделями или сложный multi-step агент с тулами. Также он не подходит для динамически меняющегося контента, который не помещается в окно системного промпта. Однако для узких задач с одной цепочкой «вопрос-ответ» или «бриф-генерация» голый HTTP-запрос к API LLM оказывается проще и надежнее, чем внедрение тяжелых фреймворков. Этот случай — иллюстрация того, что выбор инструментов должен определяться реальными требованиями задачи, а не распространенными гайдами.