Wzorzec

Orkiestracja rozmowy: state machine i guardrails

Tradycyjny, solidny sposób na przewidywalność rozmów z LLM: maszyna stanów, deterministyczne bramki oraz zaplanowany fallback. Szczególnie istotne, gdy asystent korzysta z narzędzi.

Czas czytania: ~15 min Aktualizacja: 2026-01-09
Rozszerzenie praktyczne

Operacyjny skrót

Ten rozdział należy do rodziny Projektowanie interakcji i ma formę Wzorzec. Poniższe dopowiedzenie ma jeden cel: przełożyć treść na działania, które da się wdrożyć, zmierzyć i utrzymać.

Checklista

  • Ustal cel i kryteria poprawności (co znaczy „dobry wynik”).
  • Zamknij format wyjścia (JSON / tabela / sekcje) i przygotuj walidację.
  • Ogranicz przestrzeń odpowiedzi: instrukcje, słownik terminów, limity.
  • Dodaj kontrolę jakości: self-check, sanity-checks, fallback, „no-answer”.
  • Zapisz jako szablon (prompt_template) i wersjonuj jak kod.
  • Wprowadź testy regresyjne (golden set) i przeglądy po zmianach.

Najczęstsze pułapki

  • Mieszanie instrukcji z danymi wejściowymi (brak separacji „co” vs „na czym”).
  • Format wynikowy „opisowy” bez kontraktu – brak automatycznej kontroli.
  • Zbyt ogólne polecenia („napisz mądrze”) bez parametrów i ograniczeń.
  • Brak strategii na niepewność: model zaczyna „zgadywać” zamiast eskalować.

Artefakty w Luage

prompt_template output_contract policy:language.standard trace_id golden_set

Standard działa dopiero wtedy, gdy ma właściciela, wersję, ślad (trace) oraz test regresyjny.

Szablon do skopiowania

Minimalny szablon promptu (do biblioteki)

prompt_template: support.reply@v3
intent: support.reply
inputs:
  - user_message
  - locale
constraints:
  - "Jeśli brak źródła → powiedz, że nie wiesz i poproś o doprecyzowanie"
output:
  format: markdown
  sections: ["Odpowiedź", "Co dalej"]

Traktuj szablon jak kod: owner, wersja, testy i przegląd. Wtedy to działa powtarzalnie.

W skrócie
  • rozmowa jako proces i stany
  • deterministyczne bramki w Engine
  • fallback: no‑answer / HITL / retry

Dlaczego state machine

Model językowy jest świetny w generowaniu treści, ale słaby w utrzymywaniu niejawnych reguł. Jeżeli rozmowa ma mieć przewidywalny przebieg (szczególnie z narzędziami), potrzebujesz mechanizmu, który tradycyjnie sprawdza się od dekad: maszyny stanów.

State machine rozmowy
Minimalny wzorzec stanów: intake → plan/execute → deliver z kontrolowanym fallbackiem i eskalacją.

Minimalny zestaw stanów

Dla większości asystentów wystarczą stany:

  • Intake — zrozumienie celu, zebranie danych wejściowych.
  • Plan — wybór strategii, narzędzi, ograniczeń.
  • Execute — wykonanie z bramkami (policy, DLP, ACL, timeouts).
  • Deliver — odpowiedź, cytowania, format, next steps.
  • Fallback — no‑answer, HITL, retry planowy.

Przejścia i bramki

Każde przejście ma warunek i log. Przykład (pseudo):

if missing_required_inputs:
  goto Intake (ask)
elif high_risk and not approved:
  goto Fallback (approval)
elif tools_required:
  goto Execute
else:
  goto Deliver
Kluczowe: bramki są deterministyczne. Model może proponować, ale decyzja o przejściu jest w silniku.

Integracja z narzędziami

  • Każde narzędzie ma kontrakt (schema, skutki uboczne, idempotency).
  • Execute uruchamia narzędzia z limitami i timeouts.
  • Wyniki są walidowane (schema) i cytowane (provenance).

Fallback i eskalacja

Fallback to nie „błąd”, tylko zaplanowana ścieżka. Typowe warianty:

  • No‑Answer + dopytanie.
  • Approval/HITL dla działań o skutkach ubocznych.
  • Retry planowy dla operacji technicznych (np. chwilowy timeout).

Artefakty

Warto utrzymywać trzy artefakty:

Mapa stanów
diagram + warunki przejść (wersjonowane).
Bramki
policy, DLP, ACL, SLO, approval.
Test harness
regresje na ścieżkach i wyjątkach.

Checklist

  • Zdefiniuj stany i przejścia (nie zostawiaj tego „w głowie modelu”).
  • Wymuś deterministyczne bramki w silniku.
  • Wpisz fallback (no‑answer, HITL, retry) jako część projektu.
  • Loguj state, transition i trace_id.
  • Testuj regresje na ścieżkach krytycznych.

Powiązane

Skrót operacyjny
  1. Rozmowa to proces — ma stany.
  2. Bramki są deterministyczne.
  3. Fallback jest częścią projektu.
Artefakt
Mapa stanów + warunki przejść + checklist.
Integracje w workflow