Когда НЕ стоит строить ИИ-агента (что делать вместо)

Содержание

Опубликовано в августе 2026 года.

TL;DR: Большинство идей ИИ-агентов — не тот инструмент для задачи. Прежде чем написать код агента, я проверяю пять дисквалифицирующих признаков: нестабильный процесс, низкая частота, отсутствие теста «прошёл/не прошёл», уже работающий более простой инструмент или необратимый сбой, который я не успею гейтировать вовремя. Если верен хотя бы один — я не строю. Вместо этого я спускаюсь по лестнице более дешёвых альтернатив и возвращаюсь к кастомному агенту, только если ничто на этой лестнице не сработало.

[Заметка оператора] Я управляю более чем 30 ИИ-агентами в продакшне — для консалтингового бренда и Pickleland, центра пиклбола в Пфлюгервилле, штат Техас. Я отклонил как минимум столько же идей агентов, сколько запустил, и почти ни одна не умерла из-за того, что идея была плохой — они умирали, потому что агент был не тем инструментом для конкретной задачи. Этот пост — фильтр, который я применяю до того, как «стоит ли это строить» превращается в «как это строить».

Ответ по умолчанию — нет

Фреймворк ROI, который я использую, показывает, окупает ли автоматизация затраты на разработку и поддержку. Это правильный второй вопрос. Первый вопрос проще, и его постоянно пропускают: а нужен ли здесь агент вообще?

«Агент» стал ярлыком по умолчанию для всего, что связано с LLM, — так же как пятнадцать лет назад «приложение» стало ярлыком по умолчанию для всего, что связано с экраном. Не всё, что касается модели, нуждается в постоянно работающей, автономной системе с вызовом инструментов, которая следит за триггерами и сама совершает действия. Многое из того, что люди называют «созданием агента», на самом деле — «написать по-настоящему хороший промпт и запускать его вручную», и это не провал — это часто и есть правильное конечное состояние.

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

Пять признаков того, что агент — не тот инструмент

Любого одного из этих признаков само по себе обычно достаточно, чтобы меня остановить.

1. Процесс ещё не стабилен. Если рабочий процесс менялся дважды за последний месяц, потому что сам бизнес всё ещё выясняет, чего хочет, агент фиксирует сегодняшнюю версию процесса, который вот-вот снова изменится. Вам придётся переписывать промпт, схему инструментов и набор тестов (eval set) каждый раз, когда процесс сдвигается, — а это значит, что вы обслуживаете агента вместо того, чтобы вести бизнес. Выполняйте процесс вручную, пока он не устоится хотя бы на квартал, а затем автоматизируйте устоявшуюся версию.

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

3. Вы не можете написать для неё тест «прошёл/не прошёл». Если вы не можете заранее описать, как выглядит правильный результат, — достаточно чётко, чтобы проверить это программно, — вы не сможете построить набор тестов (eval harness) для неё, а агент, который нельзя оценить, — это агент, с которым вы летите вслепую. Задачи, которые сводятся к чистому вкусу («звучит ли это как я») или к чистому суждению без устойчивого критерия за ним, остаются ручными — или требуют проверки человеком каждый раз, что сводит на нет смысл их автоматизации.

4. Более простой инструмент уже справляется с задачей. Прежде чем закладывать масштаб агента, спросите, чего добилась бы формула в таблице, workflow в Zapier/Make/n8n с одним шагом LLM или сохранённый промпт. Если честный ответ — «на 90% справляется», последние 10% редко оправдывают запуск агента с собственной инфраструктурой, мониторингом и налогом на обслуживание. Я закладывал масштаб агентов под задачи, которые не хуже решались представлением-фильтром и повторяющимся напоминанием в календаре.

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

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

Лестница, по которой я поднимаюсь перед тем, как строить

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

1. Просто спросить модель напрямую. Без обёртки, без вызовов инструментов, без постоянной инфраструктуры. Откройте Claude, вставьте контекст, задайте вопрос, используйте ответ. Это решает больше разовых и редких задач, чем кажется, потому что инстинкт «нужен агент» срабатывает даже для того, что нужно сделать всего один раз.

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

3. No-code инструмент автоматизации с одним шагом LLM. Для задач, которым действительно нужен триггер (новая отправка формы, новая строка в таблице), но сама логика проста, workflow-инструмент с одним вызовом модели в середине собрать и поддерживать гораздо дешевле, чем кастомный код. Я прибегаю к этому раньше, чем к кастомной инфраструктуре, всякий раз, когда триггер стандартный, а объём низкий или умеренный.

4. Шаблон, выполняемый вручную. Некоторым процессам чек-лист приносит больше пользы, чем автоматизация, потому что ценность — в том, что человек продумывает каждый шаг, а не в скорости. Не автоматизируйте мышление на задачах, где именно мышление — суть.

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

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

Двухнедельный теневой тест

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

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

Теневой тест также выявляет краевые случаи до того, как они попадают в продакшн. Гораздо дешевле обнаружить во время ручного прогона, что 15% вводных требуют особой обработки, чем узнать об этом из жалобы клиента после того, как агент уже запущен.

Правило, которое я применяю после того, как отклонил идею

Отклонить идею агента — не то же самое, что отклонить саму проблему. Если задача пока дисквалифицирует себя — процесс всё ещё меняется, объём слишком низкий, — я записываю почему и намечаю примерную точку повторной проверки (обычно привязанную к конкретному триггеру: «перепроверить, когда бронирования превысят 50 в неделю», а не просто к дате). Идеи агентов, которые отклонили один раз и никогда не пересматривали, тихо превращаются в постоянную ручную работу, о повторной оценке которой никто уже не помнит.

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

FAQ

Разве это не просто аргумент против автоматизации?

Нет — это аргумент против того, чтобы по умолчанию выбирать самую дорогую форму автоматизации. Большинство альтернатив на лестнице выше — тоже автоматизация, просто более лёгкая. Я управляю десятками агентов в продакшне. Смысл не в том, чтобы избегать разработки, а в том, чтобы перестать сразу перескакивать к «построить кастомного агента», когда сохранённый промпт или no-code workflow дают тот же результат за долю стоимости разработки и поддержки.

Что если объём задачи явно вырастет позже?

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

Как понять, что шаг no-code инструмента «достаточно хорош», а не требует кастомного кода?

Сначала попробуйте и измерьте по своему набору тестов, пусть даже неформальному. No-code шаги с LLM хорошо справляются с однозадачными задачами с одним вводом. Они начинают давать сбой, когда нужно многошаговое использование инструментов, постоянное состояние между запусками или условная логика, которую конструктор инструмента не может выразить чисто. Если вы упёрлись в эту стену — это реальный сигнал переходить на кастомную инфраструктуру, а не повод начинать с неё.

Применимо ли это к внутренним инструментам иначе, чем к клиентским?

Пять признаков применяются одинаково, но ставки разные. Внутренний инструмент с нестабильным процессом при сбое просто тратит время вашей же команды. Клиентский инструмент с нестабильным процессом подрывает доверие людей, которые не подписывались быть вашим набором тестов. К клиентским автоматизациям я применяю более строгую версию именно пятого признака — планка «правильно гейтировано» выше, когда на другом конце ошибки незнакомец, а не коллега.

Какая самая частая причина, по которой вы отклоняете идею агента?

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