Google Cloud Data Agent Kit: данные для coding-агентов
Главная причина, по которой coding-агент пишет корректный SQL, решающий неправильную задачу: у него нет контекста среды данных. Google Cloud Data Agent Kit закрывает дыру системно: MCP-инструменты поверх BigQuery, AlloyDB, Spanner и хранилищ плюс агентские навыки (оптимизация запросов, валидация, drift-контроль, governance) прямо в IDE и CLI-агентах. Разбираем, почему агент без дата-контекста опасен и как его давать правильно.
Срез на дату публикации: тарифы и каталог меняются — пересчитайте по методике статьи на свежих данных.
Короткий ответ
Data Agent Kit подносит данные к coding-агенту: MCP-инструменты поверх BigQuery и баз, навыки вместо generic-промптов, контекст схемы вместо листинга таблиц.
Проблема: корректный SQL не о том
Агент видит схему как текст — если вообще видит. Без доверенных таблиц, назначений колонок и примеров он пишет синтаксически верный запрос к неверным данным: не та таблица, не тот срез, не те единицы. Ошибка компилируется, выполняется и тихо врёт в дашборде. Это хуже падения: падение видно, неверные цифры — нет.
Лечится не «лучшей моделью», а контекстом: какие таблицы каноничны, что означает каждая колонка, какие запросы уже проверены. Data Agent Kit упаковывает это в два механизма: навыки (предписанные пути: оптимизация, валидация, drift, governance) и MCP-инструменты (живой доступ к метаданным и данным с правами). Навыки отвечают «как правильно», инструменты — «что там сейчас».
- верный синтаксис ≠ верные данные
- тихая ложь хуже падения
- навыки — как правильно, инструменты — что сейчас
- доверенные таблицы вместо листинга всего
Как давать контекст: навыки и инструменты
Навыки — это закодированная экспертиза вместо generic-промптов: оптимизация запросов, ML-практики, валидация данных, проверка дрейфа, разбор неполадок. Они превращают «агент, разберись» в «агент, действуй по чеклисту». Подключаются плагином к IDE и CLI-агентам (VS Code, Claude Code, Codex, Gemini CLI и совместимые).
MCP-инструменты дают живой доступ: endpoint BigQuery и других сервисов, OAuth с областями под каждый сервис, отдельные серверы под продукты. Важное свойство — гранулярность: агент видит то, что положено ролью, а не «всю базу, потому что так проще». Отдельный endpoint под BigQuery вместо свалки всего облака в один инструмент — это и есть least privilege на практике.
- навыки — чеклисты вместо generic-промптов
- инструменты — живой доступ с правами роли
- каждому продукту свой endpoint
- права уже роли, не «вся база»
Практика: генерация, проверка, governance
Рабочий цикл: разведка (какие таблицы, что значат) → генерация SQL по навыку → выполнение на сэмпле → проверка (план, стоимость сканирования, drift) → прод. Проверку не пропускать никогда: стоимость BigQuery-запроса считается до запуска, а не после счёта. Валидация данных и drift-контроль — частью каждого пайплайна, а не отдельным проектом «когда-нибудь».
Governance с первого дня: кто видит какие таблицы, где audit, сколько хранятся запросы. MCP добавляет известные риски широкого доступа — читайте их вместе со статьёй про безопасность: allowlist серверов, подтверждение записи, журнал без секретов. Данные, к которым агент ходит каждый день, заслуживают тех же границ, что и прод-база: потому что это она и есть.
- разведка → генерация → сэмпл → проверка → прод
- стоимость запроса — до запуска
- валидация и drift — в каждом пайплайне
- границы как у прод-базы с первого дня
Источники и связанные страницы
Следующий шаг
Открыть эту статью в Markdown·Поделиться в Telegram
Следующий материалGrok 4.7: почему длинные coding-задачи — отдельный класс