Параллельно — не значит дать пяти агентам одну задачу
Параллельные Codex-workflows работают, когда у каждого агента есть отдельная часть проблемы. Они ломаются, когда все правят одни и те же файлы, придумывают разные планы и приносят огромный merge-конфликт.
Цель простая: разделить фичу на безопасные потоки, запустить Codex на отдельных VPS-агентах и объединять результат только после тестов и ревью. Office Claws делает это удобным: у каждого агента свой хост, ветка, состояние терминала и видимое место в desktop-приложении. Продуктовые решения остаются за человеком; агенты берут на себя ожидание, тесты и механические правки.
Правило: делите по границам, а не по списку желаний
Слабое разделение выглядит так:
- Агент A: реализовать фичу
- Агент B: написать тесты
- Агент C: обновить документацию
Это похоже на параллельность, но B еще не знает интерфейс, а C документирует поведение, которое может измениться.
Лучше делить по техническим границам:
- Агент A: миграция и repository-слой
- Агент B: API-route и валидация
- Агент C: UI-состояния empty/loading/error
- Агент D: документация и release note после стабилизации интерфейса
Если двум агентам нужен один и тот же файл, разделение, скорее всего, плохое.
Практический workflow из четырех веток
1. Сначала напишите контракт
До запуска агентов оставьте маленький контракт в main: типы, форму endpoint, имена файлов и команду тестов.
Endpoint: POST /api/runs/:id/retry
Request: { mode: "failed-only" | "all" }
Response: { runId: string, queuedTasks: number }
Tests: npm run test -- retry
Не переименовывать существующие значения RunStatus.Это скучно, но именно это отделяет параллельность от хаоса.
2. Одна ветка на агента
Называйте ветки по ответственности:
feat/retry-runs-apifeat/retry-runs-uifeat/retry-runs-testsdocs/retry-runs-release-note
В Office Claws каждый Codex-агент работает на своем VPS и в своей ветке. Неудачные эксперименты не загрязняют остальных.
3. Узкие промпты
Ты отвечаешь только за API-route и валидацию retry runs.
Не редактируй UI-файлы. Не переименовывай shared status enums.
Перед завершением выполни: npm run test -- retry
Верни summary, измененные файлы и нужные изменения контракта.Запреты нужны не для вежливости, а для профилактики конфликтов.
Порядок merge важен
Сначала объединяйте фундамент: data model, затем API, затем UI, затем docs. После каждого merge делайте rebase оставшихся веток, чтобы все агенты видели актуальный контракт.
- Merge repository/database-ветки после зеленых тестов
- Rebase API-ветки, исправление drift, merge
- Rebase UI-ветки и подключение к реальному endpoint
- Tests/docs — в конце
Не ждите финала, чтобы слить всё разом. Так review становится огромным и скрывает место, где изменился дизайн.
Когда это стоит делать
Параллельность помогает, когда есть естественные границы:
- Backend + frontend + docs
- Migration + adapter + tests
- Refactor одного package, пока другой агент обновляет call sites
- Исследовать три возможных fix и оставить лучший
- Перенести один паттерн в несколько независимых integrations
Для бага на 20 строк один Codex-сеанс быстрее.
Где здесь Office Claws
Это можно сделать через SSH-tabs и tmux. Сложность — помнить, какая машина, ветка и терминал владеют каким куском. Office Claws дает control plane: несколько Codex-агентов на VPS, видимых из одного desktop-приложения.
Если вы пришли из OpenClaw, начните со сравнения OpenClaw vs Codex. Если уже хотите hosted Codex agents, страница цен показывает self-hosted и managed варианты.
Checklist
- Есть письменный контракт?
- У каждого агента разные файлы?
- В каждом prompt явно написано, что запрещено?
- Есть команда проверки на каждую ветку?
- Известен порядок merge до старта?
- Один человек принимает или отклоняет изменения контракта?
Параллельные Codex-workflows сильны потому, что агенты остаются узкими. Они не становятся автономными менеджерами; они просто перестают ждать друг друга, пока архитектура остается у вас в руках.