Możliwość obserwacji produkcji dla Multi-Agent AI (z KAOS + OTel + SigNoz)

Praktyczny przewodnik po dodaniu obserwacji na poziomie produkcyjnym do systemów AI z wieloma agentami za pomocą systemu K8s Agent Orchestration System przy użyciu OpenTelemetry i SigNoz Stworzyłeś agenta sztucznej inteligencji, który działa w twoim laptopie. automatycznie łańcuchuje narzędzia, deleguje zadania do specjalistycznych podagentów i produkuje dobre wyniki. Następnie wprowadź je do produkcji: Użytkownik zgłasza, że żądanie „wzięło się na zawsze”. Inni twierdzą, że otrzymali dziwną odpowiedź. Twoje dzienniki pokazują, że agent pobiegł Ale co się stało w tych 45 sekundach między prośbą a odpowiedzią? Witamy w observability challenge of agentic systems. „Tradycyjne dzienniki mówią, że to działało, obserwacja mówi, dlaczego to działało w ten sposób.” „Tradycyjne dzienniki mówią, że to działało, obserwacja mówi, dlaczego to działało w ten sposób.” W tym artykule przejdziemy przez kompletny przykład obserwacyjności dla systemów wielodzietnych. Poniżej znajduje się przegląd systemu wielu agentów, który będziemy analizować, monitorować i diagnozować w tym poście: Zacznijmy od głównego pytania o... Dlaczego systemy wielodzietne potrzebują (różnej) obserwacji? Tradycyjne mikrosłużby mają przewidywalne wzorce: pojawia się żądanie, następuje pewne przetwarzanie, wygasa odpowiedź. To nie tylko prośba o odpowiedź Systemy agencji łamią tradycyjne założenia: Traditional API Agentic System Synchronous request-response Iterative reasoning loops Predictable latency (50-500ms) Variable: 100ms to 60+ seconds Deterministic code paths Non-deterministic LLM decisions Single service per request Model calls + tool calls + delegations Fixed cost per request Cost varies by token usage Synchroniczna reakcja na żądanie Iteratywne łańcuchy rozumowania Przewidywalna latentność (50-500ms) Zmiana: od 100 ms do 60+ sekund Deterministyczne ścieżki kodowania Nie-deterministyczne decyzje LLM Pojedyncza usługa na żądanie Modelowe połączenia + połączenia narzędziowe + delegacje Stałe koszty na żądanie Koszty różnią się w zależności od użycia tokenów AI Agents 101: The Agentic Loop Consider the core loop of a multi-AI agent system. This is the deceptively simple pattern that has led to the current wave of innovation in AI systems. Poniżej znajduje się uproszczona pętla agentyczna, ponieważ pomijamy wiele niuansów, ale idea polega na tym, że wysyłamy pierwsze wezwanie do LLM, aby odpowiedzieć za pomocą połączeń narzędziowych lub połączeń delegacyjnych, a jeśli nie ma żadnych lub biegniemy do maksymalnych kroków, wysyłamy ostateczną odpowiedź. async def process_message(self, messages): for step in range(self.max_steps): # 1. Call the LLM specifically for tool/delegation requests response = await self.model.process_tool_request(messages) # 2. If the model wants to use a tool, execute it if response.has_tool_call: result = await self.execute_tool(response.tool_call) messages.append({"role": "tool", "content": result}) continue # 3. If the model wants to delegate, call another agent elif response.needs_delegation: result = await self.delegate_to_agent(response.delegation) messages.append({"role": "assistant", "content": result}) continue else: # If no tools/delegations we move to final answer break # 4. We return our final answer with any context gathered return await self.model.process_final_answer(messages) Jak widzimy, każda iteracja tego obwodu może przejść inną ścieżkę. Tradycyjne logowanie (np. „zapytanie rozpoczęte” ... „zapytanie zakończone”) nie mówi prawie nic o tym, co się naprawdę wydarzyło. A gdy weźmiemy to w systemie rozproszonym, staje się jeszcze bardziej skomplikowane, aby zrozumieć, co się dzieje - jak zobaczymy w tym poście. W ostatniej sekcji tego posta pokażemy również, w jaki sposób będziemy instrumentalizować ten łańcuch agentyczny w szczególności. Zastąpiliśmy słowo „request-response” słowem „request-panic-tool-panic-delegate-panic-response”. Zastąpiliśmy słowo „request-response” słowem „request-panic-tool-panic-delegate-panic-response”. Trzy filary obserwacji agentów OpenTelemetry dostarcza trzy rodzaje danych telemetrycznych, z których każdy służy odrębnemu celowi dla systemów agentycznych. Traces Hierarchia śladów mapuje bezpośrednio to, co zrobił agent, uchwycając i łącząc każdy skok podczas podróży. HTTP POST /v1/chat/completions (15.2s total) -> agent.agentic_loop -> agent.step.1 (3.1s) -> model.inference (3.0s) -> agent.step.2 (8.5s) ->model.inference (2.1s) -> tool.web_search (6.3s) agent.step.3 (3.4s) -> model.inference (3.3s) Traces odpowiada: „Jaką drogę podjął ten wniosek poprzez moich agentów?” Odpowiedź: „Jaką drogę poszła ta prośba przez moich agentów?” Traces Logs Tradycyjnie w oprogramowaniu logowanie zapewnia wewnętrzny wgląd w zachowanie i przepływ aplikacji. Zapewniają one sposób na zrozumienie tego, co wydarzyło się podczas konkretnego żądania lub sesji, a także przechwytywanie krytycznych informacji, takich jak wyjątki. W OpenTelemetry dzienniki są również przechwycane wraz z odpowiednimi śladami, dzięki czemu można je odpowiednio połączyć. 2024-01-15 10:30:45 INFO [trace_id=abc123] Starting message processing 2024-01-15 10:30:47 DEBUG [trace_id=abc123] Model response: calling tool 'web_search' 2024-01-15 10:30:53 ERROR [trace_id=abc123] Tool execution failed: API rate limited Logs odpowiada: „Co agent „myślał” na każdym kroku?” Odpowiedź: Co agent „myślał” na każdym kroku? Logs Metrics Wskaźniki dostarczają granulowanych, opartych na czasie KPI, które ewoluują w czasie i mogą być agregowane i podzielone, aby opowiedzieć konkretną historię. <- Store number of tokens per request <- Store success / failure rate of requests <- Store latency for model calls Metryka odpowiada: „Jak działa mój system ogólnie?” Odpowiedź: „Jak działa mój system ogólnie?” Metrics Bringing it all together Magia dzieje się, gdy te trzy są powiązane (aka połączone). Pozwala to nam zrobić takie rzeczy, jak „kliknij na ten dziennik błędu w twoim backendzie obserwacyjności” i zdiagnozować dokładny zakres w śladzie, w którym wystąpił błąd. Wielostronne rozpowszechnianie kontekstów Kiedy agent A deleguje do agenta B, który deleguje do agenta C, chcesz jednego zjednoczonego śladu - nie trzech odłączonych. Wymaga to . context propagation Obejmuje to przekazywanie kontekstu śledzenia za pośrednictwem nagłówków HTTP przy użyciu standardu W3C Trace Context. Rezultatem jest zjednoczony ślad na wszystkich agentach - oto przykład, który pokazuje, jak kontekst śladu rozciąga się na agenta koordynatora, agenta badacza i agenta analityka. coordinator.agent.agentic_loop (trace_id: abc123) -> coordinator.model.inference -> coordinator.delegate.researcher -> researcher.agent.agentic_loop (trace_id: abc123) -> researcher.model.inference -> researcher.tool.web_search -> coordinator.model.inference -> coordinator.delegate.analyst -> analyst.agent.agentic_loop (trace_id: abc123) -> analyst.model.inference -> analyst.tool.calculator Bez rozpowszechniania kontekstu, debugowanie wielu agentów jest po prostu rozproszonym zgadywaniem. Bez rozpowszechniania kontekstu, debugowanie wielu agentów jest po prostu rozproszonym zgadywaniem. Praktyczny przypadek zastosowania: system badawczy multi-agent Zacznijmy budować coś konkretnego. Będziemy używać , open-source framework do wdrażania, zarządzania i skalowania systemów wielodzietnych w Kubernetes. Chaosem (System orkiestracji agentów Kubernetes) Chaosem System Multi-Agent do monitorowania Nasz przypadek użycia składa się z agenta koordynatora, który deleguje zadania badawcze i analityczne do specjalistycznych podagentów: Każdy składnik – agenci, narzędzia i interfejsy interfejsu modelowego – wysyła ślady, metryki i dzienniki do kolektora OpenTelemetry, który przekazuje wszystko do wybranego backend do wizualizacji i analizy. Wymagania wstępne: Commands & Tools Zanim zaczniemy, będziesz potrzebować: KAOS CLI zainstalowany: pip install kaos-cli==0.2.7 Klucz API LLM (wszyscy dostawcy, tacy jak OpenAI, Nebius itp.) kubectl, hełm i klaster Kubernetes (KIND, minikube lub klaster chmury) Installing KAOS Najpierw zainstalujmy operator KAOS z obsługą OpenTelemetry i backendem obserwacyjności. (Rekomendowane przez : Using the KAOS CLI # Install the KAOS operator kaos system install \ --set logLevel=DEBUG \ --wait \ --monitoring-enabled # Enables monitoring setup (supports signoz and jaeger) # Verify the installation kaos system status # Change context to use (+create) this current namespace for convenience kaos system working-namespace kaos-hierarchy Po uruchomieniu możemy utworzyć nasz system wieloagentowy, korzystając z jednej z próbek dostarczonych z CLI. Możesz również zobaczyć ZAŁĄCZNIK na końcu posta na blogu, aby wdrożyć każdy z komponentów jeden po drugim. kaos samples deploy \ 3-hierarchical-agents \ --provider openai \ --wait \ --api-secret # This will prompt your api-key secret Możesz zobaczyć flagę dostawcy, która określa backend, takie jak nebius, gemini, bedrock i 100 innych dostawców [dokumenty KAOS], a także twój sekret -api, który zostanie zaproszony interaktywnie. Możesz zobaczyć flagę - dostawcy, która określa backend, taki jak nebius, gemini, bedrock i 100 innych dostawców [ , as well as your --api-secret which will be prompted interactively. Chaos w doktrynie) Po zainstalowaniu otwórz UI za pomocą następującego polecenia. kaos ui --monitoring-enabled To pozwala nam zobaczyć rozmieszczony system multi-agent: Putting It All Together: Monitoring KAOS Teraz wygenerujmy trochę ruchu i zacznijmy monitorować KAOS. Interakcja z agentami Możesz współpracować z agentami na wiele sposobów: # Invoke the coordinator agent directly kaos agent invoke supervisor \ --message "Research the current AI chip market and calculate the market share of the top 3 companies." Activating the Chat through the User Interface: Za kulisami, to wyzwala złożony łańcuch operacji: Przewodniczący przyjmuje wniosek Nadzorca dzwoni do LLM, który decyduje się na delegowanie Agent badawczy jest powoływany do badań rynkowych (i nazywa dwóch podagentów badawczych) Agent analityczny oblicza udziały rynkowe (i wywołuje dwóch podagentów analityków) Supervisor syntetyzuje ostateczną odpowiedź Wszystko to jest przechwycone w audytowanych śladów: każdy LLM wezwanie, każde wykonanie narzędzia, każda delegacja. Przeglądanie śladów: zrozumienie przepływu żądań W przeciwieństwie do tradycyjnych usług odpowiedzi na żądania, agenci podejmują wiele decyzji na żądanie. ślady pozwalają zobaczyć każdy punkt decyzji, jak długo zajęło to i jaką drogę wybrał agent. Why traces matter for agentic systems Lista śladów pokazuje wszystkie żądania przepływające przez Twoich agentów. Każdy ślad reprezentuje pełną interakcję użytkownika. Kliknij na ślad, aby zobaczyć pełny przepływ żądań: Pojedynczy ślad wskazujący koordynatora delegującego na agenta badacza i analityka, z każdym okresem reprezentującym odrębną operację. Ta wizualizacja śladu odpowiada na pytania, które w przeciwnym razie wymagają godzin spielunkowania dziennika: Dlaczego ta prośba zajęła 15 sekund? narzędzie web_search zajęło 8 sekund. Co to jest koordynator, co to jest analityk, co to jest koordynator? Ile połączeń LLM zostało wykonanych? 6 połączeń w trzech agentach. Wszystkie narzędzia zakończone pomyślnie (zielone zakresy). Log korelacji: zrozumienie agenta rozumowania Traces tell you Zdarzyło się. logs powiedzieć OpenTelemetry koreluje je automatycznie poprzez and i atrybutów. co Dlaczego trace_id span_id Every log entry includes these identifiers, enabling you to: Kliknij na spanie w Twoim śladzie Pokaż wszystkie dzienniki emitowane w tym okresie Zrozum rozumowanie agenta na każdym kroku It is possible to see the view of the logs themselves as well as further details. We can then drill deeper into individual log entries. Here for example we can view the log „Zadanie delegacji: ...” To pokazuje nam całą prośbę, która została przekazana, co jest bardzo przydatne do diagnostyki i debugowania. This includes full log context including all attributes, resource labels, and the complete message. Śledzenie wyjątków: znalezienie problemów produkcyjnych OpenTelemetry uchwyca wyjątki jako obywateli pierwszej klasy i przywiązuje je do zakresu, w którym miały miejsce. Możemy spróbować tego, prosząc nadzorcę o delegowanie do nieistniejącego podagenta: # Invoke the coordinator agent directly kaos agent invoke supervisor \ --message "We are now testing valid exception functionality. Try to delegate to a non-existing agent to validate that it works correctly." lub bezpośrednio przez UI: If we now navigate to the Exceptions tab, we can now see that there is an entry. This is the Exceptions list view, where all exceptions for the time period are listed. This list captures errors across the system and correlates them also with the respective request traces, and logs. Możemy również filtrować według różnych usług (agentów), a także innych atrybutów. Widzimy wyraźnie, że wyjątek był spowodowany próbą niewłaściwego delegowania. And we can also visualise the error in the trace view. Metryka: Przegląd operacyjny While traces show individual requests, metrics show trends over time. Here are some example key metrics in agentic systems: Metric What It Tells You kaos.requests Request volume by agent kaos.request.duration Latency distribution (P50, P95, P99) kaos.model.calls LLM API usage (cost indicator) kaos.tool.calls Tool execution frequency kaos.delegations Multi-agent coordination patterns kaos.requests Wymagania ilościowe według agenta kaos.request.duration Latency distribution (P50, P95, P99) kaos.model.calls Użycie API LLM (wskaźnik kosztów) kaos.tool.calls Częstotliwość wykonywania narzędzia kaos.delegations Multi-agent coordination patterns Te metryki umożliwiają ostrzeganie o problemach produkcyjnych: Request latency > 30s Error rate > 5% Niepowodzenia modeli połączeń > 1% We can also visualise them: Pod kapturem: jak to działa Now that you’ve seen observability in action, let’s dive into how it’s implemented. The challenges here aren’t obvious until you start building—and the solutions are broadly applicable to any agentic system. Architektury KAOS oddziela płaszczyznę sterowania (Go) od płaszczyzny danych (Python); wewnątrz aplikacji Python mamy menedżera OpenTelemetry (KaosOtelManager), aby zapewnić narzędzia do uproszczenia przepływów pracy. Kluczowe informacje: konfiguracja telemetrii przepływa z Operator -> Data Plane -> OTEL Collector. Użytkownicy konfigurują telemetrię raz w values.yaml, a operator rozprzestrzenia ją na wszystkie komponenty. The key insight: Użytkownicy konfigurują telemetrię raz w , a operator rozprzestrzenia go na wszystkie komponenty. telemetry configuration flows from Operator -> Data Plane -> OTEL Collector values.yaml Wykorzystanie podstawowej logiki Jeśli chodzi o systemy agentyczne, nie chodzi tylko o instrumentowanie żądania-odpowiedzi, ale także o przechwytywanie przepływu w iteracjach agentów. Zacznijmy od tego, aby upewnić się, że przechwycimy zakres ogólny na całym żądaniu/odpowiedzi na najwyższym poziomie. Następnie powinniśmy również zainstalować inne kluczowe komponenty, takie jak przewód agentyczny (przykład poniżej), a także dodatkowe połączenia, takie jak połączenia MCP i delegacje agentów. # This is the same function pseudo-code that we showed initially but instrumented async def process_message(self, session_id: str, messages: List[Dict]) -> str: """Process message through agentic loop with full tracing.""" # Start root span for entire message processing span = otel.span_begin("agent.agentic_loop", SpanKind.INTERNAL) span.set_attribute("agent.name", self.name) span.set_attribute("session.id", session_id) span.set_attribute("agent.max_steps", self.max_steps) span_failure = False try: # Agentic loop logic (see below) except Exception as e: # If exception mark as failure span_failure = True otel.span_failure(span, e) raise finally: if not span_failure: otel.span_success(span, e) Instrumenting the Agentic Loop Możemy teraz użyć tego samego wzorca w pętli agentycznej, gdzie możemy uchwycić iteracje z odpowiednim kontekstem. # Previous logic outlined above... for step in range(self.max_steps): # Span for each iteration step_span = otel.span_begin(f"agent.step.{step + 1}") step_span.set_attribute("step", step + 1) agent_span_failed = False try: # MCP Calls (with OTEL span)... # Delegation Calls (with OTEL span)... except Exception as e: otel.span_failure(step_span, e) agent_span_failed = True raise finally: if not agent_span_failed: otel.span_success(span) # Preview logic outlined above... Posiadanie zakresów zdefiniowanych w miejscu jest tym, co pozwala nam śledzić żądanie w skokach. Kilka przydatnych wzorów do zauważenia: Zakresy hierarchiczne: Istnieje rozpiętość rodzica dla pętli, rozpiętość dziecka dla każdego kroku, rozpiętość wnuka dla operacji itp. Logowanie przed zamknięciem zakresu: dzienniki są emitowane, podczas gdy kontekst śledzenia jest aktywny, co pozwala na korelację dzienników Wyraźne zarządzanie zakresem: używamy wyraźnego wzorca try/finally, aby zapewnić, że zakresy są zawsze zamknięte, ale możemy również użyć menedżerów kontekstu (tj. z klauzulą) To także pozwala nam następnie wizualizować rozpad śladów i zakresów żądań. Kontekstowe rozpowszechnianie dla systemów wielodzietnych Podczas delegowania do podagentów (biegających w oddzielnych pods), musimy rozpowszechniać kontekst śladowy: # Inject context into outgoing request from opentelemetry.propagate import inject async def delegate(self, target_agent: str, task: str) -> str: headers = {"Content-Type": "application/json"} # Inject current trace context into headers inject(headers) # Adds 'traceparent' and 'tracestate' headers async with httpx.AsyncClient() as client: response = await client.post( f"http://{target_agent}/v1/chat/completions", headers=headers, json={"messages": [{"role": "user", "content": task}]} ) return response.json()["choices"][0]["message"]["content"] Zapewnienie śladu kontekstów propagowanych Musimy również upewnić się, że kontekst jest odbierany i osadzony. # Extract context from incoming request from opentelemetry.propagate import extract @app.post("/v1/chat/completions") async def chat(request: Request, body: ChatRequest): # Extract trace context from incoming headers context = extract(request.headers) # Attach to current context so new spans are children token = otel_context.attach(context) try: return await agent.process_message(body.messages) finally: otel_context.detach(token) Log Export i korelacja For log-trace correlation, we connect Python’s logging to OpenTelemetry. If you have used previously something like the ELK stack, with OpenTelemetry now you have a setup where the logs are pushed as opposed to pulled, using the GRPC OTEL connection. The logging instrumentation automatically injects and into log records when there’s an active span context. trace_id span_id Aby skonfigurować to połączenie, możesz go skonfigurować za pomocą kilku linii, jak opisano poniżej. from opentelemetry.sdk._logs import LoggerProvider from opentelemetry.sdk._logs.export import BatchLogRecordProcessor from opentelemetry.exporter.otlp.proto.grpc._log_exporter import OTLPLogExporter from opentelemetry.instrumentation.logging import LoggingInstrumentor # Set up OTLP log export logger_provider = LoggerProvider(resource=resource) logger_provider.add_log_record_processor( BatchLogRecordProcessor(OTLPLogExporter(endpoint=endpoint)) ) # Attach handler to Python root logger handler = LoggingHandler(level=logging.DEBUG, logger_provider=logger_provider) logging.getLogger().addHandler(handler) Metryka dla operacji agentów We are also able to track metrics using the OpenTelemetry SDK. Jeśli w przeszłości używałeś Prometheus, w tym przypadku metryki nie są eksponowane za pośrednictwem punktu końcowego, który byłby wyszukiwany za pośrednictwem prometeus kolektora. Wybierając metryki, staramy się śledzić metryki z etykietami o niskiej kardynalności, aby uniknąć wybuchów kardynalności, jak opisano w poniższym przykładzie. from opentelemetry import metrics meter = metrics.get_meter("kaos-agent") # Counters request_counter = meter.create_counter( "kaos.requests", description="Number of requests processed", unit="1" ) model_call_counter = meter.create_counter( "kaos.model.calls", description="Number of model inference calls", unit="1" ) # Histograms for latency request_duration = meter.create_histogram( "kaos.request.duration", description="Request processing duration in milliseconds", unit="ms" ) # Usage example request_counter.add(1, {"agent.name": self.name, "status": "success"}) request_duration.record(duration_ms, {"agent.name": self.name}) : Never use session IDs, user IDs, prompt content, or other unbounded values as metric labels. Put those in logs or trace attributes instead. Avoid high-cardinality labels : Nigdy nie używaj identyfikatorów sesji, identyfikatorów użytkowników, treści polecenia lub innych wartości nieograniczonych jako etykiet metrycznych. Avoid high-cardinality labels Wskazówka z Iceberg Jest to łagodne wprowadzenie do obserwacji w systemach wieloagentowych i zapewnia wysoki poziom widzenia, jakie są niektóre z głównych komponentów zaangażowanych. Powinno to również zapewnić ci wystarczającą intuicję, aby zainstalować twoje systemy agentyczne sumiennie, jednak będziesz musiał zidentyfikować, które wzorce działają najlepiej w twoich konkretnych kontekstach. Instrumentowanie systemów agencji AI za pomocą OpenTelemetry wymaga zrozumienia unikalnych wyzwań, przed którymi stoją te systemy: Iteratywne łańcuchy potrzebują hierarchii, które mapują operacje logiczne Delegowanie wielu agentów wymaga wyraźnego rozpowszechniania kontekstu przy użyciu W3C Trace Context Wykonanie narzędzi korzysta z dedykowanych zakresów z wyraźnym nazwaniem Korelacja log-trace wymaga emisji dzienników przed zamknięciem zakresu need low-cardinality labels to avoid storage explosions Metrics Wzory, które omówiliśmy, mają zastosowanie do każdego systemu agentycznego, nie tylko KAOS. The agents of tomorrow will be as ubiquitous as microservices are today, and OpenTelemetry gives you the visibility to operate them with confidence. Agenci jutra będą tak powszechni, jak mikrosłużby dzisiaj, a OpenTelemetry daje Ci widoczność, aby obsługiwać je z ufnością. zasobów KAOS Framework: github.com/axsaucedo/kaos - Ramy open-source używane w tym artykule Dokumentacja KAOS: axsaucedo.github.io/kaos - pełna dokumentacja CLI i CRD OpenTelemetry Python: opentelemetry.io/docs/languages/python - Oficjalna dokumentacja Python SDK Konwencje OpenTelemetry GenAI: github.com/open-telemetry/semantic-conventions - Nowe standardy dla obserwacji AI : - Open-source APM with native OpenTelemetry support SigNoz signoz.io ZAŁĄCZNIK: Ręczne tworzenie systemu multi-agent W tej sekcji tworzymy komponenty systemu agentycznego ręcznie, zamiast używać narzędzi dla ciekawskich! We’ll show you how you can do this with CLI but you can do this also with the UI as well as with i bezpośrednio . kubectl Krok 1: Najpierw łączymy się z LLM z ModelAPI o zasób w KAOS zapewnia jednolity interfejs dla dostępu LLM. Obsługuje dwa tryby: ModelAPI Tryb proxy: kieruje żądania za pośrednictwem LiteLLM do zewnętrznych dostawców (OpenAI, Anthropic, Nebius itp.) Tryb hostowany: Wciąga modele do klastra (za pośrednictwem samochodu bocznego) i uruchamia je na serwerze w celu wyciągania wniosków Model API można łatwo wdrożyć za pośrednictwem CLI. Należy pamiętać, że aby nasi agenci mogli korzystać z modelowych interfejsów API, musimy podać nasz klucz API do uwierzytelniania.W tym przykładzie będziemy używać Nebiusa, ponieważ jest łatwy w konfiguracji, ale możesz również skonfigurować OpenAI, Gemini i kilkadziesiąt innych. Należy pamiętać, że aby nasi agenci mogli korzystać z modelowych interfejsów API, musimy podać nasz klucz API do uwierzytelniania.W tym przykładzie będziemy używać Nebiusa, ponieważ jest łatwy w konfiguracji, ale możesz również skonfigurować OpenAI, Gemini i kilkadziesiąt innych. kaos modelapi deploy llm-proxy \ --namespace kaos-hierarchy \ --provider nebius \ --api-key # When provided without value this prompts the key securely Z punktu widzenia obserwacyjności, ModelAPI daje nam widoczność opóźnienia połączeń modelu, wykorzystania tokenów i współczynników błędów - krytycznych wskaźników do zrozumienia wydajności agentów i kontrolowania kosztów. Krok 2: Wdrażanie serwerów narzędzi MCP w KAOS dostarcza narzędzi, z których mogą korzystać agenci. MCP (Model Context Protocol) Servers KAOS enables FastMCP native servers with ability to create and deploy your own images. KAOS obsługuje również wiele natywnych czasów wykonywania MCP za pośrednictwem rejestru. Runtime Description python-string Define tools as inline Python functions for testing kubernetes Kubernetes CRUD operations slack Slack messaging integration custom Your own container image python-string Definicja narzędzi jako funkcji Pythona do testowania kubernetes Operacje Kubernetes CRUD slack Integracja Slack Messaging custom Własny obraz kontenera W produkcji połączylibyście się z prawdziwymi API, bazami danych lub zewnętrznymi usługami. Uwaga: W tej sekcji używamy bieżnika python-string do szybkiego testowania, ale do wdrożenia gotowego do produkcji użyj wdrożenia niestandardowego obrazu. Uwaga: W tej sekcji używamy bieżnika python-string do szybkiego testowania, ale do wdrożenia gotowego do produkcji użyj wdrożenia niestandardowego obrazu. Najpierw tworzymy mcp, which will have a simple narzędzie, które doda dwie liczby i zwróci wynik. calculator add export ADD_TOOL=' def add(a: float, b: float) -> float: """Add two numbers together.""" return a + b ' kaos mcp deploy calculator \ --runtime python-string \ --params $ADD_TOOL \ --wait Następnie stworzyliśmy mcp, który jest również prostym narzędziem, które otrzymuje strunę i zwraca tę samą wartość jak strunę. echo export ECHO_TOOL=' def echo(message: str) -> str: """Echo back the message for testing.""" return f"Echo: {message}" ' kaos mcp deploy echo-search \ --runtime python-string \ --params $ECHO_TOOL \ --wait I możemy wysłać prośbę o przetestowanie mcp. # Run 2 + 2 on mcp calculator kaos mcp invoke calculator \ --tool add \ -a 2 \ -a 2 # Run echo hello on mcp echo kaos mcp invoke echo-search \ --tool echo \ -a "Hello" Z punktu widzenia obserwacyjności pokażemy, jak ważne jest zrozumienie połączeń wysyłanych przez dowolnego agenta (lub dowolną usługę zewnętrzną) i przetwarzanych przez same serwery MCP. 3a. pracodawca badawczy o zasób w KAOS reprezentuje jednostkę AI, która może przetwarzać żądania, modele połączeń, wykonywać narzędzia i delegować na innych agentów. Agent Wyświetla zgodny z OpenAI punkt końcowy /v1/chat/completions Wdraża łańcuch agentyczny (model > narzędzia > model > ...) Supports configurable memory for session state Specjalista będzie specjalizował się w gromadzeniu informacji: kaos agent deploy researcher \ --model "openai/gpt-4o" \ --mcp echo-search \ --description "Research specialist" \ --instructions "You research topics and provide ." \ --expose=true \ --wait W odniesieniu do obserwacji pojedynczego agenta dbamy o: Latentność połączenia modelowego: jak długo trwa inferencja? Czas wykonania narzędzia: Czy narzędzia reagują szybko? Liczba kroków: Ile iteracji potrzebuje agent? 3b – Agent analityczny Agent analityczny koncentruje się na analizie danych i obliczeniach: kaos agent deploy analyst \ --model "openai/gpt-4o" \ --mcp calculator \ --description "Data analyst with calculation capabilities" \ --instructions "You analyze data and perform calculations." \ --expose=true \ --wait 3c – Pracownik nadzoru Wreszcie, Koordynator orkiestruje pozostałych agentów. Dla obserwacji wielu agentów otrzymujemy dodatkowe obawy: Wzory delegacji: Jakie agenci są wezwani i jak często? Opóźnienie między agentami: ile czasu poświęca się delegowaniu w porównaniu z przetwarzaniem lokalnym? Korelacja śladów: Czy możemy zobaczyć pełny przepływ żądań między agentami? kaos agent deploy subervisor \ --model "openai/gpt-4o" \ --description "Coordinator that delegates to specialist agents" \ --instructions "You are a coordinator. Analyze user requests and delegate to your analyst and researcher." \ --sub-agent researcher \ --sub-agent analyst \ --wait I jesteśmy skończeni! Teraz możesz wrócić na szczyt i przejść przez ścieżkę obserwacji z wdrożonym ustawieniem!