Not all AI agents are created equal

Не все ИИ-агенты одинаковы

Фреймворк для категоризации и приоритизации ваших инициатив по агентам

👋 Привет, я Lenny. Каждую неделю я отвечаю на вопросы читателей о создании продукта, росте и ускорении карьеры. Подробнее: Lenny’s Podcast | Lennybot | How I AI | Мои любимые курсы по AI/PM, курс по публичным выступлениям и copilot для подготовки к интервью

P.S. Получите полный бесплатный год Lovable, Manus, Replit, Gamma, n8n, Canva, ElevenLabs, Amp, Factory, Devin, Bolt, Wispr Flow, Linear, PostHog, Framer, Railway, Granola, Warp, Perplexity, Magic Patterns, Mobbin, ChatPRD и Stripe Atlas, став подписчиком Insider. Да, это всерьёз.

Агенты сейчас на пике популярности. Чуть ли не каждый день кто-то запускает нового агента или новый инструмент для управления ими. Готов поспорить, что прямо сейчас у вашей команды в бэклоге лежит с полдюжины идей агентов. Всё это не значит, что вам действительно нужно строить агента уже сегодня. Но это значит, что вам нужно понимать, как агенты вписываются в вашу более широкую стратегию и какие инвестиции в них уместны.

Hamza Farooq и Jaya Rajwani ведут два из самых высоко оценённых и уважаемых курсов по созданию ИИ-агентов (Agent Engineering Bootcamp и Agentic AI for PMs) и потратили более 50 часов на подготовку этого руководства. К моменту, когда вы дочитаете этот пост, вы поймёте три типа агентов, как решать, какие инициативы приоритизировать, и как избежать типичных ошибок — с конкретными рекомендуемыми инструментами и платформами и множеством реальных примеров.

Давайте приступим.

За последний год мы вели один и тот же разговор как минимум 30 раз. Лидер в области ИИ открывает свою дорожную карту — обычно 5–10 инициатив с «агентами» — и говорит: «Помогите нам понять, что строить первым».

Список обычно включает PM-ассистента, RAG-копайлота, систему поддержки клиентов, агента для код-ревью и голосового шопинг-ассистента

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

Именно здесь большинство команд застревает. Проблема не в том, что им не хватает идей; проблема в том, что они пытаются приоритизировать принципиально разные виды систем так, будто это одно и то же. Обычный подход — взяться за привычные инструменты планирования. Команды открывают матрицу «影响 против усилий» и пытаются сравнить идеи бок о бок.

Но с ИИ-агентами это быстро разваливается. Один «агент» может строиться шесть недель. Другой — шесть месяцев. Одного может собрать продакт-менеджер с помощью n8n. Другому нужна выделенная команда ML-инженеров. Один стоит $500 в месяц в эксплуатации. Другой может генерировать шестизначный годовой счёт за LLM.

Ассистент поддержки клиентов и голосовой шопинг-агент могут оба называться агентами, но они требуют разных архитектур, разных команд, разной инфраструктуры и разных сроков. Пока вы не признаете эти различия, любая попытка сравнить «усилия» или «влияние» по сути является гаданием.

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

Недостающий шаг — это иерархия

Прежде чем решать, какого агента строить первым, нужно ответить на более базовый вопрос: Какой тип агента на самом деле предлагает каждая идея?

Это определит почти всё, что важно для планирования:

Насколько сложно будет его построитьКакие навыки и инфраструктура требуютсяСколько времени это, вероятно, займётНасколько дорогим будет его обслуживаниеКак следует измерять успех

Иными словами, категоризация — это не просто техническое упражнение. Это фундамент для разумной приоритизации.

Этот пост даёт вам фреймворк для принятия решений, который вы можете начать использовать уже сегодня с вашей текущей дорожной картой.

Мы разработали этот фреймворк на основе паттернов, которые наблюдали, помогая организациям превращать идеи агентов в реальные production-системы. Работая с корпоративными командами компаний из Fortune 500, таких как Jack in the Box, Tripadvisor и The Home Depot, мы обнаружили, что группировка идей по их базовой архитектуре раскрывает приоритизацию и значительно ускоряет процесс разработки и запуска. Эти различия также отражают то, как более широкая индустрия начинает классифицировать ИИ-агентов — от автоматизированных workflow к системам рассуждения и мультиагентным сетям (как, например, статья Levels of Autonomy for AI Agents и Types of AI agents от IBM). Это также основы того, как на самом деле устроены такие невероятно популярные инструменты, как OpenClaw и Claude Code.

Если вы смотрите на бэклог идей агентов, пытаясь понять, что строить первым, вот что у вас будет к концу этого поста:

5-минутный процесс триажа для отнесения каждой идеи агента к одному из трёх архитектурных типовРуководство по выбору правильного инструмента/платформы для вашего проекта (то есть когда использовать n8n, а когда LangGraph или ADK)Метрики успеха и фреймворки ROI, адаптированные под каждый архитектурный типПредупреждающие сигналы того, что вы выбрали неверный путь (и как это исправить)

Вы сможете взглянуть на свой бэклог и понять, какие идеи можно выпустить за шесть недель ради быстрого ROI, какие требуют трёх месяцев, но обеспечат значительный рост выручки, а какие — это полугодовая ставка, которая имеет смысл только при правильном ресурсном обеспечении и выстраивании ожиданий.

И всё это — начав с признания того, что «агент» — это зонтичный термин для очень разных видов систем.

Три категории агентов

Каждая идея «агента» попадает в одну из трёх архитектурных категорий.

Категория 1: Детерминированная автоматизацияВы определяете весь поток. ИИ обрабатывает содержимое на конкретных шагах. Например: workflow в n8n или Zapier с LLM-узлами. Именно сюда относится большинство возможностей для агентов и именно отсюда следует начинать большинству команд. Эти проекты быстрее всего запускаются и быстро дают измеримый ROI.

Категория 2: Агенты рассуждения и действияИИ решает, что делать дальше, используя доступные инструменты. Например: Cursor, Lovable или агенты, построенные на LangGraph, CrewAI, Google ADK и т. д. Эти инициативы обычно идут после Категории 1, когда более ценные задачи требуют гибкости и динамического принятия решений, с которыми одни лишь workflow не справляются.

Категория 3: Мультиагентные сетиНесколько специализированных агентов координируются друг с другом. Например: корпоративные системы, построенные на ADK или AutoGen. Эти проекты обычно оставляют на более поздние стадии, когда несколько команд должны координироваться между доменами, и они почти никогда не должны быть отправной точкой в дорожной карте.

Несколько примеров «агентов», относящихся к каждой категории, чтобы помочь вам понять различия:

Организации часто пытаются решать задачи Категории 1 с помощью фреймворков Категории 2 — переусложняя решения и добавляя ненужную сложность и затраты. Реже, но с худшими последствиями, они пытаются решать задачи Категории 2 инструментами Категории 1, и это ломается в production, потому что инструмент недостаточно надёжен.

Давайте подробнее разберём каждую категорию, начав с «рабочей лошадки» — Категории 1.

Категория 1: Детерминированная автоматизация

Что это такое

Это workflow, где вы определяете каждый шаг, каждое ответвление, каждую точку принятия решения. LLM занимается пониманием и генерацией естественного языка на конкретных узлах, но потоком управляете вы. Думайте о них как об умных блок-схемах, где путь проектируете вы, а содержимое обрабатывает ИИ.

Чаще всего используемые инструменты для детерминированной автоматизации — это n8n, Zapier, Make.com, OpenAI AgentKit, Lindy и Gumloop. Эти инструменты построены вокруг явных триггеров и заранее заданной логики ветвления. Вы определяете workflow, а LLM используются лишь для классификации, извлечения или составления черновиков в этих границах.

Как приоритизировать продукты Категории 1

Если в вашем бэклоге смесь идей агентов, проекты Категории 1 почти всегда — самое разумное место для старта. Эти инициативы, как правило, проще всего планировать и наименее рискованны в исполнении.

Они лучше всего подходят для ситуаций, где процесс уже чётко определён, а цель — автоматизировать повторяющуюся, объёмную работу. Если вам нужен быстрый, измеримый ROI, у вас ограниченные ресурсы AI-инженерии или вы под давлением выдать результаты за недели, а не за месяцы, проекты Категории 1 почти всегда — правильная отправная точка.

Большинство инициатив в этой категории имеют схожий профиль по ряду критериев:

Именно это сочетание быстрых сроков, скромных ресурсов и понятного влияния на бизнес делает инициативы Категории 1 такими мощными ранними победами. Они создают ценность в ближайшей перспективе, одновременно укрепляя уверенность организации для более продвинутых начинаний в будущем.

Какие типы продуктов попадают в эту категорию

Если вы можете отобразить весь процесс в виде блок-схемы с чёткими точками принятия решений, продукт относится к Категории 1. Вот ещё несколько черт продукта Категории 1:

Пути выполнения конечны и предсказуемы (менее 15–20 ответвлений)Выполнение задачи должно происходить за секунды или минутыЦенность — в автоматизации известного процесса, а не в поиске новых подходов

По нашему опыту работы с клиентами, это покрывает 60–70% возможностей для агентов. Возвращаясь к типичному списку возможностей, упомянутому выше, вот отличный пример продукта Категории 1: «Нам нужен ИИ-агент, который будет обрабатывать входящие письма клиентов, читать их, понимать, о чём спрашивают, доставать релевантную информацию из нашей документации, составлять ответы и направлять их нашей команде на согласование».

На первый взгляд кажется, что для этого нужно сложное рассуждение. Но когда вы расписываете, что на самом деле должно происходить, это оказывается на удивление детерминированным:

Каждый шаг предсказуем. «Интеллект» — в понимании письма и генерации хорошего ответа, а не в определении того, что делать дальше. Это Категория 1.

Существует масса отличных примеров автоматизирующих агентов; вот один, построенный мной.

Я люблю Airbnb, но терпеть не могу тратить долгие часы на поиск лучших вариантов, поэтому я построил агента, который принимает мой точный запрос — например, «Современная квартира в Париже рядом с вокзалами с 20 по 26 марта. Отлично подходит для пары» (им воспользовались более 10 000 пользователей) — и выполняет поиск. Вот как вы можете построить такого же сами.

Другие примеры «агентов» Категории 1:

агент для планирования путешествийголосовой агент-компаньон для чтения книгагент автоматизации контента (YouTube → LinkedIn)база знаний вашей организации с поиском по интернету (клон Perplexity)агент, который генерирует глубоко проработанные блоги по заданной темемаксимально персонализированное приложение-счётчик калорий, которое позволяет загружать фото ваших блюд для отслеживания дневного потребления калорий и рекомендует лучшие варианты питания и упражнения

Как оценивать продукты Категории 1

Приведённые ниже метрики призваны ответить на простой вопрос: автоматизировал ли этот агент нужный процесс, или эту идею стоит пересмотреть либо переопределить её рамки?

Детерминированного агента, построенного для процесса автоматизации писем, можно оценивать так:

Workflow completion rate: % выполнений, завершающихся успешноAutomation rate: % запросов, обработанных без вмешательства человекаТочность: корректность классификации намерения, извлечения данных и решений по маршрутизацииLatency: время от триггера до итогового результата (P50/P95, если релевантно)Стоимость на workflow: суммарная стоимость LLM и API на один завершённый прогонError rate: % прогонов, завершившихся сбоем из-за ошибок инструмента, интеграции или системыHuman review rate: % прогонов, требующих ручного согласования или вмешательства

Вот метрики workflow completion rate из реального примера продукта Категории 1 — агента поддержки по email, построенного SaaS-компанией, с которой мы работали:

Неделя 1: 52% completion rate (обнаружено много пограничных случаев)Неделя 4: 78% completion rate (доработана логика классификации)Неделя 8: 87% completion rate (стабильно, готово к production)Результат: 3000 писем поддержки/месяц автоматизировано, 2,5 FTE-часа/день высвобождено, $18K/месяц экономии

Когда эти метрики стабилизируются, а стоимость идёт вниз, workflow делает то, что должен. Если completion остаётся низким или ручное вмешательство держится высоким, проблема может быть недостаточно детерминированной для этой категории.

Как понять, что вы переросли Категорию 1

Вы поймёте, что нужна другая архитектура, когда:

В вашей блок-схеме 30+ узлов, и вы добавляете новые ответвления каждую неделюКлиенты формулируют вещи так, что вы не можете это предугадать, а отобразить все вариации невозможноАгенту нужно решать, какой API или источник знаний использовать в зависимости от контекста, а не следовать заранее заданному путиРазбор неоднозначных запросов требует исследования и адаптации, а не предопределённой декомпозицииСамые ценные возможности больше нельзя выразить в виде предсказуемых workflowБольшинство процессов с быстрой отдачей уже автоматизированы

Если несколько из этих сигналов присутствуют одновременно, задача больше не подходит для детерминированного workflow, и вам стоит рассмотреть Категорию 2.

Категория 2: Агенты рассуждения и действия (ReAct)

Что это такое

Вместо определения потока вы определяете доступные инструменты, а LLM автономно решает, что делать дальше. Агент работает в цикле: наблюдай → рассуждай → действуй → наблюдай результат → повторяй.

Ключевая характеристика: вы контролируете инструменты; LLM контролирует рассуждение.

Чаще всего используемые инструменты для построения ReAct-агентов включают LangGraph, CrewAI, AutoGen и другие библиотеки оркестрации агентов, которые поддерживают использование инструментов, память и динамическое планирование.

Как приоритизировать продукты Категории 2

Категория 2 — для ситуаций, где запросы пользователей неоднозначны, workflow нельзя отобразить заранее, а реальная ценность исходит из гибкого, контекстного принятия решений. Если вам нужны агенты, способные рассуждать с использованием нескольких инструментов, вести диалоговые взаимодействия или динамически адаптироваться к новым входным данным, это продукт Категории 2.

Продукты Категории 2 сложнее планировать и несут более высокий риск исполнения, чем Категория 1. Большинство инициатив в этой категории имеют схожий профиль:

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

Какие типы продуктов попадают в эту категорию

Продукт относится к Категории 2, если один и тот же запрос пользователя может каждый раз запускать разные последовательности действий. Это означает, что путь определяете не вы, а LLM. В этом ключевое отличие от Категории 1. Вот ещё несколько черт продукта Категории 2:

Одна и та же высокоуровневая задача требует разных последовательностей действий в зависимости от входных данныхУ вас 5–15+ различных возможностей, и нужная зависит от контекстаНамерение пользователя неоднозначно и требует уточнения через взаимодействиеНесколько модальностей ввода (голос, изображение, текст) нужно понимать контекстноРазбиение сложных запросов на подзадачи — часть ценности

В нашей работе с клиентами это правильный выбор для 25–30% возможностей для агентов. В качестве примера такого типа продукта давайте вернёмся к возможности голосового шопинг-ассистента из начала этого поста.

Клиенты должны иметь возможность искать товары голосом, загружать изображения, чтобы найти похожие позиции, проверять статус заказа, обновлять предпочтения и инициировать возвраты — всё это через разговор.

На первый взгляд это звучит как Категория 1. Просто распиши намерения и маршрутизируй соответственно, верно? Но на практике реальные разговоры не следуют фиксированным путям. Чтобы понять почему, давайте пройдёмся по одному взаимодействию.

Клиент загружает фото обуви и говорит:«Они слишком малы. Мне нужен размер побольше, и я хочу, чтобы их доставили к четвергу».

Вот что происходит «под капотом»:

Наблюдай. Агент получает смешанный ввод: изображение + голосовой запрос.Рассуждай. Он определяет:Сначала идентифицировать товар на изображенииЗатем найти доступные варианты размеровЗатем проверить даты доставкиНаконец, подтвердить заказ с пользователемДействуй. Агент динамически выбирает инструменты:visual_search() → идентифицировать товарcheck_inventory() → найти наличие размера побольшеget_delivery_options() → проверить доставку к четвергуplace_order() → после подтвержденияНаблюдай результат → рассуждай снова. Каждый ответ инструмента обновляет состояние агента и влияет на следующий шаг.

Эту последовательность невозможно задать заранее.

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

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

Другие примеры «агентов» Категории 2:

диалоговый агент поддержки клиентовкод-ассистент, который изменяет репозитории, например Claude Codeумный персональный шопинг-ассистентагент устранения IT-неполадокsales-копайлот, который исследует аккаунты и составляет черновики аутричамультимодальный ассистент, сочетающий голос, изображение и текст

Как оценивать продукты Категории 2

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

Эти метрики отвечают на вопрос: было ли динамическое рассуждение необходимым, или задачу следует упростить до более низкой категории?

Task completion rate: % сессий, где пользователи достигают намеченной целиТочность рассуждения: корректность декомпозиции задачи, выбора инструментов и порядка решенийДлина разговора: среднее число реплик до разрешенияМультимодальная точность: корректность интерпретации изображения, голоса или структурированного ввода (если применимо)Эффективность вызовов инструментов: среднее число вызовов инструментов на одну успешную сессиюLatency: время на одну реплику и длительность сессии от начала до концаСтоимость на сессию: суммарная стоимость LLM и API на одно завершённое взаимодействиеУдовлетворённость пользователя: CSAT после взаимодействия или эквивалентный сигналВлияние на бизнес: прирост конверсии, удержания или успешности задач относительно базового уровня

Вот некоторые метрики из реального примера — голосового + графического шопинг-ассистента для ритейлера товаров для дома, которого мы построили:

Месяц 1: 71% выполнения задач, более длинные разговоры, более высокое использование инструментов, $0,12 стоимость на сессиюМесяц 4: 86% выполнения задач, более короткие разговоры, меньше вызовов инструментов, $0,08 стоимость на сессию

Результат: точность идентификации изображений выросла с 76% до 91%, прирост конверсии увеличился с +8% до +22%, а CSAT поднялся с 4,0 до 4,5.

Когда выполнение задач улучшается, а длина разговора, использование инструментов и стоимость на сессию снижаются, цикл рассуждения агента добавляет ценность. Если производительность стопорится, а затраты остаются высокими, задача может быть слишком широко определена или лучше решалась бы детерминированным подходом инструментов Категории 1.

Как понять, что вы переросли Категорию 2

Вы поймёте, что нужна другая архитектура, когда:

Ваш единственный агент пытается охватить слишком много доменов (поддержка клиентов + склад + логистика + финансы), и производительность деградируетВам нужно, чтобы агенты делегировали задачи друг другу, а не просто вызывали stateless-API. Пример: шопинг-агенту нужно спросить агента склада: «Можешь проверить все склады и предложить альтернативы?»Задачи занимают часы или дни (как агент автоматизированной оценки, анализирующий 10 000 разговоров за ночь)Вам нужны сотни экземпляров агентов, работающих параллельно и координирующих работу между собойРазные команды хотят владеть своими специализированными агентами, но им нужно работать вместе

Если вы сталкиваетесь с двумя-тремя или более из этих пунктов, пора рассмотреть инструменты и подходы Категории 3.

Категория 3: Мультиагентная сеть

Что это такое

Вместо одного агента, вызывающего инструменты, у вас есть несколько специализированных агентов, которые координируются друг с другом. Каждый агент принадлежит отдельной команде, отвечает за свой домен и может запрашивать помощь у других агентов.

Этот пост доступен платным подписчикам