Skip to main content
openclaw workboard to interfejs terminalowy dołączonego pluginu Workboard. Umożliwia operatorowi wyświetlanie kart, tworzenie karty, sprawdzanie pojedynczej karty oraz zlecanie działającemu Gatewayowi przekazania gotowej pracy do uruchomień subagentów roboczych. Przed użyciem polecenia należy włączyć plugin:

​
Użycie

Polecenie odczytuje i zapisuje tę samą należącą do pluginu bazę danych SQLite, której używają pulpit i narzędzia agenta Workboard. Identyfikatory kart są identyfikatorami UUID; polecenia przyjmujące identyfikator karty akceptują również jednoznaczny prefiks identyfikatora (zwarty tekst wyjściowy pokazuje pierwsze 8 znaków). Prawidłowe wartości status: triage, backlog, todo, scheduled, ready, running, review, blocked, done. Prawidłowe wartości priority: low, normal, high, urgent.

​
list

Tekst wyjściowy ma zwartą postać:
Kolumny zawierają prefiks identyfikatora, status, priorytet, identyfikator tablicy, opcjonalny identyfikator agenta oraz tytuł. Zwarty tekst wyjściowy domyślnie ukrywa zarchiwizowane karty, dzięki czemu CLI odpowiada /workboard list. Aby je wyświetlić, należy przekazać --include-archived. Dane wyjściowe JSON zawsze zachowują pełną listę kart, w tym karty zarchiwizowane, na potrzeby istniejącej automatyzacji.

​
create

create zapisuje bezpośrednio do stanu SQLite Workboard. Karta jest natychmiast widoczna na karcie Workboard w Control UI oraz dla narzędzi Workboard.

​
show

Tekst wyjściowy zawiera zwarty wiersz karty i notatki. Dane wyjściowe JSON zwracają pełny rekord karty, w tym metadane wykonania, próby, komentarze, łącza, dowody, artefakty, dzienniki procesów roboczych, stan protokołu, diagnostykę i metadane automatyzacji.

​
move

move zmienia status karty przy użyciu tej samej ścieżki ręcznej obsługi, co przeciąganie karty na pulpicie. Akceptuje pełny identyfikator karty lub jego jednoznaczny prefiks. Aktywne blokady wynikające z zależności i harmonogramu nadal obowiązują. Operatorzy mogą przenieść przejętą kartę bez tokenu przejęcia jej agenta; tokeny przejęcia pozostają ograniczone do modyfikacji wykonywanych przez narzędzia agenta i są redagowane w danych wyjściowych JSON.

​
dispatch

dispatch najpierw wywołuje metodę RPC workboard.cards.dispatch działającego Gatewaya, która używa tego samego środowiska wykonawczego subagentów co czynność wysyłania na pulpicie, dzięki czemu gotowe karty stają się śledzonymi zadaniami uruchomieniami procesów roboczych z powiązanymi kluczami sesji. --max-starts używa addytywnej metody workboard.cards.dispatchWithOptions, aby starszy Gateway odrzucił opcję przed uruchomieniem jakichkolwiek procesów roboczych; przed użyciem flagi po aktualizacji należy ponownie uruchomić Gateway. Karty z przypisanym agentem używają kluczy sesji subagenta ograniczonych do agenta; nieprzypisane karty zachowują klucz subagenta bez takiego ograniczenia, dzięki czemu skonfigurowany domyślny agent Gatewaya zostaje zachowany. Pętla wysyłania:
  1. Przenosi elementy podrzędne z gotowymi zależnościami do ready.
  2. Blokuje wygasłe przejęcia lub uruchomienia procesów roboczych, które przekroczyły limit czasu.
  3. Rejestruje metadane wysyłania na gotowych kartach.
  4. Wybiera niewielką partię nieprzejętych gotowych kart.
  5. Przejmuje każdą wybraną kartę dla dyspozytora lub przypisanego agenta.
  6. Uruchamia subagenta roboczego z ograniczonym kontekstem karty i tokenem przejęcia karty.
  7. Zapisuje na karcie identyfikator uruchomienia procesu roboczego, klucz sesji, powiązanie z zadaniem, gdy zgłosi je rejestr zadań Gatewaya, status wykonania oraz dziennik procesu roboczego.
Wybór jest zachowawczy: pojedyncze wysłanie domyślnie uruchamia najwyżej trzy procesy robocze, pomija zarchiwizowane lub już przejęte karty i w jednym przebiegu uruchamia tylko jedną kartę na właściciela lub agenta. Karty należące już do aktywnej pracy w toku lub przeglądzie pozostają do późniejszego wysłania. Aby zmienić limit na przebieg, należy przekazać --max-starts <count> z dodatnią liczbą całkowitą; reguła jednej karty na właściciela nadal obowiązuje, więc rzeczywista liczba uruchomień może być niższa. Jeśli uruchomienie procesu roboczego nie powiedzie się po przejęciu karty, Workboard blokuje tę kartę, usuwa przejęcie i rejestruje błąd w metadanych wykonania karty oraz dziennika procesu roboczego, dzięki czemu nieudane uruchomienia pozostają widoczne zamiast po cichu zwracać kartę do kolejki. Jeśli nie podano jawnego celu Gatewaya, a lokalny Gateway jest niedostępny lub nie udostępnia jeszcze metody wysyłania Workboard, CLI przechodzi na wysyłanie wyłącznie danych względem lokalnego stanu Workboard. Wysyłanie wyłącznie danych nadal może promować zależności, usuwać nieaktualne przejęcia i blokować uruchomienia, które przekroczyły limit czasu, ale nie uruchamia procesów roboczych. Błędy uwierzytelniania, uprawnień i walidacji oraz błędy jawnego celu --url lub --token są zgłaszane bezpośrednio zamiast uruchamiania mechanizmu rezerwowego. Tekst wyjściowy zgłasza uruchomienia procesów roboczych:
Dane wyjściowe mechanizmu rezerwowego są jednoznaczne:
Dane wyjściowe JSON zawierają wynik wysyłania. Wysyłanie obsługiwane przez Gateway może zawierać started i startFailures; mechanizm rezerwowy działający wyłącznie na danych zawiera gatewayUnavailable: true. Tokeny przejęcia są redagowane w danych wyjściowych JSON karty. Na pulpicie ten sam wynik wysyłania jest wyświetlany jako krótkie podsumowanie, dzięki czemu operator może bez otwierania szczegółów karty zobaczyć, ile kart uruchomiono, przeniesiono, zablokowano, odzyskano lub zakończono błędem.

​
Zgodność poleceń ukośnikowych

Kanały obsługujące polecenia mogą używać odpowiadającego polecenia ukośnikowego:
Wysyłanie za pomocą polecenia ukośnikowego również używa środowiska wykonawczego subagentów Gatewaya, więc stosuje takie same zasady przejmowania, uruchamiania procesów roboczych i obsługi błędów jak ścieżka Gatewaya w pulpicie i CLI. /workboard list i /workboard show są poleceniami odczytu dla autoryzowanych nadawców poleceń. /workboard create, /workboard move i /workboard dispatch modyfikują stan tablicy i wymagają statusu właściciela w interfejsach czatu albo klienta Gatewaya z operator.write lub operator.admin.

​
Uprawnienia

Ścieżka wysyłania CLI zwykle żąda zakresów Gatewaya operator.write i operator.read. Karty powiązane z obszarem roboczym są uruchamiane bezpośrednio w dokładnie skonfigurowanym obszarze roboczym agenta; żądanie drzewa roboczego jest zawężane do tego katalogu zamiast zezwalać hostowi na materializację kodu kontrolowanego przez repozytorium. Wybrany proces roboczy musi mieć zapisywalny, niewspółdzielony dostęp do piaskownicy Docker dokładnie dla tego obszaru roboczego, aktywny skrót kontenera zgodny z wymaganymi punktami montowania i zasadami oraz nie może mieć możliwości wydostania się na hosta. Należy przekazać --admin, aby jawnie zażądać operator.admin, zezwolić na inne pobranie repozytorium na hoście i użyć standardowej konfiguracji zarządzanego drzewa roboczego; połączenie nie powiedzie się, jeśli ten zakres nie zostanie zatwierdzony dla klienta. Token Gatewaya tylko do odczytu może sprawdzać dane Workboard za pomocą metod odczytu, ale nie może tworzyć kart ani wysyłać procesów roboczych. Poza tym ograniczenia obszaru roboczego nie zmieniają ręcznego przenoszenia kart przez wywołujących mających uprawnienie do modyfikowania Workboard. Lokalne polecenia list, create, show i move działają na lokalnym katalogu stanu OpenClaw używanym przez bieżący profil. Gdy potrzebny jest inny katalog główny stanu, należy użyć --dev lub --profile <name> w poleceniu najwyższego poziomu openclaw.

​
Rozwiązywanie problemów

​
Nie pojawiają się żadne karty

Należy potwierdzić, że plugin jest włączony dla tego samego profilu i katalogu głównego stanu:
Jeśli pulpit pokazuje karty, ale CLI ich nie pokazuje, należy sprawdzić, czy oba polecenia używają tego samego ustawienia --dev lub --profile.

​
Wysyłanie zgłasza tryb wyłącznie danych

Należy uruchomić lub ponownie uruchomić Gateway:
Następnie należy ponowić openclaw workboard dispatch. Mechanizm rezerwowy działający wyłącznie na danych jest przydatny do czyszczenia stanu lokalnego, ale uruchomienia procesów roboczych wymagają aktywnego Gatewaya.

​
Wysyłanie niczego nie uruchamia

Należy sprawdzić, czy istnieje co najmniej jedna karta ready bez aktywnego przejęcia:
Karty mogą być również pomijane, gdy ten sam właściciel ma już pracę w toku lub w przeglądzie. Należy przenieść ukończoną pracę do done, zwolnić nieaktualne przejęcia za pomocą narzędzi Workboard albo ponownie uruchomić wysyłanie po zakończeniu pracy przez aktywny proces roboczy.

​
Powiązane materiały