AI-воркфлоу аналитика от и до: связка MCP, агента и базы знаний

Три месяца назад я собрал первый прототип: MCP-сервер к Jira, болванку RAG на проектной документации и LLM-звонок для черновика отчёта. По отдельности каждая часть давала профит. Jira-сервер находил задачи за секунды. RAG вытаскивал релевантный ADR по запросу на русском. LLM-модель неплохо структурировала вывод. Но вместе они не работали. Совсем.

Причина банальная: я собрал три разрозненных инструмента и ожидал, что они сами поймут, кто кому что передаёт. А они не поняли. MCP возвращал JSON в сыром виде, RAG подсовывал чанки без учёта контекста задачи, а LLM честно галлюцинировала по неполным данным. Красивые по отдельности кубики Lego, которые отказывались скрепляться друг с другом.

Понадобился ещё месяц, чтобы выстроить связки: MCP → нормализация данных, нормализованные данные → индекс RAG, RAG + MCP → общий контекст для агента, агент → LLM с полной картиной, LLM → структурированный результат. И когда это заработало — картинка сложилась. Именно этот пайплайн я разбираю ниже.

Если у вас уже поднят MCP-сервер для Jira и Confluence и настроен RAG на проектной документации, но между ними — ручной перенос данных и копипаст — эта статья про то, как их подружить.

Три слоя: почему по отдельности не работает

Упрощённо: AI-воркфлоу аналитика — это три независимых слоя, каждый из которых решает одну задачу. И каждый не знает о существовании соседей, пока вы не построите между ними интерфейсы.

Слой доступа (MCP). Его задача — вытащить данные из рабочих систем. Jira: задачи, эпики, спринты, комментарии. Confluence: спецификации, ретроспективы, протоколы встреч. База данных: метрики, схемы, исторические отчёты. Что MCP не делает: не структурирует данные, не фильтрует по релевантности, не связывает задачи из Jira с требованиями из Confluence. Это просто труба с краном на конце.

Слой знаний (RAG). Индексирует документацию и позволяет искать по ней семантически. Запрос «как мы обосновывали выбор брокера сообщений» — получаете три чанка из ADR про Kafka. Что RAG не делает: не видит живые данные из Jira (задачи в спринте меняются каждый день), не знает контекст текущей рабочей сессии, не ходит в базу за цифрами. Работает только с тем, что было проиндексировано.

Слой исполнения (агент). Координирует, планирует, вызывает инструменты, генерирует результат. Агент — это «мозг» воркфлоу. Но без первых двух слоёв его контекст пуст. Модель пишет отчёт по спринту, не видя задач спринта. Ищет противоречия в требованиях, не имея доступа к самим требованиям. Получается красиво, но бесполезно.

Если первые два слоя — это «глаза и память», то агент — «голова». Без глаз и памяти голова выдумывает. Без головы глаза и память просто складируют данные, которые никто не читает.

Схема целиком

Давайте посмотрим на полный пайплайн. Четыре источника данных, два канала их обработки и один агент, который всё это сводит к результату.

graph TB
  JIRA["Jira<br/>задачи, эпики"]
  CONF["Confluence<br/>спецификации"]
  BD["БД<br/>схема, отчёты"]
  DOCS["Документы<br/>ТЗ, ADR, переписка"]

  MCP_J["MCP Server<br/>Jira"]
  MCP_C["MCP Server<br/>Confluence"]
  MCP_D["MCP Server<br/>PostgreSQL"]

  CHUNK["Чанкер<br/>разбиение"]
  EMBED["Embedding<br/>векторизация"]
  VDB["Векторная БД<br/>PGVector / Qdrant"]

  AGENT["AI-агент<br/>планировщик, память,<br/>ReAct-цикл"]
  LLM["LLM<br/>Claude / GPT"]

  REPORT["Отчёт по спринту<br/>статус, блокеры, тренды"]
  ANALYZE["Анализ требований<br/>противоречия, пропуски"]
  DRAFT["Черновик ADR<br/>контекст, решение, риски"]

  JIRA --> MCP_J
  CONF --> MCP_C
  BD --> MCP_D
  DOCS --> CHUNK
  CHUNK --> EMBED
  EMBED --> VDB

  MCP_J --> AGENT
  MCP_C --> AGENT
  MCP_D --> AGENT
  VDB --> AGENT

  AGENT --> LLM
  LLM --> AGENT

  AGENT --> REPORT
  AGENT --> ANALYZE
  AGENT --> DRAFT

  style JIRA fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style CONF fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style BD fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style DOCS fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style MCP_J fill:#7b68ee,stroke:#5a4db2,color:#fff
  style MCP_C fill:#7b68ee,stroke:#5a4db2,color:#fff
  style MCP_D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style CHUNK fill:#f0a500,stroke:#c88400,color:#fff
  style EMBED fill:#f0a500,stroke:#c88400,color:#fff
  style VDB fill:#f0a500,stroke:#c88400,color:#fff
  style AGENT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style LLM fill:#7b68ee,stroke:#5a4db2,color:#fff
  style REPORT fill:#50c878,stroke:#3a9a5c,color:#fff
  style ANALYZE fill:#50c878,stroke:#3a9a5c,color:#fff
  style DRAFT fill:#50c878,stroke:#3a9a5c,color:#fff

На схеме три горизонтальных слоя. Верхний (синий) — источники данных: Jira, Confluence, БД и проектная документация. Средний (фиолетовый и жёлтый) — слой обработки: слева MCP-серверы для оперативных систем, справа RAG-пайплайн для документов (чанкер → эмбеддинг → векторная БД). Нижний (синий + зелёный) — агент с LLM, который получает данные из обоих каналов, строит план и выдаёт результат: отчёт, анализ или черновик ADR.

Двойная стрелка между агентом и LLM — это ReAct-цикл. Агент не просто вызывает модель один раз. Он думает, решает какой инструмент дёрнуть, дёргает, смотрит результат, думает снова. И так несколько итераций, пока не придёт к финальному ответу.

Слой доступа: как MCP встраивается в воркфлоу

MCP в этой схеме — не самостоятельный продукт. Это слой-прокладка между агентом и рабочими системами. Задача: дать агенту унифицированный интерфейс к данным, которые меняются каждый день.

Что важно спроектировать на этом слое:

Нормализация ответов. Jira возвращает полотно JSON с вложенными полями, историей изменений и кастомными атрибутами. Confluence — HTML с вики-разметкой. База — сырые строки таблиц. Если скормить это агенту как есть, он потратит половину контекстного окна на парсинг мусора. Нужен промежуточный слой, который обрезает лишнее и приводит к единому формату: заголовок, дата, краткое содержание, ссылка на источник.

Разграничение инструментов. У агента не должно быть одного гигантского инструмента «найди всё». Нужны атомарные: search_issues (Jira), search_pages (Confluence), run_query (БД), get_document (RAG). Агент сам решает, какой дёрнуть, исходя из плана. Это важнее чем кажется: когда инструментов ровно столько, сколько источников, агенту проще строить план «что дёргать», чем когда у него одна кнопка «получить данные».

Кэширование на уровне MCP-сервера. Одна и та же задача спринта не должна дёргаться из Jira трижды за один воркфлоу. Сервер кэширует ответы с TTL (time-to-live) хотя бы на минуту. Экономия токенов и времени: агент дёргает get_issue("PAY-341") для контекста, потом ещё раз для анализа связей — и получает кэш, а не новый запрос к Jira API.

Слой знаний: RAG как долговременная память

Если MCP даёт агенту «глаза» — оперативные данные из систем, — то RAG даёт «память». Документация, которая не меняется каждую минуту, но должна быть доступна по семантическому запросу.

RAG в связке с агентом работает иначе, чем standalone RAG. В standalone-режиме вы задаёте вопрос — RAG возвращает чанки, LLM генерирует ответ. В агентном воркфлоу RAG — это один из инструментов агента. Агент решает, когда к нему обратиться и с каким запросом.

Пример: агент получил задачу «проанализируй требования к безопасности платёжного шлюза». Он идёт в MCP → Jira, находит задачи спринта с тегами security и payment. Видит ссылку на ADR-005. Дёргает RAG: «найди ADR-005». RAG возвращает полный текст решения. Агент сопоставляет требования из ADR с задачами из Jira и находит расхождение: ADR предписывает трёхфакторную аутентификацию, а в задачах спринта — двухфакторная. Без RAG агент бы этого не заметил — у него был бы только заголовок задачи, но не содержание архитектурного решения.

Ключевые решения при интеграции RAG в воркфлоу:

• Инструмент, а не pipeline. Агент вызывает RAG когда нужно, а не на каждый запрос. Это экономит токены и не зашумляет контекст нерелевантными чанками.
• Метаданные в индексе. Каждый чанк должен нести не только текст, но и источник: «ADR-005, раздел Решение, дата 2026-04-12». Агент использует это для перекрёстных ссылок с данными из MCP.
• Свежесть индекса. Если документация обновляется раз в спринт — индексация раз в спринт. Если каждый день появляются новые ADR — индекс обновляется nightly. Агент должен знать, что данные в RAG актуальны на определённую дату, и учитывать это при анализе.

Агент: как собрать «мозг» воркфлоу

Я использую ReAct-агента (Reasoning + Acting). Это не единственный паттерн, но самый прозрачный для отладки. Цикл выглядит так:

1. План. Агент получает задачу и строит план: какие данные нужны, из каких источников, в каком порядке.
2. Действие. Вызывает инструмент — MCP-сервер, RAG-поиск или встроенную функцию.
3. Наблюдение. Получает результат, оценивает его полноту. Если данных не хватает — возвращается к шагу 2 с новым запросом.
4. Генерация. Когда контекст собран, вызывает LLM для финального вывода.

Реальный трейс одного моего запуска: агент на задачу «подготовь сводку по спринту 24» сделал 7 вызовов инструментов — три к Jira (спринт, эпики, незакрытые задачи), два к Confluence (ретроспектива, спецификация фичи), один к RAG (ADR про архитектурное решение), один к базе (метрики сборки). И только после этого сгенерировал отчёт. Ручной сбор тех же данных занял бы у меня минут двадцать минимум.

Что помещается в системный промпт агента:

• Роль: «ты AI-ассистент системного аналитика, твоя задача — собирать, анализировать и структурировать информацию…»
• Доступные инструменты с описанием: что каждый делает, какие параметры принимает, что возвращает.
• Правила: «всегда ссылайся на источники», «если данные противоречивы — отметь расхождение», «не додумывай цифры».
• Формат вывода: структура отчёта, ADR или анализа — чтобы результат был предсказуемым.

И да — промпт агента стоит версионировать в том же репозитории, что и код. Меняется логика — меняется промпт. Ловится баг в выводе — фиксишь промпт, как код. Никакой магии, просто конфигурация.

Где чаще всего ломается

Собрал список граблей, на которые наступал лично:

Агент циклится. Дёргает Jira, получает ответ, не понимает его, дёргает снова. Решение: лимит на число вызовов инструмента (max 3), и если лимит исчерпан — агент обязан сгенерировать ответ с пометкой «данные неполные по причинам X, Y».

Контекст переполняется. Агент собрал 15 чанков из RAG, 20 задач из Jira, 5 страниц Confluence — и суммарно это 40 тысяч токенов. LLM теряет середину контекста и выдаёт ответ только по первым и последним фрагментам. Решение: иерархическая фильтрация. Сначала агент запрашивает заголовки и даты (лёгкие данные), отбирает релевантное, и только потом дёргает полное содержание. Не «дай всё», а «дай самое важное по фильтру X».

Таймауты на инструментах. Jira API отвечает 8 секунд — агент ждёт. Confluence отвечает 15 — агент ждёт. Три запроса подряд — полминуты тишины, пользователь думает что всё зависло. Решение: стриминг промежуточных шагов. Агент пишет в интерфейс «ищу задачи в Jira…» → «анализирую ADR…» → «формирую отчёт…». Пользователь видит прогресс и не уходит.

Галлюцинации на стыке источников. Агент нашёл в Jira задачу PAY-341, в RAG — ADR-005 про платёжный шлюз, и «дорисовал» связь, которой нет. ADR-005 на самом деле про другой шлюз, но агент увидел слово «платёжный» в обоих документах и склеил. Лечение: обязательное требование в промпте — «для каждого утверждения указывай источник и проверяй, что источники относятся к одной и той же системе/компоненту».

С чего начать

Собирать воркфлоу целиком с нуля — плохая идея. Проверено. Я бы разбил на три итерации.

Итерация 1. Один MCP-сервер (Jira) + LLM без агента. Просто запрос → Jira → форматированный ответ. Цель: убедиться что MCP работает и данные приходят в читаемом виде.

Итерация 2. Добавить агента с ReAct-циклом и двумя инструментами: MCP + RAG (на проектной документации). Цель: агент сам решает, какой инструмент дёрнуть, и комбинирует данные из двух источников.

Итерация 3. Полный воркфлоу: три MCP-сервера (Jira, Confluence, БД) + RAG + агент с памятью (векторная БД для хранения промежуточных результатов). Цель: сквозной сценарий «получил задачу → собрал данные → проанализировал → выдал документ».

На каждой итерации вы отлаживаете один новый компонент, а не три одновременно. И главное — на каждой итерации у вас уже что-то работает, пусть и в урезанном виде. Это сильно спасает мотивацию, когда что-то идёт не так. А оно пойдёт не так.