От разработки к Production: новый пайплайн
Второй выпуск руководства по Snowflake Cortex Agents описывает полный цикл разработки: от изолированных тестов до безопасного развертывания в Production. Ключевое изменение — возможность создавать агентов в Personal Database без необходимости предоставления привилегий CREATE AGENT на общих схемах. Это устраняет конфликты имен и упрощает изоляцию окружений.
Три этапа жизненного цикла агента
Процесс внедрения агентов теперь строго разделен на три этапа, каждый из которых решает конкретные задачи безопасности и валидации:
- Разработка (Personal Database): Разработчики создают агентов в своих личных базах данных. Агент ссылается на производственные источники данных (semantic view, search service), но живет в изолированной схеме. Пример создания:
CREATE OR REPLACE AGENT "USER$JSMITH".PUBLIC.release_notes_dev
FROM SPECIFICATION $$
models:
orchestration: claude-sonnet-4-6
...
$$;- Валидация (Temporary Agent): Перед продакшеном создается временный агент, существующий только в рамках сессии. Он не требует версионирования, но позволяет протестировать логику через
SNOWFLAKE.CORTEX.DATA_AGENT_RUN. Важно: временные агенты нельзя конвертировать в постоянные и они не поддерживают алиасы.
CREATE TEMPORARY AGENT release_notes_validation FROM SPECIFICATION $$...$$;
SELECT SNOWFLAKE.CORTEX.DATA_AGENT_RUN('release_notes_validation', ...);- Промоут (COPY GRANTS): При обновлении агента в Production используется команда
CREATE OR REPLACE SECURE AGENT ... COPY GRANTS FROM SPECIFICATION. Это сохраняет все существующие права доступа (grants) для ролей потребителей (например,release_agent_consumer), предотвращая потерю доступа при обновлении спецификации.
Критическая ошибка RBAC: Ownership Gotcha
В первой части руководства подчеркивалась важность владения агентом. Если агентом владеет роль ACCOUNTADMIN, механизм redaction (сокрытия спецификации) может работать некорректно. Для обеспечения безопасности спецификация агента должна быть видна только тем ролям, которые имеют право на его вызов, а не всем пользователям аккаунта.
Контроль затрат и метрики
Для оптимизации расходов в спецификацию временных агентов добавлены параметры бюджета:
| Параметр | Значение в примере | Назначение |
|---|---|---|
budget.seconds |
30 | Максимальное время выполнения запроса |
budget.tokens |
16000 | Лимит токенов на один вызов |
max_results |
5 | Ограничение результатов поиска (Cortex Search) |
Также упоминается математика оптимизации затрат при приостановке службы Cortex Search, что позволяет избежать лишних расходов на хранение индексов в периоды низкой активности.
Почему это важно
Внедрение этих паттернов позволяет организациям масштабировать использование AI-агентов, сохраняя enterprise-уровень безопасности. Изоляция через Personal Database снижает риски случайного изменения production-агентов, а механизм COPY GRANTS упрощает CI/CD процессы для AI-приложений.
Источник: Towards AI pub ↗