Пролог: Двигатель без Автомобиля
По итогам первого 72-часового R&D-спринта у меня на руках был мощный, но изолированный RAG-прототип(статья). Он был "умным", итеративным, построенным на основе пяти передовых научных статей и умел отлично отвечать на вопросы. Это был state-of-the-art двигатель, собранный по последнему слову инженерной мысли.
Но был один нюанс. Этот двигатель просто лежал на испытательном стенде. Он не мог никуда "ехать" и взаимодействовать с реальным миром. Он был немым и безруким.
На финале хакатона перед нами встала амбициозная и очень продуктовая задача. У нас было 5 дней, чтобы взять мощный, но изолированный RAG-прототип — "двигатель", способный отвечать на сложные вопросы, — и построить вокруг него полноценный "автомобиль": многофункциональную, полезную для бизнеса AI-платформу.
Первый выбор: на каком "топливе" поедет наш автомобиль?
Выбор темы техподдержки и финансов(условие этапа) не был случайным. Проработав в этой сфере, я на собственном опыте знаю, сколько времени уходит на поиск ответов в разрозненных базах знаний. Именно эта "боль" стала идеальным полигоном для тестирования нашего ассистента. Я хотел создать инструмент, который я сам хотел бы иметь в своей ежедневной работе.
Главный архитектурный принцип: строим не машину, а конвейер
Однако с самого начала ключевой идеей было не создание узкоспециализированного "финансового бота". Нашей целью было спроектировать универсальный фреймворк, где конкретная область — будь то финансы, HR или логистика — является лишь набором сменных "плагинов" (инструментов).
Поэтому настоящий вызов второго этапа звучал так:
Как научить систему не просто отвечать, а действовать — создавать события в календаре, ставить задачи, взаимодействовать с любыми API — и сделать это так, чтобы завтра можно было легко "перенастроить" ассистента на совершенно другую область?
История этих 5 дней — это не просто рассказ о том, как я решил задачу для техподдержки. Это история о том, как я превратил исследовательский прототип в проактивную, гибкую и по-настоящему универсальную платформу(надеюсь) для создания цифровых ассистентов
Часть 1: Проектирование "Нервной Системы" — Архитектура на FastMCP
Чтобы объединить наш RAG-модуль, интеграции с Google API и клиентские приложения в единую, надежную систему, нужен был правильный "клей". Простой API на FastAPI — рабочий вариант, но он не решает проблем интерактивности и стандартизации, критически важных для AI-систем. Нужно было что-то более специализированное.
Решением стало использование FastMCP в качестве "нервной системы" для нашего ассистента.
Почему FastMCP стал идеальным выбором для платформы?
Я выбрал этот фреймворк по трем ключевым причинам:
Стандартизация "Навыков": FastMCP позволяет "обернуть" любую бизнес-логику — будь то наш сложный RAG-пайплайн или простой вызов Google API — в единый формат Инструментов (Tools), понятный для AI. Это превращает разнородные функции в стандартизированные "плагины".
Интерактивность из коробки: В отличие от классического REST, протокол MCP, на котором основан FastMCP, является двунаправленным. Это позволило мне использовать механизм Context для получения от агента его "мыслей" и статуса выполнения в реальном времени, что критически важно для отладки и прозрачности.
Архитектура "Мозг и Тело": Фреймворк изначально продвигает разделение интеллектуального ядра ("мозг") и интерфейсов ("тело"). Это позволило мне создать единый, мощный бэкенд и подключать к нему совершенно разные клиентские приложения, не меняя основной код.
В результате архитектура проекта полностью преобразилась.
Наш RAG-пайплайн, который был сердцем исследовательского прототипа, теперь стал лишь одним из многих инструментов, доступных центральному AI-агенту. Это был ключевой шаг от "продвинутого поисковика" к "многофункциональному ассистенту".
Часть 2: Рождение "Мыслящего" Агента (Эволюция в ReAct)
Иметь набор инструментов — это полдела. Главный вызов заключался в том, чтобы научить AI-агента самостоятельно выбирать нужный инструмент и, что еще важнее, вызывать их последовательно для решения сложных задач.
Столкновение с реальностью
Первая же попытка заставить агента работать с Google Calendar выявила фундаментальную проблему. Я отправил в Telegram-бот простой запрос:
"Какие у меня встречи завтра?"
Агент правильно выбрал инструмент list_google_calendar_events, но упал с ошибкой. Почему? Потому что он не смог самостоятельно преобразовать слово "завтра" в точную дату (2025-11-16...), которую требовало API. Он был как стажер, который знает, какую кнопку нажать, но не знает, какие данные ввести в поля.
Стало очевидно, что нужен был не просто "выбиратель" инструментов, а настоящий оркестратор.
Прорыв — Цикл "Разум-Действие" (ReAct)
Чтобы решить эту проблему, я полностью переработал логику агента, внедрив классический цикл ReAct (Reason-Act).
Новый "навык": Сначала я создал очень простой, но критически важный инструмент — get_datetime_range. Его единственная задача — принимать на вход запрос на естественном языке (вроде "завтра" или "через час") и, используя LLM, возвращать точный диапазон дат в формате ISO.
-
Новый "мозг" (Промпт): Я кардинально изменил промпт главного агента. Теперь он требовал от LLM не просто выбрать инструмент, а следовать строгому циклу:
Thought (Мысль): Сначала проанализируй запрос и свою "память" (историю предыдущих шагов) и опиши, какой следующий логический шаг нужно сделать.
Action (Действие): Затем, на основе своей "мысли", либо вызови инструмент, либо, если задача решена, дай финальный ответ.
Новая логика (Код): main_agent_router превратился из одноразовой функции в цикл, который мог выполняться до 5 раз. На каждой итерации он "показывал" модели историю предыдущих мыслей и результатов, позволяя ей корректировать ��вой план.
Это превратило нашего ассистента из простого исполнителя в настоящего "мыслителя". Вот как теперь выглядит его рабочий процесс:
После этого рефакторинга агент успешно справился с задачей. Вот реальный лог его работы:
Шаг 1, Мысль: "Пользователь спрашивает о встречах на завтра. Сначала мне нужно определить временной диапазон для 'завтра', используя get_datetime_range."
Шаг 1, Действие: Вызывает get_datetime_range.
Шаг 2, Мысль: "Я определил диапазон дат. Теперь нужно получить список событий из Google Calendar, используя list_google_calendar_events."
Шаг 2, Действие: Вызывает list_google_calendar_events с правильными датами.
Шаг 3, Мысль: "Я получил список событий. Задача пользователя решена. Я готов дать финальный ответ."
Шаг 3, Действие: Генерирует финальный ответ.
Этот прорыв превратил набор несвязанных инструментов в единый, синергичный организм, способный к самостоятельному планированию.
Часть 3: "Приземление" на Продукты — Клиентские Интерфейсы
Мощный бэкенд бесполезен, если к нему нет удобного доступа. За 5 дней второго спринта мы создали два совершенно разных клиентских приложения, чтобы продемонстрировать гибкость нашей платформы.
Сценарий 1: "Организационный Помощник" в Telegram.
Для большинства задач, от быстрых поручений до глубокого анализа, идеальным интерфейсом является мессенджер. Я разработал Telegram-бота на библиотеке aiogram, который стал единой точкой входа ко всем возможностям нашего "Глобального Ассистента".
Ключевая особенность — бот является "тонким" клиентом. Вся его логика сводится к трем простым шагам:
Принять текстовое или голосовое сообщение от пользователя.
Отправить его на наш главный MCP-эндпоинт (/mcp) для обработки агентом.
Получить финальный ответ и отобразить его в чате.
Вся интеллектуальная работа — будь то многошаговое планирование встречи или поиск по базе знаний — происходит на сервере. Это позволяет нам обновлять и «умножать» интеллект ассистента, не трогая код бота. Именно через этого бота мы и тестировали все сценарии:
«Умная Техподдержка»: Пользователь задавал вопрос, и агент, вызвав RAG‑инструмент, предоставлял исчерпывающий ответ из базы знаний.
«Организационный Помощник»: Пользователь давал сложные команды, и агент последовательно вызывал инструменты Google API.
Таким образом, Telegram‑бот стал полноценным «пультом управления» всей нашей AI‑платформой.
Сценарий 2: "Аналитик Документов" в Вебе
Для более узкоспециализированных задач, требующих работы с большими объемами текста, сокомандник создал простой веб‑интерфейс на чистом HTML/CSS/JS.
В отличие от Telegram‑бота, этот UI не использует главного агента‑оркестратора. Он напрямую вызывает специализированный инструмент analyze_document, передавая ему текст и выбранную пользователем задачу (например, «сделать резюме»).
Технические вызовы и решения
Интеграция с веб-фронтендом выявила несколько классических проблем full-stack разработки, которые наша архитектура позволила элегантно решить:
Проблема CORS: Запросы от фронтенда (на localhost:8080) к бэкенду (на localhost:8000) блокировались браузером. Я решил это, добавив на сервер CORSMiddleware, который явно разрешает такие кросс‑доменные запросы.
Проблема протокола: Простой браузерный fetch не «понимает» потоковый протокол FastMCP. Я решил это, настроив сервер на отдачу ответов в режиме stateless_http и json_response=True, что заставляет его отвечать простым, чистым JSON, понятным для любого веб‑клиента.
Вывод: Всего за 5 дней мы с сокомандником не просто «обернули» наш RAG‑движок, а создали полноценную платформу, которая доказала свою гибкость, успешно обслуживая два совершенно разных типа клиентов и решая задачи, выходящие далеко за рамки простого поиска.
Часть 4: Прозрачность и Контроль — Наследие Первого Этапа
Создать «умного» агента — это полдела. Гораздо сложнее — сделать его предсказуемым, отлаживаемым и контролируемым. Фундамент для этого был заложен еще на первом, исследовательском этапе проекта, и он полностью окупил себя при разработке сложной многошаговой логики.
"Мы видим каждую мысль"
Главным принципом нашей архитектуры стала полная прозрачность (Observability). Мы не просто получаем финальный результат, мы видим весь процесс его получения.
Как видно из логов, благодаря механизму Context в FastMCP, мы можем отслеживать весь мыслительный процесс агента в реальном времени, с эмодзи чтобы быстро видеть в простыне логов:
? Мысль агента: — Мы видим, почему агент принял то или иное решение.
? Агент вызывает инструмент: — Мы видим, какой инструмент и с какими аргументами он вызвал.
? Результат: Observation: — Мы видим, какой результат вернул инструмент, и как это повлияет на следующий шаг.
Это полностью устраняет эффект «черного ящика», превращая отладку сложного AI‑поведения из гадания в системный инженерный процесс.
Бенчмарки: Измеряем все, что важно
Прозрачность позволяет нам собирать точные метрики. Встроенные в нашу платформу ResourceManager и TimingMiddleware автоматически отслеживают ключевые показатели производительности и затрат для каждого запроса, даже для самых сложных.
Вот пример бенчмарков для многошаговых сценариев:
Время ответа: От 5–7 секунд для простых вызовов API до 15–25 секунд для сложных, двухшаговых задач, требующих нескольких вызовов LLM.
Стоимость: Даже комплексный запрос, включающий 3-4 обращения к языковой модели (для планирования и вызова инструментов), обходится в среднем всего в ~$0.01.
Потребление ресурсов: Пиковое потребление RAM стабилизируется на уровне ~800 MB после загрузки RAG-моделей, что является приемлемым для серверного приложения.
Вывод: Наш фокус на прозрачности с самого первого этапа позволил нам не только легко отлаживать сложную агентскую логику, но и получить полный контроль над производительностью и экономикой системы. Мы точно знаем, как работает наш ассистент и сколько это стоит.
Часть 5: Урок на 14-е Место — Продукт Важнее Технологии
После восьми дней интенсивной работы — 72 часов R&D-спринта и 5 дней продуктовой разработки — наступил момент истины: финал хакатона и объявление результатов.
Наша "Команда 73" заняла 14-е место.
Этот результат, на первый взгляд, может показаться разочаровывающим после стольких усилий. Но для меня он стал самым важным и честным уроком всего этого марафона.
Почему так вышло?
На протяжении всего хакатона мой фокус был на техническом совершенстве. Я был глубоко погружен в архитектурные дебри: строил многошагового ReAct-агента, оптимизировал RAG-пайплайн, отлаживал асинхронный код. Моей главной целью было создать state-of-the-art платформу, которая бы работала как швейцарские часы или просто работала. И, как показали логи и тесты, мне это удалось.
Однако финал — это не соревнование по программированию. Это питчинг продукта. Жюри оценивало не только сложность архитектуры, но и то, насколько понятно, убедительно и сфокусированно мы можем донести ценность нашего решения для конечного пользователя и бизнеса.
И здесь я допустил классическую ошибку инженера. Я был настолько увлечен тем, как работает проект, что, вероятно, не смог достаточно просто и ярко донести, зачем он нужен. Моя презентация была полна технических деталей, но ей, возможно, не хватило продуктовой легкости.
Ценность 14-го места
Этот результат — яркое напоминание, что в реальном мире побеждают не самые сложные технологии, а продукты, которые решают понятную проблему и о которых можно просто рассказать.
Этот опыт заставил меня выйти из "инженерного пузыря" и посмотреть на свою работу глазами пользователя, менеджера и инвестора. 14-е место — это не оценка моего кода. Это оценка моей способности донести его ценность. И я невероятно благодарен жюри за этот честный и отрезвляющий фидбэк. Он сделал меня не просто лучшим программистом, а более зрелым инженером.
Заключение: От "Движка" к Будущему
Этот хакатон начинался для меня как чисто технический вызов — спринт по R&D, а закончился как бесценный продуктовый урок.
Что было создано?
За 8 дней интенсивной работы, практически в одиночку, был пройден путь от научных статей до полноценного, рабочего прототипа гибкой AI-платформы. Я (а с финала и "мы") создал не просто "чат-бота для банка", а универсальный фреймворк, который умеет:
Думать и планировать: разбивать сложные задачи на последовательность действий.
Действовать: взаимодействовать с внешними API и внутренними базами знаний.
Быть прозрачным: показывать каждую свою "мысль" и измерять собственную эффективность.
Что дальше?
Именно результат финала и определил будущее проекта. Фундамент — мощная и гибкая платформа — готов. Теперь следующие шаги — это не наращивание технической сложности, а продуктовая работа:
Сфокусироваться на одном, самом "больном" сценарии (например, "Умная Техподдержка") и довести его до идеала с точки зрения пользовательского опыта (UX).
Провести "кастдев" (customer development): поговорить с реальными сотрудниками и выяснить, что им действительно нужно, а не то, что я, как инженер, считаю "крутым".
Упростить! Возможно, для 90% задач не нужен сложный ReAct-агент, а достаточно простого RAG. Платформа позволяет легко переключать эти режимы, и теперь задача — найти правильный баланс для конкретного продукта.
Финальная мысль
Этот второй, продуктовый спринт научил меня главному: как строить мост между сложной AI‑разработкой и реальными потребностями пользователей. Он на практике показал, что самый совершенный «двигатель» бесполезен без продуманного «автомобиля», который удобен водителю и решает его задачи. И этот урок, полученный благодаря честной оценке жюри, ценнее любого призового места.
ГитХаб проекта - https://github.com/Runoi/Final-AIforFinanceHack2025