Патерн оркестратора

Клієнт просить змінити дату бронювання. Дослідник знайшов умови, розробник змінив код, рецензент погодив patch — але ціна змінилася, а списання ще не підтверджене. Хто вирішує, що робити далі, і за якими доказами система визначить, що роботу справді завершено?

Навчальний результат. Після глави читач зможе описати межі ролей оркестратора, виконавця, рецензента й власника рішення; задати стан і критерії переходу; делегувати роботу через перевірний контракт; безпечно продовжити її після часткового успіху; перевірити інтегрований результат і визначити, коли потрібне рішення людини.

Передумови. Потрібне базове розуміння агентів, контексту, декомпозиції та передачі роботи з глав 23, 24, 26 і 38. Тут потрібні лише ці загальні поняття; знати конкретні програмні інтерфейси Codex чи комплект засобів його розробника не потрібно.

Оркестрація — це керування роботою, що складається з кількох кроків, виконавців або систем, так, щоб із них утворився перевірений результат. Оркестратор може бути програмою, агентом штучного інтелекту (artificial intelligence, AI — комп’ютерна система, що виконує інтелектуальні завдання), людиною або їх поєднанням. Велика мовна модель (large language model, LLM — модель, навчена розуміти й генерувати текст) може аналізувати неоднозначний матеріал, але вона не обов’язкова на кожному кроці. Основне завдання оркестратора — зберігати ціль і стан роботи, розподіляти обмежені доручення, перевіряти докази, узгоджувати результати та вирішувати, що робити далі.

Не кожен крок потребує мовної моделі. Код краще підходить для передбачуваної перевірки формату, обчислення, маршрутизації за чітким правилом і повторюваних операцій. Людина потрібна там, де рішення належить власнику, має правові чи фінансові наслідки або залежить від контексту, якого система не має. Модель корисна для неоднозначного аналізу, синтезу джерел і формування варіантів. Зрілий оркестратор вибирає виконавця під роботу, а не вставляє агента в кожен крок.

Глава розглядає загальний патерн і його межі. Делегування субагентам Codex описане в главі 38, плагіни й Model Context Protocol (MCP — протокол контексту моделі, який стандартизує доступ моделей до інструментів та даних) — у 39-й, а реалізація сервісу оркестрації — у главі 73. Тут зосередимося на стані, контрактах, перевірці, інтеграції та рішенні про завершення.

40.1. Ролі та відповідальність

Оркестратор зберігає ціль, призначає роботу, відстежує залежності й стан, зводить результати та визначає наступний крок. Він не обов’язково сам виконує будь-яку предметну роботу.

Виконавець — агент, програма, сервіс або людина, якій доручено певний результат. Контракт виконавця обмежує його мету, вхідні дані, доступи, артефакти й умови зупинки. Один виконавець може виконати кілька ролей у простій задачі, однак межі відповідальності все одно мають бути зрозумілими.

Рецензент перевіряє результат за визначеними критеріями й доказами. Він може бути людиною, тестом, окремим агентом або кількома з них. Рецензент не є магічним джерелом істини: його висновок — ще один артефакт, який оркестратор оцінює за точністю, охопленням і незалежністю.

Власник рішення має повноваження прийняти рішення, яке виконавець не повинен ухвалювати самостійно. Це може бути користувач, оператор, відповідальна команда чи визначена посадова особа. Право власника не можна вивести лише з того, що модель здатна запропонувати відповідь.

У маленькому сценарії одна людина може бути одночасно оркестратором, виконавцем і власником рішення. У більшому процесі ці функції розділені. Розділяти треба відповідальність, а не обов’язково створювати стільки ж агентів. Визначте, хто може змінювати спільний контракт, хто приймає інтегрований результат і хто дозволяє зовнішню побічну дію.

40.2. Цикл оркестрації

Практичний цикл має такий вигляд:

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

Кожна стрілка означає передачу конкретного артефакту чи стану, а не просто повідомлення «готово». Спочатку оркестратор з’ясовує мету та перевіряє авторитетність потрібних джерел. План — це змінна гіпотеза про порядок роботи. Після нових доказів оркестратор може його переглянути, зберігши причину й уже перевірені результати. В документації OpenAI менеджер може викликати вузького спеціаліста як інструмент і лишатися відповідальним за фінальну відповідь, або передати йому керування через handoff (передачу керування); це різні патерни application programming interface (API — інтерфейсу програмування застосунків, узгодженого способу обміну запитами й відповідями між програмами), а не універсальні ролі для кожної системи (OpenAI Agents orchestration). Anthropic додатково розрізняє workflows (заздалегідь задані послідовності роботи) та агентні системи, у яких модель динамічно обирає наступні дії (Building effective agents); це терміни їхньої архітектурної настанови, а не межа між усіма можливими системами.

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

Модель, яка сама обирає наступний крок, не скасовує потреби в межі циклу. Установіть бюджет викликів, часу, вартості чи спроб і умову зупинки. Якщо нових доказів немає, повторна генерація плану не є прогресом.

40.3. Контракт доручення та критерії приймання

Добре доручення дозволяє виконавцеві діяти самостійно в межах і дає оркестратору змогу незалежно прийняти або відхилити результат. Мінімальний контракт включає:

Поле	Що зафіксувати
Ціль	Який результат потрібен і для кого?
Обсяг робіт (scope)	Які частини включені, а які виключені?
Вхід і ревізія	Які джерела, файли, дані або версії є авторитетними?
Виконавець і права	Хто працює, які ресурси може читати чи змінювати, які дії заборонені?
Артефакт	Що саме треба повернути: аналіз, файл, патч, запит або рішення?
Критерії приймання	Які спостережувані умови засвідчать, що результат відповідає цілі?
Докази (evidence)	Які джерела, перевірки, журнали чи результати треба надати?
Залежності	Що має бути готове раніше та які інші роботи цей результат блокує?
Бюджет і час	Які межі витрат, тривалості або кількості спроб?
Стоп-умова	Коли зупинитися й ескалювати замість здогадуватися або змінювати scope?

Критерії мають описувати властивості результату, а не кількість повідомлень чи сам факт завершення виконавця. «Повернути три джерела з датами й цитатами» можна перевірити. «Дослідити добре» — ні. Якщо критерій суб’єктивний, розкладіть його на спостережувані ознаки та залиште місце для власника, який приймає ціннісне рішення.

Контракт повинен переносити потрібний контекст, але не всю історію роботи. Передавайте вихідну ревізію, рішення, припущення, потрібні посилання й зміни після останнього перегляду. Вимагайте від виконавця назвати невідомі факти, припущення та неповні частини окремо. Це допомагає не переплутати висновок із фактом.

40.4. Стан — це об’єкт керування

Поточний стан має бути явним і відновлюваним. Приклади назв станів: planned (заплановано), ready (готово до запуску), running (виконується), blocked (заблоковано), needs_review (потрібна перевірка), accepted (прийнято), failed (невдало), cancelled (скасовано). Це зручний словник, а не обов’язкова схема. Проєкт має вибрати власні стани та визначити, що вони означають.

Перехід	Необхідна умова або доказ
planned → ready	Обсяг, залежності, виконавець, доступи та критерії достатньо визначені.
ready → running	Запуск зафіксований з ідентифікатором, ревізією та бюджетом.
running → needs_review	Виконавець повернув артефакт і звіт; це ще не прийняття.
running → blocked	Є конкретний зовнішній блокер або бракує дозволу; зазначено власника наступної дії.
needs_review → accepted	Перевірено необхідні критерії на конкретному артефакті чи ревізії.
needs_review → running	Зафіксовано відхилення, його критерій і обмежене виправлення.
running → failed/cancelled	Зафіксовано причину, частковий стан і можливі зовнішні наслідки.

Термінальний стан не означає, що всі частини успішні. Наприклад, скасоване завдання могло вже створити зовнішній ресурс. Зберігайте окремо статус виконавця, статус артефакту та статус зовнішньої операції, якщо їхні життєві цикли відрізняються.

Кожна зміна стану має автора, час, попереднє значення, наступне значення й обґрунтування. Для важливого переходу зберігайте посилання на доказ: diff (порівняння версій), запуск перевірки, відповідь API, схвалення власника чи спостережений стан системи. Після відновлення не довіряйте застарілому локальному повідомленню «виконано» — звірте поточну зовнішню систему.

40.5. Декомпозиція, залежності та паралельність

Декомпозиція корисна тоді, коли результат підзадачі можна перевірити незалежно й передати далі через зрозумілий інтерфейс. Дві задачі можуть виконуватися паралельно, якщо їхні дані, права й результати не створюють взаємного запису без координації. Якщо двом виконавцям треба змінити той самий файл, спільну схему чи одне рішення, призначте власника інтеграції або розділіть інтерфейс до паралельного виконання.

Граф залежностей відповідає на три запитання: що має бути готове раніше; що можна робити одночасно; який контракт з’єднує частини. Не запускайте підзадачу, якщо її вхід ще змінюється без ревізії або якщо критерії приймання залежать від невирішеного рішення. Зупиніть чи переплануйте роботу, коли її передумови вже недійсні.

Координація сама має ціну. У «The Mythical Man-Month» Фредерік Брукс описує комунікаційні накладні витрати для людей у задачах, що потребують взаємної координації, та захищає концептуальну цілісність як принцип архітектури (бібліографія видання; текст книги). Його умовна модель парних зв’язків не є прогнозом продуктивності команди чи доказом законів для AI-агентів. Практичний висновок для оркестратора — зафіксувати спільні інтерфейси, обмежити кількість залежностей і залишити власника системного рішення. Перенесення цієї ідеї на агентів — наша інженерна інтерпретація, а не теза Брукса.

У «Team Topologies» Метью Скелтон і Мануель Пейс описують різні моделі взаємодії людських команд: обмежену за часом співпрацю, сервіс з ясним власником і тимчасову фасилітацію (книжка; моделі взаємодії). Ці моделі можуть підказати, як описувати межі між агентними ролями, однак книжка не доводить, що відповідна структура покращить агентний процес. Оберіть найменшу взаємодію, яка дає потрібне знання чи сервіс, і визначте момент її завершення.

40.6. Перевірка та інтеграція

Окрема підзадача може пройти власні перевірки й водночас зламати загальний результат. Оркестратор перевіряє дві речі: локальну коректність кожного артефакту та системну сумісність після об’єднання. Додайте для кожного підрезультату ревізію вхідних даних, версію критеріїв і точний результат перевірки. Якщо між перевіркою й інтеграцією вхід змінився, повторіть перевірки, залежні від нього.

Доказ повинен відповідати твердженню. Посилання на виконаний тест не доводить, що він охопив конкретний дефект, а завершена безперервна інтеграція (continuous integration, CI) не доводить, що перевірявся останній артефакт, якщо ревізія не збігається. Відповідь рецензента — це доказ лише щодо того, що рецензент справді прочитав і перевірив. Зафіксуйте і позитивні результати, і прогалини.

Перед прийняттям результату зведіть окремі версії, застосуйте зміни, розв’яжіть конфлікти й повторно перевірте інтегровану систему. Спільний список «готових» задач не гарантує сумісності їхніх артефактів. Перевіряйте послідовність міграцій, формат обміну, спільні домовленості та користувацький результат, який утворився після складання частин.

Реальний приклад контролера Kubernetes показує, чому потрібна узгодженість часткового стану. У повідомленні про помилку #139428 описано шлях повторного відкладання Job-ресурсу Kubernetes, який запускає й відстежує виконання скінченної задачі: значення active ставало нульовим, тоді як ready і далі відображало активні об’єкти Pod (один або кілька контейнерів зі спільним оточенням). API Kubernetes відхиляв неузгоджене оновлення з кодом помилки 422; через це затримувалося збереження статусу й зняття фіналізаторів відстеження. Пов’язаний pull request (запит на злиття змін; PR) #139457 повертає узгоджений лічильник активних задач у двох шляхах відкладеного створення та додає регресійні випадки для звичайного й поіндексного шляху. Його злили 11 червня 2026 року. Це не приклад AI-агента й не вимір продуктивності: він ілюструє, як частковий стан, відмова API, відновлення й інтеграція тестів пов’язані в одному контролері. Сторінка PR не підтверджує зелені перевірки безперервної інтеграції (CI), тому цього висновку тут немає.

40.7. Повтори, частковий успіх і відновлення

Повтор без перевірки може подвоїти зовнішній ефект. Виконавець міг створити бронювання, надіслати повідомлення або записати зміну, а потім перерватися до повернення підтвердження. Статус timeout повідомляє, що оркестратор не отримав відповідь вчасно; він не повідомляє, чи відбулася операція.

Перед повтором прочитайте фактичний стан зовнішньої системи за ключем операції, ідентифікатором, природним ключем або іншим надійним способом. Якщо система підтримує ключ ідемпотентності (повторний запит з тим самим ключем не створює нового ефекту), використайте його повторно в межах тієї ж логічної операції. Якщо не підтримує, спочатку встановіть, чи попередня дія відбулася; коли це неможливо, зупиніться й передайте невизначеність власнику. Документація LangGraph наводить пов’язану межу своєї реалізації: після переривання вузол може початися знову, тому код перед точкою переривання має враховувати повторне виконання (Interrupts).

Відновлення потребує стійкого запису: ціль, версія плану, стан кожного кроку, вхідні ревізії, артефакти, остання успішна перевірка, невирішені припущення, вже виконані зовнішні дії та наступний безпечний крок. Повторно відкрийте джерела істини після перерви. Поновлюйте тільки відсутню частину, якщо її передумови чинні; застарілий план треба перерахувати.

Повторюйте лише кроки, що мають межу спроб, часовий бюджет і пояснення, як саме нова спроба зменшить невизначеність. Вичерпання ліміту переводить задачу у blocked чи failed з коротким звітом, а не у нескінченне генерування наступного плану.

40.8. Людські рішення та розбіжності рецензентів

Людський контроль потрібен там, де його вимагають повноваження, наслідки або невирішені цінності. Це може бути підтвердження списання коштів, надсилання зовнішнього повідомлення, публікація, видалення, вибір політики чи розв’язання конфлікту між різними інтересами. Агент може підготувати варіанти та докази, але не повинен самостійно привласнювати право власника.

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

Коли рецензенти розходяться, спершу порівняйте твердження, а не підсумкові оцінки. Один може заперечувати джерело, інший — трактування, третій — критерій або межу повноважень. Сформулюйте конкретний спір, зберіть мінімальний вирішальний доказ і попросіть незалежну перевірку саме цього питання. Якщо розбіжність стосується факту, можна шукати кращі дані; якщо критерію, нехай власник уточнить критерій; якщо політики чи цінності, винесіть рішення людині. Не усереднюйте несумісні висновки й не трактуйте кількість голосів як доказ правильності.

40.9. Вартість, межі та зрозумілий результат

Повна ціна оркестрації включає модельні й інструментальні виклики, очікування, передачу контексту, CI, рецензування, інтеграцію, виправлення та увагу людини. Паралельність скорочує календарний час лише за умови незалежної роботи; вона не гарантує меншої загальної вартості. Додавайте виконавця, якщо він створює незалежно приймальний результат і цінність перевищує витрати на постановку й інтеграцію.

Вимірюйте завершені прийняті результати, час до них, кількість повернень, повторних зовнішніх ефектів і людських ескалацій. Кількість запущених агентів або виданих повідомлень не є метрикою успіху. Почніть із одного виконавця; розділяйте роботу, коли контракт, навантаження чи потрібна експертиза справді різняться. Завчасне дроблення створює більше точок передачі, джерел стану та місць, де губиться відповідальність. Власний звіт Anthropic про дослідницьку систему також описує дублювання підзадач і надмірне породження агентів як спостережені ними проблеми, а не як вимір універсальної продуктивності (звіт).

Майкл Гербер у «The E-Myth Revisited» розрізняє роботу в бізнесі та роботу над системою, що дає команді повторювану основу (сторінка книги; пояснення EMyth). Тут ми переносимо цю управлінську метафору на оркестрацію: автоматизуйте звичайний цикл так, щоб його можна було спостерігати й повторити без прихованої пам’яті диспетчера. Гербер писав про малий бізнес, а не про AI чи програмні агенти; цей перенос — аналогія. Формалізований процес має залишатися придатним для зміни: фіксуйте правила, переглядайте їх за доказами й не перетворюйте неперевірені припущення на автоматичну політику.

40.10. Три наскрізні приклади

Це вигадані навчальні ситуації. Нижче описані артефакти й результати показують, за яких умов сценарій можна прийняти; зовнішні операції та перевірки для цієї глави не запускалися.

Зміна бронювання: дослідження, реалізація, перевірка

Ціль. Додати можливість змінити дату бронювання без втрати історії, не допускаючи подвійного списання. Початковий стан містить бронювання B-381, чинну ціну й ідентифікатор останньої транзакції. Правило: зміна дати може змінити ціну; остаточну ціну підтверджує клієнт.

Оркестратор створює три залежні доручення. Дослідник читає вимоги й API платіжного провайдера та повертає джерела, обмеження і невизначеність; змінювати дані не може. Реалізатор отримує затверджений контракт API і кодову ревізію, додає операцію зміни з ключем ідемпотентності та журналом аудиту; не може здійснювати реальне списання. Рецензент перевіряє граничні випадки, історію та умови повтору на конкретній зафіксованій версії змін (commit). Реалізація починається після прийняття API-контракту, а інтеграційна перевірка — після обох артефактів.

До запуску визначені докази переходів для кожної підзадачі окремо. Повернена дослідницька нотатка з першоджерелами переводить дослідження з running у needs_review; перевірка джерел за критеріями приймання — з needs_review у accepted. Затверджений контракт, його умови помилки й ключ ідемпотентності стають входом реалізації та дають підставу для ready → running; зміни коду й цільові перевірки — для running → needs_review; висновок рецензента та інтегровані перевірки тієї самої зафіксованої версії змін (commit) — для needs_review → accepted.

У тестовому середовищі клієнт вибирає нову дату. Система читає чинну ціну, формує запит і зберігає його як очікувану зміну. Якщо змінилася сума, зовнішнє підтвердження клієнта є окремим людським кроком; після зміни дати чи вартості схвалення більше не діє. Лише потім виконується списання чи повернення. Припустімо, інтеграційна перевірка повернула історію бронювання з одним ідентифікатором операції, платіжний провайдер і локальний запис показали ту саму суму, а повтор запиту з тим самим ключем не створив другого списання. Цей набір спостережень є підставою прийняти саме цю ревізію змін. Якщо API провайдера недоступне, задача переходить у blocked, а не намагається вгадати результат платежу. Такий поділ був би надмірним для суто внутрішньої зміни дати без зміни ціни чи зовнішньої операції: там достатніший один виконавець і локальна перевірка.

Виконавець зупинився після половини роботи

Ціль. Оновити 40 підписів клієнтів. Після 20-го виконавець втратив зв’язок. Звіту немає. Оркестратор не припускає ані повного успіху, ані нульового виконання.

Спочатку він зчитує віддалений список і журнал, звіряє по одному стабільному ідентифікатору та порівнює з початковим знімком. Виявлено 18 оновлених, два завдання в невизначеному стані, 20 незмінених. Оркестратор зберігає цей перелік, ідентифікатори дій, джерельні значення й ревізію. У невизначених двох випадках окремо перевіряє фактичний стан, а не відправляє нове запрошення. Перевірка журналу показує, що перше підписання вже успішне, а для другого запрошення ще не було. Отже, стан стає 19 завершених і 21 незмінений запис; лише ці 21 отримують продовження.

Якщо зовнішня система має ключ ідемпотентності, повтор невизначеної операції використовує той самий ключ. Інакше потрібна перевірка чи рішення людини. Завершений результат — не «другий агент відповів», а відповідність усіх 40 бажаних станів, один запис на потрібну зміну та розібрана невизначеність. Для кожної частини стан і доказ приймання зберігаються окремо. Такий процес потрібен, коли дії вже могли мати зовнішні наслідки; для читання документів чи іншої операції без побічного ефекту безпечний повтор може бути простішим за повний розбір журналу.

Два рецензенти не погоджуються

Ціль. Затвердити оновлення правила повернення коштів. Рецензентка А каже, що розрахунок не враховує часткове повернення; рецензент Б каже, що приклад у тесті застарів. Вони не голосують за загальну оцінку «добре/погано».

Оркестратор розділяє суперечку на два твердження: чи підтримує платіжний контракт часткове повернення, і чи перевіряє тест актуальну поведінку. У вигаданому сценарії чинна специфікація провайдера підтверджує часткове повернення, а наявний тест перевіряв лише повне; цільова перевірка відтворює пропуск. Це розв’язує фактичну суперечку, але лишає власнику рішення: чи є часткове повернення обов’язковим критерієм продукту. Власник відповідає «так», тож критерій додається до контракту, реалізатор оновлює обробку часткового повернення, а рецензенти перевіряють ту саму нову ревізію коду та результат цільового тесту. Цей ланцюжок доказів, а не голосування, дає підставу для прийняття.

Результат не приймається лише тому, що додано третю думку. Прийняття відбувається після зафіксованого власницького рішення, відповідності реалізації уточненому критерію та інтегрованої перевірки тієї ревізії, що розглядається. Якщо суперечка стосується лише перевірного факту, а чинний критерій і авторитетне джерело однозначні, окрема ескалація щодо політики не потрібна; якщо власник недоступний, робота лишається заблокованою, а агент не обирає продуктовий компроміс сам.

Короткий підсумок

Оркестратор завершує задачу тоді, коли її інтегрований результат відповідає критеріям на конкретній ревізії, необхідні докази збережені, невизначені побічні дії з’ясовані, а рішення власника отримані там, де вони потрібні. До цього часу доручення може бути виконаним, але ціль ще не прийнята. Коли роботи не можна безпечно повторити або завершити без відсутнього рішення, оркестратор явно фіксує блокер і наступний відповідальний крок.

Джерела та подальше читання

Динамічний вміст перевірено 26 вересня 2026 року.

1. OpenAI, Agents orchestration, офіційний опис менеджера, інструментів агентів і handoff; доступ 2026-09-26.
2. Anthropic, Building effective agents, 19 грудня 2024 року. Workflows, routing, parallelization, orchestrator-workers, оцінювання та людські контрольні точки; доступ 2026-09-26.
3. Anthropic, How we built our multi-agent research system, 13 червня 2025 року. Архітектура і спостереження Anthropic за власною дослідницькою системою; досвід не узагальнено на всі проєкти; доступ 2026-09-26.
4. LangChain, Interrupts, офіційна документація LangGraph про паузу, відновлення й ідемпотентні побічні ефекти; доступ 2026-09-26.
5. Kubernetes, Issue #139428, звіт про помилку статусу Job, 2 червня 2026 року; та PR #139457, виправлення й регресійні перевірки, злитий 11 червня 2026 року; доступ 2026-09-26.
6. Michael E. Gerber, The E-Myth Revisited, опис книги на сайті автора. Застосування в цій главі — аналогія з операційних систем бізнесу; сторінку перевірено 2026-09-26.
7. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 1995, розділи “The Mythical Man-Month” і “Aristocracy, Democracy, and System Design”; бібліографічний запис Google Books та текст книги на Carnegie Mellon. Координаційна модель не є універсальним прогнозом для агентів; джерело перевірено 2026-09-26.
8. OpenAI Agents SDK, Multi-agent, Handoffs і Human in the loop: документація конкретних інтерфейсів оркестрації; доступ 2026-09-26.
9. Matthew Skelton та Manuel Pais, Team Topologies і моделювання взаємодії команд: людські командні моделі, не доказ ефекту для AI-агентів; сторінки перевірено 2026-09-26.
10. EMyth, Work ON it, not just IN it: джерело управлінської аналогії, не дослідження оркестрації; перевірено 2026-09-26.