Надёжность, цена, безопасность: guardrails, human-in-the-loop и его снятие, контроль стоимости, sandbox, evals, самообучение

Аналитика для Лучиана. Заточено под его цель: снять человеческие гейты EDIT_PENDING/APPROVAL_PENDING на заводе фейслес-видео и дать системе полную ночную автономию — кроме траты денег без подтверждения. Это единственная красная линия. Всё остальное (публикация, правки, эксперименты) агент должен уметь решать сам, безопасно.

0. Почему это отдельная, а не техническая тема

Все остальные разделы курса отвечают на вопрос «как построить». Этот раздел отвечает на вопрос «как не проснуться утром к сожжённому бюджету, зафлаженному YouTube-каналу или горе битых проектов». У Лучиана это не абстрактный риск: завод уже показал реальные примеры саморазрушения без присмотра — зомби-задачи FastGen, которые «пиннят» слоты аккаунта и жгут деньги впустую (06-errors-and-gotchas.md, пункт 3); MOSS-TTS endpoint с workersMin=1, который вхолостую жрал ~$38/сутки GPU, пока не поставили guard-скрипт; облачный VoxCPM, который на длинных текстах входит в runaway без EOS и варится 30+ минут GPU. Это не гипотетические «риски ИИ» из статьи — это то, что уже произошло на его собственном сервере. Значит, тема — не теория, а прямое продолжение его пяти законов, только формализованных как архитектура, а не как «Лучиан помнит и одёргивает руками».

Медицинская аналогия для интуиции: guardrails — это иммунная система завода. Не один барьер («антивирус»), а многоуровневая защита: кожа (input-фильтры) → слизистые (валидация на границах сервисов) → врождённый иммунитет (детерминированные проверки, работают мгновенно) → приобретённый иммунитет (evals и обучение на прошлых инцидентах, специфичны и совершенствуются). Human-in-the-loop сегодня — это как постоянный врач у кровати; цель — перевести его в «дежурного на два часа в день», к которому эскалируют только сложные случаи, а не в человека, без которого пациент не дышит.

1. Guardrails: не фильтр, а архитектура контроля доступа к действиям

Ключевая переформулировка из конспекта: «Guardrails — это не фильтры контента, а системная архитектура контроля, состоящая из слоёв, границ надёжности и ограничений выполнения» (Sendoa Moronta, источник reliability-cost-security.md). Для завода Лучиана это означает три точки контроля, которые уже частично существуют, но не формализованы:

Input guardrails — на входе в систему. У завода это: валидация промпта до отправки в FastGen (уже частично есть — QC-петли и safety-фильтры генераторов), защита от «отравленного» контента (например, если niche-finder притащит тему, которая триггерит dangerous content false-positive — сейчас решается ре-вордингом до 6 раз, что уже рабочий паттерн guardrail-с-retry).

Interaction guardrails — контроль на уровне действий, а не на уровне текста. Это САМАЯ важная категория для Лучиана, потому что именно она формализует его требование «полная автономия кроме денег». Модель из конспекта:

READ   → выполняется автоматически (чтение метрик, чтение статуса проекта, чтение памяти)
WRITE  → автоматическая валидация перед выполнением (генерация видео, правка скрипта, апдейт memory-bank)
DELETE → требует одобрения человека (удаление проекта, отмена генерации, отзыв токена)
ТРАТА  → отдельная, ЖЁСТКАЯ категория поверх этой триады — требует подтверждения ВСЕГДА

Это прямое обобщение уже существующего у него правила «дорогое не запускать самому (Veo, большие генерации, GPU) — спросить» (01-owner-and-rules.md, п. «Рабочие привычки»). Разница в том, что сейчас это неформальная инструкция агенту в промпте, а для ночной автономии это должно стать программным контролем на уровне API, а не договорённостью с LLM. LLM может забыть инструкцию под давлением контекста («context anxiety», см. §5) или её обойти под prompt injection. Технически: каждый эндпоинт завода, который тратит деньги (FastGen /generate, MOSS TTS-синтез, Veo/дорогие видео-модели, покупка API-кредитов), должен иметь программный budget-gate — не «агент решает спросить», а сервер физически отклоняет запрос, если превышен дневной/часовой лимит трат, и требует отдельного эндпоинта подтверждения (например, через Telegram-кнопку, привязанную к конкретному запросу с суммой).

Output guardrails — на выходе. Для видео-завода это validation схемы SEO-пакета (title/description/tags — корректный JSON, длины полей), фильтрация на явный слоп (thumbnail-studio уже делает это через Haiku vision QC и StyleBank — это ГОТОВЫЙ output guardrail, просто под другим именем), проверка на copyright/PII перед публикацией.

Вывод для Лучиана: три существующих гейта завода (EDIT_PENDING, APPROVAL_PENDING, ручной выбор темы на стадии ②) сегодня выполняют функцию WRITE-guardrail оптом — весь конвейер требует подтверждения человека, независимо от риска шага. Чтобы снять их и сохранить только денежный гейт, нужно разложить единый гейт на матрицу риска по каждому под-шагу, а не убрать гейт целиком. Ниже — конкретное предложение такой матрицы для его пайплайна.

Это прямо соответствует пункту профиля: «агент-критик сам решает о публикации (по чек-листу: хук, визуал, звук, факты) — человек смотрит только метрики». Технически критик — это отдельный evaluator-агент (см. §5), а не просто «включить автопубликацию».

2. Human-in-the-loop: снятие гейтов — это инженерная миграция, а не выключение рубильника

Конспект по HITL (reliability-cost-security.md) даёт формулу, которая прямо ложится на задачу Лучиана: «HITL масштабируется через автоматизацию: используйте AI для пре-скрининга, фокусируйте людей на сложных edge cases». Практический паттерн:

Agent → [Is this output acceptable?] → Human → [Yes/No + feedback] → Learning loop

Это Active Learning — самый эффективный для production подход (в отличие от дорогого supervised labeling или RLHF, которые Лучиану не нужны — у него нет ресурсов на fine-tuning). Практически это значит: не «убрать APPROVAL_PENDING», а превратить его в условный гейт: агент-критик сам ставит approved=true, если пройдены объективные пороги (evals, см. ниже), и эскалирует к Лучиану в Telegram только когда confidence ниже порога или обнаружена аномалия.

Экономика HITL по конспекту: cost per annotation $0.10–5, break-even — когда ошибка стоит дороже проверки. Для Лучиана это прямо считается: если забаненный видеоканал/страйк на YouTube стоит недели работы и потери монетизации, а 30 секунд его внимания на подтверждение в Telegram стоит условно $0 (но занимает его лимитированное время), порог эскалации нужно калибровать не по деньгам, а по риску необратимости — это совпадает с матрицей из §1.

Критическая ошибка, которую видят практики (case-studies-failures.md) — два крайних полюса автономности: 1. Полная зависимость от одобрения → бутылочное горлышко (10-20 задач/день максимум) — это буквально текущее состояние завода Лучиана: оркестратор выключен, конвейер стоит на EDIT_PENDING/APPROVAL_PENDING, и это ограничивает throughput его личным временем. 2. Полная автономия без предохранителей → McDonald's AI-бот отвечал сарказмом на жалобы клиентов и стал вирусным, компанию заставили отключить систему. Урок для Лучиана: даже когда «трать деньги — единственная красная линия», нужен отдельный репутационный circuit-breaker — если что-то публично пошло не так (шквал негативных комментариев, страйк платформы, аномальная метрика), система должна САМА приостановить публикацию и запросить человека, даже если формально это не «трата денег». Иначе одна ночь автономии может стоить канала.

Правильный «средний путь» — tiered autonomy, буквально по таблице из case-studies-failures.md:

Read-only        → 100% автономия
Create/Update     → 50%, approval от владельца
Delete            → 0%, только человек
Payment/Legal     → 0%, человек + доп. проверка

Это методологически ИДЕНТИЧНО матрице риска в §1 — два независимых источника (гайд по guardrails и полевой отчёт о провалах) сходятся на одной архитектуре. Это сильный сигнал, что это не мода, а системный принцип.

3. Sandbox: изоляция ночного строителя приложений

Второй приоритет Лучиана (после контент-фабрики) — «строитель приложений» с полной ночной автономией: план → код → критика → тест → визуальная проверка → доработка. Это САМАЯ рискованная часть системы с точки зрения sandbox, потому что агент буквально пишет и исполняет непроверенный код без присмотра всю ночь.

Из конспекта — три уровня изоляции с разным trade-off:

• Docker (уже используется на заводе для всех 16+ сервисов) — достаточен для доверенного, известного кода. Слабое место: контейнеры делят ядро хоста, kernel exploit компрометирует всё. Для ЕГО ситуации — 16 сервисов с общим Docker-хостом на VPS, это значит, что ночной «строитель приложений», если будет исполнять произвольный сгенерированный код в том же Docker-хосте, теоретически может задеть боевые сервисы завода.
• gVisor — user-space ядро, перехватывает syscalls. Оверхед 10-30% I/O, 50%+ на системные вызовы — заметно, но приемлемо для тестового кода.
• Firecracker microVM — рекомендуемый стандарт для production недоверенного кода: загрузка ~125ms, оверхед памяти <5MB, аппаратная изоляция через KVM. Это то, что используют E2B/Modal — облачные песочницы для агентного кода.

Практический вывод для Лучиана: ночной билдер приложений НЕ должен исполнять код на том же VPS, где крутится боевой завод. Варианты: (а) отдельная microVM-песочница (E2B/Modal, или Firecracker вручную) для генерации-и-теста, артефакт выгружается только после прохождения evals; (б) на его домашнем ПК с RTX 3090 — Docker/gVisor достаточно, поскольку это не публичный prod-сервер, но всё равно НЕ должен иметь доступ к секретам завода (YouTube OAuth токены, .env боевых сервисов). Правило «секреты не отдавать третьим сервисам без спроса» (01-owner-and-rules.md) нужно расширить: ночной билдер по умолчанию НЕ видит боевые credentials завода вообще, только явно прокинутые тестовые ключи.

Defense-in-depth из конспекта — 4 уровня, накладывающихся друг на друга, ни один не заменяет другой:

1. Guardrails (фильтр промптов/вызовов до выполнения)
2. Sandbox (изолированная VM)
3. Ограничение ресурсов (CPU/память/disk I/O лимиты)
4. Мониторинг (каждое действие логируется, может быть остановлено)

4. Evals: как критик-агент вообще может решать «публиковать или нет»

Это прямая техническая основа для пункта профиля «агент-критик сам решает о публикации по чек-листу». Без evals это решение — «vibes-based evaluation», прямо названная в конспекте типичной ошибкой (пункт 4.5.6).

Практическая рецептура из конспекта: 25-50 куратированных примеров, 2-3 ключевые метрики, baseline до изменений, интеграция в CI/CD. Для завода Лучиана это означает: завести датасет из 30-50 прошлых видео с известным исходом (метрики после публикации: retention, CTR, штрафы/страйки, комментарии) и разметить их вручную один раз — это тот самый Active Learning цикл, где Лучиан тратит время один раз на калибровку, а дальше evaluator-агент судит по этому образцу.

Offline evals = unit-тесты для контента: проверка ДО публикации по чек-листу (хук в первые 3 сек, синхронизация звука/видео, отсутствие явных фактических ошибок, отсутствие copyright-риска). Online evals = мониторинг ПОСЛЕ публикации (реальный retention, аномалии в комментариях) — это ровно то, что должно закрыть стадию ⑨ LEARNING, которая у него сейчас «холостая» (оркестратор выключен, метрики не текут автоматически). Пункт 06-errors-and-gotchas прямо говорит: система накопила инфраструктуру (memory-bank с тремя банками, петля обучения thumbnail-studio), но замкнутый цикл evals→learning не включён.

Ключевой урок из практики Anthropic (транскрипт про harness-инженерию для долгих агентов, 9d5bzxVsocw.txt) прямо предупреждает про главную ловушку self-evaluation: «если попросить агента оценить свою работу, он, скорее всего, её похвалит, даже если качество очевидно посредственно для человека-наблюдателя». Решение, к которому пришёл Anthropic — adversarial evaluation по аналогии с GAN: отдельный evaluator-агент с системным промптом, ЦЕЛИКОМ посвящённым скепсису, оценивает работу generator-агента и отправляет структурированную критику назад. Это НЕ то же самое, что просить ту же модель «а теперь покритикуй свою же работу» в одном контексте — разница именно в изоляции ролей.

Три условия, при которых evaluator-агент реально работает (из того же кейса Anthropic, после нескольких неудачных итераций — «out of the box Claude — плохой QA-агент»): 1. Сделать субъективное качество измеримым: не «хорош ли этот скрипт видео?», а «соответствует ли скрипт нашим правилам: хук ≤3 предложения, факт-чек по каждому утверждению, естественность озвучки». Явные, проверяемые критерии — это буквально чек-лист из профиля Лучиана (хук, визуал, звук, факты), уже интуитивно правильно сформулированный. 2. Взвесить критерии под слабые места модели — Anthropic обнаружили, что Opus силён в двух из четырёх критериев и слаб в других, и усилили вес слабых, чтобы не пропускать «AI slop». Для завода Лучиана это значит: если QC-петля thumbnail-studio видит, что визуальный QC силён, а факт-чек слаб — вес факт-чека в итоговом вердикте критика должен быть выше. 3. Дать evaluator'у инструменты взаимодействовать с артефактом, а не судить по описанию — у Anthropic это Playwright MCP (evaluator реально открывает страницу и кликает). У Лучиана это уже частично есть: Haiku vision QC реально «смотрит» на обложку, а не читает промпт. Это правильный паттерн, который стоит распространить на весь конвейер — критик должен реально просмотреть/прослушать финальное видео (или хотя бы ключевые кадры + аудио-транскрипт), а не судить по метаданным.

Метрики отказов tool calling из практики (case-studies-failures.md): 3-15% failure rate в production — это означает, что даже с evals часть решений будет ошибочной, и это нормально. Реалистичная планка — не 99.99% uptime (традиционный SLA), а 85-95% успеха на простых задачах с HITL-подстраховкой на edge cases.

5. Типичные ошибки — и где завод Лучиана уже наступил на эти грабли (или рискует наступить)

Loop of Death (Sattyam Jain, case-studies-failures.md): агент пишет код с ошибкой → среда выдаёт ошибку → «исправление» плодит новую ошибку → цикл повторяется, сжигая самые дорогие токены. Решение практиков: smart routing (дешёвая модель классифицирует сложность) + semantic caching (40% подзадач из кеша) + sandboxed execution с лимитом попыток (max 3) → результат 70% экономии, 99.9% надёжности. У завода это уже проявлялось: 06-errors-and-gotchas.md описывает ровно такой паттерн — «упавший прогон, суета загоняет проект в битое состояние»: повторные kill+relaunch+resume → 409 Conflict, стадия failed навсегда. Правило «чинить вперёд, не с нуля» и совет «не thrash'ить stop/resume» — это ЕГО собственная, полевым опытом найденная версия «max retry limit» из индустриальной практики. Для ночной автономии это нужно формализовать как жёсткий лимит: N автоматических retry на стадию, дальше — не бесконечный цикл, а эскалация или fallback.

Context anxiety (harness-транскрипт 9d5bzxVsocw): по мере заполнения контекстного окна модели не просто теряют связность — они меняют поведение: торопят финал, объявляют «готово», хотя не готово. Решение Anthropic — context reset между этапами (свежий контекст + чтение progress-файла + handoff), пока модель не станет достаточно мощной, чтобы полагаться на compaction (это случилось только на Opus 4.6). Прямая связь с токеномикой Лучиана: его собственное требование «контекстная изоляция: каждый субагент получает минимальный контекст, оркестратор передаёт выжимки, не сырьё» — это независимо выведенный тот же принцип. Для ночного билдера приложений (первый приоритет!) это значит: длинная сессия должна быть построена как серия коротких этапов с явным handoff через файлы (как уже устроено у него в state.json/config.json на уровне проектов генераторов), а не как один непрерывный диалог на 6+ часов.

Polling tax: 95% опросов статуса возвращают «без изменений», пропорционально растут затраты и риск rate-limiting. У Лучиана это прямая параллель с граблей «FastGen таймаут поллинга (10 мин) → cancel() обязателен, брошенный поллинг без cancel = двойная оплата». Решение из индустрии — event-driven (webhooks) вместо polling; на заводе это уже частично реализовано (resource-governor как брокер), но стоит проверить каждый долгий async-вызов (голос, видео-генерация) на предмет честного webhook vs слепого polling.

Brittle connectors / Dumb RAG: агент не различает 404 от 500, не проверяет статусы ответов API. Пример из практики: стартап потратил €5000 впустую, потому что агент не проверял статусы почтового сервиса. У Лучиана прямая параллель — грабля «IG Stories не выходили: proxyExecute не имеет .successful, успех = вернулся id» — это классическая ошибка недоверия к структуре ответа API, уже найденная и исправленная полевым методом.

100% автономность — фундаментальная ошибка, если понимать её буквально (Codemanship, case-studies-failures.md §8): out-of-distribution problem («модель не может надёжно понять, что задача вышла за рамки её знаний») — это, по формулировке источника, «unfixable problem» для текущего поколения трансформеров. Практический вывод НЕ «поэтому автономия невозможна», а «держите firehose короткими управляемыми очередями» — то есть автономия достигается не отменой контроля, а декомпозицией на маленькие проверяемые шаги с чек-поинтами между ними, что опять сходится с матрицей риска §1.

6. Контроль стоимости: подписка vs API vs агрегаторы — применительно к архитектуре Лучиана

Завод уже принял решение «мозг = подписка Claude (claude -p, мульти-аккаунт failover) — НЕ API-ключи», сняв AnyModel/relay слой 2026-07-10. Экономика подтверждает правильность этого выбора для ЕГО объёма: подписка выгодна, когда объём стабильно высокий и предсказуемый (ChatGPT Pro/Claude Pro окупаются при 10M+ токенов/месяц; ниже этого порога прямой API в разы дешевле). Учитывая, что завод генерирует десятки видео с многоэтапными LLM-вызовами на скрипт/визуал-режиссуру/QC ежедневно, подписочная модель с мульти-аккаунт failover — рационально дешевле построчного API при таком постоянном высоком трафике.

При этом для отдельных лёгких/механических задач (Haiku QC, классификация, сбор данных) роль подписки и роль pay-per-use API могут расходиться — лестница моделей, которую Лучиан уже практикует (Fable/opus/sonnet/haiku), реализует именно это: дорогая «подписочная» мощность бережётся для архитектурных решений, а массовая механика уходит на дешёвые токены.

Про агрегаторы (OpenRouter и подобные): наценка ~5.5%, но unified spending control и Zero Data Retention. Правило окупаемости из конспекта — окупается при 3+ провайдеров одновременно. У Лучиана мозг — только Claude (подписка), генераторы картинок/видео — отдельные специализированные провайдеры (FastGen, Veo, MOSS/RunPod), не через единый LLM-агрегатор. Значит, классический «LLM gateway» ему сейчас не нужен — но идея unified spending dashboard ему НУЖНА в другой форме: единая веб-панель $/задача, $/день, алерты — это именно то, что он уже указал как требование к системе, только реализовывать нужно кастомным cost-tracking слоем поверх resource-governor, а не через готовый агрегатор типа OpenRouter (тот решает другую задачу — маршрутизацию между LLM-провайдерами).

Практическая находка завода, прямо иллюстрирующая «cost control требует архитектуры, а не просто дешёвой модели»: MOSS-TTS endpoint с workersMin=1 жёг ~$38/сутки вхолостую, пока не поставили moss_worker_guard.py (cron), реконсилящий 0↔1 воркер по факту очереди. Это ГОТОВЫЙ пример архитектурного cost-guardrail — не «модель дешевле», а «инфраструктура не работает вхолостую». Этот паттерн (сторож-скрипт, следящий за простаивающими платными ресурсами) стоит тиражировать на все GPU/платные компоненты завода, а не изобретать заново на каждом сервисе.

Формализация денежного гейта (главное требование заказчика) технически должна выглядеть так: 1. Каждый платный вызов (FastGen, MOSS synth, Veo, аренда GPU, покупка кредитов) проходит через единую точку — уже есть resource-governor.slot, это ПРАВИЛЬНОЕ место для встраивания budget-gate. 2. Budget-gate имеет три уровня: (а) в рамках дневного лимита — авто; (б) выше лимита, но ниже разового потолка «дорогой операции» (как Veo) — авто с логированием и уведомлением постфактум; (в) превышает разовый потолок ИЛИ это явно помеченная «дорогая» категория (Veo, GPU-аренда, покупка API-кредитов) — блокирующий запрос подтверждения в Telegram, пайплайн ставится на паузу до ответа. 3. Ежедневный автоматический отчёт о тратах (burn rate, cost per video/per channel, аномалии) — прямое продолжение уже сформулированного требования к веб-панели.

7. Безопасность инфраструктуры: урок из провалов OpenClaw для Лучиана

Хотя мозг завода — Claude Code/API, а не OpenClaw, стоит учесть чужие уязвимости как чек-лист, потому что архитектурно завод Лучиана (докер-сервисы, публичные порты через Caddy, SSO, доступ снаружи) относится к тому же классу рисков, что и любой self-hosted агентный гейтвей. Конкретные факты из полевых данных: CVE-2026-25253 (CVSS 8.8) в OpenClaw — RCE через WebSocket-инъекцию, эксплуатируемая из-за того, что 30 000+ инстансов были публично доступны на 0.0.0.0:18789 без firewall; 15% из 5700+ community-скиллов на ClawHub содержали malware, 280+ подтверждённо утекали credentials.

Прямые параллели с текущей практикой завода, которые стоит закрепить как правило, а не как случайность: прямые порты сервисов у Лучиана УЖЕ ограничены 127.0.0.1 (только Caddy+SSO наружу) — это ровно то, чего не хватало уязвимым инстансам OpenClaw. Это нужно сохранить как жёсткий инвариант при добавлении новых сервисов ночному билдеру приложений — никакой новый сервис не должен биндиться на 0.0.0.0 без явного прохождения через Caddy+SSO слой. Второй урок — plaintext credential storage целевая для commodity infostealers: секреты YouTube OAuth и .env должны оставаться вне зоны видимости ночного автономного билдера кода (см. §3), и любой skill/плагин, скачанный «из интернета» для использования системой, должен проходить через явную ревизию (аналог 15% malicious skills в ClawHub — заимствованный код нельзя ставить в прод без чтения).

7.5. Observability и самообучение: как память завода становится «приобретённым иммунитетом»

Конспект разделяет мониторинг и observability принципиально: мониторинг отвечает на вопрос «работает ли система» (латентность, ошибки — известные метрики), observability — на вопрос «почему она себя так повела» (скрытые причины поведения). Для агентных систем это разница критична, потому что классический мониторинг покажет, что видео сгенерировалось за 40 минут вместо 10, но не покажет, что причина — зомби-задача, пиннящая слот аккаунта. Из практики выведены пять целей observability: надёжность (retry с exponential backoff, fallback на другого провайдера), качество (factuality/relevance/grounding — можно ли подтвердить факт документом), безопасность (детекция инъекций, утечек PII, audit log), стоимость (аномалии в burn rate) и governance (полная трассируемость запроса, версионирование промптов).

Для Лучиана это прямо ложится на уже существующую инфраструктуру memory-bank с тремя банками (global / per-channel / per-generator) — но сейчас она используется как пассивное хранилище фактов, а не как активный трейсер решений. Чтобы стадия ⑨ LEARNING заработала не «холостую», нужно логировать не только финальные метрики видео (retention, CTR), но и цепочку решений внутри пайплайна: какая тема была выбрана и почему, какой QC-вердикт получен на каждой стадии, сколько ре-вордов потребовалось на "dangerous content" false-positive, сколько стоил прогон в токенах и деньгах. Именно эта трассировка превращает memory-bank из «дневника фактов» в «иммунную память» — систему, которая в следующий раз распознаёт паттерн проблемы быстрее, потому что видела его раньше в структурированном виде, а не в виде разрозненных инцидентов, которые помнит только Лучиан.

Формат записи из практики (case-studies-failures.md) — хороший ориентир для схемы лога:

{
  "timestamp": "2026-07-12T03:14:00Z",
  "stage": "stage_visual_rules",
  "channel": "lightning",
  "action": "call_tool",
  "tool": "nano_banana_pro",
  "input": {"aspect_ratio": "9:16", "retry_count": 2},
  "latency_ms": 4200,
  "cost_usd": 0.11,
  "success": true,
  "qc_verdict": "pass",
  "decision_reasoning": "storyboard QC прошёл со второй попытки после реворда промпта"
}

Двухэтапное самообучение, которое сам Лучиан наметил в профиле («этап 1 — память уроков, этап 2 — путь к самоулучшению, система дописывает своих агентов»), напрямую зависит от качества этого лога: без структурированной трассировки решений этап 2 невозможен, потому что агенту, который пишет нового субагента, нужно на чём-то основывать вывод «этот паттерн уже 5 раз проваливался — вот почему».

7.6. Метрики отказов, на которые стоит ориентироваться при калибровке ожиданий

Прежде чем снимать гейты, полезно иметь реалистичную числовую рамку, а не ожидать «идеальной» автономии с первой ночи:

Эти цифры — не повод отказаться от автономии, а повод заранее встроить в архитектуру то, что уже частично есть у Лучиана интуитивно: retry-лимиты, resume-вместо-recreate, mechanical-first вместо LLM-аудита, лестницу моделей. Разница между «система, которая падает и разваливается» и «система, которая падает и сама чинится» — это не отсутствие сбоев (они неизбежны при такой архитектуре), а наличие чек-поинтов и наблюдаемости вокруг них.

8. Итоговые практические выводы для дорожной карты Лучиана

1. Не убирать гейты — разложить их на матрицу риска. Единый APPROVAL_PENDING заменить на: авто (READ/низкий риск) → авто-с-логом (WRITE в рамках бюджета) → блок-подтверждение (Delete/Payment/Publish-с-риском). Технически это программный слой поверх resource-governor, не просто промпт-инструкция агенту.
2. Формализовать денежный гейт как код, не как договорённость с LLM. Budget-gate на каждом платном вызове, с тремя уровнями (авто/авто+уведомление/блок-подтверждение), интегрированный в существующий resource-governor.slot.
3. Включить стадию ⑨ LEARNING через evaluator-агент, построенный на явных проверяемых критериях (не «хорошо ли видео», а конкретный чек-лист хук/визуал/звук/факты), с весами под известные слабые места модели, и с реальным доступом evaluator'а к финальному артефакту (просмотр видео/прослушка), а не к метаданным. Это прямая техническая реализация «агент-критик сам решает о публикации».
4. Изолировать ночного билдера приложений от боевого VPS. Отдельная песочница (microVM/E2B или хотя бы отдельный Docker-хост без боевых credentials), лимиты ресурсов, авто-стоп при аномалии — до того, как ему давать полную ночную автономию писать и исполнять код.
5. Ввести жёсткий retry-лимит и circuit-breaker на уровне всего конвейера, а не полагаться на «агент разберётся» — это прямое обобщение уже найденных им граблей (409-циклы, зомби-задачи, MOSS вхолостую).
6. Сохранить и расширить принцип «cost control = архитектура, не модель» — тиражировать паттерн сторожевых скриптов (как moss_worker_guard.py) на все платные простаивающие ресурсы, а не полагаться на разовые фиксы.
7. Реалистичная планка надёжности: не 99.99%, а 85-95% успеха на простых операциях с эскалацией edge cases человеку; ROI ночной автономии проявится не мгновенно, а за несколько недель калибровки evals — это стоит явно закладывать в ожидания, а не считать провалом первую неделю.

9. Что конкретно сделать в первую неделю (мостик к roadmap)

Раздел не заменяет отдельный итоговый roadmap курса, но фиксирует минимальный набор шагов, которые реализуют принципы этого раздела на существующем стеке завода, без переписывания архитектуры:

1. Включить оркестратор с новой матрицей гейтов, а не со старой бинарной моделью «всё стоит, пока не нажал». Технически — правка channel-hq/core/orchestrator.mjs: расщепить единый APPROVAL_PENDING на условный переход, где критерий перехода — вердикт evaluator-агента, а не присутствие человека.
2. Обернуть resource-governor.slot budget-gate'ом — дневной/часовой лимит трат по каналам и по типу операции (генерация картинки дешевле, чем Veo-видео), с блокирующим Telegram-подтверждением только для операций сверх разового потолка.
3. Собрать первый датасет для evaluator-агента — 30-50 уже опубликованных видео с известным исходом (retention, страйки, жалобы), разметить один раз вручную по чек-листу хук/визуал/звук/факты. Это самая трудоёмкая, но одноразовая инвестиция, дальше evaluator обучается на этом бенчмарке.
4. Изолировать будущего ночного билдера приложений от секретов завода ещё до того, как он появится — завести отдельный Docker-контекст/microVM без доступа к .env боевых сервисов и OAuth-токенам, до первого автономного ночного прогона кода.
5. Включить стадию ⑨ через структурированный лог решений (см. §7.5) — минимум JSON-лог каждой стадии в memory-bank, прежде чем пытаться строить самообучение поверх него.
6. Формализовать retry-лимиты явным конфигом, а не полагаться на память Лучиана «не thrash'ить» — max попыток на стадию, таймаут-каскад, автоматический cancel зависших polling-задач (уже частично есть для FastGen, стоит распространить на MOSS и остальные долгие вызовы).

Источники (из материалов ресёрча)

• /tmp/mas-research/web/reliability-cost-security.md — конспект по guardrails, HITL, cost control, evals, sandbox
• /home/claude/mas-research/web/case-studies-failures.md — полевые отчёты о провалах production-агентов (Loop of Death, tiered autonomy, метрики отказов)
• /home/claude/mas-research/transcripts/9d5bzxVsocw.txt — разбор блога Anthropic про harness для долгоживущих агентов: context anxiety, adversarial evaluation
• /home/claude/mas-research/web/openclaw-hermes.md — уязвимости и security-риски self-hosted агентных систем
• /home/claude/hermes-handoff/_HERMES_HANDOFF/01-owner-and-rules.md, 02-factory-overview.md, 06-errors-and-gotchas.md — фактическое состояние и грабли завода Лучиана