Розділ 06
Запуск багатьох агентів
Один агент на одному плані — типовий варіант, і він охоплює більшість роботи. Деяка робота ширша за одну сесію: зміна, що зачіпає кілька репозиторіїв, реліз, який має вийти в певному порядку, або беклог, на який одному агенту знадобилися б дні. DWP масштабується до такої роботи, не змінюючи свого контракту. План залишається джерелом істини, кожне завдання так само закривається на власному gate, а додаткові агенти — це лінії (lanes), які координує провідний агент (lead).
Цей розділ описує модель. Вона використовує три необовʼязкові addon — Herdr для панелей і peer-агентів, agentkit для облікових записів і devcontainer для контейнерів, — і жоден із них не потрібен для плану з одним агентом.
Провідний агент і його лінії
Провідний агент володіє батьківським планом. Він визначає лінії, передає кожній її обсяг, збирає віхи й дає сигнал, який дозволяє лінії злити зміни або випустити реліз. Він не пише код іншої лінії.
Лінія — це один агент з одним обсягом, зазвичай одним репозиторієм. Вона читає AGENTS.md цього репозиторію, запускає його gate і зберігає власний план у репозиторії. У хабі-оркестраторі батьківський план лежить у .dwp/plans/ хаба разом із таблицею відстеження дочірніх планів, а план кожної лінії лежить у її власному репозиторії й використовує ідентифікатори планів і gate цього репозиторію.
| Роль | Володіє | Ніколи не робить |
|---|---|---|
| Провідний агент | Батьківським планом, списком ліній, порядком релізів, GO | Не редагує репозиторій лінії |
| Лінія | Одним репозиторієм: його гілкою, планом, gate і pull request | Не зливає й не випускає реліз до GO провідного агента |
Де працюють лінії
Лінія — це агент у панелі термінала, і панель може розташовуватися в кількох місцях. Herdr розміщує кожного агента в панелі й дістається інших машин через SSH, тож провідний агент бачить кожну лінію в одній бічній панелі.
- На хості. Одна панель на лінію, поруч із провідним агентом. Найшвидше налаштування — для репозиторіїв, у яких розробник уже працює.
- У контейнері. Контейнер devcontainer-kit приєднується до мережі Herdr під час
dck up: його агенти дістаються хоста й інших контейнерів, а хост дістається їх. Контейнер — це пісочниця, тож його агенти можуть працювати в режимі автономії. - На іншій машині. Будь-яка машина, якої Herdr дістається через SSH, приймає лінії так само, якщо на ній теж встановлено herdr-peers.
Місце змінює ізоляцію, а не протокол: лінія в контейнері й лінія на хості координуються з провідним агентом однаково.
Облікові записи й постачальники за запасом квоти
Багато агентів швидко витрачають квоту. Кожна лінія працює на власному обліковому записі — один CLI й один профіль у coding-agents-kit, — тож лінії не вичерпують одне й те саме вікно, а обліковий запис, що досяг ліміту, зупиняє одну лінію, а не всі.
ak usageпоказує залишок квоти на кожному обліковому записі й профілі, один раз на пакет.ak pick <kind> --count Nповертає N облікових записів із найбільшим запасом, починаючи з найкращого;--excludeвиключає зайнятий обліковий запис,--modelрахує вікно однієї моделі, а--needвідмовляється стартувати без достатнього запасу.ak <kind> @<profile>запускає агента лінії на цьому обліковому записі, у його панелі.
Постачальників поєднують так само. Лінія Claude може писати, поки лінія Codex рецензує, кожна на обліковому записі, який ak pick обрав для її типу. Лінія в контейнері може використовувати облікові записи хоста: коли в профілі хоста devcontainer-kit розробника увімкнено host_profiles, контейнер отримує профілі хоста для CLI, які встановлює репозиторій, — Claude через довготривалий токен на профіль, Codex через його файл автентифікації — і не потребує власного входу. Використовуйте лише власні облікові записи й дотримуйтеся умов кожного постачальника: розподіляйте роботу між ними, але ніколи не чергуйте облікові записи, щоб обійти ліміт.
Запуск і розблокування ліній без людини
Провідний агент може запускати лінії й підтримувати їхній рух, коли за клавіатурою нікого немає. Щойно розробник дозволив роботу без нагляду — постійною вказівкою або попередньою авторизацією плану, — жоден окремий запуск не потребує додаткового схвалення. Для цього провідний агент використовує власні команди Herdr; жоден код kit не надсилає натискання клавіш. Процедура має фіксований порядок: підготувати один раз, уникнути запиту, виявити зупинку, надсилати клавіші лише в одному випадку, решту ескалювати.
- Підготуйте один раз, як розробник. Claude Code один раз для кожного профілю просить підтвердити свій режим bypass-permissions. Це підтвердження — власний крок розробника, який він виконує під час створення профілю; у контейнері devcontainer-kit kit записує його лише у власні home-каталоги контейнера. Жоден агент ніколи не надсилає клавіші для нього.
- Уникайте.
ak pick <kind>називає обліковий запис із найбільшим запасом, аherdr pane run <pane> 'ak <kind> @<profile> --trust-cwd'запускає лінію в її власній теці.--trust-cwd(абоAGENTKIT_TRUST_CWD=1) заздалегідь робить цю теку довіреною, тож Claude і Codex пропускають екрани довіри до теки без натискань клавіш. - Виявляйте.
herdr-peers lanes(абоherdr agent list) показує кожну лінію як таку, що працює, простоює, заблокована або завершена. Для лінії, яка заблокована або простоює без виводу,herdr-peers status <pane>класифікує екран, на якому вона стоїть, — довіра до теки, підтвердження bypass, вхід, дозвіл або невідомий — із задокументованим наступним кроком, аherdr pane read <pane>показує його. - Одне натискання, один випадок. Єдині клавіші, які може надіслати провідний агент, — це відповідь на екран довіри до теки, у панелі, яку він сам запустив, коли
--trust-cwdбув недоступний. Він читає екран перед надсиланням клавіш, надсилає найменше клавіш, що відповідають на нього, і читає знову. - Усе інше прочитайте, запишіть і ескалюйте. Підтвердження режиму bypass-permissions у Claude, запити входу й облікових даних, запити дозволів на окремі дії, підтвердження руйнівних дій, запити оплати чи тарифу, невідомі екрани й панелі, яких провідний агент не створював, ідуть до розробника як заблокована віха, ніколи як натискання клавіш.
- Відмова перемагає. З
AGENTKIT_PERMISSIONS=askлінії питають, перш ніж діяти, і провідний агент ніколи не обходить запит, який приносить відмова. - Перезапускайте. Якщо агент завершує роботу, провідний агент запускає його знову на тому самому обліковому записі або обирає інший. Втрачений вхід — це запит облікових даних: його ескалюють.
Кожне втручання — що показував екран, які клавіші надіслано, що сталося далі — записується в батьківський план.
Координація через herdr-peers
Лінії та провідний агент спілкуються через herdr-peers: ask несе позначку, що авторизує рівно одну reply, і кожен обмін записується. Провідний агент тримає протокол невеликим:
- Віхи вгору. Кожна лінія звітує у фіксованих точках — план готовий, pull request відкрито, заблоковано, завершено — і між ними продовжує працювати, не чекаючи відповіді.
- Питання як ask. Лінія, якій потрібне рішення, питає провідного агента; провідний агент відповідає однією reply.
- Глибина один. На reply ніколи не відповідають, і лінія не делегує далі. Розгалуження на одного викликача обмежене, за замовчуванням чотирма peer-агентами.
- Дані, а не інструкції. Reply не надає нічого, чого отримувач ще не мав. Твердження лінії, що її gate пройдено, перевіряється запуском цього gate.
- Запис того, хто що зробив. Кожен запис делегування називає обліковий запис і постачальника лінії, тож батьківський план показує, який обліковий запис виконав яку роботу.
- Лейни Codex називають свою панель. Codex виконує команди лейна з фонового сервера, спільного для всіх сесій цього облікового запису, тож успадкований id панелі може належати іншому лейну. Лейн Codex передає власну панель, указану в завданні лідера, через
--pane <pane>у кожній команді herdr-peers (ask,reply,notify,check,wait,lanes,cancel).
Провідний агент може бачити весь оркестр одразу: herdr-peers lanes показує кожну лінію з її станом, а DeepWorkPlan Vim показує лінії плану-оркестратора поруч із самим планом (:DwpLanes).
Одна гілка, один реліз на репозиторій
Правило, яке зберігає можливість рецензувати багато ліній, просте: одна лінія на репозиторій, на його базовому checkout, з однією гілкою, одним pull request і одним релізом для всієї зміни. Лінія не розбиває свою роботу на кілька гілок чи worktree. Worktree потрібні лише тоді, коли двоє записувачів мусять ділити один репозиторій: кожен отримує власний, щоб кожен шлях мав одного записувача.
Pull request залишається відкритим, зеленим і позначеним міткою для рецензії до GO провідного агента. Тоді лінія зливає зміни, ставить тег і повідомляє тег назад.
Порядок релізів
Репозиторії залежать один від одного, тому їх випускають у порядку залежностей: спершу інструменти, потім те, що їх закріплює, потім документація, що описує результат, а потім споживачі, які його впроваджують. Провідний агент тримає порядок і надсилає GO по одному репозиторію за раз. Лінія, що закріплює реліз іншого репозиторію, чекає на його тег, перш ніж записати закріплення, тож жодне закріплення ніколи не вказує на реліз, якого не існує.
Контрольні точки
Батьківський план закривається на доказах, а не на звітах:
- Для кожної лінії. Gate кожної лінії проходить на її власній гілці, а рецензія її pull request чиста. Рецензія може бути окремою лінією: AI Diff Reviewer рецензує pull request кожної лінії, а з addon Dailybot кожна лінія сама звітує команді про свій прогрес.
- Для кожного релізу. Кожен тег існує й закріплює те, що потрібно наступному репозиторію.
- Інтеграція. Після останнього релізу контрольна точка запускає споживачів на випущених версіях і записує вердикт в
analysis_results/батьківського плану. - Фінальна рецензія. Перевірка безпеки охоплює все, що перетнуло межу, — насамперед облікові записи, токени й файли, надані контейнерам, — перш ніж батьківський план завершиться.
Безпека
- Ніколи не кладіть ключ, токен чи секрет в ask, prompt або лог; посилайтеся на змінні за назвою.
- Спільні ресурси отримують блокування: лінія бере його перед важким кроком, як-от збирання контейнера, і звільняє після.
- Відмова від дозволів, якщо її встановлено, перемагає для кожної лінії й кожного агента, якого запускає лінія.
- Лінія, яка не може продовжити, повідомляє про це як про заблоковану віху й зупиняється; рішення ухвалює провідний агент.
Коли закінчується обліковий запис або провідний агент
Довгий запуск переживає будь-який окремий обліковий запис. Починаючи з coding-agents-kit (v0.7.1) і herdr-peers (v0.3.2), лінія перевіряє власний запас на кожній межі завдання й передає свою роботу через пакет передавання, перш ніж її обліковий запис вичерпається, провідний агент передає лідерство або його замінює заступник, а до розробника доходять лише критичні питання. Розділ Автономія рою описує цикл, пакет передавання, наступництво й класи ескалації.