Зачем нам 200 инструментов и 5 чатов: как мы строим ИИ-агентов в финтехе

Сегодня интеграцией искусственного интеллекта ^[1] в рабочие процессы никого не удивишь. Однако разница между быстрым прототипом на базе стороннего API и полноценной системой внутри корпоративной инфраструктуры для работы с внутренними данными и бизнес-задачами огромна.

Мы запустили в СВОЙ Тех ^[2] процесс внедрения собственного AI-ассистента и внутренней платформы специализированных ИИ-агентов. Рассказываем, как устроена наша архитектура «под капотом», какие инструменты мы подключили, с помощью каких чатов решаем бизнес-задачи и как управляем контекстом.

Представьте, что AI-модель — это очень умный стажер с амнезией. Он умеет отлично рассуждать, но по умолчанию не имеет доступа к корпоративным системам и забывает ^[3] контекст, когда диалог становится слишком длинным. Чтобы такой «стажер» работал эффективно, ему нужны: базовые правила и роль, рабочие материалы и выписки из баз, дополнительные инструкции под конкретные задачи и доступ к системам компании. Всё это помогает ИИ-агенту решать задачи: обращаться к модели, использовать нужные данные и инструменты.

Архитектура: AI-ассистент — это не просто чат

За привычным интерфейсом ввода и вывода сообщений у нас работает многокомпонентная система:

Мы разделяем систему на следующие ключевые слои:

1. AI-модель — вычислительный компонент, который обрабатывает переданный ей контекст и генерирует ответ. По умолчанию модель не имеет доступа к внутренним системам и актуальным корпоративным данным.

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

3. Рабочая среда обеспечивает доступ к инструментам и выполнение задач. Контекст — информация, которую система передаёт модели: запрос, история диалога, инструкции и необходимые данные.

4. System Prompt и Skills — базовые и дополнительные инструкции, которые система передаёт модели по мере необходимости.

5. Tools — методы взаимодействия с внешними системами и обработчиками данных.

На чём построена наша платформа
Основную логику ^[4] ИИ-агентов мы разрабатываем на Python с использованием фреймворка Deep Agents, который помогает управлять сложными задачами и работой с инструментами. Для подключения и маршрутизации запросов к разным AI-моделям используем LiteLLM, а Langfuse позволяет отслеживать работу агентов, анализировать ошибки ^[5] и расход токенов. Локальные модели запускаем с помощью SGLang — он обеспечивает их работу внутри нашей инфраструктуры.

Управляемость агента: базовые правила и навыки

Чтобы повысить предсказуемость и управляемость поведения ^[6] агента, мы разделили инструкции, управляющие его поведением ^[7], на два уровня:

• System Prompt: базовые правила и роль агента. 
  Это набор постоянных инструкций, которые передаются при каждом запросе, задавая формат ответов и ограничения на действия.

• Skills: дополнительные инструкции под конкретный тип задачи. 
  В нашей реализации на старте сессии агент знает только названия и короткое описание доступных навыков (например, «составление специфического отчета»). Когда в диалоге возникает соответствующий шаг, агент считывает полную инструкцию навыка и выполняет алгоритм. Это уменьшает объем контекста и количество лишней информации, передаваемой модели.

Контекстное окно и управление историей

Модель обрабатывает поступающий текст и формирует ответ на его основе. Объем информации (запрос, история диалога, загруженные файлы, выдержки из баз данных) ограничен размером контекстного окна. Чем больше история диалога, тем больше информации приходится обрабатывать модели и тем сложнее удерживать фокус на релевантном контексте.

Как мы с этим работаем:

• В длинных диалогах система может автоматически сокращать историю, сохраняя основные факты и выводы. Так в контексте остаётся больше места для текущей задачи.

• Чтобы снизить риск смешения контекста и нерелевантных ответов, мы рекомендуем пользователям открывать новый чат для каждой новой крупной задачи.

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

Какие инструменты мы задействовали

Для работы с корпоративными системами мы создали более 200 отдельных методов в собственном MCP-сервере. Они позволяют агентам искать информацию, работать с документами, анализировать данные и выполнять другие задачи.

Поиск и работа с базами знаний: векторный поиск по базе знаний Confluence, поиск задач в Jira и прямое получение содержимого страниц и задач из корпоративных систем.

Работа с документами: извлечение и обработка содержимого файлов различных форматов, включая PDF и Word.

Аналитика и базы данных: получение информации о структуре баз данных, поиск таблиц и выполнение SQL-запросов в ClickHouse.

Работа с исходным кодом: просмотр репозиториев GitLab, файлов, истории изменений и merge request’ов.

Создание отчётов: построение графиков, обработка результатов и формирование PDF-документов.

Это лишь часть доступных возможностей. Помимо перечисленных, агенты используют и другие специализированные инструменты в зависимости от поставленной задачи.

Специализированные чаты и какие бизнес-задачи они решают

Мы отказались от идеи единого универсального бота. В зависимости от задач и доступного контура данных у нас развернута линейка специализированных чатов с жестко прописанными ролями и набором доступных инструментов:

Практический пример работы с документами и отчетами

По нашим внутренним наблюдениям, Qwen лучше справляется с задачами, где нужно последовательно использовать несколько инструментов: она чаще доводит работу до результата. Gemma быстрее выполняла аналогичные задачи с тем же контекстом. Поэтому модель выбираем под конкретную задачу.

Практический кейс:

В чат загружается документ с результатами внутреннего опроса (например, 30 ответов на 10 вопросов) с задачей провести анализ и составить диаграмму.

1. Агент извлекает данные из документа с помощью инструмента парсинга.

2. Модель определяет, что нужно посчитать, а инструмент для вычислений (например, Python) рассчитывает показатели и готовит данные для графиков.

3. Модель анализирует полученные результаты, а агент с помощью инструмента генерации PDF собирает отчёт с выводами и графиками. Если данных недостаточно, агент может снова обратиться к модели и инструментам.

Безопасность и планы по развитию

Локальные модели и вспомогательные компоненты работают внутри корпоративной инфраструктуры. Данные не передаются во внешние AI-сервисы, а доступ к внутренним системам остаётся под нашим контролем.

В ближайших планах развития проекта:

1. Интеграция с корпоративным мессенджером: запуск ботов для быстрой подачи заявок на доступы и автоматического создания тикетов инцидентов в Service Desk прямо из диалога.

2. Внедрение протокола MCP: стандартизация подключения локальных инструментов для разработчиков и аналитиков.

3. Разделение контуров: выделение отдельного изолированного сервера под банковский и продуктовый контуры с повышенным уровнем защиты данных.

4. Оценка эффективности: переход к систематическому сбору обратной связи, оценке экономии трудозатрат и экономическому обоснованию масштабирования серверных мощностей.

Построение собственной платформы ИИ-агентов — это путь ухода от иллюзии «всемогущего чат-бота» к прагматичной инженерной системе. Полноценная автоматизация рабочих процессов с помощью LLM требует четкого разделения ролей, контроля используемых данных и подключения узкоспециализированных инструментов. Главный вывод нашего опыта ^[8]: автономные ИИ-агенты становятся действительно полезными только тогда, когда перестают быть «игрушкой для общения» и превращаются в управляемый инструмент взаимодействия с корпоративными системами.