Wzorzec

ReAct (Reason + Act): wzorzec pracy z narzędziami bez zgadywania

Jak projektować przebieg „plan → tool → observation → odpowiedź” w sposób kontrolowalny, audytowalny i odporny na pętle oraz nadużycia narzędzi.

W tym rozdziale
  • kiedy ReAct ma sens (a kiedy nie)
  • jak zbudować cykl plan–action–observation
  • kontrakt narzędzi + Tool Gateway
  • limity i telemetria (trace, budżety)
  • checklist wdrożeniowy

Po co ReAct

ReAct (Reason + Act) to wzorzec projektowania interakcji, w którym model naprzemiennie wykonuje kroki rozumowania i kroki działania (wywołania narzędzi). W praktyce produkcyjnej ReAct ma jeden cel: zmniejszyć ryzyko zgadywania poprzez wymuszenie pracy na danych i obserwacjach, zamiast na domysłach.

Uwaga praktyczna: w Luage „Reason” nie oznacza publikowania pełnego toku rozumowania. W systemach produkcyjnych preferujemy jawny plan i jawne działania (narzędzia, źródła, walidacje), a rozumowanie wewnętrzne pozostaje krótkie, kontrolowane i audytowalne.
Rysunek 1. Minimalny cykl ReAct w systemie narzędziowym
Plan (jawny) Action (tool) Observation Update state kontekst, pamięć Final pętla do spełnienia kryterium stopu (limity kroków, wynik, błąd krytyczny)

ReAct w Luage: trzy warstwy kontroli

Żeby ReAct był rzetelny, potrzebuje kontroli w trzech miejscach:

  1. Kontrakt narzędzi (schema, typy, ograniczenia, idempotency).
  2. Bramki (RBAC, DLP/PII, zakres uprawnień, approvals dla skutków ubocznych).
  3. Audyt i limity wykonania (trace, budżet kroków, budżet tokenów, timeouts).
Wzorzec: ReAct nie zaczyna się od „ładnego promptu”, tylko od inżynierii narzędzi i inżynierii kontekstu. Dopiero potem promptowanie dostraja zachowanie.

Minimalny kontrakt „Planner → Tool Gateway → Executor”

W praktyce warto rozdzielić role:

  • Planner – wybiera narzędzie i przygotowuje argumenty (bez skutków ubocznych).
  • Tool Gateway – waliduje i autoryzuje wywołanie (schema/RBAC/DLP/approval).
  • Executor – wykonuje narzędzie deterministycznie, loguje trace i zwraca observation.

Najczęstsze błędy i jak ich unikać

  • Tool‑loop (pętla bez postępu) → limit kroków + detektor powtarzalnych obserwacji.
  • „Tool cosplay” (model udaje wynik narzędzia) → twarde rozdzielenie kanałów: action/observation z systemu, nie z modelu.
  • Brak provenance → bind cytowań do źródeł (doc_id, wersja, fragment).
  • Za szerokie uprawnienia → allowlist narzędzi per dziedzina + RBAC + approvals.

Checklist wdrożeniowy (skrót)

  • Inventory narzędzi + kontrakty (schema, typy, ograniczenia) gotowe i wersjonowane.
  • Tool Gateway z bramkami: Schema → RBAC → DLP/PII → Approval (jeśli write).
  • Limity: max steps, max tool calls, timeout per call, idempotency key.
  • Telemetria: trace_id, wynik bramek, błędy narzędzi, retry count.
  • Regresje: scenariusze „tool fail”, „denied”, „approval required”.
Powiązane
Na tej stronie
Spis
    Nawigacja
    ← Poprzedni Następny →
    Status merytoryczny
    Ten rozdział jest częścią Compendium. Metryka (wersja, owner, terminy przeglądu) jest wypełniana automatycznie na podstawie manifestu.