Четыре принципа делегирования субагентам

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

22 августа 2026 года Google Cloud опубликовал материал How agents can delegate better. Ненад Томашев (Nenad Tomasev, Google DeepMind) и Решу Ядав (Reshu Yadav, Google Cloud) сформулировали четыре практических принципа делегирования между агентами. Пост опирается на исследование DeepMind Intelligent AI Delegation (arXiv:2602.11865v1, 12 февраля 2026 года), где предложен адаптивный подход к делегированию с передачей полномочий, ответственности и подотчётности, ясными ролями и границами, ясностью намерения и механизмами доверия.

Материал переносит эти принципы в операционную рамку, применимую к любому оркестратору. Он не описывает конкретный продукт и не пересказывает исследование целиком.

Содержание

1. Целевая архитектура — четыре шлюза перед запуском субагента
2. Чеклист быстрой проверки — 12 пунктов на пять минут
3. Проверяемый контракт — принцип 1
4. Выбор модели по сложности и стоимости — принцип 2
5. Минимум данных и прав — принцип 3
6. Право оспорить запрос — принцип 4
7. Эталонный шаблон контракта
8. Антипаттерны
9. Проверка результата
10. Источники

Целевая архитектура

Оркестратор не передаёт задачу, пока не закрыты четыре шлюза. Нумерация принципов соответствует посту Google Cloud. Рамка собрана по источникам и не проверялась на конкретном оркестраторе.

Чеклист быстрой проверки

Проверяемый контракт

Google Cloud, принцип 1:

Agents should intelligently break down work into tasks that can be reliably verified. In our research, we call this "contract-first decomposition."

Оркестратор делит цель на части, пока результат каждой части не станет надёжно проверяемым. Идеальное состояние — план, где всё поддаётся оценке (everything can be reliably graded). Если результат требует субъективного суждения, это сигнал для участия человека.

Выбор модели по сложности и стоимости

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

Маршрутизация должна сопоставлять задачу с подходящим инструментом или конечной точкой, обеспечивая требуемую надёжность при минимальной стоимости.

3 августа 2026 года в примечаниях к выпуску API Gateway отмечен запуск маршрутизации моделей в статусе публичной предварительной версии (Public Preview). Это управляемая альтернатива клиентским прокси вроде LiteLLM, описанная в документации Google Cloud API Gateway. По состоянию на 10 сентября 2026 года шлюз принимает текстовые запросы в OpenAI-совместимом формате и направляет их к заранее развёрнутым открытым моделям Model as a Service (MaaS, «модель как сервис») в Gemini Enterprise Agent Platform Model Garden. Поддерживаются модели семейств Gemini, Anthropic Claude и OpenAI GPT.

Текущая версия маршрутизирует запрос исключительно по значению поля model в JSON. Правила и модель по умолчанию задаются в спецификации OpenAPI 3.x; порядок настройки описан в официальном руководстве. Автоматический выбор модели по сложности промпта документация не заявляет.

Основные ограничения Public Preview:

• все бэкенды одного маршрутизатора должны использовать одинаковые имена хоста (hostname) и схему URL;
• расширение маршрутизации моделей применяется только к операциям POST; поддерживаются текстовые OpenAI-совместимые запросы;
• потоковая передача ответа через события, передаваемые сервером (Server-Sent Events, SSE), поддерживается, но потоковая передача в запросе, gRPC, WebSockets и Gemini Live не поддерживаются;
• VPC Service Controls и Private Service Connect для таких шлюзов не поддерживаются;
• переключение существующего шлюза между обычным режимом и маршрутизацией моделей требует создать и развернуть новую конфигурацию API и новый экземпляр шлюза;
• поле model нужно передавать явно: в Public Preview запрос без него может быть обработан некорректно вместо ожидаемого отказа.

С 3 сентября 2026 года новые шлюзы с маршрутизацией моделей могут получать имя хоста формата gateway.dev вместо run.app. Фактический адрес следует читать из свойства defaultHostname.

Минимум данных и прав

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

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

Google Cloud также указывает на передовую криптографию, включая доказательства с нулевым разглашением (zero-knowledge proofs), как на способ подтвердить вычисление без раскрытия исходных данных. В источниках этот подход описан в контексте исследования, а не как обязательный шаг настройки Google Cloud.

Право оспорить запрос

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

Google Cloud называет защитный механизм динамическим когнитивным трением (dynamic cognitive friction). Агент проверяет, точна ли переданная информация, уместна ли она, контролируемо ли её использование и эффективна ли передача. При неоднозначности он оспаривает запрос или просит человеческую проверку.

Человека подключают по конкретным условиям. Подтверждение на каждом переходе быстро превращает внимание в узкое место.

Эталонный шаблон контракта

Шаблон содержит только безопасные плейсхолдеры.

# Заполнить до запуска субагента.
# Источники проверены 2026-09-10.
task_id: "SUB-YYYYMMDD-NNN"
role: "<роль>"
intent: "<зачем выполняется задача>"  # при неясности оспорить

inputs:
  data_slice: "<только поля этой подзадачи>"  # не полный контекст

permissions:
  mode: "least_privilege"
  allow: ["read:<resource>"]
  deny: ["read:full_dataset", "send:external"]
  expires_at: "<ISO-8601>"

model_routing:
  selected_endpoint: "<cheaper_model_endpoint|strong_reasoning_model_endpoint>"
  reason: "<сложность, надёжность и стоимость>"
  via: "<direct_endpoint|api_gateway|client_proxy>"
  preview_constraints: "<перечень ограничений или none>"

verification:
  acceptance: "<наблюдаемый критерий>"
  method: "<unit_test|schema_check|human_grade>"

escalation:
  on_ambiguous: "challenge_delegator"
  human_when: "<условие привлечения человека>"

constraints:
  max_hops: "<допустимая длина цепочки>"
  no_full_context_forward: true

Антипаттерны

• Запуск без критерия приёмки.
• Сильная дорогая модель для простого форматирования.
• Полный рабочий контекст у субагента.
• Права без ограничения ресурсом и сроком.
• Субагент без возможности оспорить запрос.
• Человек на каждом переходе цепочки.
• Public Preview представлена как зрелая функция без ограничений.
• Маршрутизация по полю model выдана за автоматический выбор модели по сложности.
• Доказательства с нулевым разглашением представлены как обязательный шаг Google Cloud.

Проверка результата

1. Для каждого запуска критерий приёмки записан заранее.
2. Субагент видит только необходимый срез контекста.
3. Простые задачи не уходят на неоправданно дорогую модель.
4. Выбранный маршрут поддерживает нужные модели, протоколы и режимы передачи данных.
5. Неоднозначный запрос можно оспорить или эскалировать.
6. В журнале запуска зафиксированы доступные сведения о маршруте, выданных правах и результате проверки, если конкретный оркестратор это поддерживает.

Для Google Cloud API Gateway в Public Preview стандартные журналы показывают URL, статус, задержку, API, конфигурацию, метод и hostname бэкенда. Однако точная модель, выбранная для конкретного запроса, отдельным структурированным полем пока не фиксируется. Один hostname может обслуживать несколько моделей, поэтому одного backendRequest.hostname недостаточно для атрибуции.

Отсутствие возражений само по себе не доказывает, что когнитивное трение работает. Проверьте этот путь отдельным тестом с намеренно неоднозначным заданием.

Источники

Проверено 10 сентября 2026 года. Рамка не прогонялась на конкретном оркестраторе.

• How agents can delegate better. Google Cloud Blog, 22 августа 2026 года, Nenad Tomasev и Reshu Yadav.
• Intelligent AI Delegation. arXiv:2602.11865v1, 12 февраля 2026 года, Nenad Tomašev, Matija Franklin и Simon Osindero.
• Overview of model routing. Google Cloud Documentation, Public Preview, обновлено 3 сентября 2026 года.
• Configure model routing. Google Cloud Documentation, обновлено 3 сентября 2026 года.
• API Gateway release notes. Запуск model routing в Public Preview отмечен 3 августа 2026 года; изменение формата hostname — 3 сентября 2026 года.

Следующий шаг

Если нужен контур с ролями и границами полномочий, разберите Grok Bot: полное руководство по облачным ИИ-агентам.

Связанные материалы

• Статья: 12 приёмов, которые превращают ИИ-агента из игрушки в рабочий инструмент
• Блог: MiniMax собрали полный агентный стек — команды агентов, ассистент Mavis и открытый код
• База знаний: Agent Reach: как исследовать продукты и отслеживать темы без лишних доступов

Прогоните чеклист на одном реальном запуске: задайте критерий приёмки, урежьте контекст и проверьте путь для возражения. После этого контракт можно переносить в другие оркестраторы.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov