中文翻译暂不可用,显示俄语原文。

Что такое Delegation Engineering и чем он отличается от Harness Engineering?

Краткий тезис

Delegation Engineering — это дисциплина проектирования систем, в которых один агент (или человек) передаёт выполнение подзадач другим агентам, инструментам или людям. Если Harness Engineering фокусируется на обвязке одного агента (инструменты, промпты, пайплайны), то Delegation Engineering решает задачу распределения работы между множеством исполнителей. Формула различия: Delegation = Harness + Coordination + Escalation + Fallback. На собеседовании важно показать понимание, что переход от одиночного агента к многоагентной системе требует принципиально иного подхода к управлению ошибками, синхронизации и эскалации.


1. Термин: Harness Engineering (обвязка агента)

Harness Engineering — это процесс создания инфраструктуры вокруг одного агента (LLM + инструменты). Включает:

  • Конфигурацию LLM (модель, температура, tokens|max tokens);
  • Подключение инструментов (поиск, калькулятор, API);
  • Формирование системного промпта;
  • Логику повторных попыток (retry) и обработки ошибок;
  • Мониторинг и логирование.

Пример: Одиночный RAG-агент с инструментом "поиск по базе знаний" — это продукт Harness Engineering.

2. Термин: Delegation Engineering (делегирование)

Delegation Engineering — это проектирование системы, в которой агент (назовём его супервайзер) не выполняет всю работу сам, а распределяет подзадачи между специализированными исполнителями (агентами, людьми, внешними сервисами). Ключевые элементы:

  • Координация: кто, кому, когда и в каком порядке передаёт задачу.
  • Эскалация: что делать, если исполнитель не может справиться.
  • Fallback: аварийные сценарии (таймауты, отказы).

Математически: Delegation = Harness + Coordination + Escalation + Fallback, где Harness — обвязка каждого отдельного агента-исполнителя.

3. Сравнение Harness Engineering и Delegation Engineering

ИзмерениеHarness EngineeringDelegation Engineering
ФокусОдин агентМножество агентов (или агент + люди)
УправлениеКонфигурация, инструменты, промптыОркестрация, маршрутизация, контракты
ОшибкиRetry, fallback для одного вызоваЭскалация, перераспределение, человеко-в-цикле
МасштабированиеУлучшение одного агента (fine-tuning, больше инструментов)Добавление новых исполнителей, динамическая маршрутизация
СложностьЛинейная относительно числа инструментовКвадратичная (N агентов → N² возможных взаимодействий)
МетрикиТочность ответа, latencyПропускная способность (throughput), доля успешных делегирований, время эскалации

4. Когда нужно Delegation Engineering

  • Многоагентные системы (Multi-Agent Systems): несколько LLM-агентов с разными ролями (исследователь, редактор, критик).
  • Человеко-агентное взаимодействие (Human-in-the-Loop): агент делегирует пользователю подтверждение (например, удалить файл).
  • Интеграция с внешними сервисами (API, базы данных, legacy-системы): делегирование задач с разными SLA.
  • Иерархические архитектуры: супервайзер распределяет подзадачи между подчинёнными агентами (например, в автономных автомобилях или робототехнике).

5. Компоненты Delegation Engineering

5.1 Harness (обвязка каждого исполнителя)

Каждый агент-исполнитель должен быть подготовлен к работе: модель, инструменты, промпт, лимиты. Без качественного Harness агент не сможет корректно выполнить делегированную задачу.

5.2 Coordination (координация)

Определяет кто, кому, что передаёт. Паттерны:

  • Линейная цепочка: агент A → B → C.
  • Иерархическая: супервайзер → менеджеры → исполнители.
  • Веерная: один агент отправляет одну задачу всем исполнителям, собирает результаты.
  • Динамическая: агент сам выбирает исполнителя на основе профиля (навыки, загрузка).

5.3 Escalation (эскалация)

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

  • По времени (timeout).
  • По качеству (confidence ниже порога).
  • По исключениям (exception в коде).

5.4 Fallback (аварийный сценарий)

Что делать, если вся цепочка делегирования не сработала:

  • Выдать дефолтный ответ ("не могу ответить").
  • Использовать упрощённую модель (например, только retrieval без агента).
  • Переключиться на другого провайдера (если API недоступен).

6. Пример реализации делегирования (Python-псевдокод)

# Агент-супервайзер
class SupervisorAgent:
    def __init__(self):
        self.harness = Harness(model="gpt-4", tools=[...])
        self.registry = AgentRegistry()  # список доступных исполнителей

    def handle_request(self, query: str) -> str:
        # Анализ запроса, разбиение на подзадачи
        subtasks = self.planner.plan(query)
        results = []
        for task in subtasks:
            executor = self.registry.select(task.type)  # Coordination
            try:
                result = executor.run(task, timeout=10)
                results.append(result)
            except TimeoutError:
                # Escalation
                result = self.human_handler(task)
                results.append(result)
            except Exception:
                # Fallback
                results.append("[fallback] не удалось выполнить")
        return self.aggregator.merge(results)

7. Отличия в метриках

МетрикаHarness EngineeringDelegation Engineering
AccuracyДоля правильных ответов агентаДоля задач, успешно делегированных и выполненных
LatencyВремя ответа одного агентаОбщее время от запроса до завершения всех делегаций
ThroughputЗапросов в секунду на одного агентаЗапросов в секунду по системе (учитывая параллелизм)
Escalation rateНеприменимоДоля задач, ушедших на эскалацию

8. Плюсы и минусы Delegation Engineering

Плюсы

  • Масштабируемость: можно добавлять новых исполнителей.
  • Специализация: каждый агент отвечает за свою область (меньше ошибок).
  • Отказоустойчивость: падение одного агента не обрушивает всю систему.
  • Прозрачность: можно логировать каждый шаг делегирования.

Минусы

  • Высокая сложность проектирования (координация, deadlock'и).
  • Дополнительная задержка на коммуникацию между агентами.
  • Сложность тестирования (много состояний).
  • Необходимость в качественном контракте между агентами (формат ввода/вывода).

9. Пет-проект для закрепления

Задача Построить систему для ответов на юридические вопросы, состоящую из трёх агентов:

  • Ретривер: ищет статьи законов.
  • Анализатор: извлекает релевантные нормы.
  • Формулировщик: пишет ответ для пользователя.

Инструменты

  • LangChain / CrewAI (или кастомная реализация на Python + FastAPI).
  • Векторная БД (Chroma).
  • LLM: OpenAI API или local (Llama 3).

Шаги:

  1. Реализовать Harness для каждого агента (промпты, инструменты).
  2. Написать супервайзер-агента, который принимает запрос, решает, кому какую часть делегировать.
  3. Добавить эскалацию: если Анализатор не уверен (conf < 0.7), запрашивает подтверждение у человека.
  4. Fallback: если Ретривер ничего не нашёл, вернуть "Вопрос не относится к известным законам".

Ожидаемый результат

  • Система отвечает на сложные вопросы, распределяя работу между агентами.
  • Логи показывают цепочку делегирования.
  • Можно измерить escalation rate и latency.

10. Связь с другими вопросами

ВопросТема
751Что такое Agentic RAG?
752Как спроектировать multi-agent систему?
753Что такое Tool Use (вызов инструментов) в контексте LLM?
754Что такое Human-in-the-Loop в RAG?
755Как организовать отказоустойчивость в многоагентных системах?
759Что такое Supervisor Agent и как он работает?

11. Навигация


Навигация