Почему искусственные интеллект-агенты для производства тихо терпят неудачу и как выявлять неверные ответы

Самой опасной проблемой в работе ИИ-агента является не сбой или истечение времени выполнения. Это ответ, который кажется правильным, проходит все проверки состояния и при этом ошибочен. В приведённом ниже случае рассматривается небольшая программная компания, которая за один квартал запустила в эксплуатацию двенадцать агентов, но сохранила лишь три; в нём объясняется, что отличало выжившие агенты от остальных, чтобы вы могли разработать механизмы обнаружения проблем до их внедрения.

Команда, инструменты и основные правила

Компания была B2B-сервисом на основе SaaS, в которой работало около сорока человек, включая девять инженеров; это не была исследовательская лаборатория. С 6 января по 27 марта 2026 года команда запустила двенадцать агентов. Те, что работали в репозитории кода, функционировали на платформе Claude Code; остальные были пользовательскими агентами, созданными на основе API Anthropic и размещёнными за внутренним сервисом, благодаря чему каждый агент имел единый журнал аудита и единую функцию отключения.

С первого дня были применены два правила, оба из которых оказались полезными:

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

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

Отчёт: три агента продолжили работу, девять были отключены

В конце квартала продолжали работать три агента:

• создатель описаний pull-запросов
• ассистент для составления заявок на поддержку
• инструмент сбора информации о инцидентах

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

Предупреждающее правило, которое не помогло

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

If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.

На практике это указание почти не оказало влияния, и причина этого является самым важным уроком всего эксперимента. Этот момент подробно рассматривается в описании неудачи с аналитикой ниже.

Разрешения также начинались с осторожности: при запуске у каждого агента был только режим чтения. За квартал четырем агентам был предоставлен режим записи. Три из этих четырех позже были выключены.

Что объединяло оставшихся агентов

Составитель описания pull request

Этот агент, работающий в Claude Code, мог читать отчеты о различиях и связанные задачи, а затем писать описание в теле pull request. Инженер редактировал его и сливал изменения. Он обрабатывал примерно 35 pull request в неделю, и описания, которые он создавал, оказывались лучше тех, что писали инженеры вручную; это происходило в основном потому, что уставший разработчик в конце дня склонен писать «исправить баг», тогда как агент не устает.

Составитель списков для сортировки запросов на поддержку

Этот агент читал каждый поступивший запрос, присваивал ему метку и составлял проект ответа в виде внутренней записки в службе поддержки. У него никогда не было возможности что-либо отправлять. Примерно 60% его проектов ответов публиковались после незначительной правки, а среднее время первого ответа сократилось с немного более четырех часов до примерно восьмидесяти минут.

Сборщик контекста инцидентов

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

Структура агента, уверенно допускающего ошибки

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

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

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

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

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

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

Когда правильный агент игнорируется

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

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

Почему девять систем были закрыты

Сбои можно было четко разделить на категории:

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

Правило проектирования: останавливаться на шаг раньше, чем начнёт действовать человек

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

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

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

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

Стоимость никогда не была узким местом. Все двенадцать агентов вместе потребовали чуть менее 900 долларов на токены за квартал. Ограниченным ресурсом было внимание людей.

Три изменения, которые вы можете внести на этой неделе

• Перед выпуском описайте, как можно обнаружить уверенно ошибочный ответ. Речь идет не о том, как вы заметите сбой, а о том, как поймете, что результат неверен. Если вы не можете сформулировать эту мысль, агент должен лишь составлять проекты, а не выполнять действия.

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

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

Сверьте число со вторым источником

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

const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
  const delta = Math.abs(agentRevenue - ledgerRevenue);
  const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
  return { ok: delta <= tolerance, delta };
};

Гоняйте сравнение по расписанию. Монитор падений останется зелёным, а вот эта проверка как раз позовёт человека.

Основные выводы

• Необходимо учитывать возможность появления правдоподобно выглядящих неверных результатов, а не просто периодов простоя; стандартный мониторинг их не обнаружит.
• Инструкции относительно уровня уверенности не могут выявить ошибки, о которых сама модель не знает.
• Режим только для чтения не означает безвредность: результаты, используемые для принятия решений, фактически являются действием.
• Уровень сигнала сам по себе является способом возникновения сбоев; правильный сигнал, потерянный в шуме, не имеет никакой ценности.
• Полезным тестом для любого агента является вопрос: возразят ли кто-либо, если его выключат завтра.