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

Инженерное проектирование оценки (eval engineering) — это важнейшая основа для создания надежных систем ИИ. Настройка систематических, воспроизводимых тестов для измерения истинного поведения вашего агента может стать тем самым фактором, который отличает инструмент, которому можно доверять, от того, который незаметно ломается, не вызывает API или совершает ошибки.

Я годами руководил инициативами по инженерному проектированию оценки в Google, и разработка недавно выпущенного плагина Google Cloud Developer послужила «живым» полигоном для стресс-тестирования этих ключевых принципов в реальных рабочих процессах разработчиков.

Вот четыре урока по оценке, которые мы извлекли при создании нового плагина и которые вы можете применить в своих собственных разработках.

1. Оценивайте этапы выполнения, а не итоговое резюме

Когда мы впервые оценивали агентов, мы настроили LLM-судью для проверки финального текстового ответа агента и выставляли оценки по чек-листу. Однако мы быстро поняли, что это фундаментально ошибочный подход, поскольку проверяющий видит только то, что агент написал, а не то, что он на самом деле сделал. Когда мы запустили наш первоначальный набор из 11 промптов для оценки плагина Google Cloud Developer, автоматизированный проверяющий отметил провал по трем промптам. Но когда мы открыли необработанные логи вызовов инструментов и прочитали транскрипты, оказалось, что плагин на самом деле успешно справился со всеми тремя. Например, в промпте по очистке Cloud Run наш регламент требовал проверки синтаксиса команды перед выполнением любых действий. Агент в качестве первого шага выполнил gcloud help run services list. Он выполнил работу, но его итоговое сообщение было сосредоточено на предупреждении пользователя о необратимой потере данных, а не на отчете о том, что он сверился со справочной документацией.

Проверяющий наказал агента за правильное действие просто потому, что тот не похвастался этим в резюме. Если в вашем регламенте написано «выполнил ли он X?», LLM-судья будет гадать, если вы не оцените фактическую траекторию вызовов инструментов.

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

2. Проектируйте оценки для асинхронных операций

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

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

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

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

3. Тестируйте «живые» запуски и «сухие» прогоны параллельно

Вам нужно проверять реальные вызовы API, чтобы уловить особенности обвязки, такие как параллельная отправка. Но если вы тестируете своего агента только в одних условиях среды, вы работаете вслепую. С первого дня вам нужно запускать два условия параллельно: «живой» запуск и запуск только с планированием (plan-only). В «живом» условии у агента есть реальные учетные данные в «песочнице», и он действительно выполняет команды. Так вы увидите, работает ли синтаксис, корректно ли сериализуются параметры и проявляет ли агент сдержанность перед совершением чего-то деструктивного.

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

Например, в одном из наших промптов для онбординга «живой» запуск был немедленно заблокирован при вызове списка проектов. Запуск «только планирование» прошел без проблем и выдал план на 8000 символов, который полностью игнорировал политики организации, одобрения администратора и управление. «Живой» запуск скрыл серьезный когнитивный изъян, который запуск «только планирование» выявил за секунды.

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

4. Используйте «золотые наборы» в качестве надежных базовых показателей

Архитектуры передовых моделей меняются каждые несколько месяцев, агентные обвязки совершенствуются, а стандарты манифестов плагинов неизбежно будут развиваться. При создании плагина Google Cloud Developer мы рассматривали оценки как непрерывное интеграционное тестирование для этих недетерминированных сред. Это означает, что мы подвергали стресс-тестированию составной стек, включая обвязку, «живую» модель и инструменты, работающие вместе над реалистичными задачами.

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

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

Напоминание: Используйте наборы оценок вместо «одноразовых» демо

Распространенная ошибка, которую я вижу среди инженеров, — это то, что я называю «одноразовым демо». Это когда кто-то подает промпт в LLM, наблюдает, как она строит полноценную 3D-игру или собирает кубик Рубика за один проход, и называет это оценкой. Но на самом деле это лишь тщеславная метрика.

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

Что делать дальше

Создание плагина агента или MCP-сервера — это только начало. Чтобы выпустить продукт, которому можно действительно доверить работу с реальной облачной инфраструктурой, требуется значительно больше усилий в области оценки (evaluations), чтобы гарантировать, что он выполняет именно то, что от него ожидается. В конечном счете, единственное, что переживет смену моделей — это прошедший стресс-тестирование набор оценочных тестов. Ознакомьтесь с плагином Google Cloud Developer documentation или изучите это codelab, чтобы начать работу с плагином в Antigravity.