Оркестрация multi-agent: пять паттернов и когда выигрывает один

Португальская компания пишет насчёт инвойса FT-2026-0918. В письме сказано, что VAT выглядит неверно, и приложен инвойс: net EUR 248.00, VAT начислен по ставке 21 %, EUR 52.08, total EUR 300.08.

Факты, нужные для ответа, находятся в трёх местах, и только одно из них — в письме:

Сложите эти три факта, и инвойс неверен: должен применяться reverse charge, VAT должен быть нулевым, клиенту положена кредит-нота на EUR 52.08. Посмотрите только на инвойс — и он арифметически идеален: 248.00 плюс 52.08 равно 300.08, — так вы и скажете.

В письме действительно сказано: «мы португальская компания». Это утверждение, а не запись в системе, и ни одна billing system не выпускает кредит-ноту на основании утверждения. Ловушка не в трюке: это обычная форма бизнес-работы, где для решения нужен факт, который никто не догадался получить.

Всё выше запускается против scripted provider в стиле главы 23, с ровно одним правилом:

Ответ может использовать только факт, который есть в его prompt.

«Модель» запрашивает каждый доступный ей инструмент один раз, в порядке каталога, а затем применяет фиксированное правило к тексту, который видит. Ничего не scripted отдельно для конкретной схемы, поэтому различия в начальной таблице — не утверждения об интеллекте модели: это измеренный routing информации. Реальная модель добавляет поверх свои собственные сбои; она не устраняет эти.

Пять названий ниже — антропиковские, из Building effective agents, где этот словарь и закрепился.¹ Ни одна из пяти идей не нова, а сказать, какая школа как что назвала — и какая идея старше, — половина пользы от их знания.

/* 1. Prompt chaining: a fixed pipeline. The control flow is yours. */
export async function chain(steps: Step[], first: string) {
  let carry = first, all = first;
  for (const s of steps) {
    const r = await step(s.role, s.system, s.accumulate ? all : carry);   
    carry = r.text;
    all = `${all}\n${r.text}`;
  }
  return carry;
}

/* 2. Routing: one cheap call picks the branch. The fallback is not a model. */
export async function route<T>(input: string, classify: Classifier,
                               routes: Record<string, Branch<T>>, fallback: Branch<T>) {
  let label: string | undefined;
  try { label = await classify(input); } catch { label = undefined; }
  return ((label && routes[label]) || fallback)(input);                    
}

/* 3. Parallelisation. The pattern IS this line. */
export const parallel = <T>(workers: Branch<T>[], input: string) =>
  Promise.all(workers.map((w) => w(input)));                              

/* 4. Orchestrator-workers: an agent behind a tool. Chapter 18's interface, unchanged. */
export function agentTool(o: WorkerSpec): Tool {
  return {
    name: o.name, description: o.description, readOnly: true,
    parameters: { type: "object", properties: { question: { type: "string" } } },
    async run(args: { question: string }) {
      const child = newRun(o.system, args.question);          // its own window
      await runTracked(child, o.tools, o.usage);              // its own limits
      const conclusion = child.output ?? "no result";
      if (!o.carryFindings) return conclusion;                             
      return `${conclusion}\nFINDINGS ${evidence(child)}`;                 
    },
  };
}

/* 5. Evaluator-optimiser: make, judge, remake. Rounds are calls. */
export async function refine(make: Make, judge: Judge, maxRounds: number) {
  let draft = "", feedback: string | undefined;
  for (let r = 1; r <= maxRounds; r++) {
    draft = (await make(feedback)).text;
    const j = await judge(draft);
    if (j.ok) return { draft, rounds: r };
    feedback = j.note;
  }
  return { draft, rounds: maxRounds };
}

Это весь toolkit: пять функций, никакого framework, а параллельная — одна строка; именно поэтому её стоит выписать, а не рисовать. Теперь по очереди: происхождение, цена и случай, где она ошибается.

Prompt chaining «разбивает задачу на последовательность шагов, где каждый вызов LLM обрабатывает output предыдущего».¹ Идея старше языковых моделей: это pipeline, с обычной сделкой pipeline — ясность в обмен на control flow, зафиксированный до прихода данных.

Для нашей задачи четыре шага: извлечь поля инвойса, проверить арифметику, решить, что причитается, написать ответ. Здесь он ломается двумя разными способами, и это учит большему, чем один сбой.

--- relay: each step sees only the previous step's output
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 vat_amount=52.08 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=unknown reason=no_invoice_in_context
draft:   "we are looking into invoice FT-2026-0918 and will come back to you."

--- accumulating: each step sees the email and everything produced so far
extract: FIELDS invoice_id=FT-2026-0918 net=248.00 vat_rate_applied=21 ...
check:   ARITHMETIC ok 248.00+52.08=300.08
decide:  VERDICT=invoice_correct reason=net_248.00_plus_21pct_vat_52.08_equals_300.08
draft:   "we have checked FT-2026-0918 and it is correct... Nothing is owed back."

Relay chain стоила $0.001940 и потеряла поля инвойса между вторым и третьим шагами, потому что третьему шагу передали предложение об арифметике и ничего больше. Она выдала holding message: бесполезный и явно бесполезный.

Accumulating chain — строка в начальной таблице — стоила $0.003780, то есть на 95 % больше за четыре идентичных вызова, потому что теперь каждый шаг несёт всё, что было до него. Она выдала опасный output. Беглый, с ссылкой на арифметику, правильный по каждому числу, которое упоминает, и сообщающий клиенту, что ничего не причитается, хотя причитается EUR 52.08.

Разница между ними — один ternary. Цепочка, которая несёт меньше, даёт ответы, очевидно неполные; цепочка, которая несёт всё, даёт ответы уверенно неверные — и отправляют только второй тип.

Но ни то ни другое не является настоящим сбоем. Настоящий сбой в том, что pipeline ещё до чтения решил: эта задача — четыре шага над содержимым письма. В этой структуре нет места, где можно сказать: «страны регистрации нет в этом письме; сходи и получи её». Chaining подходит, когда decomposition заранее известна и стабильна. Здесь это была догадка, и догадку отправили.

Routing «классифицирует input и направляет его в специализированную follow-up задачу».¹ Название новое; механизм — dispatcher, старше почти всего остального в этой книге. Новое в том, что classifier может быть моделью — и именно поэтому он ломается способами, которые switch никогда не знал.

const answer = await route(email,
  (q) => classifyWithSmallModel(q),          // cheap model, one call
  { billing: billingAgent, tax: taxAgent, dunning: dunningAgent },
  taxAgent,                                  // deterministic, chosen in advance
);

Две вещи о последнем аргументе. Это не error handling; это и есть паттерн. У router на базе модели есть failure mode, которого нет у dispatcher: он может вернуть label, которого не существует, уйти в timeout или — дорогой вариант — вернуть правдоподобный неверный label без сигнала, что он неверен. Все три должны куда-то приземлиться, и этим «куда-то» не может быть ещё один вызов модели, потому что вы уже в ветке, где вызовы модели отказали.

Вторая вещь: собственный prompt router не бесплатен. Чтобы выбрать модель, router нужен каталог моделей на выбор, и каждая запись в нём — это input, за который он платит до того, как router прочитал вопрос пользователя. По input rate, используемому в этом курсе, каталог примерно из 3,800 tokens уже стоит столько же, сколько весь пяти-вызовной agent run из начальной таблицы. На практике routing call запускается на дешёвой модели — именно поэтому routing окупается; но арифметику стоит делать именно в эту сторону, а не предполагать. Routing ошибочен ровно тогда, когда routed task дешевле решения о routing.

Anthropic делит этот паттерн надвое: sectioning — «разбиение задачи на независимые subtasks, запускаемые параллельно», — и voting — «запуск одной и той же задачи несколько раз для получения разнообразных outputs».¹ У них общая диаграмма и почти ничего больше.

Sectioning — дешёвый выигрыш, та самая строка из patterns.ts: три специалиста — billing, tax, policy — у каждого своё окно и инструменты, все поверх одного письма, плюс один synthesis call в конце. Одна и та же работа в двух порядках:

Token в token то же самое, быстрее в 1,8 раза. Поэтому паттерн заслуживает собственного имени: он единственный из пяти улучшает что-то, ничего не добавляя к цене. Подвох в том, что секции должны быть действительно независимы: дайте секции B факт, который производит секция A, и Promise.all запустит обе против состояния, которого ещё нет. Loop for спрятал этот баг; one-liner его показывает.

Voting — другое животное в той же картинке. Запуск одного вопроса k раз и выбор большинства — это self-consistency, опубликованная Wang et al. в марте 2022 года как decoding strategy, почти за три года до того, как кто-то назвал это orchestration pattern. Аннотация точна насчёт механизма — «сначала выбирает разнообразный набор reasoning paths вместо того, чтобы брать только greedy one, а затем выбирает наиболее consistent answer, marginalizing out the sampled reasoning paths» — и насчёт выигрыша: +17.9 пункта на GSM8K.²

Отсюда следуют две вещи, которые скрывает картинка. Во-первых, voting требует sampling из главы 17: при temperature zero все k samples — один и тот же sample, а majority — один ответ, оплаченный k раз. Во-вторых, он работает только там, где большинство осмысленно: в ответе по инвойсу выше нечего считать, потому что пять drafts — это пять разных предложений. Voting — для задач с коротким, сопоставимым ответом, то есть ровно для бенчмарков Wang и почти ни для чего, что делает customer-facing agent.

Здесь это измерено на 20 трёхшаговых word problems, ответы на которые вычисляются, а не оцениваются, с локальной моделью главы 23, рассуждающей step by step:

В пять раз больше вызовов, в пять раз больше tokens, ровно в пять раз больше счёт — и ни одного дополнительного правильного ответа. Voting — ставка, а не улучшение, и этот run её проиграл.

Две оговорки, прежде чем кто-нибудь процитирует это как опровержение Wang. Двадцать trials не отличают 45 % от 60 %: интервал шириной с само утверждение, и это дисциплина главы 4, применённая к моему собственному результату. А опубликованные выигрыши пришли от моделей на порядки крупнее, где diverse reasoning paths, по которым voting marginalises, действительно разнообразны. Переносится не число, а то, что множитель точен и известен заранее, а выигрыш — нет.

В workflow orchestrator-workers «центральная LLM динамически разбивает задачи, делегирует их worker LLM и синтезирует их результаты», а отличие от sectioning в том, что «subtasks не предопределены, а определяются orchestrator».¹ Происхождение здесь вообще не из языковых моделей: это master-worker, а версия, где workers записывают findings в общее пространство, которое читает controller, — blackboard architecture из исследований распознавания речи 1970-х. Новое в 2026 году то, что controller — модель, а значит decomposition можно решать для каждого input отдельно: гибкость и цена в одном предложении.

Это стоило 12 model calls против 5 у single agent и пришло к тому же вердикту. Потом произошло нечто, на что стоит посмотреть внимательно:

orchestrator final: VERDICT=credit_note_due amount=52.08 source=worker_unverified
                  | PO_MISMATCH=yes source=worker_unverified
single agent:       VERDICT=credit_note_due amount=52.08 reason=reverse_charge_should_have_applied
                  | PO_MISMATCH=yes invoice_says=PO-4417 order_says=PO-4471

Оба ответа верны. Только один знает почему. Tax worker видел в своём окне инвойс, заказ и tax table, пришёл к выводу и ещё заметил — хотя никто не просил, — что номер purchase order в инвойсе не совпадает с номером в заказе. Затем он вернул summary. Оркестратор может повторить оба утверждения и не может проверить ни одно, потому что evidence осталось в окне, которого он не видел. Вот ответ на финальный вопрос главы 24: родитель видит то, что child решил записать.

Исправление — один flag, и у него есть цена:

На 12 % больше input tokens, на 8,3 % больше денег — и фраза source=worker_unverified исчезает из ответа. Это сделка в любой multi-agent system, и её почти никогда не проговаривают: чистое окно child полезно, способность родителя audit тоже стоит денег, и бесплатно получить оба нельзя.

Так когда orchestrator-workers неверен? Здесь, на этой задаче. Он купил правильный ответ, к которому один agent с теми же четырьмя инструментами тоже пришёл, за 1,66 раза стоимости и 2,3 раза wall clock, и сделал этот ответ труднее защищать. Собственная рекомендация Anthropic говорит то же самое ещё до паттернов: искать «самое простое возможное решение и повышать сложность только при необходимости», потому что «agentic systems often trade latency and cost for better task performance».¹ Таблицы выше — это та же фраза, но с числами под ней.

Один вызов генерирует, другой оценивает, и loop повторяется, пока evaluation не пройдена.¹ Опубликованные предки — Self-Refine, где одна и та же модель выступает как «generator, refiner, and feedback provider» и сообщает примерно о 20 пунктах absolute improvement в среднем по семи задачам³, — и Reflexion, где критика хранится в episodic buffer между попытками и сообщается 91 % pass@1 на HumanEval при baseline 80 %.⁴

Cost model здесь самый простой из пяти: два вызова на round, и число rounds не ваше. Три rounds refinement для задачи, которая занимала один вызов, — это шесть вызовов, так что floor паттерна равен 6×, а ceiling — любой cap, который вы поставите; поэтому budget exit из главы 23 обязателен, а не просто аккуратен.

Ceiling тоньше, и его можно измерить. На тех же 20 задачах локальная модель ответила правильно на 9. Затем ей показали каждый из этих ответов и спросили, верен ли он, — не сообщая, что ответ её собственный; это убирает flattery confound и оставляет capability:

Это лучший судья, чем намекает заголовок раздела, и именно поэтому нужно измерять, а не утверждать: он не заблокировал ничего верного и поймал 8 из 11 ошибок. Как фильтр он стоит своих вызовов.

Как stopping rule, то есть в той роли, для которой evaluator-optimiser loop фактически его использует, эти три одобрения — вся история: они завершают loop с неверным ответом на руках, и никакое количество дополнительных rounds до них уже не доберётся. Refinement loop не может стать правильнее своего судьи. Покупая больше rounds, вы покупаете попытки исправить ошибки, которые судья видит, по полной цене, и ровно ничего против тех, которых он не видит.

Отсюда правило: evaluator заслуживает свои вызовы только тогда, когда у него есть то, чего нет у generator. Компилятор, test suite, schema validator, другая модель, человек. Собственные результаты Self-Refine измеряются по human preference и task metrics, а не по мнению модели о самой себе. Если единственное преимущество evaluator — другой prompt, вы платите вдвое за согласие. Глава 29 строит версию с реальным преимуществом: golden set с заранее записанными ответами.

Пять пунктов выше — формы для вашего кода. Под ними есть второе семейство, которое часто перечисляют рядом с ними, хотя не должны: ReAct, Reflexion, plan-and-execute и tree of thoughts — это reasoning loops, и их стоимость выражается в requests.

Глава 12 была о reasoning внутри модели, за который вы платите output tokens в одном вызове. Здесь другой тип. Разница важна, когда приходит счёт: более длинная chain of thought делает один вызов дороже, а reasoning loop превращает одну задачу во много вызовов, каждый из которых заново отправляет всё, что было до него, — ту самую квадратичность, которую глава 23 измерила в runaway table.

Статья tree-of-thoughts публикует собственную cost table — это встречается реже, чем должно. На Game of 24 с GPT-4: input/output prompting best-of-100 решал 33 % по $0.13 за case, chain of thought best-of-100 — 49 % по $0.47, а tree of thoughts — 74 % по $0.74; авторы отмечают, что это «could require 5-100 times more generated tokens than CoT».⁷

Почти в шесть раз дороже дешёвого метода за чуть больше чем двойной success rate. Выгодная ли это сделка, зависит от того, сколько стоит failed case, — вопрос, который нужно задать до внедрения любого из этих четырёх.

Этот курс не реализует их заново. У всех четырёх есть reference implementations от собственных авторов, на Python, и их ценность в том, что это источник, а не перевод: ysymyth/ReAct, noahshinn/reflexion, princeton-nlp/tree-of-thought-llm и AGI-Edgerunners/Plan-and-Solve-Prompting. Читайте prompts в этих repositories; prompts и есть статьи.

Теперь собственно multi-agent, где живёт большая часть путаницы. Есть два способа, которыми один agent может задействовать другого; это не варианты одного и того же, и различие в том, кто после этого главный.

Agent как инструмент. Родитель вызывает его, получает ответ и продолжает. Это интерфейс инструмента из главы 18, только за ним целый agent, и родитель не теряет контроль. Именно это делает оркестратор выше.

Передача. Родитель передаёт разговор и не получает его обратно. У guide OpenAI самое ясное опубликованное описание: handoffs — это «one way transfer that allow an agent to delegate to another agent... If an agent calls a handoff function, we immediately start execution on that new agent that was handed off to while also transferring the latest conversation state».⁸

Предупреждение о словаре, потому что это постоянно сбивает людей: «handoff» — слово одного SDK, а не стандарт. Это терминология OpenAI Agents SDK и этого guide, где две схемы также названы «manager» и «decentralized» и сказано, что в manager pattern «edges represent tool calls whereas in the decentralized pattern, edges represent handoffs».⁸ В этой области есть открытый стандарт — A2A, версия 1.0.0, под copyright Linux Foundation, с версионированной release history и документированным списком breaking changes; его заявленный принцип — opaque execution: agents «collaborate based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations».⁹ Это не handoff, и сравнение относится к главе 26. Здесь важно, что одно из двух слов — API библиотеки, а другое — спецификация с governance.

Различие — это структура данных, а не диаграмма:

export type EdgeKind = "tool" | "handoff";
export interface AgentEdge { from: string; to: string; kind: EdgeKind }
export interface AgentGraph { root: string; agents: Record<string, AgentSpec>; edges: AgentEdge[] }

/** One agent may not be both a tool of X and a handoff target of X. */
export function conflicts(g: AgentGraph): AgentEdge[] {
  const seen = new Map<string, EdgeKind>();
  const bad: AgentEdge[] = [];
  for (const e of g.edges) {
    const key = `${e.from}->${e.to}`;
    const other = seen.get(key);
    if (other && other !== e.kind) bad.push(e);                            
    else seen.set(key, e.kind);
  }
  return bad;
}

/** Every agent reachable from the root, and at what depth. */
export function reachable(g: AgentGraph): Map<string, number> {
  const depth = new Map([[g.root, 0]]);
  const queue = [g.root];
  while (queue.length) {
    const id = queue.shift()!;
    for (const e of g.edges.filter((x) => x.from === id)) {
      if (depth.has(e.to)) continue;
      depth.set(e.to, depth.get(id)! + 1);
      queue.push(e.to);
    }
  }
  return depth;
}

Двадцать строк, два бага, которые иначе нашли бы в production. reachable находит agent, до которого никто не может добраться: сконфигурирован, оплачен, никогда не вызывается. conflicts отклоняет edge, который является обоими типами сразу; звучит педантично, пока не произнесёте вслух: родитель одновременно сохраняет контроль и отдаёт его. Запустите это на системе из пяти agents с одним orphan и одним double edge:

reachable: lead@0 billing@1 tax@1 dunning@1
orphans:   ghost
conflicts: lead->tax

Теперь измерение, ради которого существует этот раздел, и единственное в главе, сделанное на реальной модели, а не scripted.

Клиент формулирует constraint в первом сообщении — наш account зарегистрирован в Португалии, а не в Испании; всё, что касается налогов, должно использовать Португалию — потом говорит о другом, затем задаёт вопрос, на который должен ответить billing. Case передаётся. Двадцать четыре trials, каждый раз другая страна и компания, четыре transfer payloads, а receiving agent затем получает один вопрос: в какой стране зарегистрирован account этого клиента?

Третья строка — контроль, и ведёт себя как контроль: факта там нет, значит его нельзя вспомнить. Остальные три — результат.

Полная transcript — 173 tokens и работает в 83 % случаев; её четыре сбоя — тема главы 24, а не этой. Typed record — 69 tokens, всего на семь больше summary, — и работает каждый раз, потому что constraint лежит в named field, а не в предложении.

А строка summary — та, на которую нужно смотреть. Она провалилась 24 раза из 24, и причина не в том, что читатель её пропустил. Constraint вообще появился только в 1 из 24 summaries. Receiving agent не был невнимателен; ему передали текст, в котором не было ответа. Summary — это compaction, которую писали не вы, произведённая моделью, окна которой вы не видите, оптимизированная так, чтобы читаться как summary; а «клиент говорит, что в наших записях неправильная страна» — ровно такой clause, который summariser выкидывает как procedural noise.

Честное ограничение этого числа: summariser — модель на полмиллиарда параметров, и более крупная сохранила бы больше. Что не улучшается с размером, так это форма риска: sending agent решает при каждом handoff, при каждой phrasing, ненаблюдаемо, какие факты выживут. Typed record вообще не зависит от этого judgement, поэтому выигрывает by construction, а не интеллектом. Всё, что должно пережить transfer, должно быть полем, а не предложением.

Та же логика работает и в другую сторону, для topology «agent как инструмент», и ранняя таблица уже дала ей цену: то, что возвращается от worker, — тоже summary, и заплатить на 8,3 % больше, чтобы получить evidence вместе с ним, — то же исправление, только со стороны родителя.

Три заключительных факта, все из таблиц выше.

Multi-agent system умножает вызовы, а вызовы квадратичны по context. Оркестратор сделал 12 model calls там, где один agent сделал 5, и каждый несёт собственную растущую transcript — 3,628 input tokens против 2,697, разрыв растёт вместе с длиной задачи.

Каждая граница — lossy channel. Два agents означают одну summary. Четыре agents в цепочке — три summaries, наложенные друг на друга, каждая написана моделью, оптимизирующей что-то отличное от вашего решения.

Один agent нашёл то, о чём никто не спрашивал. Несовпадение purchase order surfaced, потому что одно окно одновременно держало инвойс и заказ. Разделение работы между specialists также разделяет способность заметить, что два факта противоречат друг другу.

Ничто из этого не является аргументом против опубликованных multi-agent frameworks, которые стоит читать как первоисточники, а не через tutorials.¹⁰ Это аргумент за то, чтобы второй agent заслужил своё место.

Итак, не предпочтение, а тест. Добавляйте второго agent, когда верно хотя бы одно: sub-task нужно чистое окно, которое родитель не должен наследовать (глава 24); sub-tasks действительно независимы и важен wall clock — это 1.8× выше; sub-task требует других permissions или другой модели, что глава 30 превращает в аргумент безопасности; или sub-task принадлежит кому-то ещё, и тогда начинает иметь значение настоящий protocol. Если ответ: «чтобы у каждого agent был более ясный prompt», дайте одному agent более ясный prompt. Это бесплатно.

Теперь вы можете назвать пять паттернов, оценить их друг относительно друга на одной задаче, отличить orchestrator от sectioner и tool call от handoff, а также защитить single agent таблицей, а не предпочтением.

У всех схем здесь было одно удобство, которое не переживёт столкновения с чем-то реальным: все инструменты принадлежали нам. Инвойс, заказ, tax table, workers за orchestrator — один repository, один deploy, одни types, одни люди.

Теперь поместите один из них по другую сторону границы компании. Tax table принадлежит accounting vendor, order record — warehouse system, и ни одна из них не читала ваш интерфейс Tool. Вам нужен способ, чтобы модель, которую вы не писали, могла обнаружить, описать и вызвать capability, которой управляет кто-то другой, — с authentication (это половина главы 27), versioning и гарантией, что server не может прочитать остальную часть вашего разговора. Это protocol problem, у неё есть specification с normative schema, и почти всё проиндексированное о ней описывает revision, которого больше не существует.

Глава 26 читает эту specification вместо того, чтобы пересказывать её, и начинает с ручного ввода JSON-RPC в terminal.

Все cost и token counts выше получены от scripted provider, описанного во втором разделе, на Node 22 через loopback interface, с подсчётом encoding o200k_base и оценкой по тарифам, которые глава 16 прочитала 6 сентября 2026 года: $2.00 за миллион input tokens и $12.00 за миллион output. Wall-clock figures — из тех же runs с latency provider 400 ms на call и tools 50 ms, поэтому они измеряют схему, а не provider. Два real-model measurements — таблица handoff и таблица voting-and-judging — использовали Qwen/Qwen2.5-0.5B-Instruct в float32 на CPU за endpoint той же формы, greedy, кроме мест, где указана temperature, с интервалами, вычисленными методом Wilson из главы 4. Ни один request в этой главе не ушёл на paid endpoint, и ни одно число в ней не было estimated.