Мультиагенты: сначала выжать максимум из одного агента

Первый вопрос перешёл с прошлого эфира: компенсируют ли слои вокруг модели — ревьюеры, эвалюаторы, декомпозиция задач в md-файлах — её собственную силу и где предел локальной модели. Александр делит вопрос надвое: декомпозиция и оркестрация относятся к обвязке, а эвалы — к верификации результата. Обвязку постоянно переписывают под возможности более сильных моделей, а харнеса, специально настроенного под тридцатимиллиардную модель для макбука или потребительской видеокарты, он не знает: собирать свой долго и дорого. Эвалы, наоборот, пригодятся с любой моделью. Экономия не гарантирована: локальный инференс хорош для экспериментов, но в мультиагентном режиме упираешься в токены в секунду. Алексей считает, что слабость модели компенсируется почти полностью, вопрос лишь в цене усилий: в его учебной Telegram-группе в тот же день писали, что Qwen на 480 миллиардов параметров не тянет задачи, которые с той же обвязкой проходит Opus. Александр же напоминает слова Бориса Чёрного о Claude Code: обвязку строят под модель, которая появится через три-шесть месяцев, — это подпорки под слабости конкретного поколения.

Следующий вопрос читает Алексей: как на практике доказать пользу мультиагентного режима против одноагентного и какие сценарии делают его выгодным, а какие — пустой тратой лимитов. Из исследований известно, что планировщик, исполнитель и проверяющий работают лучше как разные агенты: один исполнитель смещён к самоподтверждению. Но каждый агент заново стартует и загружает контекст, а на задаче не самой маленькой размерности видно, как система перепроверяет перепроверяющих и ищет эджкейсы, с которыми проект без миллионной базы пользователей не столкнётся. Отсюда аналогия с дорогой: двести километров в час проехать можно, но надёжность доезда падает, а на просёлочной и восемьдесят много. Повод для вопроса — знакомый, который распараллелил всё через оркестрацию в Codex и перестал понимать происходящее: агенты начали пересылать друг другу сообщения. Совет простой — не уходить в мультиагентность, пока одноагентный режим не упрётся в доказанное ограничение. Александр включает режим с сабагентами, когда требования уже зафиксированы спекой, а второе мнение получает иначе: просит соседнюю модель провести аудит ветки.

Вопрос из прошлого списка: публичные модели на работе запрещены, есть только self-hosted Qwen — можно ли получить результат, хоть немного близкий к топовым? Александр вспоминает, как из нежелания платить за зарубежные модели собирал локальный аналог Lovable на модели в 80 миллиардов параметров: простые страницы по промпту выходили неплохо, а на задании со сложным образцом результат разъезжался. Отсюда рецепт: нарезать задачи до размера, с которым модель справляется, и объяснять ей как джуну — либо выгрузить метаинформацию в умную модель, попросить у неё план с предсказуемыми шагами, входами, выходами и проверками, а исполнение отдать локальной. Похожим образом можно собрать data scout по датаплатформе, по данным которой его коллеги делали исследование: заранее неизвестно, что там чувствительное. Из чата приходит вопрос слушателя из европейской бигфармы, который из-за AI Act смотрит в сторону on-premise: Алексей напоминает, что регламент действует со 2 августа, требует явного согласия на использование данных и грозит серьёзными штрафами, а в компаниях тем временем цветёт shadow AI с личных подписок.

Вопрос из Telegram описывает сервис средней сложности на три-пять инженеров: документации нет, требования неизвестны и спустя полтора года, вокруг фрагментированный контекст из десяти-пятнадцати команд в одно рукопожатие и исторические недокументированные костыли. Алексей отвечает, что путь почти такой же, как без агентов. Сначала замкнутый цикл обратной связи, где реальность наказывает агента хуками и падающими тестами, и условие завершения, сформулированное до старта и проверяемое снаружи. Даже не понимая сервис целиком, можно описать наблюдаемое поведение: если это рассылка, письмо должно уходить и содержать имя, а не квадратные скобки. Дальше — характеризационные тесты вокруг изменяемого куска, фиксирующие текущий вывод системы, а за ними интеграционные проверки, сравнение скриншотов, линтеры и контроль связей между пакетами; иногда, как в науке, приходится написать инструмент, который проверяет результат. Организационную дисфункцию техника не лечит: сгенерированные схемы C4, которые некому прочитать и за которые никто не отвечает, лишь множат артефакты — сломался, по словам Алексея, не искусственный интеллект, а естественный.

Вопрос из LinkedIn про информационную безопасность: как не передавать исходники третьим лицам через корпоративную LLM. Алексей начинает с модели угроз — код редко оказывается главным секретом, а уязвимости живут по всей цепочке: обвязка, модель, инструментальный шлюз, недоверенный репозиторий, атака на цепочку поставок. Полная изоляция возможна, но это капекс: своя обвязка, своя инфраструктура и команды под них; самая дешёвая сборка, которую вспомнили участники, стоила около ста тысяч долларов. Компромисс — корпоративный шлюз, отфильтровывающий секреты и персональные данные; защита ценой автозавода бизнесу не нужна. Александр описывает логику безопасников как лестницу: безопаснее всего агент, который нигде не развёрнут, следом — без сети, потом через прокси и только по пустому allowlist. Следующий вопрос — про моральные принципы агентов. Алексей берёт те, что пережили тысячелетия: не вредить, не обманывать, не халявить. Строгая обвязка ловит лишь проекции, а встречать модель нужно на уровне смыслов. Александр в ответ вспоминает книгу об алайнменте: сахарозаменители и контрацепция показывают, как люди обходят настройки эволюции.

Практическая часть — как тратить меньше токенов в масштабах компании. Александр советует раздавать бюджет не на людей, а на проекты и задачи, считать стоимость действия и сравнивать её с ценой прежнего процесса; для этого нужны шлюзы с атрибуцией и квотами. Когда появляются трейсы и эвалы, в шлюз можно встроить автоматический роутинг по типу задачи — обоснованный собственными измерениями, а не публичным рейтингом модели. Алексей приводит внутренний замер знакомого директора по инженерии: пул-реквесты, отревьюенные дорогой моделью, доезжали до прода примерно в 75% случаев против 57–60% у модели в двенадцать раз дешевле; цифры он называет приблизительными, и это не публичный бенчмарк. Токенмаксинг Алексей считает ложной метрикой: мерить надо изменение продакшена, а в пересказанном интервью компания заливала около четырёх тысяч мерджей в день, пока рейтинг приложения падал. Александр подводит итог: токены — топливо, но важнее, куда едет машина; если команда быстро красит кнопки, аудит нужен не технике, а бэклогу.