LangChain открыла исходный код Paid Media Agent: долгоживущего агента, который работает в Slack, каждую неделю сводит данные рекламных платформ с лидами и воронкой из хранилища, публикует отчёт и предлагает правки кампаний. Код доступен публично, и это редкий случай, когда можно разобрать работающую систему с реальными бюджетами, а не демо из презентации.
Принцип, на котором всё построено, укладывается в одну фразу: агент - это knowledge worker. Он получает песочницу с инструментами (pandas, DuckDB, WeasyPrint), бизнес-контекст в виде внутренней вики и набора навыков, а также правила работы. Всё, что можно посчитать точно, считает код. Модель объясняет цифры и предлагает решения.
LangChain приводит такие результаты за полгода: доля платной рекламы в маркетинговом пайплайне выросла с 0 до 20%, CPL снизился на 30% с июня по август, а ранний отчётный сценарий после доработки агента стал примерно в 40 раз дешевле и в 13 раз быстрее, 85 секунд вместо 18 минут. Ниже разбираем архитектуру, границы автономности и то, что из кейса переносится в свой проект.
Что такое Paid Media Agent от LangChain и зачем он нужен
Paid Media Agent - долгоживущий агент в Slack, который отвечает за платную рекламу как за направление целиком. У него есть расписание запусков, память между сессиями, доступ к данным и право предлагать изменения кампаний. Утверждает правки человек.
Практический смысл в том, что исчезает ручная склейка таблиц. Вместо понедельничной возни с выгрузками маркетолог получает в канале отчёт с выводами и кнопками подтверждения. Здесь видно переход от чат-ботов, которые отвечают на вопросы, к агентам, встроенным в рабочий процесс и живущим месяцами.
Ключевые возможности и рабочий цикл агента
Один цикл выглядит так:
- Агент забирает статистику из рекламных платформ: расход, показы, клики, конверсии.
- Подтягивает лиды и сделки из хранилища и связывает их с кампаниями по общим ключам. Без этого шага стоимость лида и качество трафика не посчитать.
- Считает метрики в песочнице: pandas для преобразований, DuckDB для запросов к таблицам, WeasyPrint для сборки отчёта в PDF.
- Сверяет факт с целями и порогами, прописанными в коде.
- Публикует отчёт в Slack и прикладывает предложения: где поднять бюджет, где перераспределить, какие объявления выключить.
- Ждёт подтверждения от человека и только затем отправляет изменения в платформу.
Финальная точка цикла - предложение конкретной правки, а не сам отчёт. Отчёт, после которого ничего не происходит, создаёт мало ценности. Именно поэтому в карточках есть кнопки «Одобрить» и «Отклонить».
Почему это пример агента как knowledge worker
Наёмный сотрудник приходит на работу не с пустой головой: у него есть доступы, инструкции, контекст компании и зона ответственности. Paid Media Agent устроен так же. Песочница даёт вычислительные инструменты, вики и навыки описывают, как в компании считают метрики и что считают нормой, правила задают границы действий.
Отличие от обычного LLM-ассистента в трёх вещах. Долгосрочная память: агент помнит прошлые недели и сравнивает периоды. Доступ к инструментам: он не рассуждает о данных, а работает с ними. Границы ответственности: он готовит изменения, но не применяет их без человека. Модель здесь выступает интерпретатором и автором рекомендаций, а не калькулятором.
Архитектура агента: как устроен Paid Media Agent внутри
Поведение системы определяют четыре решения: расчёты и жёсткие правила живут в коде, у каждой метрики есть единственный источник истины, инструменты подгружаются по требованию, изоляция субагентов проектируется заранее.
Разделение ответственности: код vs модель
Расчёт CPL, ROI, доли платного канала и сравнение с лимитами бюджета выполняет код. Модель получает готовые числа и занимается интерпретацией: что могло сдвинуть показатель, какая гипотеза правдоподобнее, какую правку стоит предложить.
Пример: CPL кампании вышел за порог. Порог проверяет код и фиксирует факт превышения. Модель объясняет возможные причины (смена ставки, выгорание объявления, сдвиг в качестве лидов) и формулирует рекомендацию. Арифметика, на которой легко ошибиться, вообще не попадает в зону ответственности LLM.
Побочный эффект приятный: логику видно, её можно покрыть тестами, а ошибка в цифрах становится технической проблемой с конкретным адресом в коде.
Источник истины для каждой метрики
У каждой метрики один источник. Лиды и сделки приходят из CRM, показы, клики и расход - из рекламной платформы. Вариант «возьмём среднее из двух выгрузок» не рассматривается: если показатель попал в отчёт, у него есть владелец и конкретное место в хранилище.
Это снимает классическую боль, когда два отчёта показывают разные цифры по одной кампании. Аудит тоже упрощается: разошлась цифра, идём в единственный источник, а не сверяем три таблицы между собой.
Динамическая загрузка инструментов и изоляция субагентов
Агент не тащит в контекст все инструменты сразу. Он ищет подходящий и подгружает его под задачу. Контекст остаётся коротким, ответ приходит быстрее, а стоимость прогона падает.
Описывать десятки интеграций вручную не обязательно: MCP превращает инструменты в единый интерфейс, который агент подключает по мере необходимости.
Изоляция субагентов решается на этапе проектирования. Субагент по креативам не видит финансовые данные, субагент по бюджетам не читает тексты объявлений. Чем меньше лишнего в контексте, тем ниже шанс, что модель свяжет несвязуемое и выдаст вывод, который никто не проверял.
Безопасность и контроль: как агент вносит изменения в кампании
У автономности есть чёткая граница: агент готовит изменение, применяет его человек.
Approval-карточки в Slack: как это работает
Карточка описывает суть правки: какая кампания, что меняется, на сколько, какой эффект ожидается. Рядом две кнопки, «Одобрить» и «Отклонить». При нажатии система проверяет user ID и права сотрудника. Прав нет - действие блокируется, даже если карточка видна всему каналу. После одобрения агент отправляет изменение через API платформы.
Проверка по user ID отвечает на вопрос «кто именно нажал кнопку». Анонимного доступа к бюджетам не остаётся.
Проверка на стороне платформы
Отправить запрос не значит применить изменение. Агент перечитывает данные с платформы и сверяет результат с ожидаемым. Не сошлось - уведомление в Slack. Так ловятся ошибки API, отклонённые ставки, ограничения аккаунта и другие сбои, о которых сам код запроса ничего не сообщает.
Схема «человек в цикле» плюс проверка результата убирает главный страх при работе с автономными агентами: что бот ночью сольёт бюджет.
Результаты и метрики: что дал агент за 6 месяцев
LangChain делится цифрами по своему маркетингу. Они описывают конкретный контекст, поэтому переносить их на любой проект напрямую не стоит.
Как доработка агента ускорила отчёты
Ранний отчётный сценарий занимал 18 минут. После переработки - 85 секунд, то есть в 13 раз быстрее и примерно в 40 раз дешевле по стоимости прогона. Ускорение дали три вещи: вычисления ушли в код, инструменты подгружаются адресно, субагенты получили узкие роли. Стоимость прогона падает ровно там, где в контекст перестаёт лететь всё подряд.
Качество длинных отчётов стоит измерять отдельно от скорости: кейс Similarweb показывает, как оценка отчётов агента через LLM-as-judge и проверку фактической опоры ловит проблемы, которые не видны в метриках latency и cost.
Влияние на бизнес-показатели
За шесть месяцев доля платной рекламы в маркетинговом пайплайне выросла с 0 до 20%, а CPL снизился на 30% с июня по август. Логика «больше платного трафика - дороже лид» здесь не сработала: скорость реакции на данные и точность правок компенсировали рост объёма. Все цифры приведены по данным LangChain и независимо не проверялись.
Как повторить подход: практические шаги для своего проекта
Порядок работ, который снижает риск утонуть:
- Определите источник истины для каждой метрики. Одна метрика, один источник, один владелец.
- Вынесите вычисления и жёсткие правила в код. Модели оставьте интерпретацию и формулировки.
- Соберите динамическую загрузку инструментов вместо загрузки всего стека сразу.
- Спроектируйте изоляцию субагентов: каждый видит только свои данные.
- Сделайте approval-воркфлоу с проверкой прав по user ID, если агент меняет что-то во внешних системах.
- Настройте мониторинг и логирование: видно, что агент прочитал, что посчитал, что предложил.
С чего начать: минимальный жизнеспособный агент
Первый шаг без больших затрат: агент собирает данные из одного источника, считает пару метрик, формирует простой отчёт и публикует его в Slack. Права менять кампании у него нет, поэтому approval-карточки не нужны. Такой MVP проверяет главное: попадают ли данные в нужные сроки и есть ли у отчёта читатели. Как собрать агента с нуля, с кодом на Python и разбором оркестрации, памяти и обработки ошибок, подробно разобрано в материале про архитектуру самописного AI-агента.
Инструменты и технологии
Из кейса напрямую переносятся pandas для обработки данных, DuckDB для аналитических запросов к таблицам, WeasyPrint для PDF-отчётов, Slack API для интерфейса и LangChain для оркестрации. Стек не догма: заменить DuckDB на другой аналитический движок или WeasyPrint на HTML-отчёт в канале можно без пересборки логики. Важна не конкретная библиотека, а разделение ролей: инструмент делает точную работу, модель объясняет результат.
Ограничения и подводные камни
Технические и организационные вызовы
Для запуска нужны доступы к API рекламных платформ, к хранилищу с лидами, права в Slack и инженеры, которые одновременно понимают аналитику и умеют работать с LLM-агентами. Организационно главное - заранее решить, кто одобряет изменения и что делать, если карточка висит сутки. Без ответственного за подтверждения агент превращается в генератор отчётов.
История про агента, который провалил боевые задачи, но закрыл более половины исследовательских запросов аналитиков, хорошо показывает: технический успех и принятие в компании - разные вещи. Инструмент может работать, а команда им не пользоваться.
Когда агент может не подойти
Малый объём данных обнуляет пользу: при десятках лидов в месяц таблицы вручную сводятся быстрее, чем настраивается агент. Простые процессы без сложной экономики закрываются скриптом или готовым SaaS-решением для отчётности. Нехватка людей на поддержку - тоже стоп-сигнал: агент требует внимания после запуска, а не только на старте.
Если нужен ассистент с собственной инфраструктурой и ручной настройкой, посмотрите на Agenta как открытую альтернативу с self-hosted моделями: иногда разумнее взять готовую обвязку, чем писать оркестрацию с нуля.
Связь с другими кейсами и трендами
Сравнение архитектурных подходов
LangChain собрала одного агента с инструментами. Fyxer пошёл другим путём и разбил обработку почты на 30-50 узкоспециализированных микромоделей: классификатор решает, нужен ли ответ, отдельная система памяти и поиска выбирает важные детали, текст генерируют модели OpenAI. Компания накопила более 500 тысяч часов задокументированных рабочих процессов, обучалась через supervised fine-tuning и LoRA, а правки пользователей превращала в обучающую выборку через DPO. Итог: регулярная годовая выручка выросла с 1 до 32 миллионов долларов за 2025 год, удержание после 90 дней превышает 90%, а 53% писем пользователи отправляют без правок.
Perplexity поставила на локальность: 14 сентября 2026 года её агент Portable Computer стал доступен в приложении для Windows на ПК с видеокартами NVIDIA GeForce RTX и RTX PRO с 24 ГБ памяти и выше. Оркестратор, планировщик, маршрутизатор инструментов и поисковый индекс работают на устройстве, используются модели Qwen 3.8 27B или PPLX 27B, а коннекторы соединяют агента с Outlook, OneDrive, Word, Google Drive, Gmail, Slack и GitHub. Доступ открыт подписчикам Pro и Max.
Три подхода решают разные задачи. Монолитный агент с инструментами проще собрать и легче объяснить команде, но качество сильно зависит от дисциплины контекста. Ансамбль микромоделей точнее на узком домене, зато требует огромного датасета и серьёзной инфраструктуры обучения. Локальный агент даёт приватность и независимость от облака, но упирается в 24 ГБ видеопамяти и возможности локальной модели.
Что это значит для будущего AI-агентов
Общий вектор виден: агенты становятся долгоживущими, специализированными и встроенными в рабочие инструменты вроде Slack. Успех определяет не выбор модели, а дисциплина вокруг неё: где источник истины, что считает код, что видит человек в цикле. Начинать стоит с точных вычислений и одного понятного сценария, а модель подключать там, где нужна интерпретация и текст.