Multi-Agent orchestration: пет модела и кога един печели

Португалска компания пише за фактура FT-2026-0918. В имейла се казва, че ДДС изглежда грешен, и е прикачена фактурата: нето EUR 248.00, начислен ДДС 21 %, EUR 52.08, общо EUR 300.08.

Фактите, нужни за отговора, са на три места, и само едно от тях е в имейла:

Съберете трите и фактурата е грешна: прилага се reverse charge, ДДС е трябвало да бъде нула, дължи се кредитно известие за EUR 52.08. Погледнете само фактурата и тя е аритметично идеална — 248.00 плюс 52.08 е 300.08 — и ще кажете точно това.

В имейла наистина пише „ние сме португалска компания“. Това е твърдение, не запис, а никоя billing система не издава кредитно известие само по твърдение. Капанът не е трик: това е обичайната форма на бизнес работа, при която решението изисква факт, който никой не се е сетил да извлече.

Всичко по-горе работи срещу скриптиран доставчик в стила на този от Глава 23, с точно едно правило:

Отговорът може да използва само факт, който е в неговия prompt.

„Model“ иска всеки tool, който има, по веднъж, в каталожен ред, след което прилага фиксирано правило към текста, който вижда. Нищо не е скриптирано по подредба, така че разликите в началната таблица не са твърдения за интелигентността на model: те са измерено маршрутизиране на информация. Реален model добавя собствените си провали отгоре; не премахва тези.

Петте имена по-долу са на Anthropic, от 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 call обработва output на предишното“.¹ Идеята предхожда езиковите models: това е 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 веригата струва $0.001940 и загуби полетата на фактурата между втора и трета стъпка, защото третата стъпка получи изречение за аритметиката и нищо друго. Тя произведе съобщение за изчакване: безполезно и видимо безполезно.

Натрупващата верига — редът в началната таблица — струва $0.003780, тоест 95 % повече за четири идентични calls, защото всяка стъпка вече носи всичко преди нея. Тя произведе опасния output. Гладък, цитира аритметиката си, правилен за всяко число, което споменава, и казва на клиент, че нищо не се дължи, когато се дължат EUR 52.08.

Разликата между двете е един ternary. Верига, която носи по-малко, произвежда отговори, които са очевидно непълни; верига, която носи всичко, произвежда отговори, които са уверено грешни — и само вторият тип се изпраща.

Нито едното не е истинският провал. Истинският провал е, че pipeline реши, преди да прочете каквото и да било, че тази задача е четири стъпки върху съдържанието на имейл. Никъде в тази структура няма място да се каже „държавата на регистрация не е в този имейл; отиди и я вземи“. Chaining е правилен, когато разлагането е предварително известно и стабилно. Тук беше предположение, и предположението беше пуснато.

Routing „класифицира input и го насочва към специализирана последваща задача“.¹ Името е ново; механизмът е dispatcher, по-стар от почти всичко останало в тази книга. Новото е, че classifier може да бъде model — което го кара да се проваля по начини, по които 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; това е pattern. Model-based router има failure mode, който dispatcher няма: може да върне label, който не съществува, да timeout-не, или — скъпият вариант — да върне правдоподобен грешен label без сигнал, че е грешен. И трите трябва да стигнат някъде, и това някъде не може да бъде друго model call, защото вече сте в клона, в който model calls са се провалили.

Второто е, че собственият prompt на router не е безплатен. За да избере model, router се нуждае от каталог с models, между които да избира, и всеки запис в него е input, за който router плаща преди да е прочел въпроса на потребителя. При input тарифата, с която този курс остойностява, каталог от около 3,800 tokens вече струва колкото целия пет-call agent run в началната таблица. На практика routing call върви на евтин model, което е цялата причина routing да се изплаща; но си струва аритметиката да се направи в тази посока, вместо да се приема наготово. Routing е грешен точно когато маршрутизираната задача е по-евтина от routing решението.

Anthropic разделя това на две: sectioning — „разбиване на задача на независими subtasks, които се изпълняват паралелно“ — и voting — „изпълняване на една и съща задача многократно, за да се получат разнообразни outputs“.¹ Те споделят диаграма и почти нищо друго.

Sectioning е евтината победа и е редът от patterns.ts: трима специалисти — billing, tax, policy — всеки със собствен window и tools, върху същия имейл, с едно synthesis call накрая. Идентична работа, подредена по два начина:

Същото token по token, 1,8 пъти по-бързо. Затова pattern заслужава собствено име: той е единственият от петте, който подобрява нещо, без да струва нищо. Уловката е, че секциите трябва да са наистина независими — дайте на секция B факт, който секция A произвежда, и Promise.all ще пусне и двете срещу state, който още не съществува. for loop скриваше този bug; едноредовият вариант го излага.

Voting е друго животно със същата картинка. Да пуснете един и същ въпрос k пъти и да вземете мнозинството е self-consistency, публикувано от Wang и съавт. през март 2022 г. като decoding стратегия, почти три години преди някой да го нарече orchestration pattern. Abstract-ът му е прецизен за механизма — „първо sample-ва разнообразен набор от reasoning paths, вместо да взема само greedy one, и след това избира най-consistent отговора чрез marginalizing out sample-натите reasoning paths“ — и за печалбата: +17,9 точки на GSM8K.²

От това следват две неща, които картинката скрива. Първо, voting изисква sampling от Глава 17: при температура нула всички k samples са един и същ sample, а мнозинството е един отговор, платен k пъти. Второ, работи само там, където мнозинство има смисъл — при отговора за фактурата по-горе няма какво да се брои, защото пет drafts са пет различни изречения. Voting е за задачи с кратък, сравним отговор, което точно са benchmark-овете на Wang и почти нищо, което customer-facing agent прави.

Измерено тук върху 20 тристъпкови word problems, чиито отговори се изчисляват, а не се оценяват, с локалния model от Глава 23, reasoning стъпка по стъпка:

Пет пъти calls, пет пъти tokens, точно пет пъти сметката и нито един допълнителен правилен отговор. Voting е залог, не подобрение, и този run го загуби.

Две уговорки, преди някой да цитира това като опровержение на Wang. Двадесет опита не могат да различат 45 % от 60 % — интервалът е широк колкото твърдението, което е дисциплината от Глава 4, обърната към моя собствен резултат. А публикуваните печалби идват от models с порядъци по-големи, където разнообразните reasoning paths, върху които voting marginalises, наистина са разнообразни. Това, което се пренася, не е числото: то е, че множителят е точен и известен предварително, докато печалбата не е нито едното.

В workflow orchestrator-workers „централен LLM динамично разбива tasks, делегира ги към worker LLMs и синтезира резултатите им“, а разликата от sectioning е, че „subtasks не са предварително дефинирани, а се определят от orchestrator“.¹ Произходът тук изобщо не е от езиковите models: това е master-worker, а версията, в която workers записват findings в споделено пространство, което controller чете, е blackboard architecture от изследванията по разпознаване на реч през 70-те. Новото през 2026 г. е, че controller е model и следователно разлагането може да се решава за всеки input — гъвкавостта и цената в едно изречение.

Струваше 12 model calls срещу 5 за единичния 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 имаше фактурата, поръчката и данъчната таблица в собствения си window, стигна до заключението и също забеляза — никой не го беше питал — че номерът на purchase order във фактурата не съвпада с този в поръчката. После върна summary. Orchestrator може да повтори и двете твърдения и да провери нито едното, защото доказателствата останаха в window, който никога не е виждал. Това е финалният въпрос на Глава 24 с отговор: родителят може да види това, което child е избрал да запише.

Поправката е flag и има цена:

Дванадесет процента повече input tokens, 8,3 % повече пари, и фразата source=worker_unverified изчезва от отговора. Това е размяната във всяка multi-agent system и почти никога не се казва: чистият window на child си струва, способността на parent да го одитира си струва да се плати, и не можете да имате и двете безплатно.

Кога тогава orchestrator-workers е грешен? Тук, за тази задача. Купи правилен отговор, до който един agent със същите четири tools също стигна, за 1,66 пъти цената и 2,3 пъти wall clock, и направи този отговор по-труден за защита. Собственото указание на Anthropic казва същото още преди patterns да започнат: намерете „възможно най-простото решение и увеличавайте сложността само когато е нужно“, защото „agentic systems често разменят latency и цена за по-добра task performance“.¹ Таблиците по-горе са това изречение с числа под него.

Едно call генерира, друго оценява, а loop се повтаря, докато оценката мине.¹ Публикуваните предци са Self-Refine — същият model като „generator, refiner, and feedback provider“, отчитащ около 20 пункта абсолютното подобрение средно върху седем tasks³ — и Reflexion, който съхранява critique в episodic buffer между опити и отчита 91 % pass@1 на HumanEval, където baseline достига 80 %.⁴

Cost model е най-простият от петте: две calls на round, а броят rounds не е ваш. Три rounds refinement върху задача, която е взела едно call, са шест calls, така че долната граница на pattern е 6×, а горната е какъвто cap зададете — което прави budget exit от Глава 23 задължителен, а не просто подреден.

Таванът е по-фин и е измерим. На същите 20 задачи локалният model отговори правилно на 9. После му бяха показани всеки от тези отговори и беше попитан дали е правилен — без да му се казва, че отговорът е негов, което премахва flattery confound и оставя capability:

Това е по-добър съдия, отколкото заглавието на секцията внушава, и именно затова измерваме, вместо да твърдим: не блокира нищо правилно и хвана 8 от 11 грешки. Като filter си струва calls.

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

Оттук правилото: evaluator заслужава calls само когато има нещо, което generator няма. Compiler, test suite, schema validator, различен model, човек. Собствените резултати на Self-Refine са измерени срещу human preference и task metrics, никога срещу мнението на model за самия себе си. Ако единственото предимство на вашия evaluator е различен prompt, плащате двойно за съгласие. Глава 29 изгражда версията с истинско предимство: golden set с отговори, написани предварително.

Петте по-горе са форми за вашия код. Под тях стои второ семейство, което често се изброява редом с тях, но не бива: ReAct, Reflexion, plan-and-execute и tree of thoughts са reasoning loops, а цената им е в requests.

Глава 12 беше за reasoning вътре в model, за което плащате с output tokens в едно call. Това е другият вид. Разликата има значение, когато дойде сметката: по-дълга chain of thought прави едно call по-скъпо, а reasoning loop превръща една задача в много calls, всяко от които изпраща отново всичко преди него — квадратичното поведение, което Глава 23 измери в runaway таблицата си.

Статията за tree-of-thoughts публикува собствена таблица с разходи, което е по-рядко, отколкото би трябвало. На Game of 24 с GPT-4: input/output prompting best-of-100 решава 33 % при $0.13 на случай, chain of thought best-of-100 решава 49 % при $0.47, а tree of thoughts решава 74 % при $0.74, като авторите отбелязват, че то „може да изисква 5-100 пъти повече generated tokens от CoT“.⁷

Почти шест пъти цената на евтиния метод за малко повече от двоен success rate. Дали това е изгодна сделка зависи от това колко ви струва провален случай — въпросът, който трябва да зададете, преди да приемете който и да е от тези четири.

Този курс не ги имплементира отново. И четирите имат 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 като tool. Parent го извиква, получава отговор и продължава. Това е tool интерфейсът от Глава 18 с цял agent зад него, и parent никога не губи контрол. Това прави orchestrator по-горе.

Прехвърляне. Parent прехвърля разговора и не го получава обратно. Guide-ът на OpenAI е най-ясното публикувано твърдение: handoffs са „еднопосочно прехвърляне, което позволява на agent да делегира към друг agent... Ако agent извика handoff function, ние веднага започваме execution върху новия agent, към който е било прехвърлено, като също прехвърляме 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, с versioned 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 на библиотека, а другата е specification с governance.

Разграничението е data structure, не диаграма:

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;
}

Двадесет реда, два bug-а, които иначе бихте открили в production. reachable намира agent, до който никой не може да стигне — конфигуриран, платен, никога извикан. conflicts отказва edge, който е и двата вида едновременно, което звучи педантично, докато не го прочетете на глас: parent едновременно запазва контрол и го отдава. Пуснете го върху five-agent system с един orphan и един double edge:

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

Сега измерването, заради което съществува тази секция, и единственото в главата, направено срещу реален model, а не скриптиран.

Клиент заявява constraint в първото си съобщение — нашият account е регистриран в Португалия, не Испания; всичко данъчно трябва да използва Португалия — говори за друго, после задава въпрос, на който billing трябва да отговори. Случаят се прехвърля. Двадесет и четири trials, различна държава и компания всеки път, четири payload-а за прехвърляне, а receiving agent после получава един въпрос: в коя държава е регистриран account на този клиент?

Третият ред е control и се държи като такъв: фактът не е там, така че не може да бъде припомнен. Другите три са finding.

Пълният transcript е 173 tokens и работи в 83 % от случаите, като четирите му провала са тема на Глава 24, а не на тази. Typed record е 69 tokens — седем повече от summary — и работи всеки път, защото constraint стои в именувано поле, вместо в изречение.

А summary е редът, в който трябва да се взираме. Провали се 24 пъти от 24, и причината не е, че reader го е пропуснал. Constraint се появи само в 1 от 24 summaries изобщо. Receiving agent не беше невнимателен; беше му подаден текст, който не съдържаше отговора. Summary е compaction, което не сте написали, произведено от model, чийто window не можете да видите, оптимизирано да се чете като summary — а „клиентът казва, че записите ни имат грешна държава“ е точно видът клауза, която summariser изхвърля като процедурен шум.

Честен лимит за това число: summariser е model с половин милиард parameters и по-голям би запазил повече. Това, което не се подобрява с размер, е формата на риска — sending agent решава, при всяко прехвърляне, при всяка формулировка, ненаблюдаемо, кои факти оцеляват. Typed record изобщо не зависи от тази преценка, затова печели по конструкция, а не по интелигентност. Всичко, което трябва да оцелее при transfer, трябва да е поле, не изречение.

Същата логика важи и в другата посока, за topology agent-as-tool, а по-ранната таблица вече я оцени: това, което се връща от worker, също е summary, и да платите 8,3 % повече, за да получите доказателствата с него, е същата поправка, видяна от страната на parent.

Три финални факта, всички от таблиците по-горе.

Multi-agent system умножава calls, а calls са квадратични в context. Orchestrator направи 12 model calls там, където един agent направи 5, и всяко носи собствен растящ transcript — 3,628 input tokens срещу 2,697, разлика, която се разширява с дължината на задачата.

Всяка граница е lossy channel. Два agents означава едно summary. Четири agents във верига означава три, композирани, всяко написано от model, оптимизиращ за нещо различно от вашето решение.

Единичният agent намери нещо, което никой не беше поискал. Несъответствието в purchase order излезе наяве, защото един window държеше фактурата и поръчката едновременно. Разделянето на работата между specialists разделя и способността да забележите, че два факта си противоречат.

Нищо от това не спори срещу публикуваните multi-agent frameworks, които си струва да се четат като първоизточници, а не през tutorials.¹⁰ То спори, че вторият agent трябва да заслужи мястото си.

И така, тест, а не предпочитание. Добавете втори agent, когато поне едно от тези е вярно: sub-task изисква clean window, който parent не трябва да наследи (Глава 24); sub-tasks са наистина независими и wall clock има значение, което е 1,8× по-горе; sub-task изисква различни permissions или различен model, което Глава 30 превръща в аргумент за security; или sub-task е собственост на някой друг, което е мястото, където реален protocol започва да има значение. Ако отговорът е „за да има всеки agent по-ясен prompt“, дайте на единия agent по-ясен prompt. Безплатно е.

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

Всяка подредба тук споделяше едно удобство, което няма да преживее контакт с нищо реално: всички tools принадлежаха на нас. Фактура, поръчка, данъчна таблица, workers зад orchestrator — един repository, един deploy, едни types, едни хора.

Сега сложете един от тях от другата страна на фирмена граница. Данъчната таблица принадлежи на accounting vendor, записът на поръчката — на warehouse system, и нито един от тях не е чел вашия Tool интерфейс. Нуждаете се от начин model, който не сте писали, да открие, опише и извика capability, което някой друг управлява — с authentication (което е половината на Глава 27), versioning и гаранция, че server не може да прочете останалата част от разговора ви. Това е protocol problem, има specification с normative schema, и почти всичко индексирано за него описва revision, която вече не съществува.

Глава 26 чете тази specification, вместо да я обобщава, и започва с ръчно писане на JSON-RPC в terminal.

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