Khả năng quan sát sản xuất cho Multi-Agent AI (với KAOS + OTel + SigNoz)

Hướng dẫn thực tế để thêm khả năng quan sát cấp độ sản xuất cho các hệ thống AI đa đại lý với Hệ thống phối hợp đại lý K8s bằng cách sử dụng OpenTelemetry và SigNoz Bạn đã xây dựng một đại lý AI hoạt động trong máy tính xách tay của bạn. nó tự động chuỗi các công cụ với nhau, giao nhiệm vụ cho các đại lý phụ chuyên gia và tạo ra kết quả âm thanh. Sau đó bạn triển khai nó vào sản xuất: Một người dùng báo cáo rằng một yêu cầu “đã mất mãi mãi”. Một người khác nói rằng họ đã nhận được một câu trả lời kỳ lạ. Các nhật ký của bạn cho thấy các đại lý chạy Nhưng điều gì đã xảy ra trong 45 giây giữa yêu cầu và câu trả lời? Chào mừng bạn đến The observability challenge of agentic systems. “Các nhật ký truyền thống nói với bạn rằng nó đã chạy, sự quan sát cho bạn biết tại sao nó lại chạy như vậy.” “Các nhật ký truyền thống nói với bạn rằng nó đã chạy, sự quan sát cho bạn biết tại sao nó lại chạy như vậy.” Trong bài viết này, chúng tôi sẽ đi qua một ví dụ hoàn chỉnh về khả năng quan sát cho các hệ thống đa đại lý. Dưới đây là một bản xem trước của hệ thống đa đại lý mà chúng tôi sẽ phân tích, giám sát và chẩn đoán trong bài viết này: Hãy bắt đầu với câu hỏi chính của... Tại sao các hệ thống đa tác nhân cần có khả năng quan sát (khác biệt)? Microservices truyền thống có các mô hình có thể dự đoán được: một yêu cầu đến, một số quá trình xử lý xảy ra, một phản hồi đi ra. sự chậm trễ là tương đối nhất quán, các con đường mã là xác định, và xử lý lỗi thường liên quan đến việc theo dõi một chủ đề thực thi duy nhất. Không chỉ là một yêu cầu trả lời Các hệ thống đại lý phá vỡ các giả định truyền thống: 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 Trả lời yêu cầu đồng bộ Iterative Reasoning Loops (Những vòng lặp lý luận Độ trễ dự đoán (50-500ms) Biến đổi: 100ms đến 60+ giây Deterministic code con đường Các quyết định LLM không xác định Dịch vụ duy nhất theo yêu cầu Model calls + tool calls + delegations Chi phí cố định theo yêu cầu Chi phí khác nhau theo sử dụng token AI Agents 101: The Agentic Loop Hãy xem xét vòng tròn cốt lõi của một hệ thống đại lý đa AI.Đây là mô hình đơn giản lừa dối đã dẫn đến làn sóng đổi mới hiện tại trong các hệ thống AI. Dưới đây là một vòng tròn đại lý đơn giản khi chúng tôi bỏ qua rất nhiều sắc thái, nhưng ý tưởng là chúng tôi gửi một cuộc gọi đầu tiên cho LLM để trả lời với các cuộc gọi công cụ hoặc cuộc gọi phái đoàn, và nếu không có hoặc chúng tôi chạy vào các bước tối đa, sau đó chúng tôi gửi câu trả lời cuối cùng. 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) Như chúng ta có thể thấy, mỗi lần lặp của vòng lặp này có thể đi một con đường khác nhau. Việc ghi nhật ký truyền thống (ví dụ như “yêu cầu bắt đầu” ... “yêu cầu hoàn thành”) hầu như không cho bạn biết gì về những gì thực sự đã xảy ra. Và một khi chúng ta đưa điều này vào một hệ thống phân tán, nó trở nên phức tạp hơn để hiểu những gì đang xảy ra - như chúng ta sẽ thấy trong bài viết này. Trong phần cuối cùng của bài viết này, chúng tôi cũng sẽ cho bạn thấy cách chúng tôi sẽ cụ thể hóa vòng tròn đại lý này. Chúng tôi đã thay thế “request-response” bằng “request—panic—tool—panic—delegate—panic—response”. Chúng tôi đã thay thế “request-response” bằng “request—panic—tool—panic—delegate—panic—response”. Ba trụ cột của Agent Observability OpenTelemetry cung cấp ba loại dữ liệu từ xa, mỗi loại phục vụ một mục đích riêng biệt cho các hệ thống đại lý. Traces The trace hierarchy maps directly to what the agent did, capturing and connecting every hop across the journey. 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 trả lời: “Yêu cầu này đã đi theo con đường nào qua các đại lý của tôi?” Traces trả lời: “Yêu cầu này đã đi theo con đường nào qua các đại lý của tôi?” Logs Theo truyền thống trong phần mềm, ghi nhật ký cung cấp một cái nhìn bên trong về hành vi và dòng chảy của ứng dụng. Chúng cung cấp một cách để hiểu những gì đã xảy ra trong suốt một yêu cầu hoặc phiên cụ thể, và cũng thu thập thông tin quan trọng như ngoại lệ. In OpenTelemetry, the logs also are captured with the respective traces so they can be connected respectively. 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 trả lời: “Các nhân viên “suy nghĩ” gì ở mỗi bước?” Trả lời: “Các nhân viên “suy nghĩ” gì ở mỗi bước?” Logs Metrics Các chỉ số cung cấp các KPI dựa trên thời gian chi tiết mà phát triển theo thời gian, và có thể được tổng hợp và đóng cửa sổ để kể một câu chuyện lịch sử cụ thể. <- Store number of tokens per request <- Store success / failure rate of requests <- Store latency for model calls Metrics trả lời: “Hệ thống của tôi hoạt động như thế nào tổng thể?” Trả lời: “Hệ thống của tôi hoạt động như thế nào tổng thể?” Metrics Bringing it all together Sự kỳ diệu xảy ra khi ba điều này tương quan (còn được gọi là kết nối). Điều này cho phép chúng tôi làm những điều như "bấm vào nhật ký ERROR đó trong backend khả năng quan sát của bạn" và chẩn đoán khoảng thời gian chính xác trong dấu vết nơi sự cố xảy ra. Multi-Agent Context Phát triển Khi Agent A đại diện cho Agent B, người đại diện cho Agent C, bạn muốn một dấu vết thống nhất duy nhất - không phải ba dấu vết bị mất kết nối. Điều này đòi hỏi . context propagation This involves passing trace context through HTTP headers using the W3C Trace Context standard. Kết quả là một dấu vết thống nhất trên tất cả các đại lý - đây là một ví dụ cho thấy cách một bối cảnh dấu vết trải dài trên đại lý điều phối viên, đại lý nhà nghiên cứu và đại lý nhà phân tích. 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 Nếu không có sự lây lan bối cảnh, xử lý lỗi đa đại lý chỉ là đoán phân tán. Nếu không có sự lây lan bối cảnh, xử lý lỗi đa đại lý chỉ là đoán phân tán. Các trường hợp sử dụng thực tế: Một hệ thống nghiên cứu đa tác nhân Bây giờ chúng ta hãy bắt đầu xây dựng một cái gì đó cụ thể. Chúng ta sẽ sử dụng , một framework mã nguồn mở để triển khai, quản lý và mở rộng các hệ thống đa đại lý trong Kubernetes. hỗn loạn (Hệ thống phối hợp đại lý Kubernetes) hỗn loạn Hệ thống Multi-Agent để giám sát Trường hợp sử dụng của chúng tôi bao gồm một đại lý phối hợp, người ủy thác các nhiệm vụ nghiên cứu và phân tích cho các đại lý phụ chuyên gia: Mỗi thành phần - đại lý, công cụ và API mô hình - gửi dấu vết, số liệu và nhật ký đến một bộ sưu tập OpenTelemetry, chuyển mọi thứ đến backend đã chọn của bạn để hình dung và phân tích. Tiêu đề: Commands & Tools Trước khi chúng tôi bắt đầu, bạn sẽ cần: KAOS CLI cài đặt: pip install kaos-cli==0.2.7 Một khóa API LLM (bất kỳ nhà cung cấp nào như OpenAI, Nebius, v.v.) kubectl, helm và một cụm Kubernetes (KIND, minikube, hoặc một cụm đám mây) Tạo ra hỗn loạn Đầu tiên, chúng ta hãy cài đặt nhà khai thác KAOS với OpenTelemetry kích hoạt và một backend khả năng quan sát. chúng ta sẽ sử dụng SigNoz như một tùy chọn mã nguồn mở, OpenTelemetry-native. (được khuyên dùng): 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 Một khi nó đang chạy, chúng tôi có thể tạo hệ thống đa đại lý của chúng tôi bằng cách sử dụng một trong những mẫu được cung cấp với CLI. Bạn cũng có thể thấy ANNEX ở cuối bài đăng blog để triển khai từng thành phần một. kaos samples deploy \ 3-hierarchical-agents \ --provider openai \ --wait \ --api-secret # This will prompt your api-key secret Bạn có thể thấy lá cờ nhà cung cấp xác định backend, chẳng hạn như nebius, gemini, bedrock và 100s của các nhà cung cấp khác [KAOS docs], cũng như -api- bí mật của bạn sẽ được nhắc tương tác. Bạn có thể thấy lá cờ nhà cung cấp xác định backend, chẳng hạn như nebius, gemini, bedrock và 100s của các nhà cung cấp khác [KAOS docs], cũng như -api- bí mật của bạn sẽ được nhắc tương tác. Sau khi cài đặt, bạn mở UI với lệnh sau. kaos ui --monitoring-enabled Điều này cho phép chúng ta xem hệ thống đa đại lý được triển khai: Đặt tất cả mọi thứ lại với nhau: Giám sát sự hỗn loạn Now let’s generate some traffic and start monitoring KAOS. Tương tác với Agent Bạn có thể tương tác với các đại lý theo nhiều cách: # 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." Kích hoạt chat qua giao diện người dùng: Đằng sau các cảnh, điều này kích hoạt một chuỗi các hoạt động phức tạp: Người giám sát nhận được yêu cầu Người giám sát gọi LLM, người quyết định giao phó Các nhà nghiên cứu đại lý được gọi cho nghiên cứu thị trường (và gọi hai nhà nghiên cứu phụ đại lý) Phân tích đại lý tính toán thị phần (và gọi hai phân tích đại lý phụ) Người giám sát tổng hợp câu trả lời cuối cùng Tất cả điều này được ghi lại trong các dấu vết có thể kiểm toán: mỗi cuộc gọi LLM, mỗi thực hiện công cụ, mỗi phái đoàn. Xem dấu vết: Hiểu yêu cầu dòng chảy Không giống như các dịch vụ yêu cầu trả lời truyền thống, các đại lý đưa ra nhiều quyết định cho mỗi yêu cầu.Traces cho phép bạn xem từng điểm quyết định, mất bao lâu và con đường mà đại lý đã chọn. Why traces matter for agentic systems Danh sách dấu vết hiển thị tất cả các yêu cầu chảy qua các đại lý của bạn. Mỗi dấu vết đại diện cho một tương tác người dùng hoàn chỉnh. Nhấp vào một theo dõi để xem dòng yêu cầu đầy đủ: Một dấu vết duy nhất cho thấy điều phối viên giao phó cho các đại lý nhà nghiên cứu và nhà phân tích, với mỗi khoảng thời gian đại diện cho một hoạt động riêng biệt. Trình trực quan hóa dấu vết này trả lời các câu hỏi mà nếu không sẽ đòi hỏi nhiều giờ ghi nhật ký: Tại sao yêu cầu này mất 15 giây? công cụ web_search mất 8 giây. Những người tham gia có liên quan gì? Coordinator → Researcher → Analyst → Coordinator. Có bao nhiêu cuộc gọi LLM được thực hiện? 6 cuộc gọi trên ba đại lý. Có bất kỳ công cụ nào thất bại không? Tất cả các công cụ đã hoàn thành thành công (khu vực màu xanh lá cây). Log Correlation: Hiểu lý luận của đại lý Dấu vết cho bạn biết Lời bài hát: Logs Tell You OpenTelemetry tương quan chúng tự động thông qua và Các thuộc tính what Tại sao trace_id span_id Mỗi mục nhập nhật ký bao gồm các ID này, cho phép bạn: Click on a span in your trace View all logs emitted during that span Hiểu lý luận của đại lý ở mỗi bước It is possible to see the view of the logs themselves as well as further details. Sau đó, chúng ta có thể khoan sâu hơn vào các mục nhật ký riêng lẻ. Here for example we can view the log Nhiệm vụ của đại diện: ...” Điều này cho chúng tôi thấy toàn bộ lời nhắc đã được ủy quyền, điều này khá hữu ích cho chẩn đoán và xử lý lỗi. Điều này bao gồm ngữ cảnh nhật ký đầy đủ bao gồm tất cả các thuộc tính, nhãn tài nguyên và thông điệp đầy đủ. Exception Tracking: Finding Production Issues In production, things fail. OpenTelemetry captures exceptions as first-class citizens, and attaches them to the span where they occurred. 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." Or directly via the 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. Chúng tôi cũng có thể lọc theo các dịch vụ khác nhau (các đại lý), cũng như các thuộc tính khác. 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: Tổng quan hoạt động Trong khi dấu vết cho thấy các yêu cầu cá nhân, chỉ số cho thấy xu hướng theo thời gian. Dưới đây là một số ví dụ về các số liệu chính trong các hệ thống đại lý: 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 sử dụng (các chỉ số chi phí) kaos.tool.calls Tần số thực hiện công cụ kaos.delegations Multi-agent coordination patterns These metrics enable alerting on production issues: Yêu cầu độ trễ > 30s Tỷ lệ lỗi > 5% Model call failures > 1% We can also visualise them: Under the Hood: Làm thế nào nó hoạt động 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. The Architecture KAOS tách bảng điều khiển (Go) khỏi bảng dữ liệu (Python); bên trong ứng dụng Python, chúng tôi có trình quản lý OpenTelemetry (KaosOtelManager) để cung cấp các tiện ích để đơn giản hóa các quy trình làm việc. The key insight: . Users configure telemetry once in , and the operator propagates it to all components. telemetry configuration flows from Operator -> Data Plane -> OTEL Collector values.yaml Khái niệm quan trọng: Người dùng cấu hình telemetry một lần trong , and the operator propagates it to all components. telemetry configuration flows from Operator -> Data Plane -> OTEL Collector values.yaml Sử dụng Core Logic Khi nói đến các hệ thống đại lý, nó không chỉ là về việc dụng cụ hóa yêu cầu-phản ứng, mà còn là về việc nắm bắt dòng chảy qua các lần lặp của các đại lý. Để bắt đầu, chúng tôi đảm bảo rằng chúng tôi nắm bắt phạm vi tổng thể trên yêu cầu / phản hồi cấp cao nhất. sau đó chúng tôi cũng nên dụng cụ các thành phần quan trọng khác như vòng tròn đại lý (ví dụ dưới đây), cũng như các cuộc gọi bổ sung như cuộc gọi MCP và phái đoàn đại lý. # 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 Bây giờ chúng ta có thể sử dụng cùng một mô hình trong vòng tròn đại lý, nơi chúng ta có thể nắm bắt các lặp lại với ngữ cảnh tương ứng.Điều này sẽ quan trọng vì chúng ta cũng có thể nắm bắt các nhật ký và số liệu tương quan được kết nối với yêu cầu cụ thể này. # 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... Having the spans defined in placed is what allows us to trace the request across hops. Một số mô hình hữu ích để lưu ý: : There is a parent span for the loop, child spans for each step, grandchild spans for operations, etc. Hierarchical spans Log trước khi kết thúc phạm vi: Các nhật ký được phát ra trong khi ngữ cảnh theo dõi đang hoạt động, cho phép tương quan các nhật ký Quản lý phạm vi rõ ràng: Chúng tôi đang sử dụng mô hình cố gắng / kết thúc rõ ràng để đảm bảo các phạm vi luôn đóng, nhưng chúng tôi cũng có thể sử dụng người quản lý ngữ cảnh (tức là với điều khoản) This is also what allows us to then visualise the breakdown of the request traces and spans. Context Propagation cho các hệ thống Multi-Agent Khi giao phó cho các đại lý phụ (chạy trong các pods riêng biệt), chúng ta phải truyền bá bối cảnh theo dõi: # 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"] Ensuring Trace Context Propagates Chúng ta cũng cần đảm bảo rằng bối cảnh được nhận và nhúng. # 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 Đối với mối tương quan log-trace, chúng tôi kết nối logging của Python với OpenTelemetry. Nếu trước đây bạn đã sử dụng một cái gì đó như đống ELK, với OpenTelemetry bây giờ bạn có một thiết lập nơi các nhật ký được đẩy thay vì kéo, bằng cách sử dụng kết nối GRPC OTEL. Các công cụ logging tự động tiêm and vào các bản ghi nhật ký khi có bối cảnh span đang hoạt động. trace_id span_id Để thiết lập kết nối này, bạn có thể cấu hình nó với một vài dòng như mô tả bên dưới. 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) Metrics for Agent Operations Chúng tôi cũng có thể theo dõi số liệu bằng cách sử dụng OpenTelemetry SDK. Nếu bạn đã sử dụng Prometheus trong quá khứ, các số liệu trong trường hợp này không được phơi bày thông qua một điểm cuối mà sẽ được truy vấn thông qua một bộ sưu tập prometheus. thay vào đó, điều này cũng cho phép một kiến trúc đẩy nơi nó được gửi đến bộ sưu tập OTEL thông qua kết nối GRPC OLTP với bộ sưu tập OTel. Khi chọn các số liệu, chúng tôi nhằm mục đích theo dõi các số liệu với các nhãn cardinality thấp để tránh các vụ nổ cardinality, như được mô tả trong mẫu dưới đây. 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}) Tránh các nhãn có độ cardinality cao: Không bao giờ sử dụng ID phiên, ID người dùng, nội dung nhắc hoặc các giá trị không giới hạn khác làm nhãn đo lường. Tránh các nhãn có độ cardinality cao: Không bao giờ sử dụng ID phiên, ID người dùng, nội dung nhắc hoặc các giá trị không giới hạn khác làm nhãn đo lường. Tip của Iceberg Đây là một giới thiệu nhẹ nhàng về khả năng quan sát trong các hệ thống đa đại lý, và cung cấp một cái nhìn cấp cao về một số thành phần chính liên quan. Điều này cũng nên cung cấp cho bạn đủ trực giác để công cụ hệ thống đại lý của bạn một cách lương tâm, tuy nhiên bạn sẽ cần phải xác định những mô hình nào hoạt động tốt nhất trong bối cảnh cụ thể của bạn. Công cụ hóa các hệ thống AI đại lý với OpenTelemetry đòi hỏi phải hiểu những thách thức độc đáo của các hệ thống này: need span hierarchies that map to logical operations Iterative loops Nhiệm vụ đa đại lý đòi hỏi sự phổ biến ngữ cảnh rõ ràng bằng cách sử dụng W3C Trace Context Công cụ thực hiện được hưởng lợi từ phạm vi dành riêng với tên rõ ràng requires emitting logs before span close Log-trace correlation Metrics cần nhãn cardinality thấp để tránh các vụ nổ lưu trữ Các mô hình chúng tôi đã đề cập áp dụng cho bất kỳ hệ thống đại lý nào, không chỉ là KAOS. The agents of tomorrow will be as ubiquitous as microservices are today, and OpenTelemetry gives you the visibility to operate them with confidence. Các đại lý của ngày mai sẽ được phổ biến như các dịch vụ vi mô ngày nay, và OpenTelemetry cung cấp cho bạn khả năng hiển thị để vận hành chúng với sự tự tin. Resources KAOS Framework: github.com/axsaucedo/kaos - Khung nguồn mở được sử dụng trong bài viết này : - Full CLI and CRD documentation KAOS Documentation axsaucedo.github.io/kaos OpenTelemetry Python: opentelemetry.io/docs/languages/python - Tài liệu SDK chính thức của Python OpenTelemetry GenAI Conventions: github.com/open-telemetry/semantic-conventions - Các tiêu chuẩn mới nổi cho khả năng quan sát AI SigNoz: signoz.io - APM mã nguồn mở với hỗ trợ OpenTelemetry bản địa Phụ lục: Tạo hệ thống đa đại lý bằng tay Trong phần này, chúng tôi tạo các thành phần hệ thống đại lý bằng tay thay vì sử dụng các tiện ích cho những người tò mò! We’ll show you how you can do this with CLI but you can do this also with the UI as well as with trực tiếp kubectl Step 1: We first connect to LLMs with a ModelAPI The tài nguyên trong KAOS cung cấp một giao diện thống nhất cho quyền truy cập LLM. Nó hỗ trợ hai chế độ: ModelAPI Chế độ proxy: Đường dẫn các yêu cầu thông qua LiteLLM đến các nhà cung cấp bên ngoài (OpenAI, Anthropic, Nebius, v.v.) Hosted Mode: kéo các mô hình vào cụm của bạn (thông qua side-car) và chạy nó trên máy chủ để suy luận The ModelAPI can be deployed easily 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 Lưu ý rằng để các đại lý của chúng tôi sử dụng các API mô hình, chúng tôi cần cung cấp khóa API xác thực của chúng tôi. vì nó dễ dàng để thiết lập, nhưng bạn cũng có thể thiết lập OpenAI, Gemini và hàng chục người khác. Thiên đường kaos modelapi deploy llm-proxy \ --namespace kaos-hierarchy \ --provider nebius \ --api-key # When provided without value this prompts the key securely Từ quan điểm có thể quan sát được, ModelAPI cung cấp cho chúng ta khả năng hiển thị về độ trễ cuộc gọi mô hình, sử dụng token và tỷ lệ lỗi - các chỉ số quan trọng để hiểu hiệu suất của đại lý và kiểm soát chi phí. Bước 2: triển khai các máy chủ MCP Tool Trong KAOS cung cấp các công cụ mà các đại lý có thể sử dụng. MCP (Model Context Protocol) Servers KAOS cho phép FastMCP native server với khả năng tạo và triển khai hình ảnh của riêng bạn. KAOS cũng hỗ trợ nhiều thời gian chạy MCP bản địa thông qua một registry. 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 Xác định các công cụ như chức năng inline Python để thử nghiệm kubernetes Các hoạt động của Kubernetes CRUD slack Slack messaging integration custom Hình ảnh container của riêng bạn Đối với bản demo của chúng tôi, chúng tôi sẽ tạo một máy chủ máy tính. Trong sản xuất, bạn sẽ kết nối với các API thực sự, cơ sở dữ liệu hoặc các dịch vụ bên ngoài. Note: In this section we use the for quick testing, however for production-ready deployment use the . python-string runtime custom-image deployment Lưu ý: Trong phần này chúng tôi sử dụng để thử nghiệm nhanh, nhưng để triển khai sẵn sàng sản xuất sử dụng . python-string runtime Custom-image triển khai First we create the mcp, which will have a simple công cụ sẽ thêm hai số và trả về kết quả. 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 Sau đó, chúng tôi tạo ra một mcp, cũng là một công cụ đơn giản nhận được một chuỗi và trả về cùng một giá trị như chuỗi. 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 Và chúng tôi có thể gửi yêu cầu để kiểm tra 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" Từ quan điểm khả năng quan sát, chúng tôi sẽ chỉ ra tầm quan trọng của việc hiểu các cuộc gọi được gửi bởi bất kỳ đại lý nào (hoặc bất kỳ dịch vụ bên ngoài nào) và được xử lý bởi chính các máy chủ MCP. B. Nhân viên nghiên cứu Các Tài nguyên trong KAOS đại diện cho một thực thể AI có thể xử lý yêu cầu, mô hình cuộc gọi, thực hiện các công cụ và giao phó cho các đại lý khác. Agent Hiển thị một điểm cuối tương thích OpenAI /v1/chat/completions Thực hiện vòng tròn đại lý (model > tools > model > ...) Supports configurable memory for session state Nhân viên nghiên cứu sẽ chuyên thu thập thông tin: kaos agent deploy researcher \ --model "openai/gpt-4o" \ --mcp echo-search \ --description "Research specialist" \ --instructions "You research topics and provide ." \ --expose=true \ --wait Đối với khả năng quan sát đơn đại lý, chúng tôi quan tâm đến: Model call latency: Inference mất bao lâu? Thời gian thực hiện công cụ: Công cụ có phản ứng nhanh không? Step count: Agent cần bao nhiêu iterations? 3b: Nhân viên phân tích Nhà phân tích tập trung vào phân tích dữ liệu và tính toán: 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. The Supervisor Agent Cuối cùng, Điều phối viên tổ chức các đại lý khác. Đối với khả năng quan sát đa đại lý, chúng tôi có được các mối quan tâm bổ sung: Mẫu phái đoàn: Những đại lý nào được gọi và thường xuyên như thế nào? Thời gian chậm trễ giữa các đại lý: Bao nhiêu thời gian được dành cho việc giao phó so với xử lý cục bộ? Tương quan theo dõi: Chúng ta có thể thấy toàn bộ luồng yêu cầu trên các đại lý không? 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 Và chúng ta đã xong! You can now go back to the top and run through the observability walkthrough with your deployed setup!