Инженер сел и проверил шесть собственных ИИ-агентов по десяти вопросам, которые обычно задают на технической приёмке. Плюс заодно разобрал чужой открытый код. Разбор он выложил на Хабре, и читать его стоит любому, кто собирается ставить ИИ-агента в компанию.
Итог получился отрезвляющий. В одном из проектов — 416 автоматических тестов. Все они проверяют, что агент выдаёт результат правильной формы. Ни один не проверяет, что он делает.
Разница между этими двумя вещами и есть та самая пропасть, в которую проваливаются агентные проекты. Разберу три типовые поломки — они повторяются почти везде.
Поломка первая: границы записаны словами, а не кодом
Самая частая и самая обидная.
Агенту пишут в инструкции: «не отправляй письма без согласования», «не трогай боевую базу», «не удаляй файлы». Написано по-русски, звучит убедительно, все успокоились.
Проблема в том, что инструкция для языковой модели — это пожелание, а не запрет. Она не исполняется механически, как код. Модель читает её вместе с остальным текстом и учитывает при генерации ответа. Обычно этого достаточно. Иногда — нет: попалась необычная формулировка запроса, инструкция вступила в противоречие сама с собой, контекст оказался длинным и начало забылось.
Механическое ограничение выглядит иначе. У агента просто нет доступа к боевой базе — не потому, что ему запретили, а потому что в его учётной записи нет таких прав. Он не может отправить письмо напрямую, потому что технически умеет только положить черновик в папку.
Правило здесь простое: если нарушение границы приведёт к необратимым последствиям, граница должна быть в коде и правах доступа, а не в тексте инструкции. Всё, что записано словами, рано или поздно будет нарушено — не по злому умыслу, а по статистике.
Поломка вторая: тестируют форму, а не поведение
Возвращаюсь к тем самым 416 тестам.
Они проверяют, что на выходе получается корректный документ: поля на месте, формат верный, ничего не сломалось. Это нормальные тесты, и они нужны. Но они отвечают на вопрос «система выдала что-то правильного вида?», а не на вопрос «система сделала то, что нужно?».
Разница видна на примере. Агент разбирает входящие письма и заводит заявки. Тест формы проверит, что заявка создалась и все поля заполнены. Он не заметит, что в поле «сумма» уехала цифра из соседней строки, а срочная жалоба попала в категорию «прочее».
В шести разобранных проектах тестов поведения не было ни одного. При этом дисциплина в коде у людей была приличной — то есть речь не о новичках. Просто проверять поведение агента сложнее, дольше и непривычнее, чем проверять формат.
Оттуда же вторая деталь, которая мне понравилась своей узнаваемостью: пойманные ошибки записывали в памятку. Не в тест, который не даст выложить сломанную версию, а в текстовый файл, который человек может прочитать, а может и нет.
Поломка третья: чужой рантайм с чужими правами
Половина проектов из разбора работала на чужой среде исполнения — то есть агент запускался внутри платформы, права и ограничения которой достались ему по наследству.
На практике это означает, что вы не полностью знаете, что ваш агент может. Он умеет ровно то, что ему разрешила платформа, а не то, что вы для него задумали. Отдельный пункт разбора — специальный флаг запуска, который отключает все проверки разом. Он существует для отладки, но в реальной жизни его ставят, когда проверки начинают мешать.
Момент, когда «временно отключим на пару дней» превращается в постоянную настройку, обычно никто не замечает.
Это, кстати, ровно та история, о которой я писал в разборе про безопасность ИИ: там агент вышел за границы тестовой среды и четыре дня работал по чужой инфраструктуре. Разница только в том, что здесь границы никто и не ставил.
Что с этим делать: три рабочих правила
Автор разбора формулирует решения инженерным языком, я переведу на управленческий.
Разделите подготовку и исполнение. Всё необратимое — отправка письма клиенту, платёж, удаление данных, публикация — агент только готовит. Нажимает человек. Или второй механизм, у которого есть право отката. Этот принцип снимает большую часть рисков и почти не замедляет работу.
Свяжите выкладку новой версии с проверками поведения. Не «мы протестировали и вроде работает», а: набор сценариев прогоняется автоматически, и если агент повёл себя не так, новая версия просто не выкладывается. Пока проверки поведения существуют в виде памятки, они не работают.
Повышайте самостоятельность агента по факту, а не по ощущению. Хорошая формулировка из разбора: доверять коду, а не намерениям. Прежде чем разрешить агенту действовать без подтверждения, посмотрите на цифры: сколько раз за месяц он ошибся, в каких случаях, кто это заметил.
И то, за что я автору отдельно благодарен: он честно признаёт, что его собственный проект так и остался с максимальной автономией. Только теперь это осознанное решение, а не недосмотр. Разница между этими двумя состояниями — примерно вся разница между инженерией и надеждой.
Что спросить, если вы заказываете ИИ-агента в компанию
Три вопроса подрядчику, которые стоит задать до подписания договора.
Какие действия агента необратимы и как они защищены — словами в инструкции или правами доступа? Правильный ответ содержит слова про права, а не про промпт.
Есть ли автоматические проверки поведения и блокируют ли они выкладку? Если тестируется только формат ответа, вы получите систему, которая красиво ошибается.
Где агент запускается и какие права он унаследовал от среды? Ответ «на нашей платформе, там всё настроено» — это не ответ.
Стоят такие вещи денег и времени: разделить подготовку и исполнение, написать сценарии проверки, разложить права. В смете это выглядит как строчка, которую хочется сократить. Именно она отличает работающую систему от эффектной демонстрации, которая разваливается на третьей неделе.