TanStack AI 1.0 ułatwia zmianę modelu i wyjaśnia odpowiedzialność aplikacji

Autorski diagram redakcyjny Ken Jo, oparty na źródłach wymienionych poniżej.

Zmiana modelu powinna być decyzją produktową. W aplikacji, która zgromadziła formaty wiadomości zależne od dostawcy, stan przeglądarki i wywołania zwrotne narzędzi, może jednak zamienić się w projekt migracyjny, zanim ktoś porówna nowe odpowiedzi.

TanStack AI 1.0, ogłoszony 23 października 2026 roku, składa na tej granicy konkretną deklarację: stabilne API rdzenia, 23 adaptery dostawców i obsługę kilku frameworków interfejsu. Nowe środowisko wykonawcze agentów, czyli harness, pozostaje eksperymentalne. Przy wyborze podstawy rozwoju to rozróżnienie jest ważniejsze niż numer wersji. Ogłoszenie TanStack.

TanStack tworzy biblioteki open source dla programistów aplikacji. To wydanie dotyczy oprogramowania między modelem AI a produktem: strumieniowania odpowiedzi, narzędzi, interfejsów i stanu aplikacji. Przyjrzyjmy się obietnicy przenośności, jej znaczeniu w trzech typowych projektach oraz przygotowaniu aplikacji 0.x do aktualizacji.

Oficjalny przykład TanStack AG-UI, © 2025 Tanner Linsley, licencja MIT. Obraz przedstawia przykładowy interfejs projektu i wybrany model, a nie uruchomienie wykonane na potrzeby artykułu.

Wspólny interfejs ogranicza zakres zmiany dostawcy

Adapter tłumaczy oczekiwania aplikacji na API dostawcy. Zapewnia programistom spójny punkt żądania odpowiedzi modelu i odbioru wyniku. Aplikacja może zachować prezentację rozmowy i reguły biznesowe, wymieniając część komunikującą się z dostawcą.

Ta warstwa przypomina centralę połączeń. Zapewnia zrozumiałe połączenia, nie ujednolicając wszystkich systemów po drugiej stronie. Jest to przydatne właśnie dlatego, że modele, hosting i wymagania produktu zmieniają się niezależnie.

Ogłoszenie z 23 października opisuje 23 adaptery oraz opcję zgodną z OpenAI dla usług korzystających z takiego formatu API. Oddziela też stabilny rdzeń od eksperymentalnych pakietów harness. Są to zobowiązania dotyczące zgodności i utrzymania, a nie gwarancja, że każdy dostawca wspiera każdą funkcję modelu. Zakres wydania.

Pierwsze pytanie jest więc konkretne: które części obecnej aplikacji przetrwają zmianę dostawcy? Renderowanie odpowiedzi może być łatwe do przeniesienia. Proces oparty na identyfikatorach plików jednego dostawcy, nietypowym działaniu narzędzi lub założeniach o wyjściu konkretnego modelu nadal może wymagać świadomych zmian.

Uważamy, że to właściwa miara postępu. Przenośność ma wartość, gdy zmniejsza ilość kodu produktu wymagającego ponownego przeglądu. Liczba obsługiwanych dostawców mówi mniej niż skuteczna wymiana tej zależności, którą rzeczywisty produkt musi zmienić.

Definicja sukcesu nadal należy do aplikacji

Wspólne API nie sprawia, że dwa modele podejmują równoważne decyzje. Jeden lepiej przestrzega kontraktu danych strukturalnych, drugi inaczej reaguje na długą rozmowę lub niejednoznaczny wynik narzędzia. Adapter normalizuje drogę żądania, lecz nie dowodzi, że odpowiedź spełnia wymagania aplikacji.

Ma to konsekwencje dla testów. Oddziel testy integracji dostawcy od przykładów definiujących akceptowalne zachowanie produktu. Poprawnie zakończone żądanie sprawdza jeden kontrakt; trafna odpowiedź, właściwy wybór narzędzia i zrozumiały interfejs sprawdzają kolejne.

Asystent wsparcia może mieć narzędzie do wyszukiwania zamówienia oraz narzędzie do przygotowania wniosku o zwrot. Obaj dostawcy mogą poprawnie wywoływać je na poziomie protokołu. Ważne jest, czy każdy model wybiera właściwą operację, respektuje te same uprawnienia i dokładnie opisuje wynik.

Przed zmianą użyj małego, nazwanego zestawu oceny. Uwzględnij niepełne żądania, nietypowe dane, niedostępne narzędzie i rozmowę wznowioną po wcześniejszej turze. To proponowana procedura inżynierska, a nie benchmark TanStack. Ma pozwalać powtarzać własną definicję sukcesu zespołu.

Adapter może utrzymać kontrakt połączenia. Oceny właściwe dla aplikacji ustalają, czy zachowanie po drugiej stronie nadal jest akceptowalne.

Trzy projekty ujawniają różne rodzaje przenośności

Najpierw rozważmy istniejącą aplikację obsługi klientów. Ma już konta, uprawnienia i historię rozmów. Strumieniowane odpowiedzi powinny pasować do produktu bez wymiany nawigacji czy odpowiedzialności za dane. Wspólna warstwa AI jest atrakcyjna, jeśli pozwala zachować te struktury i oceniać dostawców za nimi.

W tym przykładowym projekcie zacznij od wyszukiwania pomocy tylko do odczytu. Sprawdź, czy odpowiedź cytuje dostarczone materiały i czy anulowanie pozostawia sensowny stan rozmowy. Dodaj działania, kiedy interfejs wyraźnie odróżnia propozycję od wykonanej operacji. Późniejsza zmiana modelu powinna wykorzystywać te same kontrole.

Drugi scenariusz to wewnętrzne narzędzie do pisania. Zespół chce umożliwić zaznaczenie akapitu, zamówienie poprawki i porównanie jej z oryginałem. Interfejsem jest edytor, nie zwykłe okno czatu. Integracja bez narzuconego UI pomaga, bo produkt musi decydować, gdzie pojawi się tekst i kiedy użytkownik go zaakceptuje.

Tutaj przenośność musi chronić pracę użytkownika. Nie nadpisuj oryginału tylko dlatego, że strumień się zakończył. Przechowuj sugestię oddzielnie, pozwól ją sprawdzić i określ sposób odrzucania przerwanych lub nieudanych generacji. To odpowiedzialność aplikacji niezależnie od SDK dostarczającego strumień.

Trzeci scenariusz dotyczy istniejącego backendu w innym języku. Oficjalny przykład AG-UI TanStack łączy klienta React z sześcioma możliwymi językami backendu przez Server-Sent Events. README wyjaśnia, że serwery implementują protokół bez serwerowych pakietów TanStack. Oficjalny przykład wielojęzyczny.

Ten przykład konkretyzuje przenośność. Zespół może ocenić interfejs przeglądarkowy bez natychmiastowego przepisywania działającego backendu. Nadal musi poprawnie implementować oczekiwane zdarzenia, zabezpieczyć endpoint i powiązać stan rozmowy z własnymi użytkownikami. Demonstracja zgodnego protokołu jest początkiem tej pracy.

Scenariusze pokazują, dlaczego wybór wykracza poza porównanie bibliotek czatu. Pytanie dotyczy tego, jak duża część produktu pozostaje spójna po zmianie komponentu. Nawet przy tym samym modelu różne zespoły cenią różne granice.

Stabilny rdzeń i eksperymentalny harness wymagają oddzielnych decyzji

Wydanie wyraźnie deklaruje 1.0 dla rdzenia, ale nowy harness agentów pozostaje przy eksperymentalnych API 0.x. Zapisz to jako dwie osobne decyzje dotyczące zależności. Instalacja obu nie rozszerza obietnicy stabilności rdzenia na harness. Ogłoszenie z 23 października.

Przy ograniczonej funkcji prosty cykl życia bywa łatwiejszy do zrozumienia: przychodzi żądanie, model pracuje, aplikacja obsługuje wynik. Długotrwały agent dodaje pytania o równoczesne wiadomości, odzyskiwanie, zapisany stan i działania trwające dłużej niż połączenie przeglądarki. Harness oferuje miejsce do uporządkowania tych zagadnień.

Status eksperymentalny jest informacją o utrzymaniu, nie powodem unikania wszystkich prób. Odizoluj ocenę od krytycznej ścieżki produktu, przypisz odpowiedzialność i zaplanuj zmiany API. Prototyp pozwala poznać wartość dłuższej interakcji, zanim zespół zobowiąże się ją obsługiwać.

Jeśli obecny cel to strumieniowana odpowiedź na istniejącym ekranie, zacznij od tego. Dodaj orkiestrację, gdy wymaga jej proces użytkownika. Bogatsza abstrakcja powinna rozwiązywać konkretny problem cyklu życia, a nie być warunkiem każdej niewielkiej funkcji AI.

Zacznij od małej, kompletnej interakcji

Aktualny przewodnik łączy trasę serwera, poświadczenia dostawcy i interfejs frameworka. Przykład React wykorzystuje serwerowe wywołanie modelu oraz SSE z jawnym identyfikatorem rozmowy. Klucz API pozostaje poza przeglądarką. Szybki start, sprawdzono 27 października 2026.

Pierwszą ocenę wykonaj według poniższej sekwencji na osobnej gałęzi. Celem jest interakcja możliwa do zbadania od żądania do wyniku. Nie trzeba migrować niepowiązanej infrastruktury, aby sprawdzić dopasowanie integracji.

1. Wybierz istniejący ekran i ograniczone zadanie. Pytanie tylko do odczytu o dostarczone materiały pomocy jest prostsze do sprawdzenia niż proces od razu zmieniający dane klientów.
2. Zainstaluj wspólnie stabilne pakiety interfejsu. Dla opisanego startu React/OpenAI użyj npm i @tanstack/ai@^1 @tanstack/ai-react@^1 @tanstack/ai-openai@^1. Zapisz plik blokady wersji w repozytorium, by identyfikować oceniane wydania.
3. Zaimplementuj granicę serwera według aktualnego przewodnika. Poświadczenia pozostają na serwerze. Powiąż żądanie z uwierzytelnionym użytkownikiem i identyfikatorem rozmowy zarządzanym przez aplikację.
4. Pokaż strumieniowanie, zakończenie i anulowanie. Użytkownik powinien wiedzieć, czy odpowiedź nadal napływa, zakończyła się czy została przerwana. Zachowaj dane wejściowe przy błędzie.
5. Wykonaj to samo zadanie z drugim wspieranym dostawcą. Nie zmieniaj materiałów ani przypadków oceny. Zapisuj osobno różnice zachowania i zmiany integracji.
6. Oceń wynik jako funkcję produktu. Przed rozszerzeniem sprawdź widok użytkownika, przechowywane dane i błędy wymagające interwencji.

Procedura jest celowo mała i powtarzalna. Udana odpowiedź cieszy, ale zrozumiały błąd dostarcza równie dużo informacji. Przydatna abstrakcja ułatwia utrzymanie obu ścieżek.

Aktualizacja z 0.x obejmuje również dane

Przewodnik migracji usuwa API wycofywane w 0.x i opisuje skoordynowane aktualizacje pakietów. Zapisane rozmowy, wykonania i pliki traktuje jako odrębny problem. Poprawna kontrola typów potwierdza więc tylko część gotowości. Przewodnik do 1.0, sprawdzono 27 października.

Łatwo to przeoczyć, gdy aplikacja działa poprawnie w nowej sesji. Nowa rozmowa może się udać, podczas gdy stara zawiera stan, którego nowy klient nie potrafi wznowić. Migracja musi obejmować reprezentatywne zapisane rekordy, nie tylko nowe żądania.

Przewodnik rozróżnia zmianę nazwy właściwości i dostarczenie poprawnej wartości. Jawny threadId wymaga rzeczywistego modelu własności; automatyczna edycja nie rozstrzygnie, jak trasa lub baza identyfikuje rozmowy. Podobnej opcji body w innej części API także nie należy zmieniać bezrefleksyjnym zastępowaniem tekstu.

Uruchom opisany codemod w trybie podglądu, przejrzyj różnice i aktualizuj stabilne pakiety klienta i serwera razem. Następnie wykonaj kroki dotyczące danych w środowisku testowym przed wdrożeniem. Eksperymentalny harness utrzymuj na udokumentowanej linii wydań, bez założenia, że wszystkie powiązane pakiety mają ten sam numer główny.

Aktualizacja jest zakończona, gdy nadal działają istniejące rozmowy i interfejs, a nie tylko kompiluje się nowy kod.

Zdefiniuj kontrolę wydania przez widoczne zachowania. Otwórz i kontynuuj istniejącą rozmowę, anuluj inną odpowiedź i sprawdź dozwoloną oraz zabronioną ścieżkę narzędzia. Potwierdź, że decyzja o uprawnieniach nadal dotyczy właściwego użytkownika. Pozwala to ocenić skutki bez traktowania wersji SDK jako oceny jakości.

Przenośność to utrzymywana zdolność do zmiany

TanStack AI 1.0 wskazuje użyteczny kierunek zespołom, które chcą świadomie wybierać modele i interfejsy. Najmocniejszy argument za wdrożeniem to aplikacja z wyraźną granicą, którą biblioteka upraszcza. Najsłabszy to oczekiwanie, że adapter usunie wszystkie różnice zachowania dostawców.

Praktyczny sprawdzian przychodzi przy drugiej zmianie: innym dostawcy, wznowionej rozmowie, zmienionym kontrakcie narzędzia lub starym rekordzie otwartym przez nowego klienta. Zachowaj obserwowalność tych zmian, a przenośność stanie się zdolnością operacyjną zamiast obietnicą w dokumencie architektury.

Źródła

• Ogłoszenie TanStack AI 1.0, 23 października 2026.
• Szybki start TanStack AI, sprawdzono 27 października 2026.
• Aktualizacja do 1.0, sprawdzono 27 października 2026.
• Oficjalny wielojęzyczny przykład AG-UI i licencja MIT, sprawdzono 27 października 2026. Scenariusze i procedura są ilustracyjne; nie wykonano porównawczego benchmarku dostawców.

Rekomendacja Telli.sh

Przechowuj żądania, materiały źródłowe i decyzje dotyczące integracji AI w przeszukiwalnej kolekcji. Utwórz konto Telli.sh, aby uporządkować notatki projektu i materiały do przeglądu.