AI-агенты в Rails: как внедрить автоматизацию без лишней магии

Разработчик gkosmo опубликовал подробный гайд по реализации AI-агентов в Rails-приложении на примере реального бизнес-кейса — автоматической обработки тикетов в службу поддержки. Подход отличается от типичных demo-проектов: минимум абстракций, максимум практичности.

Агент — это фоновая задача, которая умеет вызывать несколько методов. Перестаньте думать об этом как о чём-то большем — и всё встанет на место.

Что за фреймворк и зачем он нужен

Разработчик gkosmo опубликовал развёрнутый пост о том, как он использует AI-агентов в продакшн-приложении на Rails. Автор поддерживает два гема — rcrewai и rcrewai-rails — и применяет их на платформе nakyma.io. Это не нейтральный обзор, а описание собственного инструмента, и автор это честно признаёт.

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

Конкретный бизнес-кейс

Вот сценарий, на котором построен весь пример. Интернет-магазин. Клиенты пишут в поддержку. Сейчас оператор вручную читает каждый тикет, смотрит историю заказов, определяет тип обращения (возврат, вопрос по доставке или что-то ещё) и составляет ответ.

Автор заменяет человека на этапах «чтение» и «составление черновика», но оставляет отправку за живым сотрудником. Это принципиальная позиция: агенты готовят, человек подтверждает. gkosmo пишет, что каждый раз, когда он нарушал это правило, жалел об этом в течение недели.

Как устроена архитектура

Система использует два агента и две последовательные задачи.

Первый агент — «оператор поддержки». Его роль — ответить клиенту, опираясь на реальные данные о заказах. Ему доступен инструмент (tool) OrderLookupTool, который ищет заказы конкретного клиента. Важный нюанс: инструмент принимает только limit (количество заказов) и параметр customer, который инжектируется кодом, а не выбирается моделью. Модель буквально не может запросить чужие заказы — такого параметра просто нет.

Это изящная и дешёвая модель безопасности. Не сложные правила доступа, а отсутствие возможности сделать что-то запрещённое на уровне API.

Второй агент — «старший оператор». Он проверяет черновик первого агента на соответствие политике компании. Политика зашита прямо в backstory агента: возврат в течение 30 дней после доставки — без вопросов, после 30 дней — предложить кредит магазина, не обещать дат, которых нет в данных о заказе.

Второй агент получает на вход результат первого через параметр context: [draft]. В этом, по сути, и заключается вся «мультиагентность» — результат одной задачи становится входом для следующей. Никакой мистики, просто конвейер.

Что можно подглядеть для себя

Автор выделяет несколько деталей, которые стоит заметить.

Текст тикета вставляется в описание задачи напрямую. Никаких шаблонизаторов, никаких плейсхолдеров — просто Ruby heredoc. Объекты экипажа (crew) создаются под каждый тикет и уничтожаются после использования. Автор признаёт, что перестал пытаться делать их переиспользуемыми, и код стал короче.

output_schema — это ключевая деталь. Последняя задача возвращает не сырую строку от модели, а валидированный JSON. Если модель отклоняется от формата, система делает ретрай. Если у вас где-то в коде есть JSON.parse(response[/\{.*\}/m]) — это именно то, что заменяет output_schema.

Всё выполняется как фоновая задача (ActiveJob). Тикет создаётся, через 30 секунд у него есть категория и черновик ответа. Автор рекомендует выделить для очереди agents отдельного воркера, чтобы медленный вызов модели не блокировал, например, сброс паролей.

Наблюдаемость — отдельный гем

Ядро rcrewai — чистый Ruby, работает где угодно: в rake-задаче, в тестах, в консоли. Но когда всё запущено и кто-то спрашивает «а почему система сказала мадам Дюпон, что ей вернут деньги?» — нужен аудит.

Для этого существует rcrewai-rails. После установки и миграции появляются таблицы для экипажей, агентов, задач и выполнений. Каждый запуск записывается с входными данными, результатом, длительностью и ошибкой. Плюс дерево спанов с каждым промптом и вызовом инструмента. Всё это доступно через веб-дашборд по адресу /rcrewai.

Прагматичные мнения автора

gkosmo делится несколькими принципами, которые сложились за время работы с продакшн-системой.

• Двух агентов достаточно. Третьего автору ни разу не потребовалось — лучше доработать описание задачи.
• Политику бизнеса нужно класть в backstory, а не в векторную базу данных. Правило «30 дней, потом кредит магазина» помещается в одно предложение. RAG нужен, когда правила не влезают на страницу.
• Инструмент — это граница безопасности. Модель получает метод с аргументами, которые вы выбрали. Ничего больше.
• Никогда не отправляйте вывод агента клиенту напрямую. Пока черновик лежит в поле с префиксом draft_, всё в порядке. Убирать этот префикс — должно быть осознанным решением, а не случайностью.

Стоит ли пробовать

Подход gkosmo примечателен не оригинальностью, а наоборот — своей рутинностью. Автор последовательно разрушает ореол сложности вокруг AI-агентов. Нет оркестраторов на 11 сервисов, нет векторных баз, нет цепочек из пяти моделей. Есть два агента, две задачи, один инструмент с жёстко ограниченными правами и фоновая задача.

Это, конечно, взгляд разработчика одного инструмента, который заинтересован в его продвижении. Но сам паттерн — «агент как фоновая задача, которая вызывает несколько методов» — заслуживает внимания. Он вписывается в стандартный Rails-стек без дополнительной инфраструктуры, и именно это делает его применимым в небольших командах, у которых нет ресурса на полноценную MLOps-платформу.

Вопрос в другом: достаточно ли простого двухагентного конвейера для сложных сценариев поддержки, где контекст клиента размазан по десяткам тикетов и каналов? Скорее всего, нет. Но для типичного интернет-магазина с относительно простой структурой обращений — это вполне рабочий вариант, который не превратится в неподдерживаемый монстр через полгода.