Co nowego w Kelverse: od MCP do wspólnego ekosystemu wtyczek
Ostatnie wydania w ekosystemie Kelverse to coś więcej niż kolejne numery wersji. Ticketing Tool 1.5.0, premiera Kelverse Knowledge Base 1.0.0, Toolbox 0.9.0 z Integration Layer oraz Ticketing Tool 1.6.0 składają się na większą zmianę w sposobie, w jaki rozwijamy nasze narzędzia.
Do tej pory poszczególne wtyczki mogły działać obok siebie. Teraz zaczynają działać razem.
Ticketing Tool 1.5.0 — otwarcie na agentów AI
Wersja 1.5.0 Kelverse Ticketing Tool skupiła się na integracji z agentami i protokole MCP.
Ticketing Tool od początku miał być czymś więcej niż prostą tablicą zgłoszeń. Kolejnym krokiem stało się umożliwienie narzędziom takim jak agenci programistyczni bezpiecznej pracy bezpośrednio z backlogiem projektu.
Dzięki warstwie MCP agent może korzystać z funkcji Ticketing Toola w kontrolowany sposób: wyszukiwać i odczytywać zgłoszenia, podejmować pracę nad ticketem, aktualizować jego stan, dodawać notatki, łączyć zmiany w kodzie ze zgłoszeniem czy przekazywać wykonane zadanie do weryfikacji.
Nie chodzi jednak tylko o samo udostępnienie API.
Ticketing Tool nadal pilnuje mechanizmów takich jak uprawnienia, rezerwowanie zgłoszeń, rewizje danych, idempotencja operacji czy historia wykonywanych działań. Agent otrzymuje więc narzędzia potrzebne do pracy, ale nie dostaje niekontrolowanego dostępu do całego systemu.
To ważny fundament pod model pracy, w którym człowiek definiuje zadania i podejmuje decyzje, a część pracy implementacyjnej może być wykonywana przez wyspecjalizowanych agentów.
Kelverse Knowledge Base 1.0.0 — wiedza staje się osobnym produktem
Drugim dużym krokiem było powstanie Kelverse Knowledge Base.
Zamiast rozbudowywać Ticketing Tool o kolejne funkcje FAQ i dokumentacji, zdecydowaliśmy się oddzielić wiedzę przeznaczoną dla użytkowników i supportu od systemu zarządzania ticketami.
KKB 1.0.0 zapewnia własny system artykułów wiedzy, FAQ, instrukcji i materiałów troubleshootingowych wraz z wyszukiwaniem oraz API umożliwiającym korzystanie z bazy przez inne elementy ekosystemu.
Istotną częścią rozwiązania jest również przepływ tworzenia wiedzy na podstawie realnych problemów.
Rozwiązany ticket może stać się podstawą propozycji nowego artykułu. Powstaje draft, który może zostać zweryfikowany i zaakceptowany przez człowieka, a następnie opublikowany w Knowledge Base. Dzięki temu rozwiązanie problemu nie musi kończyć swojego życia razem z zamknięciem zgłoszenia.
Ticketing Tool zachowuje przy tym własną wiedzę projektową i deweloperską wykorzystywaną przez agentów. Knowledge Base odpowiada za inny rodzaj informacji — treści przeznaczone do ponownego wykorzystania przez użytkowników i support.
W praktyce zaczynamy więc budować mechanizm:
problem → ticket → rozwiązanie → artykuł wiedzy → mniej podobnych ticketów w przyszłości.
Toolbox 0.9.0 — Integration Layer
Posiadanie kilku wtyczek rozwiązujących różne problemy prowadzi jednak do kolejnego pytania: jak powinny się ze sobą komunikować?
Odpowiedzią jest największa architektoniczna zmiana w Kelverse WP Toolbox od początku jego powstania.
Wersja 0.9.0 wprowadza Integration Layer.
Toolbox staje się wspólną warstwą pozwalającą wtyczkom Kelverse odnajdywać się nawzajem, deklarować oferowane funkcje i korzystać z nich bez budowania sztywnych zależności pomiędzy konkretnymi klasami czy implementacjami.
Integration Layer wprowadza między innymi rejestr wtyczek i usług, jawne kontrakty i wersjonowanie integracji, obsługę wymaganych oraz opcjonalnych zależności, lokalny system zdarzeń oraz diagnostykę stanu integracji.
Najważniejsza zasada pozostaje jednak bardzo prosta:
Toolbox łączy produkty, ale nie przejmuje ich odpowiedzialności.
Ticketing Tool nadal odpowiada za tickety. Knowledge Base nadal odpowiada za wiedzę. Toolbox dostarcza jedynie wspólny język, dzięki któremu mogą ze sobą rozmawiać.
Co równie ważne, brak opcjonalnej integracji nie powinien powodować awarii całej wtyczki. Poszczególne produkty nadal mogą działać niezależnie, a dodatkowe możliwości pojawiają się wtedy, gdy odpowiednie elementy ekosystemu są dostępne.
Ticketing Tool 1.6.0 — pierwsza praktyczna integracja
Ticketing Tool 1.6.0 jest momentem, w którym wcześniejsze elementy zaczynają składać się w całość.
Po jednej stronie mamy system zgłoszeń. Po drugiej Knowledge Base. Pomiędzy nimi znajduje się Integration Layer Toolboxa.
Ticketing Tool może dzięki temu korzystać z usług Knowledge Base przez stabilny kontrakt zamiast bezpośrednio odwoływać się do jej wewnętrznego kodu.
W praktyce oznacza to możliwość wyszukiwania wiedzy z poziomu pracy nad zgłoszeniem, podpowiadania istniejących artykułów, osadzania ich przy ticketach oraz tworzenia propozycji nowych artykułów na podstawie rozwiązanych problemów.
Relacja działa również w drugą stronę — artykuł może zachować informację o tickecie, z którego powstał.
To właśnie tutaj Integration Layer przestaje być wyłącznie elementem technicznej infrastruktury, a zaczyna dawać widoczny efekt użytkownikowi.
Cztery wydania, jeden kierunek
Patrząc na każde z tych wydań osobno, otrzymujemy cztery różne zestawy funkcji.
Patrząc na nie razem, widać jednak znacznie ważniejszą zmianę.
Ticketing Tool 1.5.0 umożliwia współpracę z agentami.
Knowledge Base 1.0.0 tworzy wspólne miejsce na wiedzę.
Toolbox 0.9.0 zapewnia standard komunikacji pomiędzy produktami.
Ticketing Tool 1.6.0 po raz pierwszy wykorzystuje tę architekturę w praktyce.
Kelverse zaczyna więc odchodzić od modelu zbioru niezależnych wtyczek w kierunku modularnego ekosystemu, w którym każdy produkt ma jasno określoną odpowiedzialność, ale może udostępniać swoje możliwości pozostałym.
To również przygotowanie gruntu pod kolejne zmiany.
Obecny moduł obsługi użytkownika w Ticketing Toolu nadal pełni rolę przejściową. W przyszłości Support zostanie wydzielony do osobnej wtyczki. Dzięki Integration Layer taka zmiana nie będzie jednak wymagała ponownego budowania całej integracji — nowy moduł będzie mógł korzystać z tych samych usług Ticketing Toola i Knowledge Base.
To dopiero pierwsze wykorzystanie nowej architektury, ale kierunek jest już wyraźny:
mniejsze, wyspecjalizowane produkty, wspólne kontrakty i coraz więcej możliwości pojawiających się wtedy, gdy połączymy je ze sobą.
I właśnie na tym chcemy budować kolejne elementy Kelverse.