Один сильный агент или команда специалистов: выбор задаёт характер работы. Рейтинг модели в этом решении второстепенен, потому что архитектура определяет, что произойдёт с противоречиями во входных данных.
Одиночная количественная задача, которую нужно довести до конца, лучше решается одним агентом с длинным потоком рассуждений. Множество мелких подзадач с разными данными и разными требованиями к проверке выигрывает от команды специализированных агентов: Claude Code и Claude Skills позволяют развести роли и собрать результат по частям.
Практический кейс из планирования AI-инфраструктуры показал цену ошибки в этом выборе. Одиночная reasoning-модель усреднила противоречия между данными и выдала уверенный, но неверный вывод. Решение выросло в паттерн из пяти специализированных агентов: каждый решает свою задачу и возвращает типизированный результат с уровнем уверенности и свежестью данных, а координатор называет противоречия явно и не сводит их к среднему.
Почему один сильный агент не всегда справляется с AI-задачей
Ограничение проявляется на данных, которые расходятся друг с другом. Чем больше источников получает агент, тем выше шанс конфликта, и тем важнее, как система с этим конфликтом обходится.
Как одиночная reasoning-модель усредняет противоречия
Схема ошибки повторяется от задачи к задаче. Агент собирает несколько источников: выгрузку метрик, заметки инженера, историю инцидентов, прошлый прогноз. Данные расходятся. Один источник говорит о росте нагрузки, второй о падении, третий содержит срез недельной давности. Модель не выносит конфликт отдельным пунктом. Она строит единое связное представление, в котором расхождения сглажены, и заканчивает вывод уверенной формулировкой.
Уверенный тон ничего не сообщает о корректности. Модель, усреднившая два взаимоисключающих сигнала, звучит так же ровно, как модель на согласованных данных. Сравнение из аналитики: если сложить прогноз из отчёта A и противоположный прогноз из отчёта B, получится среднее, которого не давал ни один автор. Противоречие исчезло из ответа, а решение принято на числе без источника.
Корень в архитектуре одиночного потока. Reasoning-модель обучена выдавать связный текст, и связность достигается в том числе за счёт сглаживания несогласованных фрагментов. Один агент отвечает и за сбор фактов, и за их примирение, и за финальный вывод, поэтому внутренний конфликт данных некуда вынести. Это свойство схемы, а не следствие неудачного промпта.
Когда одного сильного агента достаточно: пример Codex
Есть класс задач, где одиночный агент даёт лучший результат. Признаки: одна цель, один тип результата, внутренняя логика не распадается на независимые ветви, конфликтующих источников нет по определению. Расчёт по одному набору данных, генерация кода по спецификации, разбор одного лога, доведение численной задачи до финального значения укладываются в единый поток.
Codex ориентирован на код и количественные задачи: он держит длинную цепочку шагов и доводит работу до конца. Наглядный разбор того, как выглядит выбор модели под agentic coding, есть в материале про 120 прогонов на самопроверяемых задачах: там сравнивают не общее впечатление, а число ошибок вызовов, успешность прогонов и расход входных токенов.
Ключевое условие - право на длинную цепочку шагов без промежуточных согласований. Как только появляется необходимость сверять независимые показатели, проверять конфликтующие источники или отдавать результат с метаданными, один агент начинает проигрывать.
Паттерн из пяти специализированных агентов: как устроена команда
Схема, которая закрывает проблему усреднения, строится из двух уровней. Первый - пять специализированных агентов, каждый отвечает за свою зону ответственности и не лезет в чужую. Второй - координатор, который собирает результаты и работает с расхождениями. Типовое разделение ролей в такой схеме: извлечение данных, проверка свежести, расчёт или оценка, контроль рисков, итоговая формулировка. Набор ролей подстраивается под домен, неизменным остаётся принцип разделения.
Логика близка к Agentic RAG: система планирует, реформулирует и повторяет извлечение вместо одного фиксированного поиска перед генерацией. Карта работы включает пять этапов, среди них интерпретация вопроса и того, каких доказательств не хватает, выбор источника или способа поиска, переформулировка и проверка, синтез только после сбора доказательств. Внешне похожий одношаговый RAG с одним запросом и одним извлечённым контекстом выглядит как то же самое, но меняет причинно-следственную историю: другие доказательства подтверждают успех, другие ресурсы определяют стоимость, другие механизмы контроля предотвращают вред.
Типизированный результат: уверенность и свежесть данных
Агент возвращает структуру с полями: результат, уровень уверенности, свежесть данных, источник. Свежесть принципиальна не меньше уверенности: срез недельной давности и срез часовой давности описывают реальность по-разному, и смешивать их в одном выводе нельзя.
Пример. Один агент даёт прогноз с уверенностью 0.9 на свежих данных, второй - с уверенностью 0.6 на устаревших, причём прогнозы расходятся. Координатор показывает конфликт: свежий сигнал противоречит устаревшему, вес у них разный. Среднее между ними не описывает ни одну из картин.
Формат структуры задаёт команда, универсального стандарта нет. Важно одно: поля заполняются одинаково всеми агентами. Иначе координатор снова получит несовместимые куски текста и вернётся к тому же усреднению.
Координатор, который называет противоречия, а не сглаживает их
Работа координатора - сравнение, не синтез. Он раскладывает типизированные результаты по осям уверенности и свежести, находит расхождения и выносит их отдельным пунктом ответа. Если два агента дают разные ответы, координатор возвращает оба с пометкой о конфликте и не сворачивает их в одно число.
Практическая выгода в том, что решение переходит к человеку с готовым описанием развилки. Видно, какие данные расходятся, насколько свеж каждый источник, где уверенность низкая. Вместо иллюзии консенсуса пользователь получает карту риска с явно помеченными развилками.
Пример Fyxer: 30-50 микромоделей вместо одной
Похожий принцип в проде реализовала компания Fyxer, ИИ-ассистент для руководителей. Инженеры отказались от идеи одной большой модели для обработки почты и разбили процесс на систему из 30-50 узкоспециализированных микромоделей.
Конвейер выглядит так. Первая модель-классификатор решает, нужен ли ответ, требуется ли назначить встречу или это информационное сообщение. Дальше другие алгоритмы определяют намерения отправителя и прогнозируют вероятный исход диалога. Отдельная система памяти и извлечения решает, какие детали из прошлых переписок важны сейчас. Генерация текста запускается только после сбора контекста.
Для обучения компания накопила датасет более чем из 500 тысяч часов задокументированных рабочих процессов. Это позволило применить контролируемое дообучение (supervised fine-tuning) и метод низкоранговой адаптации LoRA для создания специфических версий моделей под каждую микрозадачу. Сооснователь Fyxer Арчи Холлингсворт связывает сложность такой декомпозиции с парадоксом Моравека: то, что легко для человека, трудно для алгоритма.
Обратная связь работает на правках пользователей. Когда человек редактирует черновик перед отправкой, система фиксирует разницу, и эти данные превращаются в обучающую выборку через метод прямой оптимизации предпочтений (DPO). Каждое изменение проходит A/B-тестирование и попадает в прод только при статистически значимом улучшении. По данным компании, 53% писем пользователи отправляют без правок, регулярная годовая выручка выросла с 1 до 32 млн долларов за 2025 год, а удержание после 90 дней превышает 90%.
Цифры принадлежат компании, независимого подтверждения в разборе нет. Относиться к ним стоит соответственно: как к заявленным результатам вендора, а не как к воспроизведённому бенчмарку.
Codex или Claude Code и Claude Skills: что выбрать под характер работы
Сравнение упирается в один вопрос: распадается задача на независимые части или нет. Есть и второй фактор, который часто недооценивают: выбор обвязки вокруг агента. Контролируемый эксперимент в материале про архитектурные ставки обвязок кодинг-агентов показал, что смена harness влияет на результат сильнее, чем смена модели, поэтому архитектуру выбирают вместе с инструментом, а не после него.
Одиночная количественная задача до конца: когда Codex эффективнее
Признаки: цель одна, результат одного типа, сбор противоречивых данных из разных источников не нужен. Примеры - расчёт по одному набору данных, генерация кода по спецификации, разбор одного лога, доведение численной задачи до финального значения.
Codex ориентирован на код и количественные задачи: длинный поток рассуждений и доведение работы до конца без постоянного ручного контроля. Плюс схемы в отсутствии накладных расходов на координацию: не нужно описывать протокол обмена, следить за согласованностью форматов и разбирать конфликты между агентами. Минус в другом: при противоречивых входных данных ошибка сглаживания возвращается, и уверенный ответ снова может оказаться неверным.
Оркестрация множества мелких подзадач: когда Claude Code и Claude Skills выигрывают
Другой класс задач распадается на десятки мелких шагов, у каждого свои данные, свой уровень уверенности и своя цена ошибки. Claude Code и Claude Skills позволяют развести эти шаги по ролям и собрать результат по частям. Обработка почты из примера Fyxer устроена ровно так: классификация, определение намерений, retrieval, генерация - четыре разных микрозадачи, и под каждую настроена своя модель.
Цена схемы в сложности. Нужны единый формат результата, координатор, который называет противоречия, и дисциплина в поддержке всего этого. Без них команда агентов превращается в источник шума: пять уверенных ответов, которые не сходятся между собой и не сводятся в решение.
Критерии выбора: количество подзадач, необходимость параллельной проверки конфликтующих источников, требования к типизированному результату, готовность вкладываться в координацию. Если хотя бы два пункта из четырёх указывают на распад задачи, команда окупается.
Калибровка прогнозов: P90 и бэктест покрытия
Уровень уверенности из типизированного результата имеет смысл только после калибровки. P90 - это квантиль, который показывает, что 90% фактических значений должны попадать ниже прогноза. Количественная граница задаёт требование: заявленный интервал совпадает с реальным покрытием.
Бэктест покрытия проверяет, так ли это на практике. Прогнозы за период сопоставляются с фактом, и считается доля случаев, когда значение уложилось в заявленный интервал. Если агент говорит об уверенности 90%, а в бэктесте в интервал попадает 60% случаев, калибровка нарушена, и число 0.9 в ответе вводит в заблуждение сильнее, чем его отсутствие.
Нарушенная калибровка ломает всю конструкцию. Координатор сравнивает результаты по уверенности и свежести, и если уровни уверенности не откалиброваны, сортировка по ним бессмысленна. Настройка требует регулярной работы: калибровка дрейфует вместе с данными и версией модели.
Автоматические алерты, право на откат и маршрутизация по уровню риска
Автоматические алерты и действия опасны без заранее согласованного права на откат. Если система ошиблась, а действие ушло во внешний контур, вернуть состояние нечем. Право на откат согласуют до внедрения: что именно откатывается, за какое время, кто запускает процедуру, какие данные для этого нужны.
Маршрутизация решений к человеку строится по уровню риска, а не по типу операции. Тип операции отвечает на вопрос, что делаем. Уровень риска отвечает на вопрос, чем платим за ошибку. Типовая операция с высоким риском требует подтверждения человеком; нетиповая, но дешёвая в откате может идти автоматически. Разбор границы между возможностями агентной модели и практическим риском есть в материале про надёжность агентных моделей.
Рабочая иллюстрация - агент Ace, развёрнутый TSA. Он обрабатывает около 100 000 типичных разговоров с путешественниками в месяц и закрывает 96% типичных запросов без человека, остальные уходят людям. Salesforce оценила совокупный эффект цифровой стратегии TSA в экономию более 11 660 часов персонала в год и 11 млн долларов за три года, а сам Ace сократил стоимость взаимодействий с потребителями более чем на 90%. Схема держится на том, что автоматика ограничена типовым сценарием, а всё выходящее за рамки эскалируется по риску, а не по названию операции.
Ограничения подхода: малая выборка, привязка к моменту, зависимость от документации
Три ограничения стоит держать в голове, прежде чем переносить паттерн в свой проект.
- Малая выборка. Выводы о выборе архитектуры выросли из ограниченного числа задач в одном домене. Экстраполировать их на любой процесс нельзя: другой домен даёт другой набор подзадач и другой профиль риска.
- Привязка выбора моделей к текущему моменту. Разделение «Codex для одиночной количественной работы, Claude Code и Claude Skills для оркестрации» отражает состояние инструментов на сентябрь 2026 года. Версии обновляются, сильные стороны смещаются, критерий придётся пересматривать. Практический чек-лист для такой переоценки собран в разборе про оценку новых AI-моделей без шума вокруг релизов.
- Зависимость от качества документации. Агент работает на том, что описано. Если регламенты противоречат друг другу или устарели, никакая декомпозиция не спасёт: команда из пяти агентов аккуратно воспроизведёт хаос в документации, причём с высоким уровнем уверенности в каждом ответе.
Паттерн из пяти агентов решает узкую задачу: не даёт усреднить противоречия и потерять их по дороге к выводу. Универсальной архитектурой для любых AI-задач он не становится, и заявлять обратное было бы преувеличением.
Как выбрать архитектуру под свою задачу: практический чек-лист
- Задача цельная или распадается на подзадачи? Если результат один и его нельзя разбить на независимые части, берите одиночного агента.
- Нужна ли параллельная проверка противоречивых источников? Если данные приходят из нескольких систем и могут расходиться, одиночный поток начнёт усреднять.
- Требуется ли типизированный результат с уверенностью и свежестью? Наличие такого требования почти всегда означает координатора и несколько ролей.
- Есть ли право на откат для автоматических действий? Нет процедуры отката - нет автоматизации write-операций, независимо от качества модели.
- Как маршрутизируются решения по уровню риска? Тип операции не должен быть единственным триггером эскалации к человеку.
- Готова ли документация? Противоречивые регламенты превращают любую мультиагентную схему в генератор уверенных ошибок.
Если задача цельная и количественная, начинайте с одного сильного агента: Codex, единый промпт, одна метрика качества, длинная цепочка шагов без промежуточных согласований. Если задача распадается на множество мелких подзадач с разными данными, собирайте команду: Claude Code и Claude Skills для оркестрации, типизированный результат на выходе каждого агента, координатор, который называет противоречия вместо их сглаживания.
Дальше проверяйте схему на своей выборке, калибруйте уровни уверенности через P90 и бэктест покрытия, фиксируйте право на откат до первого автоматического действия. И помните про три ограничения: малый объём наблюдений, быструю смену моделей и качество документации. Архитектура, выбранная под характер работы, переживёт смену версии модели. Архитектура, выбранная под хайп вокруг конкретного релиза, не переживёт и квартала.