Skip to content
← Все главы

Глава 05

Архетипы репозитория

Прежде чем изменить хотя бы одну строку кода, агент принимает одно решение, которое определяет всё дальнейшее: что это за репозиторий? Архетип, который он выводит, задаёт границу, в рамках которой он будет рассуждать на протяжении всей работы: как проходит онбординг, насколько далеко простирается план и где хранится состояние. Ошибитесь — и агент очертит работу на неверной поверхности, что является самой распространённой причиной дрейфа на долгосрочных задачах. Определите правильно — и агент сможет работать автономно часами, потому что планы, онбординг и состояние будут соответствовать реальной форме кода.

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

Отдельный репозиторий

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

Характеристики:

  • Единая целостная кодовая база.
  • Планы изменяют файлы в этом репозитории.
  • Рабочее пространство .dwp/ живёт в корне репозитория.

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

Координирующий случай: репозиторий, задача которого — управлять другими репозиториями. Здесь единица работы — не файл, а дочерний репозиторий, поэтому планы могут порождать дочерние планы в суб-репозиториях, а онбординг читает реестр управляемых репозиториев хаба, а не единую кодовую базу. Агент рассуждает о границах и передаче управления — какой репозиторий владеет какой работой и как их состояние остаётся согласованным.

Характеристики:

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

Рабочее пространство агента

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

Ключевое понимание состоит в том, что harness — это рабочее пространство, не обязательно репозиторий. Каждый элемент, который DWP устанавливает в репозиторий — AGENTS.md, docs/, .agents/, .dwp/ — имеет прямой эквивалент в рабочем пространстве. Поверхность методологии отображается чисто: файлы постоянного контекста заменяют корневой AGENTS.md, директория навыков платформы заменяет .agents/, а папка .dwp/ в корне рабочего пространства остаётся без изменений. Меняется роль git. В репозитории git log несёт состояние и делает планы возобновляемыми между сессиями. В рабочем пространстве без git эту работу выполняет state.json — именно поэтому машиночитаемый слой состояния обязателен для рабочих пространств агента.

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

Характеристики:

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

Эвристика классификации

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

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

Чем различается онбординг

Архетип — это не косметический ярлык; он меняет то, что агент читает, что план может затрагивать и где фиксируется состояние.

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

Практический эффект в том, что агент отдельного репозитория рассуждает об одной кодовой базе от начала до конца, агент-оркестратор рассуждает о координации между репозиториями, а агент рабочего пространства рассуждает о непрерывности между сессиями — что было запланировано, что выполнено, что заблокировано и что следует дальше.

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