Паралельна робота AI без конфліктів: ізолюйте кожну задачу в worktree

ai · 2026-10-09

Паралельні AI-агенти корисні тоді, коли задачі справді незалежні: один досліджує код, другий додає тести, третій перевіряє ризики. Але запускати їх в одному каталозі — майже гарантований спосіб отримати змішані зміни, зламані тести й незрозумілий авторський намір.

Робочий патерн простий: одна задача — один контекст — один Git worktree — один перевірений результат. Worktree — це окремий робочий каталог і гілка, які використовують спільну історію репозиторію. Git описує цю модель у документації git worktree.

Що саме ізолювати

Ізоляція потрібна не лише для файлів. Для кожного паралельного працівника варто окремо визначити:

контекст — короткий контракт задачі, а не весь діалог координатора;
файли — власний worktree, щоб індекс, незакомічені зміни й гілка не перетиналися;
дозволи — дослідник читає, виконавець пише, рев’юер не пише;
артефакти — логи, результати тестів і підсумок повертаються як звіт, а не потік сирого виводу;
межу завершення — агент закінчив роботу після тестів і diff, а не після фрази «готово».

Це відрізняється від простого поділу одного чату на кілька підзадач. Підзадачі економлять увагу головного агента, але не захищають спільний каталог від одночасного запису.

Як це роблять Claude, Codex і OpenCode

У Claude Code worktree є вбудованим режимом: claude --worktree <name> створює окрему гілку й каталог. Документація також описує ізоляцію subagent через isolation: worktree, очищення незмінених worktree та важливе обмеження: неінтерактивний запуск не показує фінального запиту на очищення, тому прибирання треба планувати явно. Деталі — у Run parallel sessions with worktrees та огляді Run agents in parallel.

Codex радить subagent-процеси насамперед для читання, пошуку, тестів і тріажу; паралельне редагування потребує обережності через конфлікти й координаційні витрати. Це прямо зазначено в документації Codex про subagents. Тому для write-heavy задач worktree має бути явною частиною контракту, навіть якщо клієнт уміє запускати агентів паралельно. У Codex CLI також окремо виділені делегування, локальне рев’ю й робота з репозиторієм — це зручна модель для головного координатора.

OpenCode розділяє primary agents і subagents: вбудований Plan обмежує редагування та shell-команди, Explore призначений для читання, а Build має повний набір інструментів. Це частина відкритого проєкту, код і поточні можливості якого доступні в репозиторії OpenCode. Для дозволів застосовуйте ту саму модель allow, ask, deny. Отже, спільний для всіх інструментів принцип такий: агент, який знаходить проблему, не обов’язково має право її виправляти.

Мінімальний ручний цикл

Для будь-якого клієнта спочатку можна перевірити патерн звичайними командами Git:

git fetch origin main
git worktree add ../worktrees/task-123 -b ai/task-123 origin/main
cd ../worktrees/task-123

# Тут працює лише один агент і лише над task-123.
run-tests
git diff --check
git status --short

cd -
git diff --stat main...ai/task-123
git worktree remove ../worktrees/task-123
git worktree prune

Не передавайте агенту розмиту інструкцію «попрацюй над репозиторієм». Дайте короткий контракт:

task_id: task-123
base: origin/main
goal: "Додати перевірку терміну дії токена"
allowed_paths:
  - src/auth/
  - tests/auth/
read_only_paths:
  - docs/
  - vault/
must_run:
  - unit-tests
  - git-diff-check
result:
  - summary
  - changed_files
  - test_commands_and_results
  - known_risks

allowed_paths не є заміною дозволам операційної системи, але добре зменшує область помилки. Перед злиттям все одно перевіряйте diff, список файлів і тести на рівні координатора.

Практичні схеми для OpenClaw

1. Telegram як диспетчер, а не робочий каталог

Зробіть Telegram-бота точкою постановки задачі. Він створює task_id, записує контракт у vault і запускає окрему сесію виконавця. Сам бот не редагує репозиторій і повертає лише статус: started, needs-input, ready-for-review, failed.

Топологія може бути такою:

Telegram dispatcher (read-only) ──> task contract in vault
                                   ├─> explorer (read-only)
                                   ├─> worker in own worktree
                                   └─> reviewer (read-only)

Для кожної задачі зберігайте в vault не повний лог, а контракт, посилання на гілку, commit SHA, результати перевірок і рішення про merge. Це дає відновлюваність після перезапуску OpenClaw і не забиває контекст головного агента.

2. Три ролі замість трьох однакових агентів

Розділіть інструменти за ролями:

explorer: читання коду, документації й логів; без запису;
worker: один worktree, обмежені каталоги, запуск тестів;
reviewer: читання diff і тестових звітів; без запису в робочий worktree.

Explorer повертає п’ять–десять перевірених фактів і список файлів, а не копію всього репозиторію. Worker отримує цей стислий результат разом із контрактом. Reviewer перевіряє саме diff від базової гілки, а не довіряє переказу worker.

Це добре лягає на можливості OpenCode: Plan/Explore можна залишити без запису, а для окремого reviewer встановити edit: deny і bash: deny у конфігурації агента. У Claude та Codex назви полів інші, тому переносити конфігурацію буквально між клієнтами не слід; переноситься лише модель ролей і меж.

3. Vault як журнал станів, а не спільна пам’ять для запису

Для довгих задач створіть одну сторінку на task_id з чіткими станами:

queued -> explored -> working -> tested -> reviewed -> merged
                              \-> failed

Записувати її може тільки координатор. Працівники повертають структурований звіт, а координатор атомарно оновлює стан. Такий порядок запобігає ситуації, коли два агенти одночасно переписали «поточний план» і стерли важливу інформацію один одного.

4. Нестандартний варіант: короткоживучий worktree на кожен тестовий сценарій

Для критичних змін можна створювати worktree не на feature, а на окремий сценарій: token-expired, token-revoked, clock-skew. Кожен агент змінює лише тест і мінімальний код, після чого координатор порівнює результати й переносить узгоджене рішення в основну гілку.

Перевага — легко зрозуміти, який сценарій зламався, і можна паралельно запускати дорогі перевірки. Недоліки — більше диска, повторна інсталяція залежностей і більше cherry-pick/merge-операцій. Цей варіант виправданий для міграцій, security-fix та регресій, але надмірний для маленької зміни в одному файлі.

Правила завершення

Перед merge координатор має вимагати:

git diff --check без помилок;
список змінених файлів у дозволеній області;
конкретні команди тестів і їхній результат;
commit SHA або інший відтворюваний ідентифікатор;
окремий список невідомих ризиків.

Якщо агент завершився посередині, worktree не видаляйте автоматично: спочатку перевірте git status, незакомічені зміни та блокування. Якщо робота не потрібна, видаляйте worktree штатною командою Git і періодично запускайте git worktree prune. Якщо вона потрібна — збережіть гілку й продовжіть сесію з тим самим контрактом.

Головний критерій паралельності — не кількість запущених агентів. Це кількість незалежних, перевірених і придатних до merge результатів. Worktree вирішує конфлікт файлів; короткий контракт, рольові дозволи й журнал станів вирішують конфлікт намірів.