Skip to content
← Усі розділи

Розділ 05

Архетипи репозиторіїв

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

DWP розрізняє три архетипи. Більшість репозиторіїв належать до першого; другий існує для команд, що координують багато репозиторіїв; третій охоплює довготривалі робочі простори автономних агентів.

Окремий репозиторій

Типовий випадок: самодостатня кодова база — застосунок, бібліотека чи сервіс. Є єдина цілісна поверхня для розмірковування, тому плани діють безпосередньо на код у репозиторії, а онбординг читає власну структуру й домовленості репозиторію. Агент утримує всю кодову базу як свій контекст і опрацьовує її від початку до кінця.

Ознаки:

  • Єдина цілісна кодова база.
  • Плани змінюють файли в цьому репозиторії.
  • Робочий простір .dwp/ живе в корені репозиторію.

Хаб-оркестратор

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

Ознаки:

  • Координує кілька суб-репозиторіїв.
  • Плани можуть делегувати дочірнім планам.
  • Веде реєстр керованих репозиторіїв.
  • Робочий простір .dwp/ у корені хабу відстежує стан між репозиторіями.

Робочий простір агента

Третій архетип, доданий у v2.2, описує те, що є простором перш ніж репозиторієм: довготривала домівка автономного агента. Робочий простір OpenClaw, службовий каталог Hermes, каталог даних демона-персонального-помічника, постійний том хмарного агента — кожен має плани для виконання, інструменти для використання та пам’ять для підтримки, але може не мати кодової бази для постачання.

Ключова ідея: harness — це простір, а не конкретно репозиторій. Кожен елемент, що DWP встановлює у репозиторій — AGENTS.md, docs/, .agents/, .dwp/ — має прямий еквівалент у просторі. Поверхня методології відображається чисто: файли постійного контексту замінюють кореневий AGENTS.md, каталог скілів платформи замінює .agents/, а папка .dwp/ у корені простору залишається незмінною. Змінюється роль git. У репозиторії журнал git несе стан і робить плани відновлюваними між сесіями. У просторі без git цю роботу виконує state.json — саме тому машиночитаний рівень стану є обов’язковим для робочих просторів агентів.

Практична вигода — автономні нічні плани. На платформах класу OpenClaw heartbeat або cron-поворот прокидає агента, запускає протокол відновлення DWP, виконує наступне атомарне завдання, оновлює state.json і поступається. Одиницею неперервності є план, а не сесія. Багатоденний план виживає після перезапусків, заміни моделей та меж сесій, бо все, що потрібно наступному повороту, знаходиться у файлах плану: мета, відмічений прогрес, записи gate та точний checkpoint всередині поточного завдання.

Ознаки:

  • Робочий каталог автономної агентної платформи.
  • AGENTS.md, .agents/ та .dwp/ у корені простору.
  • Git є рекомендованим, але не обов’язковим.
  • state.json є обов’язковим, коли git відсутній, і для будь-якого автономного запуску.
  • Плани зазвичай виконуються автономно, керованими запланованим heartbeat або cron.

Евристика класифікації

Три архетипи виглядають по-різному на диску, і агент вибирає між ними за сигналами, які він може перевірити, — а не за ярликом, який йому повідомили. Дерево рішень нижче показує шлях; коротко: класифікуйте як робочий простір агента, коли присутні сигнали ідентичності платформи, як хаб-оркестратор лише тоді, коли цього вимагають докази, а в іншому разі — як окремий репозиторій.

Агент має спочатку шукати сигнали робочого простору агента: файл ідентичності платформи (наприклад, SOUL.md або HEARTBEAT.md OpenClaw), відсутність основного стеку застосунку та вміст, що переважно є власним станом агента. Якщо їх немає, він шукає сигнали оркестратора: кілька вкладених git-репозиторіїв чи субмодулів, реєстр або маніфест керованих репозиторіїв або конфігурацію, що вказує на зовнішні репозиторії. За відсутності обох він вважає ціль окремим репозиторієм — безпечне значення за замовчуванням, адже надмірне розширення плану за межі, яких не існує, гірше, ніж робота в межах однієї, яка дійсно існує.

Чим відрізняється онбординг

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

Аспект Окремий Оркестратор Робочий простір агента
Обсяг Цей репозиторій Кілька репозиторіїв Простір та його плани
Онбординг Структура репозиторію Реєстр хабу Файли платформи + конвенції простору
Ціль плану Локальні файли Дочірні плани Локальні або зовнішні репозиторії
Стан Локальний .dwp/ Міжрепозиторний .dwp/ .dwp/ + state.json (обов’язковий без git)

Практичний наслідок такий: агент окремого репозиторію міркує про одну кодову базу від початку до кінця, агент-оркестратор міркує про координацію між репозиторіями, а агент робочого простору міркує про неперервність між сесіями — що було заплановано, що виконано, що заблоковано і що далі.

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