Практические выводы из 11 сборок программного обеспечения с использованием нескольких агентов без программных шаблонов

Ключевые технические выводы из экспериментов с мультиагентными системами

Анализ 11 автономных программных сборок с несколькими агентами без программных лесов, основанный на 295 млн токенов, 98 сессиях агентов и 6,1 млн строках вывода работников, раскрывает практические инсайты для разработчиков, работающих с ИИ-агентами для программирования.

Обеспечение соблюдения области и оркестрация

Обеспечение соблюдения области решается механически, а не через промпты: Подходы на основе промптов провалились 0/20 раз под давлением компилятора, в то время как механические подходы (позволяющие агентам редактировать всё и используя git revert для файлов вне области) увенчались успехом 20/20 раз. Ключевой инсайт: не просите модели уважать границы — обеспечивайте их соблюдение постфактум.

Затраты оркестратора ограничены памятью: Примерно 95% входных расходов приходится на перечитывание истории разговора. «Премия за состояние» означает, что передовой оркестратор, который не пишет ни строчки отгружаемого кода, может стоить столько же, сколько весь флот работников. Оптимизация должна быть направлена на меньшее количество ходов и меньшее повторное поглощение, а не на более дешёвые рассуждения.

Динамика координации и масштабирования

Модели не обнаруживают координацию самостоятельно: Opus с голыми промптами и полным доступом к инструментам никогда не делегировал, никогда не писал спецификации и никогда не обнаруживал параллельную диспетчеризацию — он просто строил всё в одиночку. Шаблон координации выполняет реальную работу.

Глубина масштабируется иначе, чем качество: Плоская диспетчеризация превосходит иерархию при ≤10 доменах по пропускной способности, эффективности токенов и реальному времени. При более чем 10 доменах иерархия обеспечивает параллелизм, недостижимый для плоской диспетчеризации.

Одиночная работа превосходит координацию, пока не сработают ограничения контекста: Пропускная способность одиночного агента составляет примерно 325 LOC/мин и не зависит от размера проекта. Пропускная способность пирамиды масштабируется с количеством работников. При объёме ниже ~30K LOC делегирование — это чистая накладная нагрузка.

Производительность работников и системы типов

Возможности модели работника определяют пропускную способность: Одна и та же архитектура, одна и та же спецификация, три модели работников дали результат: 17 761 LOC против 6 001 против 1 818 — разрыв в 9,8 раза. Архитектура обеспечивает параллельную пропускную способность; модель работника её определяет.

Контракты типов обеспечивают общий словарь: Интеграция успешна без контрактов при любом масштабе, который тестировался (6–36 модулей), даже при ограничениях только на чтение. Но без контрактов параллельные работники молча производят структурно несовместимые типы, которые компилируются только потому, что ничто на них не ссылается. Единственный слепо написанный контракт на 984 строки сохранялся в 10 независимых доменах.

Контракты типов устраняют накладные расходы на координацию при масштабировании: Контролируемый тест масштабирования (1–20 работников, фиксированная спецификация) показал нулевые ошибки интеграции в 50 сборках доменов. Оптимальная точка при 10 работниках: ускорение реального времени в 2,05 раза. При 20 работниках зависимости серийной фазы сводят на нет выгоды от параллелизма (серийная доля Амдала ~44%).

Контекст и шаблоны делегирования

Подготовка контекста работает; формат не важен: 0% передачи формулы «на холодную», 100% при наличии контекста дизайна (N=10 на условие). Статический справочный документ даёт идентичные показатели передачи, что и синтетическая загрузочная беседа.

Сжатие делегирования присуще процессу: Каждый слой делегирования действует как потерянный суммаризатор. Количественные требования («80 оружия») исчезают; структурные требования (интерфейсы типов) сохраняются. Исправление: работники должны читать полные спецификации из файловой системы, а не полагаться на сжатые цепочки промптов.

Восстановление после уплотнения надёжно при хороших суммаризациях: Нулевой рецидив задач в 11 событиях уплотнения. Модель сообщает ожидаемое состояние, затем читает диск для проверки.

Режимы сбоев и исправления

• Рефлекс абстракции: Строит оркестратор вместо оркестрации — укажите это в промпте
• Ошибка само-модели: Заявляет о ложных возможностях — документируйте доступные инструменты явно
• Парадокс идентичности: Не может удерживать двойные роли — используйте отдельные экземпляры модели
• Сжатие делегирования: Используйте перечислительные спецификации плюс доступ к файловой системе