Что такое planner-executor архитектура для агентов?

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

Planner-executor — это архитектура AI-агента, в которой два компонента работают в цикле: Planner (обычно LLM) генерирует высокоуровневый план, разбивая сложную задачу на шаги, а Executor (LLM или rule-based) выполняет эти шаги, используя доступные инструменты. Такая архитектура эффективна для задач с длинным горизонтом планирования (более 5 шагов), так как снижает когнитивную нагрузку на один вызов LLM и позволяет динамически перепланировать при ошибках. Основной вызов — ошибки декомпозиции и дополнительная стоимость двухэтапного процесса.

1. Эволюция архитектур AI-агентов

ReAct (Reasoning + Acting) — популярная архитектура, где агент в одном цикле генерирует мысль (thought), действие (action) и наблюдение (observation), повторяя до достижения цели. ReAct хорош для коротких цепочек (2–5 шагов), но на более длинных горизонтах страдает от накопления ошибок (error accumulation) и потери контекста. ReAct можно представить как вложенный цикл:

Thought → Action → Observation → (повтор)

Planner-executor решает эту проблему, разделяя этапы «придумывания последовательности шагов» и «выполнения». Planner работает на уровне декомпозиции задачи (task decomposition), а Executor отвечает за исполнение с проверкой (execution with verification). Это напоминает классический планировщик-робот в робототехнике, но с LLM в роли интеллектуального планировщика.

Термин горизонт задачи (task horizon) — количество шагов, необходимых для завершения задачи. При горизонте >5 ReAct часто проваливается, а planner-executor даёт более надёжный результат.

2. Компонент Planner (LLM)

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

Как работает генерация плана

• Planner использует Chain-of-Thought (CoT), чтобы разбить задачу логически.
• План может быть представлен в виде JSON-массива:

plan = [
    {"step_id": 1, "action": "search_web", "params": {"query": "температура в Москве"}},
    {"step_id": 2, "action": "parse_weather", "params": {"source": "step_1"}},
    {"step_id": 3, "action": "respond", "params": {"format": "text"}}
]

• План может быть линейным (step 1 → step 2 → …) или условным (с ветвлением, если executor возвращает ошибку).

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

Planner -> План -> Executor -> Результат -> Planner (анализ) -> новый План -> ...

Способы улучшения Planner

• Few-shot промпты с примерами удачных планов.
• Self-consistency — генерация нескольких планов и выбор наиболее консистентного.
• Re-planning trigger — порог «уверенности» Executor'а (например, если оценка качества выполнения шага < 0.7).

Термин декомпозиция задачи (task decomposition) — процесс разбиения задачи на подзадачи, которые можно выполнить независимо или последовательно.

3. Компонент Executor (LLM или rule-based)

Executor — это компонент, который берёт один шаг из плана и выполняет его. Executor может быть:

• LLM с вызовом инструментов (tool‑using LLM) — для шагов, требующих генерации текста, summarization, reasoning.
• Rule-based скриптом — для чётких действий (поиск в БД, выполнение кода, API-запрос), где LLM излишен.

Типичный цикл работы Executor'а

1. Получает шаг плана.
2. Вызывает соответствующий инструмент (если нужно) или генерирует ответ.
3. Возвращает результат (наблюдение) обратно Planner'у.

Executor может также сообщать о статусе: success, error, partial — это помогает Planner'у принимать решение о перепланировании.

Пример: Planner сгенерировал шаг search_web("погода в Москве"). Executor:

• Вызывает API поиска.
• Получает HTML.
• Извлекает текст.
• Возвращает {"status": "success", "data": "температура -5°C"}.

Если API упал, Executor возвращает {"status": "error", "message": "timeout"} → Planner решает повторить с задержкой или использовать другой инструмент.

Термин инструмент (tool) — внешняя функция (API, база данных, калькулятор, код-интерпретатор), доступная агенту.

4. Основной цикл — Loop

Взаимодействие Planner и Executor образует цикл:

1. Planner генерирует начальный план (или берёт из кэша).
2. Executor выполняет первый шаг.
3. Результат передаётся Planner.
4. Planner оценивает результат:
   - если успех → переходит к следующему шагу (или завершает);
   - если ошибка → перепланирует (изменяет/добавляет шаги).
5. Повторяется до достижения условия завершения.

Условия завершения

• Все шаги выполнены успешно.
• Planner решает, что задача решена (может запросить у LLM оценку).
• Достигнуто максимальное количество итераций (для защиты от бесконечных циклов).

Пример на Python (псевдокод):

class PlannerExecutorAgent:
    def __init__(self, planner_llm, executor_llm, tools):
        self.planner = planner_llm
        self.executor = executor_llm
        self.tools = tools

    def run(self, user_query):
        plan = self.planner.generate_plan(user_query)
        results = []
        for step in plan:
            observation = self.executor.execute(step, self.tools)
            results.append(observation)
            if observation['status'] == 'error':
                plan = self.planner.replan(user_query, plan, results)
        return results[-1]['data']  # финальный ответ

5. Преимущества перед ReAct

Planner-executor выбирают, когда точность важнее скорости, а задача требует многошагового рассуждения с внешними проверками.

6. Недостатки и вызовы

• Ошибки декомпозиции: Planner может разбить задачу неоптимально или пропустить важный шаг. Например, для вопроса «Что такое гравитационная постоянная?» Planner может сделать шаг «поискать в Википедии» и забыть уточнить единицы измерения.
• Избыточная стоимость: Два вызова LLM на шаг (planner + executor) дороже, чем один ReAct-вызов. Если шагов 10, то получаем 20 вызовов вместо 10.
• Latency: Planner часто использует более мощную (и медленную) модель, executor — более лёгкую. При большом количестве шагов общее время может быть неприемлемым.
• Зацикливание: Если Planner постоянно перепланирует из-за мелких ошибок, возникает бесконечный цикл. Нужны строгие лимиты и fallback-стратегии.
• Сложность промпт-инжиниринга: Planner нужно научить правильно декомпозировать, а Executor — выполнять именно то, что написано в шаге (не галлюцинировать).

7. Примеры реализации

7.1 Plan-and-Solve (PS)

Paper: "Plan-and-Solve: Improving Zero-Shot Chain-of-Thought Reasoning by Planning" (Wang et al., 2023).
Идея: Модель сначала генерирует план (последовательность этапов), затем последовательно их выполняет. Без обратной связи — это упрощённая версия planner-executor.

7.2 HuggingGPT

Идея: LLM (Planner) анализирует запрос и составляет план использования моделей из Hugging Face Hub. Executor (также LLM) запускает каждую модель и возвращает результат. Planner затем объединяет результаты в ответ.

7.3 BabyAGI

Идея: Planner (LLM) генерирует список задач и добавляет их в очередь. Executor (LLM + инструмент) берёт задачу из очереди, выполняет и ставит результат. Planner динамически создаёт новые задачи на основе результатов. Это классический пример planner-executor с очередью.

7.4 AutoGPT

Идея: AutoGPT использует одну LLM в режиме «thought → action», но дополнительно включает «планировщик» (plan step), который пересматривает общий план после каждого действия. Фактически, это гибрид ReAct и planner-executor.

8. Когда выбирать planner-executor

• Длинные задачи (написание статьи, исследование темы, автоматизация многоэтапного рабочего процесса).
• Требуется высокая точность (юридические или медицинские консультации, где каждый шаг критичен).
• Доступно несколько мощных LLM — можно выделить дорогой Planner для стратегии и дешёвый Executor для тактики.
• Нужна интерпретируемость — план можно показать пользователю и запросить подтверждение.

Когда лучше не использовать:

• Задачи с одним чётким действием (например, перевод текста — хватит одного вызова LLM).
• Реальное время (низкая latency критична).
• Нет бюджета на два LLM-вызова на шаг.

9. Интеграция с инструментами

Executor обычно работает в tool-use окружении (function calling). Пример интеграции:

tools = {
    "search": lambda q: external_search(q),
    "code": lambda code: run_python(code),
    "calc": lambda expr: eval(expr)
}

def executor_step(step):
    action = step["action"]
    params = step["params"]
    if action in tools:
        return tools[action](**params)
    else:
        return {"status": "error", "message": "unknown tool"}

Planner должен знать список доступных инструментов (через системный промпт). Обычно описание инструментов включается в контекст Planner'а с примерами использования.

10. Оценка архитектуры

Метрики для planner-executor:

• Успешность выполнения плана (Plan Success Rate, PSR): доля запросов, где все шаги выполнены без ошибок и финальный ответ корректен.
• Среднее число шагов (Average Steps) — показатель эффективности планировщика.
• Среднее число перепланирований (Average Replans) — чем меньше, тем лучше Planner.
• Корректность декомпозиции (Decomposition Accuracy) — оценивается вручную или через LLM-as-judge (например, GPT-4 оценивает, правильно ли разбита задача).
• Отзывчивость на ошибки — насколько быстро и правильно Planner исправляет план при сбое Executor'а.

Для автоматизации оценки можно использовать RAGAS-подобные фреймворки, адаптированные для агентов (например, AgentBench).

11. Современные варианты и улучшения

• LLMCompiler (Kwon et al., 2024): планировщик на основе графа, где шаги могут выполняться параллельно. Planner генерирует DAG, Executor выполняет вершины графа с учётом зависимостей. Это повышает скорость.
• Tree-of-Thoughts (ToT): Planner генерирует дерево возможных планов, Executor оценивает каждый путь, Planner выбирает лучший. Комбинация поиска по дереву с LLM.
• Self-Refine: Executor выполняет шаг, затем Planner/Refiner предлагает улучшения. Цикл повторяется до сходимости.
• Modular RAG (например, RAPTOR): Planner строит иерархию подзадач, Executor запускает retrieval и генерацию для каждой. Применяется в сложных RAG-сценариях.

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

Задача: Разработать агента planner-executor для организации дня (планировщик задач).

• Инструменты: Python, библиотека openai (или anthropic), requests, простой веб-скрейпинг (например, requests + BeautifulSoup).

• Шаги:

  1. Создайте Planner (LLM, например, GPT-4o-mini), который принимает запрос «Запланируй мой день: купить подарок другу, написать отчёт, позвонить в банк» и выводит план в JSON.
  2. Создайте Executor (вторая LLM, например, gpt-4o-mini), который выполняет один шаг (например, «Поискать идеи подарков» вызывает поиск в интернете; «Написать отчёт» генерирует текст).
  3. Реализуйте цикл с проверкой ошибок (если поиск не дал результатов → Planner добавляет шаг «Уточнить запрос»).
  4. Добавьте возможность пользователя корректировать план через диалог.
  5. В конце – генерация итогового расписания.

• Ожидаемый результат: Агент выводит последовательность шагов с результатами (например, «Шаг 1: Поиск идей подарков → Нашёл 5 вариантов; ... Шаг 4: Завершение — расписание дня»).

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

14. Навигация

• Предыдущий: 890
• Следующий: 892
• Индекс: 00. Индекс разборов

Навигация

• Предыдущий: 890
• Следующий: 892
• Индекс: 00. Индекс разборов