Planning vs Reactive Agents: у чому різниця

Planning agents і reactive agents часто виглядають як конкуренти, але на практиці це два режими керування агентною поведінкою. Planning підхід робить акцент на явному плані, reactive підхід — на швидкій адаптації до поточного стану.

Порівняння за 30 секунд

Planning agents — це підхід, де агент спочатку будує план (етапи, порядок, критерії завершення), а потім виконує його з контрольованими корекціями.

Reactive agents — це підхід, де агент приймає наступний крок у runtime без довгого upfront-плану: observe → decide → act.

Головна різниця: planning підхід оптимізує узгодженість довгих задач, reactive підхід оптимізує швидку реакцію на зміну контексту.

Практичне правило: якщо задача довга і вимагає передбачуваної послідовності дій — частіше виграє planning. Якщо задача коротка, динамічна і сильно залежить від "що сталося щойно" — частіше виграє reactive.

Таблиця порівняння

Головна архітектурна відмінність — де приймається основне керуюче рішення: до старту виконання чи на кожному кроці в runtime.

Архітектурна різниця

Planning agents будуються навколо явного плану і контролю виконання етапів. Reactive agents будуються навколо циклу швидких рішень на основі поточного стану.

Інженерна аналогія: Planning — це маршрут із чекпойнтами, який можна перевірити перед стартом.
Reactive — це керування в реальному часі, де наступний маневр залежить від поточної ситуації на дорозі.

У такій схемі сильна сторона — передбачуваність довгого маршруту. Слабка — ризик застарілого плану.

У такій схемі сильна сторона — адаптивність у runtime. Слабка — складніше тримати довгострокову стратегію.

Що таке Planning Agents

Planning agents — це підхід, у якому агент спочатку формує план задачі, а потім виконує кроки з явною перевіркою прогресу.

Типовий потік:

request → create plan → validate → execute steps → replan (за потреби) → finalize

Приклад ідеї Planning Agents (псевдокод)

Нижче ілюстрація логіки, а не буквальний API.

KNOWN_STEP_STATUSES = {"done", "blocked", "failed", "needs_replan"}

def run_planning_agent(request):
    state = init_state(request, max_steps=20, max_replans=3, budget_usd=1.4)
    plan = planner.create_plan(request)

    if not validate_plan(plan, max_steps=state.max_steps):
        return fail("invalid_plan")

    step_idx = 0
    replans = 0

    # Глобальний timeout виконання і watchdog — на рівні інфраструктури.
    while step_idx < len(plan.steps) and state.cost_usd < state.budget_usd:
        step = plan.steps[step_idx]

        verdict = policy.check(step)
        if verdict == "deny":
            return fail("policy_denied")

        if verdict == "needs_approval":
            if not wait_for_human_approval(state.trace_id, timeout_sec=120):
                return fail("approval_timeout")

        result = executor.run(step, timeout_sec=10, retries=1)
        if result.status not in KNOWN_STEP_STATUSES:
            emit_trace(state.trace_id, step, "unknown_step_status")
            return fail("unexpected_step_response")

        emit_trace(state.trace_id, step, result.status)

        if result.status == "failed":
            return fail("step_failed")

        if result.status == "needs_replan":
            replans += 1
            if replans > state.max_replans:
                return fail("replan_limit_exceeded")

            plan = planner.replan(state, failed_step=step)
            if not validate_plan(plan, max_steps=state.max_steps):
                return fail("invalid_replan")

            # Після replanning запускаємо новий план із початку; цикл обмежений max_replans.
            # max_steps обмежує довжину одного плану; сумарний верхній поріг кроків залежить від replanning
            # (зазвичай оцінюють як max_steps * (max_replans + 1)).
            step_idx = 0
            continue

        if result.status == "blocked":
            return fail("blocked_without_recovery")

        state = observe(state, step, result)
        step_idx += 1

    if state.cost_usd >= state.budget_usd:
        return fail("budget_exceeded")

    if step_idx < len(plan.steps):
        return fail("step_limit_or_incomplete")

    return finalize(state)

Сильна сторона planning підходу — керованість довгих задач. Слабка сторона — якщо план слабкий або застарів, помилки масштабуються на кілька кроків вперед.

Що таке Reactive Agents

Reactive agents — це підхід, у якому агент не тримає довгий фіксований план, а вирішує наступний крок за поточним станом.

Типовий потік:

request → observe → decide next action → act → observe

Приклад ідеї Reactive Agents (псевдокод)

Нижче ілюстрація логіки, а не буквальний API.

KNOWN_ACTION_STATUSES = {"ok", "blocked", "failed", "no_op"}

def run_reactive_agent(request):
    state = init_state(request, max_steps=16, budget_usd=0.9)

    # Глобальний timeout циклу і watchdog — на рівні інфраструктури.
    while state.step < state.max_steps and state.cost_usd < state.budget_usd:
        action = reactive_policy.decide(state)

        if action.type == "final":
            return finalize(state)

        verdict = policy.check(action)
        if verdict == "deny":
            return fail("policy_denied")

        # Approval стоїть до ризикової дії, щоб не створювати окремий approved_retry-контур після blocked.
        if verdict == "needs_approval":
            if not wait_for_human_approval(state.trace_id, timeout_sec=90):
                return fail("approval_timeout")

        result = tool_gateway.call(action, timeout_sec=8, retries=1)
        if result.status not in KNOWN_ACTION_STATUSES:
            emit_trace(state.trace_id, action, "unknown_action_status")
            return fail("unexpected_action_response")

        emit_trace(state.trace_id, action, result.status)

        if result.status == "failed":
            return fail("action_failed")

        if result.status == "blocked":
            # blocked тут означає зовнішнє блокування виконання, а не відсутнє approval.
            return fail("blocked_without_recovery")

        # Статус no_op не завершує цикл: зупинка контролюється max_steps/budget/explicit final.
        # observe/state update має оновлювати step, щоб жоден retry-шлях не обходив лічильник.
        state = observe(state, action, result)

    if state.step >= state.max_steps:
        return fail("step_limit_exceeded")

    if state.cost_usd >= state.budget_usd:
        return fail("budget_exceeded")

    return finalize(state)

Сильна сторона reactive підходу — швидка адаптація до змін. Слабка сторона — без жорстких меж цикл легко перетворюється на дорогий і шумний перебір кроків.

Коли використовувати Planning Agents

Planning agents підходять, коли сценарій довгий, структурований і критичний до порядку кроків.

Підходить

Коли використовувати Reactive Agents

Reactive agents підходять, коли середовище часто змінюється і важлива швидка локальна реакція.

Підходить

Недоліки Planning Agents

Planning підхід додає передбачуваність, але має власні ризики у динамічному середовищі.

Недоліки Reactive Agents

Reactive підхід гнучкий, але без дисципліни швидко переходить у нестабільний цикл.

На практиці часто працює гібридний підхід

Поширений сценарій з практики: автоматизація support-операцій у SaaS стартувала як реактивний агент.

На старті reactive контур добре працював для коротких задач: перевірити статус, дістати дані, відповісти або виконати одну дію.

Потім зʼявилися тригери для додавання planning-шару:

• enterprise-звернення вимагали довгого маршруту з кількома залежностями
• зросла кількість інцидентів, де локально правильні кроки не давали правильної кінцевої дії
• комплаєнс попросив явну трасу: чому саме цей порядок кроків був обраний

Що лишили в reactive контурі:

• короткі операційні дії з швидким зворотним звʼязком
• runtime-адаптацію після відповідей зовнішніх API
• дешевий шлях для масових "швидких" запитів

Що винесли у planning-шар:

• побудову етапного маршруту для довгих кейсів
• валідацію плану перед стартом виконання
• ліміти replanning і явні критерії завершення (criteria of done)

Чому це спрацювало:

• короткі задачі залишились швидкими
• довгі задачі стали передбачуванішими і краще дебажились
• команда не переписувала весь контур, а ізолювала лише сценарії з довгим горизонтом рішень

Коротко

FAQ

Q: Що обирати першим: planning чи reactive?
A: Часто стартують з reactive для швидкого запуску. Але для high-risk або auditable сценаріїв planning може бути стартовим вибором.

Q: Коли reactive підхід уже не тягне?
A: Коли одночасно видно три сигнали: зростає довжина сценаріїв, частішають інциденти "кроки були логічні, результат — ні", і дебаг вимагає відновлювати десятки дрібних рішень без явного плану.

Q: Коли planning — це overengineering?
A: Коли більшість трафіку — короткі динамічні задачі, а команда витрачає більше часу на побудову і підтримку планів, ніж на реальну цінність для користувача.

Q: Чи можна комбінувати planning і reactive в одній системі?
A: Так, і це найпрактичніший шлях. Часто planning керує "скелетом" довгого процесу, а reactive виконує окремі кроки, які залежать від поточного стану.

Q: Які сигнали, що пора додавати planning-шар?
A: Практичні сигнали: повторювані збої в середині довгих маршрутів, часті ручні втручання для виправлення порядку кроків, вимоги комплаєнсу до пояснюваної послідовності рішень.

Q: Який мінімальний контроль потрібен в обох підходах?
A: Для planning мінімум: валідація плану, ліміти replanning, критерії завершення (criteria of done), policy checks по етапах, аудит відхилень. Для reactive мінімум: бюджети, stop conditions, policy checks на кожному кроці, памʼять стану, idempotency і трейсинг.

Пов’язані порівняння

Якщо ви обираєте архітектуру агентної системи, ці сторінки також допоможуть:

• LLM Agents vs Workflows — коли потрібен агентний цикл, а коли достатньо workflow.
• Single-Agent vs Multi-Agent — один контур рішень проти координації кількох агентів.
• OpenAI Agents vs LangGraph — керований runtime проти явного graph-контролю переходів.
• LangChain vs LangGraph — компоненти проти формалізованого графа станів.
• RAG vs Agents — knowledge-pipeline проти decision loop.