Architektura asystenta AI: LLM, pamięć, narzędzia, routing, obserwowalność

Produkcjny asystent AI to nie „LLM z promptem”. To system, który przyjmuje intencję, utrzymuje stan, decyduje, kiedy pobierać dane lub wykonywać akcje, oraz udostępnia wystarczająco szczegółowych danych środowiska uruchomieniowego do debugowania awarii.

To systemowe podejście jest przedmiotem eksploracji w klasterze AI Systems, gdy asystenci wykraczają poza pojedyncze wywołanie modelu.

OpenAI opisuje agenty jako aplikacje, które planują, wywołują narzędzia, współpracują i utrzymują wystarczający stan do pracy wieloetapowej, podczas gdy Anthropic definiuje ten sam problem jako zarządzany mechanizm, który może bezpiecznie uruchamiać pliki, polecenia, dostęp do sieci i kod.

Najczystsza architektura dzieli odpowiedzialności na pięć warstw: LLM, Pamięć, Narzędzia, Routing i Obserwowalność. To podział odzwierciedla możliwości udostępniane przez główne API dostawców, protokół MCP, samodzielnie hostowane środowiska uruchomieniowe, takie jak vLLM i llama.cpp, oraz rzeczywiste systemy asystentów, takie jak OpenClaw oraz Hermes.

Pamięć powinna być traktowana jako coś więcej niż „dłuższy kontekst”. Systemy wyszukiwania zamieniają zewnętrzną wiedzę w jawne, nieparametryczne pamięci — ten sam obszar projektowy jest szczegółowo omawiany w Retrieval-Augmented Generation (RAG) — zarówno wytyczne Anthropic dotyczące kontekstu, jak i artykuł „Lost in the Middle” ostrzegają, że samo wciskanie większej liczby tokenów do kontekstu nie gwarantuje niezawodnego przywoływania.

Używanie narzędzi to granica kontraktu, a nie magia. Wywoływanie funkcji OpenAI, używanie narzędzi Anthropic oraz MCP opierają się na tym samym wzorcu: model emituje strukturalne żądanie, pewne środowisko uruchomieniowe je wykonuje, a wynik wraca do rozmowy. Jeśli ta granica jest luźna, asystent staje się niedokładny.

Moja opinia jest prosta: zacznij od nudnego rozwiązania. Jeden orkiestrator, jedna trwała ścieżka pamięci, jeden ślad na żądanie i jedna jawna polityka wykonywania narzędzi. Grafy wieloagentowe są przydatne, ale dopiero po tym, jak będziesz mógł wyjaśnić przypadki awarii pojedynczego agenta bez zgadywania.

czym jest system asystenta AI

Praktyczna definicja brzmi następująco: system asystenta AI to środowisko uruchomieniowe, które przekształca intencję użytkownika w odpowiedź lub akcję, łącząc interfejs modelu, składanie kontekstu, wykonywanie narzędzi, zarządzanie stanem i telemetrię. Dlatego użyteczne dokumenty to nie tylko karty modeli. Użyteczne dokumenty to odniesienia do API, kontrakty narzędzi, przewodniki po wyszukiwaniu, dokumentacja routingu i dokumentacja śledzenia. API Responses OpenAI udostępnia interakcje ze stanem, wbudowane narzędzia i wywoływanie funkcji. API Claude Anthropic udostępnia bezpośredni dostęp do Messages oraz Managed Agents. OpenClaw i Hermes idą krok dalej i pokazują, co się dzieje, gdy umieścisz te możliwości za trwałymi bramkami, kanałami, sesjami i pamięcią.

Mówiąc inaczej, system asystenta ma szerszy kontrakt niż uzupełnienie czatu. Dobry wewnętrzny kontrakt wygląda mniej więcej tak:

AssistantRequest  = intencja użytkownika + tożsamość + sesja + załączniki + polityka
AssistantResponse = odpowiedź + akcje + cytowania + zmiany stanu + identyfikator śledzenia

Ten kontrakt jest ważny, ponieważ każda produkcyjna nieporozumienie ostatecznie sprowadza się do jednego z tych pytań: jaki kontekst był widoczny, które narzędzie zostało wykonane, który model odpowiedział, która pamięć została odczytana lub zapisana i gdzie śledzenie wskazuje, że system spędził czas. OpenTelemetry definiuje śledzenia jako ścieżkę żądania przez aplikację, co jest dokładnie abstrakcją potrzebną poważnym asystentom. LangSmith i OpenLIT specjalizują tę koncepcję dla LLM, narzędzi, baz danych wektorowych i przepływów agentów.

Podstawowe komponenty i interfejsy

Poniższy podział komponentów jest tym, który uważam za najbardziej trwały. To również podział, który najlepiej koreluje z oficjalnymi API i open-source’owymi środowiskami uruchomieniowymi, które ludzie faktycznie eksploatują.

Powyższa tabela została opracowana na podstawie oficjalnych interfejsów dostawców, MCP, dokumentacji baz danych wektorowych oraz dokumentacji środowisk uruchomieniowych vLLM, llama.cpp, OpenClaw i Hermes.

Warstwa LLM powinna dobrze robić trzy rzeczy: konsumować bieżący kontekst roboczy, emitować ostateczną odpowiedź lub strukturalne żądanie akcji oraz zwracać wystarczająco metadanych do wspierania ponownych prób i śledzenia. API Responses OpenAI jest wyraźnie zaprojektowane dla interakcji ze stanem oraz wbudowanych narzędzi i wywoływania funkcji. API Messages Anthropic udostępnia ten sam podstawowy pętli przez bloki tool_use i zwracane tool_result, podczas gdy Managed Agents daje Ci zarządzany mechanizm, jeśli nie chcesz budować tej pętli samodzielnie. Samodzielnie hostowane środowiska uruchomieniowe, takie jak vLLM i llama.cpp, mają znaczenie, ponieważ zachowują znajome interfejsy stylu dostawcy, pozwalając Ci umieścić wnioskowanie w swoim własnym środowisku.

Warstwa pamięci powinna być mentalnie podzielona na trzy zasobniki: pamięć roboczą, trwałą pamięć symboliczną i przeszukiwaną pamięć semantyczną. Wektory OpenAI zwracają wektory, które mogą być indeksowane i przeszukiwane; Wyszukiwanie i Wyszukiwanie Plików OpenAI nakłada wyszukiwanie semantyczne i słów kluczowych na magazyny wektorowe. Pinecone, Weaviate, pgvector i Milvus reprezentują cztery wspólne kształty magazynowania: w pełni zarządzane, open-source’owe natywne wektorowe, natywne dla Postgres’a i rozproszone bazy danych wektorowych. Hermes i OpenClaw dodają przydatne przypomnienie, że nie cała pamięć należy do magazynu wektorowego: notatki oparte na plikach, sprawdzone promocje i migawki zakresu sesji są często bardziej uczciwym projektem. Systemy Pamięci w Asystentach AI mapuje model międzyramowy; System Pamięci Agentów Hermesa omawia ograniczoną pamięć rdzeniową i zamrożone migawki sesji w jednym produkcie.

Warstwa narzędzi to miejsce, gdzie asystent przestaje być podsumowującym i zaczyna być oprogramowaniem. Wywoływanie funkcji OpenAI traktuje narzędzia jako zdefiniowaną schematem funkcjonalność, którą model może zdecydować się wywołać. Anthropic mówi to samo bardziej jawnie: używanie narzędzi to kontrakt między Twoją aplikacją a modelem, a model nigdy nie wykonuje niczego samodzielnie. MCP uogólnia ten kontrakt do protokołu klient-serwer, gdzie gospodarze łączą się z jednym lub więcej serwerami, które udostępniają narzędzia, prompty i zasoby — tę samą granicę opisaną krok po kroku w Serwer MCP w Go. LangChain i LlamaIndex wygodnie mieszczą się tutaj jako biblioteki orkiestracyjne: LangChain koncentruje się na gotowej architekturze agenta i integracjach, podczas gdy LlamaIndex koncentruje się na dostępie do danych wzmocnionych kontekstem, silnikach zapytań i przepływach pracy.

Warstwa routingu istnieje, ponieważ „który model?” to nigdy nie jedyne pytanie. Potrzebujesz też „która ścieżka dostawcy, który najemca, który budżet, która klasa opóźnienia i który awaryjny?”. LiteLLM jest przydatny, ponieważ jego oficjalna dokumentacja jest orzeźwiająco konkretna: ważony wybór, najmniej zajęty, routing oparty na opóźnieniu, routing oparty na koszcie i ograniczone awarie to wszystko pierwszoklasowe wzorce. OpenClaw rozszerza routing w górę do izolacji kanałów i agentów, podczas gdy Hermes rozszerza go w dół do slotów modeli dla pracy głównej i pomocniczej, takiej jak kompresja, podsumowanie i routing narzędzi MCP. To właściwy model umysłowy: router wybiera więcej niż model, wybiera ścieżkę wykonania.

Warstwa obserwowalności to to, co zapobiega przekształcaniu architektury w legendy. OpenTelemetry daje Ci abstrakcję śledzenia. LangSmith daje Ci widoczność end-to-end nad krokami aplikacji LLM i wspiera kształty wdrożeń chmurowych, hybrydowych i samodzielnie hostowanych. OpenLIT daje Ci natywną obserwowalność AI OpenTelemetry z opcjami instrumentacji zerowego kodu i ręcznej, w tym wsparciem dla LLM, ram agentów, baz danych wektorowych i GPU. Dla metryk produkcyjnych, śledzeń i wzorców SLO w wnioskowaniu i przepływach agentów, zobacz Obserwowalność dla Systemów LLM. Jeśli Twój asystent nie ma śledzenia na żądanie, rozpięcia na wywołanie modelu i historii zdarzeń dla wykonania narzędzi, nie masz naprawdę architektury. Masz wibracje.

Przechwytywanie, wzbogacanie, odpowiadanie

Sekwencja, która ciągle pojawia się w rzeczywistych systemach, to przechwytywanie -> wzbogacanie -> odpowiadanie -> rejestrowanie. Różne ramy owijają to inaczej, ale przepływ jest wystarczająco stabilny, aby traktować go jako kręgosłup.

Krok przechwytywania jest zwykle ważniejszy, niż się wydaje. Zarówno OpenClaw, jak i Hermes umieszczają trwałą bramkę przed asystentem, ponieważ wejście to nie tylko wprowadzanie tekstu. Obejmuje metadane kanału, tożsamości, autoryzację, granice sesji, wiadomości bezpośrednie, grupy, tik cron i semantykę dostawy. Jeśli pominiesz tę warstwę i polegaj na abstrakcji surowego widżetu czatu, ostatecznie dołożysz ją z powrotem jako ad hoc middleware.

Krok wzbogacania to miejsce, gdzie dojrzałe systemy różnią się od demo zabawek. Wyszukiwanie i Wyszukiwanie Plików OpenAI czyni wyszukiwanie jawnym poprzez magazyny wektorowe i wywołania wyszukiwania. LlamaIndex formalizuje ten sam wzorzec poprzez konektory danych, indeksy, silniki zapytań i przepływy pracy. Hermes idzie dalej, dzieląc posiadanie modeli na sloty główne i pomocnicze, delegując pracę, taką jak kompresja, podsumowanie i routing, na mniejsze lub bardziej specjalizowane modele. To wzorzec projektowy wart skradnięcia: nie wydawaj najdroższych tokenów modelu na chores.

Krok odpowiadania to nie „generuj tekst”. To „zamknij bieżącą pętlę”. Jeśli model może odpowiedzieć bezpośrednio, to robi. Jeśli potrzebuje narzędzia, emituje strukturalne żądanie. Kontrakt używania narzędzi Anthropic i przewodnik wywoływania funkcji OpenAI czynią to jawnym. Powód, dla którego to ma znaczenie architektonicznie, to fakt, że wyjścia obejmują teraz zarówno język, jak i przepływ sterowania. Twój obiekt odpowiedzi jest częściowo prozą, a częściowo planem środowiska uruchomieniowego.

Krok rejestrowania to miejsce, gdzie pojawia się semantyka spójności. Pinecone oddziela ścieżki zapisu i odczytu i przetwarza zapisy po trwałym potwierdzeniu. Pamięć Hermesa jest wstrzykiwana jako zamrożona migawka na sesję, więc może zachować wydajność cache prefiksu, co oznacza, że nowe zapisy nie pojawiają się automatycznie w promptach bieżącej sesji. System Dreaming OpenClaw promuje tylko sprawdzone, ugruntowane kandydaty do MEMORY.md, a jest to opcja rather niż zawsze włączona. Praktyczna lekcja polega na tym, że pamięć rzadko jest naprawdę odczyt-po-zapisie na każdej warstwie. Musisz projektować dla stopniowej widoczności.

OpenClaw i Hermes jako systemy referencyjne

OpenClaw i Hermes są przydatnymi przypadkami referencyjnymi, ponieważ nie są tylko opakowaniami wokół jednego API dostawcy. Obie przedstawiają asystenta jako długotrwały system z bramkami, sesjami, narzędziami, pamięcią i wieloma backendami modeli.

To mapowanie jest oparte na oficjalnej dokumentacji i repozytoriach OpenClaw i Hermes. OpenClaw dokumentuje architekturę bramki, routing wieloagentowy, wsparcie dla niestandardowych i samodzielnie hostowanych dostawców, w tym vLLM i Ollama, opcjonalną aktywną pamięć i promocję opartą na Dreaming. Hermes dokumentuje bramkę wiadomości, centralną pętlę AIAgent, sloty modeli główne i pomocnicze, wbudowaną pamięć i natywną integrację MCP.

Moja lekko opiniowana interpretacja polega na tym, że oba systemy wysuwają ten sam argument architektoniczny w różnych akcentach. OpenClaw jest silnie bramkowy. Hermes jest silnie pętlowy agent. Ale oba odrzucają płytką ideę, że asystent to tylko „prompt plus model”. Modelują kanały, tożsamości, semantykę pamięci, powierzchnie narzędzi i heterogeniczność backendu jako pierwszoklasowe problemy. To dokładnie to, co powinna robić produkcyjna architektura.

Praktyczny stos hybrydowy inspirowany przez oba systemy wygląda tak:

edge:
  gateway: hermes lub openclaw

routing:
  proxy: litellm
  policy: świadomy opóźnień i budżetu
  tenancy: zakres sesji i kanału

llm:
  primary: odpowiedzi openai lub komunikaty anthropic
  local_fallback: vllm
  local_dev: ollama lub llama.cpp

memory:
  session: sqlite lub postgres
  semantic: pgvector lub weaviate
  embeddings: wektory openai lub wektory ollama

tools:
  contract: narzędzia ze schematem json plus mcp
  examples: system plików, przeglądarka, wyszukiwanie sieci, wewnętrzne API

observability:
  traces: opentelemetry
  ai_dashboards: openlit lub langsmith
  evals: ewaluacje openai plus specyficzne dla aplikacji zbiory regresji

Ten stos to przemyślane wzorzec wdrożenia, a nie blueprint narzucony przez dostawcę. Działa, ponieważ oficjalne interfejsy się zgadzają: OpenAI i Anthropic udostępniają API zorientowane na narzędzia, vLLM i llama.cpp emulują punkty końcowe stylu dostawcy, Ollama obsługuje lokalne modele i wektory, MCP standaryzuje zewnętrzne narzędzia, LiteLLM obsługuje routing i awarie, a platformy zgodne z OpenTelemetry mogą śledzić całą ścieżkę.

Wzorce, tabele i kompromisy

Istnieje kilka powtarzalnych wzorców asystentów, które warto nazwać. Zarządzany asystent utrzymuje większość środowiska uruchomieniowego w API dostawcy. Asystent oparty na wyszukiwaniu traktuje pamięć i wyszukiwanie jako główną różnicę. Asystent oparty na narzędziach zachowuje się bardziej jak operator niż bot czatu. Asystent bramkowy priorytetyzuje dostęp always-on poprzez powierzchnie wiadomości. Specjalistyczna siatka dekomponuje pracę na wielu agentów lub trasy. Oficjalne dokumenty z OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw i Hermes wspierają wersje tych wzorców, nawet jeśli nazywają je inaczej.

Wzorzec specjalistycznej siatki rozwija się w odrębną dyscyplinę inżynieryjną wraz ze wzrostem liczby agentów. Dla sześciu kanonicznych wzorców koordynacji — orkiestrator-pracownik, sekwencyjny potok, rozproszenie, hierarchiczny, rojowy i siatkowy — ze specyficznymi trybami awarii i ramą decyzyjną produkcyjną, zobacz Wzorce Orkiestracji Wieloagentowej.

Ta tabela wzorców to syntezę z dokumentów dostawców, dokumentów ram i systemów referencyjnych, a nie twierdzenie od jednego dostawcy.

Noty tabeli: Hostowane Wyszukiwanie Plików OpenAI to zarządzane narzędzie, Anthropic oferuje zarządzany mechanizm, Pinecone to zarządzana usługa wektorowa, podczas gdy vLLM, llama.cpp, Ollama, pgvector, Weaviate, Milvus, samodzielnie hostowany LangSmith i OpenLIT wspierają operacje samodzielnie zarządzane lub hybrydowe w różnym stopniu.

Noty tabeli: Pinecone dokumentuje zarządzaną płaszczyznę sterowania i regionalne płaszczyzny danych. Weaviate dokumentuje wektory i indeksy odwrócone z wieloma typami indeksów wektorowych. pgvector dodaje dokładne i przybliżone wyszukiwanie najbliższego sąsiada do Postgres. Milvus pozycjonuje się jako open-source’owa, wysokiej wydajności, skalowalna baza danych wektorowych, z Zilliz Cloud jako opcją zarządzaną.

Noty tabeli: OpenAI dokumentuje Responses jako swój zaawansowany interfejs dla odpowiedzi ze stanem i wbudowanych narzędzi. Anthropic dokumentuje API Messages i kontrakt używania narzędzi osobno od Managed Agents. vLLM udostępnia serwer zgodny z OpenAI plus wsparcie API Messages Anthropic. Ollama dokumentuje lokalne przepływy wektorów i modeli. llama.cpp dokumentuje czat, odpowiedzi i wektory zgodne z OpenAI, plus ukończenia czatu zgodne z Anthropic.

Ta macierz kompromisów to wnioskowanie architektoniczne z oficjalnej dokumentacji, a nie benchmark dostawcy. Wiersz spójności ma większe znaczenie niż przyznaje wiele wpisów blogowych: Pinecone oddziela ścieżki zapisu i odczytu, Hermes zamraża pamięć w promptach startu sesji, a OpenClaw promuje trwałą pamięć poprzez stopniowe sprawdzanie. Oznacza to, że „pamięć zaktualizowana” i „pamięć widoczna dla bieżącej odpowiedzi” to często różne prawdy.

Tryby awarii i łagodzenie

Większość asystentów nie zawodzi, ponieważ podstawowy model jest „zły”. Zawodzą, ponieważ otaczający system kłamie modelowi, głodzi go odpowiedniego kontekstu, pozwala narzędziom dryfować lub czyni debugowanie niemożliwym.

Baza dowodowa dla tej tabeli jest szeroka, ale spójna. Dokumenty narzędzi Anthropic czynią jasne, że używanie narzędzi to granica kontraktu. Guardrails OpenAI obejmuje wykrywanie halucynacji przeciwko referencyjnej bazie wiedzy poprzez Wyszukiwanie Plików. SelfCheckGPT pokazuje, że spójność własna między próbkami może pomóc w wykrywaniu nieobsługiwanych twierdzeń. Wyniki „Lost in the Middle” i wytyczne kontekstu Anthropic wzmacniają tę samą lekcję operacyjną: więcej tokenów nie usuwa potrzeby kuracji kontekstu.

Preferowany stos łagodzenia może być nudny i powtarzalny: śledź każde żądanie, wersjonuj prompty, ewaluuj wyszukiwanie niezależnie, trzymaj narzędzia idempotentne i uruchamiaj ewaluacje regresji przed zmianą tras lub polityki pamięci. Dokumenty i repozytorium Evals OpenAI są bezpośrednie w sprawie dlaczego: bez ewaluacji trudno i czasochłonnie jest zrozumieć, jak zmiany modelu lub promptu wpływają na Twój przypadek użycia. To dotyczy routingu i wyszukiwania tak samo, jak promptów.

Więcej czytania

Jeśli chcesz iść głębiej, oto najprzydatniejsze pierwotne źródła do otwarcia podczas projektowania lub przeglądania architektury asystenta.

• OpenAI: Przegląd Responses, Wywoływanie Funkcji, Używanie Narzędzi, Wyszukiwanie, Wyszukiwanie Plików, Evals i MCP dla zdalnych serwerów narzędzi.

• Anthropic: Przegląd API, Używanie Narzędzi, kontrakt używania narzędzi, Managed Agents, Okna Kontekstu i konektor MCP.

• Sam MCP: Przegląd Architektury i Specyfikacja są warte bezpośredniego przeczytania, ponieważ wyjaśniają gospodarzy, klientów, serwery, narzędzia, prompty, zasoby, transporty i negocjacje możliwości czysto. Dla praktycznego porównania MCP z protokołem Agent2Agent i kiedy system wieloagentowy potrzebuje obu warstw, zobacz A2A vs MCP: Czy Agenty AI Naprawdę Potrzebują Obojga Protokołów? i dla samych koncepcji A2A — Karty Agentów, cykl życia zadań, wiadomości, części i artefakty — zobacz Czym Jest Protokół A2A? Wyjaśnienie Kart Agentów i Zadań.

• Asystenci tła i proaktywni: warstwa narzędzi to tylko jedna część tego, jak asystenci działają. Aby dowiedzieć się, jak sprawić, aby asystent patrzył, decydował i działał samodzielnie — harmonogramy, pracownicy oparte na kolejkach, protokoły roszczeń, trwałe przepływy pracy i semantyczne polling — zobacz Agentów Polling w Asystentach AI: 11 Wzorców Implementacji.

• Protokół A2A i adopcja: gdy agenty są niezależnie wdrożone i potrzebują współpracy przez granice własności, A2A staje się istotny. Dla praktycznego widzenia 2026, gdzie A2A faktycznie ma trakcję, pytania bezpieczeństwa, które podnosi, i ramę decyzyjną, kiedy go adoptować, zobacz Protokół A2A Google w 2026: Adopcja, Hype i Rzeczywistość. Gdy te agenty wymieniają długotrwałe zadania zamiast pojedynczych tur czatu, Streaming A2A i Asynchroniczne Zadania dla Długotrwałych Przepływów Roboczych Agentów omawia projekt SSE, push i input_required na granicy protokołu.

• Ramy i routing: Przegląd LangChain, dokumentacja wzmocnienia kontekstu LlamaIndex, dokumentacja routingu LiteLLM, dokumentacja obserwowalności LangSmith.

• Samodzielnie hostowane środowiska uruchomieniowe i systemy asystentów: vLLM, serwer llama.cpp, wektory Ollama, dokumentacja i repozytorium OpenClaw, dokumentacja i repozytorium Hermes.

• Przechowywanie i obserwowalność: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Artykuły badawcze: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Lost in the Middle i SelfCheckGPT.