Включение
Workboard входит в комплект поставки, но по умолчанию отключён:- Откройте Plugins в интерфейсе управления или перейдите по адресу
/settings/pluginsотносительно настроенного базового пути интерфейса управления. Например, для базового пути/openclawиспользуется/openclaw/settings/plugins. - Найдите Workboard и выберите Enable. Поскольку Workboard входит в состав OpenClaw, действие Install не требуется.
- Если интерфейс сообщает, что требуется перезапуск, перезапустите Gateway.
/workboard, когда плагин отключён или заблокирован параметрами
plugins.allow/plugins.deny, вместо данных карточек отображается состояние
недоступности плагина.
Эквивалентный рабочий процесс в CLI:
Конфигурация
У Workboard нет конфигурации, специфичной для плагина. Включайте и отключайте его с помощью стандартной записи плагина:Поля карточки
Карточки также содержат компактные метаданные о попытках, комментариях, ссылках, подтверждениях,
артефактах, настройках автоматизации, вложениях, журналах исполнителей, состоянии протокола
исполнителя, заявках, диагностике, уведомлениях, идентификаторе шаблона, состоянии архива и
обнаружении устаревших сеансов, а также список недавних событий (
created, edited,
moved, linked, specified, decomposed, claimed, heartbeat,
execution_updated, attempt_started, attempt_updated, comment_added,
link_added, proof_added, artifact_added, attachment_added,
diagnostic, notification, dispatch, orchestration,
protocol_violation, archived, unarchived, stale). Эти метаданные позволяют
оператору увидеть, как карточка перемещалась по доске, не открывая связанный
сеанс; это локальный операционный контекст, а не замена расшифровкам
сеансов или истории задач GitHub.
Плагин и интерфейс управления используют единый контракт карточки Workboard. Поэтому обновления панели управления
сохраняют происхождение и полномочия рабочей области, состояние заявки, диагностические
действия и порядковые номера уведомлений вместо создания уменьшенной
копии карточки только для интерфейса. Неизвестные виды диагностики, уровни серьёзности диагностики и
виды уведомлений игнорируются, пока обе поверхности не начнут их поддерживать; они никогда
не преобразуются в другое допустимое состояние.
Открытая панель управления обновляется при аннулировании данных plugin.workboard.changed. Каждое
событие содержит только эпоху и ревизию хранилища; затем интерфейс повторно считывает канонические
карточки через обычный RPC operator.read. Несколько ревизий объединяются в
одно последующее считывание. Workboard откладывает это считывание, пока карточку перетаскивают,
редактируют или записывают, а затем возобновляет его после завершения локального взаимодействия.
При повторном подключении всегда выполняется каноническая перезагрузка. Регулярный полный опрос
карточек отсутствует, а Refresh остаётся доступной для ручного восстановления.
Если существует несколько досок, панель инструментов включает фильтр Board, основанный
на сохранённых метаданных досок, а не только на видимых в данный момент карточках. Поэтому пустые
и архивные доски остаются доступными для выбора. Карточки без явно заданного
идентификатора доски относятся к канонической доске default. Выбранная доска сохраняется
в параметре запроса ?board=, поэтому URL-адрес отфильтрованной доски Workboard можно добавить в закладки
или предоставить другим пользователям; при выборе All boards параметр удаляется.
Карточки хранятся в собственном состоянии Gateway плагина и перемещаются вместе с остальной частью
состояния OpenClaw этого Gateway (см. раздел Хранилище).
Запуск работы из карточки
Из карточек без связей можно запустить работу напрямую:- Run Codex / Run Claude запускает отслеживаемый как задача запуск агента с
явно заданным движком, отправляет запрос карточки и присваивает карточке состояние
running. Запуски Codex используютopenai/gpt-5.6-sol; запуски Claude используютanthropic/claude-sonnet-4-6. - Open Codex / Open Claude создаёт связанный сеанс панели управления без отправки запроса карточки или перемещения карточки — для ручной работы, которая остаётся привязанной к доске.
review или blocked по тому же правилу
синхронизации, что и связанные сеансы (см. Синхронизация жизненного цикла сеанса).
Инструменты агента
Назначенные карточки отклоняют изменения через инструменты агента от других агентов, если вызывающая сторона
не располагает токеном назначения, возвращённым
workboard_claim. В каждой карточке, возвращаемой
инструментом агента или вызовом RPC Gateway, значение metadata.claim.token заменяется на [redacted]
(сам токен возвращается один раз на верхнем уровне и только из workboard_claim),
поэтому операторы панели управления и другие агенты могут просматривать состояние назначения, никогда
не получая пригодный для использования токен. Восстановление выполняется через
workboard_promote/workboard_reassign/workboard_reclaim, для которых
токен не требуется.
Диспетчеризация
Диспетчеризация выполняется локально в Gateway: она не создаёт произвольные процессы ОС. Выполнением по-прежнему управляют обычные сеансы субагентов OpenClaw. Один проход диспетчеризации:- Продвигает карточки с готовыми зависимостями.
- Записывает метаданные диспетчеризации в готовые карточки.
- Блокирует истёкшие назначения или выполнения с превышенным временем ожидания.
- Помечает настроенные на доске карточки разбора как кандидатов на оркестрацию.
- Назначает небольшую группу готовых карточек и запускает исполнителей через среду выполнения субагентов Gateway.
operator.write могут использовать настроенные рабочие пространства агентов;
клиенты operator.admin могут использовать другие рабочие копии на хосте. Инструменты агентов в песочнице используют
доступ к рабочему пространству своей песочницы, а инструменты без песочницы, ограниченные рабочим пространством, используют
настроенный корень рабочего пространства. Workboard записывает эти полномочия при назначении рабочего пространства
и при диспетчеризации снова пересекает их с текущими полномочиями вызывающей стороны,
поэтому сохранённая карточка не может расширить доступ последующей вызывающей стороны. Для старых карточек с
явно заданным рабочим пространством хоста, но без записанных полномочий, необходимо повторно сохранить это рабочее пространство
перед диспетчеризацией с полным доступом к хосту; карточки без пути на хосте принимают
полномочия текущей вызывающей стороны при первой диспетчеризации.
Диспетчеризация, привязанная к рабочему пространству, принимает каталог или рабочую копию Git, только если корень
репозитория точно соответствует целевому рабочему пространству агента. Запрос рабочего дерева
ограничивается этим каталогом и сохраняется как рабочее пространство-каталог, поэтому
хост не создаёт рабочую копию и не выполняет код настройки репозитория. Целевой
исполнитель должен использовать доступную для записи, необщую песочницу Docker именно для этого
рабочего пространства, без выполнения с повышенными привилегиями, сохранённых переопределений выполнения на хосте/Node, а также
неклассифицированных инструментов плагинов и MCP. Workboard перечисляет зарегистрированные инструменты
вместо доверия префиксу workboard_*, а диспетчеризация отклоняет активный контейнер Docker,
если хеш его текущего подключения/конфигурации устарел. Диспетчеризация сообщает о
несовместимой политике целевой среды вместо запуска исполнителя с менее строгими ограничениями.
Диспетчеризация с полным доступом к хосту может использовать другие локальные рабочие копии и сохраняет обычную настройку
управляемого рабочего дерева.
Полномочия рабочего пространства не создают вторую модель разрешений жизненного цикла карточек.
Вызывающие стороны, которым разрешено изменять карточки Workboard, могут вручную переводить их между теми же
статусами на любой поверхности; доступ к рабочему пространству только для чтения предотвращает лишь
диспетчеризацию исполнителей, требующую записи.
Выбор исполнителей
Каждый проход по умолчанию запускает не более 3 исполнителей. Готовые карточки упорядочиваются по приоритету, затем по позиции, затем по времени создания. За один проход запускается только одна карточка для каждого владельца/агента; владельцы, у которых на доске уже есть выполняемая или проверяемая работа, пропускаются. Архивированные карточки, карточки с активным назначением и карточки не в статусеready
никогда не выбираются для запуска исполнителей (на них по-прежнему может влиять
часть диспетчеризации, работающая с данными: очистка устаревших назначений, продвижение зависимостей, очистка
по превышению времени ожидания).
Ключи сеансов детерминированы для каждой пары доски/карточки, поэтому повторная диспетчеризация направляет
работу обратно в ту же линию исполнителя, а не создаёт несвязанные сеансы:
- Назначенные карточки:
agent:<agentId>:subagent:workboard-<boardId>-<cardId> - Неназначенные карточки:
subagent:workboard-<boardId>-<cardId>(Gateway определяет настроенного агента по умолчанию)
Точки входа
- Действие диспетчеризации на панели управления
openclaw workboard dispatch/workboard dispatchв канале с поддержкой команд
unknown method для более старых
версий Gateway), при этом не задана явная цель --url/--token и не применяется настроенный удалённый
Gateway (OPENCLAW_GATEWAY_URL или gateway.mode: remote), CLI выполняет
диспетчеризацию только данных на основе локального состояния SQLite — он может активировать зависимости,
очищать устаревшие заявки и блокировать запуски с истёкшим временем ожидания, но не может запускать исполнителей. Ошибки аутентификации,
разрешений и валидации от доступного Gateway не считаются
ошибками недоступности; они отображаются как ошибки команд, как и любая ошибка
Gateway, если была задана явная цель --url/--token.
В метаданных доски можно задать autoDecompose, autoDecomposePerDispatch,
defaultAssignee и orchestratorProfile. OpenClaw записывает это намерение и
передаёт его в контекст исполнителя; фактическое составление спецификации и декомпозиция по-прежнему выполняются
через обычные инструменты Workboard.
CLI и слеш-команда
list по умолчанию скрывает архивные карточки (--include-archived
отменяет это поведение); --json всегда включает архивные карточки в соответствии с контрактом
полного набора карточек, который используют существующие скрипты. show и move принимают однозначный
префикс идентификатора. list, create, show и move всегда напрямую читают и записывают локальное
состояние плагина. Только dispatch обращается к работающему Gateway с резервным вариантом,
описанным выше.
Полное описание флагов, вывода JSON, резервного поведения Gateway,
обработки префиксов идентификаторов, правил выбора при диспетчеризации и
устранения неполадок см. в разделе CLI Workboard.
/workboard list, /workboard show <card-id>, /workboard create <title>,
/workboard move <card-id> --status <status> и /workboard dispatch соответствуют
CLI. Операции просмотра списка и отдельной карточки доступны любому авторизованному отправителю команд.
Создание, перемещение и диспетчеризация требуют статуса владельца в интерфейсах чатов либо клиента Gateway
с operator.write/operator.admin. Перемещения, выполняемые оператором вручную, используют
то же поведение переопределения заявки, что и перетаскивание на панели управления. Доступ таких операций к рабочему дереву
по-прежнему ограничивается описанной выше границей рабочего пространства.
Синхронизация жизненного цикла сеанса
Карточки можно связать с существующим сеансом панели управления или с сеансом, созданным при запуске работы из карточки. В связанных карточках состояние жизненного цикла сеанса отображается непосредственно: выполняется, устарел, связан и простаивает, завершён, завершён с ошибкой или отсутствует. Существующий сеанс также можно добавить на вкладке Sessions с помощью Add to Workboard; карточка будет связана с этим сеансом, получит в качестве заголовка метку сеанса или недавний запрос пользователя, а её заметки будут заполнены недавним запросом пользователя и последним ответом ассистента, если они доступны. Если связанный сеанс пропадает, карточка сохраняет связь для контекста и по-прежнему предоставляет элементы управления запуском, чтобы перезапустить работу в новом сеансе. Если активный связанный сеанс перестаёт сообщать о недавней активности, Workboard помечает карточку какstale и сохраняет эту отметку в метаданных, пока жизненный цикл её не удалит.
Пока карточка находится в активном рабочем состоянии, Workboard следует за связанным сеансом:
Состояния ручной проверки имеют приоритет. Перемещение карточки в
review, blocked или done
останавливает её автоматическую синхронизацию, пока она не будет возвращена в todo или running.
При запуске карточки используются обычные сеансы Gateway; Workboard хранит только
метаданные и связи карточки. Стенограмма разговора, выбор модели и жизненный цикл
запуска остаются в ведении обычной системы сеансов. Чтобы прервать активный запуск, используйте Stop на работающей
связанной карточке — Workboard пометит её как blocked, чтобы
она оставалась видимой для последующих действий.
Новые карточки можно создавать на основе шаблонов Workboard (bugfix, docs, release,
pr_review, plugin). Шаблоны предварительно заполняют заголовок, заметки, метки и приоритет;
идентификатор шаблона сохраняется в метаданных карточки.
Рабочий процесс на панели управления
- Откройте вкладку Workboard в Control UI.
- Создайте карточку, указав заголовок, заметки, приоритет, метки, необязательного агента и необязательный связанный сеанс, либо откройте Sessions и выберите Add to Workboard для существующего сеанса.
- Перетащите карточку между столбцами либо переведите фокус на компактный элемент управления её статусом и используйте меню или клавиши ArrowLeft/ArrowRight. Во время перетаскивания исходная карточка становится полупрозрачной, а доступные для перемещения столбцы выделяются контуром.
- Запустите работу из карточки, чтобы создать или повторно использовать сеанс панели управления.
- Откройте связанный сеанс из карточки, пока агент работает.
- Позвольте синхронизации жизненного цикла переместить выполняемую работу в
review/blocked, затем вручную переместите карточку вdoneпосле принятия результата.
Диагностика
Диагностика вычисляется на основе локальных метаданных карточек. Встроенные проверки выявляют:Разрешения
Методы RPC Gateway находятся в пространствеworkboard.*:
Ни один метод RPC не требует
operator.admin. Браузеры, подключённые с доступом оператора
только для чтения, могут просматривать доску, но не могут изменять карточки. Область администратора
расширяет набор допустимых путей хоста Workboard; она не меняет доступные методы.
Хранилище
Workboard хранит долговременные данные в принадлежащей плагину реляционной базе данных SQLite в каталоге состояния OpenClaw: доски, карточки, метки, события жизненного цикла, попытки запуска, комментарии, связи зависимостей, подтверждения, ссылки на артефакты, метаданные и двоичные данные вложений, диагностика, уведомления, журналы исполнителей, состояние протокола и подписки хранятся в таблицах Workboard (а не в записях хранилища пар «ключ — значение» плагина). Экспорт карточки сохраняет историю доски, не включая в неё содержимое двоичных данных вложений. В установках, где Workboard использовался в выпуске.28, можно выполнить
openclaw doctor --fix, чтобы перенести поставлявшиеся пространства имён устаревшего состояния плагина
(workboard.cards, workboard.boards, workboard.notify и, при наличии,
workboard.attachments) в реляционную базу данных.
Устранение неполадок
На вкладке указано, что Workboard недоступенplugins.allow, добавьте в него workboard. Если plugins.deny
содержит workboard, удалите его перед включением плагина.
Карточки не сохраняются
Убедитесь, что подключение браузера имеет доступ operator.write. Сеансы оператора
только для чтения могут просматривать список карточек, но не могут создавать, редактировать, перемещать или удалять их.
При запуске карточки не открывается ожидаемый сеанс
Проверьте идентификатор агента и связанный сеанс карточки, затем откройте Sessions или Chat,
чтобы проверить фактическое состояние запуска.
Диспетчеризация не запускает исполнителя
Убедитесь, что существует хотя бы одна карточка ready без активной заявки: