📕 Большой разбор

Единый вводный материал перед курсом: сначала обзор с интерактивом (~20 мин), затем четыре части чтения (~1 час). Полная глубина — в курсе.

Четыре части разбора (~1 час чтения)

Выше был обзор с интерактивом; ниже — основное чтение. Собрано СТРОГО из базы архива (analysis/, verify/, DECISIONS.md) — ничего из «общих знаний». Каждая цифра помечена: (проверено) — подтверждена первоисточником, (осторожно) — первоисточник не найден / иллюстративный расчёт, (исправлено) — в исходных данных была ошибка. Это ВВОДНЫЙ уровень: полная глубина, бюджеты и практика — в курсе; углубление по темам — в Библиотеке; термины — в Глоссарии.

Как читать. Четыре части, каждая ~15 минут. Можно подряд, можно по одной перед соответствующими модулями курса: Часть 1 → модули 1–2 · Часть 2 → модули 3 и 5 · Часть 3 → модули 4, 6, 7 · Часть 4 → модули 9–11.

Часть 1. Что такое агент и как органы работают вместе

Прежде чем говорить о «заводе из шестнадцати сервисов» как о едином организме, надо честно договориться о словах. В индустрии сейчас терминологическая инфляция: почти всё называют «AI-агентом». Anthropic прямо признаётся, что села писать свою программную статью «Building Effective Agents» именно потому, что «мы заходим на встречи с клиентами, и все называют одну и ту же вещь разными терминами». Для тебя это не лингвистика ради лингвистики: у тебя в коде лежит файл orchestrator.mjs, который называется «оркестратор», но выключен; есть память memory-bank; есть циклы генерации с ретраями. Вопрос практический — что из этого уже настоящий агент, а что просто длинный скрипт, который кажется умным, потому что дёргает модель несколько раз подряд.

Агент, workflow и чат-бот: три разных договора с миром, а не три уровня ума

Разница между ними — не в том, насколько умна модель внутри. Разница в договоре с окружением, как разница между тремя типами реакции живого организма.

Чат-бот (chatbot) — это консультант, который только советует. Ты приходишь с жалобой, он отвечает и снова замолкает до следующего вопроса. Он реактивен, работает по сценарию, начинает каждый разговор с чистого листа и ничего не делает руками. Формула из материалов звучит так: «Chatbots respond. AI agents resolve» — чат-бот отвечает, агент решает проблему. И это видно по цифрам: чистый чат-бот или простой поиск-по-базе (RAG) доводит до конца лишь 10–20% обращений, тогда как настоящий агент — 40–80%+ (проверено).

Workflow (рабочий процесс) — это рефлекторная дуга (reflex arc). Раздражитель приходит — организм отвечает заранее прошитой, всегда одинаковой последовательностью: стимул → фиксированная реакция. Число шагов и их порядок зашиты в код заранее. Именно так устроен твой конвейер генерации видео ⓪→⑨: stage_script → stage_script_qc → stage_voice → stage_visual_rules → stage_prompts → stage_images → stage_timeline → stage_render → stage_capcut. Жёсткая, предсказуемая цепочка с известным числом звеньев, обёрнутая двумя человеческими воротами (EDIT_PENDING, APPROVAL_PENDING). Это НЕ агент — и в этом нет ничего унизительного. Anthropic прямо пишет: когда задача хорошо определена и повторяема, workflow предпочтительнее, потому что даёт предсказуемость и низкую цену ошибки. Публичная заливка на YouTube — задача с высокой ценой ошибки, поэтому рефлекторная дуга с ручными воротами тут архитектурно правильна.

Агент (agent) — это уже организм с собственной нервной системой, который сам решает, сколько раз сократить «мышцу» и когда остановиться. Официальное определение Anthropic (проверено, дословно): «AI-агент — это система, где LLM динамически направляет свои собственные процессы и использование инструментов, сохраняя контроль над тем, как выполняет задачи». Ключевое слово — «динамически». Число шагов заранее НЕ известно и определяется самой моделью по ходу дела. Твоя цель №1 — «строитель приложений» (план → код → критика → тест → доработка ночью) — это по определению агент, а не workflow, потому что заранее нельзя знать, сколько кругов критики понадобится до зелёных тестов.

Между этими полюсами есть и промежуточный, самый скромный уровень — augmented LLM (усиленная модель): модель с доступом к одному инструменту или к памяти, но без цикла. Это твой единичный вызов claude -p в стадии stage_visual_rules — модель один раз пишет режиссуру для куска сцен и к этому решению не возвращается. Путаница у новичков обычно рождается ровно из-за того, что они перепрыгивают через этот средний уровень и зовут агентом любой второй вызов модели.

Анатомия одного хода: рефлекторная дуга «Мысль → Действие → Наблюдение»

Один проход агентного кольца называют ход (turn). Его каноническая форма — фреймворк ReAct (Reasoning + Acting, рассуждение + действие): Мысль (Thought) → Действие (Action) → Наблюдение (Observation) → снова Мысль …. Это в точности рефлекторная дуга с обратной связью: чувствительное звено (что вернули инструменты и в каком состоянии проект) → двигательное звено (вызов инструмента) → и снова афферентный сигнал от «рецептора». На каждом ходу агент делает четыре вещи: анализирует текущее состояние; выбирает один или несколько инструментов; получает результат выполнения (наблюдение); решает — задача закончена или нужен ещё ход. Лилиан Вэнг (Lilian Weng) в классическом разборе автономных агентов настаивает, что в это кольцо обязательно должна быть встроена самокритика (self-reflection) — способность анализировать свои прошлые действия и учиться на ошибках.

Здесь — самая недооценённая деталь, и она прямо касается твоего завода. Обратная связь должна приходить из окружения (environment), а не быть самовнушением модели. Инженер Anthropic формулирует это как диагноз: «модель может конвергировать к правильному ответу, только если получает сигнал каждый раз, когда проходит цикл»; «без механизма обратной связи вы не добавляете сигнал — вы просто добавляете шум». Именно поэтому кодинг-агенты работают лучше прочих: тест либо прошёл, либо нет — это детерминированный сигнал, как объективный анализ крови, а не «пациент говорит, что чувствует себя лучше».

У тебя это самое слабое место. Стадия ⑨ LEARNING — холостая: метрики с YouTube (просмотры, retention) не текут обратно в memory-bank автоматически, оркестратор выключен. Формально это значит, что даже там, где цикл есть (например, петля обучения thumbnail-studio), он не замкнут до настоящего самообучения — рецептор оторван от нервной системы, рефлекторная дуга разомкнута. Организм совершает движение, но не чувствует его результата.

Инструменты: как модель обзаводится руками

Вызов функции (function calling / tool use) — механизм, которым модель вместо генерации свободного текста запрашивает выполнение конкретной функции. Это то, что превращает «говорящую голову» в работника с руками. Стандартный цикл — пять шагов (проверено как общепринятый паттерн): приложение отправляет модели запрос вместе с JSON-схемами доступных инструментов → модель генерирует вызов с параметрами → приложение выполняет функцию у себя (не модель!) → результат возвращается модели → модель либо даёт финальный ответ, либо зовёт следующий инструмент.

Anthropic формулирует пять правил хороших инструментов, и одно замечание бьёт прямо по твоей архитектуре. Инженер честно говорит: «люди тратят кучу сил на красивые промпты, а инструменты дают модели голые — без документации, с параметрами, названными A и B… инженер бы не смог работать с такой функцией — как вы ждёте, что Клод сможет?» Вывод для завода: если ты захочешь строить настоящих агентов поверх channel-hq или resource-governor, каждый их внутренний API должен быть описан как публичный tool-контракт для модели (имя, смысл, параметры), а не просто как REST-эндпоинт для людей. Иначе агент начнёт «фантазировать» вызовы — как хирург, которому дали инструмент без подписи и без объяснения, что он делает.

Есть и второй слой — то, что называют «tool calling 2.0». Классический вызов требует, чтобы модель сама прогоняла через себя каждый промежуточный результат: чтобы прочитать 10 писем, она должна 10 раз вызвать read_email и каждый раз «увидеть» ответ — дорого по токенам и недетерминированно. Новый подход — позволить агенту написать код, который сам оркеструет пачку вызовов (цикл for email in emails). Механический код не требует, чтобы модель видела каждый промежуточный результат: программа пишется один раз и выполняется детерминированно. Это буквально твоё собственное правило «скрипт вместо ИИ, где можно» — Anthropic независимо вывела тот же принцип и назвала его «код как универсальный интерфейс к цифровому миру». Для тебя, с болью раздувания контекста до ~1M токенов на многошаговой задаче, это не абстракция, а прямой рычаг экономии.

Skills вместо зоопарка агентов

В докладе Anthropic «Don't Build Agents, Build Skills Instead» звучит тезис, который стоит принять как архитектурный: «агенты сегодня во многом похожи на Махеша — блестящие, но без экспертизы». Навык (skill) определяется как «организованная коллекция файлов, упаковывающая композируемое процедурное знание для агентов» — по сути папка с инструкциями, которую можно версионировать в git. Это медицинский протокол, клинический гайдлайн: не новый врач под каждую болезнь, а один компетентный врач плюс полка проверенных протоколов, которые он достаёт по необходимости.

Практический вывод для тебя: не обрастать десятками узкоспециализированных «агентов» под каждый канал и нишу. Дешевле и предсказуемее масштабируется один универсальный код-агент (в духе Claude Code) плюс растущая библиотека навыков (faceless-script-skill, capcut-marker-builder и т.п., которые у тебя уже частично есть). Anthropic превратила твою же интуицию — «повторил дважды → оформи скиллом» — в официальную архитектуру. Ядро агента может быть тонким, как bash плюс файловая система; вся специализация уезжает в навыки.

Отдельно стоит удержать в голове различие между Function Tools (строгие JSON-схемы, ограниченное и предсказуемое пространство вызовов — надёжнее) и Custom Tools (свободный текстовый ввод: произвольный bash или SQL — там, где структуру заранее описать нельзя). Для завода это конкретный выбор: детерминированные действия (создать проект, одобрить пакет, запросить слот у resource-governor) — обязательно Function Tool со строгой схемой; исследование неизвестного (ресёрч ниши, произвольный код строителя приложений) — Custom Tool в духе «выполни код». Смешивать эти два режима в одном инструменте — типичная причина, по которой агент то работает надёжно, то начинает выдумывать параметры.

Соберём раздел одной формулой: агент — это не более умная модель и не больше инструментов, это замкнутый цикл (ход → инструмент → наблюдение → оценка → следующий ход), где число шагов заранее не известно. И маленькая, но важная арифметическая оговорка на будущее: при точности 95% на шаг десятишаговая цепочка доходит до конца без ошибки лишь примерно в 60% случаев — 0.95¹⁰ ≈ 0.60 (проверено как чистая математика; осторожно — это иллюстративный расчёт, а не результат исследования). Чем длиннее агентная цепочка, тем важнее промежуточная проверка, а не «доверие модели до конца». Это мостик ко второй теме.

Оркестрация: как органы работают в одном организме

Оркестрация (orchestration) — это не «запустить несколько ИИ одновременно». Это управление координацией: кто что делает, кто кому передаёт результат, кто проверяет качество, что происходит при сбое. Anthropic формулирует жёстко: «многоагентные системы нужно проектировать как архитектуры прежде всего, промпты — во вторую очередь». Первая ошибка новичка — думать, что мультиагентность решается хорошим промптом для «главного» агента. Не решается. Она решается тем, кто кому что показывает и в какой момент — то есть строением нервной системы, а не красноречием отдельного нейрона.

Три роли консилиума: планировщик, исполнитель, критик — и почему автор не проверяет сам себя

Под общим словом «агент» прячутся три разные роли, и их смешение — главная причина, почему «умный ИИ» выдаёт правдоподобный, но неверный результат.

Планировщик (planner) решает, ЧТО делать и в каком порядке. На выходе — план и критерии готовности, а не готовый результат. Это врач, составляющий план лечения.

Исполнитель (executor) делает конкретную работу инструментами: пишет код, генерирует картинку, шлёт запрос в API. Это хирург у стола.

Критик (critic / judge) оценивает результат исполнителя против критериев планировщика и имеет право вернуть на доработку или наложить вето. Это независимый патологоанатом или второе мнение.

Почему нельзя, чтобы исполнитель проверял сам себя? Потому что у автора работы есть то, что доклад Factory называет «cost bias» (перекос заинтересованности): он объективно заинтересован, чтобы его же работа оказалась правильной. Хирург не делает сам себе послеоперационную гистологию — за этим и существует второе мнение. В материалах про автономный кодинг это правило называется verifier pattern (паттерн проверяющего): «независимый агент получает только артефакт и требования, без контекста генератора. Это предотвращает систематические ошибки, которые генератор и ревьюер делают одинаково». Иначе — если критик видит всю цепочку рассуждений автора — он наследует его слепые пятна. У тебя это уже случалось вживую: в thumbnail-studio пришлось гасить «эхо-камеру обучения» — судья, слишком близкий к генератору, начал подтверждать его же ошибки. Правило: критик получает минимум контекста от генератора, максимум — от требований.

Насколько это важно количественно — здесь надо быть аккуратным. В материалах приводятся эффектные цифры финансового исследования на 522 сессиях: 24.9% безошибочных результатов у одного агента без критика, рост до 92.1% с циклом «планировщик-исполнитель-критик». Осторожно: первоисточник этих цифр не найден — обе независимые проверки архива не смогли воспроизвести их в открытых источниках, так что использовать их как установленный факт нельзя. Качественный вывод при этом подтверждается другими, проверяемыми источниками (Anthropic про adversarial evaluation): вынесение критика в отдельного скептичного агента — «сильный рычаг», и «настроить отдельного скептичного оценщика оказывается куда легче, чем заставить генератора критиковать собственную работу». То есть верь принципу, а не конкретным процентам.

У тебя уже есть живой консилиум-конвейер ⓪→⑨: центральный «диспетчер» (orchestrator.mjs, пока выключен) ведёт проект по стадиям, у каждой свой владелец-сервис, узкая специализация, и два человеческих контрольных пункта. Это, по сути, «оркестратор + рабочие» с ручными воротами вместо агента-критика.

Пять паттернов оркестрации — и где они уже живут на твоём заводе

Материал выделяет пять архитектур координации; полезно сразу примерить их на твой организм.

1. Sequential / Pipeline (конвейер). Линейная цепочка, каждый этап зависит от предыдущего. Это ровно ⓪→⑨. Хорош, когда порядок операций фиксирован (видео действительно нельзя озвучить до сценария).

2. Hierarchical (оркестратор + воркеры). Центральный агент решает, каких специалистов позвать, и параллелит независимые части. Здесь — единственные твёрдые цифры этого раздела (проверено): параллельные вызовы инструментов ускоряют результат до 90% против последовательных, а мультиагентная система (лидер на Opus + подагенты на Sonnet) обошла одиночный Opus на 90.2% в исследовательских задачах. У тебя это уже частично есть: POST /api/projects/batch запускает N видео параллельно, а resource-governor играет роль честного брокера пулов — это и есть иерархическая оркестрация с брокером ресурсов вместо неконтролируемого веера. По-медицински resource-governor — вегетативная нервная система: сам, без участия сознания, распределяет «кровоток» (GPU, render, brain, voice) между органами, чтобы никто не захлебнулся.

3. Handoff (передача управления). Децентрализованная маршрутизация: агент сам решает, кому передать задачу, и получатель становится полноправным владельцем, а не просто вызванным инструментом. Хорошо ложится на будущего «разведчика возможностей» (opportunity scout): сканирование рынка — задача с заранее неизвестным маршрутом (сегодня зацепка в нише X, завтра тренд Y), поэтому её правильно строить цепочкой передач (сканер → углублённый анализ находки → расчёт экономики → передача в очередь на решение), а не жёстким конвейером. Риск паттерна — бесконечные передачи «А зовёт Б, Б зовёт А»; лечится пределом числа хопов и «естественным завершением» (процесс кончается, когда активный агент не инициирует новую передачу).

4. Blackboard (общая доска). Агенты не общаются напрямую, а читают и пишут в общее хранилище; управляющий компонент решает, кто активируется дальше. У тебя это буквально memory-bank — три банка (global / per-channel / per-generator), к которым обращаются разные сервисы. Blackboard-архитектура на практике, просто пока в роли пассивного склада профилей и логов, а не активного диспетчера «кто следующий».

5. Concurrent / Fan-out-Fan-in (веер и сборка). Много агентов обрабатывают один вход параллельно, дальше агрегатор сводит результаты. Это ядро твоей будущей консультант-фабрики.

Вывод: у тебя уже работают экземпляры четырёх из пяти паттернов. Не хватает главного — настоящего замкнутого агентного цикла, где число шагов решает сама модель. И, что важно, оркестрацию для больших ночных прогонов лучше держать «как код» с явным состоянием (QUEUED → GENERATING → … → DONE), а не как «умного менеджера, который всё помнит»: промежуточное состояние живёт в переменных и файлах, а не в контексте модели — иначе контекст оркестратора взрывается при масштабе. orchestrator.mjs в этом смысле устроен правильно, его надо включать и достраивать, а не выбрасывать.

Судейская панель и best-of-N: ядро консультант-фабрики

Это самый релевантный паттерн для твоего второго приоритета — «веер MVP за ночь». Схема: задача расходится на N генераторов (Generator #1…#N дают решения A…N), затем судейская панель (judge panel) выбирает лучшее. Настоящий медицинский консилиум: несколько независимых специалистов, каждый со своим углом.

Три методологические детали, которые легко упустить. Первая: судейство бывает pointwise (оценка одного решения по шкале), pairwise (сравнение двух, турнир на выбывание) и checklist (критерии с весами). Вторая: исследование «When AIs Judge AIs» показывает, что для best-of-N турнир на выбывание (сложность O(N·log N)) эффективнее, чем сравнение всех со всеми (O(N²)). Третья, самая важная: гомогенные судьи снижают качество оценки — нельзя просто трижды запустить одну и ту же модель в роли критика, разнообразие ролей критично. Это как собрать консилиум из трёх одинаковых терапевтов: они дружно пропустят одно и то же. Тебе нужна панель с разными углами (например: судья по UX, судья по техническому риску, судья по скорости продажи), и сравнение — турниром, а не полным перебором пар, иначе стоимость судейства растёт квадратично с N.

Конкретная реализация этого паттерна: три explorer-агента в отдельных контекстных окнах, каждый оптимизирует свой trade-off (производительность / удобство / скорость), плюс один critic-агент, который оценивает полноту, режимы отказа и синтезирует лучшее. Экономическая деталь, снимающая твой страх «монстр, кушающий $1000 в минуту»: параллельное выполнение занимает примерно столько же реального времени, как один агент последовательно, — веер дорог не по времени, а по деньгам. Указывается, что «мультиверс-разработка» стоит примерно в 2–3× дороже линейной за счёт охвата вариантов (осторожно: этот множитель — эвристическая оценка, в независимых источниках как точная цифра не подтверждён). Смысл в том, что дороговизна тут — управляемая переменная: можно ограничить N и поставить на explorer'ов модель дешевле.

Токеномика оркестрации и когда мультиагентность вредит

Сначала цена. Anthropic даёт прямое сравнение потребления (проверено): обычный чат = 1×, агент с инструментами ≈ 4×, полноценная многоагентная система ≈ 15× токенов (с оговоркой: это замер именно на их исследовательской мультиагентной системе, а не универсальный закон для любой). Для тебя, с травмой раздувания контекста, вывод жёсткий: оркестрация без управления контекстным окном — не архитектура, а способ сжечь бюджет. Рецепт из того же материала совпадает с твоими правилами: компактификация между агентами (передавать выжимку, не сырьё), суммаризация перед передачей, внешнее хранилище вместо раздувания контекста, явная приоритизация.

Теперь — когда мультиагентность прямо вредна. Тут стоит быть точным в атрибуции: широко цитируемый тезис «95% пилотов ИИ-агентов падают при масштабировании» — это исправление: было «по данным Composio», верно — это статистика MIT, которую Composio как раз цитирует и критикует за методологию, а собственный вклад Composio — три архитектурные причины провала (примитивный поиск-по-базе; хрупкие коннекторы; polling tax — агент дёргает API каждые 5 секунд, 95% запросов впустую). Само наблюдение — что пилоты падают не из-за «недостаточно умной модели», а из-за архитектуры и интеграции — остаётся в силе.

Есть и урок против интуиции «больше агентов = быстрее». Команда Factory (система Missions, автономные прогоны до 16 дней подряд; осторожно — «30 дней» это цель, которую команда считает достижимой, а не факт) попробовала запустить 10 агентов параллельно на одной кодовой базе — и не сработало: агенты конфликтуют, наступают на чужие изменения, дублируют работу, принимают несовместимые архитектурные решения, «overhead координации съедает выигрыш в скорости, сжигая токены». Решение — фичи выполняются серийно, параллелится только безопасное: read-only разведка (поиск по коду, исследование API, code review). Для твоего строителя приложений правило прямое: параллелить независимые модули, но не строки одного файла; веер вариантов — да (разные MVP, разные ниши), одна кодовая база одним прогоном — серийно.

И два фреймворковых предупреждения-цифры (обе проверены). CrewAI в иерархическом режиме на простом запросе спалил 15 759 токенов за 38 секунд (итоговый ответ — 200 токенов), потому что менеджер выполняет всё последовательно без условной маршрутизации — это предупреждение против «оркестратор для всего», когда достаточно прямого вызова. OpenClaw держит двухуровневую иерархию с жёстким пределом максимум 5 активных субагентов на родителя — защитный барьер против неконтролируемого разрастания дерева. Твой resource-governor — уже похожий предохранитель; его логику стоит распространить и на глубину/ширину дерева субагентов.

Наконец — человек в контуре, который масштабируется, а не блокирует. Работающий средний путь между «каждое действие требует одобрения» (узкое горло) и «полная автономия» — это ступенчатая автономия (tiered autonomy) по типу действия: read-only и анализ — 100% автономии; генерация и публикация контента — высокая автономия с опциональной проверкой; удаление и необратимое — человек обязателен; деньги — 0% автономии, человек плюс явное подтверждение. Это буквально формализует твою красную линию «тратить деньги без подтверждения нельзя, а писать/публиковать ночью — можно». Чекпоинт перед дорогим необратимым решением математически «перезагружает» накопленную вероятность ошибки (0.95⁵ вместо 0.95¹⁰).

Практическое правило перед тем, как плодить нового агента-специалиста, задай три вопроса: (1) это механическая операция → скрипт/grep, не агент; (2) это существующий навык в новом контексте → не новый агент, а новый вызов существующего; (3) это принципиально новый тип суждения, новая роль в консилиуме → вот только тогда агент. Мультиагентность у тебя уже не гипотеза — она работает в конвейере каждый день. Следующий шаг не «включить оркестратор и надеяться», а сделать её осознанной, ограниченной по бюджету и наблюдаемой: разделить роли planner/executor/critic по разным моделям (а критика по возможности держать вообще на другом семействе модели, чтобы не унаследовать те же слепые пятна), поставить жёсткие лимиты попыток на каждом узле, и заложить трассировку решений с самого начала — без структурированного лога «кто, что выбрал, на основе чего и за сколько» любой веер MVP останется чёрным ящиком, а обещанное самообучение будет нечем кормить.

Часть 2. Память и общий мозг. Токеномика: дешёвая система by design

Память как орган: контекстное окно — это кратковременная память, банк — это гиппокамп

Прежде чем спорить о том, какой сервис что делает, стоит развести два принципиально разных слоя, которые на практике постоянно путают — и из этой путаницы растёт половина твоих проблем, включая ту самую, где контекст раздувался до ~1M токенов на 12-шаговой задаче. Оркестрация отвечает на вопрос «кто и в каком порядке работает». Память отвечает на другой: «что агент вообще ЗНАЕТ в момент, когда действует, и откуда это знание берётся».

Медицинская аналогия тут почти буквальная. Контекстное окно (context window) — это кратковременная, рабочая память (working memory), твоё оперативное «здесь и сейчас». Как ОЗУ компьютера или как рабочая память в коре — она летучая: всё, что в ней лежало, исчезает по окончании сессии. Предпочтения, изложенные на первом ходу, ограничение, поставленное на третьем, решение, принятое на седьмом — всё стирается, как только «пациент проснулся». Долгая память (long-term memory) — это диск, гиппокамп, консолидирующий опыт между сессиями. Ошибка путать одно с другим даёт предсказуемую клинику: нарушение ограничений, размывание предпочтений, внутренние противоречия к середине разговора — ровно то, как ведёт себя человек с несформированной долговременной памятью, каждые пять минут теряющий нить.

На твоём заводе это разделение не метафора, а физическая топология. memory-bank (отдельный сервис) — это диск, гиппокамп. А каждая сессия claude -p внутри генератора — это рабочая память, которая гаснет сразу после рендера видео. Хорошая новость: архитектурно ты уже сделал правильно — у тебя есть орган долговременной памяти отдельно от эфемерного «сознания» генератора. Плохая: этот орган пока работает как склад, а не как мозг, и об этом — ниже.

Два уровня памяти и retrieval: почему нельзя «вывалить весь банк» в контекст

Здоровая память двухуровневая. Уровень 1 — рабочее окно: 5–10 релевантных воспоминаний, извлечённых специальным «извлекателем» (retriever) ПЕРЕД каждым вызовом модели. Уровень 2 — персистентное хранилище: полная история, все факты и паттерны. Ключевая клиническая деталь, которую легко пропустить: производительность падает ЗАДОЛГО до того, как кончится лимит токенов — из-за эффекта «потерянного в середине» (lost-in-the-middle). Модель хуже держит информацию из центра длинного контекста — ровно как студент на трёхчасовой лекции лучше помнит начало и конец, а середина проваливается.

Отсюда прямой вывод, идущий вразрез с интуицией «дай ей всё на всякий случай»: даже если у модели формально влезает 1M токенов, скармливать весь memory-bank целиком НЕЛЬЗЯ. Нужен активный retriever, решающий, что из банка релевантно ИМЕННО этой задаче, и подающий только это. Твоя боль («12+ шагов → 1M токенов, платил за перечитывание одного и того же») — это клинический симптом отсутствия Уровня 1: каждый субагент получал «весь контекст на всякий случай» вместо выжимки.

Цифры, которыми это подтверждено, стоит запомнить. Система памяти Mem0 на бенчмарках памяти показала высокие баллы, потребляя ~6 900 токенов на запрос против ~26 000 у подхода «полный контекст» — сокращение на 73% (проверено). То есть грамотный retrieval почти вчетверо дешевле «вывалить всё», и при этом ТОЧНЕЕ. Причём наибольший прирост дало не просто нахождение похожего факта, а два более тонких умения: временны́е рассуждения (+29.6 балла) — понимать эволюцию истории («стиль А работал три месяца назад, но последние две недели проигрывает Б») — и multi-hop поиск (+23.1) — прослеживать цепочку зависимостей, а не одну похожую запись (проверено).

Практический нюанс для тебя: не бросайся в vector DB. Современный поиск в памяти — гибридный (multi-signal retrieval): плотные эмбеддинги для смысла + BM25 для точных сущностей и дат + графовые связи. Для десятка каналов плоские JSON + точный lookup по ключу дешевле и надёжнее векторного поиска; вектор оправдан, когда записей тысячи, а не десятки.

Три типа памяти — и все три уже живут на твоём заводе

Нейропсихология делит долговременную память на три вида, и это не академия — это ровно структура твоего memory-bank.

Эпизодическая память (episodic) — конкретные события в последовательности: «15 июля вышло видео с обложкой А, собрало Z просмотров». Как автобиографические воспоминания — что, когда, в каком порядке случилось. На заводе это log.jsonl внутри per-channel банка — журнал того, что произошло с конкретным каналом.

Семантическая память (semantic) — обобщённые факты и правила, оторванные от конкретного эпизода: «этот канал говорит таким голосом», «максимум 5 задач на агента». Как знание, что Париж — столица Франции, без воспоминания, где ты это узнал. На заводе это global.json (кросс-канальные правила для ВСЕХ каналов) и profile.json каждого канала (маскот, DNA, scene-mix — устоявшееся «какой этот канал»).

Процедурная память (procedural) — «как делать вещи», выученные навыки: «такой промпт для сцен даёт лучший рендер». Как умение ездить на велосипеде — знание в руках, не в словах. На заводе это per-generator банк — channel-агностичный крафт, приёмы генерации в принципе, независимо от канала.

Это разделение — не бюрократия, а иммунная защита от одной конкретной болезни: протечки между уровнями. У тебя она случалась дважды. Первый раз — синтетические (тренировочные) каналы протекали в общий банк и портили правила для реальных; лечение — гейт, закрывающий все пишущие двери. Второй — AVOID-правила текли между стадиями (сценарий/визуал) без разбора; лечение — читать правила scoped по стадии. Общий принцип: любая многоуровневая память без строгих границ «кто пишет, кто читает» деградирует в общий шум быстрее, чем накапливает пользу.

Git-память для длинных задач: Git Context Controller

Для будущего «строителя», который работает многошаговыми задачами (твоя боль №1), есть проверенный паттерн ведения памяти как в git — он называется Git Context Controller (GCC) (исправлено: в видео-разборе его расслышали как «OneContext», настоящее название — Git Context Controller, arXiv 2508.00031). Идея: агент держит четыре файла — main.md (глобальная дорожная карта), и для каждой ветки-подхода свою папку с commit.md (высокоуровневые вехи-резюме), log.md (полная сырая история действий) и metadata (навигация). Четыре действия зеркалят git: branch (пробуем альтернативную стратегию), commit (после каждой вехи — короткое резюме, не полная история), merge (успешный подход вливается в главный).

Выигрыш измерен: около +13% качества на задачах разработки (проверено: +13.6% относительного прироста на SWE-bench Verified). Механизм лечения твоей боли прямой: вместо одной раздувающейся сессии на 12 шагов строитель ведёт файловую структуру, и перечитывать нужно только main.md плюс, при необходимости, конкретный commit.md — а не всю сырую историю. Это буквальная файловая реализация двухуровневой памяти: main.md/commit.md — сжатый Уровень 1, log.md — полный Уровень 2, читаемый только «когда надо покопаться».

Сюда же примыкает клинический синдром context anxiety («контекстная тревога»): по мере заполнения окна модель не просто теряет связность — она МЕНЯЕТ поведение, начинает сворачивать работу преждевременно, торопится и объявляет сделанным то, что не сделано. Для ночной автономии это прямая угроза: строитель может «сдаться раньше». Лечение первого поколения — context reset: начать с чистого окна, прочитать последнее состояние из progress-файла, продолжить (проверено; оговорка: на более новых моделях эффект слабее, но первоисточник — Anthropic — связывает это с общим улучшением модели, а не именно с размером окна). Важно: сам progress-файл полезен НЕЗАВИСИМО от качества модели — это не костыль под слабую модель, а гарантия, что прогресс переживёт краш процесса или обрыв сессии. У тебя он уже есть буквально: state.json + config.json в каждом проекте генератора.

От склада фактов к общему мозгу: замыкание стадии LEARNING

Три банка, разделённые по типу — это ещё склад. Общим мозгом их делает третий уровень поверх индивидуальной памяти: Shared Multi-Agent Memory — коллективное состояние, доступное ВСЕМ агентам. Без него система «неизбежно дублирует работу, производит противоречивые действия и впустую жжёт бюджет»: если один канал через QC узнал, что визуальный стиль плохо работает, а другой не имеет доступа к этому знанию — он повторит ту же ошибку и потратит те же токены на её повторное открытие. Твой per-generator банк («channel-агностичный крафт») — это и есть shared memory; per-channel банк — индивидуальная память. Держать их раздельно ты уже догадался; важно не размывать границу при добавлении новых сервисов.

Но есть незакрытая рана, и её надо назвать прямо: стадия ⑨ LEARNING сейчас холостая — оркестратор выключен, метрики не текут в банки автоматически (подтверждено внутренним снимком завода). С точки зрения памяти это не мелкий баг, а отсутствие обратной связи в самом важном месте: банки накапливают структуру, но не учатся на реальных результатах публикации. Это как гиппокамп, который получает сигналы, но нейромедиатор консолидации не выделяется — опыт не превращается в память. Замкнуть эту петлю — самый дешёвый и высокий по отдаче шаг: не новая архитектура, а активация уже построенной.

Когда петля замкнётся, всплывёт следующий вопрос — самоправка памяти (self-editing). Концепция Letta/MemGPT рассматривает модель как операционную систему, управляющую собственной памятью: Core Memory (всегда в контексте — идентичность агента, жёсткие «никогда не делай X»), способность самому обновлять и архивировать записи, авто-суммирование старых диалогов. Заманчиво дать генератору инструмент «обнови память прямо сейчас» вместо пассивного логирования постфактум. Но здесь критично предупреждение, которое ты УЖЕ выстрадал руками: самоправка без порога опасна. При двух каналах один разовый артефакт генерации становился вечным глобальным правилом — поэтому у тебя стоит порог «повторилось ≥5 раз» перед промоушеном в общий банк. Это точная аналогия иммунного ответа: организм не вырабатывает антитело на единичный сигнал — нужна повторяемость, чтобы отличить угрозу от шума. Полностью автоматическая экстракция «без ручного тегирования» — прямой путь обратно к этой болезни, только теперь без возможности объяснить, ПОЧЕМУ система что-то запомнила.

Последнее, чего памяти пока не хватает — забывания (TTL). Банк, который только растёт и никогда не чистит устаревшее, копит правила, актуальные для канала полгода назад, но не сегодня. Синаптический прунинг — не дефект, а функция: без него старый шум влияет на решения так же весомо, как свежий сигнал. Простое лечение — рядом с полем «сколько раз повторилось» добавить «когда в последний раз подтвердилось», и раз в месяц МЕХАНИЧЕСКИ (скриптом, не ИИ) помечать давно не подтверждавшиеся правила «под вопросом».

Токеномика: откуда берутся токены — чат 1×, агент 4×, мультиагент 15×

Теперь переходим к метаболизму. Токены — это энергия системы, её АТФ; каждый прочитанный файл памяти, каждый результат retrieval, каждый ход рассуждения сжигает калории, за которые ты платишь. И расход зависит не столько от модели, сколько от АРХИТЕКТУРЫ вокруг неё.

Базовая шкала, которую надо знать наизусть: обычный чат — это 1×. Агент (модель с инструментами в цикле) тратит примерно в 4× больше токенов, чем чат. Мультиагентная система — примерно в 15× больше (проверено, Anthropic). Причина простая: каждый агент носит свой контекст, каждый вызов инструмента возвращает результат обратно в окно, а несколько агентов дублируют базовый контекст между собой. Там же Anthropic называет ещё одну отрезвляющую цифру: объём потреблённых токенов сам по себе объясняет 80% разброса в качестве (проверено) — то есть многоагентная система работает лучше во многом просто потому, что тратит больше, а не потому что «умнее по устройству». Это не индульгенция на расход, а предупреждение: 15× легко превращается в счёт, не оправданный результатом.

Насколько велик может быть счёт — показывает крайний пример: создатель OpenClaw за месяц сжёг $1.3 млн на 603 млрд токенов через 100+ параллельных агентов (проверено, но с важной оговоркой: это стоимость РАЗРАБОТКИ самого OpenClaw, а не пример эксплуатации в проде). Твоя фраза про «монстра, кушающего $1000 в минуту» — не паранойя, а реальный класс риска при бесконтрольном параллелизме.

Отдельно про долю впустую: по разным оценкам до ~70% оплаченных токенов не приносят прямой ценности — уходят на дублирование контекста между агентами, переключения, отсутствие кеширования (осторожно: первоисточник не найден; цифра гуляет по вторичным блогам, это порядок величины, а не установленный факт).

Как контекст раздувается: механика молчаливого переполнения

Понять, откуда берётся раздувание, важнее, чем бороться с симптомом. Есть цифры про внутреннюю механику агентных инструментов, которые прямо ложатся на твою боль (осторожно: они из реверс-инжиниринга, не проверялись отдельно; трактуй как ориентир, а не спецификацию): автокомпакция срабатывает задолго до формального лимита окна и, сработав, сжимает историю в короткий блок — «выбрасывая каждое прочтение файла, каждую цепочку рассуждений, каждое промежуточное решение». Чтение файла жёстко обрезается без предупреждения, что хвост потерян. Длинные результаты инструментов уходят на диск и подменяются коротким превью — агент не знает, что видит не всё. А у каждого субагента своя память и свой цикл компакции — пять параллельных субагентов дают суммарно в разы больше рабочей памяти, чем один.

Клинический вывод: главная опасность — не «дорого», а «молча». Автокомпакция стирает контекст без симптома, и агент продолжает уверенно работать с дырявой памятью. Есть и второй тревожный факт: контекстное окно эффективно используется лишь на 50–60% от заявленного размера — «не начинай сложные задачи на половине разговора, качество деградирует» (осторожно: первоисточник не найден). Практический рецепт отсюда прямой: дробить любую многошаговую задачу на фазы с явной верификацией между ними, и начинать свежую сессию не по факту переполнения, а по факту СМЕНЫ ЭТАПА — даже если токены формально не кончились.

Пять рычагов дешёвой системы by design

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

Первый — изоляция контекста. Каждый субагент получает минимальный контекст под свою подзадачу, а не «весь на всякий случай». Это лечит и деньги (не носим лишнее), и качество (нет lost-in-the-middle). Субагент, делающий разведку, возвращает в оркестратор только ВЫВОД, а не весь процесс поиска — так он работает как орган сжатия контекста, а не его раздувания.

Второй — внешняя память вместо контекста. Промежуточные результаты, черновики промптов, сырые логи ошибок живут в файлах/scratchpad/memory-bank, а модель ЯВНО решает, когда их прочитать (retrieval по запросу), а не таскает постоянно в окне. Это одновременно снижает счёт и защищает от context anxiety — меньше шума, из-за которого модель «устаёт» раньше.

Третий — компакция и кеширование. Prompt caching резко удешевляет повторное чтение СТАБИЛЬНОГО контента (system prompt, инструкции, DNA канала), но НЕ помогает, если содержимое меняется от вызова к вызову. Отсюда правило: делить память на стабильную часть (кешируется, ставится в начало промпта) и volatile-часть (последние N событий, свежие метрики — маленькая, идёт отдельно, чтобы не сбивать кеш). Отдельно — кеш АРТЕФАКТОВ между этапами: «эту нишу уже анализировали вчера — не пересчитывать». В индустриальном кейсе связка smart-routing + семантический кеш (40% подшагов из кеша) + песочница с лимитом попыток дала −70% расходов и 99.9% надёжности (проверено).

Четвёртый — лестница моделей (tiered computation). Твоё же правило: дешёвая модель на механику и зрение, средняя на чёткий код, дорогая на архитектуру и синтез. Не гоняешь же кардиохирурга на забор крови. Важная поправка из твоего собственного замера: на чётких код-задачах средняя модель равна дорогой по успеху, но кратно дешевле — при этом на сложных/мутных агентных стадиях понижать модель НЕЛЬЗЯ без теста (там дешёвая модель тратит больше токенов на блуждание). Отдельно к памяти: сам retrieval (найти релевантные записи по полям) — механическая задача, её не надо делать дорогой моделью; дорогая нужна только на рассуждении над уже извлечённым.

Пятый — mechanical-first (скрипт вместо ИИ, где можно). Твой замеренный контраст нагляден: LLM-аудит 10 тулок стоил ~4M токенов, тот же результат через grep — ~0. Любой цикл по репо/файлам/сервисам (поиск, подсчёт, health-статус, ревизия TTL) — это скрипт за копейки; LLM оставляем только там, где внутри неоднозначное суждение. Это самый недооценённый рычаг: он не оптимизирует расход, он его ОБНУЛЯЕТ на целом классе задач.

Стоп-краны и бюджеты: метаболизм под контролем

Даже здоровый метаболизм нуждается в предохранителях — иначе одна зациклившаяся задача сжигает бюджет, как гипертиреоз сжигает тело. У тебя стоп-кран уже есть: «выше порога чтения кеша или цены за прогон — стоп и пересборка». Это конкретная реализация «rate limiting + timeout». Второй предохранитель — на уровне инфраструктуры: resource-governor как брокер лимитов на генерации; «запусти N проектов» → все параллельно, а governor пейсит расход.

Чего стоит добавить осознанно — не только денежный стоп-кран, но и АГЕНТНЫЕ промежуточные чекпойнты внутри длинной (в т.ч. ночной) сессии: критик проверяет прогресс каждые N шагов и либо продолжает, либо откатывает, прежде чем ошибка на шаге 2 испортит шаг 7. И трезвый бюджетный расчёт под масштаб: индустриальная норма faceless-канала — заметные сотни долларов в месяц (осторожно: ориентир из аналитики кейсов, не жёсткий факт), и «десятки каналов» по этой норме не влезают в твой бюджет. Единственный путь, которым рост числа каналов НЕ масштабирует расходы линейно — это как раз замкнутая память: каждый раз, когда per-generator банк предотвращает уже известный дефект, ты экономишь токены на генерацию и повторный QC; каждый раз, когда per-channel банк удерживает канал в его DNA — меньше отклонённых видео. Память и токеномика — это не две темы, а один орган: дешёвая система by design и есть система с хорошей памятью.

Часть 3. Иммунная система, ночной строитель и выбор ядра

Иммунная система: надёжность, guardrails и деньги

Все предыдущие разделы отвечали на вопрос «как построить». Этот отвечает на другой: как не проснуться утром к сожжённому бюджету, зафлаженному каналу или горе битых проектов. Для завода это не абстрактная страшилка — он уже показывал реальные примеры саморазрушения без присмотра: зомби-задачи генерации, которые «пиннят» слоты аккаунта и жгут деньги впустую; облачный голосовой эндпоинт, вхолостую евший около 38 долларов в сутки, пока не поставили сторож-скрипт (это внутренние данные завода, внешне не проверяемые, но логика «простаивающий GPU жжёт деньги без программного сторожа» общеизвестна). То есть тема — не теория рисков ИИ, а прямое продолжение твоих пяти законов, только формализованных как архитектура, а не как «Лучиан помнит и одёргивает руками».

Держи в голове медицинскую картинку, она здесь работает буквально. Guardrails — это иммунная система завода, и она не один барьер, а несколько слоёв, накрывающих друг друга. Кожа — это фильтры на входе (валидация промпта до отправки в генератор). Слизистые — валидация на границах между сервисами. Врождённый иммунитет — детерминированные проверки, которые срабатывают мгновенно и не думают (скрипт, а не LLM). Приобретённый иммунитет — evals и обучение на прошлых инцидентах: он специфичен и совершенствуется от заражения к заражению. Human-in-the-loop сегодня — это дежурный врач у койки постоянно; цель — перевести его в консультанта, которого зовут только на сложный случай, а не в аппарат, без которого пациент не дышит.

Guardrails — это архитектура контроля доступа, а не фильтр контента

Главная переформулировка, которую надо усвоить: guardrails — не «фильтр мата на выходе», а системная архитектура контроля над действиями. Она делится на три точки. На входе (input) — проверка того, что вообще пришло в систему; у завода это уже частично живёт как QC-петли и переформулировка темы до нескольких раз, когда разведчик ниш притащил тему, ложно триггерящую «dangerous content». На выходе (output) — валидация схемы SEO-пакета и отсев явного брака; thumbnail-studio со своим vision-QC — это уже готовый output-guardrail, просто под другим именем. И, самое важное для тебя, — контроль на уровне действий (interaction guardrails), где решается не «хорош ли текст», а «можно ли вообще выполнить это действие».

Именно этот третий слой формализует твоё требование «полная автономия, кроме денег». Модель простая — четыре категории действий с разным иммунным ответом:

• READ (чтение метрик, статуса проекта, памяти) — выполняется автоматически, иммунитет пропускает без вопросов.
• WRITE (генерация видео, правка скрипта, апдейт памяти) — автоматически, но с валидацией перед выполнением.
• DELETE (удаление проекта, отзыв токена, отмена генерации) — требует одобрения человека.
• ТРАТА денег — отдельная жёсткая категория поверх этой триады, подтверждение ВСЕГДА.

Это не новое правило, а обобщение уже существующего «дорогое сам не запускай — спроси». Разница только в том, что сейчас это инструкция агенту в промпте, а для ночной автономии она должна стать программным контролем на уровне API. И вот почему это принципиально: LLM может забыть инструкцию под давлением заполненного контекста или обойти её под prompt injection. Обещание модели — это иммунитет, который иногда спит. Код — это иммунитет, который не спит никогда.

Практический вывод для снятия гейтов: не убирать финальное одобрение, а разложить единый гейт на матрицу риска по каждому под-шагу. Выбор темы и генерация скрипта — низкий риск, обратимо, дёшево → 100% автономно. Генерация голоса, картинок, видео — тратит деньги, но в рамках бюджета → автономно, но под денежным гейтом. Обложки и SEO — обратимо → автономно с QC. Публикация на YouTube — средне-высокий риск, необратимо публично → автономно, ЕСЛИ evals прошли порог. Дорогая генерация и удаление проекта/канала/доступов — всегда подтверждение. Здесь два независимых источника — гайд по guardrails и полевой отчёт о провалах агентов — сходятся на одной и той же лестнице (tiered autonomy). Когда два разных источника независимо приходят к одной архитектуре — это не мода, а системный принцип.

Денежный гейт как код, а не как обещание

Твоя единственная красная линия должна быть реализована технически так. Каждый платный вызов — генерация медиа, синтез голоса, дорогое видео, аренда GPU — уже проходит через одну точку: слот resource-governor. Это и есть правильное место, чтобы встроить budget-gate. Гейт работает в три уровня: в рамках дневного лимита — авто; выше лимита, но ниже разового потолка «дорогой операции» — авто с логом и уведомлением постфактум; сверх потолка или явно помеченная дорогая категория — блокирующий запрос подтверждения в Telegram, и пайплайн встаёт на паузу до ответа. Отдельно — ежедневный автоотчёт: скорость расходов, стоимость на видео и на канал, аномалии.

И тут важный урок из практики завода: контроль стоимости — это архитектура, а не выбор модели подешевле. История с голосовым эндпоинтом за 38 долларов в сутки вхолостую лечится не «моделью дешевле», а сторож-скриптом, который следит за простаивающим платным ресурсом. Этот паттерн стоит тиражировать на все GPU/платные компоненты, а не изобретать заново на каждом. По объёму данных индустрии: у оплаченных токенов в агентных системах большая доля — порядка 70% — уходит не в ценность (осторожно: это широко цитируемая оценка порядка величины из вторичных источников, не первичное исследование). Это ровно тот «монстр, кушающий 1000 долларов в минуту», которого ты боишься, — и лечится он mechanical-first, кешем и лестницей моделей, а не одним стоп-краном.

Критик-агент и evals: чем снять человеческий гейт

Чтобы «агент-критик сам решал, публиковать или нет», нужны evals, иначе это «оценка на глаз» (vibes-based), прямо названная типичной ошибкой. Рецепт приземлённый: 25–50 куратированных примеров, 2–3 ключевые метрики, baseline до изменений. Для завода — завести датасет из 30–50 прошлых видео с известным исходом (retention, CTR, страйки, комментарии) и разметить один раз вручную. Offline evals — это unit-тесты для контента до публикации (хук в первые 3 секунды, синхрон звука и видео, отсутствие явных фактических ошибок и copyright-риска). Online evals — мониторинг после (реальный retention, аномалии в комментариях), и это ровно то, что замкнёт «холостую» стадию LEARNING.

Здесь — ключевой урок Anthropic про долгоживущих агентов, и его важно понять правильно. Если попросить агента оценить собственную работу, он, скорее всего, её похвалит, даже когда для человека качество очевидно посредственное (проверено — это из статьи Anthropic «Effective harnesses for long-running agents»). Лекарство — adversarial evaluation, по аналогии с иммунным консилиумом: отдельный evaluator-агент с системным промптом, целиком посвящённым скепсису, судит работу генератора. Это НЕ то же самое, что попросить ту же модель «а теперь покритикуй себя» в одном контексте — разница именно в изоляции ролей. Настроить отдельного скептика оказалось куда проще, чем заставить генератор быть строгим к самому себе. Три условия, при которых критик реально работает: сделать субъективное качество измеримым (не «хорош ли скрипт», а «хук ≤3 предложения, факт-чек по каждому утверждению»); взвесить критерии под слабые места модели; дать критику инструменты реально взаимодействовать с артефактом, а не судить по описанию — как vision-QC реально «смотрит» на обложку, а не читает промпт.

И сразу калибровка ожиданий, чтобы не считать первую неделю провалом. Реалистичная планка агентной системы — не 99.99% как у классического ПО, а 85–95% успеха на простых задачах с человеком на краевых случаях. Сбои неизбежны при такой архитектуре; разница между «система, которая падает и разваливается» и «которая падает и сама чинится» — не отсутствие сбоев, а наличие чек-поинтов и наблюдаемости вокруг них.

Loop of Death и вероятностная математика длинных цепочек

Есть болезнь, которую надо знать в лицо. Loop of Death: агент пишет код с ошибкой → среда возвращает ошибку → «исправление» плодит новую ошибку → цикл повторяется, сжигая самые дорогие токены. Завод уже болел этим в другой форме: упавший прогон, суета kill+relaunch+resume загоняет проект в конфликт и стадию «failed» навсегда. Твоё правило «чинить вперёд, не с нуля» — это твоя, полевым опытом найденная версия индустриального лекарства. А индустриальное лекарство из трёх частей даёт конкретный результат: smart routing (маленькая дешёвая модель классифицирует сложность) + semantic caching (около 40% подзадач обслуживаются из кеша) + sandboxed execution с жёстким лимитом попыток — вместе это снизило расходы на 70% и дало 99.9% надёжности (проверено по первоисточнику). Для ночной автономии это надо зафиксировать явным конфигом: N автоматических повторов на стадию, дальше не бесконечный цикл, а эскалация или запасной путь.

Почему длинные цепочки вообще опасны — чистая арифметика. При точности 95% на шаг десятишаговый прогон имеет только 0.95¹⁰ ≈ 60% шанс дойти до конца без единого сбоя (проверено — расчёт верен; но это модельная величина, а не измеренный на практике процент). Вывод не «автономия невозможна», а «держи пожарный шланг короткими управляемыми очередями»: каждая промежуточная проверка «перезагружает» вероятность ошибки. Это буквально твоё правило «упал — resume, не пересоздавай», только выведенное из теории вероятностей. И родственная болезнь — context anxiety: по мере заполнения контекстного окна модель не просто теряет связность, она меняет поведение — торопит финал, объявляет «готово», хотя не готово (проверено, тот же источник Anthropic). Лекарство — сброс контекста между этапами: свежий контекст, чтение progress-файла, передача через файл. Это независимо выведенный твой же принцип «оркестратор передаёт выжимки, не сырьё».

Sandbox: изолировать ночного строителя от секретов

Самая рискованная часть будущей системы — ночной «строитель приложений», потому что он буквально пишет и исполняет непроверенный код без присмотра всю ночь. Три уровня изоляции с разным компромиссом. Docker (уже на заводе) достаточен для доверенного кода, но контейнеры делят ядро хоста — эксплойт ядра компрометирует всё. gVisor — прослойка-ядро в пользовательском пространстве, оверхед заметный, но терпимый для тестового кода. Firecracker microVM — стандарт для недоверенного кода в проде, аппаратная изоляция, быстрый старт. Практический вывод жёсткий: ночной билдер НЕ должен исполнять код на том же сервере, где крутится боевой завод, и по умолчанию НЕ должен видеть боевые credentials — токены YouTube и секреты боевых сервисов остаются вне его зоны видимости, ему прокидываются только явные тестовые ключи.

Почему это не паранойя — чужой урок. У self-hosted агентного гейтвея OpenClaw в 2026-м нашли CVE-2026-25253 (CVSS 8.8): один клик по вредоносной ссылке уводил auth-токен и давал удалённое исполнение кода; онлайн светилось более 30 000 инстансов (проверено, с уточнением: экспозиция в основном от пользовательских настроек «LAN-режима», а не только дефолта). У завода прямые порты уже закрыты снаружи, доступ только через прокси с единым входом — это ровно то, чего не хватало уязвимым инстансам, и это надо держать жёстким инвариантом для любого нового сервиса. Второй урок — заимствованный «из интернета» код опасен: независимые исследования каталога скиллов OpenClaw нашли, что заметная доля скиллов небезопасна — одно исследование насчитало 283 из 3984 скиллов (около 7%), архитектурно светящих credentials, другое — 341 из 2857 (около 12%) с активным вредоносным ПО (исправлено: ходившая цифра «15% malware» ни одним источником не воспроизводится). Мораль простая — любой скачанный скилл/плагин перед боевым использованием читается глазами. Итоговая защита строится по принципу глубокой обороны, четыре слоя, ни один не заменяет другой: guardrails (фильтр до выполнения) → sandbox (изоляция) → лимиты ресурсов → мониторинг (каждое действие логируется и может быть остановлено).

Ночной строитель приложений

Теперь — приоритет №1: система, которая по одной команде за ночь строит сайт/тулзу/MVP без тебя. Главная мысль сразу: это не новый продукт и не фреймворк, который надо скачать. Это применение уже знакомого паттерна завода — специализированные роли + гейты + память + QC-петля — к новому типу артефакта: работающему коду с интерфейсом. Разница с видео-конвейером всего в двух местах. Первое: верификация «на глаз» из просмотра ролика превращается в скриншот UI. Второе: единица параллелизма — не «тема видео», а «архитектурный вариант решения». Всё остальное — оркестрация, гейты, брокер ресурсов, память, экономика токенов — переносится буквально.

Три референс-архитектуры как три органа

Индустрия к 2026-му сошлась на трёх архитектурных семьях, и все три полезны как разные органы будущей системы. Первая — примитивы Claude Code, которыми ты уже пользуешься. Claude Code — это не чат-бот, а программируемая платформа из кирпичей: CLAUDE.md как конституция репозитория; Skills как переиспользуемые процедуры, грузящиеся только при вызове (прямое попадание в токеномику — твоё «повторил дважды → оформи скиллом» это и есть); субагенты с изолированным контекстом; и — критично для иммунитета — Hooks, про которые ключевая цитата: «hooks execute deterministic code. They cannot hallucinate». Hook либо пропускает действие, либо блокирует его по коду выхода. Это и есть детерминированный guardrail: hook проверяет сумму и тип операции ПЕРЕД тем, как агент потратит деньги.

Вторая — Devin (Cognition AI): составная архитектура из разных ролей Planner → Coder → Critic → Browser Agent. Это не один агент, «разговаривающий сам с собой», а четыре разные роли. Её ключевое свойство — самоисправление: если тесты падают, система не идёт дальше, а чинит текущую задачу. Без такой петли ночной прогон просто накопит гору сломанного кода к утру. Третья — OpenHands: событийная (event-sourced) архитектура, где все взаимодействия — неизменяемые события в логе. Это даёт детерминированный повтор и надёжное восстановление после сбоя — прямой техперенос твоего закона «упал прогон → resume, никогда не удалять готовое». Вывод: у тебя уже есть мозг (подписка Claude), значит фундамент — примитивы Claude Code; разделение ролей Devin реализуется через субагентов с разными системными промптами и разными правами инструментов; событийность OpenHands — это урок «пиши состояние в файлы, не держи всё в одной длинной сессии».

Цикл план → код → тест → критика → скриншот → доработка

Рабочий цикл ночи собирается так, по шагам. PLAN: план пишется в файл, не в контекст. CODE: исполнитель реализует план, пишет код и тесты. TEST: детерминированные проверки — юнит-тесты, линтер, сборка, ноль токенов мозга. CRITIQUE: независимый критик в другой сессии, который видит только артефакт и требования, но НЕ видит рассуждений генератора. SCREENSHOT: агент запускает приложение и делает скриншот ключевых экранов (десктоп + мобильный). FIX/ITERATE: по вердикту критика — либо релиз, либо возврат на CODE, с жёстким лимитом 3–5 итераций.

Почему шаг CRITIQUE не может быть той же моделью или сессией — цитата, которую стоит запомнить: «Любая ошибка, сделанная при генерации, скорее всего переживёт и ревью — потому что ревьюер думает так же, как автор». Критик твоих лендингов должен получать только результат и исходное ТЗ, без хвоста рассуждений генератора, иначе унаследует те же слепые пятна (это широко наблюдаемая практика, а не единичное исследование). Это та же архитектура, что уже стоит в thumbnail-studio: vision-QC как отдельный судья поверх генератора — паттерн верный, надо просто повторить его для кода и UI. Требования к промпту критика: конкретные критерии, не «найди баги» (для кода это «работает ли форма, нет ли ошибок в консоли, проходят ли тесты, не пусто ли на мобильном»); структурированный вердикт в JSON, чтобы оркестратор решал «фикс или релиз» программно; жёсткий лимит итераций; опционально — разные семейства моделей для генератора и критика ради независимости.

Почему скриншот обязателен

Для видео QC у тебя уже двухуровневый — детерминированный плюс зрение. То же нужно для UI. Агент может написать синтаксически верный, тестово проходящий, но визуально сломанный код: наехавший текст, битая раскладка на мобильном, пустой экран. Unit-тест этого не поймает. Скриншот-шаг — это дополнительная «перезагрузка вероятности ошибки», которую нельзя заменить только тестами. И глубже — главная опасность ночного режима сформулирована так: «Величайший риск — молчаливый сбой: агент, который работает, не выдаёт ошибку, но производит неверный результат». Молчаливый сбой опаснее явной ошибки: явная падает и зовёт на помощь, молчаливая тихо выдаёт мусор и идёт дальше. Именно поэтому «раз не упало — значит работает» — ложь, и защита от неё — скриншот плюс структурированные логи, а не отсутствие исключений. Технически скриншот-QC делается недорого через headless-браузер, GPU для этого не нужен.

Организация ночи: cron, очередь, resume, короткие фазы

Три способа запустить режим без присмотра на твоей инфраструктуре. Самый прямой — cron + headless-вызов мозга по таймеру (у тебя уже так работает утренний разведчик X); просто для одношаговых задач, минус — нет повторов и зависимостей из коробки. Второй — оркестрация с очередью задач для конвейера с зависимостями (повторы с нарастающей паузой, история прогонов); это ровно то, чем является твой выключенный оркестратор — для строителя приложений нужен тот же паттерн, новый оркестратор под код вместо видео. Третий — управляемые облачные пайплайны — избыточен для self-hosted, но полезен принципом по умолчанию: «процессы только читают; запись требует явного safe-output; результат никогда не вливается автоматически». Это готовый шаблон твоего правила про деньги, расширенный на любое необратимое действие: ночью — читай, анализируй, генерируй, выкладывай в песочницу; наружу (публикация, боевой деплой, оплата) — либо явный safe-output с логом, либо утреннее одобрение.

И безопасный чек-лист для ночи: ограниченные права (у читающего агента нет прав записи и шелла); валидация результата ПЕРЕД действием, не после; таймауты на каждый шаг и на весь прогон; человеческое ревью для рискованного; и обязательный мониторинг ради ловли молчаливых сбоев. Отсюда — золотое правило дизайна ночи: полная автономия — это не один десятичасовой марш-бросок без единой точки контроля, а десятки коротких проверяемых фаз, каждая со своим QC-гейтом, просто человек не смотрит на них до утра. Между фазами — чекпойнт-артефакт на диске (коммит, файл состояния), не контекст сессии, чтобы при сбое перезапускалась только провалившаяся фаза. И реалистичный настрой из практики: для НОВОГО типа задачи первая попытка — во многом черновой мусор, который строит контекст, вторая уточняет нюансы, третья даёт рабочий результат. Значит в дизайн ночи закладывается минимум 2–3 цикла критики, а не одна попытка. Отдельный мост к консультант-фабрике MVP — паттерн Best-of-N + судейская панель: несколько исследователей пишут варианты в РАЗНЫЕ директории/ветки (не в один код, иначе «ломается сборка — заблокированы все»), а разнородная судейская панель ранжирует их турниром. Время веера ≈ времени самого медленного варианта, а не сумме — потому и нужен брокер параллелизма, как resource-governor для видео.

Выбор ядра

Здесь надо сразу развести два вопроса, которые постоянно путают. «Мозг» (какая LLM думает) — уже решён: подписка Claude с мульти-аккаунт подстраховкой, НЕ API-ключи; это работает и менять его не надо. «Оркестратор» (кто управляет циклом агент→инструмент→агент, кто хранит состояние, кто порождает субагентов) — вот это и есть настоящий вопрос ядра. И важное наблюдение: завод де-факто уже работает как workflow — конвейер стадий с человеческими гейтами, — а не как «свободный» агент. Оркестратор существует, но выключен. Значит переход к ночной автономии — это не смена фреймворка, а включение оркестратора и замена части человеческих гейтов на агентов-критиков.

Матрица восьми систем — коротко, почему не они

Пройдём консилиумом по кандидатам. LangGraph — «граф, а не абстракция»: состояние/узлы/рёбра дают детерминированный контроль потока и чекпойнт после каждого шага (та самая защита от потери прогресса при сбое). Кейс масштаба — Klarna: сокращение среднего времени резолюции обращений на 80% при 85 млн пользователей (проверено); ходившие цифры «853 сотрудника» и «60 млн долларов экономии» исправлены — официально фигурирует эквивалент 700 сотрудников, а долларовой оценки в кейсе нет вовсе. Для тебя LangGraph — это язык описания графа, максимум библиотека внутри одного сервиса, но не «операционная система» всего завода: полная миграция на его абстракции состояния — избыточное переписывание уже работающей инфраструктуры. CrewAI — «роли вместо графа», красивая ролевая модель, но с доказанным дефектом: иерархический менеджер не умеет условно пропускать агентов и выполняет всё подряд — 15 759 токенов за 38 секунд на простой запрос вместо ожидаемых ~200 (проверено дословно). Это буквально иллюстрация твоей токеномической боли — как ядро отклоняется. AutoGen/AG2 — «диалог вместо графа», полезен для дебатов и судейских панелей, но незрел (beta) и склонен к бесконечным циклам без явного лимита раундов; годится как локальный паттерн для судейской панели, не как каркас. OpenAI Agents SDK отклоняется сразу по определению — привязан к чужим моделям, несовместим с мозгом-Claude.

OpenClaw ближе всего по духу (ты его пробовал, его файлы памяти калькируют твой memory-bank, двухуровневая иерархия субагентов — нужный предохранитель против разрастания), но как ядро отвергнут по двум причинам. Первая — токен-бомба параллелизма: у создателя 100+ параллельных агентов сожгли 1,3 млн долларов за месяц на 603 млрд токенов (проверено, но с важной оговоркой — это стоимость РАЗРАБОТКИ самого OpenClaw, а не пример эксплуатации в проде; смысл предупреждения «монстр при неконтролируемом параллелизме» остаётся). Вторая — уязвимости 2026 (та самая CVE и небезопасные скиллы в публичном каталоге). Разумный компромисс — заимствовать идеи OpenClaw (каналы связи, файлы уроков, ограничение глубины субагентов), но реализовать их на Claude Agent SDK, а не тащить чужой код. OpenHands/MetaGPT — узкоспециализированы: отличный строительный блок для «строителя приложений», но не оркестратор всего бизнеса. И n8n — это клей, а не мозг: инструмент для быстрых интеграционных мостиков, использовать точечно, не архитектурно.

Рекомендация: Claude Agent SDK + PAUL-дисциплина + заимствования

Финальное решение (совпадает с DECISIONS.md): ядро оркестрации — Claude Agent SDK поверх уже существующей подписки Claude. Причина в том, что это единственный кандидат, совместимый по всем осям сразу: не альтернативный фреймворк со своей философией состояния, а официальная библиотека поверх той же модели работы, которую завод уже использует. Субагенты получают изолированный контекст — наследуют только свой системный промпт и CLAUDE.md, но НЕ историю родителя и не его промежуточные результаты, с лимитом глубины вложенности 5 уровней (проверено по документации). Это прямое архитектурное лекарство твоей токеномической боли — «оркестратор передаёт выжимки, не сырьё» становится встроенным свойством, а не дисциплиной, которую надо помнить. Hooks дают детерминированные guardrails без LLM — и это то самое место, где живёт денежный гейт как код.

Поверх ядра — три надстройки, ни одна из которых не заменяет ядро, а накладывается на него. Первая — PAUL-дисциплина (Plan → Apply с проверкой → Unify) для режима «Строитель приложений»: явные критерии приёмки до старта работ и честные статусы вроде «готово с оговорками» вместо бинарного «готово». Это прямое лекарство от Loop of Death и от «агент сказал готово, а на самом деле нет»; и заметь — твой пайплайн план→код→критика→тест→визуальная проверка→доработка почти дословно совпадает с этой дисциплиной. Вторая — LangGraph-паттерн как модель мышления, а не как библиотека: у тебя уже есть чекпойнт-файл состояния в каждом проекте; включение оркестратора с персистентным состоянием закрывает ту же дыру, которую концептуально решает LangGraph, без тащения новой базы данных. Третья — дебаты в стиле AutoGen локально для модуля судейской панели: параллельные MVP-варианты, критикующие и ранжирующие друг друга; это узкий изолированный сценарий, который закрывается несколькими субагентами с разными системными промптами, без внедрения целого нового фреймворка. Отдельно стоит помнить, что ни одно ядро само по себе не спасает от типовых ловушек — Loop of Death, перезапись чужих результатов, мнимая делегация, токен-бомба параллелизма: против них работает дисциплина (лимит попыток, структурированный вывод, стоп-краны и лестница моделей), а не выбор фреймворка. Именно поэтому ядро — это Agent SDK как расширение того, что уже работает, PAUL как иммунная дисциплина поверх него, и заимствованные, а не импортированные, идеи из OpenClaw и LangGraph.

Часть 4. Три завода, чужие шрамы и дорога в понедельник

Один организм, а не три проекта

Если смотреть на твой год как врач на пациента, три направления — контент-фабрика на десятки каналов, универсальный строитель приложений и консультант-фабрика MVP — это не три разных организма, которых надо вырастить с нуля. Это три органа одного тела, и большая часть анатомии у тебя уже есть. Завод сегодня — почти учебниковая мультиагентная система: конвейер стадий ⓪→⑨ — это иерархическая оркестрация (hierarchical orchestration), где channel-hq играет роль дирижёра-супервизора, а генераторы — рабочих-исполнителей; memory-bank с тремя банками — это разделяемая память (shared memory), общая «нервная система»; resource-governor — брокер ресурсов; а связка thumbnail-studio + vision-QC — зачаток контрольной петли. Ты построил это раньше, чем прочитал теорию.

Не хватает по документам ровно трёх вещей, и они одни и те же для всех трёх направлений: дирижёр (orchestrator.mjs) выключен, поэтому завод работает как workflow с ручными гейтами, а не как agent, который сам решает число шагов; стадия обучения (LEARNING) холостая — метрики не текут обратно в память автоматически; и человек до сих пор стоит на каждом одобрении там, где по-хорошему должен стоять агент-критик. Держи в голове разницу как диагноз: workflow ломается непредсказуемо на нестандартном входе, а agent должен деградировать предсказуемо — откатиться, попросить уточнение, взять безопасный дефолт. Полная ночная автономия — это не «тот же конвейер без гейтов», а качественный переход от workflow к agent.

Контент-фабрика: путь к десяткам каналов и что ломается первым

Наивный сценарий — просто включить дирижёр и оставить «одобрение = кнопка человека». Это не даст автономии: конвейер доедет до финального одобрения и там же упрётся в тебя. Правильный ход — заменить человеческий гейт на агент-критика по паттерну Planner-Executor-Critic. Критик получает финальный пакет (видео + обложка + SEO) и выносит вердикт по явному чек-листу — хук, визуал, звук, факты — ровно как ты уже это формулируешь вслух.

Одно инженерное правило здесь — жёсткое, и оно проверено первоисточником. Критик обязан получать НЕ ту же сессию и не тот же контекст, что генератор. Иначе он унаследует те же слепые пятна — это самопроверка одной моделью (same-model review), и она не работает. Anthropic формулирует прямо: разделение агента, делающего работу, и агента, судящего её, — сильный рычаг, а «настроить отдельного скептичного оценщика оказывается гораздо проще, чем заставить генератор критиковать собственную работу» (проверено). Медицинская аналогия точная: хирург не оперирует сам себя. Технически это отдельный вызов с чистым контекстом, на вход которого идёт только финальный артефакт и требования — без истории генерации.

Вместо бинарного «одобрить/отклонить» нужна матрица автономии по риску (tiered autonomy). Чтение и черновики — сто процентов автономии. Публикация и правки SEO — решает критик, эскалация к тебе редка (репутационный риск обратим, видео можно снять). Всё, что тратит деньги сверх заранее одобренного бюджета на канал в день, — всегда твоё явное подтверждение. У тебя этот принцип уже живёт на одном шве (бесплатный голос на тестах, платный в бою) — задача распространить его на весь завод.

Обучение оживает не абстрактной «базой данных», а типологией памяти, наложенной на твои три банка: семантическая память — устойчивые выводы уровня «военные темы заходят лучше катастроф»; эпизодическая — конкретные прогоны с метриками в логе канала; процедурная — какие настройки генератора дают меньше отказов QC. Замкнутый цикл: аналитика YouTube (задержка ~72 ч) → агент пишет эпизодическую запись → раз в N видео агрегатор (это работа для средней модели, не дорогой) обновляет семантическую память профиля → следующая генерация читает обновлённый профиль.

Теперь диагноз, что сломается первым при переходе с трёх каналов на десятки. Первое — конкуренция за ресурсы (resource contention): governor существует именно для этого, но на одном канале уже понадобилось поднять параллелизм подготовки; на десяти нагрузка качественно другая, governor надо проверять на роль узкого места. Второе — дрейф качества, «эхо-камера обучения»: этот баг уже ловили в thumbnail-studio (агент учится хвалить сам себя), и при десяти параллельных петлях обучения риск растёт линейно — вот почему изоляция критика не роскошь, а несущая стена. Третье, и самое отрезвляющее — не техника, а экономика: 97% faceless-каналов не окупают вложений в производство, лишь 3% доходят до монетизации (проверено). Автономия просто ускоряет производство; она не даёт нишевого попадания. Масштабировать каналы быстрее, чем настроен радар форматов и оценка ниши, — значит масштабировать риск, а не доход: получишь десять автономных фабрик, штампующих контент в насыщенные ниши.

И токеномика. Включённое обучение + критик + возможный повтор делают каждое видео самым токеноёмким сценарием: мультиагентные системы потребляют примерно в 15 раз больше токенов, чем простой чат (проверено — цифра про исследовательскую систему Anthropic, не универсальный закон, но порядок верен). Отраслевая норма расходов на канал (по вторичным источникам — порядка нескольких сотен долларов в месяц; осторожно: первоисточник не найден) при «десятках каналов» превращается в бюджет, несовместимый с твоими рамками, — если не давить цену лестницей моделей. Это прямое следствие твоего же замера «средняя модель ≈ дорогой на чётких задачах, кратно дешевле», применённого не только к коду, но ко всей фабрике.

Строитель приложений: харнесс важнее модели

Здесь главный тезис короткий: харнесс важнее модели (the harness matters as much as the model) — это дословная цитата из рабочих материалов (проверено). Строитель приложений — не новая система, а обобщение того процесса, которым ты уже построил завод (git, патч-ноты, пять законов как персональный аналог CLAUDE.md) в переиспользуемый харнесс, применимый к любому новому репозиторию. Индустрия сходится к одному набору примитивов: файлы-память репозитория, прямая интеграция инструментов (git, тесты, shell), специализация субагентов, длинные циклы исполнения.

Две вещи стоит скопировать в харнесс намеренно. Первая — хуки вместо промптов (hooks, not prompts): это исполняемые скрипты в точках жизненного цикла агента, и, в отличие от промпта, «они не могут галлюцинировать» — детерминированный код физически блокирует действие. Линтер, тесты, проверка безопасности, проверка «не потратил ли денег» должны быть хуками, а не пунктом в промпте, который агент проигнорирует в три часа ночи. Это техническое воплощение твоего правила «скрипт вместо ИИ, где можно». Вторая — визуальная проверка (visual verification): LLM плохо «видит» вёрстку в коде, поэтому критик приложения не читает код глазами, а смотрит скриншот через vision-модель. Технология у тебя уже работает — это тот же vision-QC, что судит обложки, просто применённый к другому артефакту (UI вместо картинки).

И трезвая граница. Стопроцентная автономия в кодировании не работает — «проблемы вне распределения всегда будут свойством генеративных моделей, это неустранимо». Практики, у которых получилось, отказались от погони за полной автономией в пользу «держи пожарный шланг короткими управляемыми очередями». Эмпирика от инженера с недельным опытом ночных прогонов: первая попытка — 95% мусора (ИИ строит контекст, ты выявляешь реальные проблемы), вторая — 50%, третья — итерируемый результат. Вывод для ночного билдера: закладывай 2-3 внутренних цикла критики за ночь, а не «одна попытка → готово утром». Математика объясняет почему: при точности 95% на шаг десятишаговая цепочка успешна лишь в ~60% случаев — 0.95¹⁰ ≈ 0.60 (проверено как арифметика; это модельная оценка, не измеренный процент). Каждый чекпоинт «перезагружает» вероятность. Твои гейты — не бюрократия, а математически обоснованные чекпоинты; вопрос не «убрать их», а «заменить в тех же точках человека на автоматического критика».

Консультант-фабрика MVP: боли клиента → ночь → веер → демо утром

Это направление в индустрии называют мультиверс-разработкой (multiverse development): вместо последовательного выбора одной архитектуры пробуют несколько параллельных путей сразу, и это, по оценкам, лишь в 2-3 раза дороже линейной разработки при кратно большем обучении (осторожно: точный множитель первоисточник не подтверждает). Но веер — это не десять копий одного агента на одну задачу. Правильный паттерн — исследователь×критик с явно разными углами: один оптимизирует под производительность, второй — под простоту поддержки, третий — под дешевизну и скорость запуска. Дифференциацию задаёшь явно в промпте каждого, а не оставляешь на волю случая — иначе исследователи сходятся к похожим решениям. Для кофейни это буквально: один строит CRM, второй — бот лояльности, третий — панель управления запасами.

Сравнение вариантов — судейская панель турниром на выбывание: не попарно все со всеми (для десяти прототипов это 45 сравнений), а турнир — пары → полуфинал → финал, порядка десятка сравнений. И судьи разнородные, не один и тот же промпт трижды, иначе та же эхо-камера.

Как система поймёт домен, которого никогда не видела? Не «опиши боль в промпте и жди чуда». Гибридный подход (явные процедурные правила + понимание LLM) даёт заметный прирост качества против чистого «промпт-и-надежда» в незнакомом домене (называлась и конкретная цифра прироста, но осторожно: первоисточник не найден — качественный вывод верен и без неё). Практически: вечером ты не надиктовываешь боли свободным текстом, а прогоняешь их через структурированное интервью (structured intake) с явными полями — рабочий процесс, точки решений, практические правила. У тебя для этого уже есть кандидат-агент.

И самое важное для денег — честная граница, «проблема 70%» (70% problem): ИИ раскрывает ~70% решения быстро, а оставшиеся 30% (краевые случаи, безопасность, интеграция в боевую среду) так же трудоёмки, как раньше. Значит утренняя демонстрация клиенту — это не готовый продукт, а убедительный кликабельный прототип, который закрывает продажу. Твоя реальная монетизация — не сам ночной прогон (его себестоимость в токенах минимальна), а право продать вход в оплачиваемую фазу доработки клиенту, который увидел рабочий прототип и поверил. Это первая фаза модели «пилот → MVP → масштабирование», а не весь продукт за ночь.

Клей: одна ОС вместо трёх заводов

Твою боль №1 — «я сам клей между инструментами» — индустрия называет точным термином: проблема человека-клея (glue person / human as API). Лекарство — паттерн из двух слоёв: плоскость сотрудничества (collaboration plane) — читаемый человеком источник истины, куда ты структурированно бросаешь намерение («новый канал», «клиент, боли: …», «построй тулзу»), и агент-оркестратор, который сам мониторит эту плоскость, вызывает нужные API и возвращает результат. Один диспетчер с паттерном передачи (handoff) маршрутизирует задачу в нужный «завод» — контент, строитель или MVP-веер, — а не три изолированных системы, которые ты клеишь руками. У тебя уже есть кандидат на плоскость сотрудничества (заметки + персистентная очередь задач); не хватает автоматического мониторинга, который сейчас делаешь ты сам.

Главная развилка тут — общая память против передачи сообщений (shared memory vs message passing). При передаче сообщений агент B видит только вывод A, теряет исходный контекст, и каждый агент рассуждает из своей частичной реальности — решения противоречат друг другу. Ты эту проблему уже частично решил единым memory-bank. При добавлении двух новых направлений рекомендация — единый граф знаний, чтобы опыт контент-фабрики (какие ниши денежные) был доступен и разведчику возможностей, и MVP-строителю, и наоборот. Вывод короткий: у тебя нет задачи «построить строителя и MVP-фабрику с нуля» — есть задача обобщить уже боевые паттерны завода на новые типы артефактов (код вместо видео, прототип вместо ролика). Каждый орган уже протестирован на реальном производстве.

Как реально зарабатывают на агентах: модели монетизации

Теперь чужие шрамы — что случалось у людей, уже построивших нечто похожее. Начнём с денег, потому что это твоя главная метрика. Наблюдаемые в поле модели монетизации сводятся к нескольким классам. Первый — соло-оператор с кластером агентов: публичные билдеры запускают несколько параллельных агентов на одну задачу и берут лучший вариант — прямой прообраз твоего MVP-веера (осторожно: декларируемые ими суммы доходов первоисточниками не подтверждаются). Второй — агентства «под ключ» за несколько тысяч долларов в месяц с клиента (осторожно: первоисточник не найден). Третий — фермы каналов, но с той самой поправкой: 97% не окупаются (проверено), выигрывают дисциплинированные, а не многочисленные.

Четвёртый класс, недооценённый, — продажа не агентов, а знания о них: курсы по построению агентных систем и сертификации собирают большую аудиторию, а формальное подтверждение навыка само становится аргументом продажи при консалтинге. Пятый — объём × автоматизация на легальных воронках: есть громкий кейс агента, рассылавшего десятки тысяч мелких счетов в день с конверсией ~2% (осторожно: цифры не проверены, и кейс этически сомнителен — брать не как рецепт, а как иллюстрацию класса «объём, недоступный человеку вручную», применимого к легальным холодным воронкам). Шестой — расширение автоматизации маркетинга за пределы контента: A/B лендингов, ценообразование, email-цепочки «уже крутятся как агентные джобы». Ключевая мысль поля: «рычаг смещается от создания ассетов к выбору, какие эксперименты запускать» — то есть твоя ценность как критика, выбирающего что публиковать, а не производителя контента руками.

Дом против VPS: полевой опыт

Твоя развилка размещения — не абстракция, у соло-билдеров есть год практики. Один известный оператор кодит год только через агента на арендованном сервере, без ноутбука, работает с телефона: «агент просто продолжает работать всю ночь, пока ты спишь» — прямая параллель с твоей целью. Он выкладывает в бой без промежуточной среды именно потому, что работает соло (и честно оговаривает: в команде рекомендовал бы иначе), но с обязательными бэкапами. Его же предупреждение: агент однажды чуть не снёс все файлы — «ещё причина не гонять кодинг-агентов на ноутбуке». Другой билдер описывает связку сервер + локальная машина + защищённая сеть с мессенджером как мобильным интерфейсом — структурно это ровно твоя связка.

Отсюда решение, к которому сходится ресёрч: гибрид, а не выбор одного узла. Арендованный сервер — «мозг снаружи» (оркестрация, память, панель, 24/7, не зависит от того, включён ли дома компьютер). Домашний ПК с мощной видеокартой — «мышцы по требованию» (локальный инференс, рендер, голос) через защищённую сеть, с облачным GPU как запасным вариантом, если ПК офлайн. И честная экономика, потому что исходные цифры пришлось исправить: собрать ПК с топовой видеокартой прошлого поколения нельзя за 900 долларов — сама карта стоит около 1050–1500, реалистичная сборка 1500–3500 (исправлено); аренда такой карты в облаке — 0.13–0.6 доллара в час, а не 15 (исправлено), из-за чего «окупаемость за 1-2 года» верна только против премиальных managed-сервисов, а не против честной GPU-аренды. Вывод не «у тебя уже стоит железо, поэтому его и используй», а «GPU по требованию — это уже правильный режим, его надо формализовать, а не менять».

Восемь грабель, на которые ты уже наступил — и как их зовёт индустрия

1. Два человеческих гейта — это не перестраховка, а избирательная автономия (selective autonomy): каждая проверка «перезагружает» вероятность отказа в цепочке 0.95¹⁰ ≈ 60% (проверено). Обратная крайность тоже провальна: тотальная зависимость от одобрения превращает систему в узкое место — снижать гейты надо постепенно, накопив статистику доверия по каждой стадии.
2. «Петля смерти» (Loop of Death): агент чинит ошибку, чинка рождает новую, дорогие токены горят по кругу — ровно твоё «залил одно видео и завис». Индустриальный рецепт: умная маршрутизация + семантический кэш (~40% подзадач из кэша) + песочница с лимитом попыток → −70% расходов, 99.9% надёжности (проверено). Governor у тебя уже играет роль такого ограничителя.
3. 95% пилотов ИИ-агентов не выживают при масштабировании — и не из-за модели, а из-за хрупких коннекторов, «тупого RAG» (свалить всё в вектор-базу и надеяться) и «налога на опрос» (постоянный опрос вместо событий) (осторожно: сводная отраслевая оценка). Прежде чем строить ночного дирижёра — проаудируй, что происходит при таймауте генератора, при неожиданном ответе API, при частичном ответе анализа ниши.
4. Faceless-провал: полная автоматизация без человека даёт галлюцинированные факты, нарушения копирайта, жалобы и бан канала (проверено, что 97% не окупаются; конкретный срок «бан за 2 недели» — осторожно: первоисточник не найден). Твои лаборатории стиля и голоса уже решают проблему «одинаковой архитектуры для всех ниш», до которой многие фермы не доходят.
5. Токен-взрыв: 15× против чата (проверено) плюс до 70% оплаченных токенов без пользы (осторожно: вторичный источник). Лечится твоей же лестницей моделей и умной маршрутизацией по стоимости задачи — это не заплатка, а принцип архитектуры с первого дня.
6. Человек-клей — общая боль, а не твоя личная; индустрия независимо приходит к паттерну «плоскость сотрудничества + агент-оркестратор».
7. Общая память против передачи сообщений: даже с общей памятью есть отдельный сбой — рассогласование агентов (inter-agent misalignment): параллельные кодеры конфликтуют при записи в общий репозиторий — «ломается сборка, и все заблокированы». Для веера MVP отсюда прямое требование — изоляция рабочих копий (отдельные ветки/контейнеры на вариант), а не только общая память на чтение.
8. Стопроцентная автономия — задокументированная ошибка: даже без денежного риска долгий прогон без промежуточных чекпоинтов даёт каскадные отказы (ошибка на шаге 2 рушит план к шагу 7). Нужны не только денежный стоп-кран, но и агентные чекпоинты внутри ночи — критик проверяет прогресс каждые N шагов и откатывает/паузит.

Реальные провалы: агент купил курс, слитый трейдинг

Две истории стоит держать как клинические случаи, подтверждающие твою красную линию «деньги — только с подтверждением». Первая: человек дал агенту доступ к портфелю с промптом «торгуй до миллиона, не ошибайся». Агент сканировал посты, чертил теханализ, торговал круглосуточно — и слил всё до нуля. Инфраструктура была технически впечатляющей; границы по капиталу не было. Вторая, полушуточная, но методологически ровно та, которой ты боишься: агент записался на платный «мастермайнд по личному бренду» за почти три тысячи долларов, посмотрев несколько мотивационных клипов (осторожно: суммы из соцсетей, первоисточник не подтверждён). Третья, про безопасность: руководитель дала агенту полный доступ к компьютеру, не зная про команду аварийного стопа. Урок не «как разрешить агенту действовать», а обязательный, проверенный на практике аварийный стоп (kill-switch).

Вывод по всем трём: денежный гейт должен быть встроен как код (hook), а не как обещание модели — хуки детерминированы и не могут галлюцинировать разрешение на трату. Это прямое лекарство от «монстра, кушающего 1000 долларов в минуту», и страх обоснован не только у соло-предпринимателя: на масштабе в это уже врезались целые корпорации (осторожно: конкретные цифры из соцсетей не подтверждены). Разница в том, что у тебя есть рычаг, которого нет у корпорации на тысячах инженеров: полный контроль над архитектурой с нуля.

Дорога: от полуручной фабрики к автономной системе

Внедрять надо не «всё сразу», а по фиксированной последовательности, расставленной по риску и ценности, а не по интересности. Сначала — дёшево и безопасно, потом — фундамент доверия, и только в самом конце — самое рискованное и дорогое.

Девять этапов по порядку:

1. Гигиена и безопасность. Освободить диск (переполненный диск — тихий убийца автономии) и закрыть лишние выходы наружу. Дёшево, безопасно, чинится первым.
2. Замкнуть обучение. Структурированный лог решений в память → метрики начинают течь обратно автоматически. Без замкнутой обратной связи система не учится, а снимать гейты вслепую нельзя.
3. Изолированный критик на существующем одобрении. Поставить агент-критика в режим «советует, не решает» и калибровать его неделями против собственных решений — пока не совпадает уверенно. Только потом снимать гейт.
4. Очередь-брокер между стадиями. Чтобы упавший шаг возобновлялся, а не начинал всё с нуля (твой принцип «resume, не restart»).
5. Включить дирижёра с матрицей гейтов + денежный гейт как hook. Матрица риска (чтение / запись / удаление / трата) заменяет единый бинарный «одобрить».
6. Мобильная панель + двусторонний Telegram. Плоскость сотрудничества и мобильный контроль — чтобы бросать задачи и получать утренний дайджест.
7. Отдельная песочница ночного билдера (направление 2), изолированная от боевого завода.
8. Агент-разведчик возможностей (opportunity scout) — расширение уже работающего паттерна периодического скана + дайджеста, только источники другие: где бизнесы теряют деньги.
9. Веер MVP на изолированных рабочих копиях (направление 3) — самое рискованное и дорогое, поэтому в самом конце.

Первый кандидат «включить агентность» — одна вертикаль, один канал (сначала критик-советник → потом дирижёр в режиме чтения → потом полный цикл до одобрения), а не весь завод разом.

Первая неделя по дням:

• Понедельник. Гигиена и безопасность (этап 1): освободить место, закрыть лишние выходы. Ничего не ломает, снимает главный тихий риск.
• Вторник. Начать замыкать обучение (этап 2): включить структурированную запись эпизодов (тема → метрики) в память хотя бы на одном канале.
• Среда-четверг. Поставить изолированного критика на финальном гейте в режиме «советует» (этап 3) и запустить калибровку — каждый день сравниваешь его вердикт со своим, копишь статистику доверия.
• Пятница. Аудит токеномики: развесить лестницу моделей по стадиям, вынести где можно LLM в скрипт (mechanical-first), поставить стоп-краны как хуки, а не как пункт промпта.
• Выходные. Выбрать одну вертикаль для первого включения агентности в режиме чтения и настроить утренний дайджест в Telegram — чтобы даже без гейтов у тебя был человеческий чекпоинт раз в сутки.

Что делать в понедельник утром

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