Направлять фоновые воркеры

Это руководство показывает, как вести разговор в роли директора, а не воркера: сессия читает и проверяет, а правки вносят фоновые агенты.

Что меняется, когда вы вводите /vibe

Две вещи, и только первая принудительно обеспечивается механизмом:

1. Собственные инструменты сессии опускаются до режима только для чтения, плюс пять глаголов воркера. Единственный способ для неё повлиять на репозиторий — через воркера, а единственный способ узнать, что произошло, — прочитать файлы, которых коснулся воркер.
2. Ей предписано проверять чтением, а не верой. Отчёт воркера — это заявление о том, что он сделал, а не доказательство того, что это сработало.

Нагрузку несёт первое. Директор, который по-прежнему может искать и редактировать, под давлением сделает работу сам — а именно этот сценарий отказа и призван предотвратить данный режим.

/vibe migrate the auth module to the new session API

Воркеры стартуют с чистого листа

Воркер никогда не видел ваш разговор и никогда не увидит. Задание — это весь его контекст.

Именно это делает схему дешёвой — двадцать воркеров, каждый из которых хранил бы историю директора, стоили бы в двадцать раз больше контекста директора, — и одновременно это единственное, что делает задания трудными для написания. «Сделай теперь и второе» для директора читается как полная инструкция, а для свежей сессии — как ничего.

Хорошее задание называет файлы, команды и критерий готовности:

В lib/features/auth/ замените каждый вызов SessionStore.read(key) на SessionStore.get(key). Новый метод возвращает Future<String?>, тогда как старый возвращал String?, поэтому вызывающему коду нужен await. Когда закончите, запустите fvm flutter analyze lib/features/auth и сообщите об ошибках, которые не удалось исправить.

Пять глаголов

Глагол	Что он делает
vibe_spawn	Запускает воркера с заданием. Возвращает управление сразу.
vibe_list	Уровень, статус, затраченное время и последний результат для всех
vibe_send	Дополнительный ход для воркера, который уже завершился
vibe_wait	Блокирует, пока один воркер не завершится
vibe_kill	Останавливает одного

Запуск воркеров асинхронен по замыслу. Директор, который блокируется на каждом запуске, выполняет воркеров по одному — то есть делает медленнее то, что и так делал сам. Используйте vibe_wait, только когда действительно не можете продолжить без конкретного ответа.

Два уровня

Уровень	Для чего
fast	Механическая работа с чёткой спецификацией — правки, переименования, черновики, запуск команд
good	Проектирование, суждение или проверка того, что сделал воркер fast

Обычная схема — распараллелить воркеров fast по независимым файлам, а затем запустить одного воркера good, чтобы проверить, что они сделали вместе.

Проверка

Именно здесь решается, чего стоит вся эта схема.

vibe_list
→ w1 [fast] auth-migrate — done (48s): Edited lib/features/auth/session.dart …
  w2 [fast] tests — running (12s)

Затем прочитайте файлы, которые он назвал. У директора есть read, search, lsp и ast_grep; ради этого их и оставляют. Директор, который принимает отчёт за чистую монету, лишь пересказывает оптимизм других агентов.

lsp(action: "diagnostics", file: "*") после круга воркеров — обычно самая быстрая одиночная проверка.

Когда воркер теряет нить

Убейте его и составьте задание заново. Свежее исправленное задание дешевле спора, а vibe_send работает только с воркером, который уже завершил свой ход.

vibe_kill(worker_id: "w2")
vibe_spawn(brief: "…corrected…", label: "tests", tier: "fast")

Ограничения

• Восемь одновременных воркеров. Это потолок расходов, а не техническое ограничение: каждый воркер — полноценная сессия модели, и директор, распараллеливший двадцать, уже не отслеживает, чем все они заняты.
• Ни один воркер не переживает режим. Когда запуск завершается, все они останавливаются, и в транскрипте указывается, сколько их было. Фоновый агент, который продолжает править файлы после того, как разговор ушёл дальше, — единственный сбой, которого здесь нельзя допустить.
• По своей сути воркеры — обычные субагенты. Тот же предел вложенности, та же политика ограничений, та же дочерняя запись в журнале запуска. Vibe меняет то, кто ими управляет, а не то, что им разрешено, — поэтому запросы на одобрение по-прежнему появляются для вызовов записи и выполнения у воркера.

Когда его не использовать

Режим vibe предназначен для работы, которая разбирается на независимые задания. Если следующий шаг зависит от результата предыдущего, вы описываете конвейер или оркестрацию, и оба выражают зависимости правильно, а не заставляют директора имитировать их через vibe_wait.

См. также

• Запускать агентов параллельно — другие способы распараллелить работу
• Оркестрация — когда у работы есть форма
• Встроенные инструменты агента — глаголы и их аргументы