Параллельные задачи Codex: как запускать несколько потоков и не столкнуть их в одних файлах

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

Но у параллельной работы есть простое ограничение. Если два потока трогают одни и те же файлы, страницы или публикационные артефакты, ускорение быстро превращается в конфликт. Один агент исправляет, второй перезаписывает, третий проверяет уже не ту версию.

Поэтому навык здесь не в том, чтобы открыть больше чатов. Навык в том, чтобы дать каждому потоку свою зону работы.

Почему параллельность в Codex не равна хаосу

Параллельная работа полезна, когда задачи действительно независимы. Например, один поток может готовить статью, второй — проверять старую публикацию, третий — делать аудит очереди, четвёртый — анализировать документацию. Они могут работать одновременно, если не меняют один и тот же пакет.

Проблема начинается, когда границы не названы. Тогда два потока могут одновременно править один draft.md, один seo_fields.yaml, одну страницу сайта или один queue-файл. Формально оба работают правильно, но вместе создают неуправляемую смесь.

Для владельца проекта это важно не как техническая тонкость, а как правило управления. Параллельность нужна только там, где результат можно собрать без спора версий.

Что документация говорит о thread model

В документации OpenAI Codex thread описан как отдельная сессия: ваш prompt, ответы модели и действия инструментов внутри этой работы. Один thread может включать несколько сообщений и продолжаться позже.

Там же есть важное практическое предупреждение: можно запускать несколько threads одновременно, но нужно избегать ситуации, когда два thread меняют одни и те же файлы.

Документация также разделяет локальные и облачные потоки. Локальный thread работает на вашей машине и видит ваши файлы и инструменты. Облачный thread запускается в изолированной среде и полезен, когда нужно делегировать работу или выполнять её параллельно. Но логика границ остаётся той же: параллельная задача должна иметь отдельную область ответственности.

Иными словами, Codex разрешает параллельность, но не отменяет управление конфликтами.

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

Перед тем как открыть несколько потоков, нужно составить короткую карту задач.

Вход для Codex:

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

Не надо писать сложную техническую схему. Достаточно сказать:

У меня есть три задачи. Сначала помоги разделить их по потокам.
Для каждой задачи назови:
1. отдельную зону файлов или документов;
2. что поток может менять;
3. что поток не должен трогать;
4. какой артефакт он должен вернуть;
5. есть ли конфликт с другими потоками.

После такого запроса Codex не начинает работу вслепую. Он сначала помогает понять, можно ли вообще безопасно распараллелить задачу.

Как выглядит карта потоков

Хорошая карта потоков выглядит как рабочая таблица.

Такая таблица сразу показывает, где можно работать одновременно, а где нужен один ответственный поток.

Если две строки используют один и тот же файл, это красный сигнал. Их лучше делать последовательно или объединить в один поток.

Как проверить границы без кода

Непрограммисту не нужно понимать Git-merge на уровне инженера. Нужно проверить четыре вещи.

Первое: у каждой задачи есть отдельная зона. Не "сделай сайт лучше", а "проверь страницу A", "обнови текст B", "собери визуал для статьи C".

Второе: один файл не назначен двум потокам. Если два потока хотят менять один draft.md, один STATE.yaml или один файл очереди, это не параллельность, а спор.

Третье: у каждого потока есть свой артефакт. Один возвращает текст, другой — аудит, третий — визуал, четвёртый — список рисков.

Четвёртое: есть общий момент сборки. Кто-то должен собрать результаты и решить, что публиковать, что отклонить и что запускать дальше.

Без этого параллельные потоки создают не скорость, а расхождение состояния.

Когда задачи нельзя запускать параллельно

Есть задачи, которые лучше не распараллеливать.

Не стоит запускать два потока на один и тот же текст. Один будет менять структуру, другой — заголовки, третий — SEO. В итоге непонятно, чей результат актуален.

Не стоит параллельно публиковать и редактировать одну статью. Сначала готовим пакет, затем проходим gates, затем публикуем.

Не стоит параллельно менять общие конфиги, правила, политики и queue-файлы, если нет явного владельца.

Параллельность хороша для независимых задач. Для общего состояния нужен один главный поток и понятная последовательность.

Шаблон запроса

Используйте такой запрос перед запуском нескольких потоков:

Я хочу запустить несколько задач Codex параллельно.

Задачи:
1. [задача A]
2. [задача B]
3. [задача C]

Сначала не выполняй их.
Составь карту потоков:
- какой thread должен делать какую задачу;
- какие файлы, страницы или документы относятся к каждому thread;
- что каждому thread можно менять;
- что каждому thread нельзя трогать;
- какие задачи конфликтуют и должны идти последовательно;
- где нужен общий контрольный шаг перед публикацией или применением.

После карты остановись и жди подтверждения.

Так Codex становится не набором случайных чатов, а рабочим местом с распределением ответственности. Параллельность остаётся полезной, но перестаёт ломать состояние проекта.