Каждая команда данных знакома с этой ситуацией: менеджеры по продукту ждут ответов, аналитики завалены работой, а самостоятельные BI-дашборды решают проблему лишь частично. GitHub только что опубликовал детальный разбор того, как они решили эту проблему внутри компании — и описанные ими паттерны неожиданно актуальны для всех, кто строит команды AI-агентов на собственной инфраструктуре.
19 июня 2026 года инженеры GitHub Маттео Вазирани и Синтия Джозеф опубликовали текст «Как мы создали внутреннего агента аналитики данных». В посте рассматривается архитектура Qubot — агента на базе Copilot, позволяющего любому сотруднику GitHub задавать вопросы к хранилищу данных компании на простом языке и получать ответы за считанные секунды. Это не дашборд и не инструмент отчётности — это агент, созданный специально для разведывательных вопросов вроде «У какой когорты пользователей самый высокий показатель удержания для этой функции?» или «Какой продукт больше всего повлиял на изменение этой метрики на прошлой неделе?».
Пост стоит прочитать целиком, но наше внимание привлек не только сам продукт. А архитектурное мышление за ним — и то, насколько оно перекликается с вызовами, которые стоят перед командами при развёртывании AI-агентов в продакшне, особенно в автономных, многоагентных конфигурациях.
Трёхуровневая архитектура
Дизайн Qubot чётко делится на три компонента: слой пользовательского интерфейса, слой контекста и слой движка запросов. Это разделение — не просто аккуратная инженерия, а урок того, как сделать AI-агентов действительно надёжными.
Слой интерфейса охватывает Slack, VS Code и CLI Copilot. Slack — основная точка входа: пользователь задаёт вопрос в специальном канале, экземпляр Qubot создаётся как облачный агент Copilot, и ответ приходит прямо в Slack. Пользователь может уточнять в той же цепочке сообщений, а каждый результат также сохраняется как markdown-отчёт в пул-реквесте для дальнейшего использования. Этот дизайнерский выбор — сделать результаты одновременно диалоговыми и персистентными — паттерн, который стоит перенять.
Слой движка запросов подключается к двум системам: Kusto для быстрых разведывательных запросов к свежим данным событий и Trino для сложных соединений и глубокого исторического анализа. Важно, что пользователям не нужно знать, какой движок использовать. Qubot по умолчанию обращается к Kusto и автоматически переключается на Trino, когда вопрос этого требует. GitHub создал кастомный Trino MCP-сервер и развёрнул локальную версию Fabric RTI MCP Server для Kusto. Абстракция скрывает сложность инфраструктуры от задающего вопрос человека — именно так и должны работать агенты.
Но самая поучительная часть — это средний слой.
Федеративный контекст: настоящее новаторство
Хранилище данных GitHub следует стандартной архитектуре медальона — бронза (сырые события), серебро (приведённые в соответствие факты и измерения) и золото (курируемые бизнес-наборы данных). Слой контекста Qubot отражает эту структуру с федеративным вкладом знаний:
- Для данных бронзового уровня продуктовые команды вносят контекст телеметрии — информацию о схеме и метаданные.
- Для данных серебряного уровня команда данных и аналитики ведут примеры запросов, рекомендации по использованию и обязательные фильтры.
- Для данных золотого уровня команды, владеющие наборами данных, вносят бизнес-правила и определения метрик.
Это федеративный контекст, сделанный правильно. Вместо одной центральной команды, пытающейся задокументировать всё (заведомо проигрышная стратегия в масштабе), знания остаются там, где они производятся. Затем контекстный агент поглощает, организует и нормализует вклады в структурированный формат, который Qubot может использовать во время выполнения через GitHub MCP Server. Команды вносят вклад через стандартизированный шаблон или ссылаются на репозиторий с соответствующим контекстом. Поскольку GitHub в основном использует markdown для документации, нет никакой «налоговой нагрузки» на интеграцию — не нужно жонглировать множеством инструментов.
Урок для команд, создающих AI-агентов: архитектура контекста важнее выбора модели. Самая умная LLM в мире выдаст мусор, если работает с пустым или плохо структурированным слоем знаний. Федеративная модель GitHub, где доменные эксперты вносят структурированные знания, загружаемые во время выполнения, — паттерн, который может воспроизвести любая команда.
Оценка перед развёртыванием
Другая выдающаяся деталь — фреймворк оценки GitHub. Каждое изменение слоя контекста или конфигурации агента тестируется перед публикацией. Когда кто-то обогащает контекст новыми знаниями через пул-реквест, офлайн-фреймворк оценки измеряет точность, задержку и регрессии.
Бенчмаркинговая система состоит из трёх компонентов:
- Тестовые случаи: курируемый набор данных с промптами, для которых известны правильные ответы, эталонный SQL и метаданные, такие как домен и сложность.
- Автоматизированная оркестрация запусков: скрипт, который запускает каждый тестовый случай как задачу агента с помощью GitHub CLI (
gh agent-task create), выполняет несколько параллельных испытаний, опрашивает статус выполнения и сохраняет детальные результаты в формате JSON. - Агрегация статистики: скрипт отчётности, вычисляющий метрики для каждого тестового случая — процент выполнения, точность и продолжительность (среднее, минимальное, максимальное).
Сквозной поток прост: определить тестовые случаи → запустить Qubot N раз для каждого случая → собрать результаты → агрегировать статистику → сравнить конфигурации.
Это тот уровень строгости, которого избегает большинство развёртываний AI-агентов. Команды публикуют агентов, скрестив пальцы, и надеются, что пользователи не заметят падения точности после обновления контекста. Подход GitHub, где каждое изменение контекста рассматривается как изменение кода, которое нужно провести через тесты, — правильная ментальная модель. А тот факт, что они запускают несколько испытаний для каждого тестового случая, признаёт важную особенность поведения LLM: стохастичность реальна, а оценка по одному запуску лжёт.
Что это значит для команд с автономным ИИ
GitHub — большая компания с выделенными инженерами платформы данных. Но описанные ими паттерны не привязаны к их масштабу. Вот что можно перенять:
Многоуровневый контекст лучше монолитных промптов. Запускаете ли вы агента аналитики данных или многоагентную AI-команду, структурированный контекст, загружаемый во время выполнения, а не впихиваемый в системный промпт, даёт более надёжные результаты. Разделение метаданных, рекомендаций по использованию и бизнес-правил на отдельные, удобоподдерживаемые слои — задача, посильная для любой команды, даже с небольшой базой знаний.
Федеративный вклад масштабируется; централизованная документация — нет. Если вашим AI-агентам нужно знать о пяти разных предметных областях, пусть эксперты этих областей вносят структурированные знания, а не рассчитывайте на одного человека, который всё задокументирует. Стандартизированные шаблоны и агенты-поглотители снижают барьер.
MCP — стандартный паттерн интеграции. Весь слой движка запросов GitHub работает через MCP-серверы — кастомный для Trino и развёрнутый экземпляр для Kusto. Протокол MCP становится стандартом для подключения агентов к внешним инструментам и источникам данных. Команды, строящие автономные агентные архитектуры, должны проектировать их с учётом этого.
Оценка не опциональна. Если вы запускаете агентов, чьим результатам люди доверяют, вам нужен фреймворк тестирования. Он не обязан быть таким сложным, как у GitHub, но базовый цикл — курируемые тестовые случаи, автоматизированные запуски, агрегированные метрики — достижим для любой команды.
Эти паттерны — федеративные слои знаний, интеграция инструментов через MCP, многоагентные системы с персистентной памятью — лежат в основе того, как построен OfficeForge. Пять AI-сотрудников (исследователь, программист, копирайтер, секретарь, дизайнер), работающих на вашем собственном VPS, каждый со структурированными навыками и доступом к внешним инструментам через MCP. Та строгость оценки, которую описывает GitHub? Агенты OfficeForge поддерживают общую граф знаний, чтобы не исследовать одни и те же факты повторно — контекст накапливается, а не сбрасывается.
Купить — 15 400 ₽Более широкая картина
Qubot был широко принят внутри GitHub, сотни пользователей запускают тысячи запросов. Количество вопросов, адресованных в Slack-каналы команд данных и аналитики, резко сократилось — не потому что люди перестали быть любопытными, а потому что теперь они могут исследовать данные самостоятельно.
Это то обещание, которое «самостоятельная аналитика» давала десятилетиями, но так и не выполнило. Что изменилось — это не только то, что LLM могут генерировать SQL. Полный стек — интерфейс, управление контекстом, маршрутизация запросов, оценка — достаточно созрел, чтобы сделать выводы надёжными в масштабе.
Для команд, оценивающих, как развернуть AI-агентов в своих организациях — будь то для аналитики данных, производства контента, генерации кода или исследований, — пост GitHub — это мастер-класс по правильной архитектуре. Модель важна, но слой контекста, интеграция инструментов и цикл оценки — вот что отличает демо от продакшн-системы.
Инструменты для самостоятельной сборки такого решения доступны как никогда. Используете ли вы автономную AI-команду OfficeForge или собираете свой стек, принципы одни и те же: структурированный контекст, чистая интеграция инструментов, персистентная память и строгое тестирование. GitHub просто показал свои черновики — и их стоит изучить.
---
*Источник: How we built an internal data analytics agent — The GitHub Blog, Маттео Вазирани и Синтия Джозеф, 19 июня 2026 г.*
FAQ
Что такое Qubot?
Qubot — это внутренний аналитический агент GitHub на базе Copilot, который позволяет любому сотруднику задавать вопросы к хранилищу данных компании на простом языке и получать ответы за считанные секунды — без необходимости знать SQL.
Как устроен слой контекста Qubot?
Знания вносятся разными командами по федеративной модели: продуктовые команды добавляют метаданные телеметрии, команда данных — примеры запросов и рекомендации по использованию, а владельцы наборов данных — бизнес-правила. Контекстный агент всё это поглощает и нормализует в структурированный формат.
Какие движки запросов использует Qubot?
Qubot подключается как к Kusto (для быстрых разведывательных запросов к свежим данным событий), так и к Trino (для сложных соединений и исторического анализа). По умолчанию он использует Kusto и автоматически переключается на Trino, когда вопрос этого требует.
Как GitHub оценивает точность Qubot?
Каждое изменение слоя контекста или конфигурации агента проходит через фреймворк оценки с курируемыми тестовыми случаями, автоматизированной оркестрацией, запускающей несколько параллельных испытаний для каждого случая, и агрегацией статистики, измеряющей скорость выполнения, точность и задержку.
Почему это важно для небольших команд?
Архитектурные паттерны, использованные GitHub, — федеративный контекст, интеграция инструментов на базе MCP, многоуровневая курация данных и автоматизированная оценка — напрямую применимы к автономным конфигурациям ИИ, где команды создают многоагентные системы на собственной инфраструктуре.