Handbuch — NCP-AAI NVIDIA-Certified Professional: Agentic AI

Die Wahl zwischen einem einzelnen Agenten und einem Multi-Agenten-System für einen komplexen Workflow.

→Standardmäßig einen einzelnen Agenten mit Tools verwenden. Nur dann in mehrere Agenten aufteilen, wenn Aufgaben klar voneinander abgegrenzt sind, der Kontext überläuft oder unterschiedliche Modellebenen für verschiedene Unteraufgaben geeignet sind.

Warum: Jeder hinzugefügte Agent vervielfacht Latenz, Fehleranfälligkeit und Orchestrierungskosten; die meisten Workloads sind mit einem gut ausgestatteten Agenten erfolgreich.

Der Orchestrator muss heterogene Unteraufgaben an Spezialisten verteilen.

→Einen Supervisor-Agenten verwenden, der das Ziel zerlegt, an Worker-Agenten mit eigenen Prompts und Tools weiterleitet und die Ergebnisse aggregiert.

Warum: Zentrale Kontrolle hält den Zustand kohärent und macht die Entscheidungsgrenze prüfbar, im Gegensatz zu einem unkontrollierten Schwarm.

Der Agenten-Flow hat bedingte Verzweigungen, Schleifen und parallele Fan-Outs.

→Den Workflow als expliziten Graphen von Knoten und Kanten modellieren, anstatt als freie Schleife, damit der Kontrollfluss deterministisch und fortsetzbar ist.

Warum: Ein Graph macht Verzweigungen testbar und ermöglicht es, nach einem Fehler einen Checkpoint zu setzen und von jedem Knotenpunkt aus neu zu starten.

Eingehende Anfragen variieren stark in Typ und Kosten.

→Das System mit einem leichtgewichtigen Router-Agenten vorschalten, der die Absicht klassifiziert und an den günstigsten, fähigen nachgeschalteten Agenten oder Tool weiterleitet.

Warum: Routing vermeidet die Kosten eines frontier-model für triviale Anfragen und isoliert Verantwortlichkeiten pro Pfad.

Mehrere Agenten müssen einen gemeinsamen Workflow-Zustand lesen und schreiben.

→Den Zustand in einen gemeinsamen Speicher (Key-Value oder Dokument) auslagern, der nach Session-ID organisiert ist, anstatt das vollständige Transkript zwischen Agenten zu übergeben.

Warum: Ein gemeinsamer Speicher begrenzt das Kontextwachstum und verhindert divergierende Zustands-Kopien über Agenten hinweg.

Agenten für horizontale Skalierung entwerfen.

→Die Agentenberechnung zustandslos halten; Konversation und Gedächtnis extern persistieren, damit jede Replika jede Anfrage aufnehmen kann.

Warum: Zustandslose Knoten skalieren sauber und überleben Pod-Neustarts, ohne laufende Arbeiten zu verlieren.

Ein Sub-Agent oder Tool fällt mitten im Workflow aus.

→Idempotente Schritte mit Wiederholung/Backoff, kompensierenden Aktionen für Nebeneffekte und einem Fallback-Pfad oder einer menschlichen Eskalation entwerfen, wenn Wiederholungsversuche erschöpft sind.

Warum: Agentensysteme versagen teilweise; die Wiederherstellung muss ein primäres Designanliegen sein, keine nachträgliche Überlegung.

Sub-Agenten werden von separaten Teams entwickelt.

→Den Eingabe-/Ausgabekontrakt jedes Agenten als typisiertes Schema definieren und Agenten als Dienste hinter stabilen Schnittstellen behandeln.

Warum: Explizite Kontrakte ermöglichen es Agenten, sich unabhängig zu entwickeln und isoliert getestet zu werden.

Die Ausgabequalität des Agenten ist bei schwierigen Aufgaben inkonsistent.

→Einen Kritiker-/Reflexionsschritt hinzufügen, der den Entwurf anhand von Kriterien überprüft und einen begrenzten Wiederholungsversuch auslöst, bevor er zurückgegeben wird.

Warum: Selbstkritik fängt Fehler kostengünstig ab, aber die Iterationen begrenzen, um unkontrollierte Schleifen und Kosten zu vermeiden.

Der Agent muss mit externen APIs, Datenbanken oder Dateien interagieren.

→Fähigkeiten als typisierte Funktions-/Tool-Definitionen bereitstellen; das Modell gibt einen Tool-Aufruf aus, Ihr Code führt ihn aus und gibt das Ergebnis zurück, dann wird die Schleife fortgesetzt.

Warum: Strukturierte Tool-Aufrufe sind zuverlässiger und prüfbarer als das Parsen von Freitextanweisungen.

Der Agent muss über Beobachtungen nachdenken, bevor er erneut handelt.

→Eine ReAct-Schleife implementieren: Das Modell erzeugt einen Gedanken, wählt ein Tool, empfängt die Beobachtung und wiederholt dies, bis eine Stoppbedingung erfüllt ist.

Warum: Das Ineinandergreifen von Überlegung und Aktion legt die Kette zur Fehlerbehebung offen und verbessert die Genauigkeit bei mehrstufigen Aufgaben.

Das Modell missbraucht oder halluziniert Tool-Argumente.

→Präzise Tool-Beschreibungen verfassen, Argumenttypen und Enums einschränken und ein oder zwei Anwendungsbeispiele pro Tool bereitstellen.

Warum: Die meisten Tool-Aufruf-Fehler gehen auf vage Schemas zurück; die Beschreibung ist der Prompt für das Tool.

Nachgeschalteter Code benötigt zuverlässiges JSON vom Agenten.

→Die Generierung auf ein JSON-Schema (strukturierte Ausgabe) beschränken, anstatt Freitext zu parsen, und vor der Verwendung validieren.

Warum: Die schema-beschränkte Dekodierung eliminiert anfälliges Regex-Parsing und schleichende Formatänderungen.

Einen Produktionsagenten auf dem NVIDIA Stack erstellen.

→Das NeMo Agent Toolkit verwenden, um Agenten, Tools und Workflows zu komponieren und Modellaufrufe mit NIM-bereitgestellten Backends zu verbinden.

Warum: Das Toolkit standardisiert die Agenten-Infrastruktur und integriert sich nativ in die NVIDIA Bereitstellung.

Referenz↗

Ein Tool gibt einen Fehler zurück oder überschreitet die Zeit.

→Den Fehler als Tool-Ergebnis an das Modell zurückgeben, damit es den Vorgang wiederholen, Argumente anpassen oder einen alternativen Pfad wählen kann.

Warum: Das Offenlegen von Fehlern für den Agenten ermöglicht die Wiederherstellung; ihr Verschlucken macht den Agenten blind.

Mehrere unabhängige Tool-Aufrufe sind in einem Schritt erforderlich.

→Tool-Aufrufe parallel ausführen, wenn das Modell dies unterstützt und die Aufrufe keine Reihenfolgeabhängigkeit haben, und dann die Ergebnisse zusammenführen.

Warum: Parallele Ausführung reduziert die Echtzeit-Latenz für Fan-Out-Arbeiten wie Multi-Source-Lookups.

Eine spezialisierte Fähigkeit sollte workflowübergreifend wiederverwendbar sein.

→Einen Sub-Agenten hinter einer einzigen Tool-Schnittstelle verpacken, sodass das übergeordnete Element ihn wie jedes andere Tool aufrufen kann.

Warum: Die Behandlung von Sub-Agenten als Tools hält die Komposition einheitlich und verbirgt die interne Komplexität.

Der Agent weicht von der Aufgabe ab oder ignoriert Einschränkungen.

→Rolle, erlaubte Tools, Ausgabeformat und harte Einschränkungen in einem prägnanten System-Prompt festlegen; kritische Regeln am Ende wiederholen.

Warum: Ein prägnanter System-Prompt ist die kostengünstigste und wirkungsvollste Kontrolle über das Agentenverhalten.

Messen, ob ein Agent eine mehrstufige Aufgabe korrekt gelöst hat.

→Sowohl die endgültige Antwort als auch die Trajektorie – Tool-Aufruf-Genauigkeit, Schrittreihenfolge und unnötige Aktionen – anhand eines gelabelten Datensatzes evaluieren.

Warum: Eine korrekte Antwort aus einer fehlerhaften Trajektorie ist fragil; die Trajektorienbewertung fängt latente Fehler ab.

Für offene Agenten-Ausgaben existieren keine Ground-Truth-Labels.

→Ein LLM als Judge mit einer Rubrik verwenden, um Ausgaben zu bewerten, kalibriert anhand einer kleinen, von Menschen gelabelten Stichprobe.

Warum: Judge-Modelle skalieren die Evaluierung, müssen aber kalibriert werden, da sie sonst ihre eigene Voreingenommenheit kodieren.

Sie müssen Regressionen vor jeder Veröffentlichung abfangen.

→Eine Offline-Evaluierungs-Harness mit einer festen Szenario-Suite erstellen, die bei jeder Änderung läuft und Bereitstellungen bei Erreichen eines Schwellenwerts freigibt.

Warum: Das Agentenverhalten ändert sich subtil mit Prompt- oder Modelländerungen; eine Regressionstestsuite ist das Sicherheitsnetz.

Der Agent wählt das falsche Tool oder falsche Argumente.

→Die Präzision/Recall der Tool-Auswahl und die Gültigkeit der Argumente als eigenständige Metriken verfolgen, nicht nur den Erfolg der Endaufgabe.

Warum: Die Isolierung der Tool-Aufruf-Schicht zeigt genau, ob Fehler von der Auswahl oder vom Schema herrühren.

Die Erfolgsquote der Evaluierung ist nach einer Änderung gesunken.

→Die vollständigen Trajektorien der Fehlerfälle untersuchen, Fehlermodi clustern und zuerst den dominanten Cluster beheben.

Warum: Aggregierte Scores verbergen die Grundursache; Per-Trace-Clustering deckt den tatsächlichen Defekt auf.

Der Agent erbringt unzureichende Leistung und Sie müssen ihn verbessern.

→Zuerst Prompts und Tool-Beschreibungen iterieren; erst dann auf ein größeres Modell oder Fine-Tuning eskalieren, wenn Prompt-Änderungen keine Verbesserung mehr bringen.

Warum: Prompt-Iteration ist schnell und günstig; Modellwechsel erhöhen die Kosten und sollten evidenzbasiert sein.

Zwei Agenten-Designs vergleichen, die beide die Genauigkeitsziele erreichen.

→Kosten pro Aufgabe und p95-Latenz zur Evaluierung hinzufügen, damit das günstigere, schnellere Design bei Gleichstand gewinnt.

Warum: Produktionsfähigkeit ist Genauigkeit plus Kosten plus Latenz, nicht nur Genauigkeit.

Modellinferenz für Agenten in der Produktion bereitstellen.

→Modelle als NIM-Microservices bereitstellen, um Agenten einen standardisierten, GPU-beschleunigten Inferenz-Endpunkt mit integriertem Batching zu bieten.

Warum: NIM paketiert optimierte Inferenz hinter einer stabilen API, sodass Agenten die Serving-Interna nicht verwalten müssen.

Referenz↗

Der Agentenverkehr ist sprunghaft und unvorhersehbar.

→Agenten und Serving containerisieren, auf Kubernetes ausführen und bei Gleichzeitigkeit oder GPU-Auslastung mit vernünftigen Min/Max-Grenzen automatisch skalieren.

Warum: Autoscaling absorbiert Spitzen, während minimale Repliken die Kaltstart-Latenz auf dem kritischen Pfad vermeiden.

Die GPU-Inferenzkosten sind unter Last zu hoch.

→Dynamisches/kontinuierliches Batching auf der NIM-Ebene aktivieren, um die Token pro GPU-Sekunde zu erhöhen, bevor Hardware hinzugefügt wird.

Warum: Batching verbessert die GPU-Auslastung dramatisch; das Skalieren von Knoten zuerst verschwendet Kapazität.

Agenten starten unbegrenzte parallele Tool- und Modellaufrufe.

→Pro-Agent- und globale Gleichzeitigkeitslimits mit einer Warteschlange anwenden, damit das System unter Last kontrolliert abbaut.

Warum: Unbegrenzter Fan-Out erschöpft GPU- und Downstream-Kontingente, was zu Kaskaden von Fehlern führt.

Auswahl der GPU-Hardware für einen Agenten-Inferenz-Workload.

→Größe an den Modell-Footprint und die Latenzziele anpassen – H100 für etablierte große Modelle, Blackwell, wo Speicherbandbreite und Reasoning-Durchsatz dominieren.

Warum: Die Anpassung der Hardware an das Modell vermeidet sowohl Unterprovisionierung als auch das Bezahlen ungenutzter Kapazität.

Eine neue Agenten- oder Modellversion sicher ausliefern.

→Per Canary-Deployment auf einen kleinen Verkehrsanteil ausrollen, Live-Metriken mit der Baseline vergleichen und dann fortfahren oder zurückrollen.

Warum: Agentenverhaltensänderungen sind offline schwer vollständig vorhersehbar; Canary begrenzt den Ausfallradius.

Lange Agentenketten bergen das Risiko hängender Anfragen.

→Pro-Schritt- und End-to-End-Timeout-Budgets festlegen; bei Überschreitung abbrechen und auf Fallback zurückgreifen.

Warum: Ohne Budgets kann ein einzelnes langsames Tool einen GPU-Slot blockieren und andere Anfragen aushungern.

Die Aufgabe erfordert viele voneinander abhängige Schritte.

→Ein Plan-and-Execute-Muster verwenden: Zuerst einen expliziten Plan generieren, dann die Schritte ausführen und neu planen, wenn eine Annahme fehlschlägt.

Warum: Vorausschauende Planung reduziert zielloses Verhalten und bietet einen Checkpoint zur Validierung, bevor Tool-Aufrufe getätigt werden.

Die Qualität der Zerlegung ist der Engpass.

→Den Planungsschritt an ein Nemotron Reasoning-Modell leiten, während für die Ausführung günstigere Modelle verwendet werden.

Warum: Rechenleistung für Reasoning dort einsetzen, wo sie zählt – den Plan – nicht bei jedem Routine-Teilschritt.

Der Agent muss sich Fakten über eine lange Session hinweg merken.

→Jüngste Interaktionen im Arbeitskontext behalten; dauerhafte Fakten in einem Langzeitspeicher persistieren, der bei Bedarf abgerufen wird.

Warum: Alles in den Kontext zu stopfen, erhöht Kosten und Latenz und überfüllt schließlich das Fenster.

Wahl der Speichermethode für das Agenten-Gedächtnis.

→Episodische Interaktionshistorie separat von semantischen Fakten speichern; semantisches Gedächtnis nach Ähnlichkeit abrufen, episodisches nach Aktualität/Session.

Warum: Verschiedene Zugriffsmuster erfordern unterschiedliche Speicher; ein einziger Behälter ruft für beides schlecht ab.

Eine lang andauernde Konversation nähert sich der Kontextgrenze.

→Ältere Gesprächsrunden zu einer kompakten laufenden Zusammenfassung zusammenfassen und die Rohhistorie verwerfen, nur die jüngsten wörtlichen Runden behalten.

Warum: Rollierende Zusammenfassung bewahrt die Kontinuität, begrenzt gleichzeitig die Token-Kosten und vermeidet Trunkierungsfehler.

Der Agent muss Antworten auf privaten Unternehmensdaten basieren.

→Dem Agenten ein Retrieval-Tool über einen Vektor-Store geben, damit er entscheidet, wann und was abgerufen werden soll, anstatt immer Kontext voranzustellen.

Warum: Agentenbasiertes Retrieval ruft nur bei Bedarf ab, wodurch Token und irrelevanter Kontext reduziert werden.

Eine hochwertige Retrieval-Pipeline auf NVIDIA aufbauen.

→NeMo Retriever Embedding- und Reranking-NIM-Microservices für beschleunigtes RAG in Produktionsqualität verwenden.

Warum: NeMo Retriever bietet optimierte Embedding-/Rerank-Modelle, die effizient auf der GPU bereitgestellt werden.

Referenz↗

Reine Vektor-Suche verfehlt exakte Übereinstimmungen und Keyword-Abfragen.

→Dichte Vektorsuche mit spärlicher/Keyword-Retrieval kombinieren und die zusammengeführten Kandidaten neu bewerten.

Warum: Hybrid-Retrieval stellt präzise Begriffe (IDs, Codes) wieder her, die Embeddings verwischen.

Abgerufene Chunks sind zu grob oder zu fragmentiert.

→Chunks an semantischen Grenzen mit geringer Überlappung erstellen und Metadaten anhängen; Größe an das Embedding-Modell und den Abfragetyp anpassen.

Warum: Die Chunk-Granularität beeinflusst direkt die Retrieval-Relevanz; beide Extreme verschlechtern das Grounding.

Der Agent liefert veraltete Informationen aus dem Index.

→Inkrementelle Neuindexierung bei Quelländerungen pipelinen und Dokumente mit Zeitstempeln versehen für eine aktualitätsbewusste Rangfolge.

Warum: Ohne Aktualitätsbehandlung stützt RAG Antworten selbstbewusst auf veraltete Daten.

Auswahl eines Modell-Backends für das Agenten-Reasoning.

→Ein Nemotron-Modell wählen, das auf die Reasoning-Last zugeschnitten ist, und es über NIM für einen standardisierten Endpunkt bereitstellen.

Warum: Nemotron Reasoning-Varianten sind für die agentenbasierte Planung und Tool-Nutzung optimiert; NIM standardisiert die Bereitstellung.

Referenz↗

Eine agentenbasierte Anforderung der richtigen NVIDIA Komponente zuordnen.

→NeMo Agent Toolkit für Orchestrierung, NIM für Serving, NeMo Retriever für RAG, NeMo Guardrails für Sicherheit und Nemotron für Reasoning verwenden.

Warum: Zu wissen, welche Komponente für welches Anliegen zuständig ist, ist eine wiederkehrende Prüfungs- und Designentscheidung.

Eine End-to-End-Agenten-Anwendung auf NVIDIA zusammenstellen.

→Diskrete NIM-Microservices (LLM, Embedding, Rerank, Guardrails) hinter der Agenten-Schicht komponieren und jeden unabhängig skalieren.

Warum: Die Microservice-Zerlegung ermöglicht es jeder Fähigkeit, eigenständig zu skalieren und zu versionieren.

Datenspeicherungsregeln verbieten das Senden von Daten an externe APIs.

→NIM-Microservices auf eigener GPU-Infrastruktur selbst hosten, damit Modelle und Daten innerhalb der Grenze bleiben.

Warum: NIM's portable Paketierung unterstützt On-Premise-Bereitstellung, die den Residenzanforderungen entspricht.

Ein Produktionsagent verhält sich fehlerhaft und Sie müssen ihn diagnostizieren.

→Verteilte Traces emittieren, die jeden Modellaufruf, Tool-Aufruf und jede Entscheidung erfassen, und dann die fehlerhafte Trajektorie Ende-zu-Ende inspizieren.

Warum: Agentenfehler sind mehrstufig; ohne vollständige Traces kann man nicht feststellen, wo das Reasoning fehlgeschlagen ist.

Der Token-Verbrauch und die Latenz des Agenten steigen mit der Zeit an.

→Token, Kosten und p95-Latenz pro Agent und pro Tool verfolgen, mit Warnungen bei Schwellenwertüberschreitungen.

Warum: Kosten und Latenz driften unbemerkt, während Prompts und Traffic sich entwickeln; Metriken fangen dies frühzeitig ab.

Die Qualität verschlechtert sich allmählich ohne Code-Änderungen.

→Die Eval-Suite kontinuierlich gegen Produktionsproben ausführen und bei Metrik-Drift von der Baseline alarmieren.

Warum: Daten- und Upstream-Modell-Drift untergraben die Qualität zwischen den Releases unsichtbar.

Der Agent muss beim Thema bleiben und unsichere Anfragen ablehnen.

→NeMo Guardrails mit Eingabe-, Ausgabe-, thematischen und Dialog-Rails um den Agenten anwenden.

Warum: Programmierbare Rails setzen Richtlinien unabhängig vom und als Rückhalt für das eigene Verhalten des Modells durch.

Referenz↗

Nicht vertrauenswürdiger Inhalt könnte den Agenten über abgerufene oder Tool-Daten kapern.

→Alle externen Inhalte als nicht vertrauenswürdig behandeln, sie von Anweisungen isolieren und die Tool-Autorität einschränken, damit eingeschleuste Befehle nicht eskalieren können.

Warum: Injection nutzt die Macht des Agenten aus; die Verteidigung ist das Prinzip der geringsten Rechte plus Trennung von Anweisungen und Daten.

Der Agent verarbeitet regulierte oder persönliche Daten.

→PII vor Modellaufrufen redigieren oder tokenisieren und manipulationssichere Audit-Logs der Agentenaktionen und Tool-Aufrufe schreiben.

Warum: Compliance erfordert sowohl die Minimierung der Exposition als auch den Nachweis, was der Agent getan hat.

Der Agent kann risikoreiche Aktionen wie Zahlungen oder Löschungen durchführen.

→Eine menschliche Genehmigungsschranke vor irreversiblen oder folgenreichen Tool-Aufrufen einfügen, die den Workflow pausiert, bis die Bestätigung erfolgt ist.

Warum: Autonomie ist für reversible Schritte in Ordnung; folgenreiche Aktionen erfordern einen Menschen in der Schleife.

Der Agent ist unsicher oder scheitert wiederholt an einer Aufgabe.

→Einen Konfidenz-/Fehlerschwellenwert definieren, der zu einem Menschen mit vollständigem Kontext eskaliert, anstatt zu raten.

Warum: Eine elegante Übergabe ist besser als eine selbstbewusst falsche Antwort bei Aufgaben mit hohen Einsätzen.

Interessenten misstrauen den Ausgaben des Agenten.

→Die Reasoning-Zusammenfassung des Agenten, verwendete Quellen und Tools offenlegen, damit Menschen Entscheidungen überprüfen und überschreiben können.

Warum: Erklärbarkeit schafft Vertrauen und ist oft für Aufsicht und Audit erforderlich.