Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Усложнение архитектуры само по себе не помогает ИИ-агенту надёжнее выполнять корпоративные процедуры. В работе Amazon и University of Washington только исправленный оркестратор значимо обошёл одного агента, хотя препринт не рецензирован, а числа получили сами авторы. Для нового продукта это делает одного агента исходной архитектурой, которую стоит менять лишь после замеров на собственных процедурах.
Как отделили архитектуру от модели и инструментов
Эксперимент построили на стандартных операционных процедурах (SOP): длинных инструкциях с ветвлениями, вызовами инструментов и решениями, которые зависят от предыдущих шагов. Сравнение охватило 13 процедур из SOP-Bench — от проверки бизнеса и обработки опасных грузов до разметки видео и приёма пациента.
Во всех запусках использовали claude-opus-4-8, одинаковые задания и одинаковый набор инструментов. Внешние сервисы заменили детерминированными имитациями: один и тот же вызов всегда возвращал одинаковый результат. Поэтому разница между вариантами возникала из-за управления контекстом, разделения работы и описания навыков, а не из-за сбоев API.
Восемь вариантов представляли четыре подхода. Базовый агент видел процедуру целиком и сам вызывал инструменты. Агент с навыками загружал подходящую инструкцию и получал только объявленные в ней инструменты. Централизованный оркестратор делил работу между исполнителями, а рой специалистов передавал управление между агентами через общее состояние процесса.
Успех засчитывали, только если итог совпадал с эталоном по всем полям. Процедуры учитывали с равным весом: иначе множество похожих задач внутри одной простой процедуры могло бы скрыть провал на другой.
Исправление оркестратора изменило результат сильнее, чем выбор семейства
Один агент успешно выполнил 67,4% задач. Первая версия оркестратора справилась с 58,2%: исполнители видели изолированные фрагменты процедуры, не могли запросить недостающие данные и возвращали заглушки вместо решения.
Во второй версии каждый исполнитель получил полную процедуру и все инструменты. Система потребовала обосновывать решение, добавила повторную отправку задания и проверку результата. Доля успеха выросла до 75,6%, и этот вариант оказался единственным, который статистически значимо обошёл базового агента.
Рост точности потребовал в 4,7 раза больше токенов и увеличил задержку в 3,1 раза. Получился не общий аргумент в пользу нескольких агентов, а пример того, как конкретный разрыв в передаче контекста меняет итог сильнее, чем название архитектуры.
Навыки дали похожий урок. Хорошие определения помогали на части длинных и ветвящихся процедур, а испорченные опускали результат ниже базового. В одном случае навык заменил ключ в схеме ответа: решение оставалось почти правильным по смыслу, но проверка не могла его принять.
Рою специалистов хватало общего описания этапов. Жёсткий порядок не повышал точность, зато заставлял выполнять лишние шаги и иногда отменял допустимый ранний выход. Дополнительная структура помогала только тогда, когда закрывала конкретный пробел в маршрутизации.
Работу проверяли на синтетических инструментах, одной семье моделей и одном результате для каждой задачи. Связь между сложностью процедуры и пользой развитой архитектуры видна лишь как тенденция и статистически не подтверждена. Кроме того, часть результатов оркестратора для многочастных ответов остаётся предварительной: исправление ошибки разбора там не проверили.
Что менять в планах разработки
Для первой версии системы достаточно одного агента, который видит процедуру целиком и имеет доступ к нужным инструментам. Такой вариант проще наблюдать и отлаживать, а в эксперименте ни одна другая архитектура не оказалась одновременно дешевле и точнее.
Переходить к оркестратору стоит после разбора конкретных ошибок. Если агент теряет независимые ветви, переполняет контекст или не может удержать промежуточное состояние, разделение работы может помочь. Если причина в неверной схеме ответа, недоступном инструменте или неясном правиле остановки, добавление агентов лишь размножит дефект.
Навыки следует проверять как исполняемые компоненты, а не как справочные тексты. Тесты должны покрывать выбор навыка, область доступных инструментов, обязательные поля ответа, условия раннего завершения и неоднозначные маршруты. Особенно опасны ошибки, при которых агент завершает процедуру без сбоя, но возвращает результат в неподходящем формате.
Сравнивать варианты нужно на реальных процедурах продукта и сразу учитывать три показателя: долю полностью успешных задач, расход токенов и задержку. Универсального порога окупаемости работа не задаёт: дополнительная точность должна покрывать стоимость вычислений и ожидания именно в конкретном процессе.
Для решений о блокировке аккаунтов, модерации, проверке бизнеса или доступе к медицинской услуге одного процента успеха недостаточно как критерия запуска. Нужны проверяемый отказ от ответа, аудит шагов и участие человека там, где ошибка меняет права или доступ пользователя.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
