Wzorzec

Plan‑and‑Execute: plan jako artefakt kontroli i jakości

Jak oddzielić planowanie od wykonania, zwalidować plan przed uruchomieniem i uruchamiać przebiegi, które da się testować i utrzymywać jak klasyczny workflow.

Plan jako artefakt: po co to robić

Plan‑and‑Execute bywa mylony z „łańcuchem promptów”. Różnica jest zasadnicza: plan jest artefaktem kontroli. Da się go walidować, wersjonować, audytować i testować – zanim cokolwiek zostanie wykonane.

Minimalny schemat planu

plan:
  goal: "..."
  constraints: ["privacy", "policy@2.1", "tool.read_only"]
  steps:
    - id: "retrieve_policy"
      tool: "knowledge.search"
      input: {query:"..."}
      expected: "citations"
    - id: "draft_answer"
      tool: "llm.generate"
      input: {format:"answer_md"}
    - id: "final_check"
      tool: "lint.language"
      input: {tone:"tone_v2"}

Walidacja planu (bramki)

  • Policy gate: czy plan respektuje ograniczenia (PII, cytowania, narzędzia).
  • Tool gate: czy kroki narzędziowe mają kontrakt, timeout, retry, idempotency.
  • Cost gate: budżet tokenów i czas p95 (SLO).
W praktyce: plan powinien być krótki. Jeżeli plan ma 30 kroków, to zwykle znaczy, że problem jest źle zdekomponowany albo brakuje narzędzia wyższego poziomu.

Egzekucja i ślad

Execute powinien produkować dziennik: krok → wejście → wynik → decyzja bramki. To jest podstawa debugowania i regresji.

  • trace: rozmowa + kroki narzędziowe,
  • replay: odtwarzanie krok po kroku (mini-scrubber),
  • post-mortem: porównanie planu z wykonaniem (odchylenia).
W tym rozdziale
  • różnica względem ReAct
  • struktura planu (JSON)
  • walidacja planu: policy/RBAC/DLP
  • execute: timeouts, idempotency, trace
  • checklist wdrożeniowy

Dlaczego Plan‑and‑Execute

Plan‑and‑Execute rozdziela proces na dwa etapy: najpierw model tworzy jawny plan, a dopiero potem system go wykonuje (często częściowo deterministycznie). W odróżnieniu od ReAct, gdzie plan może ewoluować w pętli, tutaj plan jest artefaktem, który można zwalidować przed wykonaniem.

Wartość biznesowa: plan jest „obiektem kontroli” — można go zatwierdzić, zablokować, wersjonować, a także uruchomić regresje. To ważne przy procesach o skutkach ubocznych (zmiany danych, wysyłki, działania w systemach firmowych).
Rysunek 1. Plan‑and‑Execute jako dwustopniowy pipeline
Etap 1: Plan (JSON) cele, kroki, narzędzia, dane Walidacja policy, RBAC, DLP Etap 2: Execute kroki, timeouts, idempotency Walidacja wyjścia format, cytowania, testy, audyt

Artefakt planu: struktura minimalna

Rekomendowana forma planu, możliwa do walidacji:

{
  "goal": "…",
  "steps": [
    { "id": "S1", "tool": "search_docs", "input": { "q": "…" }, "expects": "chunks[]" },
    { "id": "S2", "tool": "compose_answer", "input": { "chunks_ref": "S1" }, "expects": "draft" }
  ],
  "stop_conditions": ["evidence_coverage>=1.0", "max_steps<=6"]
}

Walidacja planu: co musi przejść bramki

  • Dozwolone narzędzia (allowlist) dla danej dziedziny i roli.
  • Zakaz kroków o skutkach ubocznych bez approvals (write/send/delete).
  • Budżety: max steps, max tool calls, timeouts.
  • Wymóg dowodowości: dla twierdzeń faktualnych plan musi przewidzieć źródła.

Execute: deterministyka tam, gdzie można

Dobre Plan‑and‑Execute przenosi część odpowiedzialności z modelu na system: parsowanie, walidacje, mapowanie danych, idempotency i obsługę błędów. Model zostaje w roli „architekta przebiegu”, nie „operatora systemów”.

Checklist wdrożeniowy

  • Plan w JSON + walidator schematu.
  • Brama planu: policy/RBAC/DLP + limity + approvals.
  • Silnik wykonania kroków: retry, idempotency, trace.
  • Walidacja wyjścia: format, źródła, standard językowy, regresje.
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.