Перейти к содержанию
Новое AiManual теперь в MAX Подписаться
Публикация AiManual

Как Apollo перестроил AI-ассистента на Deep Agents и LangSmith для полного цикла GTM

Apollo переписал AI-ассистента, заменив LangGraph на Deep Agents: скорость разработки выросла на 85%, а подтверждающие запросы к пользователю сократились. Шести

Коротко

Что будет в материале

  1. 01

    Почему Apollo решился на перестройку AI-ассистента

  2. 02

    От иерархии супервизора к библиотеке навыков: архитектурный сдвиг

  3. 03

    AI Watchtower: шестиуровневая система оценки качества на LangSmith

  4. 04

    Headless-агент: API, MCP-сервер и CLI для командной работы

Apollo переписал своего AI-ассистента, отказавшись от иерархии супервизора на LangGraph в пользу библиотеки навыков Deep Agents. Результат: скорость разработки выросла на 80–85%, количество подтверждающих запросов к пользователю резко сократилось, а сам ассистент вышел за пределы веб-интерфейса - теперь он работает через API, MCP-сервер и CLI. Более 40 000 команд уже используют интеграцию через MCP.

Качество работы обеспечивает шестиуровневая система AI Watchtower на базе LangSmith. Она охватывает весь цикл: от юнит-тестов отдельных навыков до анализа живых трейсов и пользовательских оценок. Это не просто мониторинг - это полноценный конвейер проверок, встроенный в CI/CD пайплайн Apollo.

В этом разборе - архитектурные решения, метрики и уроки, которые можно применить при построении AI-агентов для полного цикла GTM.

Почему Apollo решился на перестройку AI-ассистента

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

Пользователи жаловались на три проблемы. Первая - перегруженность интерфейса. Чтобы выполнить сквозной сценарий GTM, приходилось вручную переключаться между модулями: поиск лидов в одном месте, составление цепочки писем в другом, анализ ответов в третьем. Вторая - медлительность. Иерархический супервизор на каждом шаге уточнял у пользователя подтверждение: «Найти лидов по этим критериям?», «Отправить письмо этому сегменту?», «Обновить CRM?». Диалог растягивался, а ценность ассистента падала. Третья - сложность расширения. Добавление нового навыка требовало правок в логике супервизора, что замедляло релизный цикл.

Эти трения напрямую били по полному циклу GTM. Торговые представители тратили время на навигацию по интерфейсу вместо работы с клиентами. Команда Apollo зафиксировала: ассистент должен действовать, а не спрашивать разрешения на каждом шагу.

От иерархии супервизора к библиотеке навыков: архитектурный сдвиг

Решение - переход от иерархии к плоской библиотеке навыков на Deep Agents. Вместо одного супервизора, который управляет подчинёнными агентами, каждый навык стал самодостаточным модулем с чётким контрактом: входные параметры, действие, результат. Ассистент выбирает нужный навык напрямую, без промежуточного слоя согласования.

Этот сдвиг дал два немедленных эффекта. Во-первых, ускорение разработки на 80–85%. Новый навык добавляется как независимый модуль - не нужно трогать логику оркестрации. Во-вторых, радикальное снижение подтверждающих запросов. Ассистент выполняет задачу сразу, если контекст достаточен. Запрос уточнения происходит только при реальной неопределённости, а не по умолчанию.

Что такое Deep Agents и как они работают в Apollo

Deep Agents - это библиотека навыков, где каждый навык представляет собой изолированную функцию с предсказуемым поведением. Навык «Поиск лидов» получает на вход критерии и возвращает список. Навык «Отправка email» принимает шаблон и контакты, отправляет письма и возвращает статусы. Навык «Обновление CRM» синхронизирует данные после встречи.

В контексте GTM-цикла Apollo эти навыки собираются в цепочки не на уровне кода, а на уровне запроса пользователя. Пользователь говорит: «Найди лидов в SaaS-компаниях Калифорнии, отправь им персонализированное письмо и обнови CRM». Ассистент последовательно вызывает три навыка, передавая результаты между ними. Никакого ручного переключения между модулями.

LangGraph vs Deep Agents: практические выводы из кейса

Выбор между иерархией супервизора и библиотекой навыков зависит от характера задач. Опыт Apollo даёт чёткие критерии.

КритерийLangGraph (иерархия)Deep Agents (навыки)
Сложность оркестрацииВысокая - супервизор управляет маршрутизациейНизкая - навыки вызываются напрямую
Скорость добавления функцийМедленно - нужны правки супервизораБыстро - новый модуль независим
Количество подтвержденийВысокое - супервизор переспрашиваетНизкое - навык действует при достаточном контексте
Подходит дляСложных многошаговых рассуждений с неопределённостьюЧётких операционных задач с предсказуемыми шагами
ОграниченияЗадержки, хрупкость при измененияхТребует качественного тестирования каждого навыка

Apollo выбрал Deep Agents, потому что GTM-задачи операционны по природе: найти, отправить, обновить. Иерархия здесь избыточна. Но в сценариях с высокой неопределённостью - например, сложные переговоры с динамической стратегией - LangGraph сохраняет преимущество. Подробнее о построении агентов с нуля и выборе архитектуры мы разбирали в гайде по самостоятельной разработке AI-агентов.

AI Watchtower: шестиуровневая система оценки качества на LangSmith

Переход на навыки решил проблему скорости, но создал новую: как гарантировать, что каждый навык работает корректно, а их комбинации не ломаются? Apollo построил AI Watchtower - шестиуровневую систему оценки на базе LangSmith. Она охватывает весь жизненный цикл навыка: от написания кода до продакшена и обратной связи.

Как устроены уровни оценки: от юнит-тестов до пользовательских рейтингов

Уровень 1: Юнит-тесты навыков. Каждый навык проходит изолированные проверки на синтетических данных. Навык «Поиск лидов» тестируется на фиксированных наборах критериев с известным ожидаемым результатом. Навык «Отправка email» проверяет корректность шаблонов и подстановки переменных.

Уровень 2: Интеграционные тесты. Проверяются цепочки из двух-трёх навыков. Например, связка «Поиск лидов → Отправка email»: корректно ли передаются контакты между навыками, не теряются ли данные на стыках.

Уровень 3: Сквозные сценарии GTM. Полные бизнес-сценарии: от поиска лидов до обновления CRM после отправки писем. Здесь проверяется не только техническая корректность, но и бизнес-логика: правильный ли сегмент выбран, соответствует ли тон письма целевой аудитории, корректно ли обновлены поля в CRM.

Уровень 4: Трейсы реальных сессий. LangSmith записывает все вызовы навыков в продакшене. Команда анализирует трейсы на предмет аномалий: неожиданно долгие выполнения, повторные вызовы одного навыка, ошибки на стыках.

Уровень 5: Автоматическая оценка ответов. LangSmith автоматически оценивает качество ответов ассистента по заданным критериям: релевантность, полнота, отсутствие галлюцинаций. Для этого используются отдельные LLM-оценщики, которые выставляют баллы по шкале.

Уровень 6: Сбор и анализ обратной связи. Пользователи оценивают действия ассистента прямо в интерфейсе. Эти оценки агрегируются и сопоставляются с автоматическими метриками. Расхождения между пользовательской оценкой и оценкой LangSmith - сигнал к пересмотру критериев.

Интеграция LangSmith в CI/CD пайплайн Apollo

Все шесть уровней встроены в пайплайн разработки. При каждом обновлении навыка автоматически прогоняются юнит-тесты и интеграционные проверки. Если метрики падают ниже порога, деплой блокируется. Сквозные сценарии запускаются nightly. Трейсы реальных сессий мониторятся continuously с алертами на аномалии.

Пороги качества установлены жёстко: точность навыка ниже 95% на синтетических тестах - релиз запрещён. Падение пользовательской оценки ниже 4.0 из 5 в течение скользящего окна - автоматический откат последних изменений. Такой подход исключает ситуацию, когда ускорение разработки достигается ценой качества. Для более широкого контекста о корпоративной AI-архитектуре и governance с LangSmith смотрите разбор enterprise data platform нового поколения.

Headless-агент: API, MCP-сервер и CLI для командной работы

Ассистент Apollo перестал быть привязанным к веб-интерфейсу. Его навыки доступны как headless-агент через три канала: REST API, MCP-сервер и CLI. Это принципиальный сдвиг: ассистент встраивается в рабочие инструменты команды, а не требует отдельного окна.

Статистика подтверждает востребованность: более 40 000 команд уже используют интеграцию через MCP. Разработчик в IDE запрашивает данные о лидах, не покидая редактор кода. Менеджер запускает подбор лидов из терминала. Операционный директор получает отчёт в корпоративный чат.

MCP-сервер Apollo: как это работает и зачем нужно командам

MCP - Model Context Protocol - открытый протокол для взаимодействия AI-агентов с внешними инструментами. Apollo реализовал MCP-сервер, который предоставляет навыки ассистента как инструменты для любого MCP-совместимого клиента.

Сценарий: разработчик работает в VS Code с MCP-плагином. Он пишет код для интеграции и хочет проверить, какие лиды доступны для тестового окружения. Прямо в IDE он отправляет запрос к MCP-серверу Apollo: «Дай 10 лидов из SaaS с revenue > $10M». Сервер вызывает навык «Поиск лидов» и возвращает структурированный JSON. Ни одного переключения окон. Ни одного ручного экспорта из CRM.

CLI-интерфейс решает схожую задачу для сценариев автоматизации. Скрипт в CI/CD может дёрнуть навык Apollo для проверки данных перед деплоем. А API позволяет встроить ассистента в корпоративные системы: Slack-боты, дашборды, внутренние порталы. Такой подход к headless-агентам перекликается с концепцией автономных агентов в Google Antigravity 2.0, где агенты работают асинхронно без привязки к IDE.

Что дальше: автономные агенты и фоновые процессы в Apollo

Дорожная карта Apollo включает переход от реактивных агентов к проактивным. Сейчас ассистент действует по запросу пользователя. Следующий этап - автономные агенты, работающие по расписанию и в фоне.

Первый сценарий уже в разработке: ежедневный подбор лидов через Slack. Агент по расписанию сканирует базу, находит новые компании, соответствующие критериям, и отправляет подборку в канал команды. Пользователь не инициирует поиск - он получает результат к началу рабочего дня.

Второе направление - фоновые процессы без участия пользователя. Например, агент мониторит ответы на отправленные письма, классифицирует их (позитивный, негативный, автоответ) и автоматически обновляет статусы в CRM. Торговый представитель заходит в систему и видит актуальную картину, а не список задач по обновлению полей.

Эти сценарии требуют ещё более строгого контроля качества. Ошибка автономного агента, работающего без надзора, может привести к каскадным последствиям. Поэтому AI Watchtower будет расширена уровнями для мониторинга фоновых процессов: алерты на бездействие агента, проверка корректности автоматических обновлений, эскалация неоднозначных случаев человеку.

Уроки Apollo для внедрения AI-агентов в ваши GTM-процессы

Кейс Apollo даёт пять конкретных уроков для команд, которые строят AI-агентов для продаж и маркетинга.

1. Начинайте с навыков, а не с иерархии. Большинство GTM-задач операционны: найти, отправить, обновить, проверить. Плоская библиотека навыков покрывает их быстрее и надёжнее, чем многоуровневая оркестрация. Иерархия нужна, когда маршрут выполнения заранее не определён. Apollo показал: переход на навыки ускорил разработку на 80–85%.

2. Встройте оценку качества с первого дня. AI Watchtower не появилась постфактум. Шестиуровневая система росла вместе с библиотекой навыков. Минимальный стартовый набор: юнит-тесты навыков и трейсы реальных сессий. Без этого ускорение разработки обернётся падением надёжности.

3. Дайте агентам доступ через API и CLI. Ассистент, запертый в веб-интерфейсе, требует от пользователя переключения контекста. Headless-режим через API, MCP и CLI встраивает агента в существующие инструменты. 40 000 команд Apollo, использующих MCP - прямое подтверждение востребованности.

4. Планируйте автономность постепенно. Переход от реактивных агентов к проактивным требует зрелой системы мониторинга. Сначала добейтесь стабильного качества по запросу, затем добавляйте работу по расписанию, и только потом - полностью автономные фоновые процессы.

5. Измеряйте влияние на полный цикл GTM. Метрики Apollo не ограничиваются техническими: точность навыков, задержка, аптайм. Ключевой показатель - время торгового представителя, возвращённое от навигации по интерфейсу к работе с клиентами. Именно этот показатель оправдывает инвестиции в перестройку архитектуры.

Подписаться на канал