Oh My Subagents сохраняет работу команд Claude Code

Oh My Subagents, локальный рантайм с открытым кодом для субагентов Codex и Claude, представленный 1 сентября, хранит делегирование от родительского агента к дочерним в базе контроллера. Поэтому работа не теряется, если закрыть терминал, если оборвётся сессия у провайдера или перезапустится сам контроллер.

В README проекта на GitHub авторы описывают проблему так. Делегировать «на ходу» начать легко, а сопровождать такую работу неожиданно трудно. Родитель запускает дочерних агентов и опрашивает их, по переписке восстанавливает, кто за что отвечал, и надеется, что закрытый терминал или прерванная сессия провайдера не стёрли единственный внятный отчёт о том, что произошло. Раздел с этим описанием так и называется: «Хватит нянчиться с субагентами».

Волна и ожидание родителя

Штатные субагенты устроены проще. В Claude Code субагент работает как отдельный экземпляр Claude со своим контекстным окном: получает задачу, делает работу и возвращает только результат. Codex, как сказано в его документации, запускает специализированных агентов параллельно и собирает их результаты в один ответ. OMS забирает эту координацию себе.

Делегирование в OMS идёт волнами (Wave). Агент с подчинёнными, в терминах проекта Manager, делегирует волну дочерних заданий (Assignments), и контроллер записывает их в базу вместе с отметкой о том, что родитель ждёт. Дети возвращают итоговые Checkpoints независимо друг от друга. Контроллер собирает всю волну и продолжает родителя сразу со всеми ответами, в том числе если в промежутке что-то упало. Родитель при этом не крутится в цикле опроса.

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

В README разобран прогон с исправлением бага. Собранные доказательства определяют, какой будет следующая волна, замечания ревьюера превращаются в новое задание на исправление, а проверка остаётся независимой.

Кто отвечает за Result

Завершение работы у провайдера OMS успехом не считает. Готовность дочернего агента для родителя служит лишь доказательством, а итогом, который видит пользователь, становится только принятый Checkpoint руководителя задачи (Task lead) со статусом completed или blocked.

Остальные правила авторы называют контрактом рантайма:

• каждая задача закрепляет точную опубликованную ревизию Workflow, с которой стартовала;
• у каждого Assignment один владелец; дочернее задание неизменяемо и привязано к участнику, который должен его вернуть;
• волны, ожидания, повторы, перепланирования и продолжения живут в состоянии контроллера, не только в транскрипте провайдера;
• закрытый браузер, прерванный провайдер или перезапуск контроллера не дорисовывают завершение задним числом и не выбрасывают уже принятую историю.

Файлы остаются обычными файлами. Заметки, отчёты, код и артефакты лежат в рабочем каталоге, а OMS хранит только небольшие ссылки для навигации и не делает снимков каждого байта. Огромные ответы через чат тоже не гоняют: дочерний агент сдаёт короткий Checkpoint с явными ссылками на файлы.

Права в OMS по умолчанию запрещены и от родителя не наследуются. Провайдер, модель, песочница, запросы к человеку (Human Request) и управляемые запуски команд (Command Run) задаются явно там, где команде это нужно. Обязательной церемонией для каждого Workflow это, по словам авторов, не становится.

Ответственность вместо расписания

Workflow в OMS отвечает на вопрос «кто отвечает», но не задаёт, когда участник запускается, и не загоняет работу в DAG (граф шагов с заранее заданным порядком). Схему выбирают Managers во время прогона, исходя из задачи и собранных доказательств: зависимую работу ведут последовательно, независимую раскидывают параллельно, гоняют цикл «реализация, ревью, исправление», делят ограниченную пачку между постоянными исполнителями или смешивают всё это в одной задаче. Если команда перестала подходить, можно перепланировать одно поддерево ответственности. Будущая работа меняется, а прежние ревизии, сделанное и принятая история остаются как были.

Одна и та же опубликованная команда поэтому может по-разному отработать две разные задачи. Для старта oms init публикует восемь готовых команд (Starters), не привязанных к провайдеру. Среди них incident-investigation-and-recovery для серьёзных или плавающих сбоев с конкурирующими гипотезами, migration-and-modernisation для больших миграций с инвентаризацией, пакетами по зависимостям и удалением устаревших путей, decision-through-competing-prototypes, где альтернативы проверяют по одной общей рубрике, и security-audit-and-hardening с повторной состязательной проверкой исправлений.

Авторы сами предупреждают, что большая команда нужна не всегда. Workflow из одного участника, по их словам, «допустим и обычно разумнее», когда делегирование добавило бы церемоний без независимых доказательств, полезной специализации или реальной интеграции. Есть и денежная сторона: в документации Codex прямо сказано, что сценарии с субагентами тратят больше токенов, чем сопоставимый прогон одним агентом, потому что каждый субагент сам обращается к модели и инструментам.

Консоль и Operator

Основной интерфейс OMS - визуальная Console. В Workflow Studio дерево ответственности собирают на горизонтальном холсте, проверяют и публикуют. Run Studio показывает живую команду, текущие планы, Activity, запросы к человеку, управляемые действия, файлы, на которые есть ссылки, и итоговый Result. Через Steering можно передать ограниченный новый контекст одному конкретному активному участнику, при этом уже сделанная работа и последствия вызванных инструментов из истории не исчезают.

Для тех, кому удобнее чат, есть отдельный Operator. Он умеет составлять и править Workflows, объяснять устройство команд, публиковать по запросу, запускать прогоны и управлять ими, отвечать на Human Requests. Operator и визуальный интерфейс вызывают одни и те же операции контроллера, поэтому чат не заводит вторую скрытую копию состояния.

Проект распространяется под MIT, кроме каталога console/: в нём есть материал, производный от n8n, и он идёт под Sustainable Use License. Она разрешает внутреннее использование в бизнесе, некоммерческое и личное, а распространять этот код можно только бесплатно и некоммерчески.

Как поставить

Нужен Python 3.12 или новее. Поддерживаются Linux, macOS 13+ и Windows 11 x64. Ставить авторы советуют в изолированное окружение через pipx:

• pipx install oh-my-subagents
• oms init
• oms service install

После этого консоль открывается по адресу http://127.0.0.1:18125/. Мастер инициализации выбирает рабочий каталог по умолчанию, настраивает Codex или Claude как провайдера задач, публикует Starters и при желании подключает Operator. По умолчанию используется SQLite, так что отдельный сервер базы данных для локальной установки не нужен. PostgreSQL опционален: ставится пакет oh-my-subagents[postgres], а при инициализации передаётся SQLAlchemy URL через --database-url.

oms service install проверяет конфигурацию и схему базы, регистрирует фоновую службу для текущего пользователя и запускает её. На Linux это пользовательская служба systemd, на macOS LaunchAgent, на Windows задача в планировщике. Контроллер продолжает следить за работой после закрытия терминала и поднимается при входе в систему. oms service uninstall убирает только определение службы, а конфигурация, база и учётные данные провайдеров остаются. Если служба не нужна, есть oms serve, который работает на переднем плане.

Для существующих установок Banksia предусмотрена миграция. Сначала pipx uninstall banksia и установка нового пакета, затем oms migrate-from-banksia и oms db upgrade. Миграция переносит конфиг, базу, учётные данные, историю задач и состояние службы в канонические пути OMS, а oms init создаёт новую базу контроллера. Поэтому авторы прямо предупреждают: не запускать oms init первым и не использовать oms db reset как способ переименования.