Контракти делегування для команд штучних інтелект-агентів: обсяг, процедури прийняття та робота з невдачами.
Чому назви посад агентів не запобігають проблемним передачам завдань, та як можна перевірити контракт делегування з обов’язковим дотриманням правил, незалежними критеріями прийняття та реагування на невдачі.
Уявіть собі зміну продукту, якою керують три агента: додати пагінацію за допомогою курсора до API, до клієнта, який його викликає, та до тестів. Усі троє повідомляють про успіх, проте клієнт не може розпарсити те, що повертає API. Агент API відправляє next_cursor, агент клієнта очікує nextCursor, а агент тестів перевіряє моки, створені на основі припущень клієнта. Кожне локальне завдання здається виконаним, але спільна зміна зазнає невдачі при першому справжньому запиті.
Позначення агентів як інженерів, спеціалістів з клієнтами та рецензентів не вказує, який інтерфейс є переможцем чи хто підтверджує результат. Ці рішення мають бути вказані у договорі про делегування повноважень, тобто у конкретному завданні, яке визначає вхідні дані, дозволений обсяг роботи, необхідний результат, умови прийняття та дії у разі невдачі. Його цінність полягає у тому, як система використовує цю угоду, а не у створенні ще одного документа.
Уявіть це у вигляді шарів: роль визначає, як агент підходить до виконання роботи, тоді як договір прописує, які внески є прийнятними. Політика часу виконання визначає, що агент насправді може зробити, а процедура прийняття вирішує, чи перетворюється цей внесок на готовий продукт.
Спеціалізація залишає процес передачі відкритим
Роль описує певний погляд на справи, наприклад пошук проблем з безпекою, створення клієнта чи критика дизайну. Контракт завдання описує конкретне завдання: використати цю версію інтерфейсу, змінити ці файли, надати ці докази. Права під час виконання визначають, що саме працівник може читати, змінювати чи запускати.
Розділення цих аспектів дозволяє корисній ролі залишатися корисною, не роблячи її відповідальною за все. Оглядач може виявити зміни, які порушують існуючі правила, не маючи права їх схвалити, а інженер може запропонувати оновлений інтерфейс, не маючи повноважень зробити його остаточним варіантом.
Дослідження мультиагентних систем від Anthropic, проведене у серпні 2026 року, зробило проблему залежностей конкретною. У експериментах зі створенням ігор рекомендовані ролі та ієрархія у стилі CEO майже не змінилися, і гри залишалися слабкими, навіть коли деякі моделі показували кращі результати за показниками координації. У тому ж звіті зазначається наявність корелованої поведінки та корелованих помилок. Ці результати отримані в ході конкретних експериментів та не є остаточними для кожної команди агентів, крім того, порівняння щодо вразливостей відрізняються за обсягом та використанням ресурсів, тому загальні кількісні показники не дозволяють визначити, що саме сприяло координації.
Існує контрприклад. Технічний звіт компанії Anthropic про їхню систему досліджень описує переваги паралельних досліджень та наводить завдання, які містять цілі, формати вихідних даних, інструкції щодо інструментів та обмеження. У звіті також зазначається підвищене споживання ресурсів та попереджаються про проблеми при роботі з великою кількістю залежностей. Це свідчить про необхідність серйозного підходу до розбирання завдань, але не доводить, що архітектура досліджень може бути без змін перенесена у інженерну реалізацію в спільному кодовому базисі.
Пропозиція, яка тут наводиться, стосується межі між делегованими та прийнятими завданнями. Чи варто явно визначати цю межу та чи компенсує це додаткові витрати, — це те, що потрібно перевірити.
Складіть завдання з урахуванням залежностей
Щодо зміни сторінкування, спочатку власник продукту має виправити бажану поведінку, а власник API — схвалити інтерфейс. Припустимо, що інтерфейс використовує next_cursor, причому значення null позначає останню сторінку. Тоді роботи API та клієнта можуть працювати з однією версією, тоді як тести прийняття перевірятимуть об’єднаний результат.
Наведений нижче YAML є прикладом контракту для роботи клієнта. Його шляхи, назви версій та ідентифікатори перевірок є прикладними, і він не є стандартом та не є частиною API жодної фреймворк-системи.
task_id: pagination-client-17
objective: Fetch successive pages using next_cursor; stop at null.
inputs:
repository:
ref: product-repo
revision: base-42
requirement:
ref: pagination-behavior
revision: r3
interface:
ref: api/pagination.yaml
revision: r7
scope:
writable:
- client/pagination.ts
- tests/client/pagination.test.ts
non_goals:
- interface_changes
- api_changes
- deployment
deliverable:
- patch_against_base-42
- check_results_bound_to_patch_and_input_revisions
acceptance:
checks:
- client-pagination-unit
- pagination-api-client-e2e
owner: product-maintainer
policy_ref: client-worker-v2
failure:
stale_or_conflicting_input: stop_and_report_to_owner
missing_evidence: return_incomplete
authority_required: request_owner_decision
max_attempts: 2
exhausted: return_unaccepted_to_owner
Назви перевірок мають відповідати реальним командам та умовам у реєстрі, яким керує виконавець. У цьому прикладі вони позначають перевірки щодо обробки курсора та повноцінну перевірку, яка працює з кількома сторінками, порівнюючи їх із фактичною API-системою, включаючи завершувальний елемент null. Клієнтський працівник може виконувати власні перевірки, тоді як інтеграційний виконавець генерує об’єднані докази після того, як існують обидва патчі.
Аналогічно, policy_ref лише вказує на назву політики. Диспетчер має прив’язати схвалене завдання до автентифікованого працівника та знайти відповідну політику у конфігурації, яку працівник не може редагувати. Невідомий посилання чи запит на більш сувору політику мають призводити до невдачі перевірки, а редагування YAML-файлу ніколи не повинно надавати додаткових прав доступу.
Обмеження кількості спроб до двох є локальним вибором, який дозволяє тримати цикли виправлень у межах, проте він нічого не говорить про надійність. Кінцевий бюджет виконання, встановлений власником, гарантує, що жодна з спроб не буде тривати вічно.
Структуроване завдання не є межею авторизації. YAML може описати запланований обсяг роботи, проте система все одно мусить це дотримуватися.
Шлях кроків, який робить контракт реальністю
Навколо робітників існує шлях кроків. Інструментарій тут — це просто програмне забезпечення, яке запускає робітників, координує їхні інструменти та фіксує те, що відбувається.
- Схвалення залежностей: власники продукту та API підтверджують вимоги та інтерфейс.
- Перевірка призначення: автор надає контракт та остаточні версії.
- Відправка згідно з обов’язковою політикою: диспетчер запускає ізольованих робітників API та клієнта.
Це завдання може бути створене людиною або іншим агентом. Після цього виконуються дві перевірки. Детерміністичний валідатор перевіряє структуру та те, що всі посилання коректно працюють, а відповідальна особа переконується, що текст дійсно відображає вимоги продукту. Після цього диспетчер чекає на схвалені залежності, завантажує необхідні дані та запускає кожного працівника в межах його функціоналу.
Чотири питання мають залишатися окремими. Перевірка коректності схеми стосується наявності та належної форми обов’язкових полів. Семантична адекватність перевіряє, чи описує призначення відповідну роботу. Забезпечення дозволів перевіряє, чи може працівник перевищити свої повноваження. Перевірка результатів стосується того, чи відповідає кінцевий продукт вимогам. Документ, який є структурно коректним, відповідає лише на перше питання.
Для забезпечення дотримання правил список написуваних шляхів має стати справжнім обмеженням під час виконання, підтримуваним перевіркою змінених файлів під час інтеграції. Доступ до шелу не повинен надавати другого способу обійти контроль файлів чи мережі. Окремий процес затвердження дозволяє тримати пропозиції окремо, проте сам по собі він не є межею авторизації.
У оголошенні GitHub про керовані дозволи від 9 вересня описуються операції, які блокуються централізовано, потребують схвалення або є дозволеними, з обмеженнями, які налаштування робочого простору не можуть послабити. У описі архітектури агентних робочих процесів йдеться про ізольовану експекутацію та поетапні, перевірені записи. Обидва ці підходи є прикладами механізмів забезпечення дотримання правил, причому жоден з них не доводить, що така схема делегування покращує процес виконання завдань чи гарантує правильні зміни.
Власність на об’єднаний результат
У прикладі з пагінацією інтеграційний запускач об’єднує пропозиції API та клієнта у тимчасовому робочому просторі. Він перевіряє обсяг завдань, верифікує зміни вхідних даних та запускає зареєстровані перевірки прийнятності саме щодо цього тимчасового простору. Потім власник процесу прийняття переглядає отримані докази та враховує будь-які аспекти продукту, які перевірки не можуть вирішити.
Незалежна перевірка означає, що працівник, який виконував роботу, не контролює самостійно критерії та докази. Положення та фіксатори на всьому шляху залишаються поза можливостями запису працівником, а результати пов’язані з оглядом кандидата. Перевірка може поєднувати детерміновані перевірки з участю людини-адміністратора, а інший ШІ є необов’язковим. Назва моделі «Supervisor» не надає їй авторитету та не робить її судження надійними.
Лише авторизований власник може змінити критерії перевірки, роблячи це з задокументованою причиною та оновленням завдання. Агент, який виконує роботу, може запропонувати зміни, але не повинен приховувати невдалий тест у наборі чи переопределяти структуру сторінок як завершену після однієї сторінки.
Нарешті авторизований інтегратор підтверджує обраний кандидат через вже налаштований захищений шлях злиття. У записі про підтвердження вказується саме той кандидат та версії вхідних даних, які він охоплює. Якщо цільова гілка розвиватиметься раніше за процес інтеграції, кандидат буде перебудований та ще раз перевірений у порівнянні з новою базою.
Результати, які вказують на конфлікт, повертаються тому, хто керує спірною ділянкою. Дві можливі інтерфейси все одно залишаються двома несумісними інтерфейсами, тож доки цей власник не прийме рішення, жодна з пропозицій не стане спільним визначенням лише через те, що вона надійшла першою.
Обробка помилок має бути частиною того ж робочого процесу
Кожен з цих випадків слід перевірити окремо в межах робочого процесу сторінкування, визначивши очікувану відповідь та особу, відповідальну за її забезпечення.
Коли обидва працівники намагаються змінити інтерфейс, диспетчер відхиляє ситуацію з перекриванням прав власності на нього, а обмеження під час виконання програми не дозволяють здійснити недозволену редагування. Інтеграційний модуль відхиляє будь-які патчі, які виходять за межі призначеного їм діапазону, а власник API приймає рішення щодо запропонованих змін.
Якщо версія інтерфейсу змінюється під час виконання роботи, перевірка залежностей позначає цю пропозицію як застарілу. Власник вирішує, чи потрібно її повторно подати для нової версії, а інтеграційний модуль не може просто прийняти дані, зібрані для старої версії.
Коли з’являється правдоподібний код без відповідних доказів, система прийняття записує його як неповний. Достовірний виконавець проводить необхідні перевірки, і повідомлення про завершення не може замінити фактичні результати.
Коли працівник зупиняється на півдорозі, пристрій кріплення фіксує це переривання та зберігає часткову пропозицію окремо. Перед початком робіт заміни стара спроба видаляється, щоб вона не могла пізніше надіслати прийнятий результат.
Якщо повторна спроба може створити дві однакові середовища попереднього перегляду, адаптер зовнішніх дій спочатку узгоджує попередній запит. Якщо постачальник підтримує усунення дублікатів, використовується стабільний ключ операції, а ефекти, які залишаються невизначеними, надсилаються власнику на перегляд.
Якщо для інтеграції потрібні повноваження, яких немає у працівника, політика інструменту блокує операцію та надсилає запит відповідному власнику. Пропозиція залишається неприйнятою до моменту отримання рішення.
Сценарій середовища попереднього перегляду є необов’язковим додатком до прикладу, який належить сервісу інтеграції, причому його розгортання залишається поза компетенцією клієнтського працівника. Одна ключова операція визначає єдиний бажаний ефект для всіх спроб, ідентифікатор спроби розділяє окремі виконання, а повторна спроба не повинна створювати нову операцію лише для подолання неоднозначної відповіді.
Акаунт Agent Harness від Temporal описує стабільне виконання та точки керування всередині циклу внутрішнього агента, з можливістю відновлення та очікування схвалення. Це проект постійного розвитку від постачальника та не є незалежним доказом для порівняння. Для зовнішніх дій все ще потрібна дедуплікація чи узгодження, специфічні для постачальника, оскільки сама стабільна оркестрація не гарантує ефекту „робити саме один раз“ у довільному сервісі, а власна документація Temporal щодо повторних спроб передбачає виявлення дублікатів на наступних етапах.
Кожен ремонт витрачає кошти з оголошеного бюджету спроб та ресурсів. Коли будь-що з цих ресурсів вичерпується, процес обробки повертає неприйнятий результат разом із доказами та вказаним власником. Для ескалації також потрібен термін завершення або спосіб скасування, щоб відповідальність не залишилася у покинутому діалозі.
Контракти можуть формалізувати неправильну роботу
Найсильнішою заперечною точкою є високі операційні витрати. Коли один агент редагує окрему функцію, сама проблема разом із наявними тестами вже може забезпечити достатній обсяг роботи та контроль за її прийняттям. Для одноразових прототипів та незалежних дослідницьких завдань з низьким ризиком майже не потрібно нічого, крім чітких інструкцій. Створення сервісу на основі контракту лише для того, щоб переоформити такі домовленості, було б марним.
Контракти також не можуть створити намір щодо продукту чи модельну здатність, якої немає. Погане розкладення завдань залишається поганим, кореловані помилки продовжують існувати, а оракул прийняття рішень, тобто тест чи оцінка, які визначають, чи є результат правильним, залишається несправним. Припустімо, що тест від початку до кінця повторно використовує пошкоджений мок клієнта: тоді його позитивний результат повністю ігнорує первинну проблему.
З цієї причини такий дизайн варто порівняти з простішими альтернативами, включаючи одного агента чи детерміністичний робочий процес. Питання полягає у тому, чи покращує додаткова координація якість виконаної роботи чи контролює справжній ризик для поточного обсягу роботи.
Як його тестувати
Для цього елемента не було проведено жодних нових експериментів. Варто порівняти три конфігурації: одного агента (A), кількох агентів із ролевими призначеннями (B) та кількох агентів із використанням чітких контрактів делегування та вищезазначеного підходу (C).
Справедливість вимагає надання A, B та C ідентичної інформації про завдання та критерії прийнятності, порівнянних інструментів та меж безпеки, однакових початкових умов та оголошеного загального бюджету ресурсів. B та C діляться моделями та кількістю працівників, а A використовує відповідну модель, якщо це можливо. Об’єктом дослідження є механізм делегування та координації, без додаткових можливостей чи прихованих вимог з боку.
B повинен зберігати звичайні захисні заходи та корисні описи завдань. Якщо природним чином виникають чіткі угоди про передачу обов’язків, слід задокументувати таку поведінку та не забороняти її. Публікуйте справжні конфігурації, щоб порівняння не перетворювалося на порівняння оптимізованої реалізації з навмисно слабкою базовою версією.
Вибирайте завдання, які відображають реальну суміш: деякі з незалежними елементами, деякі з послідовною залежністю, а деякі — з інтерфейсами чи ресурсами, якими користуються кілька працівників. Тести повторюються у сферованих середовищах у випадковому порядку, а звичайні завдання залишаються окремо від навмисно створених помилок. Після пілотного тесту конфігурації фіксуються, завдання, які залишилися, використовуються для фактичного порівняння, а рівень невизначеності вказується з урахуванням структури залежностей.
Методологія оцінки Anthropic відрізняє текстовий запис від стану середовища, яке залишилося після його виконання, та оцінює модель разом із її інфраструктурою. Саме тут потрібно вимірювати: чи працює сторінкування у поєднаному середовищі? Те, що три агента повідомляють про завершення роботи, нічого не доводить.
Існують три основні показники: прийняті кінцеві результати, загальна вартість кожного прийнятого результату та час, що минув до його прийняття. Витрати включають невдалі спроби, координацію, повторні спроби, перевірку, налаштування та складання контрактів. Початкове налаштування відображається окремо від періодичних витрат; зазначаються будь-які припущення щодо амортизації, а людський час фіксується відкрито. Якщо нічого не було прийнято, слід вказати загальні витрати та кількість нулевих успіхів замість того, щоб показувати одиничну вартість, яка здається конкретною, але вводить в оману.
Окрім цього необхідно відстежувати збої інтеграції, дублювання роботи, збої через застарілі дані, втручання людей, порушення обсягу робіт та результати, які були відхилені після того, як їх оголосили завершеними. Спроби порушень та їх успішні випадки фіксуються окремо, а незавершені спроби та перевищення часу залишаються у звіті, щоб швидкі успіхи не приховували тривалих збоїв.
Правильне відхилення застарілого патча доводить функціональність механізмів контролю, проте завдання з використанням продукту все одно залишається невиконаним, якщо не буде прийнятий коректний результат у межах бюджету. Ранні результати пілотних проектів вказують лише на напрямок розвитку. Якщо контракти призводять до додаткових витрат без кращих результатів чи суттєвого зниження ризиків, розумною порадою є утриматися від них для цього обсягу роботи.
Почніть з одного процесу, який можна перевірити
Розумний початок – це єдиний існуючий робочий процес із двома працівниками та визначеним особою, відповідальною за прийняття результату. Перевірка інтеграції залишається поза контролем працівників, а кожен випадок збою тестується окремо перед розширенням обсягу роботи. Короткий опис у цьому форматі може бути надісланий фахівцю з програмування:
Add the minimum delegation contract to [WORKFLOW].
Acceptance owner: [OWNER].
Preserve existing safety boundaries.
1. Inspect current delegation, inputs, permissions, and acceptance.
Exit: map who assigns, executes, checks, accepts, and commits.
2. Identify missing boundaries; reuse existing issues and checks.
Exit: owner-approved scope, revisions, deliverable, and criteria.
3. Wire the minimum contract into dispatch and result handling.
Exit: references resolve; proposals cannot accept themselves; unauthorized operations are blocked by the actual runtime.
4. Exercise valid and invalid handoffs in isolated fixtures.
Exit: demonstrate acceptance, conflict rejection, stale-input detection, missing-evidence rejection, interruption recovery, bounded retries, and authority escalation. Mock external effects.
5. Report changed files, commands run, outcomes, and remaining gaps.
Exit: distinguish implemented controls from unverified behavior.
Не замінюйте платформу оркестрації та не змінюйте несуміжні елементи, а також не публікуйте, розгортайте та не розширюйте права доступу.
API, клієнт та тести все ще залежать від функціональних працівників. Зміна полягає у правилах їхньої роботи. Перш ніж об’єднана робота вважатиметься завершеною, необхідно чітко визначити, що має включати кожен внесок, хто може його прийняти та що станеться, якщо його неможливо прийняти. Назви посад ніколи не визначають цих меж.