Когда один ИИ-агент передаёт часть работы другому, он делает больше, чем просто копирует задачу. Он решает, на какие части её разбить, кому доверить каждую часть, какие данные можно отдать, а какие — нет, и как потом убедиться, что работа сделана верно. Это и есть делегирование, и в многоагентных системах это становится отдельной инженерной задачей.
Google DeepMind собрала эти решения в единый фреймворк под названием «интеллектуальное делегирование». В его основе — девять компонентов: от декомпозиции задач до проверяемого завершения и безопасности. Google Cloud, в свою очередь, выделила из исследования четыре практических принципа, которые можно применить в рабочих процессах уже сейчас.
Важно: материал описывает исследовательский фреймворк и принципы, а не готовый продукт. Часть механизмов — смарт-контракты, доказательства с нулевым разглашением — пока существует на уровне протоколов и предложений, а не повсеместной практики.
Что это
Интеллектуальное делегирование — это последовательность решений о распределении задач, в которую входят передача полномочий, ответственности и подотчётности, чёткое описание ролей и границ, ясность намерений и механизмы установления доверия между сторонами. Сложные задачи дополнительно требуют декомпозиции и подбора исполнителя под возможности.
Делегирование отличается от простого вызова подпрограммы. Когда задача превышает базовый уровень сложности, её нельзя просто «передать дальше» — нужно решить, кто за что отвечает и как проверить результат. На другом конце спектра — агенты с полной автономией, которые свободно преследуют подцели без явных проверок. Интеллектуальное делегирование занимает пространство между этими крайностями.
В делегировании участвуют две роли: делегирующий (тот, кто передаёт задачу) и исполнитель (тот, кто её принимает). Каждая роль может быть человеком или ИИ-агентом. Отсюда три сценария: человек передаёт агенту, агент передаёт агенту, агент передаёт человеку. Первый изучен лучше всего, но по мере роста числа агентов в системах два других становятся не менее важными.
Отношения между агентами бывают иерархическими и равноправными. Иерархия — это агент-координатор, который раздаёт задачи субагентам внутри коллектива. Равноправие — это агенты одного уровня, которые договариваются между собой. Продвинутый агент может также передать задачу специализированной модели без собственной агентности.
Ключевое правило: делегирование — это не только разбиение задачи на части, но и передача ответственности за результат. Без этого звена система не может ответить на вопрос, кто виноват, если что-то пошло не так.
Зачем нужно
Современные агенты справляются со всё более сложными задачами, но их полезность упирается в то, насколько хорошо они умеют раскладывать цель на подзадачи и безопасно передавать их другим агентам и людям. Существующие способы разбиения задач на части опираются на простые правила и не умеют подстраиваться под изменения среды или восстанавливаться после сбоев.
- Сложные задачи не решаются одним агентом — цель, которая требует возможностей и ресурсов сверх собственных, нужно разложить на части и распределить по исполнителям с нужными навыками.
- Текущие подходы хрупкие — жёстко заданные эвристики и простая параллелизация работают в прототипах, но не выдерживают реальных развёртываний, где нужна адаптация к изменениям.
- Нужна подотчётность — без явной передачи ответственности и полномочий невозможно понять, кто отвечает за сбой в длинной цепочке делегирования.
- Растёт число взаимодействий агент-агент — по мере появления виртуальных рынков и экономик агентов таких взаимодействий станет больше, и они будут включать передачу задач.
Google Cloud сформулировала четыре принципа, которые вытекают из исследования и отвечают на практические вопросы заказчиков. Первый — проверять делегированную работу: разбивать задачу на части, которые можно надёжно проверить. Второй — разумно подходить к стоимости: подбирать под каждую задачу модель нужной мощности, а не гонять простые операции через дорогую рассуждающую модель. Третий — уважать чувствительные данные: передавать исполнителю минимум прав и информации. Четвёртый — остерегаться зоны безразличия, где агент принимает запрос без критической оценки.
Как устроено
Фреймворк строится вокруг пяти требований, каждое из которых закрывается конкретными техническими компонентами:
| Опора фреймворка | Ключевое требование | Техническая реализация |
|---|---|---|
| Динамическая оценка | Детальный вывод состояния агента | Декомпозиция задач, назначение задач |
| Адаптивное исполнение | Реакция на смену контекста | Адаптивная координация |
| Структурная прозрачность | Аудируемость процесса и результата | Мониторинг, проверяемое завершение |
| Масштабируемый рынок | Эффективная доверенная координация | Доверие и репутация, многокритериальная оптимизация |
| Системная устойчивость | Предотвращение системных сбоев | Безопасность, управление правами |
Всего компонентов девять. Разберём каждый по порядку.
Декомпозиция задач
Прежде чем назначить задачу, её нужно разбить на части. Декомпозиция оптимизирует граф исполнения по эффективности и модульности: оценивает критичность, сложность и ограничения по ресурсам, чтобы решить, какие подзадачи выполнять параллельно, а какие — последовательно. Модульность упрощает подбор исполнителя: узкую задачу с конкретными требованиями подобрать надёжнее, чем общий запрос.
Ключевое ограничение — «декомпозиция сначала контракт»: задача передаётся только тогда, когда её результат можно точно проверить. Если результат подзадачи слишком субъективен, дорог или сложен для проверки, систему следует разбить дальше — до тех пор, пока части не совпадут с доступными способами проверки, например формальными доказательствами или модульными тестами.
Назначение задач
Для каждой подзадачи делегирующий ищет исполнителя с подходящими навыками, ресурсами и временем по приемлемой цене. Централизованный реестр агентов и людей плохо масштабируется, поэтому фреймворк предлагает децентрализованные рыночные узлы: делегирующий публикует задачу, агенты и люди подают конкурентные заявки, делегирующий выбирает лучшую.
Успешное совпадение оформляется в смарт-контракт, который связывает требования к результату с механизмами проверки и автоматическими штрафами за нарушение. Контракт должен быть двусторонним: защищать исполнителя так же строго, как и делегирующего, с условиями компенсации за отмену и возможностью пересмотра при непредвиденных событиях.
Многокритериальная оптимизация
Делегирующий редко оптимизирует один показатель. Лучший выбор — не самый быстрый, дешёвый или точный, а тот, что даёт оптимальный баланс между стоимостью, неопределённостью, приватностью, качеством и эффективностью. Сильные агенты дороже и требуют больше вычислений; экономия ресурсов замедляет исполнение; снижение риска через проверенных исполнителей повышает цену.
Оптимизация ищет решение, которое не уступает ни одному другому доступному варианту. Это не разовое действие: процесс работает как непрерывный цикл, который вбирает данные мониторинга и обновляет оценку вероятности успеха, длительности и стоимости. Если исполнение заметно отклонилось от плана, система пересматривает выбор и заново распределяет задачи.
Адаптивная координация
Для задач с высокой неопределённостью или длительностью статичный план не годится. Адаптивная координация реагирует на внешние и внутренние триггеры: изменение спецификации, отмену задачи, сбой стороннего API, появление более приоритетной задачи, деградацию исполнителя или провал проверки промежуточного результата.
Обнаружив триггер, делегирующий диагностирует причину и выбирает ответ — от подстройки параметров до полной передекомпозиции. Выбор зависит от обратимости задачи: обратимые сбои допускают автоматическое переделегирование, а необратимые и критичные требуют немедленной остановки или эскалации человеку.
Мониторинг
Мониторинг — это систематическое наблюдение за состоянием, прогрессом и результатом делегированной задачи. Он обеспечивает соблюдение контракта, обнаруживает сбои, даёт данные для оценки и питает систему репутации. Подходы различаются по пяти осям:
| Ось | Лёгкий вариант | Интенсивный вариант |
|---|---|---|
| Цель | Проверка итогового результата постфактум | Непрерывное отслеживание промежуточных состояний и расхода ресурсов |
| Наблюдаемость | Косвенная: вывод прогресса по побочным эффектам | Прямая: опрос статуса, push-уведомления, поток событий |
| Прозрачность | Чёрный ящик: видны только вход и выход | Белый ящик: полный доступ к ходу рассуждений и памяти |
| Приватность | Полная прозрачность данных | Криптографическая: доказательства без раскрытия данных |
| Топология | Прямая: наблюдение только за ближайшим исполнителем | Транзитивная: через подписанные заверения промежуточных агентов |
Технически прямой мониторинг реализуется через API: делегирующий периодически опрашивает конечную точку статуса или подписывается на webhook. Для тонкого отслеживания в реальном времени подходят потоковые платформы, где исполнитель публикует события вроде «задача начата», «достигнута контрольная точка», «задача завершена».
Доверие и репутация
Доверие — это степень уверенности делегирующего в том, что исполнитель выполнит задачу в соответствии с ограничениями и намерением. Репутация — публичная проверяемая история надёжности агента, которая служит прогнозным сигналом. Высокое доверие позволяет снизить затраты на мониторинг и проверку.
Репутацию можно реализовать тремя способами: неизменяемый реестр выполненных задач, сеть доверия с проверяемыми удостоверениями о конкретных навыках и поведенческие метрики, которые оценивают, как агент выполняет задачу, а не только итог. Репутация становится ценным активом: испорченная история ограничивает будущий заработок агента.
Управление правами
Предоставление автономии агенту создаёт поверхность уязвимости. Для рутинных задач с низкой критичностью подходят стандартные права, выведенные из проверяемых атрибутов — членства в организации или репутации выше порога. В критичных областях права должны быть адаптивными к риску: доступ выдаётся точно в срок, ограничивается длительностью задачи и при необходимости проходит через одобрение человека.
При рекурсивном делегировании действует ослабление привилегий: агент не может передать весь свой набор прав, а выдаёт только строгое подмножество, нужное для конкретной подзадачи. Права должны быть семантическими — не просто «доступ к базе», а «только чтение конкретных строк» или «только вызов конкретной функции».
Проверяемое завершение
Жизненный цикл делегирования завершается проверкой результата. Это событие превращает предварительный результат в зафиксированный факт и запускает расчёт, обновление репутации и распределение ответственности. Проверка — не запоздалая мысль, а ограничение на проектирование: гранулярность задачи подбирается заранее под доступные способы проверки.
Механизмов проверки четыре: прямая оценка результата, аудит доверенной третьей стороной, криптографические доказательства и игровые механизмы консенсуса. После проверки делегирующий выдаёт исполнителю подписанное удостоверение, которое попадает в постоянный журнал репутации.
Безопасность
Угрозы делятся на три группы: злонамеренный исполнитель, злонамеренный делегирующий и системные уязвимости экосистемы. Исполнитель может красть данные, отравлять их, обходить проверку через инъекции или внедрять скрытые закладки. Делегирующий может передавать вредоносные задачи, прощупывать уязвимости или воровать системный промпт исполнителя.
На уровне экосистемы возникают атаки Сивиллы (множество фальшивых личностей), сговор агентов, агентные ловушки во внешнем контенте и когнитивная монокультура — чрезмерная зависимость от ограниченного числа базовых моделей. Защита строится эшелонированно: доверенные среды исполнения, принцип минимальных привилегий, фильтрация запросов и криптографическая защита сети.
Когда использовать
Интеллектуальное делегирование оправдано не всегда. Для простых задач накладные расходы на переговоры, контракты и проверку могут превысить ценность самой задачи. Ниже — ориентир по ситуациям.
| Ситуация | Подходит / не подходит | Почему |
|---|---|---|
| Сложная цель, превышающая возможности одного агента | Подходит | Нужна декомпозиция и распределение по исполнителям |
| Задача с высокой критичностью и необратимыми последствиями | Подходит, с усилением | Требует строгих прав, проверок и участия человека |
| Простая рутинная операция с низкой ценностью | Не подходит | Накладные расходы на делегирование превышают выгоду |
| Задача с чувствительными данными | Подходит, с ограничениями | Нужен принцип минимальных привилегий и криптографическая проверка |
| Долгая задача в меняющейся среде | Подходит | Нужна адаптивная координация вместо статичного плана |
Пример
Как принцип «сначала контракт» выглядит на уровне протокола. Расширение объекта задачи в протоколе A2A задаёт стандарт доказательства, который исполнитель должен предоставить, чтобы задача считалась выполненной:
"verification_policy": {
"mode": "strict",
"artifacts": [
{
"type": "unit_test_log",
"validator": "mcp://test-runner-agent",
"signature_required": true
},
{
"type": "zk_snark_trace",
"circuit_hash": "0xabc123...",
"proof_protocol": "groth16"
}
],
"escrow_trigger": true
}Такой контракт заставляет исполнителя смоделировать проверку ещё до принятия задачи. Если агент не умеет генерировать доказательство с нулевым разглашением, он должен отклонить заявку на этапе подбора, а не провалиться позже.
А вот как выглядит заявка исполнителя в рыночном механизме запроса котировок. Агент указывает цену, длительность, гарантию приватности и репутационный залог:
"bid_object": {
"agent_id": "did:web:fast-coder.ai",
"estimated_cost": "5.00 USDC",
"estimated_duration": "300s",
"privacy_guarantee": "tee_enclave_sgx",
"reputation_bond": "0.50 USDC",
"expiry": "2026-10-01T12:00:00Z"
}Делегирование между ИИ-агентами — это не просто передача задачи дальше, а отдельная инженерная дисциплина. Система, которая умеет проверять работу, подбирать модель под сложность, ограничивать доступ к данным и оспаривать неоднозначные запросы, масштабируется безопасно. Система, которая просто пересылает задачи, — нет.
Ограничения
Ограничения
Что учитывать, прежде чем строить систему делегирования.
Накладные расходы на переговоры и проверку — Каждый акт делегирования стоит денег: переговоры, создание контракта, проверка и вычисления на рассуждения.
Для задач с низкой критичностью и короткой длительностью эти издержки могут превысить ценность самой задачи. Поэтому фреймворк задаёт нижний порог сложности, ниже которого задачу выгоднее выполнить напрямую.
Проверка добавляет задержку и стоимость — Доказательства с нулевым разглашением и игры консенсуса медленнее и дороже, чем исполнение без проверки.
Это «премия за надёжность», которая оправдана для критичных задач, но избыточна для рутинных. Решение — многоуровневые уровни обслуживания: дешёвое делегирование для простого и высоконадёжное для критичного.
Безопасность может стать предметом роскоши — Если высоконадёжное делегирование дорого, пользователи с меньшими ресурсами рискуют остаться на непроверенных путях исполнения.
Это этическая проблема: нужен минимальный гарантированный уровень надёжности для всех, а не только для тех, кто может заплатить за проверку.
Часть механизмов пока на уровне протоколов — Смарт-контракты, эскроу, децентрализованные удостоверения и криптографические доказательства описаны как предложения, а не как повсеместно работающая практика.
Существующие протоколы вроде MCP и A2A не имеют встроенной поддержки проверяемого завершения и управления правами — их нужно расширять.
Антипаттерны
Антипаттерны
Чего не делать при проектировании делегирования.
Передавать задачу без способа её проверить — Если результат подзадачи нельзя надёжно оценить, делегирование превращается в слепую передачу.
Правильный ход — разбивать задачу дальше, пока части не совпадут с доступными способами проверки. Субъективные части стоит отдавать на оценку человеку, а не агенту.
Отдавать исполнителю полный набор прав и данных — Передача всей информации субагенту не только нарушает безопасность, но и раздувает контекстное окно и снижает производительность.
Нужно выдавать абсолютный минимум прав и данных, необходимый для конкретного задания, и ничего сверх этого.
Гонять простые задачи через дорогую модель — Переформатирование таблицы не требует рассуждающей модели.
Подбор модели под сложность задачи — отдельная задача делегирующего: сложное отдавать сильной модели, простое — лёгкой и дешёвой.
Позволять агенту принимать запрос без критической оценки — Широкая зона безразличия позволяет тонким несовпадениям намерений распространяться вниз по цепочке делегирования.
Агент должен уметь распознавать неоднозначный запрос и оспаривать его или запрашивать проверку человеком.
Чеклист
Чеклист
Проверка перед запуском системы делегирования.
Каждая подзадача имеет способ проверки — Для каждой части работы определён механизм оценки результата: модульные тесты, формальное доказательство или явная передача на оценку человеку.
Задач без способа проверки в плане нет.
Права и данные ограничены минимумом — Исполнитель получает только те права и данные, которые нужны для конкретного задания.
При рекурсивном делегировании привилегии ослабляются на каждом шаге цепочки.
Модель подобрана под сложность задачи — Сложные задачи направлены сильной модели, простые — лёгкой и дешёвой.
Маршрутизация по моделям настроена так, чтобы достигать результата при минимальной стоимости.
Агент умеет оспаривать неоднозначный запрос
— В системе заложено динамическое когнитивное трение: агент проверяет точность и уместность запроса и может запросить уточнение или проверку человеком вместо слепого исполнения.
Ответственность распределена по цепочке
— Для длинных цепочек делегирования определены разрывы ответственности: агент либо принимает полную ответственность за действия ниже по цепочке, либо останавливает исполнение и запрашивает новые полномочия.
Ссылки
Ссылки
- Документация: Model Context Protocol (MCP)
- Документация: Agent2Agent Protocol (A2A)