Twórz instrukcje workflow z agentem

Nie musisz pisać instrukcji workflow od zera. Zacznij od wykonania rzeczywistego zadania z agentem. Gdy wynik będzie przydatny, poproś agenta o przekształcenie wspólnie opracowanej metody w powtarzalny workflow.

Agent tworzy pierwszy szkic. Twoją rolą jest przejrzenie jego założeń i zdecydowanie, gdzie workflow wymaga jaśniejszych ograniczeń, aby inny członek zespołu mógł uzyskać wiarygodny rezultat.

Każdy workflow należy do jednego agenta. Agent określa szerszą rolę i możliwości; workflow zapisuje procedurę i ograniczenia dla jednego powtarzalnego zadania.

Zacznij od udanego uruchomienia

Workflow łatwiej utworzyć po tym, jak agent zobaczy zadanie, materiały źródłowe, Twoje uwagi i akceptowalny wynik.

1. Daj agentowi prawdziwe zadanie i rzeczywiste dane wejściowe, których potrzebuje.
2. Przejrzyj wynik i popraw brakujący kontekst, słabe rozumowanie lub niewłaściwy format.
3. Gdy wynik jest dobry, poproś agenta o wyodrębnienie powtarzalnej metody.
4. Poproś agenta o przygotowanie szkicu nazwy workflow, opisu, instrukcji oraz wszelkich plików referencyjnych, które rekomenduje.
5. Przejrzyjcie szkic razem przed upublicznieniem workflow.

Możesz zapytać:

Przekształć to, co właśnie zrobiliśmy, w powtarzalny workflow dla zespołu. Przygotuj szkic nazwy, opisu i instrukcji. Oddziel powtarzalną metodę od szczegółów dotyczących tylko tego przypadku. Zanim to zatwierdzimy, wypisz założenia i ograniczenia, które powinienem przejrzeć.

To daje agentowi zadanie przygotowania szkicu. Tobie pozostawia decyzję, które elementy muszą być kontrolowane.

Instrukcja to częste miejsce na ograniczenia

Instrukcja workflow towarzyszy workflow i obowiązuje przy każdym uruchomieniu. To jedno z najczęstszych miejsc definiowania ograniczeń, takich jak wymagane dane wejściowe, zatwierdzone źródła, format wyjściowy, standardy jakości i działania wymagające potwierdzenia.

To nie jedyna warstwa kontroli:

Nie polegaj na tekście instrukcji jako zamienniku kontroli dostępu. Jeśli działanie musi być technicznie ograniczone, użyj autoryzacji agenta i uprawnień oraz jasnej instrukcji.

Przejrzyj pierwszy szkic agenta

Nie musisz przepisywać każdego zdania. Skup się na decyzjach istotnych dla zespołu.

Kiedy powinien być używany?

• Jakie żądanie lub sytuacja powinna wybrać ten workflow?
• Kiedy agent nie powinien go używać?
• Czy opis jest wystarczająco precyzyjny, by odróżnić go od podobnych workflow?

Jakie dane wejściowe są wymagane?

• Co członek zespołu musi dostarczyć przed rozpoczęciem pracy?
• Jakie brakujące dane powinny skłonić agenta do zadania pytania?
• Które szczegóły dotyczą pojedynczego uruchomienia, a nie stałej instrukcji?

Które źródła i zasady mają pierwszeństwo?

• Jaki jest system źródłowy?
• Który załączony plik zawiera zatwierdzone kryteria lub szablon?
• Jeśli dwa źródła są sprzeczne, które ma pierwszeństwo?
• Jak agent powinien oznaczać fakty, których nie może zweryfikować?

Jak powinien wyglądać wynik?

• Jakie sekcje lub pola są wymagane?
• Jaki poziom szczegółowości jest przydatny?
• Czy wynik wymaga cytowań, linków lub etykiety pewności?
• Gdzie powinien trafić wynik, jeśli podano miejsce docelowe?

Gdzie agent musi się zatrzymać?

• Jakie działania wymagają potwierdzenia?
• Czy agent powinien utworzyć szkic zamiast wysyłać lub publikować?
• Jakie dane nie mogą pojawić się w publicznym workflow lub udostępnionym wyniku?

To są ograniczenia warte wyraźnego określenia. Pozwól agentowi sformułować treść, a następnie potwierdź, że odzwierciedla Twoje decyzje.

Struktura do wspólnego przeglądu

Agent może użyć poniższej struktury do pierwszego szkicu. Traktuj ją jako ramę do przeglądu, nie formularz do samodzielnego wypełnienia:

# Goal
State the single outcome this workflow must produce.

# Use this workflow when
Describe when to use it and any important exclusions.

# Required inputs
- List the information needed for a reliable result.
- Explain what to do when an input is missing.

# Sources and tools
- Name authoritative systems, documents, or attached files.
- Explain which source wins if information conflicts.
- Define how to handle facts that cannot be verified.

# Procedure
1. Verify the inputs and scope.
2. Gather the required evidence.
3. Apply the team's rules or rubric.
4. Produce the deliverable.
5. Check it against the quality bar.

# Output
Define the required sections, fields, format, and destination.

# Quality bar
- State what must be accurate, cited, complete, or consistent.
- Define what counts as done.

# Approval boundaries
- List actions that require confirmation.
- Specify when to create a draft instead of taking the final action.

W przypadku workflow o wysokim ryzyku lub znaczeniu potrzebne są bardziej szczegółowe zasady dotyczące źródeł, walidacji i akceptacji.

Przykład: współtworzenie workflow kwalifikacji leadów

Załóżmy, że prosisz agenta o zbadanie jednego nowego leada i przygotowanie odpowiedzi. Podczas uruchomienia poprawiasz wielkość firmy, wyjaśniasz, że CRM jest systemem źródłowym, stosujesz kryteria ICP zespołu i prosisz o krótszy e-mail.

Po zatwierdzeniu wyniku poproś agenta o przekształcenie rozmowy w workflow. Agent przygotowuje procedurę. Następnie dodajesz ograniczenia, które powinny obowiązywać także poza tym leadem:

• sprawdź CRM przed rozpoczęciem publicznego researchu;
• użyj załączonych kryteriów ICP do oceny;
• cytuj źródła dla wielkości firmy, lokalizacji i aktualnej roli;
• oznacz niezweryfikowany wymagany fakt jako Nieznany;
• zwróć Podsumowanie konta, Dowody, Wynik ICP, Ryzyka, Zalecany następny krok i Szkic odpowiedzi;
• utwórz szkic e-maila i nigdy nie wysyłaj go bez potwierdzenia.

Agent może teraz uwzględnić te decyzje w instrukcji. Nie musisz opisywać każdego kroku researchu. Musisz jasno określić źródła zespołu, kontrakt na wynik i granicę akceptacji.

Dawaj uwagi do ograniczeń prostym językiem

Możesz doprecyzować szkic, mówiąc agentowi, co musi się zmienić:

• „Poproś o rekord CRM przed rozpoczęciem, jeśli go brakuje.”
• „Traktuj CRM jako system źródłowy, gdy nazwy firm się różnią.”
• „Każde stwierdzenie w briefie musi mieć link do źródła.”
• „Odpowiedź ma mieć maksymalnie 150 słów, ale dostosuj ton do wiadomości przychodzącej.”
• „Utwórz e-mail jako szkic. Nigdy nie wysyłaj automatycznie.”
• „Ten workflow nie powinien działać dla istniejących szans.”

Poproś agenta o aktualizację workflow i podsumowanie, które ograniczenie dotyczy każdej zmiany. Ułatwia to wychwycenie źle zrozumianej zasady lub umieszczenia jej w niewłaściwej sekcji.

Zostaw właściwe rzeczy poza instrukcją

Niektóre informacje nie powinny stać się stałym tekstem workflow:

• nazwy klientów, jednorazowe terminy i miejsca docelowe dotyczące konkretnego przypadku należą do żądania uruchomienia;
• hasła, tokeny i prywatne dane uwierzytelniające nie powinny być w instrukcji ani załączniku;
• harmonogramy i wydarzenia należą do automatyzacji;
• techniczne granice dostępu należą do autoryzacji i uprawnień agenta;
• osobiste uwagi dotyczące tylko jednego wyniku mogą pozostać w tym czacie.

Instrukcja powinna zawierać powtarzalną metodę i ograniczenia zachowań, a nie każdy szczegół dotyczący pracy.

Testuj i udoskonalaj razem

Uruchom workflow z co najmniej dwoma realistycznymi danymi wejściowymi, najlepiej z drugim członkiem zespołu. Po każdym uruchomieniu zapytaj:

• Czy workflow aktywował się dla właściwego zadania?
• Czy poprosił o potrzebne dane wejściowe?
• Czy zastosował właściwy priorytet źródeł?
• Czy wynik był spójny, ale nie sztywny?
• Czy zatrzymał się na wymaganej granicy akceptacji?
• Czy problem jest powtarzalny, czy dotyczy tylko tego przypadku?

Poproś agenta o poprawienie instrukcji dla powtarzalnych luk. Jednorazowe poprawki zostaw w uruchomieniu. Gdy metoda działa także dla innych niż jej twórca, udostępnij workflow zespołowi.