Не спрашивайте, сколько у вас агентов. Спрашивайте, сколько их ответов вы пропускаете без проверки

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

Почему adoption rate измеряет намерение, а не результат?

Adoption rate — доля компаний, команд или сотрудников, которые начали пользоваться инструментом. Метрика пришла из SaaS, где она работала по назначению: если человек каждый день заходит в CRM и что-то в ней делает, он ею пользуется, и для оценки внедрения этого достаточно.

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

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

Доля приёмки: что именно считать?

Доля приёмки — это процент ответов агента, которые пошли дальше без вмешательства человека. «Дальше» означает конкретное действие: письмо отправлено, поле в CRM записано, тикет закрыт, документ передан в работу. Знаменатель — все ответы, которые агент выдал в этом процессе за период, включая те, что не дошли до действия.

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

Какие три события нельзя складывать в одно?

Дашборды обычно показывают одно число: «вмешательство человека». Внутри него прячутся три разных события, и у двух из них противоположный смысл.

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

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

Что показали те, кто уже это измерял?

Публичный замер доли приёмки с раскрытой методикой сделал GitHub на собственном продукте. В исследовании Ziegler и коллег (2022, 2631 ответ в опросе, из них 2047 сопоставлены с телеметрией IDE) проверяли, какая метрика использования лучше всего предсказывает ощущение продуктивности у разработчика. Победила доля принятых подсказок: на когорте участников исследования она составила 27%. Сама корреляция слабая (ρ = 0,24) — метрика оказалась лучшей среди проверенных, а не сильной сама по себе.

Вторая работа ближе к агентам. Исследователи Sierra AI в 2024 году показали на бенчмарке τ-bench, что агент, успешно закрывший задачу один раз, совсем не обязательно закроет её во второй раз. Они предложили считать pass^k — вероятность пройти одну и ту же задачу k раз подряд. Лучший на тот момент агент на GPT-4o в среднем давал меньше 50% успеха, а на восьми последовательных попытках в розничном сценарии опускался примерно до 25%. Модели из того замера давно устарели, и повторять эти проценты как актуальные не стоит. Забирать стоит конструкцию: однократный успех на демонстрации не доказывает надёжности.

Третий ориентир даёт METR — некоммерческая исследовательская организация, которая занимается оценкой моделей. В работе 2025 года она измеряет способности модели длиной задачи, которую та может довести до конца самостоятельно, и публикует эту длину сразу для двух планок надёжности: 50% успеха и 80%. Разница между ними большая, и разговор об автономии ведётся по более высокой планке.

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

Почему «без правок» — правильная планка для агента и неправильная для копайлота?

Кроме доли принятых подсказок, авторы того же исследования считали persistence — осталась ли принятая подсказка неизменной через 30, 120, 300 и 600 секунд. Эта метрика коррелировала с продуктивностью хуже. Разработчикам не мешало дорабатывать подсказку, если она давала годную отправную точку.

Разница в том, зачем в процессе стоит человек. У копайлота он стоит там по замыслу: инструмент даёт черновик, автор доводит его до конца, и правка — нормальная часть работы, а не потеря. У агента, который сам отправляет письмо клиенту или меняет запись в CRM, человек стоит в процессе по необходимости. Каждая его правка означает, что работу сделали дважды, и за оба раза заплатили вы.

Как эту метрику подделать?

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

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

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

Существует ли нормальная доля приёмки?

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

• Цена ошибки высокая, объём низкий — низкая автономия здесь нормальна. Контролируйте и не гонитесь за числом: оно и не должно расти.
• Цена ошибки низкая, объём высокий — низкая автономия означает, что вы платите дважды: за агента и за человека, который его перечитывает.
• Цена ошибки высокая, объём высокий — именно здесь метрика ценнее всего, потому что у каждого процентного пункта есть денежное выражение, и именно здесь стоит вкладываться в набор тестов.

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

Почему это метрика про деньги, а не про технологии?

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

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

Чего доля приёмки не показывает?

У метрики есть свои границы, и о них стоит знать до того, как вы поставите её в договор.

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

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

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

Сам Intercom, который выставлял счета по похожей метрике, в собственных материалах 2026 года пишет, что переходит от бинарного «закрыл или не закрыл» к оценке результата, потому что успех перестал быть двоичным. Там же он приводит среднюю долю самостоятельно закрытых обращений для агента Fin — 76% у более чем 12 тысяч команд (так на странице по состоянию на октябрь 2026). Это самоотчёт поставщика, не независимый замер, и читать его нужно именно так.

Как снять базовую долю приёмки за две недели?

• Выберите один процесс, а не все сразу. Метрика, посчитанная сразу по всему парку агентов, даёт усреднение, из которого не следует ни одного решения.
• Определите единицу измерения: один ответ агента — одна строка в журнале. Договоритесь об этом письменно до старта.
• Логируйте три поля на каждую строку: менял ли человек содержание, была ли эскалация, сработал ли guardrail. Форматирование и тон считайте отдельным счётчиком.
• Не трогайте промпт и настройки две недели. Правки во время замера уничтожают базу, с которой вы потом будете сравнивать следующую версию.
• Посчитайте три доли и посмотрите на распределение по дням, а не только на среднее. Провал в конкретные дни обычно указывает на тип обращений, а не на модель.
• Добавьте выборочную проверку: пять процентов принятых ответов перечитывает человек. Без этого шага число вам льстит.

Две недели — минимум, за который виден недельный цикл нагрузки. Если в процессе есть месячная сезонность (закрытие периода, отчётность), базу нужно снимать дольше.

Как сформулировать порог приёмки в договоре?

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

Формулировка, которая имеет смысл в SOW — описании работ в приложении к договору, — выглядит примерно так: на согласованном наборе из N реальных обращений доля ответов, принятых без содержательных правок, не ниже X процентов при нулевых нарушениях guardrails, замер проводится на стороне заказчика и на его данных.

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

Что Auspex делает на внедрении?

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

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

Первые шаги к собственному числу

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

Если агент у вас уже работает, а трёх чисел нет — снимите базу на одном процессе за две недели: три счётчика, порог из ваших данных и выборочная проверка принятого. Замер агента делает Grow2.ai, наше AI-подразделение, в формате бесплатного AI-аудита; если вопросы шире и начинаются с процесса и CRM под агентом — это аудит CRM и автоматизаций в Auspex. Обе ссылки ниже.