Loop Engineering · 2026

Как собрать контур проверки для AI-агентов: автор, критик и HITL

Разделите роли автора и критика, добавьте детерминированные гейты и HITL — чтобы агенты не публиковали мусор сами себе на зачёт

Контур в Telegram автор → критик → HITL

Коротко. Контур проверки — это не «ещё один промпт улучши». Это раздельные роли: кто делает, кто ищет ошибки, кто разрешает выпуск. Если один и тот же агент пишет и ставит себе оценку, качество почти всегда завышено.

Для контент-завода и автоматизации контента это прямой риск репутации. Ошибка в коде можно откатить. Ошибочный пост в Telegram или на сайте уже ушёл к аудитории. Ниже — как собрать рабочий контур «агент-автор → агент-критик → HITL» с детерминированными гейтами и stop/go до публикации.

Почему агент, который сам себе ставит зачёт, сливает качество

ИИ-агенты умеют писать посты, собирать черновики и даже «проверять» свою работу. Проблема в другом: если один и тот же агент и пишет, и ставит себе оценку, качество почти всегда завышено. Текст выглядит уверенно. Факты — сомнительные. Обещания бренда — слишком смелые. А в логе стоит зелёная галочка «готово».

Для контент-завода и автоматизации контента это прямой риск репутации. Ошибка в коде можно откатить. Ошибочный пост в Telegram или на сайте уже ушёл к аудитории.

Коротко. Контур проверки — это не «ещё один промпт улучши». Это раздельные роли: кто делает, кто ищет ошибки, кто разрешает выпуск.

Где «один промпт на всё» ломает контент и репутацию

Типичный сценарий новичка выглядит так: один чат, один длинный промпт, команда «напиши и проверь сам». Агент выдаёт черновик, сам же пишет: «текст готов, фактов достаточно, тон в норме». Вы публикуете. Через час находите устаревшую цифру, чужое обещание или слабый SEO-заголовок.

Почему так происходит:

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

Инженерный паттерн evaluator–optimizer давно описан у Anthropic: один вызов генерирует, второй оценивает и даёт обратную связь. Он работает, когда критерии оценки ясные и итерации реально улучшают результат. В контенте критерии тоже можно сделать ясными — если разделить роли и артефакты.

Маркер: простыми словами. Evaluator–optimizer — схема «сделал → оценил → улучшил». Первый агент пишет. Второй только оценивает по правилам и говорит: принять, доработать или отклонить. Оценщик не должен «дописывать красиво вместо автора», пока вы сами так не решили.

Self-grade vs отдельный критик — в чём конфликт интересов

Self-grade — это когда модель оценивает свой же текст в том же диалоге. Исследования 2026 года по self-attribution bias показывают: LLM чаще считает свои действия более корректными и менее рискованными, чем идентичный контент без «это я написал». На практике это звучит так: «я только что сочинил — значит, я прав».

Маркер: простыми словами. Self-grade — «сам написал, сам поставил пятёрку». Self-attribution bias — склонность модели быть добрее к своему результату, чем к чужому такому же.

Правило Loop Engineering формулируется жёстко: агент, который сделал вещь, не должен быть единственным, кто её оценивает. Для контента это значит: автор и критик — разные инструкции, часто разный контекст, иногда даже разная модель. Критик не видит внутренние рассуждения автора «почему я так решил» — только готовый артефакт и критерии приёмки.

Автор

Делает артефакт по брифу. Не ставит PASS. Не публикует.

Критик

Ищет дыры по чек-листу. Не «улучшает красиво» вместо автора.

Человек

Жмёт approve до публикации. Ловит бренд и юридику.

Контур проверки простыми словами: автор → критик → человек

Минимальный рабочий контур для маркетингового или контентного пайплайна:

Агент-автор получает бриф и делает черновик.
Детерминированные гейты проверяют формат без «мнения» модели.
Агент-критик ищет смысловые дыры, тон, обещания, слабую логику.
Человек утверждает выпуск (HITL) — или возвращает на доработку.
Только после approve идёт публикация.

Это и есть мультиагентная система в прикладном смысле: не «много красивых названий ролей», а оркестрация агентов с понятным handoff и stop-правилами.

Маркер: простыми словами. Harness (обвязка) — всё вокруг модели: промпты, роли, проверки, лимиты, логи, инструменты. На одной и той же модели разброс качества из-за обвязки может быть огромным. Поэтому «поменять модель» часто слабее, чем «собрать нормальный контур проверки».

Что такое HITL без англицизмов

HITL (human in the loop) — это человек в контуре. Не «почитал пост после публикации», а точка утверждения до необратимого шага.

В разработке AvitoTech разделяют два слоя:

HITL — человек ревьюит требования, тесты, результат;
Agent-in-the-loop — агент проверяет другого агента с другим промптом.

Для контент-завода оба слоя нужны. Агент-критик ловит черновую ошибку быстро и дёшево. Человек ловит то, что нельзя отдать модели: бренд, юридические риски, «можно ли это обещать клиенту».

Маркер: простыми словами. HITL — «человек нажимает „можно выпускать“». Agent-in-the-loop — «второй агент проверяет первого», но финальный выпуск всё равно за человеком на рискованных шагах.

Какие задачи вообще имеют право на автозапуск

Loop имеет смысл, только если выполняются условия разом:

задача повторяется (посты, карточки, черновики лонгридов по шаблону);
есть автоматическая проверка, которая умеет сказать «нет»;
бюджет токенов выдерживает 2–5 итераций;
у агента есть нужные инструменты (доступ к брифу, чек-листу, CMS/боту approve).

Не отдавайте в автозапуск без HITL: цены, гарантии, юридические формулировки, ответы клиентам от имени компании, публикацию на главный канал без approve.

Контур проверки · не hero

Артефакт идёт через гейты: автор → критик → человек → публикация

Сцена справа — мостик мониторинга: черновик не «сам себе ставит зачёт», а проходит станции с stop/go. Один FAIL — возврат автору, не тихий выпуск.

Автор отдаёт артефакт, а не оценку качества.
Детерминированные гейты ловят формат до мнения модели.
Критик + HITL — раздельные роли; публикация только после approve.

Дальше разберём, почему эти роли нельзя склеивать в один system prompt.

Цикл ~48 с · FAIL → возврат · GO → publish

Роли, которые нельзя склеивать в один system prompt

Самая частая ошибка при попытке «как создать ИИ агента» для контента — склеить всё в один system prompt: «ты автор и редактор и SEO-специалист, будь строгим к себе». Это красиво на бумаге и бесполезно в проде.

Агент-автор: бриф, черновик, артефакт на выход

Автор отвечает только за производство. На входе — бриф с критериями приёмки. На выходе — один артефакт, например draft.md.

В брифе зафиксируйте:

цель текста и аудиторию;
обязательные факты и запретные обещания;
структуру (H2/H3, FAQ — да/нет);
тон и длину;
что считать «готово к проверке» (не «готово к публикации»).

Автор не выставляет себе PASS. Автор не публикует. Автор максимум помечает статус: draft_ready.

Агент-критик: отдельные инструкции и запрет «подправить красиво»

Критик получает:

бриф и критерии приёмки;
черновик автора;
чек-лист рисков;
отдельный system prompt.

Запретите критику переписывать текст «чтобы стало лучше». Его работа — найти, что неправильно, и вернуть вердикт: PASS / REVISE / FAIL плюс список замечаний. Если критик начинает сам «улучшать», вы снова получите self-grade под маской.

Практичный промпт-каркас для критика:

найди фактические дыры и неподтверждённые цифры;
найди обещания без основания;
проверь тон бренда и кликбейт;
проверь, закрыт ли бриф;
не предлагай новый текст целиком — только замечания и severity.

Человек-утверждает: что смотрит руками, а что нет

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

можно ли выпускать от имени бренда;
нет ли юридических/репутационных мин;
соответствует ли оффер реальности;
не сломан ли смысл после правок цикла.

Орфографию, длину title, наличие H1, schema FAQ — это работа детерминированных гейтов, не человека.

Детерминированные гейты против LLM-ревью — где что ловит ошибки

Два контура проверки закрывают разные классы ошибок. Если оставить только LLM-критика, он будет «мягким». Если оставить только правила — пропустите смысловой бред в идеальном формате.

Маркер: простыми словами. Детерминированный гейт — проверка по жёсткому правилу: да/нет без «ну вроде нормально». Пример: «в title больше 70 символов — стоп», «нет H2 — стоп», «есть фраза из чёрного списка — стоп».

Чек-листы, schema, линтеры, smoke-тесты

Для контент-пайплайна из России удобный набор гейтов:

Гейт	Что ловит	Пример правила
Длина и поля	SEO-мета	title 50–65, description 120–160
Структура	читаемость / GEO	есть H1, ≥3 H2, FAQ-блок
Запреты	репутация	чёрный список фраз, «гарантия 100%»
Ссылки и alt	доступность	у img есть alt; внешние ссылки ≤5
Schema/FAQ	формат	FAQ = вопрос→ответ, без пустых пунктов
Smoke	публикация	страница открывается, нет битого HTML

Эти проверки можно собрать в Make, n8n, скрипте в Cursor или даже в таблице + боте. Главное — чтобы гейт умел вернуть FAIL без участия модели.

Когда критик на модели полезен, а когда только шумит

LLM-критик полезен, если:

есть ясные критерии (как в evaluator–optimizer);
замечания можно проверить человеком за 2–3 минуты;
цикл revise реально улучшает текст.

LLM-критик шумит, если:

критерии размыты («сделай экспертнее»);
критик видит цепочку рассуждений автора и «поддакивает»;
нет лимита итераций — агенты вежливо спорят до пустого бюджета.

Handoff между агентами: что передавать, чтобы петля не разъезжалась

Без протокола передачи мультиагентные системы превращаются в кашу из чатов. Handoff — это не «переслал сообщение», а пакет артефактов со статусом.

Маркер: простыми словами. Handoff — передача эстафеты: файл/пакет + статус + кто отвечает дальше. Как в офисе: Коля отдал ядро, Артём — факты, Женя — текст. Не «всё в одном чате на 80 экранов».

Минимальный пакет артефактов (бриф, черновик, отчёт критика)

Минимум для одной контент-задачи:

brief.md — цель, аудитория, факты, запреты, критерии приёмки;
draft.md — черновик автора;
gates.json — результаты детерминированных проверок;
review.md — вердикт критика и список замечаний;
state.md — статус: draft / revise / awaiting_hitl / approved / stopped.

Автор не переписывает review.md. Критик не правит brief.md без эскалации человеку. Человек меняет только решение на HITL и, при необходимости, бриф.

Логи и статусы: принято / вернуть / стоп

В логе на каждый прогон фиксируйте:

номер итерации;
кто правил (author / critic / human);
вердикт и причину;
сколько токенов/минут ушло;
почему сработал stop.

Без лога вы не поймёте, почему контур «вдруг» стал дорогим или почему один и тот же баг проходит три раза.

HITL-гейт до публикации: критерии stop и go

HITL стоит до публикации, а не «для галочки после автопостинга». Иначе это не контроль, а дневник инцидентов.

Красные флаги, после которых публикация запрещена

Ставьте STOP и эскалируйте человеку немедленно, если:

критик вернул FAIL по фактам или юридике;
детерминированный гейт не пройден;
в тексте есть цифры/обещания вне брифа;
превышен лимит циклов без PASS;
агент пометил «готово», но пакет артефактов неполный.

Зелёный коридор: когда человек только подтверждает

GO для быстрого approve, если:

гейты зелёные;
критик дал PASS или мелкий REVISE, уже закрытый автором;
нет новых обещаний и цен;
шаблон задачи уже обкатан на 10+ похожих постах.

Даже в зелёном коридоре человек нажимает approve. Разница только во времени ревью: 30–60 секунд вместо 10 минут.

STOP

FAIL по фактам, красный гейт, неполный пакет — публикация закрыта.

REVISE

Автор правит только по списку замечаний, без нового текста «с нуля».

GO

Гейты зелёные, критик PASS — человек подтверждает за минуту.

Лимиты циклов и токенов — как не дать контуру крутиться вечно

Без stop rule контур легко сжигает бюджет в разы сильнее ожидания. В материалах Loop Engineering для бесконтрольных петлей приводят порядок в 5–10 раз больше токенов, чем планировали. Для малого бизнеса в РФ это не «абстрактная инженерия», а прямые деньги на API.

Маркер: простыми словами. Stop rule — заранее записанный стоп: «максимум 3 круга автор↔критик, иначе к человеку» или «если токены > X — стоп». Без этого агенты могут вежливо спорить всю ночь.

Максимум итераций автор↔критик

Практичный старт для контента:

max_iterations = 3 для короткого поста;
max_iterations = 5 для лонгрида;
после лимита — только HITL или STOPPED, без «ещё разок».

Каждая итерация должна менять артефакт по конкретным замечаниям, а не генерировать новый текст с нуля «на всякий случай».

Эскалация человеку при тупике

Тупик — это когда:

одни и те же замечания повторяются два цикла подряд;
автор «исправляет», но гейты снова красные;
критик и автор спорят о вкусе без критерия в брифе.

Тогда статус needs_human, в state.md — одна фраза причины. Человек либо правит бриф, либо правит черновик руками, либо убивает задачу.

Мини-схема под контент-завод: от брифа до публикации

Ниже — рабочая цепочка, которую можно повторить без «магического» стека. Это и есть практический ответ на запрос автоматизации контента через агентов.

Бриф → черновик → фактчек → SEO/GEO-чек → HITL → публикация

Шаг 1. Бриф

Создайте файл brief.md. Заполните: тема, аудитория, 5 обязательных фактов, 5 запретов, желаемые H2, CTA. Признак успеха: любой новый человек понимает задачу за 2 минуты без созвона.

Шаг 2. Автор

Отдельным чатом/агентом сгенерируйте draft.md строго по брифу. Признак успеха: в черновике есть все обязательные факты и нет запретных фраз из брифа.

Шаг 3. Гейты

Прогоните чек-лист: длина meta, структура H2, FAQ, alt, чёрный список. Запишите результат в gates.json. Признак успеха: все пункты pass или явный список fail без «ну почти».

Шаг 4. Критик

Новым контекстом (без истории автора) запустите агента-критика. Получите review.md со статусом PASS/REVISE/FAIL. Признак успеха: нумерованные замечания с severity; критик не прислал «переписанный пост целиком».

Шаг 5. Revise

Если REVISE — автор правит только по списку, критик перепроверяет. Не больше 3 циклов для поста. Признак успеха: замечания закрываются, а не размножаются.

Шаг 6. HITL

Человек в Telegram/CMS смотрит пакет и жмёт approve / reject. Признак успеха: публикация технически невозможна без статуса approved.

Шаг 7. Публикация

Выкладка + запись в state.md: кто утвердил, сколько циклов, что было красным. Признак успеха: через неделю вы можете объяснить, почему этот текст вышел.

Типичные ошибки новичка на этой схеме:

Автор и критик в одном чате — критик «помнит», как автор оправдывался. Решение: новый контекст, только артефакты.
HITL после автопубликации — уже поздно. Решение: approve-кнопка блокирует publish.
Нет лимита циклов — бюджет тает, текст плывёт. Решение: max_iterations в state.md до первого запуска.

Где встроить MCP и инструменты без смены ролей

MCP-сервер и инструменты — это руки агента, не новая роль. Автор может читать бриф из файла, критик — гонять линтер, человек — получать карточку approve в Telegram. Роли при этом не склеиваются.

Если вы только начинаете вайбкодинг и автоматизацию, не обязательно сразу тянуть LangGraph. Для первой рабочей петли хватит папки с артефактами + двух промптов + чек-листа + ручного approve. LangGraph и CrewAI имеют смысл, когда задач много и нужны interrupt/checkpointer из коробки — но архитектура ролей та же.

Маркер: простыми словами. MCP — способ дать агенту безопасный доступ к инструментам (файлы, CMS, Wordstat) по понятному протоколу. Это не замена критика и не замена HITL.

Типичные ошибки контура и как их поймать до продакшена

Автор и критик делят один контекст

Симптом: критик пишет «в целом согласен с автором».
Проверка: откройте историю чата — если видна цепочка рассуждений автора, контексты склеены.
Фикс: новый диалог, на вход только brief + draft + чек-лист.

Нет лимита циклов и нет логов handoff

Симптом: «агенты всю ночь дописывали», счёт за API неприятный, версия текста неизвестна.
Фикс: max_iterations, state.md, запрет запуска без статуса.

HITL стоит «для галочки» после автопубликации

Симптом: правки приходят комментариями под уже вышедшим постом.
Фикс: технический блок публикации до approved. Если используете Make/n8n из РФ — сделайте ветку «ждём emoji/кнопку в Telegram», и только потом модуль publish.

Отдельно ловите «Ralph Wiggum loop»: агент рано орёт «готово», хотя гейты красные. Лечится только шлюзом, который умеет сказать нет.

FAQ: частые вопросы по контуру проверки агентов

Чем HITL отличается от обычного редактора

Обычный редактор может править текст когда угодно. HITL — это встроенный гейт процесса: без статуса approve следующий шаг (публикация) не стартует. Редактор — роль человека. HITL — место этой роли в контуре.

Нужны ли LangGraph или CrewAI для старта

Нет. Для первой задачи достаточно двух ролей, папки артефактов и HITL. LangGraph удобен, когда нужны паузы interrupt, сохранение состояния и повторяемые графы. CrewAI — когда хотите быстро собрать «команду» ролей. Оба инструмента вторичны относительно правила «автор ≠ критик ≠ выпускающий».

Сколько ролей минимум, чтобы контур работал

Три: автор, критик, человек. Детерминированные гейты — не «роль личности», а обязательный слой между автором и критиком/HITL. Дополнительные роли (фактчекер, SEO-checker) добавляйте только когда одна роль критика перегружена.

Подойдёт ли контур, если нужны ИИ агенты для бизнеса без разработки

Да, если задача повторяемая и результат проверяемый. Начните с одного типа контента (например, пост в Telegram по шаблону). Не запускайте сразу «нейросети для бизнеса» на все каналы сразу: сначала одна петля, один лог, один HITL.

Можно ли обойтись без человека, если критик очень строгий

На черновых внутренних черновиках — иногда. Перед внешней коммуникацией, деньгами и обещаниями бренда — нет. Даже сильный Agent-in-the-loop не снимает ответственность с выпускающего.

Чек-лист запуска контура на одной контент-задаче

Распечатайте и пройдите перед первой боевой публикацией:

Выбрана одна повторяемая задача с понятным «готово»
Есть brief с критериями приёмки и запретами
Автор и критик — разные промпты и контексты
Критику запрещено self-grade и «переписать красиво»
Включены детерминированные гейты (формат/запреты/meta)
Задан max_iterations и правило эскалации
Есть state/лог handoff со статусами
HITL стоит до публикации, publish заблокирован без approve
Прогнан тестовый прогон с искусственной ошибкой (гейт должен поймать)
После теста понятен расход токенов на 1 успешный пост

Если все пункты закрыты, у вас не «чат с нейросетью», а рабочий контур контроля качества контента для контент-завода.

Что проверяли по источникам

Паттерн evaluator–optimizer и разделение ролей генератор/оценщик — Engineering Anthropic: Building effective agents
Условия loop, запрет self-grade, stop-правила — Loop Engineering на Хабре
Верификация как часть архитектуры агента — Built with Claude / контур проверки
HITL и Agent-in-the-loop в агентной разработке — AvitoTech на Хабре
Практика «второй редактор» перед публикацией — onff.ru

Итог

Контур проверки AI-агентов собирается не из «лучшей модели», а из дисциплины: автор делает, машины отсекают формат, критик ищет смысл, человек выпускает. Разделите роли, запретите самозачёт, поставьте лимит циклов и HITL до публикации — и автоматизация контента перестанет быть генератором уверенного мусора.