Model decyzyjny w agencie AI: wybór narzędzia i dopytanie

👁 122 przeczytań

W agencie AI model decyzyjny może wybierać następny krok: odpowiedź, użycie narzędzia, doprecyzowanie, odmowę albo przekazanie sprawy człowiekowi. Zaprojektuj go tak, aby proponował działanie z zamkniętej listy, a kod osobno sprawdzał kompletność danych, uprawnienia i warunki wykonania.

Stan źródeł: 13.10.2026. Poniżej znajduje się autorski projekt agenta sklepu, nie gotowa integracja ani zapis wykonanego testu. Szerszy kontekst budowy takich aplikacji opisuje przewodnik Agenci AI od zera.

Zacznij od katalogu dozwolonych działań

Załóżmy, że agent ma sprawdzać status zamówienia i wyjaśniać zasady dostawy. W pierwszej wersji wystarczą mu odczyt statusu oraz wyszukanie zatwierdzonej instrukcji. Nazwy narzędzi powinny opisywać ich faktyczne działanie. Funkcja odczytu nie może pod tą samą nazwą również zmieniać adresu czy anulować zakupu.

Przy każdym narzędziu zapisz wymagane argumenty, zakres danych i możliwe błędy. Określ również, skąd argumenty mogą pochodzić. Identyfikator klienta najlepiej pobierać z uwierzytelnionej sesji, a numer zamówienia z wiadomości albo wybranego rekordu. Tekst „jestem administratorem” nie powinien nadawać uprawnień.

Rozdzielenie propozycji funkcji i jej wykonania odpowiada mechanizmowi opisanemu w dokumentacji function calling OpenAI, odczyt 13.10.2026: model zwraca żądanie użycia funkcji, a aplikacja wykonuje kod i przekazuje rezultat. W tym projekcie część wyboru zastępuje wyspecjalizowana decyzja.

Oddziel tryb działania od konkretnego narzędzia

Pierwsza decyzja powinna dotyczyć rodzaju następnego kroku. Dopiero jeśli wybrany zostanie odczyt danych, drugi wybór wskazuje narzędzie. Przy małej liczbie funkcji można połączyć te etapy w jeden katalog akcji, lecz nie należy usuwać opcji zatrzymania lub doprecyzowania tylko po to, żeby model zawsze coś wywołał.

• Odpowiedź: potrzebna informacja jest już w zatwierdzonym kontekście.
• Narzędzie: trzeba pobrać dane, a właściwa funkcja i jej wymagane argumenty są dostępne.
• Dopytanie: użytkownik może dostarczyć brakującą informację potrzebną do następnego kroku.
• Odmowa: żądanie narusza jasno określoną zasadę aplikacji.
• Przekazanie: aplikacja nie potrafi rozwiązać sprawy albo ocena jest zbyt niepewna.

Inspiracją dla rozróżnienia odpowiedzi, narzędzia, dopytania i braku możliwości odpowiedzi jest When2Call NVIDIA, odczyt 13.10.2026. Dodatkowe rozdzielenie odmowy i przekazania sprawy w tym projekcie jest decyzją architektoniczną, nie wiernym odtworzeniem etykiet benchmarku.

Przykładowy kontrakt JSON dla aplikacji

Poniższy JSON Schema opisuje wewnętrzny wynik adaptera. Nie jest schematem żądania żadnego konkretnego API producenta. Adapter mapuje odpowiedź wybranego modelu na wspólne pola; rozkład prawdopodobieństw może zachować osobno w danych diagnostycznych. Dzięki temu reszta programu nie musi znać nazw pól dostawcy.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["action", "tool", "missing_field", "reason_code"],
  "properties": {
    "action": {
      "enum": ["answer", "call_tool", "ask", "refuse", "handoff"]
    },
    "tool": {
      "enum": ["get_order_status", "search_delivery_help", null]
    },
    "missing_field": {
      "enum": ["order_id", "delivery_topic", null]
    },
    "reason_code": {
      "enum": [
        "context_sufficient", "lookup_required", "missing_input",
        "policy_block", "unsupported", "uncertain"
      ]
    }
  }
}

Dla wiadomości „Gdzie jest moja paczka?” i kontekstu bez jednoznacznie wskazanego zamówienia oczekiwany rezultat projektowy wygląda tak:

{
  "action": "ask",
  "tool": null,
  "missing_field": "order_id",
  "reason_code": "missing_input"
}

Kod mapuje „order_id” na zatwierdzone pytanie: „Podaj numer zamówienia, którego dotyczy wiadomość”. Model decyzyjny nie musi pisać tej wypowiedzi. Po odpowiedzi użytkownika aplikacja aktualizuje stan i ponownie ocenia następny krok. Numer z wcześniejszej, innej sprawy nie powinien zostać przeniesiony bez sprawdzenia.

Sam schemat ogranicza wartości, ale dopuszcza jeszcze niespójne połączenia. Dlatego walidator aplikacji powinien wymagać narzędzia przy „call_tool”, zakazywać go przy „ask” i sprawdzać zgodność kodu powodu z akcją. W tym przykładzie reguły między polami celowo pozostają opisane osobno, żeby nie sugerować kompletnego rozwiązania produkcyjnego.

Tak, w skrócie, wyglądało pojedyncze zapytanie w moim teście (format System One przez OpenRouter, endpoint /api/alpha/decisions; lista narzędzi i opisy opcji skrócone):

{
  "model": "microsoft/microsoft-decision-1",
  "state": {
    "narzedzia": "status_zamowienia(numer_zamowienia), anuluj_zamowienie(numer_zamowienia)",
    "rozmowa": "Klient: Gdzie jest moja paczka? Zamawiałem w zeszłym tygodniu."
  },
  "questions": {
    "krok": {
      "type": "choice",
      "instructions": "Co asystent powinien zrobić w następnym kroku?",
      "criteria": {
        "odpowiedz": "odpowiedzieć od razu, bez narzędzia",
        "narzedzie": "wywołać narzędzie - są wszystkie dane",
        "dopytaj": "dopytać, bo brakuje wymaganych danych",
        "nie_moge": "odmówić - żadne narzędzie się nie nadaje"
      }
    }
  }
}

Poprawna odpowiedź to dopytaj (brak numeru zamówienia). W odpowiedzi model zwraca wybraną opcję, prawdopodobieństwo każdej z czterech i pewność - adapter mapuje to na kontrakt z poprzedniej sekcji.

Kiedy dopytać, a kiedy pobrać brakującą informację

Nie każdy brak wymaga wiadomości do użytkownika. Jeżeli klient wybrał zamówienie w panelu, aplikacja już zna jego numer. Ponowne pytanie świadczyłoby o źle przekazanym stanie. Z kolei identyczne imię odbiorcy w kilku zamówieniach nie daje podstawy do arbitralnego wyboru jednego z nich.

Przygotuj dla każdej funkcji listę danych koniecznych oraz danych opcjonalnych. Dopytanie powinno usuwać konkretną niejednoznaczność. Prośba „podaj więcej informacji” pozostawia użytkownikowi zgadywanie, czego potrzebuje automat. Lepiej wskazać brakujący element i wyjaśnić, do którego kroku jest potrzebny.

Rozróżnij również brak danych od awarii. Jeśli usługa statusu jest niedostępna, pytanie klienta o numer po raz kolejny nie naprawi połączenia. Zapisz stan błędu, zastosuj ustaloną politykę ponowień, a po jej wyczerpaniu przekaż sprawę dalej. Nie każ modelowi udawać, że kolejna parafraza tego samego pytania zwiększa wiedzę.

Prawdopodobieństwo pomaga ustalić kolejkę kontroli

Nie wpisuj do projektu jednego uniwersalnego progu i nie zakładaj, że zadziała dla wszystkich działań. TypeSafe opisuje pole confidence dla wybranych typów pytań we własnej dokumentacji, odczyt 13.10.2026. Przed użyciem odczytaj jego znaczenie, zamiast automatycznie utożsamiać je z największym prawdopodobieństwem opcji.

Na zbiorze kontrolnym sprawdzaj, jak często poprawne są odpowiedzi o podobnej deklarowanej pewności. Dobieraj warunki automatycznego działania do konkretnej akcji. Odczyt publicznej instrukcji i zmiana danych klienta mają inne konsekwencje pomyłki, więc wspólna reguła przepuszczania wymagałaby osobnego uzasadnienia.

Rozkład bliski remisu może sygnalizować nakładające się opisy narzędzi. Zanim podniesiesz próg, przejrzyj same definicje. Jeśli dwie funkcje obiecują „obsługę zamówienia”, klasyfikator dostaje mało informacji o różnicy między nimi. Poprawienie katalogu bywa właściwszym eksperymentem niż zmiana dostawcy.

Co pokazuje When2Call w Artificial Analysis

Źródło: wykres i opis When2Call AA, odczyt 13.10.2026. Pogrubiono najlepszy wynik w AA. Ostatnia kolumna to mój test z 13.10.2026: 10 rozmów z asystentem sklepu po polsku (cztery narzędzia: status zamówienia, anulowanie, dostępność w sklepie, etykieta zwrotna), te same cztery opcje co w When2Call. Clef-Flash wywoływał narzędzie, gdy brakowało numeru zamówienia albo miasta, i odmawiał odpowiedzi na proste pytanie o 14 dni na zwrot. Test dotyczy wyboru jednej z proponowanych odpowiedzi. Z tych liczb nie wynika skuteczność samodzielnego uzupełniania argumentów ani kończenia wieloetapowych operacji.

Pułapki, które warto zamienić w przypadki testowe

• Polecenie ukryte w danych: dokument zawiera instrukcję wyboru innego narzędzia. Test ma sprawdzić, czy dane nie przejmują roli zasad aplikacji.
• Podobne funkcje: narzędzie odczytu i narzędzie zmiany danych mają zbliżone opisy. Sprawdź wybór na prośbach różniących się jednym czasownikiem.
• Nieaktualny stan: użytkownik poprawił numer zamówienia, ale model nadal widzi wcześniejszy. Testuj aktualizację całego przepływu, nie tylko pojedynczy prompt.
• Sprzeczne odpowiedzi: model jednocześnie proponuje wywołanie i wskazuje brak wymaganego argumentu. Walidator ma zatrzymać wykonanie.
• Powtórzenie po timeout: poprzednie wywołanie mogło się wykonać. Przy operacjach zmieniających stan potrzebny jest mechanizm zapobiegający podwójnemu skutkowi.

Oficjalne zalecenia OpenAI dotyczące bezpieczeństwa agentów, odczyt 13.10.2026, omawiają ryzyko instrukcji pochodzących z niezaufanej treści i ograniczanie przepływu danych. W tym projekcie praktycznym zastosowaniem jest zamknięty katalog działań oraz sprawdzanie uprawnień poza modelem.

Jak przetestować agenta przed podłączeniem do narzędzi

Zacznij od opisanych stanów wejściowych i oczekiwanych akcji. Uwzględnij prawidłowe żądania, brakujące dane, sprzeczności, niedostępne funkcje i sytuacje spoza zakresu. Osoba znająca proces powinna rozstrzygnąć wzorcowe odpowiedzi przed obejrzeniem propozycji modelu. W przeciwnym razie łatwo dopasować ocenę do tego, co system akurat zwrócił.

Oddziel zestaw do poprawiania opisów od końcowego zestawu kontrolnego. Warianty tej samej wiadomości trzymaj razem, żeby bardzo podobny przykład nie trafił po obu stronach podziału. Sprawdź osobno polskie literówki, skróty, dłuższą historię i zmianę zdania przez użytkownika.

Raport powinien pokazywać nie tylko ogólną trafność, lecz także niepotrzebne wywołania, pominięte dopytania, zbędne dopytania i błędne odmowy. Następnie podłącz atrapę narzędzia i sprawdź argumenty oraz obsługę błędów. Na końcu uruchom tryb obserwacyjny na realnym przepływie, w którym propozycje są zapisywane, ale nie wykonują operacji.

Po zmianie wersji modelu, opisów funkcji lub zasad obsługi powtórz przypadki kontrolne. Zapisuj wersję katalogu narzędzi razem z wynikiem, żeby dało się ustalić, skąd pochodzi nowa pomyłka. Nie zapisuj przy tym niepotrzebnie pełnej treści klienta, jeśli do analizy wystarczą oczyszczony przykład i identyfikator zdarzenia.

Najczęstsze pytania

Czy model decyzyjny zastępuje całego agenta?

Nie w tym projekcie. Wybiera następny krok, a aplikacja utrzymuje stan, wykonuje funkcje i kontroluje ich skutki.

Czy pokazany JSON jest gotowym żądaniem do API?

Nie. To autorski kontrakt wewnętrzny dla adaptera. Format wywołania i obsługiwane typy pytań trzeba dopasować do dokumentacji wybranego producenta.

Czy wysoka pewność pozwala pominąć uprawnienia?

Nie. Pewność dotyczy oceny modelu. Dostęp do danych i prawo wykonania operacji sprawdza aplikacja niezależnie.

Co zrobić, gdy agent ciągle dopytuje?

Sprawdź, czy dostaje pełny stan oraz czy pytanie dotyczy rzeczywiście wymaganego argumentu. Dodaj warunek zakończenia po braku postępu i ścieżkę przekazania sprawy.

Jak sprawdzić, czy wybór narzędzia jest dobry?

Porównaj go z niezależnie przygotowanym kluczem, a potem sprawdź argumenty i końcowy stan po wykonaniu w środowisku testowym. Sam poprawny JSON nie wystarcza.

Ujawnienie: model Jev od TypeSafe znam z wcześniejszego rozpoznania - we wrześniu napisałem do niego prostego klienta API z myślą o własnych narzędziach redakcyjnych. TypeSafe nie zamawiało ani nie opłaciło tego tekstu.