Observabilidad de producción para AI multiagente (con KAOS + OTel + SigNoz)

Una guía práctica para agregar observabilidad de grado de producción a los sistemas de IA multiagente con el sistema de orquestación de agentes K8s utilizando OpenTelemetry y SigNoz Usted ha construido un agente de IA que funciona en su portátil. automáticamente cadena herramientas juntas, delega tareas a subagentes especializados, y produce resultados sólidos. Luego, se lanza a la producción: Un usuario informa de que una solicitud “se tomó para siempre”. Alguien dijo que había recibido una respuesta extraña. Sus registros muestran que el agente corrió Pero, ¿qué pasó en esos 45 segundos entre la solicitud y la respuesta? Bienvenido a la observability challenge of agentic systems. “Los registros tradicionales te dicen que funcionó, la observación te dice por qué funcionó de esa manera”. “Los registros tradicionales te dicen que funcionó, la observación te dice por qué funcionó de esa manera”. En este artículo, caminaremos a través de un ejemplo completo de observación de extremo a extremo para sistemas multiagentes. A continuación se muestra una vista previa del sistema multi-agente que analizaremos, monitorizaremos y diagnosticaremos en este post: Empecemos por la pregunta principal de... ¿Por qué los sistemas multiagentes necesitan (diferentes) observaciones? Los microservicios tradicionales tienen patrones predecibles: una solicitud entra, ocurre algún procesamiento, una respuesta sale.La latencia es relativamente consistente, los caminos de código son deterministas, y el desgaste suele involucrar el seguimiento de un solo hilo de ejecución. No es sólo una solicitud-respuesta Los sistemas de agentes rompen las suposiciones tradicionales: 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 Solicitud de respuesta sincronizada Loops de razonamiento iterativo Latencia previsible (50-500ms) Variable: 100ms to 60+ seconds Pautas de código determinista Non-deterministic LLM decisions Servicio único por solicitud Modelos de llamadas + llamadas de herramientas + delegaciones Costos fijos por solicitud El costo varía según el uso de token AI Agents 101: The Agentic Loop Considere el ciclo central de un sistema de agentes multi-AI.Este es el patrón engañosamente simple que ha llevado a la actual ola de innovación en los sistemas de IA. A continuación se muestra un ciclo de agentes simplificado, ya que salimos muchos de los matices, pero la idea es que enviamos una primera llamada para que el LLM responda con llamadas de herramientas o llamadas de delegación, y si no hay ninguna o entramos en los pasos máximos, entonces enviamos la respuesta final. 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) As we can see, each iteration of this loop may take a different path. The model might need one tool call or five. El logging tradicional (por ejemplo, “la solicitud comenzó” ... “la solicitud se completó”) no le dice casi nada sobre lo que realmente sucedió. Y una vez que tomemos esto en un sistema distribuido se vuelve aún más complejo para entender lo que está sucediendo - como veremos en este post. En la última sección de este post también te mostraremos cómo instrumentaremos este ciclo de agentes específicamente también. Hemos reemplazado “request-response” por “request—panic—tool—panic—delegate—panic—respuesta”. Hemos reemplazado “request-response” por “request—panic—tool—panic—delegate—panic—respuesta”. Los tres pilares de la observabilidad de los agentes OpenTelemetry proporciona tres tipos de datos de telemetría, cada uno de los cuales sirve un propósito distinto para los sistemas de agentes. Traces La jerarquía de rastros mapea directamente lo que el agente hizo, capturando y conectando cada salto a lo largo del viaje. 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 responde: “¿Qué camino tomó esta solicitud a través de mis agentes?” Respuesta: “¿Qué camino tomó esta solicitud a través de mis agentes?” Traces Logs Tradicionalmente en el software, el logging proporciona una visión interna del comportamiento y el flujo de la aplicación. Estos proporcionan una manera de entender lo que sucedió durante una solicitud o sesión en particular, y también capturan información crítica, como excepciones. En OpenTelemetry, los registros también se capturan con los rastros respectivos para que puedan conectarse respectivamente. 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 responde: “¿Qué “pensó” el agente en cada paso?” Logs responde: “¿Qué “pensó” el agente en cada paso?” Metrics Las métricas proporcionan KPIs granulares basados en el tiempo que evolucionan a lo largo del tiempo, y se pueden agregar y ventanular para contar una historia histórica particular. <- Store number of tokens per request <- Store success / failure rate of requests <- Store latency for model calls Metrics responde: “¿Cómo funciona mi sistema en general?” Respuesta: “¿Cómo funciona mi sistema en general?” Metrics Bringing it all together La magia ocurre cuando estos tres están correlacionados (aka conectados). 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 Context Propagation Cuando el agente A delega a el agente B, que delega a el agente C, usted quiere un único rastro unificado - no tres desconectados. This requires . context propagation Esto implica pasar el contexto de rastreo a través de los encabezados HTTP utilizando el estándar W3C Trace Context. El resultado es un rastro unificado en todos los agentes - aquí está un ejemplo que muestra cómo un contexto de rastro se extiende a través del agente coordinador, el agente investigador y el agente analista. 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 Sin propagación de contexto, el desmantelamiento de múltiples agentes es simplemente adivinación distribuida. Sin propagación de contexto, el desmantelamiento de múltiples agentes es simplemente adivinación distribuida. El caso de uso práctico: un sistema de investigación multi-agente Ahora vamos a empezar a construir algo concreto. We’ll use , un marco de código abierto para desplegar, gestionar y escalar sistemas multiagentes en Kubernetes. El caos (Sistema de Orquestación de Agentes de Kubernetes) El caos El sistema multi-agente para monitorear Nuestro caso de uso consiste en un agente coordinador que delega tareas de investigación y análisis a subagentes especializados: Cada componente -agentes, herramientas y APIs de modelo- envía rastros, métricas y registros a un colector de OpenTelemetry, que transmite todo a su backend elegido para visualización y análisis. Requisitos: Comandos y herramientas Antes de empezar, necesitarás: KAOS CLI instalado: pip instalar kaos-cli==0.2.7 Una clave de API LLM (Cualquier proveedor como OpenAI, Nebius, etc.) kubectl, casco y un clúster Kubernetes (KIND, minikube, o un clúster de nube) Installing KAOS Primero, vamos a instalar el operador KAOS con OpenTelemetry habilitado y un backend de observabilidad. (que se recomienda): 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 Una vez que esté en funcionamiento, podemos crear nuestro sistema multiagente utilizando una de las muestras proporcionadas con el CLI. También puede ver el ANEXO al final del post del blog para desplegar cada uno de los componentes uno por uno. kaos samples deploy \ 3-hierarchical-agents \ --provider openai \ --wait \ --api-secret # This will prompt your api-key secret Puede ver la bandera del proveedor que especifica el backend, como nebius, gemini, bedrock y cientos de otros proveedores [KAOS docs], así como su --api-secret que se pedirá de forma interactiva. Puede ver la bandera del proveedor que especifica el backend, como nebius, gemini, bedrock y cientos de otros proveedores [KAOS docs], así como su --api-secret que se pedirá de forma interactiva. Una vez instalado, abre la interfaz con el siguiente comando. kaos ui --monitoring-enabled Esto nos permite ver el sistema multi-agente implementado: Poniéndolo todo juntos: monitoreando el caos Ahora vamos a generar algún tráfico y comenzar a monitorear el CAOS. Interacting with Agents Puedes interactuar con los agentes de varias maneras: # 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." Activar el chat a través de la interfaz de usuario: Detrás de las escenas, esto desencadena una compleja cadena de operaciones: El supervisor recibe la solicitud El supervisor llama al LLM, que decide delegar El agente investigador es invocado para la investigación de mercado (y llama a dos subagentes investigadores) El agente analista calcula las acciones de mercado (y llama a dos subagentes analistas) Supervisor synthesizes the final response Todo esto se captura en rastros audibles: cada llamada LLM, cada ejecución de herramientas, cada delegación. Ver rastros: comprender el flujo de solicitudes A diferencia de los servicios tradicionales de solicitud-respuesta, los agentes toman múltiples decisiones por solicitud.Traces le permite ver cada punto de decisión, cuánto tiempo se tomó y qué camino eligió el agente. Why traces matter for agentic systems La lista de rastro muestra todas las solicitudes que fluyen a través de sus agentes. Cada rastro representa una interacción completa con el usuario. Haga clic en una pista para ver el flujo completo de solicitudes: Una única pista que muestra al coordinador delegando a los agentes del investigador y del analista, cada una representando una operación distinta. Esta visualización de rastros responde a las preguntas que de otro modo requerirían horas de log spelunking: The web_search tool took 8 seconds. Why did this request take 15 seconds? ¿Cuáles son los agentes implicados? Coordinador → Investigador → Analista → Coordinador. 6 calls across the three agents. How many LLM calls were made? ¿Alguna herramienta falló?Todas las herramientas se completaron con éxito (intervalos verdes). Log Correlation: Comprender el razonamiento del agente Los rastros te dicen Los logos te dicen OpenTelemetry los correlaciona automáticamente a través de y los atributos. Qué why trace_id span_id Cada entrada de registro incluye estos identificadores, lo que le permite: Click on a span in your trace View all logs emitted during that span Understand the agent’s reasoning at each step Es posible ver la vista de los propios registros, así como más detalles. We can then drill deeper into individual log entries. Aquí, por ejemplo, podemos ver el “Tareas de la delegación: ...”. This shows us the entire prompt that was delegated, which is quite useful for diagnostics and debugging. Esto incluye Contexto de registro completo, incluyendo todos los atributos, etiquetas de recursos y el mensaje completo. Seguimiento de excepciones: encontrar problemas de producción OpenTelemetry captura las excepciones como ciudadanos de primera clase, y las adhiere al rango en el que ocurrieron. Podemos intentar esto pidiendo al supervisor que delegue a un subagente no existente: # 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." O directamente a través de la 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. Esta lista captura los errores en todo el sistema y los correlaciona también con los respectivos rastros de solicitud y registros. También podemos filtrar por diferentes servicios (agentes), así como por otros atributos. Podemos ver claramente que la excepción se debió a un intento de delegación incorrecta. Y también podemos visualizar el error en la vista de rastro. Metrics: Vista general de operaciones 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 Volumen de solicitud por agente kaos.request.duration Latency distribution (P50, P95, P99) kaos.model.calls Uso de la API LLM (indicador de costes) kaos.tool.calls Frecuencia de ejecución de herramientas kaos.delegations Modelo de coordinación multiagente Estas métricas permiten alertar sobre problemas de producción: Latencia de solicitud > 30s Error rate > 5% Fracaso de llamadas de modelo > 1% También podemos visualizarlos: Under the Hood: How It Works 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. La arquitectura KAOS separa el plano de control (Go) del plano de datos (Python); dentro de la aplicación Python tenemos un gerente de OpenTelemetry (KaosOtelManager) para proporcionar utilidades para simplificar los flujos de trabajo. La información clave: la configuración de la telemetría fluye desde Operador -> Data Plane -> OTEL Collector. Los usuarios configuran la telemetría una vez en values.yaml, y el operador la propaga a todos los componentes. The key insight: Los usuarios configuran telemetría una vez en , y el operador lo propaga a todos los componentes. telemetry configuration flows from Operator -> Data Plane -> OTEL Collector values.yaml Desarrollar la lógica básica Cuando se trata de sistemas de agentes, no se trata sólo de instrumentar la solicitud-respuesta, sino también de capturar el flujo a través de las iteraciones de agentes. To start with we ensure that we capture the overarching span across the top level request/response. We then should also instrument other key components such as the Agentic Loop (example below), as well as extra calls such as MCP calls, and agent delegations. # 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 Ahora podemos usar el mismo patrón en el círculo de agentes, donde podemos capturar las iteraciones con el contexto respectivo. Esto será importante ya que también podemos capturar los registros y métricas correlacionados que están conectados a esta solicitud particular. # 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... Tener los intervalos definidos en el lugar es lo que nos permite rastrear la solicitud a través de saltos. Algunos patrones útiles a tener en cuenta: Intervalos jerárquicos: hay un intervalo parental para el ciclo, intervalo de niños para cada paso, intervalo de nietos para las operaciones, etc. : Logs are emitted while trace context is active, which allows correlating the logs Log before span close : We are using explicit try/finally pattern to ensure spans are always closed, but we can also use context managers (i.e. clause) Explicit span management with Esto también es lo que nos permite visualizar la descomposición de los rastros y intervalos de solicitud. Context Propagation for Multi-Agent Systems When delegating to sub-agents (running in separate pods), we must propagate trace context: # 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"] Propagando los rastros del contexto También necesitamos asegurarnos de que el contexto sea recibido e incorporado. # 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 and Correlation Para la correlación log-trace, conectamos el logging de Python a OpenTelemetry. Si ha utilizado anteriormente algo como la pila ELK, con OpenTelemetry ahora tiene una configuración en la que los registros son empujados en lugar de tirados, utilizando la conexión GRPC OTEL. La herramienta de logging inyecta automáticamente y en los registros de registro cuando existe un contexto de span activo. trace_id span_id Para configurar esta conexión, puede configurarla con algunas líneas como se describe a continuación. 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) Metricas para las operaciones de agentes También podemos rastrear métricas utilizando el SDK de OpenTelemetry. Si ha utilizado Prometheus en el pasado, las métricas en este caso no se exponen a través de un punto final que sería consultado a través de un colector prometéus. En cambio, esto también permite una arquitectura push donde se envía al colector OTEL a través de la conexión GRPC OLTP al colector OTel. Al seleccionar métricas, buscamos rastrear métricas con etiquetas de baja cardinalidad para evitar explosiones de cardinalidad, como se describe en la muestra a continuación. 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 : Nunca utilice ID de sesión, ID de usuario, contenido de solicitud u otros valores ilimitados como etiquetas métricas. Avoid high-cardinality labels The Tip of The Iceberg Esta es una introducción suave a la observabilidad en sistemas multi-agente, y proporciona una visión de alto nivel de lo que son algunos de los principales componentes involucrados. Esto también debería proporcionarle suficiente intuición para instrumentar sus sistemas de agentes conscientemente, sin embargo, tendrá que identificar qué patrones funcionan mejor en sus contextos particulares. Instrumentar sistemas de IA de agentes con OpenTelemetry requiere comprender los desafíos únicos que estos sistemas presentan: Los circuitos iterativos necesitan jerarquías que mapeen operaciones lógicas requires explicit context propagation using W3C Trace Context Multi-agent delegation La ejecución de herramientas se beneficia de espacios dedicados con nombramiento claro La correlación log-trace requiere la emisión de registros antes de cerrar el rango Las métricas necesitan etiquetas de baja cardinalidad para evitar explosiones de almacenamiento Los patrones que hemos cubierto se aplican a cualquier sistema de agentes, no solo a KAOS. The agents of tomorrow will be as ubiquitous as microservices are today, and OpenTelemetry gives you the visibility to operate them with confidence. Los agentes del mañana serán tan omnipresentes como los microservicios de hoy, y OpenTelemetry te da la visibilidad para operarlos con confianza. Recursos KAOS Framework: github.com/axsaucedo/kaos - El marco de código abierto utilizado en este artículo : - Full CLI and CRD documentation KAOS Documentation axsaucedo.github.io/kaos OpenTelemetry Python: opentelemetry.io/docs/languages/python - Documentación oficial del SDK de Python OpenTelemetry GenAI Conventions: github.com/open-telemetry/semantic-conventions - Estándares emergentes para la observabilidad de la IA SigNoz: signoz.io - APM de código abierto con soporte nativo de OpenTelemetry ANEXO: Crear el sistema multi-agente manualmente En esta sección, creamos los componentes del sistema de agentes manualmente en lugar de usar las utilidades para los curiosos! Te mostraremos cómo puedes hacer esto con CLI, pero también puedes hacerlo con la interfaz de usuario, así como con de manera directa. kubectl Paso 1: Primero nos conectamos a los LLM con una ModelAPI El resource in KAOS provides a unified interface for LLM access. It supports two modes: ModelAPI Modo Proxy: Ruta las solicitudes a través de LiteLLM a proveedores externos (OpenAI, Anthropic, Nebius, etc.) Modo alojado: trae modelos a su clúster (a través de un carril lateral) y lo ejecuta en el servidor para inferencias La ModelAPI se puede implementar fácilmente a través de CLI. Tenga en cuenta que para que nuestros agentes utilicen las APIs del modelo necesitamos proporcionar nuestra clave de API de autenticación. Para este ejemplo usaremos Nebius ya que es fácil de configurar, pero también puede configurar OpenAI, Gemini y docenas de otros. Tenga en cuenta que para que nuestros agentes utilicen las APIs del modelo necesitamos proporcionar nuestra clave de API de autenticación. Para este ejemplo usaremos Nebius ya que es fácil de configurar, pero también puede configurar OpenAI, Gemini y docenas de otros. kaos modelapi deploy llm-proxy \ --namespace kaos-hierarchy \ --provider nebius \ --api-key # When provided without value this prompts the key securely Desde una perspectiva de observabilidad, la ModelAPI nos da visibilidad a la latencia de llamadas del modelo, el uso de token y las tasas de error - métricas críticas para comprender el rendimiento del agente y controlar los costes. Paso 2: Despliegue los servidores de herramientas de MCP en KAOS proporcionan herramientas que los agentes pueden utilizar. MCP (Model Context Protocol) Servers KAOS permite a los servidores nativos de FastMCP crear y implementar sus propias imágenes. KAOS también admite múltiples tiempos de ejecución nativos de MCP a través de un registro. Los más comunes son: 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 Define tools as inline Python functions for testing kubernetes Operaciones de Kubernetes CRUD slack Integración de mensajes Slack custom Imagen de tu propio contenedor Para nuestra demostración, crearemos un servidor de calculadora.En la producción, se conectaría a APIs reales, bases de datos o servicios externos. Nota: En esta sección utilizamos el tiempo de ejecución de la cadena de python para pruebas rápidas, sin embargo, para la implementación listo para la producción utilice la implementación de imagen personalizada. Nota: En esta sección utilizamos el tiempo de ejecución de la cadena de python para pruebas rápidas, sin embargo, para la implementación listo para la producción utilice la implementación de imagen personalizada. Primero creamos el mcp, which will have a simple la herramienta que agregará dos números y devolverá el resultado. 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 Entonces creamos un mcp, que también es una herramienta simple que recibe una cadena y devuelve el mismo valor que la cadena. 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 Y podemos enviar una solicitud para probar el 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" Desde el punto de vista de la observabilidad, mostraremos lo importante que es comprender las llamadas que son enviadas por cualquier agente (o cualquier servicio externo) y procesadas por los propios servidores MCP. 3a. el investigador El El recurso en KAOS representa una entidad de IA que puede procesar solicitudes, modelos de llamadas, ejecutar herramientas y delegar a otros agentes. Agent Exponer un punto final compatible con OpenAI /v1/chat/completions Implementa el ciclo de agencia (modelo > herramientas > modelo > ...) Memoria configurable para el estado de sesión The Researcher agent will specialise in gathering information: kaos agent deploy researcher \ --model "openai/gpt-4o" \ --mcp echo-search \ --description "Research specialist" \ --instructions "You research topics and provide ." \ --expose=true \ --wait Para la observación de un solo agente, nos preocupamos por: Latencia de llamada del modelo: ¿Cuánto tarda la inferencia? Tiempo de ejecución de herramientas: ¿Las herramientas responden rápidamente? Conto de pasos: ¿Cuántas iteraciones necesita el agente? 3b. el agente analista El agente analista se centra en el análisis de datos y los cálculos: 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. El agente supervisor Por último, el Coordinador orquestará a los otros agentes. Para la observabilidad multiagente, obtenemos preocupaciones adicionales: Padrones de delegación: ¿Qué agentes son llamados y con qué frecuencia? : How much time is spent in delegation vs. local processing? Cross-agent latency : Can we see the full request flow across agents? Trace correlation 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 ¡Y estamos terminados! ¡Ahora puedes volver a la cima y correr a través del paseo de la observabilidad con tu configuración desplegada!