Когда Codex нужен не один агент, а несколько: как не утопить задачу в шуме
Когда проект становится сложнее, возникает понятное желание: давайте дадим Codex больше агентов. Один пишет статью, второй делает заголовок, третий рисует, четвертый проверяет, пятый публикует. На бумаге звучит как фабрика. На практике легко получить не архитектуру, а шум: много потоков, каждый что-то сделал, а ответственность за итог растворилась.
В официальной документации OpenAI по Subagents этот механизм описан не как магическое умножение Codex, а как способ выделять специализированные независимые ветки работы. Subagents помогают, когда нужно исследовать разные направления, проверить гипотезы, прогнать тесты, изучить логи или снизить загрязнение основного контекста. Но они не должны заменять простой навык там, где задача линейная.
Для редакционного производства это особенно важно. У нас есть статьи, источники, SEO, визуал, публикация, очередь. Если все смешать в один чат, контекст пухнет. Если все раздать случайным агентам, процесс расползается. Нужна середина: главный редакционный оркестратор плюс subskills, а subagents только для действительно независимых ролей.
Skill и subagent - не одно и то же
Skill - это повторяемый способ делать задачу. Например: написать статью по источникам, собрать SEO-поля, подготовить визуальный бриф, проверить draft.md, сделать GIF, упаковать публикацию. Skill живет как инструкция, чеклист, скрипт, шаблон и локальная память.
Subagent - это отдельный исполнитель, которому можно отдать самостоятельную ветку работы. Он должен иметь свой вопрос, свои входные данные и короткий результат на выходе. Если subagent возвращает в главный поток еще больше сырого контекста, он не помог. Он просто переложил беспорядок.
| Вопрос | Лучше skill | Лучше subagent |
|---|---|---|
| Нужно повторить известный редакционный шаг | Да | Нет |
| Нужно независимо проверить источники | Иногда | Да, если проверка большая |
| Нужно создать визуал в отдельном производственном контуре | Нет, если это один prompt | Да, если есть отдельная визуальная студия и QA |
| Нужно придумать заголовок по готовой статье | Да | Обычно нет |
| Нужно параллельно исследовать три гипотезы | Нет | Да |
| Нужно опубликовать готовый пакет | Да, через pipeline | Нет, если нет отдельной ответственности |
Главный критерий: subagent должен уменьшать нагрузку на основной контекст, а не создавать новый слой координационной боли.
Как это выглядит для написания статей
Для статьи главный Codex-чат должен оставаться редактором-оркестратором. Он выбирает источник, понимает аудиторию, пишет текст, следит за правилами проекта, создает iteration package и решает, что готово, а что заблокировано.
Внутри этого процесса можно использовать subskills:
- Источник и фактчек.
- Заголовок и SEO-обещание.
- Структура статьи.
- Длинный текст.
- Проверка публичного тела.
- Визуальный бриф.
- Публикационный gate.
Это не обязательно отдельные агенты. Часто это один Codex, который последовательно применяет разные навыки. Так меньше накладных расходов, меньше конфликтов и проще понять, кто отвечает за итог.
Subagent появляется, когда шаг стал достаточно самостоятельным. Например, визуальная студия в отдельном чате "Журнал : GIF генератор" - уже не просто функция. Там есть свой визуальный язык, свои референсы, свои проверки, свой результат-пакет. Это похоже на отдельного production-исполнителя, и его правильно отделять.
Что дать Codex как вход
Если вы хотите распараллелить работу, не пишите "пусть несколько агентов подумают". Лучше дать карту:
Главный Codex пишет статью и отвечает за итоговый пакет. Отдельный visual subagent получает только тезис статьи, visual brief и ограничения. Отдельный review subagent получает только draft.md и чеклист качества. Каждый возвращает короткий result packet: что сделано, что заблокировано, какие файлы готовы. Главный Codex принимает решение, публиковать или ждать.Такой ввод сразу разделяет роли. Главный поток не теряет ответственность. Subagents не спорят за редакционное решение. Визуал не начинает переписывать статью. Проверка не начинает придумывать новую тему.
Как не утонуть в контексте
Большая опасность subagents - context rot, то есть постепенное загрязнение рабочего контекста. Сначала агент получает задачу, потом все промежуточные рассуждения, потом чужие черновики, потом старые решения, потом уже никто не помнит, что было утверждено.
Лечение простое: subagent возвращает не поток мыслей, а артефакт.
Для визуала это может быть:
media_manifest.yaml;- source image;
- final image или GIF;
- visual QA status;
- короткое объяснение, почему визуал соответствует статье.
Для проверки текста:
- список блокеров;
- список предупреждений;
- решение pass или blocked;
- точные файлы, которые надо исправить.
Для источников:
- какие публичные источники проверены;
- какие тезисы подтверждены;
- где есть риск устаревания;
- что нельзя утверждать.
Главный Codex должен получать короткие результаты, а не чужую историю работы.
Где остается человеческое решение
Человек не обязан управлять каждым subagent вручную. Но человек должен решить архитектуру ответственности.
Например:
| Решение | Кто принимает |
|---|---|
| Нужна ли отдельная визуальная студия | Человек и главный редакционный Codex |
| Можно ли публиковать без визуала | Политика проекта, обычно нет |
| Какие subskills входят в статью | Главный редакционный Codex по policy |
| Какие задачи отдавать subagent | Главный Codex, если задача независимая |
| Готов ли итог к публикации | Gate и человек при необходимости |
Это важнее, чем количество агентов. Один хорошо устроенный процесс лучше пяти активных, но несогласованных исполнителей.
Практическая архитектура для журнала
Для ONFF разумная схема такая:
| Слой | Роль |
|---|---|
| Главный article skill | пишет статью, держит структуру, источники, SEO и статус |
| Title subskill | делает кликабельный, но честный заголовок |
| Structure subskill | собирает H2, таблицу, практический артефакт |
| Text review gate | проверяет публичное тело и блокеры |
| Visual production subagent | делает концепт, изображение, GIF и visual QA |
| ArticleFactory | публикует и ставит готовое в очередь, но не творит |
Так мы не превращаем ArticleFactory в художника, не заставляем визуальный чат писать статьи и не смешиваем редакторскую ответственность с очередью публикаций. Codex остается редакцией. Skills дают повторяемость. Subagents появляются там, где нужен отдельный производственный контур.
Subagents в Codex нужны не для того, чтобы работа выглядела сложнее. Они нужны, когда сложность уже есть и ее надо аккуратно разнести по независимым каналам. Если задача линейная, хватит skill. Если задача ветвится и каждая ветка возвращает проверяемый артефакт, subagent оправдан. Это и есть нормальная архитектура: меньше театра, больше управляемого результата.
