Контракты на делегирование для команд ИИ-агентов: объем работы, критерии приемки и порядок реагирования на сбои
Почему названия должностей агентов не предотвращают сбои при передаче задач, и как можно протестировать контракт на делегирование с обязательным соблюдением правил, независимыми критериями приемки и обработкой сбоев.
Представьте себе ситуацию, когда изменение продукта реализуется тремя агентами: добавление механизма пагинации с помощью курсора в API, в клиент, который его вызывает, и в тесты. Все трое сообщают о успешном выполнении задачи, однако клиент не может распарсить данные, возвращаемые API. Агент API генерирует значение next_cursor, агент клиента ожидает значение nextCursor, а агент тестов проверяет моки, созданные на основе предположений клиента. Каждая локальная задача кажется выполненной, но в совокупности это изменение терпит неудачу при первом реальном запросе.
Обозначение агентов как Инженер, Специалист по работе с клиентами и Рецензент не указывает, какой интерфейс побеждает или кто утверждает результат. Такие решения должны быть описаны в договоре о делегировании полномочий, то есть в конкретном поручении, в котором указываются исходные данные, допустимый объем работ, требуемый результат, условия приемки и действия в случае сбоя. Ценность такого документа заключается в том, как система использует эти условия, а не в самом наличии еще одного документа.
Рассмотрим это по уровням: роль определяет, как агент подходит к выполнению задачи, в то время как договор указывает, какие вклады считаются приемлемыми. Политика выполнения решает, что агент действительно может сделать, а процедура приемки определяет, превращается ли этот вклад в готовый продукт.
Специализация оставляет процесс передачи задач неопределенным
Роль описывает определённую точку зрения, такую как поиск проблем с безопасностью, разработка клиента или критика дизайна. Контракт задачи описывает конкретное поручение: использовать эту версию интерфейса, изменить эти файлы, предоставить такие доказательства. Разрешения во время выполнения задачи определяют, что сотрудник может фактически читать, изменять или запускать.
Разделение этих аспектов позволяет полезной роли оставаться полезной, не делая её ответственной за всё. Рецензент может обнаружить нарушающие правила изменения, но не иметь права их одобрять, а инженер может предложить пересмотренный интерфейс, но не иметь полномочий сделать его официальным вариантом.
Исследования многоподразделенческой системы от компании Anthropic, проведенные в августе 2026 года, делают проблему зависимости более ощутимой. В экспериментах по созданию игр предписанные роли и иерархия в стиле генерального директора почти не менялись, и качество игр оставалось низким, даже когда некоторые модели показывали лучшие результаты по показателям координации. В том же отчете отмечается сопутствующее поведение и сопутствующие ошибки. Эти результаты получены в ходе конкретных экспериментов и не говорят ничего окончательного о каждой команде агентов; к тому же сравнения уязвимостей различаются по объему и использованию ресурсов, поэтому суммарные исходные данные не позволяют определить, что именно способствовало координации.
Существует контрпример. В техническом описании исследовательской системы компании 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, клиент и тесты по-прежнему зависят от работоспособных рабочих процессов. Изменение касается правил их управления. Прежде чем совместная работа будет считаться завершенной, необходимо четко определить, что должно входить в каждый вклад, кто может его принять и что произойдет, если его невозможно принять. Названия должностей никогда не определяют эти границы.