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

Чеклист на пять минут: в любой петле делегирования «оркестратор → субагент» управляющий агент (оркестратор, orchestrator) перед запуском (spawn) субагента (subagent) закрывает четыре шлюза (gate): проверяемый контракт, подходящий класс модели, минимум данных и прав, путь для возражения. Ниже — что именно проверять в каждом шлюзе и как зафиксировать это в контракте подзадачи.

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

Этот материал переносит принципы в операционную рамку, применимую к любому оркестратору. Это не гайд по конкретному продукту (Grok Bot, Harvey, Gemini Legal или ADK — Agent Development Kit, набор для сборки агентов от Google) и не полный пересказ бумаги: из неё взяты только места, которые подтверждают или уточняют принципы.

Содержание

1. Целевая архитектура: четыре шлюза перед spawn — схема проверок до запуска субагента
2. Чеклист быстрой проверки — 12 пунктов, которые проходят за пять минут
3. Контракт на подзадачу — принцип 1: делегировать можно только проверяемое
4. Дешёвая модель и frontier — принцип 2: маршрутизация по стоимости задачи
5. Минимум данных и прав — принцип 3: субагент получает срез, а не полный контекст
6. Зона безразличия и трение A→B→C — принцип 4: право оспорить неясный запрос
7. Эталонный шаблон контракта субагента — YAML, готовый к копированию
8. Антипаттерны — шесть способов сломать делегирование
9. Проверка результата — наблюдаемые признаки, что рамка работает
10. Ссылки — первоисточники и дата проверки

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

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

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

Контракт на подзадачу

Cloud, Principle 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». Если grading субъективен, туда ставят человеческое время.

В §4.1 бумаги декомпозиция с контрактом впереди ("contract-first decomposition") — связывающее ограничение: делегировать можно, только если исход точно проверяется. Слишком субъективный вывод режут до единиц под автотесты.

Дешёвая модель и frontier

Principle 2: «Can this particular task be handled by a smaller, cheaper model?» Расчёт зарплат (payroll) может не потянуть лёгкая модель; переформатирование таблицы (reformatting a spreadsheet) не гонят на strong reasoning model (модель с усиленным режимом рассуждений).

Маршрутизация моделей (model routing): практика клиентов Cloud, не поставка Google. В посте: API-шлюзы и клиентские прокси, «such as LiteLLM». LiteLLM не продукт Google. Правила «дешёвая vs frontier» в бумаге нет.

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

Пример Cloud — расчёт зарплат: агент «should never pass along its full set of information to a sub-agent». Причины: безопасность и контекст, который «degrades performance». Principle 3: «An agent should grant the absolute minimum permissions required to complete that specific assignment, and nothing more.»

§4.7: ослабление полномочий (privilege attenuation): право только на подмножество ресурсов этой подзадачи. §4.9: «never be granted more permissions than are strictly necessary».

Cloud: криптография «can help», в том числе доказательства с нулевым разглашением (zero-knowledge proofs). В бумаге (§4.5) это направление исследований, а не общедоступная функция (GA, general availability) GCP.

Зона безразличия и трение A→B→C

Principle 4 Cloud опирается на Честера Барнарда, 1938, The Function of the Executive (атрибуция Cloud, не бумаги): зона, где задачу принимают без вопроса. Пока запрос не бьёт в safety-запрет, модель исполняет. Цитата бумаги §2.3:

As delegation chains lengthen (A → B → C), a broad zone of indifference allows subtle intent mismatches or context-dependent harms to propagate rapidly downstream, with each agent acting as an unthinking router rather than a responsible actor.

Динамическое когнитивное трение (dynamic cognitive friction): Cloud требует “dynamic cognitive friction” и проверку accurate, relevant, controlled and efficient. Агент оспаривает делегатора или зовёт человека. §5.1: без меры будет alarm fatigue — усталость от слишком частых запросов, после которой на тревоги перестают реагировать.

Эталонный шаблон контракта субагента

Только плейсхолдеры, без секретов.

# Заполнить до spawn. Cloud 21 Aug 2026; arXiv:2602.11865, 12 Feb 2026.
task_id: "SUB-YYYYMMDD-NNN"
role: "<роль>"
intent: "<зачем>"                     # иначе оспорить
inputs:
  data_slice: "<поля этой подзадачи>" # не полный payroll-контекст
permissions:
  mode: "least_privilege"
  allow: ["read:<resource>"]
  deny: ["read:full_dataset", "send:external"]
  expires_at: "<ISO-8601>"
model_routing:
  selected_endpoint: "<cheap_model|frontier_reasoning>"
  reason: "<сложность vs стоимость>"
  via: "<api_gateway|client_proxy>"   # LiteLLM: клиентский прокси, не продукт Google
verification:
  acceptance: "<наблюдаемый критерий>"
  method: "<unit_test|schema_check|human_grade>"
escalation:
  on_ambiguous: "challenge_delegator"
  human_when: "<нет критерия приёмки>"
constraints:
  max_hops: 1
  no_full_context_forward: true

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

• Spawn без критерия приёмки.
• Frontier на форматирование таблицы.
• Полный payroll-контекст субагенту.
• Субагент-роутер без права оспорить запрос.
• Человека вызывают на каждом шаге передачи (hop) — получается alarm fatigue.
• «Правила DeepMind», IT Brief как Google, ZKP как обязательный GCP-шаг.

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

1. У каждого spawn критерий приёмки записан до запуска.
2. Субагент не видит полный контекст оркестратора.
3. Дешёвые задачи не идут на frontier.
4. Есть путь challenge / эскалации, и по нему уже был отказ или вопрос.

Если пункта 4 не было ни разу, трение скорее всего не инженерится.

Ссылки

Проверено 27 августа 2026. Без прогона на конкретном оркестраторе. HTML бумаги обрезан в §6; AP2/UCP и заключение не цитируются.

• How agents can delegate better. Google Cloud Blog, 21 августа 2026, Nenad Tomasev и Reshu Yadav.
• Intelligent AI Delegation. arXiv:2602.11865v1, 12 февраля 2026. PDF. Пять столпов.
• Google Cloud sets four rules for AI agent delegation. IT Brief US, Mark Tarre, 24 августа 2026. Вторичный пересказ, не цитатник Google.

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

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

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

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

Если вы строите связку «оркестратор → субагенты» — в своём контуре или у клиента — прогоните чеклист на одном реальном запуске: критерий приёмки, урезанный контекст, путь challenge. Дальше контракт копируется в любой оркестратор.

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