Один агент или команда: как выбрать
Практика · учебный пример, мы ничего не запускали
Заранее нельзя сказать, что лучше: один агент или команда. Выбор проверяют прогонами на своих примерах. Результат — таблица прогонов и правило маршрутизации.
Числа взяты из одного показательного учебного прогона и из оценок того, кто его вёл. Мы прогоны не повторяли. Схема B не запускалась. Компания и сотрудница Мая вымышлены.
Три схемы работы
Схема работы — способ организовать агентов для одной задачи. Координатор раздаёт задачи и собирает ответ. Аналитик ищет причину. Ревьюер проверяет вывод аналитика. В схеме C координатор пишет черновик, аналитик и ревьюер дают замечания, координатор пишет финальный ответ.
Схема A: один агент
Схема B: один проход
Схема C: с возвратом черновика
Читайте схемы слева направо. Связи по тексту:
- A: один агент получает задачу и пишет ответ.
- B: координатор поручает задачу аналитику и ревьюеру, получает их выводы и пишет ответ.
- C: как B, но координатор пишет черновик и отправляет его на замечания. Затем он пишет финальный ответ.
Что команда даёт и что берёт
| Даёт | Берёт |
|---|---|
| Чистый контекст: свежий ревьюер видит ошибку | Налог на координацию: связей больше, чем участников |
| Роли и проверки в трассировке | Налог на онбординг: каждому агенту снова отправляют промпт и контекст |
| Параллельность | Глухой телефон: координатор пересказывает и может исказить |
| Дешёвые модели для простых подзадач | Наводящая постановка: «я решил, подтверди» |
Anthropic пишет: агенты тратят примерно в 4 раза больше токенов, чем чат. Мультиагентные системы — примерно в 15 раз. Их система обошла одиночный Opus 4 на 90,2% во внутренней оценке исследовательских задач.
Передача данных: файл + ссылка
Координатор не пересказывает данные. Смысл не искажается, и контекст координатора остаётся чистым. Пересказ через координатора несёт риск искажения.
Учебный инцидент
Компания оплатила доступ для Маи в 10:03. В 10:07 Мая пыталась забронировать место и получила отказ с надписью «Payment pending». Причина: в коде участник должен совпадать с плательщиком. Для корпоративной оплаты это неверно.
Сначала предскажите результат
Семь проверок записывают как тесты: вход и ожидаемый результат. Таблицу ответов смотрите после выбора.
| № | Случай | Ожидаемый результат |
|---|---|---|
| 1 | Компания оплатила за сотрудника. Новое бронирование. Места есть. | Забронировать. Случай инцидента: сейчас не проходит. |
| 2 | Участник оплатил сам за себя. Места есть. | Забронировать. |
| 3 | Сотрудника убрали из программы компании. | Отказать. |
| 4 | Это не участник. Он только прислал оплаченный счёт. | Отказать. |
| 5 | Участник. Мест нет. Брони нет. | Лист ожидания. |
| 6 | Участник. Бронь уже есть. Мест нет. | Вернуть существующую бронь. |
| 7 | Участник. Повторный запрос. Старая бронь есть в системе. | Вернуть существующую бронь, без второго места. |
Значения 2–7 мы восстановили сами по описанным правилам. Порядок правил: бронь есть → вернуть её. Иначе условия выполнены и место есть → забронировать. Иначе условия выполнены, мест нет → лист ожидания.
Результат учебного прогона: A против C
| Схема A | Схема C | |
|---|---|---|
| Причина найдена | да | да |
| Надпись «Payment pending» названа вводящей в заблуждение | отмечено без указания надписи | отмечено явно |
| Время | около 1 минуты | около 2,5 минуты |
| Токены | гораздо меньше | около 130 тыс. |
| Стоимость | базовая | по оценке ведущего, в 3–4 раза выше |
Аналитик в схеме C нашёл ответ на 43-й секунде. Остальное время ушло на проверки и координацию. Прогон один. Схема B не запускалась.
Тренировка маршрутизатора
Маршрутизатор — правило или агент, который выбирает схему работы по признакам задачи. Выберите схему для каждой задачи. Ответы участников разбора — под выбором.
| Задача | Позиция разбора |
|---|---|
| Поменять надпись | Один агент. Все участники согласились. |
| Три системы | Мнения разделились. Ведущий: один агент, если нужны знания из всех трёх систем. Команда — если контекст не помещается в окно, нужна ширина взгляда или скорость. |
| Ревью кода про доступ | Команда. Все участники согласились. |
Это позиции участников, не замеры.
Правило маршрутизатора: образец
Это учебный образец, не измеренное правило. Замените его правилом из своих прогонов. Человек пересматривает правило по журналу.
Шаги
- Выберите одну повторяющуюся задачу. Соберите 5–20 случаев с известным правильным ответом.
- Запишите проверки как тесты до запуска. Включите случай, который сейчас не проходит.
- Запустите схему A на каждом случае. Запишите верность, время и токены.
- Запустите схему C (и схему B, если нужна). Передавайте данные файлом и ссылкой.
- Повторите каждую схему несколько раз.
- Сравните: сначала верность, затем время, затем токены.
- Если схема C не лучше схемы A по верности, оставьте схему A.
- Запишите правило маршрутизации: признак задачи → схема.
- Пересматривайте правило по новым случаям.
Промпт для агента-исследователя
Это наша конструкция, в источнике промпта нет. Он ставит только исследование и ничего не исправляет.
Ты исследователь инцидента. Найди причину инцидента: [описание инцидента, время, пользователь].Твои источники: [список источников: дашборд, обращения, записи системы, код и правила, лог].Читай только эти источники. Код и данные не меняй.Сначала запиши, что ты будешь проверять и что ожидаешь увидеть. Только потом читай логи.Оцени каждый источник: относится он к инциденту или это шум. Объясни кратко.Назови реальную причину и покажи доказательство: строку лога или правила.Сравни реальную причину с текстом ошибки, который увидел пользователь. Если они расходятся, напиши это отдельной строкой.Прогони проверки: [список проверок, каждая с входом и ожидаемым результатом]. Для каждой напиши, какой результат даёт текущая логика и почему. Проверку, которую ты не смог выполнить, пометь как не проверенную.Если нужного источника нет, назови его. Не придумывай данные.В конце напиши: причина, доказательство, расхождение с текстом ошибки, проверки, что осталось неизвестным. Исправление кода не предлагай.Как проверить результат
- Причина названа и подтверждена строкой лога или правила.
- Шум отделён от значимых источников.
- Расхождение между текстом ошибки и причиной названо отдельно.
- По каждой проверке есть результат. Не проверенные помечены.
- В трассировке есть вызовы инструментов. Если вызовов 0, повторите запуск.
Если схема C на ваших случаях не лучше схемы A по верности, оставьте схему A. Если ошибка затрагивает деньги или доступ клиента, а ответы расходятся между запусками, спросите человека.
Ограничения
- Прогоны мы не повторяли. Числа взяты из одного показанного прогона и из оценок ведущего.
- Схема B не запускалась.
- Оценка «в 3–4 раза дороже» относится к условиям ведущего.
- Научные работы, на которые ссылались участники, мы не нашли и не цитируем.
- Сам маршрутизатор стоит денег. Его работу можно измерить.
Источники
- Anthropic, How we built our multi-agent research system, 13.06.2025.
- Фредерик Брукс, «Мифический человеко-месяц» (1975): закон Брукса, аналогия для агентов.
- Дональд Кнут (1974): «преждевременная оптимизация — корень всех зол». Идея: начинать с простой схемы.
- Показательный учебный прогон: источник цифр времени, токенов, оценки стоимости и голосования.
- Наша конструкция: ожидаемые результаты проверок 2–7, промпт, образец правила.
- Слой ИИ-индустрии: Applications. Организация работы агентов в процессе. Новых моделей и чипов нет, есть вопрос счёта.
- Уровень специалиста: 4 — Архитектор. Он решает, добавлять ли субагентов, считает токены и пишет проверки до запуска.
- Уровень компании: 3 — повторяющиеся задачи и замер. Инциденты, поддержка, ревью, где разница в 3–4 раза по цене видна в бюджете. Оценка применимости, не результат внедрения.