Agent Skills для Firebase: как выстроить eval-driven development без угадывания

Skills для Firebase: слой контекста, а не замена инженерному контролю

Firebase описывает Agent Skills как специализированные инструкции и контекст, которые можно передавать предпочитаемым AI-агентам. В этой модели агент сначала получает краткую информацию о доступных skills, а затем загружает подробный контекст, относящийся к текущей задаче. Firebase называет такой подход progressive disclosure, или поэтапным раскрытием контекста.

На практике skill отвечает на вопросы: какие правила учитывать, в какой последовательности анализировать задачу, какие ограничения соблюдать и какие артефакты подготовить. Для Firebase-задачи это может быть контекст по конфигурации, безопасности, данным или развёртыванию. Но skill не выполняет действие сам по себе. Он не заменяет функцию, MCP-интеграцию, команду CLI, тест или проверку прав доступа.

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

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

Цитата в переводе

«Agent Skills — это специализированные инструкции и контекст, которые можно передать предпочитаемым AI-агентам.»

Сначала контракт поведения, затем изменение skill

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

Контракт должен быть конкретнее запроса «помоги с Firestore». Например, агенту можно поручить проанализировать конфигурацию, подготовить изменение, не выполнять рискованную операцию без подтверждения и выдать результат, проверяемый в тестовом окружении. Такое описание не гарантирует успеха, но переводит расплывчатую полезность в набор наблюдаемых критериев.

Vertex AI описывает оценку траекторий агента, то есть последовательностей шагов и вызовов инструментов. Для таких проверок доступны подходы exact match, in-order match, any-order match, а также метрики precision и recall траектории. Это полезно, когда сравнения финальных ответов недостаточно: в агентном workflow могут иметь значение порядок действий, лишний вызов или пропущенная проверка.

Одинаковая траектория не всегда служит единственным признаком правильности. Exact match подходит для жёстко регламентированного процесса, но может оказаться слишком строгим для диагностики или исследовательской задачи, где допустимы несколько корректных путей. Поэтому набор eval’ов лучше строить на нескольких уровнях: проверках итогового состояния, ограничений безопасности, требований к инструментам и, при необходимости, ручном разборе спорных случаев.

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

Четыре уровня eval’ов: activation, tools, траектория, результат

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

Второй уровень: использование инструментов. Gemini API поддерживает function calling; разработчик может ограничивать доступный набор через allowed_tools, а режим validated требует, чтобы вызов соответствовал объявленной схеме. Это снижает риск некорректной структуры аргументов, но не отвечает на главный продуктовый вопрос: нужен ли этот вызов и имел ли агент право совершать его в данном контексте.

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

Четвёртый уровень: итог в среде, приближённой к реальной. Для технических задач предпочтительны проверяемые критерии: прохождение сборки и тестов, результат policy-check, ожидаемый ответ тестового API или корректное состояние изолированного проекта. Модель может оценивать объяснение и полноту плана, но не должна быть единственным доказательством того, что изменение работает и не нарушает ограничения.

• Activation: выбран ли нужный skill и исключён ли лишний.
• Tool use: корректны ли инструмент, параметры, полномочия и подтверждения.
• Траектория: соблюдена ли необходимая последовательность действий.
• Результат: проходит ли технический критерий в тестовой среде.

Цитата в переводе

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

LLM-as-a-judge: полезный сигнал, но не окончательный арбитр

Vertex AI позволяет использовать модельные метрики, в которых Gemini выступает судьёй качества. Такой подход применим, когда результат трудно свести к точному совпадению: например, при оценке ясности объяснения, полноты рекомендаций или соответствия заданному стилю. Документация рекомендует подготовить набор с человеческими оценками как ground truth и проверить согласованность judge-модели с этими оценками.

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

Практичная схема строится на сочетании методов. Детерминированные проверки отвечают за то, что можно формализовать: схему аргументов, сборку, тесты, состояние ресурсов и правила доступа. LLM-as-a-judge оценивает качество объяснения, структуру плана или полезность диагностического ответа. Человек разбирает новые классы ошибок, спорные примеры и изменения с повышенным риском.

Для последующего разбора нужно сохранять не только итоговый score, но и исходный запрос, версию skill, версию модели, доступные инструменты, trace вызовов, результаты внешних тестов и причину ручного решения. Иначе после изменения промпта, модели или SDK команда увидит регрессию, но не сможет воспроизвести условия её возникновения.

• Используйте judge-модель для критериев, которые трудно выразить точным тестом.
• Калибруйте модельную оценку на человеческих решениях.
• Не заменяйте технический ground truth текстовой оценкой модели.
• Храните контекст оценки, а не только итоговый балл.

Trace и хранение данных: наблюдаемость нужно проектировать заранее

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

Gemini API описывает Interactions API как единый интерфейс для моделей, оркестрации инструментов и agentic workflows. Объект Interaction хранит последовательность шагов, включая пользовательский ввод, вызовы инструментов, результаты и финальный ответ. Для eval-driven разработки это позволяет сопоставлять не только два варианта ответа, но и две траектории выполнения одного сценария.

У наблюдаемости есть обратная сторона. В документации указано, что Interaction сохраняется по умолчанию; срок хранения составляет 55 дней для paid tier и один день для free tier. Для stateless-сценария предусмотрен параметр store=false. Если trace содержит код, токены доступа, персональные данные или фрагменты рабочих конфигураций, правила минимизации, очистки и доступа к таким данным должны быть частью архитектуры eval-системы.

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

• Логируйте вход, выбранный skill, tool calls, ответы инструментов и финальный результат.
• Версионируйте dataset, skill, модель и конфигурацию инструментов.
• Исключайте секреты и чувствительные данные до сохранения trace.
• Для сценариев без необходимости хранения учитывайте store=false.

Высокая оценка не даёт агенту право менять production

Даже агент, успешно прошедший подготовленный набор eval’ов, не должен автоматически получать широкие полномочия. В документации Gemini API для managed agents рекомендуется проверять действия и результаты перед применением в чувствительных workflow. Там же указано, что песочницы по умолчанию имеют неограниченный исходящий сетевой доступ, который разработчик должен ограничивать allowlist’ом.

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

В Firebase-ориентированном workflow агент может анализировать проект, готовить дифф или конфигурацию, запускать проверки в изолированной среде и объяснять результат. Затем CI проверяет обязательные политики, а человек или отдельный утверждающий процесс принимает решение о production-применении. Такой подход ограничивает последствия ошибки в skill, внешнем инструменте или входных данных.

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

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

Рабочий цикл команды: от малого набора кейсов к регрессиям

Начинать не обязательно с большого бенчмарка. Команде достаточно сформулировать контракт skill и собрать небольшой набор репрезентативных сценариев: типовые запросы, неоднозначные формулировки, неполный контекст, известные ошибки и опасные действия. Для каждого сценария следует определить предмет проверки: активацию skill, допустимый набор tool calls, результат внешнего теста, качество объяснения или необходимость передать решение человеку.

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

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

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

• Контракт skill, затем сценарии, автоматические и ручные проверки.
• Сравнивайте baseline и candidate, а не делайте вывод по одному впечатляющему запуску.
• Критические safety-кейсы важнее среднего score.
• Каждый инцидент пополняет регрессионный набор.
• CI-политика и человек контролируют применение изменений в production.

Что подтверждают платформенные инструменты Google и чего они не обещают

Подтверждённая картина складывается из нескольких частей: Firebase предлагает skills для доставки специализированного контекста агенту; Gemini API предоставляет function calling и механизмы ограничения доступных инструментов; Vertex AI описывает оценку результатов, модельные метрики и анализ траекторий; Interactions API помогает фиксировать шаги workflow. Это набор строительных блоков для инженерного процесса, в котором агентное поведение можно наблюдать и сравнивать.

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

Зрелый смысл eval-driven development состоит не в том, чтобы заставить агента всегда повторять одну идеальную цепочку. Его задача: сделать поведение проверяемым, ошибки воспроизводимыми, границы автоматизации явными, а решение о доступе к production обоснованным. Для разработчика это уменьшает число необъяснимых регрессий, для безопасности даёт контроль над полномочиями, а владельцу продукта показывает, где автономность действительно оправдана.

• Skills структурируют контекст, но не заменяют тестирование и контроль прав.
• Траектории и traces делают агентные ошибки предметом разбора, а не догадок.
• Главный результат eval-системы: контролируемое решение о допустимой автономности, а не высокий балл сам по себе.

Что это означает на практике

Ниже приведён рабочий чек-лист для команды, которая меняет Firebase Agent Skills, конфигурацию Gemini API или агентную оркестрацию. Его следует применять к конкретному проекту и его политикам доступа, а не использовать как замену собственному процессу безопасности.

Контракт и сценарии

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

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

Проверки и наблюдаемость

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

• Проверяйте activation, tool use, траекторию и итоговый технический результат.
• Используйте детерминированные проверки там, где они доступны: схемы функций, тесты, policy-checks и изолированную среду.
• Применяйте LLM-as-a-judge для языковых и субъективных критериев, но калибруйте его на человеческих оценках.
• Сохраняйте trace с учётом минимизации данных, сроков хранения и возможности store=false.
• Фиксируйте dataset, skill, модель, конфигурацию инструментов и результаты внешних тестов.

Полномочия и регрессии

Успешный eval не должен автоматически расширять права агента. Production-применение остаётся отдельным контролируемым этапом, а ошибки должны становиться постоянной частью регрессионного набора.

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

Вывод

Firebase Agent Skills полезно рассматривать как версионируемый компонент агентной системы, а не как текстовую настройку, которую меняют по впечатлению от одной демонстрации. Эффект зависит от модели, инструментов, прав доступа, оркестрации и среды выполнения.

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

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

Источники

• Firebase Blog: AI agent skills for Firebase
• Google Cloud Blog: Introducing agent evaluation in Vertex AI Gen AI Evaluation Service
• Google AI for Developers: Function calling with the Gemini API
• Google Cloud Documentation: Evaluation agents
• Google Cloud Documentation: Evaluate with a judge model
• Google AI for Developers: Interactions API overview
• Google AI for Developers: Agents

Практический чек-лист

Чек-лист: eval-driven development для Agent Skills

Подготовить скачиваемый PDF-файл downloads/firebase-agent-skills-eval-checklist.pdf с этим чек-листом. В XLSX на листе Downloads указать: filename — firebase-agent-skills-eval-checklist.pdf; title: «Чек-лист eval-driven development для Agent Skills»; description: «Памятка для подготовки сценариев, eval’ов, трассировки и ограничений полномочий AI-агента»; buttonLabel: «Скачать PDF».

Контракт и набор сценариев

• Зафиксировать ожидаемый результат, запрещённые действия и точки подтверждения.
• Добавить типовые запросы, неоднозначные формулировки, неполный контекст и опасные действия.
• Определить, какие сценарии требуют эскалации человеку.
• Версионировать skill вместе с набором проверок.

Оценка поведения

• Проверить activation нужного skill и отсутствие ложных срабатываний.
• Проверить инструмент, параметры, полномочия и подтверждения.
• Проверить траекторию в многошаговых сценариях.
• Подтвердить итог внешним тестом, policy-check или состоянием изолированной среды.
• Не допускать, чтобы средний score скрывал критическое нарушение.

Наблюдаемость и доступы

• Сохранять контекст запуска, версии модели и skill, список инструментов и trace.
• Исключать секреты и чувствительные данные до сохранения trace.
• Учитывать срок хранения Interaction и параметр store=false для stateless-сценариев.
• Разделить подготовку изменения и право применить его в production.
• Ограничить инструменты и исходящий сетевой доступ только необходимыми возможностями.