Sub-agents are just wrong

Агент autofix в Polylane изначально строился как workflow из нескольких субагентов, каждый из которых отвечал за одну задачу:

• триаж, который разбирает тысячи алертов и сигналов
• координатор, управляющий субагентами
• до пятнадцати субагентов, исследующих все возможные гипотезы по проблеме
• и кодинг-агент, который в итоге отправляет pull request

Подтверждённая проблема могла задействовать до 18 агентов и субагентов для расследования и исправления. Сегодня ту же работу выполняет один агент.

Такой workflow был разумным решением, исходя из того, что мы знали на тот момент: небольшие промпты, небольшие наборы инструментов, оркестратор, переносящий результаты между специализированными агентами. Однако он был крайне дорогим, сложным в эксплуатации и трудным для анализа.

Что такое проблема (issue)?

Polylane сканирует логи, метрики и трейсы каждого облачного ресурса (Lambda-функция, Cloudflare Worker, проект Vercel и т. д.) у каждого подключённого провайдера. Для каждого ресурса мы храним базовые уровни на нескольких горизонтах, чтобы учитывать сезонность в данных. Затем мы оцениваем текущее состояние облачного ресурса и сравниваем его с историческими данными. Значения, выходящие за пределы базового уровня, фиксируются как проблемы.

Проблемы также могут создаваться алертами, которые мы получаем от решений для наблюдаемости и отслеживания ошибок.

Как мы решаем проблемы?

Чтобы решить проблему, нужно:

1. Провести триаж: собрать данные, чтобы подтвердить или отклонить проблему.
2. Расследовать: оценить несколько гипотез и определить первопричину.
3. Открыть pull request или эскалировать. Либо написать pull request для решения проблемы, либо эскалировать инженеру, если исправление не сводится к изменению кода, либо составить отчёт с выводами и остановиться.

Подавляющее большинство прогонов завершается до pull request или эскалации, когда Polylane приходит к выводу, что проблема либо ложноположительная, либо безобидная.

Архитектура с субагентами

Изначальная архитектура строилась на нескольких субагентах.

Мы использовали агента-оркестратора, чтобы координировать работу между несколькими субагентами. Субагенты создавались для проверки гипотез, пытаясь подтвердить или опровергнуть каждую гипотезу с разных стартовых точек (например, начиная с изучения логов, или начиная с кодовой базы и т. д.).

Находки субагентов взвешивались простой арифметикой и обобщались другим агентом, прежде чем передаваться агенту-координатору.

Вердикт по каждой гипотезе представлял собой голосование, взвешенное по уверенности, по всем проходам.

const CONFIDENCE_RANK = { definitive: 4, strong: 3, moderate: 2, weak: 1, speculative: 0 };

function aggregatePassVerdicts(passes: PassResult[]): Verdict {
  const weights: Record<string, number> = {};
  const counts: Record<string, number> = {};
  for (const p of passes) {
    weights[p.verdict] = (weights[p.verdict] ?? 0) + CONFIDENCE_RANK[p.confidence];
    counts[p.verdict] = (counts[p.verdict] ?? 0) + 1;
  }
  const totalWeight = Object.values(weights).reduce((a, b) => a + b, 0);
  const [winner, winnerWeight] = Object.entries(weights).sort((a, b) => b[1] - a[1])[0];

  const countMajority = counts[winner] > passes.length / 2;
  const weightMajority = winnerWeight > totalWeight / 2;
  if (!countMajority && !weightMajority) {
    return { verdict: "inconclusive", confidence: "weak", summary: `No consensus across ${passes.length} passes.` };
  }

  const majority = passes.filter((p) => p.verdict === winner);
  const confidence = majority.reduce((min, p) => (CONFIDENCE_RANK[p.confidence] < CONFIDENCE_RANK[min] ? p.confidence : min), majority[0].confidence);
  const lead = majority.reduce((best, p) => (CONFIDENCE_RANK[p.confidence] > CONFIDENCE_RANK[best.confidence] ? p : best));
  return { verdict: winner, confidence, summary: lead.summary };
}

Как только все гипотезы были исследованы, если первопричина была установлена, координатор либо эскалировал инженеру, либо составлял план исправления. Этот план передавался кодинг-субагенту, чтобы реализовать исправление и отправить pull request.

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

Более того, агент, писавший исправление, располагал только планом, без контекста об исходной проблеме или доказательствах, собранных в ходе расследования. Это приводило к посредственным pull request’ам, которые часто были сосредоточены на симптомах, а не на первопричине.

Мы выбрали эту архитектуру в первую очередь потому, что когда мы впервые проектировали её в марте 2026 года, флагманские модели не всегда были способны провести расследование от начала до конца, включая написание исправления, да и, откровенно говоря, наша обвязка (harness) была не так хороша.

Строить на этом фундаменте становилось всё сложнее по следующим причинам:

• Отладка требовала множества трейсов. Чтобы рассуждать о расследовании от начала до конца, нужно было просматривать несколько, порой десятки трейсов.
• Оценка была пооэтапной. Каждый субагент можно было оценить отдельно и получить успешный результат, при этом итог оставался слабым, потому что сбои происходили именно на передачах между агентами.

Мы месяцами дорабатывали эту архитектуру, улучшая каждого агента по отдельности и настраивая промпты и передачи, но результаты никогда не соответствовали затраченным усилиям. Это было дорого, сложно отлаживать, а pull request’ы получались недостаточно хорошими.

Единый агент

3 сентября мы заменили workflow с субагентами на единого агента, который делает всё: от триажа до pull request. Один и тот же агент собирает доказательства, исследует все гипотезы и отправляет pull request.

Мы удалили агента триажа, координатора, агентов-гипотез и агента autofix, вместе с workflow, переносившими результаты между ними, и гейтами, стоявшими перед pull request. Эксплуатационные преимущества проявились сразу: один трейс для оценки и никаких сводок между субагентами.

Что важнее, качество pull request’ов выросло, а время между обнаружением проблемы и открытием исправляющего её pull request резко сократилось. За месяц вокруг перехода медиана снизилась с 2,2 часа до 35 минут, а p90 — с девяти дней до менее чем двух часов. При конвейерной архитектуре находка обычно «зависала» на многие часы в цепочке workflow, где каждый ждал предыдущего. При едином агенте pull request открывается спустя всего несколько минут после обнаружения проблемы.

Теперь мы также открываем гораздо больше pull request’ов. Когда мы использовали субагентов, 0,6% обнаруженных проблем заканчивались pull request’ом. При едином агенте это 4,2%, и доля растёт. Разница в режимах отказа. Конвейер с несколькими субагентами должен пережить каждую передачу: триаж должен продвинуть находку, координатор должен сформировать гипотезы, fan-out должен прийти к вердикту и т. д. Каждая передача — потенциальная точка отказа.

Стоимость на один pull request также снизилась. Теперь каждый прогон начинается на более мощной модели, поэтому отклонённая находка обходится дороже, чем при конвейере. Тем не менее средняя стоимость на pull request упала со $111 до примерно $18 за первые девять дней работы единого агента. Это снижение не связано исключительно с изменением архитектуры, поскольку мы активно дорабатываем каждый аспект Polylane. Часть этого — обычный дрейф системы, находящейся в постоянной итерации.

Не стройте субагентов

• На передачах теряется больше, чем выигрывается. Каждая сводка, передаваемая между агентами, это контекст, которого никогда не будет у следующего агента. Агент, собирающий доказательства, должен быть тем же агентом, который действует на их основе.
• Оценивайте прогон, а не агентов. Оценки по отдельным агентам проходят успешно, пока система в целом даёт сбой, потому что сбои происходят именно между агентами.
• Держите один трейс на прогон. Неверное решение, размазанное по десятку трейсов, объяснить можно за полдня. В одном трейсе для этого хватит прокрутки.