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

Produkcja asystenta AI to nie „LLM z promptem”. To system, który przyjmuje intencję, utrzymuje stan, decyduje, kiedy odzyskiwać dane lub działać, oraz wystawia wystarczająco szczegółowe informacje runtime, aby debugować awarie.

To podejście systemowe jest tym, co cluster Systemy AI bada, gdy asystenci wychodzą poza pojedyncze wywołanie modelu.

OpenAI opisuje agenty jako aplikacje, które planują, wywołują narzędzia, współpracują i utrzymują wystarczająco dużo stanu do pracy wieloetapowej, podczas gdy Anthropic definiuje to samo zagadnienie jako zarządzany mechanizm, który może bezpiecznie uruchamiać pliki, komendy, dostęp do sieci i kod.

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

Pamięć powinna być traktowana jako coś więcej niż „dłuższy kontekst”. Systemy odzyskiwania danych przekształcają zewnętrzną wiedzę w eksplicitną pamięć nieparametryczną — to samo pole projektowe, które szczegółowo omawia Generowanie Wspomagane Odzyskiwaniem (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łania.

Użycie narzędzi to granica kontraktu, a nie magia. OpenAI function calling, Anthropic tool use i MCP polegają na tym samym wzorcu: model emituje strukturalne żądanie, pewien runtime je wykonuje, a wynik wraca do rozmowy. Jeśli ta granica jest niedokładna, asystent staje się niedokładny.

Mój uprzedzenie jest proste: zacznij od nudnego. Jeden orchestrator, jedna trwała ścieżka pamięci, jeden trace na żądanie i jedna eksplicitna polityka wykonania narzędzi. Grafy multi-agent są przydatne, ale dopiero po tym, jak będziesz mógł wyjaśnić przypadki awarii single-agent bez zgadywania.

Czym jest system asystenta AI

Praktyczna definicja brzmi tak: system asystenta AI to runtime, który przekształca intencję użytkownika w odpowiedź lub działanie, łącząc interfejs modelu, składanie kontekstu, wykonanie narzędzi, zarządzanie stanem i telemetrię. Dlatego użyteczne dokumenty to nie tylko karty modelu. Użyteczne dokumenty to referencje API, kontrakty narzędzi, przewodniki odzyskiwania, dokumentacja routingu i dokumentacja tracingu. OpenAI Responses API wystawia interakcje stanowe, wbudowane narzędzia i function calling. Anthropic Claude API wystawia bezpośredni dostęp Messages oraz Managed Agents. OpenClaw i Hermes idą o krok dalej i pokazują, co dzieje się, gdy umieszczasz te możliwości za trwałymi bramkami, kanałami, sesjami i pamięcią.

Innymi słowy, system asystenta ma szerszy kontrakt niż completion czatu. Dobry wewnętrzny kontrakt wygląda mniej więcej tak:

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

Ten kontrakt ma znaczenie, 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 trace mówi, że system spędził czas. OpenTelemetry definiuje trace jako ścieżkę żądania przez aplikację, co jest dokładnie abstrakcją, której potrzebują poważni asystenci. LangSmith i OpenLIT specjalizują tę ideę dla LLM, narzędzi, składow wektorowych i przepływów agentów.

Podstawowe komponenty i interfejsy

Podział komponentów poniżej jest tym, który uważam za najbardziej trwały. Jest to również podział, który najlepiej koresponduje z oficjalnymi API i open-source runtimes, które ludzie faktycznie obsługują.

Powyższa tabela jest pochodna z oficjalnych interfejsów dostawców, MCP, dokumentacji baz danych wektorowych oraz dokumentacji runtime dla vLLM, llama.cpp, OpenClaw i Hermes.

Warstwa LLM powinna dobrze robić trzy rzeczy: konsumować bieżący kontekst roboczy, emitować końcową odpowiedź lub strukturalne żądanie działania i zwracać wystarczająco metadanych do wsparcia ponownych prób i tracingu. OpenAI Responses API jest wyraźnie zaprojektowane dla interakcji stanowych plus wbudowanych narzędzi i function calling. Anthropic Messages API wystawia ten sam pętlę jądro przez bloki tool_use i zwrócenia tool_result, podczas gdy Managed Agents daje Ci hostowany mechanizm, jeśli nie chcesz budować pętli samemu. Samodzielnie hostowane runtimes 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 zasoby: pamięć roboczą, trwałą symboliczną pamięć i przeszukiwalną semantyczną pamięć. OpenAI embeddingi zwracają wektory, które można indeksować i przeszukiwać; OpenAI Retrieval i File Search nakładają semantyczne i słowowe wyszukiwanie na składow wektorowe. Pinecone, Weaviate, pgvector i Milvus reprezentują cztery wspólne kształty składow: w pełni zarządzane, open-source wektorowe natywne, Postgres-native i rozproszone bazy danych wektorowych. Hermes i OpenClaw dodają użyteczne przypomnienie, że nie cała pamięć należy do składow wektorowego: notatki oparte na plikach, zatwierdzone promocje i snapshoty zakresu sesji są często bardziej uczciwym projektem — wzorce rozpakowane w System Pamięci Agentów Hermes dla ograniczonej pamięci jądro i zamrożonych snapshotów sesji.

Warstwa narzędzi to miejsce, gdzie asystent przestaje być podsumowaczem i zaczyna być oprogramowaniem. OpenAI function calling traktuje narzędzia jako funkcjonalność zdefiniowaną schematem, którą model może zdecydować się wywołać. Anthropic mówi to samo bardziej eksplicitnie: użycie narzędzi to kontrakt między Twoją aplikacją a modelem, a model nigdy nic nie wykonuje samodzielnie. MCP uogólnia ten kontrakt do protokołu klient-serwer, gdzie hosty łączą się z jednym lub więcej serwerami, które wystawiają narzędzia, prompty i zasoby — ta sama granica opisana krok po kroku w Serwer MCP w Go. LangChain i LlamaIndex komfortowo tu siedzą jako biblioteki orkiestracji: LangChain koncentruje się na gotowej architekturze agenta i integracjach, podczas gdy LlamaIndex koncentruje się na dostępie do danych wspomaganych kontekstem, silnikach zapytań i przepływach.

Warstwa routingu istnieje, ponieważ „który model?” nigdy nie jest jedynym pytaniem. Potrzebujesz również „która ścieżka dostawcy, który tenant, który budżet, która klasa opóźnienia i który fallback?”. LiteLLM jest przydatne, ponieważ jego oficjalne dokumenty są odświeżająco konkretne: ważony wybór, najmniej zajęty, routing oparty na opóźnieniu, routing oparty na kosztach i ograniczone failovery to wszystko pierwsze klasy wzorców. OpenClaw rozszerza routing do góry do izolacji kanałów i agentów, podczas gdy Hermes rozszerza go do dołu do slotów modeli dla pracy głównej i pomocniczej, takiej jak kompresja, podsumowanie i routing narzędzi MCP. To jest poprawny model mentalny: router wybiera więcej niż model, wybiera ścieżkę wykonania.

Warstwa obserwowalności to to, co zapobiega temu, aby architektura stała się folklorem. OpenTelemetry daje Ci abstrakcję trace. 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 obserwowalność AI natywną dla OpenTelemetry z opcjami zero-code i ręcznego instrumentowania, w tym wsparciem dla LLM, frameworków agentów, baz danych wektorowych i GPU. Dla metryk produkcyjnych, trace i wzorców SLO przez wnioskowanie i przepływy agentów, zobacz Obserwowalność dla Systemów LLM. Jeśli Twój asystent nie ma trace na żądanie, nie ma span na wywołanie modelu i nie ma historii zdarzeń dla wykonania narzędzi, nie masz naprawdę architektury. Masz vibe.

Złap, wzbogać, odpowiedz

Sekwencja, która ciągle pojawia się w rzeczywistych systemach, to capture -> enrich -> respond -> record. Różne frameworki owijają to inaczej, ale przepływ jest na tyle stabilny, aby traktować go jako kręgosłup.

sequenceDiagram
    participant U as User or Channel
    participant G as Gateway or UI
    participant R as Router
    participant M as Memory and Retrieval
    participant L as LLM
    participant T as Tools or MCP
    participant O as Observability

    U->>G: message, file, or command
    G->>O: start root trace
    G->>R: request + identity + session + policy
    R->>M: load session state and retrieve context
    M-->>R: notes, chunks, metadata
    R->>L: prompt + context + tool schemas
    L-->>R: answer or tool call
    alt tool call
        R->>T: execute tool or MCP action
        T-->>R: tool result
        R->>L: tool result + updated context
        L-->>R: final answer
    end
    R->>M: persist session changes and memory candidates
    R->>O: spans, metrics, eval events
    G-->>U: response

Krok capture jest zwykle ważniejszy, niż się wydaje. OpenClaw i Hermes umieszczają trwałą bramkę przed asystentem, ponieważ ingress to nie tylko wprowadzanie tekstu. Obejmuje metadane kanału, tożsamości, autoryzację, granice sesji, wiadomości bezpośrednie, grupy, ticty cron i semantykę dostawy. Jeśli pominiesz tę warstwę i polegasz na abstrakcji surowego widżetu czatu, ostatecznie podbijesz ją z powrotem jako ad hoc middleware.

Krok enrich to miejsce, gdzie dojrzałe systemy odbiegają od zabawnych demo. OpenAI Retrieval i File Search czynią odzyskiwanie eksplicitnym przez składow wektorowe i wywołania wyszukiwania. LlamaIndex formalizuje ten sam wzorzec przez konektory danych, indeksy, silniki zapytań i przepływy. Hermes idzie dalej, dzieląc majątek modeli na sloty główne i pomocnicze, zlecając pracę, taką jak kompresja, podsumowanie i routing, mniejszym lub bardziej specjalizowanym modelom. To jest wzorzec projektowy wart skradania: nie wydawaj swoich najdroższych tokenów modelu na chores.

Krok respond to nie „generuj tekst”. To „zamknij bieżącą pętlę”. Jeśli model może odpowiedzieć bezpośrednio, robi to. Jeśli potrzebuje narzędzia, emituje strukturalne żądanie. Kontrakt użycia narzędzi Anthropic i przewodnik function calling OpenAI czynią to eksplicitnym. 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ą i częściowo planem runtime.

Krok record to miejsce, gdzie pojawiają się semantyki spójności. Pinecone oddziela ścieżki zapisu i odczytu i przetwarza zapisy po trwałym potwierdzeniu. Pamięć Hermes jest wstrzykiwana jako zamrożony snapshot na sesję, więc może zachować wydajność prefix-cache, co oznacza, że nowe zapisy nie pojawiają się automatycznie w bieżącym prompcie sesji. System Dreaming OpenClaw promuje tylko zatwierdzone, uziemione kandydaty do MEMORY.md, a jest to opcjonalne, a nie zawsze włączone. Praktyczną lekcją jest to, że pamięć rzadko jest naprawdę read-after-write przez każdą warstwę. 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 prezentują asystenta jako system długotrwały z bramkami, sesjami, narzędziami, pamięcią i wieloma backendami modeli.

To mapowanie jest uziemione w oficjalnych dokumentach i repozytoriach OpenClaw i Hermes. OpenClaw dokumentuje architekturę bramki, routing multi-agent, wsparcie dla dostawców custom i samodzielnie hostowanych, w tym vLLM i Ollama, opcjonalną aktywną pamięć i promocję opartą na Dreaming. Hermes dokumentuje bramkę messaging, centralną pętlę AIAgent, sloty modeli główne i pomocnicze, wbudowaną pamięć i natywną integrację MCP.

Moja nieco opiniacyjna interpretacja mówi, że oba systemy czynią ten sam argument architektoniczny w różnych akcentach. OpenClaw jest silnie gateway-first. Hermes jest silnie agent-loop-first. 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 heterogenność backendu jako pierwsze klasy zagadnień. To jest dokładnie to, co powinna robić architektura produkcyjna.

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

edge:
  gateway: hermes or openclaw

routing:
  proxy: litellm
  policy: latency and budget aware
  tenancy: session and channel scoped

llm:
  primary: openai responses or anthropic messages
  local_fallback: vllm
  local_dev: ollama or llama.cpp

memory:
  session: sqlite or postgres
  semantic: pgvector or weaviate
  embeddings: openai embeddings or ollama embeddings

tools:
  contract: json schema tools plus mcp
  examples: filesystem, browser, web search, internal APIs

observability:
  traces: opentelemetry
  ai_dashboards: openlit or langsmith
  evals: openai evals plus app-specific regression sets

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

Wzorce, tabele i kompromisy

Istnieje kilka powtarzalnych wzorców asystentów, które warto nazwać. Zarządzany asystent utrzymuje większość runtime w API dostawcy. Asystent retrieval-first traktuje pamięć i wyszukiwanie jako główny wyróżnik. Asystent tool-first zachowuje się bardziej jak operator niż chatbot. Asystent gateway priorytetyzuje dostęp always-on przez powierzchnie messaging. Siatka specjalistów dekomponuje pracę na wielu agentów lub trasy. Oficjalne dokumenty przez OpenAI, Anthropic, LlamaIndex, LiteLLM, OpenClaw i Hermes wspierają wersje tych wzorców, nawet jeśli nazywają je inaczej.

Ta tabela wzorców to syntez z dokumentów dostawców, dokumentów frameworków i systemów referencyjnych, a nie roszczenie od żadnego jednego dostawcy.

Uwagi do tabeli: OpenAI hostowane File Search 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ą w różnym stopniu operacje samodzielnie zarządzane lub hybrydowe.

Uwagi do tabeli: Pinecone dokumentuje zarządzaną płaszczyznę kontroli 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, wysokowydajna, skalowalna baza danych wektorowych, z Zilliz Cloud jako opcją zarządzaną.

Uwagi do tabeli: OpenAI dokumentuje Responses jako swój zaawansowany interfejs dla odpowiedzi stanowych i wbudowanych narzędzi. Anthropic dokumentuje API Messages i kontrakt użycia narzędzi osobno od Managed Agents. vLLM wystawia serwer zgodny z OpenAI plus wsparcie API Messages Anthropic. Ollama dokumentuje przepływy embeddingu i modelu lokalnego. llama.cpp dokumentuje chat, odpowiedzi i ścieżki embeddingu zgodne z OpenAI, plus uzupełnienia chat zgodne z Anthropic.

Ta macierz kompromisów to wnioskowanie architektoniczne z oficjalnych dokumentów, a nie benchmark dostawcy. Wiersz spójności ma większe znaczenie, niż przyznaje wiele blogów: Pinecone oddziela ścieżki zapisu i odczytu, Hermes zamraża pamięć w promptach startowych sesji, a OpenClaw promuje trwałą pamięć przez etapowy przegląd. To oznacza, ż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 dowodów dla tej tabeli jest szeroka, ale spójna. Dokumenty narzędzi Anthropic czynią jasne, że użycie narzędzi to granica kontraktu. OpenAI Guardrails obejmuje wykrywanie halucynacji przeciwko referencyjnej bazie wiedzy przez File Search. SelfCheckGPT pokazuje, że spójność własna przez próbki może pomóc wykryć niepoparte twierdzenia. 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: traceuj każde żądanie, wersjonuj prompty, evaluj odzyskiwanie niezależnie, trzymaj narzędzia idempotentne i uruchamiaj evali regresyjne przed zmianą tras lub polityki pamięci. Dokumenty Evals OpenAI i repo są bezpośrednie, dlaczego: bez evali, trudno i czasochłonne zrozumienie, jak zmiany modelu lub promptu wpływają na Twój przypadek użycia. To dotyczy tak samo routerów i odzyskiwania, jak promptów.

Więcej do czytania

Jeśli chcesz wejść głębiej, oto najprzydatniejsze pierwotne źródła, które należy trzymać otwarte podczas projektowania lub przeglądania architektury asystenta.

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

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

• Sam MCP: Przegląd Architektury i Specyfikacja są warte przeczytania bezpośrednio, ponieważ wyjaśniają hosty, klientów, serwery, narzędzia, prompty, zasoby, transport i negocjacje możliwości czysto.

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

• Samodzielnie hostowane runtimes i systemy asystentów: vLLM, serwer llama.cpp, embeddingi Ollama, dokumentacja i repo OpenClaw, dokumentacja i repo Hermes.

• Składow i obserwowalność: Pinecone, Weaviate, pgvector, Milvus, OpenTelemetry, OpenLIT.

• Artykuły badawcze: Retrieval-Augmented Generation dla Złożonych Zadania NLP, Lost in the Middle i SelfCheckGPT.