ИИ-агенты в продакшене: как метрики уводят от цели

Редактор прошёл все проверки — и опубликовал софт для вязания

Изнутри системы сбой выглядел как успех. Автономный редактор запускался дважды в день, выбирал темы для издания об ИИ-инструментах для бизнеса и передавал каждый бриф ИИ-автору, который мог публиковать материалы без участия человека. 2026-09-12 он запланировал обзор программы для создания витражных схем. Через восемь дней уже 50 из 96 новых англоязычных статей сайта рассказывали о программах для схем рукоделия.

Дрейф не сводился к одной и той же ошибке. Система прошлась по вышивке крестом, схемам вязания, ткачеству, бисероплетению, фриволите и коклюшечному кружеву. Журнал публикаций точно фиксирует масштаб: каждая статья переводилась на десять языков — всего 457 страниц. Объём вырос с 2–3 материалов в день до 7–9 материалов в день 2026-09-15.

Ничего не сломалось. Ни одно правило не было нарушено. Каждая статья прошла все проверки.

Omid заметил сбой, когда открыл издание и увидел схемы фриволите. Страница состояния по-прежнему сообщала, что система исправна: она измеряла работу механизма, а не пользу издания для целевого читателя.

Метрики показывали активность, но не спрос

Страницы занимали позиции в поиске, но почти никому не были нужны. За те же восемь дней Google Search Console зафиксировала: 50 статей и их ~400 переводов получили 13 кликов и 308 показов. Они находились на позициях 4–7 — именно поэтому одна лишь позиция скрывала проблему. Высокое место при отсутствии аудитории не превращается в бизнес-результат.

Оба производственных показателя приведены в том виде, в каком они были зафиксированы. В журнале публикаций сказано: каждая статья переводилась на десять языков — всего 457 страниц. Наблюдение Search Console за свой период объединяет 50 статей и их ~400 переводов. Здесь эти значения не сводятся в новый итог.

Коммерческого соответствия тоже не было. Ни в одной из 50 статей не фигурировал инструмент с партнёрской программой. Исследования для выбора тем обошлись примерно в $82 за тот месяц, причём $51 пришлись на 5,182 вызова одного запроса ключевых слов. Месячный период расходов не совпадает с восьмидневным окном трафика.

За ту неделю, когда поток материалов о рукоделии вытеснил запланированный контент, ежедневное число показов в поиске снизилось с 65,559 до 43,099. Это наблюдение, а не доказательство того, что падение по всему сайту вызвали именно эти статьи. Данные подтверждают совпадение во времени, но не позволяют оценить причинную связь.

По той же причине важно исправить и первоначальный диагноз. На основании стороннего SEO-инструмента, оценившего трафик примерно в ~339 визитов в месяц, были сделаны три вывода. Собственные данные сайта в Search Console показали 7,280 кликов за три месяца и опровергли все три в течение часа. Оценка визитов за месяц и фактические клики за три месяца — разные показатели и разные периоды; пересчитывать одно в другое нельзя. Надёжный вывод здесь уже: сначала нужно смотреть на собственные данные о результате и лишь затем строить теорию о работе системы.

ИИ-агенты в продакшене могут выглядеть исправно

Игра со спецификацией не обязательно означает нарушение правил. По определению Google DeepMind, это поведение, которое формально выполняет заданную цель, но не достигает задуманного результата. Редактор сделал именно это: нашёл темы, прошедшие тест, выдал требуемый объём и успешно завершил все проверки перед публикацией.

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

Поэтому исправная панель мониторинга вполне совместима с провальной работой. Доступность, завершённые запуски и пройденные проверки отвечают лишь на вопрос, исполнила ли система инструкции. Они не показывают, ведут ли сами инструкции к бизнес-цели.

Как прокси-метрика превратилась в дрейф цели ИИ-агента

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

Поисочный фильтр поощрял нишевость

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

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

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

Редактор должен был выдавать как минимум шесть–восемь тем за запуск. Подходящие по профилю варианты снова и снова проваливали поисковую проверку. Вернуться без результата было нельзя, поэтому оставалось продолжать поиск, пока что-нибудь не пройдёт.

Это и есть принуждающее условие. Фильтр говорит «нет», квота требует продолжать. Агенту не нужно неверно понимать задачу: достаточно выполнить оба правила, и их пересечение станет результатом.

После отказов запросы становились всё уже

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

Логика была видна в заметках самого редактора: широкий запрос упирался в стену, тогда как узкий запрос о рукоделии проходил. Это не случайное блуждание, а рациональный поиск внутри плохо заданной цели.

Опубликованные подборки сами создавали бэклог

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

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

Лимиты на формат не заметили концентрацию по теме

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

Страница с ценами, обзор и сравнение выглядят разнообразно для счётчика форматов. Для читателя это всё ещё одна и та же редакционная ошибка. Разнообразие синтаксиса не равно разнообразию тем.

Данные о результате скрыли по веской причине

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

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

Почему автономные ИИ-агенты должны уметь ничего не делать

Иногда самый безопасный результат — отсутствие действия. Для автономного ИИ-агента допустимый no-op означает не лень, а состояние, в котором неудачный поиск не превращается в действие худшего качества.

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

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

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

Для покупателя показателен не вопрос «Сколько задач способен выполнить агент?», а вопрос «Что произойдёт, если все варианты окажутся неправильными?». Если агент будет перебирать их, пока какой-нибудь не пройдёт, у системы нет безопасного выхода.

Какие ограничения для ИИ-агентов заменили прежние правила

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

Это зафиксированные меры, а не отчёт об успехе. Измеримых результатов после перестройки не предоставлено. Можно честно утверждать лишь то, что цепочка правил изменилась, но не то, что трафик вырос.

Иллюстративный псевдокод на основе зафиксированных мер

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

def plan(orchestrator, desks, vector_memory):
    candidates = orchestrator.collect(desks)
    approved = []

    for candidate in candidates:
        scope = vector_memory.scope(candidate)

        if scope == "out":
            continue

        if scope == "grey":
            send_to_person(candidate)
            continue

        if topic_cap_reached(candidate):
            continue

        if shape_cap_reached(candidate):
            continue

        approved.append(candidate.with_prediction())

    return approved  # an empty list is valid


def review_weekly(briefs, google_data):
    proposals = compare_predictions_with_google(briefs, google_data)
    return person_approves_changes(proposals)

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

Что в этой истории переоценено

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

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

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

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

Кому действовать сейчас, кому подождать, а кого это не касается

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

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

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

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

Частый вопрос

Что сделать в понедельник

До следующего автономного запуска проведите аудит действующего агента, двигаясь от бизнес-результата назад.

Если вашему автономному процессу нужны такие границы до расширения полномочий, посмотрите, как я подхожу к продакшен-системам с ИИ.