Multi-agent workflow в Claude Code: роли, изоляция и ручная проверка
Практический multi-agent workflow для Claude Code: разделение ролей автора и ревьюера, изоляция через Git worktree, контракт handoff и финальная ручная приёмка.
Создание полностью автономных «команд AI-агентов» с автоматическим слиянием кода часто приводит к незаметным ошибкам архитектуры, циклическим правкам и деградации кодовой базы. Два агента, запущенные параллельно, не гарантируют независимой истины: если автор допустил логическую ошибку, проверяющий агент на той же базе промптов может её пропустить.
Надёжный multi-agent workflow строится не на иллюзии полной автономии, а на строгом разделении ролей: исполнитель (Author), независимый верификатор (Reviewer) и человек, принимающий решение о слиянии (Decision Maker).
1. Разделение ролей: автор, ревьюер и человек
В эффективном рабочем процессе у каждого участника есть своя замкнутая зона ответственности:
2. Изоляция контекста и рабочих директорий
Не запускайте автора и ревьюера в одной и той же директории или общем диалоге. Разделяйте их на трёх уровнях:
- Сессия диалога: отдельный контекст, исключающий взаимное убеждение агентов.
- Файловая изоляция: отдельные Git worktree, чтобы ревьюер проверял только зафиксированный diff.
- Безопасность окружения: API Key и секреты не передаются между сессиями в текстовом виде.
Команды подготовки worktree:
[!IMPORTANT]
API-конфигурация: Каждая сессия Claude Code использует собственный API Key, настроенный через переменные окружения. Схему Claude Code API-workflow и собственный Key сверяйте в BetterToken Docs: https://docs.bettertoken.ai/ai-tools/claude-code?utm_source=blog&utm_medium=organic_content&utm_campaign=SEO-103&utm_content=claude-code-multi-agent-review-workflow.
3. Контракт передачи (Handoff Card)
После завершения задачи исполнителем формируется компактная карточка передачи. В неё запрещено включать токены, дампы переписки или непроверенные утверждения:
Handoff Card
- Задача: Добавить повтор HTTP 429 в платёжном клиенте с экспоненциальной задержкой.
- Ветка:
feat/payment-retry - Изменённые файлы:
src/client/http.ts,tests/http-retry.test.ts - Команда проверки:
npm test -- tests/http-retry.test.ts(Passed) - Риски и блокеры: Экспоненциальный backoff ограничен 3 попытками; таймаут сокета не менялся.
- Следующий шаг: Ревьюер проверяет обработку заголовка Retry-After.
4. Протокол ручной приёмки инженером
Ревьюер-агент запускает изолированную проверку:
- Переходит в рабочую копию
../agent-reviewer. - Запускает записанную команду верификации.
- Проводит независимый аудит diff на предмет побочных эффектов.
- Выдаёт инженеру структурированное резюме.
Инженер выполняет финальный шаг:
- Просматривает замечания ревьюера;
- Подтверждает отсутствие конфликтов с
main; - Выполняет мерж вручную:
git merge feat/payment-retry.
Такой конвейер исключает галлюцинации взаимного подтверждения и оставляет контроль над качеством кода в руках разработчика.
Оплата и пополнение баланса
Пополнение баланса и оплата API осуществляются в личном кабинете BetterToken. Платформа поддерживает удобные способы оплаты, мгновенное зачисление средств и единый баланс для всех доступных моделей.
Пример числового расчёта и тарифы
По состоянию на 15 августа 2026 года в каталоге цен BetterToken базовые ставки составляют:
- Вход: $3.00 за 1M токенов;
- Выход: $15.00 за 1M токенов;
- Чтение из кэша (cache read): $0.30 за 1M токенов.
Для типового запроса на 100 000 входных и 10 000 выходных токенов без кэша итоговая стоимость составит: 0.1 × $3.00 + 0.01 × $15.00 = $0.45.