תצפית ייצור עבור AI רב-סוכן (עם KAOS + OTel + SigNoz)

מדריך מעשי להוסיף תצפיות ברמה הייצור למערכות AI מרובות סוכנים באמצעות מערכת תזמורת הסוכנים של K8s באמצעות OpenTelemetry ו-SigNoz אתה בנה סוכן AI שעובד במחשב הנייד שלך.הוא אוטומטית מחברת כלים יחד, מעבירה משימות לסוכנים מיוחדים, ומייצר תוצאות טובות. לאחר מכן, אתה מפעיל אותו לייצור: משתמש אחד מדווח כי בקשה "לקחה לנצח". לדבריו, קיבלו תשובה מוזרה. הכתבה מראה שהסוכן רץ אבל מה קרה בתוך 45 שניות בין בקשה לתגובה? ברוכים הבאים ל The observability challenge of agentic systems. "היומנים המסורתיים אומרים לך שזה עבד, התבוננות אומרת לך למה זה עבד ככה." "היומנים המסורתיים אומרים לך שזה עבד, התבוננות אומרת לך למה זה עבד ככה." במאמר זה, נסתכל על דוגמה מלאה של תצפיות עבור מערכות מרובות סוכנים. להלן תצוגה מקדימה של המערכת המולטי-אגנט שאנחנו ננתח, לפקח על ואבחן בפוסט זה: בואו נתחיל עם השאלה העיקרית של... מדוע מערכות מרובות סוכנים זקוקות לתצפית (שונה)? למיקרו-שירותים המסורתיים יש דפוסי צפייה צפויים: בקשה נכנסת, חלק מהעיבוד מתרחש, תגובה נעלמת. זה לא רק בקשה-תשובה מערכות סוכנות מפרות את ההנחות המסורתיות: 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 בקשה סינכרון תשובות Iterative Rationing Loops - סיבות אורך זמן הצפייה (50-500ms) משתנה: 100ms עד 60+ שניות מסלולי קוד Deterministic החלטות LLM non-deterministic שירות יחיד לפי בקשה שיחות מודל + שיחות כלי + נציגות עלות קבועה לפי בקשה העלות משתנה בהתאם לשימוש בטוקן AI Agents 101: The Agentic Loop קחו בחשבון את מעגל הליבה של מערכת סוכני ה-AI מרובה, זהו הדפוס הפשוט המביך שהוביל לגל החדשנות הנוכחי במערכות ה-AI. להלן זרם סוכן פשוט כמו אנחנו מפספסים הרבה ניואנסים, אבל הרעיון הוא שאנחנו שולחים שיחה ראשונה עבור LLM כדי להגיב עם שיחות כלי או שיחות נציגות, ואם אין אחד או אנחנו פועלים לשלבים מקסימליים, אז אנחנו שולחים את התשובה הסופית. 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) כפי שניתן לראות, כל iteration של מעגל זה עשוי לקחת נתיב שונה. הדו"ח המסורתי (לדוגמה, "הבקשה החלה" ... "הבקשה הושלמה") לא אומר לך כמעט כלום על מה שקרה באמת. ברגע שאנו לוקחים את זה למערכת מפוזרת זה הופך אפילו יותר מסובך כדי להבין מה קורה - כפי שאנו רואים במאמר זה. בסעיף האחרון של הפוסט הזה נראה לך גם כיצד ננגן את המעגל האגנטי הזה באופן ספציפי. אנו מחליפים את 'ביקוש-תגובה' על ידי 'ביקוש-פאניקה-כלי-פאניקה-פניקה-תגובה'. אנו מחליפים את 'ביקוש-תגובה' על ידי 'ביקוש-פאניקה-כלי-פאניקה-פניקה-תגובה'. שלושת עמודי התצפית של הסוכן OpenTelemetry מספק שלושה סוגים של נתוני טלמטריה, שכל אחד מהם משרת מטרה נפרדת עבור מערכות סוכנות. Traces ההיררכיה של עקבות מפות ישירות למה הסוכן עשה, לתפוס ולחבר כל קפיצה לאורך הנסיעה. 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 עונה: "איזה נתיב בקשה זו לקחה דרך הסוכנים שלי?" תשובה: "איזה נתיב בקשה זו לקחה דרך הסוכנים שלי?" Traces Logs באופן מסורתי בתוכנה, יומן מספק תצפית פנימית להתנהגות והתנועה של היישום. אלה מספקים דרך להבין מה קרה במהלך בקשה או פגישה מסוימת, כמו גם לתפוס מידע קריטי כגון יוצאים מן הכלל. ב-OpenTelemetry, גם יומני האינטרנט נלקחים עם השלבים המתאימים, כך שהם יכולים להיות מחוברים בהתאמה. 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 Metrics המדידות מספקות KPIs מבוססי זמן גרניאליים המתפתחים לאורך זמן, וניתן לאסוף ולהדפיס כדי לספר סיפור היסטורי מסוים. <- Store number of tokens per request <- Store success / failure rate of requests <- Store latency for model calls Metrics עונה: "איך המערכת שלי פועלת באופן כללי?" Metrics עונה: "איך המערכת שלי פועלת באופן כללי?" Bringing it all together הקסם מתרחש כאשר שלושת הדברים האלה קשורים (aka מחוברים). זה מאפשר לנו לעשות דברים כמו "לחצו על יומן ה- ERROR הזה ב-Observability Backend" ולבחור את המרחב המדויק במסלול שבו התרחש הכישלון. פרופיל Multi-Agent Context כאשר סוכן א' מייצג את סוכן ב', אשר מייצג את סוכן סי, אתה רוצה עקבות מאוחדות אחת - לא שלוש נפרדות. זה דורש . context propagation זה כרוך בהעברה של מסגרת עקבות באמצעות כותרות HTTP באמצעות הסטנדרט W3C Trace Context. התוצאה היא עקבות מאוחדות בכל הסוכנים - הנה דוגמה שמראה כיצד הקשר של עקבות מתפשט בין הסוכן המשותף, הסוכן המחקר והסוכן האנליסט. 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 ללא התפשטות הקשר, דיבוג multi-agent הוא רק הנחה מפוזרת. ללא התפשטות הקשר, דיבוג multi-agent הוא רק הנחה מפוזרת. מקרים של שימוש מעשי: מערכת מחקר רב-סוכן בואו נתחיל לבנות משהו מעשי. אנחנו נשתמש , מסגרת קוד פתוח לביצוע, ניהול ופיתוח מערכות רב-סוכנים ב- Kubernetes. כאוס (מערכת תזמורת סוכן Kubernetes) כאוס מערכת Multi-Agent Monitor מקרה השימוש שלנו מורכב מאנשי קואורדינטור המייצגים משימות מחקר וניתוח לסוכנים מיוחדים: כל רכיב – סוכנים, כלים ו- APIs מודל – שולח עקבות, מטריקים ושעתונים לאוסף OpenTelemetry, אשר מעביר את כל הדברים ל-Backend הנבחר שלך לצורך ויזואליזציה וניתוח. תגית: Commands & Tools לפני שאתם מתחילים, תזדקקו: קואוס CLI מותקן: pip install kaos-cli==0.2.7 מפתח API LLM (כל ספק כמו OpenAI, Nebius, וכו ') kubectl, קסדה וקבוצת Kubernetes (KIND, minikube, או קבוצת ענן) הפעלת הכאוס ראשית, בואו להתקין את מפעיל KAOS עם OpenTelemetry מופעל ואת תצפית backend.We will use SigNoz as an open-source, OpenTelemetry-native option. (מומלץ על ידי : 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 ברגע שהוא פועל, אנו יכולים ליצור את המערכת שלנו multi-agent באמצעות אחד הדוגמאות המסופקות עם CLI. אתה יכול גם לראות את ה- ANNEX בסוף הפוסט של הבלוג כדי ליישם כל אחד מהמרכיבים אחד אחר אחד. kaos samples deploy \ 3-hierarchical-agents \ --provider openai \ --wait \ --api-secret # This will prompt your api-key secret באפשרותך לראות את דגל ה- provider המפרט את backend, כגון nebius, gemini, bedrock ו-100s של ספקים אחרים [KAOS docs], כמו גם את ה-api-secret שלך אשר יוזמנו באופן אינטראקטיבי. You can see the --provider flag which specifies the backend, such as nebius, gemini, bedrock and 100s of other providers [ , כמו גם -api-סוד שלך אשר יוזמנו באופן אינטראקטיבי. KAOS docs] לאחר ההתקנה, פתח את ה- UI עם הפקודה הבאה. kaos ui --monitoring-enabled זה מאפשר לנו לראות את המערכת multi-agent המופעלת: לשים את הכל ביחד: מעקב אחר הכאוס עכשיו בואו נפיק קצת תנועה ולהתחיל לפקח על הכאוס. אינטראקציה עם סוכנים אתה יכול לתקשר עם סוכנים בכמה דרכים: # 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." להפעיל את הצ'אט באמצעות ממשק המשתמש: מאחורי הקלעים, זה מפעיל שרשרת מורכבת של פעולות: המנהל מקבל את הבקשה המפקח קורא ל-LLM, אשר מחליט להעביר סוכן מחקר מופנה למחקר שוק (ואשר קורא לשני סוכני מחקר) סוכן אנליסט מחשב מניות שוק (ואקרא שני סוכני אנליסט) המפקח סינתזה את התשובה הסופית כל זה נלקח ברמזים שניתן לבדוק: כל שיחת LLM, כל ביצוע כלי, כל נציגות. ראיית עקבות: הבנת זרימת בקשות בניגוד לשירותי בקשה-תגובה מסורתיים, הסוכנים מקבלים החלטות מרובות על בקשה אחת.Traces מאפשרים לך לראות כל נקודה החלטה, כמה זמן זה לקח ואיזה נתיב בחר הסוכן. Why traces matter for agentic systems רשימת השלבים מציגה את כל הבקשות הזורמות דרך הסוכנים שלך.כל רשימת השלבים מייצגת אינטראקציה שלמה עם המשתמש. לחץ על מסלול כדי לראות את זרימת הבקשה המלאה: רמז יחיד המראה את הקואורדינטור המשלח לחוקר ולסוכני האנליסטים, וכל רמז מייצג פעולה נפרדת. This trace visualization answers questions that would otherwise require hours of log spelunking: למה דרישה זו נמשכה 15 שניות?הכלי web_search לקח 8 שניות. אילו סוכנים היו מעורבים?Coordinator → Researcher → Analyst → Coordinator. כמה שיחות LLM נעשו? 6 שיחות בין שלוש הסוכנים. כל הכלים הושלמו בהצלחה (חלקים ירוקים). Log Correlation: הבנה של סוכן סיבה עקבות לספר לך תגית: logs tell you OpenTelemetry מתאימה אותם באופן אוטומטי באמצעות ו של תכונות מה למה trace_id span_id כל רשום יומן כולל מזהים אלה, המאפשר לך: Click on a span in your trace View all logs emitted during that span להבין את ההגיון של הסוכן בכל שלב ניתן לראות את התצוגה של היומנים עצמם כמו גם פרטים נוספים. לאחר מכן נוכל לטפס עמוק יותר לתוך כניסות יומן בודדות. לדוגמה, כאן ניתן לראות את הקובץ המשימה של המועצה: » זה מראה לנו את כל הדו"ח שהועבר, וזה די שימושי עבור אבחון ודיבוג. זה כולל full log context including all attributes, resource labels, and the complete message. 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." או ישירות דרך ה- UI: אם נגיע כעת לכרטיסיה יוצאים מן הכלל, נוכל לראות כי קיים רשומה.זוהי תצוגת רשימת יוצאים מן הכלל, שבה מופיעים כל יוצאים מן הכלל עבור התקופה. 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. ואנחנו יכולים גם להציג את השגיאה בתצוגת עקבות. Metrics: Operational Overview בעוד עקבות מציגות בקשות בודדות, מדדים מציגים מגמות לאורך זמן. 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 בקשה למספר סוכנים kaos.request.duration Latency distribution (P50, P95, P99) kaos.model.calls LLM API שימוש (אינדיקטור עלויות) kaos.tool.calls תדירות ביצועים של כלי kaos.delegations דפוסים קואורדינליים של סוכנים רבים מדדים אלה מאפשרים אזהרה על בעיות הייצור: Request latency > 30s Error rate > 5% Model call failures > 1% We can also visualise them: Under the Hood: How It Works עכשיו שכבר ראיתם את התצפית בפעולה, בואו ננסה להבין כיצד היא מתבצעת.האתגרים כאן אינם ברורים עד שאתם מתחילים לבנות – והפתרונות יחולו באופן נרחב על כל מערכת סוכנת. האדריכלות KAOS מפריד את לוח הבקרה (Go) משטח הנתונים (Python); בתוך היישום Python יש לנו מנהל OpenTelemetry (KaosOtelManager) כדי לספק כלי שימושיים כדי לפשט את זרימי העבודה. התובנה העיקרית: הגדרת הטלמטיקה זורמת מ- Operator -> Data Plane -> OTEL Collector. Users configure telemetry once in values.yaml, and the operator propagates it to all components. התובנה העיקרית: הגדרת הטלמטיקה זורמת מ- Operator -> Data Plane -> OTEL Collector. Users configure telemetry once in values.yaml, and the operator propagates it to all components. להבין את ההיגיון הבסיסי כשמדובר במערכות סוכנות, זה לא רק על מכשיר בקשה-תגובה, אבל זה גם על קלטת זרימת דרך iterations הסוכנים. כדי להתחיל, עלינו לוודא שאנחנו קובעים את המרחב הכללי בכל בקשת/תגובה ברמה העליונה.אחר כך עלינו גם להפעיל רכיבים מרכזיים אחרים כגון סרגל הסוכנים (דוגמה להלן), כמו גם שיחות נוספות כגון שיחות MCP, ומשלוחים של סוכנים. # 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 We can now use the same pattern in the agentic loop, where we can capture the iterations with the respective context. This will be important as we can also capture the correlated logs and metrics that are connected to this particular request. # 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... יש את המרחקים המוגדרים במקומם הוא מה שמאפשר לנו לעקוב אחר הבקשה בין קפיצות. Some useful patterns to note: : There is a parent span for the loop, child spans for each step, grandchild spans for operations, etc. Hierarchical spans Log before span close: יומנים נמסרים בזמן שמקשר המעקב פעיל, מה שמאפשר הקשר בין היומנים ניהול טווח מפורש: אנו משתמשים בתבנית ניסיון/סוף מפורשת כדי להבטיח כי טווחים תמיד סגורים, אך אנו יכולים גם להשתמש במנהל הקשר (כלומר, עם סעיף) זה גם מה שמאפשר לנו לאחר מכן להציג את ההפרדה של עקבות הבקשה ומרחבים. Context Propagation for Multi-Agent Systems כאשר אנו מעבירים סוכנויות משנה (שנוהלות במערכות נפרדות), עלינו להפיץ את הקשר של עקבות: # 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"] עקבו אחרי context context context context context אנחנו גם צריכים לוודא שהקשר מתקבל ומוטבע. # 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 כדי לקשר log-trace, אנו מחברים את Logging של Python ל- 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. מכשיר ה- Logging Instruments זריקה אוטומטית ו רשומות יומן כאשר יש קונצרט span פעיל. trace_id span_id כדי להגדיר חיבור זה, אתה יכול להגדיר אותו עם כמה שורות כפי שמתואר להלן. 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 אנו גם יכולים לעקוב אחר מדדים באמצעות OpenTelemetry SDK. אם השתמשת בעבר ב-Prometheus, המטריקים במקרה זה אינם נחשפים דרך נקודת קצה שתתבקש באמצעות אוסף prometheus.במקום זאת, זה גם מאפשר ארכיטקטורה דחופה שבה היא נשלחת לאוסף OTEL באמצעות חיבור ה- GRPC OLTP לאוסף OTel. בעת בחירת מדדים, אנו שואפים לעקוב אחר מדדים עם תוויות קרדינליות נמוכות כדי למנוע פיצוצים של קרדינליות, כפי שמתואר בדוגמה להלן. 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}) הימנע תוויות בעלות קריטריוניות גבוהה: לעולם אל תשתמש ב- Session IDs, User IDs, Prompt Content, או ערכים אחרים ללא גבולות כסימנים מטריים. הימנע תוויות בעלות קריטריוניות גבוהה: לעולם אל תשתמש ב- Session IDs, User IDs, Prompt Content, או ערכים אחרים ללא גבולות כסימנים מטריים. טיפים לIceberg This is a gentle introduction to observability in multi-agent systems, and provides a high level view of what are some of the main components involved. זה גם צריך לספק לך מספיק אינטואיציה כדי להפעיל את מערכות הסוכנים שלך בתודעה, עם זאת, תצטרך לזהות אילו דפוסים עובדים הכי טוב בהקשרים הספציפיים שלך. Instrumenting agentic AI systems with OpenTelemetry requires understanding the unique challenges these systems present: need span hierarchies that map to logical operations Iterative loops הפצה מרובה סוכנים דורשת הפצה מפורשת של הקשר באמצעות W3C Trace Context היתרונות של ביצוע כלים משטחים ייעודיים עם כינוי ברור requires emitting logs before span close Log-trace correlation מטריקים צריכים תוויות קלוריות נמוכות כדי למנוע פיצוצים אחסון הדפוסים שאנו מכסים חלים על כל מערכת סוכנים, לא רק על KAOS. הסוכנים של מחר יהיו נפוצים כמו מיקרו-שירותים היום, ו-OpenTelemetry נותן לך את הנראות לפעול בהם בביטחון. The agents of tomorrow will be as ubiquitous as microservices are today, and OpenTelemetry gives you the visibility to operate them with confidence. משאבים KAOS Framework: github.com/axsaucedo/kaos - מסגרת קוד פתוח המשמשת במאמר זה תיעוד KAOS: axsaucedo.github.io/kaos - תיעוד CLI מלא ו- CRD OpenTelemetry Python: opentelemetry.io/docs/languages/python - מסמך ה-Python SDK הרשמי OpenTelemetry GenAI Conventions: github.com/open-telemetry/semantic-conventions - סטנדרטים מתפתחים עבור תצפית AI SigNoz: signoz.io - APM קוד פתוח עם תמיכה מקורית OpenTelemetry תגית: Multi-Agent System בסעיף זה אנו יוצרים את רכיבי המערכת האגנטית באופן ידני במקום להשתמש בציוד למעניינים! אנו נראה לך כיצד אתה יכול לעשות זאת עם CLI אבל אתה יכול לעשות זאת גם עם UI כמו גם עם directly. kubectl שלב 1: אנחנו קודם כל להתחבר LLMs עם ModelAPI The משאב ב KAOS מספק ממשק משותף עבור גישה LLM. הוא תומך בשני מצבים: ModelAPI מצב פרוקי: מסלול בקשות דרך LiteLLM לספקים חיצוניים (OpenAI, Anthropic, Nebius, וכו ') מצב המארח: דוחף מודלים לקולסטר שלך (באמצעות מכונית צדדית) ומפעיל אותו בשרת כדי להסיק The ModelAPI can be deployed easily via CLI. שים לב כי על מנת שסוכנינו יוכלו להשתמש במודל APIs, עלינו לספק את מפתח ה-API שלנו עבור אימות.לדוגמה זו נשתמש ב- Nebius, שכן הוא קל להגדיר, אבל אתה יכול גם להגדיר OpenAI, Gemini ועשרות אחרים. שים לב כי על מנת שסוכנינו יוכלו להשתמש במודל APIs, עלינו לספק את מפתח API האותנטיקה שלנו. כמו זה קל להגדיר, אבל אתה יכול גם להגדיר OpenAI, Gemini ועשרות אחרים. השמים kaos modelapi deploy llm-proxy \ --namespace kaos-hierarchy \ --provider nebius \ --api-key # When provided without value this prompts the key securely מנקודת מבט של תצפית, ModelAPI נותן לנו נוכחות במודל שיחה מאוחרת, שימוש טוקן ושיעורי שגיאה - מדדים קריטיים להבנת ביצועים של סוכנים ולשלוט על עלויות. שלב 2: הפעל את MCP Tool Servers in KAOS provide tools that agents can use. MCP (Model Context Protocol) Servers KAOS enables FastMCP native servers with ability to create and deploy your own images. KAOS תומך גם במספר זמני ביצוע מקוריים של MCP באמצעות רישום. 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 הגדרת כלים כפונקציות Python מקוונות לניסוי kubernetes מבצעי Kubernetes CRUD slack שילוב של Slack Messaging custom תמונת המכולת שלך עבור הדומיין שלנו, אנו יוצרים שרת מחשב.בפיתוח, אתה תהיה מחובר ל- API אמיתי, מסדי נתונים או שירותים חיצוניים. הערה: בסעיף זה אנו משתמשים ב- python-string runtime לביצוע בדיקות מהירות, אך עבור הפצה מוכנה לייצור, השתמשו ב- custom-image deployment. הערה: בסעיף זה אנו משתמשים ב- python-string runtime לביצוע בדיקות מהירות, אך עבור הפצה מוכנה לייצור, השתמשו ב- custom-image deployment. קודם כל אנחנו יוצרים את MCP, אשר יהיה פשוט מכשיר שמוסיף שני מספרים ומחזיר את התוצאה. 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 לאחר מכן יצרנו mcp, שהוא גם כלי פשוט שמקבל שורה ומחזיר את אותה ערך כמו השורה. 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 ואנחנו יכולים לשלוח בקשה לבדיקת 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" מנקודת המבט של התבוננות, נציג כיצד חשוב להבין את השיחות שנשלחות על ידי כל סוכן (או כל שירות חיצוני) ומעובדות על ידי שרתי ה- MCP עצמם. א) סוכן המחקר The משאב ב- KAOS מייצג ישות AI שיכולה לעבד בקשות, להתקשר למודלים, להפעיל כלים ולפנות לסוכנים אחרים. Agent מציג נקודת קצה OpenAI-compatible /v1/chat/completions הפעל את המעגל האגנטי (מודל > כלים > מודל > ...) תמיכה בזיכרון שניתן להגדיר עבור מצב הפגישה סוכן המחקר יהיה מתמחה באיסוף מידע: kaos agent deploy researcher \ --model "openai/gpt-4o" \ --mcp echo-search \ --description "Research specialist" \ --instructions "You research topics and provide ." \ --expose=true \ --wait עבור תצפית סוכן יחיד, אנו דואגים: דגם שיחה מאוחרת: כמה זמן לוקח להסיק? זמן ביצוע כלי: האם הכלים מגיבים במהירות? מספר צעדים: כמה iterations צריך הסוכן? 3B: סוכן האנליסט סוכן האנליסט מתמקד בניתוח נתונים וחישובים: 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: סוכן המפקח לבסוף, הקואורדינטור מתארגן את הסוכנים האחרים.על מנת להבטיח תצפית מרובה סוכנים, אנו מקבלים דאגות נוספות: דפוסים של נציגות: אילו סוכנים מתקשרים וכמה פעמים? עיכוב בין סוכנים: כמה זמן מנוהל בהעברה לעומת עיבוד מקומי? קשרי עקבות: האם אנו יכולים לראות את זרימת הבקשות המלאה בין סוכנים? 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 And we’re done! עכשיו אתה יכול לחזור לחלק העליון ולרוץ דרך התצפית עם ההתקנה המופעלת שלך!