Agentic workflow для стартапа: с чего начать и где не сжечь бюджет

За последний год фреймворки для агентов вышли из ресёрча в продакшн: LangGraph получил стабильный релиз, OpenAI выпустила Agents SDK и Responses API, Anthropic описала Model Context Protocol как открытый стандарт подключения инструментов. Для стартапа это значит, что собрать процесс, где модель сама вызывает функции, ходит в базу и принимает решения в несколько шагов, теперь можно за дни, а не за квартал. Проблема в другом: большинство таких процессов ломаются на второй неделе, потому что их построили как демо, а не как систему.

Ниже — как выстроить agentic workflow¹ так, чтобы он пережил переход от питча к реальным пользователям, и на каких решениях стартапы теряют деньги и время.

Что такое agentic workflow и чем он отличается от обычного вызова модели

Обычный вызов LLM — это запрос и ответ. Agentic workflow — это цикл: модель получает задачу, решает, какой инструмент вызвать, получает результат, оценивает его и делает следующий шаг, пока не достигнет цели или лимита шагов. Разница принципиальная: в первом случае вы контролируете каждый запрос, во втором отдаёте модели право самой выбирать маршрут.

Anthropic в своём инженерном блоге разделяет два понятия, которые в стартапах постоянно путают:

• Workflow — заранее заданная цепочка шагов, где переходы прописаны в коде. Модель отвечает за содержание шага, но не за маршрут.
• Agent — система, где модель сама решает, сколько шагов делать и какие инструменты вызывать. Гибче, но дороже и менее предсказуема.

Для 80% задач стартапа достаточно первого. Полноценный автономный агент нужен там, где заранее неизвестно число шагов: разбор входящей заявки произвольного вида, ресёрч по открытым источникам, дебаг чужого кода.

С чего начать: три шага перед первой строкой кода

Соблазн — сразу взять LangGraph или CrewAI и собрать многоагентную схему из пяти ролей. Это самый быстрый способ получить систему, которую невозможно отладить. Порядок другой:

1. Опишите задачу как один запрос без инструментов. Если модель решает её обычным промптом с хорошим контекстом — агент вам не нужен. Многие «агентные» задачи закрываются одним вызовом с правильно собранным входом.
2. Добавьте инструменты по одному. Сначала поиск по вашей базе, потом вызов внешнего API, потом запись результата. Каждый инструмент — отдельный измеримый шаг, который вы проверяете изолированно.
3. Введите цикл только когда шагов заранее не сосчитать. Пока число шагов фиксировано, оставайтесь на workflow: его дешевле поддерживать и проще логировать.

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

Чем собирать: сравнение подходов

На середину 2024–2025 годов у стартапа есть три реалистичных пути. Выбор зависит от того, привязываетесь ли вы к одному провайдеру и сколько контроля над логикой хотите оставить в своём коде.

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

Про MCP и подключение инструментов

Model Context Protocol от Anthropic — открытый стандарт, который описывает, как модель подключается к внешним источникам данных и инструментам единообразно. Практический смысл для стартапа: вы описываете доступ к своей базе или сервису один раз по стандарту, а не переписываете интеграцию под каждый фреймворк. Стоит ли внедрять его сразу — зависит от того, сколько источников данных у вас будет. Для одного-двух проще прямой вызов.

Кому это пригодится и кому нет

Agentic workflow оправдан, когда задача многошаговая и шаги нельзя жёстко прописать заранее. Он лишний, когда вы можете описать процесс блок-схемой.

Стоит строить, если у вас:

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

Не стоит, если у вас:

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

Где стартапы теряют деньги

Три статьи расходов, которые всплывают уже после запуска:

1. Раздувшийся контекст. Агент тащит в контекстное окно² всю историю диалога и результаты всех вызовов. Токены на входе оплачиваются каждый шаг — на длинном цикле сумма растёт нелинейно. Обрезайте контекст и суммируйте историю.
2. Отсутствие лимита шагов. Без жёсткого потолка на число итераций агент способен зациклиться и жечь бюджет, пока вы это не заметите. Ставьте лимит с первого дня.
3. Слишком мощная модель на простых шагах. Дорогую модель имеет смысл держать на планировании, а рутинные вызовы отдавать модели попроще. Смешанная схема заметно снижает счёт при том же результате.

Минимальный рабочий набор

Чтобы агентный процесс дожил до реальных пользователей, с самого начала заложите:

• логирование каждого шага: какой инструмент вызван, с какими аргументами, что вернул;
• лимит на число итераций и на бюджет токенов на одну задачу;
• отдельный слой валидации вывода перед любым действием с побочным эффектом (запись, отправка, оплата);
• набор тестовых сценариев, который прогоняется при каждом изменении промпта — иначе регресс вы заметите только в проде.

¹ Agentic workflow — процесс, в котором языковая модель не просто отвечает на запрос, а в цикле выбирает и вызывает инструменты, оценивает результат и решает следующий шаг сама.

² Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один вызов; в него входят и инструкция, и история, и результаты вызовов инструментов.