中文翻译暂不可用,显示俄语原文。
Что такое 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 Engineering | Delegation 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 Engineering | Delegation Engineering |
|---|---|---|
| Accuracy | Доля правильных ответов агента | Доля задач, успешно делегированных и выполненных |
| Latency | Время ответа одного агента | Общее время от запроса до завершения всех делегаций |
| Throughput | Запросов в секунду на одного агента | Запросов в секунду по системе (учитывая параллелизм) |
| Escalation rate | Неприменимо | Доля задач, ушедших на эскалацию |
8. Плюсы и минусы Delegation Engineering
Плюсы
- Масштабируемость: можно добавлять новых исполнителей.
- Специализация: каждый агент отвечает за свою область (меньше ошибок).
- Отказоустойчивость: падение одного агента не обрушивает всю систему.
- Прозрачность: можно логировать каждый шаг делегирования.
Минусы
- Высокая сложность проектирования (координация, deadlock'и).
- Дополнительная задержка на коммуникацию между агентами.
- Сложность тестирования (много состояний).
- Необходимость в качественном контракте между агентами (формат ввода/вывода).
9. Пет-проект для закрепления
Задача Построить систему для ответов на юридические вопросы, состоящую из трёх агентов:
- Ретривер: ищет статьи законов.
- Анализатор: извлекает релевантные нормы.
- Формулировщик: пишет ответ для пользователя.
Инструменты
- LangChain / CrewAI (или кастомная реализация на Python + FastAPI).
- Векторная БД (Chroma).
- LLM: OpenAI API или local (Llama 3).
Шаги:
- Реализовать Harness для каждого агента (промпты, инструменты).
- Написать супервайзер-агента, который принимает запрос, решает, кому какую часть делегировать.
- Добавить эскалацию: если Анализатор не уверен (conf < 0.7), запрашивает подтверждение у человека.
- 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. Навигация
- Предыдущий: 759
- Следующий: 761
- Индекс: 00. Индекс разборов
Навигация
- Предыдущий: 759
- Следующий: 761
- Индекс: 00. Индекс разборов