Представь типичную автоматизацию «на коленке». Вчера работала, сегодня API чихнул, ответ стал чуть длиннее — и всё, бизнес-процесс ушёл в закат. И ты сидишь как человек, который поставил будильник на чайник и удивился, что тот не умеет звонить.
Проблема у большинства компаний скучная и бытовая: модели стали сильными, а внедряют их так, будто это очередной чат-бот для поддержки. Потом удивляются, почему в работе оно ведёт себя как лотерея.
Почему цепочка из ИИ-шагов ломается
Обычные инструменты автоматизации мыслят линейно: шаг 1, шаг 2, шаг 3. Всё предсказуемо — пока мир ведёт себя предсказуемо.
ИИ-агенты устроены иначе. Ты задаёшь цель и инструменты, а как именно дойти — делегируешь модели. Красиво. Но не надёжно само по себе.
Потому что языковая модель — штука вероятностная. Она не «знает», она угадывает следующий шаг по распределению вариантов. И когда строишь цепочку из нескольких таких шагов, ошибки начинают размножаться как кролики на даче.
Вот конкретная математика: если у тебя пять шагов и каждый удаётся в 90% случаев, общая вероятность успеха — около 59%. То есть «почти наверняка» превращается в «ну, через раз». Это не слабость модели. Это просто математика.
Три слоя которые решают проблему
Есть подход — его называют DOE Framework — который предлагает разделить систему на три части и держать их отдельно.
Первая часть — правила. Это обычные текстовые файлы с описанием: что делает агент, какие инструменты ему доступны, что считается успехом, что нельзя нарушать. Бизнес-логика живёт здесь, отдельно от кода. Хочешь изменить процесс — правишь текст, а не лезешь переписывать скрипты.
Вторая часть — оркестратор. Это и есть сама языковая модель: она читает правила, смотрит на текущую ситуацию и решает какой следующий шаг запускать. Здесь ИИ реально полезен — он умеет разбираться с непредвиденными ситуациями: упавший API, странный формат данных, частичный ответ. Там где нельзя заранее прописать все ветки — модель справляется лучше обычного кода.
Да, это звучит как менеджер проекта. И да, иногда этот менеджер будет уверенно нести чушь. Поэтому нужна третья часть.
Третья часть — исполнение. Это обычные скрипты, которые не рассуждают. Они берут вход, делают конкретное действие и возвращают результат. Всё реальное и важное — запись в базу, отправка письма, изменение статуса заказа — происходит здесь. Без вариаций, без творческого подхода.
Если коротко: ИИ решает что делать дальше, а код гарантирует как это будет сделано.
Длинный диалог убивает надёжность
Ещё одна типовая причина развала — накопление контекста. Чем длиннее разговор с моделью, тем менее надёжной она становится: начинает путаться, тащить лишнее, забывать важное.
Решение почти офисное: держи несколько коротких «чистых» рабочих пространств вместо одной бесконечной простыни переписки. Каждая задача — своё окно, свой контекст, без груза предыдущих шагов.
Отсюда идея субагентов — изолированных помощников под узкие задачи. Один проверяет код независимо от того кто его писал. Другой обновляет документацию, чтобы она не жила в режиме «потом допишем». Каждый работает в своём чистом пространстве и возвращает главному агенту только нужное.
Что из этого брать
Главная мысль здесь не в конкретном фреймворке. Мысль в том, чтобы перестать ждать от языковой модели поведения как у обычного кода.
Модель хороша в рассуждениях и разборе нестандартных ситуаций. Плоха в гарантиях и повторяемости. Поэтому надёжная система — это когда ИИ думает, а детерминированный код делает.
Как в ремонте: можно сколько угодно обсуждать дизайн кухни, но проводку всё равно доверяешь не вдохновению, а нормальному электрику с тестером.