Перейти к основному содержимому

Workflow orchestration

После главы вы сможете решить, где control flow должен оставаться детерминированным, а где модели действительно нужен выбор следующего шага.

Надёжная система гибридна

LLM не обязана решать authentication, rate limits, ledger invariants или queue delivery. Agent loop полезен внутри ограниченного участка, где path зависит от языка и новых observations.

Основные patterns

Sequential

Шаг B зависит от validated output A. Просто наблюдать и retry, но latency складывается.

Routing

Classifier/rule/model выбирает один специализированный path. Нужны fallback и eval routing confusion, иначе ошибочный первый выбор скрыто определит весь результат.

Parallel fan-out/fan-in

Подходит независимым reads, нескольким graders или поиску по независимым источникам. Не запускайте параллельно конфликтующие writes без coordination и idempotency.

Evaluator–optimizer

Один шаг создаёт candidate, другой проверяет против rubric, цикл ограничен budget. Полезно, когда feedback конкретен; бесполезно, если evaluator повторяет вкус generator.

Planner–executor

Plan помогает декомпозиции, но не является authority или гарантией. Executor проверяет каждое действие по текущему state; после новых facts plan version обновляется явно.

Human gate

Run сохраняет exact pending operation и ждёт approve/edit/reject. После resume модель не должна заново угадывать, что одобрил человек.

Динамический agent или workflow?

ПризнакWorkflowBounded agent
Ветки известныДаНе полностью
Цена ошибкиВысокаяДопустима внутри guardrails
Feedback machine-readableОбычноОбязательно желательно
Нужна explorationМалоМного
Нужен auditПростоТребует event vocabulary
Latency/costПредсказуемееБолее вариативны

Если agent всегда вызывает tools в одном порядке, закрепите порядок кодом. Если workflow разрастается тысячами brittle intent branches, bounded agent может упростить semantic routing.

Framework choice

ПодходВыигрышЦенаПлохой выбор
Plain code loopПрозрачно, легко учитьСами timers/storage/retryLong-running production
Graph/state-machine libraryЯвные узлы/веткиFramework state semantics2–3 простых шага
Durable workflow engineTimers, workers, replayDeterminism/deployment overheadShort synchronous chat
Queue + custom workersПолный контрольМного инфраструктурного кодаКоманда без ops capacity

Названия вроде LangGraph и Temporal относятся к implementation choices. Публичные контракты курса — ModelPort, StateStore, PolicyEngine, RunEvent — не названы в честь provider/framework.

Parallelism и consistency

Перед fan-out определите:

  • независимы ли inputs;
  • какой shared state читается;
  • может ли один branch сделать side effect;
  • как отменить остальные после достаточного ответа;
  • как агрегировать partial failures;
  • есть ли per-branch и total budget.

Parallel model calls увеличивают test-time compute и могут повысить качество на некоторых задачах, но также стоимость. Проверяйте gain на eval set, не добавляйте voting по эстетике.

Planning state

Хороший plan хранит:

  • версию и goal;
  • шаги/зависимости;
  • evidence, на котором основан;
  • выполненные outcomes;
  • invalidated assumptions;
  • условие re-plan.

Плохой plan — длинный assistant text, который невозможно сопоставить events и postconditions.

Helios и реальный аналог

Запрос «почему груз задержан?» идёт bounded agent: нужно исследовать order, customs и carrier. Refund идёт fixed workflow: calculate eligibility → preview → approval → idempotent commit. В telehealth triage safety routing остаётся policy workflow, а conversational clarification может использовать model.

Multi-agent — escalation, не default

Отдельный agent оправдан, если есть хотя бы одно:

  • независимый context/tool boundary;
  • параллельное исследование с измеримым ускорением;
  • отдельная security/tenant authority;
  • специализация, доказанная evals.

Иначе появляются handoff loss, duplicate work, conflicting writes, больше tokens и сложнее causality. Начните с одного loop и обычных functions.

Лаборатория

Сравните минимальный AgentRuntime и DurableExecution:

npm run test:course:pattern -- "bounded loop|approval"

Нарисуйте Helios refund как deterministic workflow. Отметьте единственный участок, где model choice действительно полезен.

Failure modes

  • Agent управляет KYC/ledger invariant.
  • Router не имеет fallback и confidence/abstain.
  • Parallel branches делают конфликтующие writes.
  • Planner меняет согласованный scope.
  • Human gate хранит только «approved=true» без exact operation.
  • Framework checkpoint ошибочно считают domain idempotency.
  • Multi-agent введён до single-agent eval baseline.

Self-check

  • Какие ветки можно выразить обычным кодом?
  • Какой feedback делает динамический выбор полезным?
  • Где durable wait и resume?
  • Какие операции нельзя parallelize?
  • Как план связывается с events?
  • Как eval доказывает необходимость agent/multi-agent complexity?

Источник

Provider guidance, проверено 2026-08-30: patterns workflow/agent и рекомендация начинать с простого решения описаны в Anthropic Building effective agents. Используйте как каталог patterns, не как framework standard.