Przepływy pracy

Odczytuje automatyzacje przepływów pracy obiektu: przepływy pracy, pełny graf jednego przepływu, typy węzłów, których może używać graf, oraz wybrane szablony. Przed utworzeniem lub edycją grafu odczytaj node_types, aby każdy typ i parametr był prawidłowy w obiekcie.

Akcje:

• list: Lista przepływów pracy. Każdy przepływ z informacją, czy jest aktywny, jego opublikowaną wersją, liczbą uruchomień, ostatnim uruchomieniem i węzłami (id, name, type). Przepływy pracy marki i organizacji nie są wyświetlane.
• get: Pobranie przepływu pracy. Pełny graf wersji roboczej (węzły, połączenia, notatki, ustawienia) i meta: active, publishedVersionId oraz, po publikacji, publishedWorkflow, czyli graf, który jest teraz aktywny. Tylko przepływy pracy tego obiektu. Wymaga: workflowId.
• node_types: Typy węzłów. Pozycje palety z type, label, category, outputs (gałęzie) i inputSchema, czyli parametrami do uzupełnienia. available ma wartość false, z podaniem przyczyny, gdy obiekt nie ma modułu potrzebnego węzłowi. Narzędzia MCP są widoczne jako węzły mcp...
• templates: Szablony. Punkty wyjścia dla typowych automatyzacji, z risk i riskNote (co może pójść źle przy nieostrożnej publikacji), typami węzłów, wymaganymi modułami, dostępnością w tym obiekcie i grafem podglądu. Szablon zamienisz w graf za pomocą workflow_definitions_write instantiate_template.

Tworzy, edytuje, publikuje, zatrzymuje i usuwa automatyzacje przepływów pracy obiektu. Cykl tworzenia: odczytaj node_types za pomocą workflow_definitions_read, zbuduj graf (lub zacznij od instantiate_template), utwórz go jako wersję roboczą, wypróbuj za pomocą workflow_runs_write test (symulacja), a następnie opublikuj. Zmiany w wersji roboczej nigdy nie zmieniają aktywnej wersji, dopóki nie zostaną opublikowane.

Akcje:

• create: Utworzenie przepływu pracy. Zapisuje nową, nieaktywną wersję roboczą z pełnego grafu z co najmniej jednym węzłem; name domyślnie ma wartość "Untitled workflow". Problemy z walidacją są zwracane w errors ze szczegółami węzłów. Wymaga: nodes.
• update: Zapisanie wersji roboczej. Zastępuje całą wersję roboczą: wyślij każdy węzeł i każde połączenie, nie tylko zmiany. Aktywna wersja działa dalej, dopóki nie opublikujesz zmian. Problemy z walidacją są zwracane w errors ze szczegółami węzłów. Wymaga: workflowId, nodes.
• patch_meta: Zmiana nazwy. Zmienia tylko nazwę lub opis; graf i aktywna wersja pozostają bez zmian. changed ma wartość false, gdy oba już się zgadzają. Wymaga: workflowId.
• duplicate: Duplikowanie. Kopiuje przepływ pracy do nowej wersji roboczej o nazwie " (copy)" z nowymi identyfikatorami węzłów, nigdy nieopublikowanej ani nieaktywnej. Oryginał pozostaje nienaruszony. Wymaga: workflowId.
• delete: Usunięcie. Trwale usuwa przepływ pracy: wersję roboczą, opublikowane wersje, historię uruchomień i routing wyzwalaczy. set_active false zatrzymuje go, ale zachowuje; discard_draft tylko resetuje zmiany w wersji roboczej. Wymaga: workflowId. Prosi o potwierdzenie.
• discard_draft: Odrzucenie zmian w wersji roboczej. Przywraca wersję roboczą do ostatniej opublikowanej wersji, odrzucając zmiany wprowadzone od tego czasu. Aktywna wersja nigdy nie jest zmieniana; wymaga opublikowanej wersji. Wymaga: workflowId. Prosi o potwierdzenie.
• publish: Publikacja. Waliduje wersję roboczą, zapisuje ją jako aktywną wersję i włącza przepływ pracy, dzięki czemu jego wyzwalacze się uruchamiają, a akcje są wykonywane naprawdę. Trwające uruchomienia kończą się na starej wersji. Jeśli oczekujące kroki Delay miałyby zostać przeliczone, wynik ma code WAIT_RETARGET_CONFIRMATION_REQUIRED i impacts: wywołaj ponownie z confirmWaitRetargets i tymi impacts. Wymaga: workflowId. Prosi o potwierdzenie.
• set_active: Włączenie lub wyłączenie. active true ponownie włącza opublikowany przepływ pracy. active false go zatrzymuje: wyzwalacze przestają się uruchamiać, a oczekujące kroki Delay są anulowane, więc nigdy się nie zakończą. Nic nie jest usuwane. Najpierw prosi o potwierdzenie, chyba że przepływ jest już w tym stanie. Wymaga: workflowId, active. Może prosić o potwierdzenie.
• instantiate_template: Graf z szablonu. Zamienia szablon w graf gotowy do create: { name, description, nodes, connections } z nowymi identyfikatorami węzłów. Szablony celowo pozostawiają puste pola odbiorców, drzwi i godzin; najpierw je uzupełnij. Niczego nie zapisuje. Wymaga: templateId.
• generate: Generowanie grafu. Tworzy graf na podstawie polecenia w języku naturalnym za pomocą AI obiektu i zwraca { name, description, nodes, connections }, używając tylko prawidłowych typów węzłów. Przekaż workflow, aby poprawić istniejący; zwracany jest pełny poprawiony graf. Niczego nie zapisuje, ale zużywa kredyty AI obiektu. Wymaga: prompt. Prosi o potwierdzenie.

Historia uruchomień przepływu pracy, od najnowszych, oraz jedno uruchomienie krok po kroku. Użyj tego, aby sprawdzić, czy automatyzacja została uruchomiona, śledzić uruchomienie rozpoczęte za pomocą workflow_runs_write lub ustalić, który węzeł zawiódł i dlaczego.

Akcje:

• list: Lista uruchomień. Każde uruchomienie ze stanem, trybem (live lub test), skutkami ubocznymi, wyzwalaczem, osobą, która je rozpoczęła, czasami, liczbą kroków, węzłem, na który czeka, i ewentualnym błędem. Wymaga: workflowId.
• get: Pobranie uruchomienia. Stan uruchomienia oraz każdy krok po kolei, z danymi wejściowymi, wyjściowymi, notatką i błędem każdego węzła. Uruchomienia są asynchroniczne: uruchomienie z krokami Delay czeka, aż nadejdzie czas jego kontynuacji. Wymaga: workflowId, executionId.

Uruchamia, testuje, anuluje i ponawia uruchomienia przepływów pracy. Preferuj test, który uruchamia wersję roboczą z symulowanymi skutkami ubocznymi; run wykonuje opublikowany przepływ pracy naprawdę. Uruchomienia są asynchroniczne: śledź je za pomocą workflow_runs_read get.

Akcje:

• run: Uruchom teraz. Uruchamia opublikowany przepływ pracy z jego wyzwalacza ręcznego (custom.manualTrigger), z rzeczywistymi skutkami ubocznymi. Wyzwalacze harmonogramu, webhooków i zdarzeń uruchamiają się samodzielnie. Zwraca executionId uruchomienia i jego pierwszy stan. Wymaga: workflowId. Prosi o potwierdzenie.
• test: Test wersji roboczej. Uruchamia zapisaną wersję roboczą bez jej publikowania, rejestrowane jako uruchomienie testowe. Skutki uboczne są domyślnie symulowane: nic nie jest wysyłane ani przełączane, a każdy węzeł raportuje, co by zrobił. sideEffects live najpierw prosi o potwierdzenie. Wymaga: workflowId. Może prosić o potwierdzenie.
• cancel: Anulowanie oczekującego uruchomienia. Anuluje uruchomienie oczekujące na Delay: jego oczekiwania zostają zamknięte, a kolejne kroki nigdy się nie wykonają. Zakończonych uruchomień i uruchomień w trakcie kroku nie można anulować. Wymaga: workflowId, executionId. Prosi o potwierdzenie.
• retry: Ponowienie uruchomienia. Ponawia zakończone uruchomienie na podstawie zarejestrowanych danych wejściowych wyzwalacza, powiązane z oryginałem przez retryOf. published (domyślnie) ponownie uruchamia użytą wersję naprawdę i najpierw prosi o potwierdzenie; draft-test uruchamia bieżącą wersję roboczą w symulacji, co jest właściwym wyborem podczas naprawiania błędu. Wymaga: workflowId, executionId. Może prosić o potwierdzenie.