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

«Контент-завод» — это система, в которой статьи, посты, обзоры производятся конвейерно: одна задача — несколько специализированных агентов, чёткое разделение ролей, контроль качества. В этой статье — реальная архитектура такого завода на OpenClaw, проверенная на сайте infoclaw.ru (где вы это сейчас читаете).

Зачем «завод», а не одна большая нейросеть

«Напиши статью на тему X» — даёт один длинный текст, но обычно с ошибками: вода, выдуманные цифры, плохой SEO, противоречия с уже опубликованным.

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

Архитектура: 6 ролей

┌──────────────┐
│ ОРКЕСТРАТОР  │ читает план, ставит задачи, контролирует
└──────┬───────┘
       │
       ├──→ ИССЛЕДОВАТЕЛЬ ──→ собирает источники (web search, RAG)
       │
       ├──→ ПЛАНИРОВЩИК   ──→ структура статьи, H2/H3, ключевые тезисы
       │
       ├──→ РЕДАКТОР      ──→ пишет черновик по плану и материалам
       │
       ├──→ ФАКТЧЕКЕР     ──→ проверяет факты, цифры, ссылки
       │
       ├──→ SEO-РЕДАКТОР  ──→ title, description, keywords, перелинковка
       │
       └──→ ПУБЛИКАТОР    ──→ frontmatter, файл, git commit, push

Каждая роль — отдельный sub-агент с собственным системным промптом и набором инструментов. Оркестратор не пишет текст — он только координирует.

Технологический стек

OpenClaw как раннер агентов (CLI + sub-agents через Task tool)
MCP-серверы: web search (Tavily/Brave), RAG по уже опубликованному (ChromaDB), git
.openclaw/skills/ — папка с описанием каждой роли в формате SKILL.md
content/queue.json — очередь задач
Git как хранилище — каждая статья = коммит, можно ревьюить и откатывать

Скилл оркестратора

skills/orchestrator/SKILL.md:

---
name: orchestrator
description: |
  Главный координатор. Берёт следующую задачу из queue.json,
  запускает sub-агентов, контролирует качество, передаёт публикатору.
---

# Алгоритм

1. Прочитай ./content/queue.json, возьми первую запись со status=pending.
2. Запусти research-agent с темой задачи — получи bundle источников.
3. Запусти planner-agent с темой + источниками — получи outline (JSON).
4. Запусти editor-agent с outline + источниками — получи draft.md.
5. Запусти factchecker-agent с draft — получи список вопросов или ✓.
   Если вопросы есть → верни editor-agent с правками.
6. Запусти seo-agent с draft — получи финальный .md с frontmatter.
7. Запусти publisher-agent — закоммитит и подтвердит публикацию.
8. Обнови queue.json: status=published, ts=now.
9. Логируй каждый шаг в logs/{slug}.log.

Скилл исследователя

skills/research-agent/SKILL.md — выделенный sub-агент. У него:

Доступ к web search MCP
Доступ к RAG по уже опубликованному (чтобы не дублировать)
Нет доступа к публикации — только чтение
Возвращает структуру { sources: [{url, title, key_facts}], rag_hits: [...] }

Принцип безопасности: каждый sub-агент имеет минимальные права под свою задачу. Исследователь не должен мочь писать в репозиторий.

Скилл редактора

skills/editor-agent/SKILL.md — пишет драфт. Особенности:

Жёсткие правила TOV в системном промпте (формальность, длина абзацев, запрещённые слова)
Запрет на цифры без источника — если факт без ссылки на research bundle, помечает [CITATION NEEDED]
Шаблон структуры — обязательны H2 «Что это», «Как работает», «Что дальше»

Скилл фактчекера

Самая важная роль — без неё контент рассыпается. Алгоритм:

Извлеки из драфта все утверждения с цифрами, датами, именами, ссылками.
Сопоставь с research bundle. Если не сходится — отметь.
Для каждой внешней ссылки — проверь, что URL открывается (HTTP 200).
Верни список { issue, location, severity }.

Severity > medium → возврат редактору с правками.

Очередь задач

content/queue.json — простой массив:

[
  {
    "slug": "openclaw-vs-code-podklyuchenie-nastroyka",
    "topic": "Как подключить OpenClaw к VS Code",
    "category": "integratsii",
    "target_words": 1500,
    "keywords": ["vs code", "vscode", "visual studio code"],
    "status": "pending",
    "created": "2026-05-26"
  }
]

Можно генерировать автоматически из анализа поисковых запросов (запрос «vs code openclaw» → новая задача в очереди).

Запуск

Ручной — раз в день:

openclaw run skill orchestrator

Автоматический — через cron, обычно в нерабочие часы (3:00 ночи), чтобы не тратить лимиты API днём:

openclaw cron add --name content-factory --schedule "0 3 * * *" --skill orchestrator

Подробнее — cron-jobs в OpenClaw и мульти-агентная оркестрация.

Безопасность

API-ключи — только в переменных окружения, не в скиллах.
Sub-агенты — каждый со своим минимумом прав (allowedPaths, mcpServers).
Лимит на статью — установите hard-cap на токены (например, 50k), чтобы баг в скилле не сожрал бюджет.
Human-in-the-loop — на старте обязательно ревью каждой статьи человеком перед публикацией. Через 50–100 статей можно ослабить до выборочного.
Git — все коммиты с пометкой источника (агент vs человек), легко откатить.

Метрики реального завода (infoclaw.ru)

6 волн × 7–20 статей за 2 месяца = 110+ статей
Cost: $40–80 на волну в зависимости от модели
Время оркестратора на статью: 6–12 минут wall-clock, 1–3 минуты GPU-эквивалента
Human review time: 8–15 минут на статью (читаем по диагонали, правим 1–2 фразы)
% статей с фактическими правками после ревью: ~30% (в основном — корректировка дат, версий, мелких терминов)

Чего нельзя делегировать

Тематический план — что вообще писать. Должен формировать человек на основе бизнес-целей и SEO-анализа (см. как это сделано в SEO-workflow OpenClaw).
Tone of voice и стилевые решения — задаются в системных промптах и обновляются вручную.
Финальная публикация на чувствительные темы (медицина, юридические, финансовые советы) — обязательное ревью эксперта.

С чего начать свой завод

Начните с одной роли: попросите OpenClaw написать статью по теме с конкретной структурой. Поймёте, чего не хватает.
Добавьте фактчекера — поймаете 60% типичных проблем.
Добавьте исследователя с RAG по своему сайту — статьи перестанут дублироваться.
Только потом — оркестратора и очередь.

Это эволюционный путь. Прыгать сразу к полной архитектуре — пустая трата времени и токенов.