На прошлой неделе я писал о NeMoCo — самообучающейся системе, которая учится классифицировать нейронные структуры так, как мозг классифицирует мир — из сырых, непомеченных данных, не будучи информированным о том, какие категории существуют. Я постоянно возвращался к одной и той же фразе: labels are a shortcut, structure is what matters.

На этой неделе я реализовал другую половину этой идеи в той области, в которой я действительно работаю. Я веду личного ИИ‑ассистента — Aura — который управляет памятью, распределяет задачи и старается быть действительно полезным между сессиями. Он работает на флоте моделей: Claude для продакшн‑кодинга, несколько облачных моделей для исследований и дизайна, а также локальная модель, которая ничего не потребляет. Проблема та же, что решает NeMoCo, только инвертированная. NeMoCo извлекает структуру из сырых данных. У меня уже была структура — список агентов, каждый со своей задачей — и мне нужна была система, которая бы decide which model should do which task, live, under a budget that runs out.

Этот механизм принятия решений, который я построил на этой неделе, состоит из трёх частей: classifier — классификатор, который читает задачу и определяет, какой вид работы она представляет; router — маршрутизатор, который сопоставляет это с лучшей цепочкой моделей с учётом текущей квоты; и dashboard — панель управления, которая отображает всё это как живой, пульсирующий мозг. Это техническое описание — что делает каждая часть, почему она имеет такую форму и какие неудачи вынудили такой дизайн.

Проблема: список агентов — это не маршрутизатор

Наивная настройка — это статическая таблица: этот агент запускает эту модель, тот агент запускает ту модель. Это просто, и это неправильно по трём причинам.

Сначала бюджет заканчивается. Claude работает с недельной квотой и с скользящей сессионной квотой, и они меняются независимо. В один день недельная квота составляла 15%, а сессионная — 71% — и поскольку старый роутер отслеживал только недельное число, он сообщал «Claude доступен, режим NORMAL» и направлял код прямо в стену. CLI отказывал в каждом вызове в течение трёх часов с сообщением «Вы достигли лимита сессии», тогда как панель управления продолжала говорить, что всё в порядке. Роутер, который не читает лимит, который на самом деле является обязательным, не является роутером, это предположение.

Во‑вторых, quality is not one number. Модель, которая хорошо пишет код, не обязательно хороша в извлечении длинного контекста или генерации UI. Оценка каждой модели одним единственным показателем «качество» бесполезна — она не скажет, какая модель должна вести кодинг, а какая — исследование. Каждому агенту нужно оценивать по своей own оси.

В‑третьих, the reviewer must not inherit the writer's blind spots. Я намеренно парализую писателя и рецензента — кодер пишет, диагност проверяет — и они должны работать different семействами моделей, иначе рецензент просто повторит те же ошибки. Первая версия маршрутизатора постоянно помещала обе «головы» на одну модель, потому что разрешала ничьи по задержке. Это полностью нивелировало замысел.

Итак, статическая таблица должна была уйти. Её заменил движок принятия решений, который считывает текущее состояние и вычисляет, для каждой задачи, оптимальную цепочку моделей.

Классификатор: Чтение задачи

Первый элемент — классификатор, который читает задачу и определяет, какой тип работы она представляет. Вход — предложение — «конечная точка платежа возвращает 500 в рабочей среде с момента развёртывания» — а выход — вердикт: вид, уровень и приоритет.

Первая версия была чистым регулярным выражением. Она работала, и была хрупкой именно теми способами, которыми всегда хрупки регулярные выражения. «Log parser» был неправильно направлен в ops (это компонент кода, а не задача ops). «Checkout is charging customers twice» не содержал вообще никакого словаря ошибок, поэтому он был классифицирован как unknown и прошёл сквозь основного агента — в рабочем инциденте. «Throwing 500s» не соответствовал шаблону статус-кода из-за завершающей 's', которая сломала границу слова. Каждый из этих случаев был реальной ошибкой маршрутизации, которую я исправлял по одному, и каждое исправление представляло собой новое правило регулярного выражения. Это признак того, что вы боретесь с неправильным инструментом.

Теперь классификатор сначала пробует дешёвую модель — `deepseek-v4-flash:cloud` читает задачу и возвращает JSON‑вердикт. Если модель недоступна, происходит откат к классификатору на основе регулярных выражений. Модель — основной путь, а регулярное выражение — страховочная сеть. Это тот же урок, что и в NeMoCo: не размечайте каждый случай вручную, изучайте структуру и позволяйте ей переноситься.

Классификатор также получает актуальную квоту от своего вызывающего, поэтому он никогда не отклоняется от маршрутизатора. Вызывающий читает состояние квоты и передаёт её; классификатор не читает файл квоты напрямую. Ключевое правило: рабочая нагрузка в production никогда не понижается до слабой модели, насколько бы ни был ограничен бюджет. Инцидент в production классифицируется как `prod` даже когда Claude исчерпан — он не перенаправляется незаметно на лёгкого агента и не сообщается как выполненный. Он блокируется, и срабатывает протокол передачи. Риск качества хуже риска квоты, и дизайн никогда не забывает, какой из них какой.

Маршрутизатор: Движок принятия решений

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

Ядро — это осевой скоринг. Каждый агент оценивается по своей оси навыков — программист по генерации кода, диагност по отладочному рассуждению, исследователь по извлечению фактов, креатив по генерации интерфейса, оператор по вызову инструментов, главный по оркестровке. Эффективное качество модели — это её синтетический балл бенчмарка times её наблюдаемая надёжность в реальных сессиях. Модель, которая хорошо показывает себя в бенчмарке, но ошибается в эксплуатации, понижается. Это слой «учиться на реальной производительности»: бенчмарк — это синтетическая способность, а данные о надёжности показывают, что действительно выдержало.

Формула оценки — это матрица весов Bander: `score = quality·Wq − cost·Wc − latency·Wl + claudeBonus`. Стоимость — это относительный уровень 0..1, а не реальные доллары — потому что у ollama cloud нет цены за вызов, а Claude — это подписка, и вы не можете честно свести их к общему min-max масштабу. Кроме того, существует жёсткий порог качества: кандидат, набравший ниже него по своей оси, отбрасывается до ранжирования, поэтому дешёвая но глупая модель никогда не выиграет только за счёт цены.

Маршрутизатор также решает проблему проблема декорреляции — заставляя головы программиста и диагноста работать на разных семействах моделей, чтобы рецензент не унаследовал слепые зоны писателя. И он обрабатывает экономика суб агентов: суб агент выполняет часть работы своего родителя, и одна делегирование может разветвиться до 20×, поэтому цепочки суб агентов придают стоимости гораздо больший вес, чем любой постоянный уровень. Это и удерживает Claude вне цепочек суб агентов без жёсткого исключения — при весе стоимости 0.45 он просто не может выиграть.

Панель управления: Роботизированный мозг

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

Есть вид 3D-мозга — это нейронная структура, отрисованная WebGL, где каждый агент — это регион, и вы можете вращать, масштабировать и кликать по региону, чтобы углубиться в его цепочку моделей, статистику и селектор переопределения. И есть «электронный мозг — центральный элемент» в представлении сетки: это плата цепи SVG, где агенты являются узлами рабочего процесса, соединёнными анимированными сигнальными следами, причём вся система пульсирует быстрее или медленнее в зависимости от живой активности.

Мозг — не просто украшение. Это телеметрия, сделанная видимой. Панель управления получает активность каждого агента из роста файлов сессий между опросами — самый сильный сигнал того, что агент действительно работает — и отображает её как импульсы сигнала, движущиеся по трассам цепей. Когда система простаивает, мозг замедляется до ползания. Когда она занята, трассы мчатся. Вы можете see как мозг думает.

Также есть селектор уровня — шесть кнопок (Уровень 1–4, «Локальный» щит и «Базовый» сброс), которые позволяют заставить весь флот работать на заданном уровне качества. И переопределения моделей для каждого агента, сохранённые в файле, позволяют закрепить конкретную модель за конкретным агентом, когда выбор живого маршрутизатора не соответствует вашим ожиданиям. Панель управления является поверхностью управления для мозга.

Неудачи, которые сформировали его

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

• Слепая зона лимита сессий. Маршрутизатор шлюзил только по недельной квоте и игнорировал сессионную квоту, которая фактически была обязательной. Исправление: читать оба и позволять более строгому одержать победу.
• Ошибка конверта benchmark. Бенчмарк rev1 записывал свой файл в конверте `{value:[...]}` вместо простого массива, поэтому у каждой строки отсутствовало поле `.model`, а маршрутизатор молча получал пустую карту. Данные бенчмарка никогда не достигали маршрутизатора, и никто не жаловался. Исправление: распаковать устаревшую форму, чтобы старые файлы всё ещё загружались.
• Инверсия оси‑рубрики. Рубрика оси оценила opus в 0,50 по отладочному рассуждению — ниже модели, которая никогда не должна проверять производственный код. Позволив ей переупорядочитьprod‑уровни, мы сделали бы рецензента автором. Исправление: prod‑уровни не переранжируются рубрикой. Рубрика по ключевым словам не является достаточным доказательством, чтобы отменить заявленное проектное решение.
• Спираль смерти контекстного окна. Размещение модели с контекстом 131k в начале уровня оркестрации привело к переполнению окна и запустило спираль смерти компакта. Исправление: каждый кандидат на оркестрацию должен иметь окно с комфортным запасом выше бюджета контекста плюс резерв.
• Бесполезная операция надёжности. Журналы сессий хранят голое имя модели, тогда как кандидаты несут префикс провайдера, поэтому уровень надёжности молча не находит совпадений. Исправление: удалить префикс перед сопоставлением.

Что я выношу

Пост NeMoCo завершился словами: метки — это ярлык, структура — это то, что важно, и вы можете изучить структуру из сырых данных. На этой неделе это был инженерный эквивалент того. Я не писал правило вручную для каждой задачи — я создал классификатор, который читает задачу, и маршрутизатор, который читает текущее состояние, и позволил структуре работы определить инструмент. Классификатор на основе регулярных выражений был подходом «метки», и он ломался именно там, где всегда ломаются метки: на краях, в случаях, которых вы не предвидели. Классификатор, поддерживаемый моделью, является подходом «структура»: изучите паттерн, перенесите его, откатывайтесь gracefully.

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

Маршрутизатор открыт по духу — это набор скриптов в моём рабочем пространстве: `classify-job.mjs`, `model-router-core.ps1`, `quota-dashboard.mjs` — и он работает на смеси Claude, облачных моделей ollama и локальной модели, которая ничего не потребляет. Это не закрытая корпоративная система. Это движок принятия решений, который вы могли бы собрать сами, а неудачи, которые его сформировали, представляют полезную часть.

Это урок. Ростер — это список. Маршрутизатор — это решение. А мозг — это то, что вы получаете, когда решение принимается в реальном времени, при ограниченном бюджете, который исчерпывается, системой, которая учится на своих собственных ошибках.