После нескольких успешных пилотных проектов с агентами многие организации начинают тихо обнаруживать, что прирост эффективности куда-то утекает. Разрозненные агенты создают повторную работу, конфликты и пограничные случаи, за которые никто не отвечает. Разговаривая с заказчиками, я понял, что уже видел этот фильм.
У каждой технологической волны есть вопрос, который задним числом кажется очевидным, но в разгар всеобщего энтузиазма его пропускают. Для микросервисов это был вопрос: кто на самом деле отвечает за сквозной поток клиентского сценария? Для агентов, думаю, вопрос тот же.
Обещание микросервисов заключалось в том, что команды разработки смогут оставаться независимыми и двигаться быстрее — сервисы просто будут реагировать на события, без необходимости координации. Вначале это даже работало. Добавить новый сервис было легко: достаточно было начать потреблять события из уже существующей системы, не нужно было разговаривать ни с одним производителем событий. Команды двигались быстро.
Доминирующий стиль координации назывался хореографией: сервисы не общаются друг с другом напрямую. Вместо этого они генерируют события (например, заказ размещён, платёж подтверждён, товар зарезервирован), а другие сервисы независимо реагируют на эти события. Таким образом, не нужен центральный координатор и, возможно, даже не нужно задавать явную последовательность. Каждый сервис занимается своим делом, в результате чего получается слабо связанная архитектура (спойлер: слабо связанной она не была — как я разобрал в докладе под названием «Слабая или паршивая связанность? Понимаем паттерны коммуникации в микросервисных архитектурах»).
Но затем потоки событий начали множиться, неявные зависимости накапливаться, а отладка сломанного бизнес-потока означала необходимость отслеживать события через множество сервисов, которые понятия не имели о существовании друг друга. Поддержка стала болезненной. А всякий раз, когда появлялось реальное бизнес-требование с логической последовательностью — например, отгружать только оплаченные заказы или подтверждать доставку только тогда, когда товар действительно зарезервирован, — попытка выразить это неявно через хореографию оборачивалась множеством проблем.
Последовательность была реальным бизнес-требованием. Она заслуживала того, чтобы быть видимой, контролируемой и иметь конкретного владельца. Это и есть оркестрация: один явный владелец потока, а не цепочка независимых реакций. Команды на собственном горьком опыте выяснили, для каких проблем нужен какой подход, и многие в итоге добавили явную оркестрацию для тех потоков, где она была необходима.
Это изменение не было провалом микросервисов как таковых. Индустрии просто нужно было научиться понимать, где этот паттерн работает, а где нет, — и что скучная оркестрация процессов по-прежнему необходима даже в «современных» архитектурах.
Agentic AI движется по той же траектории
Agentic AI движется по той же траектории. И первые признаки уже знакомы.
Сейчас разговор почти целиком идёт о том, что могут делать агенты: рассуждать, использовать инструменты, действовать автономно. И эти возможности действительно впечатляют. Но я веду множество разговоров с архитекторами и руководителями инженерных команд, которые развернули своих первых агентов, увидели хорошие результаты, развернули ещё больше — и теперь вдруг обнаруживают, что долг координации съедает прирост эффективности. Агенты принимают противоречащие друг другу решения или работа выполняется повторно, потому что два агента не знали, что другой уже начал её выполнять. И что ещё хуже: никто не отвечает за то, что происходит, когда шаг завершается ошибкой после трёх операций, когда другие системы уже были обновлены. Недавно я подробно писал о технических причинах этого (см. «Почему пристёгивание LangChain к движку рабочих процессов даёт обратный эффект при масштабировании» и «Как на самом деле выглядит нативная агентная архитектура»).
В книге, которую я сейчас пишу вместе с моей коллегой Эми Джонстон, — «Agentic Orchestration: How Process Discipline Governs and Scales AI Agents in Enterprise Operations» — мы называем это ловушкой агентной ценности. Это распространённое явление. И, как и в случае с микросервисами, его можно избежать, но только если с самого начала задавать правильные вопросы.
Важные вопросы
И правильные вопросы — это старые вопросы, а не вопросы об интересных новых технологиях.
Кто отвечает за конечный результат от начала до конца? Не за то, какой агент обрабатывает какую задачу, а за то, кто отвечает за путь клиента от начала до конца, включая те передачи ответственности, которые никто не предусмотрел.
Что происходит, когда что-то выходит из строя на полпути, после того как предыдущие шаги уже были выполнены? Не в демонстрации по счастливому сценарию, а в продакшене, когда третий шаг завершается ошибкой, а второй уже обновил несколько систем.
Где хранится состояние работы, чтобы любой участник — человек, агент или последующая система — мог продолжить её с полным контекстом даже несколько дней спустя?
Как выглядит аудиторский след? Не лог рассуждений LLM, а запись бизнес-процесса, которая через шесть месяцев позволит ответить на вопрос регулятора. В регулируемых отраслях это не просто полезная возможность — зачастую именно от этого зависит, сможете ли вы вообще выйти в продакшен.
Эти вопросы кажутся административными, но на самом деле они архитектурные. Пропуск этих вопросов не проявляется на пилоте. Он проявляется в продакшене, когда вы обнаруживаете, что вам нужна команда для ручной очистки последствий.
Я хочу чётко обозначить, чего я не говорю. Я не утверждаю, что BPM возвращается или что вам следует потратить шесть месяцев на рисование BPMN-диаграмм, прежде чем написать хоть строчку кода. Дисциплина процессов — это не методология. Это привычка спрашивать, кто отвечает за конечный результат от начала до конца, прежде чем вы развернёте что-то автономное, — и честно признавать, когда ответ: «никто».
Команды, работавшие с микросервисами и правильно решившие эту проблему, не были теми, кто больше всех моделировал процессы. Это были команды, которые воспринимали вопрос оркестрации против хореографии как настоящее архитектурное решение, а не как что-то, что само собой разрешится. Для агентов вопрос тот же: что действительно работает независимо, а что на самом деле является процессом — последовательностью с бизнес-логикой, зависимостями между шагами и кем-то, кто должен отвечать за результат, когда что-то идёт не так?
Есть ещё один контринтуитивный момент, который стоит назвать. Мы ожидаем, что наиболее зрелые агентные системы со временем станут более детерминированными, а не менее. Они начинают как агентные, потому что пока никто не знает паттернов. Агент обнаруживает их благодаря работе в продакшене.
Как только вы знаете паттерн, вы превращаете его в детерминированную логику, которая работает быстрее, стоит дешевле и полностью поддаётся аудиту. Агент заслужил своё увольнение, обнаружив нечто, что теперь можно закодировать как правило. Версия 1 — это умный агент, а версия 4 — управляемый процесс, в котором агенты занимаются только тем, что действительно требует суждения. Эта эволюция работает только в том случае, если вы создаёте основу оркестрации, способную её поддержать.
Скучная технология выводит агентный подход на совершенно новый уровень
Статья Дэна МакКинли Choose Boring Technology содержит известную мысль, к которой я постоянно возвращаюсь: скучные технологии стоит выбирать именно потому, что их сценарии отказа хорошо изучены. Оркестрация процессов подходит под это определение. Она уже два десятилетия используется для критически важных корпоративных потоков.
И вот что на самом деле открывает эта основа. Процессное мышление заставляет вас смотреть на путь клиента целиком — не на отдельные задачи, а на весь поток. А когда вы смотрите на весь поток, вы можете задать гораздо более интересный вопрос, чем «как сделать это быстрее?». Вы можете спросить, должен ли этот процесс вообще существовать в его нынешнем виде.
AI-агенты не просто автоматизируют отдельные шаги; они делают возможным полностью перепроектировать путь — устранять передачи ответственности, ликвидировать ожидание, обрабатывать исключения, которые раньше требовали специалистов. Но провести такую переработку можно только в том случае, если сначала понять процесс целиком и взять на себя ответственность за него от начала до конца. Дисциплина процессов — это не старый способ делать вещи. Это то, что делает новый способ возможным.
Признаюсь, «дисциплина процессов для AI-агентов» — не тот лозунг, от которого у кого-то начинает учащённо биться пульс. Наверное, никогда не был. Я помню, как на конференции в первые годы существования Camunda один из организаторов с искренним недоумением спросил меня, почему два молодых парня вроде нас (моего сооснователя Якоба и меня) занимаются такой старомодной темой, как BPM. Ответ тогда был тем же, что и сейчас: сквозная автоматизация реальных бизнес-процессов — одна из самых значимых вещей, которые может делать программное обеспечение.
Двадцать лет спустя новое поколение команд вот-вот обнаружит, что скучное и ненужное — это не одно и то же.
Подписывайтесь на мой канал Agentic Enterprise
