llama.cpp waliduje narzędzia przy starcie — koniec cichych błędów
- llama.cpp w buildzie b9029 wprowadza walidację flagi --tools na starcie serwera, zamiast po cichu ignorować nieznane narzędzia.
- Serwer teraz zatrzymuje się z błędem i wyświetla listę dostępnych narzędzi, gdy podasz nieznaną nazwę.
- Zmiana eliminuje trudne do wykrycia błędy konfiguracyjne w pipeline'ach agentowych.
llama.cpp b9029 przestał milczeć przy złej konfiguracji
Build b9029 llama.cpp zmienia zachowanie serwera przy uruchamianiu z flagą --tools — zamiast po cichu ignorować nieznane nazwy narzędzi, serwer teraz twardо odmawia startu i wyrzuca błąd z listą tego, co faktycznie jest dostępne.
Brzmi jak drobnostka. Dla osób budujących agentowe pipeline’y to jednak zmiana, która oszczędza sporo debugowania.
Jak działało to wcześniej
Przed tą poprawką błędna nazwa narzędzia przekazana przez --tools była milcząco pomijana. Serwer startował normalnie, agent działał — tylko bez narzędzia, które miał mieć. Efekt? Trudne do złapania błędy, gdzie agent zachowywał się dziwnie, ale nie wyrzucał żadnego czytelnego komunikatu. Trzeba było samodzielnie diagnozować, czy problem leży w prompcie, modelu, czy właśnie w tym, że --tools web_search nigdy się nie załadował, bo literówka zmieniła nazwę na web_serach.
Fail-fast zamiast silent failure
Nowe zachowanie jest klasycznym wzorcem fail-fast: serwer sprawdza każdą nazwę narzędzia przy starcie i jeśli coś nie gra, zatrzymuje się od razu z komunikatem pokazującym dostępne opcje. Zero zgadywania, zero debugowania w ciemno.
To szczególnie istotne w automatycznych deploymentach, gdzie nikt nie patrzy ręcznie na logi startowe. CI/CD pipeline sam wykryje błędną konfigurację zamiast przepuszczać ją do produkcji.
Czy to zmiana breaking?
Technicznie tak — jeśli masz skrypty, które przekazywały nieistniejące nazwy narzędzi i liczyły na to, że serwer po prostu je zignoruje, teraz te skrypty przestaną działać. W praktyce trudno sobie wyobrazić scenariusz, gdzie celowo chciałeś przekazać nazwę narzędzia, które nie istnieje.
Migrating jest prosty: odpal serwer z dotychczasową konfiguracją, sprawdź listę dostępnych narzędzi w komunikacie błędu i popraw nazwy. Jednorazowa robota.
llama.cpp dojrzewa do poważniejszych zastosowań
Ta zmiana to część szerszego trendu w projekcie — llama.cpp systematycznie zamyka luki między szybkim prototypowaniem a produkcyjnym użyciem. Serwer z lepszą obsługą błędów to serwer, który można bezpieczniej wrzucić w pipeline agentowy bez bania się, że cicha awaria skończy się godzinami diagnozy.
PR #22538 prowadził do buildu z adnotacją Assisted-by: llama.cpp:local pi, co sugeruje użycie lokalnego modelu do wsparcia przy pisaniu kodu — czyli llama.cpp dosłownie pomogła zbudować własną poprawkę.
Następny build już dostępny na GitHubie — warto odpalić update przed wdrożeniem nowych agentowych konfiguracji.
