Skrypty jako bezpieczne tools dla AI: deterministyczne akcje zamiast improwizacji Ollamy

Jedno dobrze zaprojektowane narzędzie jest bezpieczniejsze i bardziej przewidywalne niż seria kilku decyzji LLM. Skrypt może mieć własną walidację, warunki, timeouty, dokładnie ograniczone parametry i jawny wynik zwracany modelowi.

Zaczynamy od helpera `LLM test`, aby zobaczyć poprawny tool call, realny efekt i response_variable bez ryzyka dla urządzeń fizycznych.

Opisujemy dokładnie co tool robi, kiedy powinien być używany i jaki wynik ma zakomunikować użytkownikowi. Nie zostawiamy modelowi pola do zgadywania.

Tworzymy `AI LAB | Przygotuj salon` z polem jasności 10-60%, własną walidacją, obsługą unavailable i deterministyczną sekwencją świateł.

Stop + response_variable zwraca mapę ze statusem, komunikatem i parametrami. Ollama nie musi wymyślać, czy operacja się udała.

Każdy skrypt przechodzi ręczny commissioning w Tools > Actions. Dopiero gdy działa bez LLM, wystawiamy go jako tool.

Sprawdzamy 95%, brak parametru, zły pokój, unavailable, granice 10/60%, unexpose oraz zachowanie przy wyłączonej Ollamie.

• dlaczego script tool ogranicza improwizację LLM
• różnicę między script entity i callable tool
• pierwszy bezpieczny tool na input_boolean
• poprawny description skryptu
• aktualne ścieżki UI exposure
• Stop i response_variable
• mapę wyniku status/message
• kontrolowany error: true
• pola wejściowe scripts
• limit 128 znaków dla field description
• number selector 10-60%
• wewnętrzną walidację argumentów
• obsługę missing field
• obsługę unavailable
• pełny skrypt Przygotuj salon
• manual commissioning przez Tools > Actions
• test 95% bez LLM
• wystawienie do Voice assistants > Assist
• limit 128 script tools
• test naturalnego języka
• kontrolę tool args
• wynik skryptu kontra odpowiedź modelu
• negative test z parametrem poza zakresem
• zły use case kuchnia kontra salon
• description jako kontrakt wyboru
• anti-pattern dowolna action/entity/data
• zasadę jeden tool = jedna zdolność
• działania na encjach wewnętrznych skryptu
• audyt niejawnych skutków skryptu
• mode single jako bezpieczny start
• różnicę script tool i Sentence trigger
• local-first + skrypt jako wspólny backend
• pełny test Voice PE
• kilka parafraz tego samego zamiaru
• brak liczby i pytanie doprecyzowujące
• testy graniczne 10/60%
• restart Home Assistant
• WAN OFF
• Ollama OFF kontra Sentence trigger
• select zamiast wolnego tekstu
• bezpieczne zastosowanie text field
• unexpose test
• rollback toola
• Tool Test Pack, Design Matrix i Security Checklist

Nie wystawiamy złożonego skryptu i nie zaczynamy od głosu. Najpierw test manualny, potem tekstowy tool call, dopiero na końcu Voice PE.

Nie używamy promptu jako zabezpieczenia. Parametry i preconditions są sprawdzane przez sam skrypt, a możliwość LLM ograniczamy do konkretnego toola.

Ollama może przyjąć naturalne „zrób w salonie spokojne światło do filmu”, ale zamiast samodzielnie sterować kilkoma encjami wywołuje jeden sprawdzony skrypt Home Assistant z ograniczonym parametrem i jawnym wynikiem.

Ta lekcja jest częścią kursu Smart Home od Zera na platformie MarkLabs E-Learning. Pełna wersja prowadzi od pustego script toola do kontrolowanego parametrycznego narzędzia i testów awarii.