Как компания Mendral сократила затраты на LLM, перейдя на Opus: шаблон триажера, доступ к SQL и архитектура под-агентов

Mendral недавно опубликовал подробности о том, как они перешли на Opus 4.6 для анализа сбоев CI, при этом снизив общие расходы на LLM по сравнению с предыдущей настройкой на Sonnet 4.0. Ключевым моментом является архитектура, которая разделяет сортировку и расследование, используя дешевые под-агенты для тяжелой работы.

Архитектура: дешевый сортировщик, дорогой планировщик

Из примерно 4000 проанализированных сбоев CI 3187 были дубликатами — известный нестабильный тест, инфраструктурный сбой или сетевой глюк. Запускать дорогую модель для таких случаев расточительно. Но дедупликация не детерминирована: одна и та же задача может упасть по разным причинам. Их решение — паттерн сортировщика:

• Агент Haiku выполняет узкую задачу: решает, отслеживается ли уже данный сбой. Он использует точное совпадение и семантический поиск (pgvector) по известным сообщениям об ошибках. Две разные строки, такие как operator does not exist bigint character varying и migration type mismatch on installation_id, могут быть одной и той же первопричиной — семантический поиск это улавливает.
• В случае сомнений Haiku передает задачу Opus 4.6. Ложное срабатывание стоит немного; ложное отрицание пропускает реальную ошибку.
• 4 из 5 сбоев никогда не доходят до Opus. Совпадение сортировщика стоит примерно в 25 раз меньше, чем полное расследование.

Пусть агенты тянут контекст, не толкайте его

Вместо того чтобы втискивать 200К+ строк логов в промпты, агенты получают SQL-интерфейс к ClickHouse. Есть сырая таблица (github_logs, одна строка на строку лога) и материализованные представления с предварительно агрегированными данными: частота отказов по рабочим процессам, время выполнения задач, количество результатов. Большинство расследований начинаются с представлений для сужения области поиска, затем переходят к сырым логам. Если запрос возвращает слишком много строк, система обрезает и предлагает более конкретное представление. Если логи еще не загружены, агенты переключаются на GitHub CLI.

Дорогие модели планируют, дешевые выполняют

Opus формирует гипотезу и запускает под-агентов Haiku, ограниченных одним уровнем вложенности — без неограниченного ветвления. Каждый под-агент получает от Opus промпт: что именно искать и как. Пример из реального случая:

Три задачи Storybook CI упали на одном коммите, сбой произошел на шаге pnpm install. Opus отправил под-агента получить сообщения об ошибках с этого шага. ClickHouse еще не имел логов, поэтому под-агент использовал GitHub CLI и вернул: gyp ERR! not found: make — [email protected] не смог скомпилироваться, потому что на раннере не было make. Затем Opus запросил в ClickHouse тренд отказов за 14 дней, нашел точку перегиба и передал эскалацию. Промпты под-агентов явные: "Получите логи CI для этого запуска. Верните точные сообщения об ошибках из шага pnpm install, полный вывод ошибок, особенно последние 50-100 строк."

Для кого это

Команды, создающие агентов на основе LLM для отладки CI или любых задач, где размер контекста и стоимость являются проблемами.