Produktion Observation for Multi-Agent AI (med KAOS + OTel + SigNoz)

En praktisk vejledning til at tilføje observabilitet på produktionsniveau til multi-agent AI-systemer med K8s Agent Orchestration System ved hjælp af OpenTelemetry og SigNoz Du har opbygget en AI-agent, der fungerer i din bærbare computer. Den knytter automatisk værktøjer sammen, delegerer opgaver til specialiserede underagenter og producerer gode resultater. Derefter indsættes den i produktionen: En bruger rapporterer, at en anmodning "tog for evigt". En anden siger, at de fik en mærkelig reaktion. Dine logs viser agenten løb Men hvad skete der i de 45 sekunder mellem anmodning og svar? Velkommen til den observability challenge of agentic systems. "Traditionelle logs fortæller dig, at det løb, observation fortæller dig, hvorfor det løb sådan." "Traditionelle logs fortæller dig, at det løb, observation fortæller dig, hvorfor det løb sådan." I denne artikel vil vi gå gennem et komplet end-to-end eksempel på observabilitet for multi-agent systemer. Nedenfor er en forhåndsvisning af multi-agent-systemet, som vi vil analysere, overvåge og diagnosticere i dette indlæg: Lad os starte med hovedspørgsmålet om... Hvorfor har multi-agent systemer brug for (forskellig) observabilitet? Traditionelle microservices har forudsigelige mønstre: en anmodning kommer ind, nogle behandling sker, et svar går ud. Det er ikke bare en forespørgsel-svar Agentiske systemer bryder traditionelle antagelser: 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 Synkron anmodningssvar Iterativt ræsonnement Loops Predictable latency (50-500ms) Variabel: 100 ms til 60+ sekunder Deterministiske kodeveje Ikke-deterministiske LLM beslutninger Single service per request Modelopkald + værktøjsopkald + delegationer Faste omkostninger pr. anmodning Omkostningerne varierer afhængigt af token brug AI Agents 101: The Agentic Loop Overvej den kerne loop af et multi-AI agent system.Dette er det vildledende enkle mønster, der har ført til den nuværende bølge af innovation i AI-systemer. Nedenfor er en forenklet agentisk bue, da vi hopper mange af nuancerne, men ideen er, at vi sender et første opkald til LLM for at svare med værktøjsopkald eller delegationsopkald, og hvis der ikke er nogen, eller vi kører ind i de maksimale trin, så sender vi det endelige svar. 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) Som vi kan se, kan hver iteration af denne loop tage en anden vej. Traditionel logning (f.eks. "anmodning startede" ... "anmodning afsluttet") fortæller dig næsten ingenting om, hvad der rent faktisk skete. Og når vi tager dette ind i et distribueret system, bliver det endnu mere komplekst at forstå, hvad der foregår - som vi vil se i dette indlæg. I det sidste afsnit af dette indlæg vil vi også vise dig, hvordan vi vil instrumentere denne agentiske loop specifikt også. Vi har erstattet 'anmodning-svar' med 'anmodning - panik - værktøj - panik - delegere - panik - svar'. Vi har erstattet 'anmodning-svar' med 'anmodning - panik - værktøj - panik - delegere - panik - svar'. The Three Pillars of Agent Observability OpenTelemetry leverer tre typer telemetri data, som hver især tjener et særligt formål for agentiske systemer. Traces Sporhierarkiet kortlægger direkte til, hvad agenten gjorde, og fanger og forbinder hvert hop på tværs af rejsen. 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 svar: "Hvilken vej tog denne anmodning gennem mine agenter?" svar: "Hvilken vej tog denne anmodning gennem mine agenter?" Traces Logs Traditionelt i software giver logging et indvendigt overblik over applikationens adfærd og flow. Disse giver en måde at forstå, hvad der skete i løbet af en bestemt anmodning eller session, og også fange kritiske oplysninger som undtagelser. I OpenTelemetry er logs også indfanget med de respektive spor, så de kan forbindes henholdsvis. 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 svar: "Hvad "tænkte" agenten på hvert skridt?" Svar: “Hvad ”tænkte” agenten ved hvert skridt?” Logs Metrics Metrikkerne giver granulære tidsbaserede KPI'er, der udvikler sig over tid, og kan aggregeres og vindues til at fortælle en bestemt historisk historie. <- Store number of tokens per request <- Store success / failure rate of requests <- Store latency for model calls Metrics svar: “Hvordan fungerer mit system generelt?” Metrics svar: “Hvordan fungerer mit system generelt?” Bringing it all together The magic happens when these three are correlated (aka connected). This allows us to do things like “click on that ERROR log in your observability backend” and diagnose the exact span in the trace where the failure occurred. Multi-agent kontekstfordeling Når agent A delegerer til agent B, som delegerer til agent C, vil du have et enkelt enhedsspor - ikke tre frakoblede spor. Dette kræver . context propagation Dette indebærer at passere trace-kontekst gennem HTTP-overskrifter ved hjælp af W3C Trace Context-standarden. Resultatet er en ensartet spor på tværs af alle agenter - her er et eksempel, der viser, hvordan en spor kontekst spænder over koordinerende agent, forsker agent og analytiker agent. 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 Uden kontekstpropagation er multi-agent debugging bare distribueret gætning. Uden kontekstpropagation er multi-agent debugging bare distribueret gætning. Den praktiske anvendelse-sag: Et multi-agent forskningssystem Lad os nu begynde at bygge noget konkret. Vi vil bruge , et open source-rammeværk til at implementere, administrere og skalere multi-agent-systemer i Kubernetes. KAOS (Kubernetes Agent Orchestration System) Kaoset Multifunktionssystem til overvågning Vores brugssag består af en koordinatoragent, der delegerer forskning og analyseopgaver til specialiserede underagenter: Hver komponent - agenter, værktøjer og model-API'er - sender spor, målinger og logs til en OpenTelemetry-samler, som videresender alt til din valgte backend til visualisering og analyse. Forudsætninger: Kommandoer og værktøjer Før vi begynder, har du brug for: KAOS CLI installeret: pip install kaos-cli==0.2.7 En LLM API-nøgle (en hvilken som helst udbyder som OpenAI, Nebius osv.) kubectl, hjelm og et Kubernetes-cluster (KIND, minikube eller et cloud-cluster) Installation af kaos Lad os først installere KAOS-operatøren med OpenTelemetry aktiveret og en observabilitetsbackend. (Det er anbefalet) 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 Når det er kørt, kan vi oprette vores multi-agent system ved hjælp af en af de prøver, der leveres med CLI. Du kan også se bilaget i slutningen af blogindlægget for at implementere hver af komponenterne en efter en. kaos samples deploy \ 3-hierarchical-agents \ --provider openai \ --wait \ --api-secret # This will prompt your api-key secret Du kan se -providers flag, der angiver backend, såsom nebius, gemini, bedrock og 100s af andre udbydere [KAOS-dokumenter], samt din -api-hemmelighed, der vil blive opfordret interaktivt. Du kan se -udbyder flag, der angiver backend, såsom nebius, gemini, bedrock og 100s af andre udbydere [ , samt din -api-hemmelighed, som vil blive opfordret interaktivt. Det er kaos] Når du har installeret, åbner du UI med følgende kommando. kaos ui --monitoring-enabled This allows us to see the deployed multi-agent system: At sætte det hele sammen: Overvågning af kaos Lad os nu generere lidt trafik og begynde at overvåge KAOS. Interagere med agenter Du kan interagere med agenter på flere måder: # 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." Aktivering af chatten via brugergrænsefladen: Bag kulisserne udløser dette en kompleks kæde af operationer: Bestyrelsen modtager anmodningen Supervisor kalder LLM, som beslutter at delegere Forskeragent påberåbes til markedsundersøgelser (og kalder to forskerunderagenter) Analytiker agent beregner markedsandele (og kalder to analytiker sub-agenter) Supervisor syntetiserer det endelige svar All of this is caputred in auditable traces: every LLM call, every tool execution, every delegation. Se spor: Forståelse af forespørgselsstrøm I modsætning til traditionelle anmodningssvarstjenester træffer agenter flere beslutninger pr. anmodning. spor giver dig mulighed for at se hvert beslutningspunkt, hvor længe det tog, og hvilken vej agenten valgte. Why traces matter for agentic systems Sporlisten viser alle forespørgsler, der strømmer gennem dine agenter. Hver spor repræsenterer en komplet brugerinteraktion. Klik på et spor for at se den fulde forespørgselsstrøm: Et enkelt spor, der viser koordinatoren delegere til forsker og analytiker agenter, med hver span repræsenterer en separat operation. Denne sporvisualisering besvarer spørgsmål, der ellers ville kræve timers logspilunking: Hvorfor tog denne anmodning 15 sekunder? web_search værktøjet tog 8 sekunder. Hvilke agenter var involveret? koordinator → forsker → analytiker → koordinator. Hvor mange LLM opkald blev lavet? 6 opkald på tværs af de tre agenter. Alle værktøjer er afsluttet med succes (grønne områder). Log korrelation: Forstå agent begrundelse Sporene fortæller dig Det er sket.Logs fortæller dig OpenTelemetry korrelerer dem automatisk gennem og af attributter. Hvad Hvorfor trace_id span_id Hver logindgang indeholder disse identifikatorer, så du kan: Klik på en spand i dit spor View all logs emitted during that span Forstå agentens begrundelse på hvert trin Det er muligt at se udseendet af logfilerne selv samt yderligere detaljer. We can then drill deeper into individual log entries. Her kan vi f.eks. se den Delegationens opgave: » Dette viser os hele prompt, der blev delegeret, hvilket er ret nyttigt til diagnostik og debugging. Dette omfatter fuld logkontekst, herunder alle attributter, ressourceetiketter og den komplette meddelelse. Exception Tracking: Finding Production Issues OpenTelemetry indfanger undtagelser som førsteklasses borgere og knytter dem til det område, hvor de opstod. We can try this by asking the supervisor to delegate to a non-existing sub-agent: # 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." Eller direkte via UI: Hvis vi nu navigerer til fanen Undtagelser, kan vi nu se, at der er en post. Dette er visningen af listen Undtagelser, hvor alle undtagelser for tidsperioden er angivet. This list captures errors across the system and correlates them also with the respective request traces, and logs. We are also able to filter by different (agent) services, as well as other attributes. We can see clearly that the exception was due to an attempted incorrect delegation. And we can also visualise the error in the trace view. Metrics: Operational Overview 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 Request volume by agent kaos.request.duration Latency distribution (P50, P95, P99) kaos.model.calls LLM API brug (omkostningsindikator) kaos.tool.calls Værktøjets udførelsesfrekvens kaos.delegations Multi-agent koordinering mønstre Disse metrikker gør det muligt at advare om produktionsproblemer: Anmodning om latens > 30 s Error rate > 5% Modelopkaldsfejl > 1% We can also visualise them: Under Hood: Hvordan det virker 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. Arkitekturen KAOS adskiller kontrolplanet (Go) fra dataplanet (Python); inde i Python-applikationen har vi en OpenTelemetry manager (KaosOtelManager) til at give værktøjer til at forenkle arbejdsprocesserne. Den vigtigste indsigt: telemetri-konfigurationen strømmer fra Operator -> Data Plane -> OTEL Collector. Brugere konfigurerer telemetri en gang i values.yaml, og operatøren spreder det til alle komponenter. Nøglen til indsigt: . Users configure telemetry once in , and the operator propagates it to all components. telemetry configuration flows from Operator -> Data Plane -> OTEL Collector values.yaml Brug af Core Logic Når det kommer til agentiske systemer, handler det ikke kun om at instrumentere anmodningen-svaret, men det handler også om at fange strømmen gennem agent iterationerne. Til at begynde med sørger vi for, at vi indfanger den overordnede rækkevidde på tværs af den øverste niveau anmodning/svar. Vi bør derefter også instrumentere andre nøglekomponenter som agent loop (eksempel nedenfor), samt ekstra opkald som MCP opkald og agent delegationer. # 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 Vi kan nu bruge det samme mønster i den agentiske loop, hvor vi kan fange iterationerne med den respektive kontekst. Dette vil være vigtigt, da vi også kan fange de korrelerede logs og metrikker, der er forbundet med denne specifikke anmodning. # 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... At have intervallerne defineret i placeret er, hvad der giver os mulighed for at spore anmodningen på tværs af hopper. Some useful patterns to note: Hierarkiske spænder: Der er en forælder spænder for sløjfen, børn spænder for hvert trin, børnebarn spænder for operationer, etc. Log før span lukker: Logs udstedes, mens sporkonteksten er aktiv, hvilket gør det muligt at korrelere logs Eksplicit span management: Vi bruger eksplicit try/finally mønster til at sikre, at intervaller altid er lukket, men vi kan også bruge kontekstledere (dvs. med klausul) This is also what allows us to then visualise the breakdown of the request traces and spans. Kontekstudbredelse for multi-agent systemer Når vi delegerer til underagenter (kører i separate pods), skal vi sprede sporkontekst: # 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"] Sikkerhed for sporing af kontekstpropaganda Vi skal også sørge for, at konteksten modtages og indlejres. # 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 eksport og korrelation For log-trace-korrelation forbinder vi Pythons logging med OpenTelemetry. Hvis du tidligere har brugt noget som ELK-stack, har du med OpenTelemetry nu en opsætning, hvor logs skubbes i modsætning til trukket, ved hjælp af GRPC OTEL-forbindelsen. The logging instrumentation automatically injects and into log records when there’s an active span context. trace_id span_id For at oprette denne forbindelse kan du konfigurere den med et par linjer som beskrevet nedenfor. 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) Metrik for agentoperationer Vi kan også spore målinger ved hjælp af OpenTelemetry SDK. Hvis du tidligere har brugt Prometheus, bliver metrikken i dette tilfælde ikke eksponeret gennem et slutpunkt, der ville blive forespurgt gennem en prometeus-samler.I stedet muliggør dette også en push-arkitektur, hvor den sendes til OTEL-samleren via GRPC-OLTP-forbindelsen til OTEL-samleren. Når vi vælger metrikker, har vi til formål at spore metrikker med lav-cardinality etiketter for at undgå cardinality eksplosioner, som beskrevet i stikprøven nedenfor. 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}) Undgå etiketter med høj cardinalitet: Brug aldrig session-id'er, bruger-id'er, promptindhold eller andre ubegrænsede værdier som metriske etiketter. Brug aldrig session-id'er, bruger-id'er, promptindhold eller andre ubegrænsede værdier som metriske etiketter. Avoid high-cardinality labels Tip af Iceberg Dette er en blid introduktion til observabilitet i multi-agent systemer, og giver et højt niveau overblik over, hvad nogle af de vigtigste komponenter er involveret. This should also provide you with enough intuition to instrument your agentic systems conscientiously, however you will need to identify which patterns work best in your particular contexts. Instrumentering af agentiske AI-systemer med OpenTelemetry kræver forståelse af de unikke udfordringer, disse systemer præsenterer: need span hierarchies that map to logical operations Iterative loops Delegering af flere agenter kræver udtrykkelig formidling af konteksten ved hjælp af W3C Trace Context benefits from dedicated spans with clear naming Tool execution Log-trace-korrelation kræver udstedelse af logs, før span lukker Metrikere har brug for etiketter med lav kardinalitet for at undgå opbevaringseksplosioner De mønstre, vi har dækket, gælder for ethvert agent-system, ikke kun KAOS. The agents of tomorrow will be as ubiquitous as microservices are today, and OpenTelemetry gives you the visibility to operate them with confidence. Morgendagens agenter vil være lige så udbredte som mikroservices i dag, og OpenTelemetry giver dig synligheden til at betjene dem med tillid. Ressourcerne : - The open-source framework used in this article KAOS Framework github.com/axsaucedo/kaos KAOS Dokumentation: axsaucedo.github.io/kaos - Fuld CLI og CRD dokumentation : - Official Python SDK documentation OpenTelemetry Python opentelemetry.io/docs/languages/python : - Emerging standards for AI observability OpenTelemetry GenAI Conventions github.com/open-telemetry/semantic-conventions SigNoz: signoz.io - Open-source APM med nativ OpenTelemetry support ANNEX: Oprettelse af Multi-Agent System manuelt I dette afsnit opretter vi de agentiske systemkomponenter manuelt i stedet for at bruge værktøjerne til de nysgerrige! We’ll show you how you can do this with CLI but you can do this also with the UI as well as with Det direkte. kubectl Trin 1: Vi forbinder først til LLM'er med en ModelAPI The ressource i KAOS giver en samlet grænseflade for LLM adgang. Det understøtter to tilstande: ModelAPI : Routes requests through LiteLLM to external providers (OpenAI, Anthropic, Nebius, etc.) Proxy Mode Hosted Mode: Trækker modeller ind i din klynge (via side-car) og kører den på serveren til konklusion ModelAPI kan nemt implementeres via CLI. Note that in order for our agents to use the model APIs we need to provide our authentication API Key. For this example we will be using as it’s easy to set up, but you can also set up OpenAI, Gemini and dozen others. Nebius Bemærk, at for at vores agenter kan bruge model-API'erne, skal vi give vores autentisering API-nøgle. da det er nemt at oprette, men du kan også oprette OpenAI, Gemini og snesevis af andre. Himlen kaos modelapi deploy llm-proxy \ --namespace kaos-hierarchy \ --provider nebius \ --api-key # When provided without value this prompts the key securely Fra et observabilitetsperspektiv giver ModelAPI os synlighed i modelopkaldets latens, tokenbrug og fejlrater - kritiske målinger for at forstå agentens ydeevne og kontrollere omkostninger. Trin 2: Udnyt MCP-værktøjsservere i KAOS giver værktøjer, som agenter kan bruge. MCP (Model Context Protocol) Servers KAOS giver FastMCP-native servere mulighed for at oprette og implementere dine egne billeder. KAOS understøtter også flere native MCP runtimes via et register. De mest almindeligt anvendte er: 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 Definer værktøjer som inline Python-funktioner til test kubernetes Kubernetes CRUD operationer slack Integration af Slack Messaging custom Dit eget containerbillede I produktionen vil du oprette forbindelse til rigtige API'er, databaser eller eksterne tjenester. Bemærk: I dette afsnit bruger vi Python-string runtime til hurtig test, men til produktionsklar implementering bruger vi brugerdefineret image-implementering. Bemærk: I dette afsnit bruger vi Python-string runtime til hurtig test, men til produktionsklar implementering bruger vi brugerdefineret image-implementering. Først skaber vi MCP, som vil have en enkel værktøj, der tilføjer to tal og returnerer resultatet. 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 Så skabte vi en mcp, som også er et simpelt værktøj, der modtager en streng og returnerer den samme værdi som strengen. 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 Og vi kan sende en anmodning om at teste 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" Fra et observabilitetsperspektiv vil vi vise, hvor vigtigt det er at forstå de opkald, der sendes af enhver agent (eller enhver ekstern tjeneste) og behandles af MCP-serverne selv. 3a. den forskeragent Den ressource i KAOS repræsenterer en AI-enhed, der kan behandle anmodninger, kalde modeller, udføre værktøjer og delegere til andre agenter. Agent Eksponerer et OpenAI-kompatibelt /v1/chat/completions-endpoint Implementerer den agentiske loop (model > værktøjer > model > ...) Understøtter konfigurerbar hukommelse til sessionstilstand Forskeren agent vil specialisere sig i at indsamle oplysninger: kaos agent deploy researcher \ --model "openai/gpt-4o" \ --mcp echo-search \ --description "Research specialist" \ --instructions "You research topics and provide ." \ --expose=true \ --wait For single-agent observabilitet, vi bekymrer os om: Model opkald latens: Hvor lang tid tager inference? Værktøjets udførelsestid: Reagerer værktøjerne hurtigt? Step count: Hvor mange iterationer har agenten brug for? 3b. analytiker The Analyst agent focuses on data analysis and calculations: 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. tilsynsførende agent Endelig organiserer koordinatoren de andre agenter.For multi-agent observabilitet får vi yderligere bekymringer: Delegationsmønstre: Hvilke agenter kaldes og hvor ofte? Cross-agent latency: Hvor meget tid bruges i delegation vs. lokal behandling? Sporkorrelation: Kan vi se den fulde forespørgselsstrøm på tværs af agenter? 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 Og vi er færdige! Du kan nu gå tilbage til toppen og køre gennem observabilitetspadseret med din implementerede opsætning!