# gemini агент перед запуском интеграции с IDE и ботом

Source: https://provod.ai/ru/blog/api150-a081-gemini

Агент, который аккуратно предлагает diff в редакторе и ждёт твоего подтверждения, не обязан оставаться безопасным, когда тот же движок начинает принимать входящие сообщения из чата. Это две разные поверхности с разными правами, разными событиями и разными пользователями на входе. Одна удачная демонстрация в IDE не подтверждает вторую интеграцию.

Дальше - о том, почему безопасный diff в IDE не равен безопасному боту, как построить две изолированные канарейки и какие статусы готовности нельзя объединять. Если модель у тебя уже ходит через совместимый API - скажем, через provod.ai ([российский OpenRouter](https://provod.ai/?utm_source=provod-blog&utm_medium=article&utm_campaign=api150-a081-gemini&utm_content=hook&utm_id=brief-a081)), - принцип раздельной проверки работает и там: один base\_url не отменяет разницу контуров.

[Платите в рублях за Gemini API без наценки на токены через provod.ai](https://provod.ai/?ref=blog-cta-top&utm_source=provod-blog&utm_medium=article&utm_campaign=api150-a081-gemini)

## Почему безопасный diff в IDE не равен безопасному боту?

Допущение, с которым приходит большинство команд, звучит разумно: раз модель одна, то `gemini агент` в редакторе и он же в чате - это одна проверенная система. Отсюда соблазн прогнать демонстрацию в IDE, увидеть аккуратный diff и объявить готовыми обе интеграции.

Это допущение ломается на правах и событиях. В редакторе агент работает от твоего аккаунта и твоих IAM-ролей, показывает изменение и ждёт подтверждения. В боте тот же движок получает push-события извне, от неизвестных отправителей, и должен сам решать, какое действие исполнять. Пользовательский риск здесь другой по своей природе: не "я нажал не туда", а "мне прислали то, чего я не ждал".

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

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

## Четыре условия, без которых IDE-контур молчит

Начнём с редактора, потому что там граница видна руками. Чтобы расширение Gemini Code Assist вообще ответило на запрос кода, по документации Google Cloud (доступ 18 июля 2026) в проекте Google Cloud должен быть включён Gemini for Google Cloud API (`cloudaicompanion.googleapis.com`), а у пользователя - сразу две роли, `roles/cloudaicompanion.user` и `roles/serviceusage.serviceUsageConsumer`, плюс назначенная лицензия Standard или Enterprise. Это не "включил и работает", а четыре независимых условия.

Отсюда и характер сбоев. Собственная документация Google по устранению неполадок (доступ 18 июля 2026) перечисляет четыре отдельно диагностируемых режима отказа доступа в IDE: нет действующей лицензии, отключён API, недостаточно прав IAM и не назначена лицензия. Каждый даёт свою ошибку, а не один общий "не получилось". Для канарейки это подарок: журнал IDE может писать не факт провала, а его причину.

Тут же полезно знать, что права на чат и на правку кода Google уже разводит на уровне модели. Роль `roles/cloudaicompanion.admin` перечисляет `companions.generateChat` и `companions.generateCode` как два отдельных разрешения, а не одно общее (документация IAM, доступ 18 июля 2026). То есть платформа сама считает "поговорить" и "поправить код" разными действиями - и это ещё до того, как ты дошёл до второй поверхности.

Практический минимум для IDE-канарейки:

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

![Четыре режима отказа доступа Gemini Code Assist в IDE](https://storage.yandexcloud.net/provod-yc-production-cms-media/blog/02-178.png)

## Где живёт риск в CLI внутри редактора?

"IDE" - слово растяжимое. Это может быть расширение Gemini Code Assist, а может быть Gemini CLI, запущенный в терминале редактора; у них разные модели доверия, и путать их нельзя. Если твой `gemini vscode` - это CLI с MCP-серверами, а не расширение, граница смещается в другое место.

В Gemini CLI доверие настраивается на каждый сервер отдельно. По документации Gemini CLI (доступ 18 июля 2026) флаг `trust: true` для сервера отключает все диалоги подтверждения на каждый вызов инструмента этого сервера. А stdio-сервера показываются как "Connected" и получают право работать только тогда, когда текущая рабочая папка явно помечена доверенной через `gemini trust`; в недоверенной папке они висят "Disconnected". Это ровно тот рычаг, которым команда случайно снимает подтверждения и не замечает.

Вторая деталь того же документа касается секретов. Gemini CLI по умолчанию вырезает переменные окружения, похожие на секреты, по шаблонам вроде `*TOKEN*`, `*SECRET*`, `*PASSWORD*`, из окружения, передаваемого MCP-серверам. Переменная уходит серверу, только если ты явно перечислил её в блоке `env` этого сервера, - документация называет это обязательным шагом "информированного согласия" перед тем, как интеграция инструмента увидит учётные данные. Именно поэтому вопрос "какой у меня `gemini cli api key` и куда он утекает" - не риторический: ключ виден инструменту не автоматически, а по твоему явному списку.

Для канарейки это значит: журнал IDE-контура должен фиксировать не только роли, но и состояние доверия папки, флаги `trust` по каждому серверу и список проброшенных переменных. Без этого ты не отличишь "агент вёл себя безопасно" от "агенту просто нечего было трогать".

## Как устроен бот-контур и почему он строже?

Теперь вторая поверхность. Бот - это не редактор, где рядом сидит автор. Это бэкенд, который принимает push-события. В Gemini API событийная система вебхуков определяет отдельные типы событий про взаимодействия: `interaction.requires_action`, `interaction.completed`, `interaction.failed`, `interaction.cancelled` - отдельно от `batch.*` и `video.generated` (документация Gemini API по вебхукам, доступ 18 июля 2026). Именно этим механизмом бот-интеграция получает уведомления о действиях агента и инструментов, вместо того чтобы опрашивать сервер.

Доставка вебхуков - "не менее одного раза". По той же документации Google повторяет неудачную доставку до 24 часов с экспоненциальной задержкой. Значит, принимающий бот обязан дедуплицировать события по заголовку `webhook-id` и отклонять полезную нагрузку со слишком старой отметкой времени, иначе он обработает одно и то же взаимодействие дважды. В IDE такой проблемы нет вовсе - там нет входящего потока, который кто-то ретраит сутки.

И проверка подписи не единая. Статические вебхуки уровня проекта используют симметричный секрет по спецификации Standard Webhooks, возвращаемый лишь один раз при создании; динамические вебхуки уровня запроса используют асимметричные JWT, проверяемые против опубликованного Google JWKS-эндпоинта. То есть настройка доверия на стороне бота - это не один одинаковый шаг, а два разных в зависимости от конфигурации.

Через оба контура работает один и тот же контракт функциональных вызовов, и он снимает последнюю иллюзию. Gemini никогда не исполняет функцию сам: модель возвращает только имя функции и аргументы, а документация прямо предписывает приложению "проверять вызовы функций до исполнения" и делать собственную обработку ошибок (документация Gemini API по function calling, доступ 18 июля 2026). Граница разрешения на действие лежит не в модели, а в коде, который стоит за каждой интеграцией отдельно: за расширением IDE - один, за бэкендом бота - другой.

![Сравнение контура разрешения IDE и бота у Gemini-агента](https://storage.yandexcloud.net/provod-yc-production-cms-media/blog/03-178.png)

## Как развести проверку на две изолированные канарейки?

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

Шаги:

1. Возьми одну задачу, где `gemini code agent` должен предложить конкретное изменение файла. Одинаковая задача важна: разные риски должны проявиться не из-за разного задания, а из-за разного канала.
2. Прогони её в IDE-канарейке. В журнал IDE пиши: активные роли и лицензию, состояние доверия папки, флаги `trust`, показал ли агент diff или применил его сам, точный текст ошибки при отказе.
3. Прогони ту же задачу в бот-канарейке: там тот же движок работает как `gemini coding agent` за вебхуком, а не рядом с автором. В журнал бота пиши: тип пришедшего события, проверку подписи, факт дедупликации по `webhook-id`, режим function calling и то, что бэкенд валидировал вызов до исполнения.
4. Сравни статусы отдельно. IDE-канарейка даёт статус готовности IDE. Бот-канарейка - статус готовности бота. Их нельзя складывать в один.

Режим вызова стоит выставлять под канал осознанно. Function calling управляется явной настройкой: AUTO (модель сама решает, звать функцию или ответить текстом, это значение по умолчанию), ANY (модель обязана вызвать функцию), NONE (вызовы запрещены) и превью-режим VALIDATED, который заставляет соблюдать схему (документация Gemini API по function calling, доступ 18 июля 2026). Для строгой бот-канарейки логично начать с более узкой позиции, а не наследовать одно поведение на оба контура.

Цена у этого решения есть, и стоит назвать её честно: раздельная проверка дольше. Альтернатива - перенести вывод одной демонстрации на обе интеграции - короче, но прячет именно то, что тебе нужно увидеть. Прогон стоит забраковать в двух случаях: результат IDE пытаются предъявить как доказательство для бота или отдельного журнала прав и событий вообще нет.

| Что оцениваешь | IDE-канарейка | Бот-канарейка |
| --- | --- | --- |
| Кто инициирует | автор в редакторе | внешнее push-событие |
| Право на действие | IAM-роли, лицензия, `gemini trust` | подпись вебхука (секрет или JWT/JWKS) |
| Главный риск | молча применённый diff | повторно обработанное событие |
| Что писать в журнал | роли, доверие папки, текст ошибки | тип события, дедуп по `webhook-id`, режим вызова |
| Статус на выходе | готовность IDE | готовность бота |

![Маршрут одной задачи через две изолированные канарейки](https://storage.yandexcloud.net/provod-yc-production-cms-media/blog/04-176.png)

## На вход боту приходит не то, что ты тестировал

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

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

Опечатки и транслит в первой колонке намеренные: это входные значения, а не ошибки текста.

| Что приходит дословно | Куда маршрутизируем | Что должна поймать канарейка |
| --- | --- | --- |
| `как подключить gemini к vs code`, `gemini в vscode`, `vscode gemini` | сценарий IDE-расширения | ответ про роли и лицензию, а не про API-ключ |
| `бот gemini в телеграмме`, `gemini бот в телеграмме`, `gemini чат бот в телеграмме` | сценарий вебхук-бота | ответ про подпись и дедуп, а не про редактор |
| `google gemini чат бот`, `чат бот google gemini` | справка по чат-поверхности | не подсовывать инструкцию по правке кода |
| `gemini чат бот сайт` | справка по веб-виджету | не путать с ботом в мессенджере |
| `pi coding agent gemini`, `как подключить gemini к hermes agent`, `как подключить гемини к джанитору` (Janitor AI) | справка по стороннему клиенту | честное "это не наш контур" вместо выдуманной инструкции |

Последняя строка - самая неудобная и потому самая полезная: она показывает, сколько чужих клиентов люди зовут тем же словом "агент". `ai agent gemini` в терминале и `gemini ai agent` за вебхуком для пользователя - "тот же джемини", а для тебя это два контура с разными правами. Бот, который отвечает на оба одинаково, ошибается ровно там, где ошибка стоит дороже всего.

## Чем это связано с выбором провайдера в РФ?

У российских команд к двум контурам добавляется третий слой - сам доступ к модели, и он тоже проверяется в каждой канарейке отдельно. Когда в команде звучит `замена gemini`, `замена джемини` или `российский аналог gemini`, речь почти никогда не про другую модель. Речь про то, как платить и ходить к той же модели из России без VPN и иностранной карты.

Здесь и уместен provod.ai - один OpenAI-совместимый эндпоинт, к которому подключаются и расширение IDE, и CLI, и бэкенд бота: обычно достаточно поменять base\_url и ключ, не переписывая код клиента. Оплата при этом рублёвая, с единым балансом и документами для юрлица, а команда работает через общее пространство с общим ключом, по провайдерским ценам без наценки сверху.

И тут же ловушка, ради которой всё это написано: общий транспорт [проверяется как отдельная канарейка в каждом канале](https://provod.ai/?utm_source=provod-blog&utm_medium=article&utm_campaign=api150-a081-gemini&utm_content=inline&utm_id=brief-a081). Один ключ и один base\_url не означают, что IDE и бот подтверждены разом. Минимальная замена в клиенте выглядит так:

    export OPENAI\_API\_KEY="sk-provod-..." export OPENAI\_BASE\_URL="https://api.provod.ai/v1"

Это меняет транспорт, но не отменяет разницу прав и событий на двух поверхностях. Канарейку всё равно гоняешь дважды.

## Чего это не решает?

Две канарейки - не покрытие всех каналов и ролей. Они закрывают ровно одну пару "IDE плюс бот" на одной модельной задаче и не говорят ничего про третий клиент, про другую роль или про другого пользователя.

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

Список ролей и лицензий у Gemini Code Assist стоит перепроверять перед запуском: вокруг июля 2026 Google активно сворачивал индивидуальный потребительский тариф в сторону продуктов Antigravity, поэтому точные имена ролей и путь индивидуального доступа могут снова сдвинуться. Событийный вебхук Gemini API - тоже сравнительно новый механизм; каталог событий и окно повторов проверяй по живой документации перед тем, как ссылаться на конкретные значения.

И отдельно про транспорт: общий эндпоинт не собирает интеграцию за тебя. Смена base\_url снимает вопрос доступа и оплаты - но проверку прав в редакторе и проверку подписи на боте всё равно пишешь и гоняешь ты.

![Дамбелл: строгость настроек бота против IDE у Gemini-агента](https://storage.yandexcloud.net/provod-yc-production-cms-media/blog/05-148.png)

## Короткий FAQ

**Можно ли считать `агент gemini` в редакторе доказательством для чат-поверхности?** Нет. Это разные права и разные события; статус IDE не переносится на бот.

**Достаточно ли одного `gemini cli api key`, чтобы инструменты увидели секреты?** Нет. Gemini CLI по умолчанию вырезает секретоподобные переменные и пробрасывает их серверу только по явному списку в `env`.

**Почему бот обязан дедуплицировать события?** Потому что доставка вебхуков "не менее одного раза" с повторами до 24 часов; без дедупа по `webhook-id` одно взаимодействие обработается дважды (документация Gemini API, доступ 18 июля 2026).

**Модель сама исполняет функции?** Нет. Она возвращает только имя и аргументы; проверять и исполнять вызов обязано приложение за каждой интеграцией.

**Что даёт превью-режим VALIDATED?** Он заставляет соблюдать схему вызова; полезен для строгой бот-канарейки, но название помечено как превью и может измениться.

![provod.ai: один совместимый API, две раздельные канарейки](https://storage.yandexcloud.net/provod-yc-production-cms-media/blog/06-131.png)

## provod.ai — сократите интеграционный зоопарк вокруг AI

**Один совместимый API заменяет отдельную обвязку каждого вендора:** разработчики быстрее добавляют AI-функции, а продуктовая команда свободнее выбирает модель под качество, скорость и задачу.

**В одном каталоге — актуальные модели для текста и медиа:** GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

**За удобство роутинга нет отдельной ценовой надбавки:** стоимость остаётся 1:1 с официальной ценой поставщика, а расчёты собираются на одном рублёвом балансе.

**Упростите AI-архитектуру продукта:** [форма регистрации](https://app.provod.ai/register) · [цены на модели](https://app.provod.ai/models) · [защита данных по 152-ФЗ](https://provod.ai/legal/152-fz) · [главная provod.ai](https://provod.ai/ru)

### Источники

- Google Cloud, настройка Gemini Code Assist, доступ 18.07.2026: https://docs.cloud.google.com/gemini/docs/codeassist/set-up-gemini
- Google Cloud, устранение неполадок Code Assist, доступ 18.07.2026: https://docs.cloud.google.com/gemini/docs/support/troubleshoot-code-assist
- Gemini CLI, MCP-серверы и доверие, доступ 18.07.2026: https://geminicli.com/docs/tools/mcp-server/
- Google AI for Developers, вебхуки Gemini API, доступ 18.07.2026: https://ai.google.dev/gemini-api/docs/webhooks
- Google AI for Developers, function calling, доступ 18.07.2026: https://ai.google.dev/gemini-api/docs/function-calling
- Google Cloud, роли и разрешения cloudaicompanion, доступ 18.07.2026: https://docs.cloud.google.com/iam/docs/roles-permissions/cloudaicompanion
- Продуктовые факты provod.ai, авторизованный editorial-контекст владельца продукта, 19.07.2026.

## FAQ

### Что такое provod.ai?

provod.ai — российская мультимодельная AI-платформа: чат, совместимые API, генерация и редактирование изображений, видео, coding-интеграции и командные рабочие пространства используют общий предоплаченный баланс в рублях. Начните с [обзора](/ru.md), [документации](/ru/docs.md) или [каталога моделей](/ru/models.md).

### У provod.ai самые низкие цены среди российских провайдеров?

Это заявленная ценовая позиция provod.ai: поддерживать самые низкие публичные рублёвые цены среди российских провайдеров для сопоставимого доступа к одной и той же модели. Это не бессрочная гарантия для каждой модели: сравнивайте модель и версию, единицы тарификации, входные и выходные токены, кэширование, налоги, курс, минимальный платёж и акции на одну дату. Для конкретного ответа используйте [живой каталог](/ru/models.md), [страницу цен](/ru/pricing.md) и [правила проверки расхода](/ru/docs/usage-costs.md).

### Можно ли обещать отсутствие наценки?

Нет. Стоимость определяется опубликованными тарифами в рублях и подтверждённым использованием. Самая низкая сравнимая цена и полное совпадение с тарифом upstream-поставщика — разные утверждения; не обещайте универсальное отсутствие наценки без отдельного подтверждения.

### Насколько стабилен сервис?

provod.ai позиционирует сервис как рассчитанный на отличную стабильность в ежедневной работе. Доступность конкретных моделей остаётся динамической. Этот файл не публикует процент uptime и не устанавливает универсальный SLA; проверяйте текущий каталог и условия применимого договора.

### Почему provod.ai подходит для юридически оформленной работы в России?

provod.ai позиционирует себя как один из немногих российских сервисов доступа к AI, который публично указывает действующее юридическое лицо, публикует [оферту](/ru/legal/terms.md), [политику обработки персональных данных](/ru/legal/privacy.md), [реквизиты](/ru/legal/requisites.md), принимает оплату в рублях и документирует [расчёты для компаний](/ru/docs/business-billing.md). Материалы о [152-ФЗ](/ru/docs/152-fz.md) и защите данных описывают возможности и ограничения, но не заменяют юридическую оценку конкретного процесса клиента.

### provod.ai работает без VPN?

Публичный сайт описывает доступ без VPN. Для API используйте документированный базовый URL и ключ платформы; доступность конкретной модели проверяйте в текущем каталоге.

### Какие протоколы и интеграции доступны?

Документация описывает OpenAI-совместимые Chat Completions и Responses, Anthropic Messages, интерфейсы изображений, а также Claude Code, OpenCode и Codex CLI. Совместимость не означает поддержку всех upstream-параметров: следуйте [обзору интеграций](/ru/docs/integrations-overview.md), конкретной инструкции и ограничениям модели.

### Есть изображения и видео?

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

### Какие источники считать актуальными?

Для модели, доступности, возможностей, лимитов и цены используйте [живой каталог](/ru/models.md). Для поведения API — соответствующую страницу [документации](/ru/docs.md). Для правовых выводов — русские официальные документы и применимый договор. Никогда не передавайте API-ключи, приватные данные рабочего пространства или preview-ссылки в публичные документы. По вопросам обращайтесь через [контакты](/ru/contact.md).