Hinweis des Autors: Am Referenzbeispiel der SMT-Linie von NVIDIA FOX zeigen wir, wie Management-Agenten, spezialisierte Agenten und manuelle Prüfpunkte abgegrenzt werden, wenn Multi-Agenten-Systeme in der Produktion zum Einsatz kommen.
Wenn an einer AOI-Station eine Leiterplatte einen Alarm auslöst, muss das Team Prüfbilder sichten, Produktionsaufzeichnungen durchsehen, Reparaturen einplanen und zusätzlich klären, ob die Ofentemperatur anomal ist. Die Belege sind über mehrere Systeme verteilt; wirklich zeitaufwendig ist oft die Koordination. Am 4. November 2026 stellte NVIDIA das Factory Operations Blueprint (kurz FOX) öffentlich vor und beschrieb eine Referenzarchitektur aus Management-Agent + spezialisierter Agent + manueller Prüfpunkt.
Dies ist kein weiterer Einführungsartikel zu Multi-Agenten-Konzepten. Dieser Artikel stützt sich auf das offiziell veröffentlichte Beispiel einer SMT-Linie (Surface Mount Technology) und bereitet die beschriebene Arbeitsteilung zu umsetzbaren Schritten für die Einführung auf. Die Methoden zur Prüfentscheidung und das Rollout-Tempo in diesem Artikel sind unsere praktischen Empfehlungen und werden getrennt von den offiziellen FOX-Funktionen erläutert.
Der zentrale Nutzen: Nach der Lektüre wissen Sie, wie Sie Agenten entlang ihrer Verantwortungsgrenzen aufteilen, manuelle Prüfpunkte nach Risikostufe festlegen und einen Einführungsplan vom Shadow-Betrieb bis zur kontrollierten Ausführung erstellen.
Zentrale Punkte für den Einsatz von Multi-Agenten in der Produktionsumgebung
Der Schlüssel zur Aufteilung von Multi-Agenten liegt darin, zuerst klar festzulegen, wer die Koordination übernimmt, wer die fachliche Beurteilung vornimmt und wer die endgültige Verantwortung trägt. Die folgende Tabelle zeigt die grundlegende Aufgabenteilung der drei Rollen; die späteren Schritte bauen darauf auf.
| Rolle | Hauptaufgaben | Aufgaben, die nicht übernommen werden sollten | Mehrwert im Einsatz |
|---|---|---|---|
| Management-Agent | Aufgabe verstehen, Plan erstellen, Aufgaben delegieren, Ergebnisse zusammenführen | Fachliche Detailentscheidungen anstelle spezialisierter Modelle treffen | Systemübergreifende Evidenz verknüpfen, manuelle Koordination reduzieren |
| Fachagent | Innerhalb eines begrenzten Kontexts Prüfungen, Disposition und Analysen durchführen und Evidenz zurückliefern | Eigenmächtig den Gesamtprozess entscheiden oder globale Richtlinien ändern | Entscheidungen sind nachvollziehbar und lassen sich einzeln austauschen |
| Menschliche Prüfinstanz | Unsichere Ergebnisse bearbeiten, risikoreiche Aktionen genehmigen, Sanierungspläne bestätigen | Alle risikoarmen Ergebnisse einzeln nachprüfen | Die Verantwortungsgrenze für Sicherheit und Qualität wahren |
Wofür der Management-Agent in einem Multi-Agenten-System zuständig ist
Der Management-Agent von FOX besteht aus drei Teilen: Ein Großes Sprachmodell (LLM) interpretiert Aufgaben, verknüpft Daten, erstellt Pläne und bewertet Ergebnisse; das Agent Harness verbindet Tools, Skills, persistentes Gedächtnis und Fachagenten, verwendet standardmäßig NemoClaw und unterstützt auch Alternativen; NVIDIA OpenShell isoliert die Ausführungsumgebung und kontrolliert die Zugriffsrichtlinien für Dateien, Befehle und Netzwerkziele.
Dieses Design zeigt: Der Management-Agent ist nicht nur eine Eingabeaufforderung, sondern eine dauerhaft laufende Ausführungsumgebung. Er muss bei Hintergrund- und geplanten Aufgaben kontinuierlich auf Bediener reagieren und den Untersuchungsfortschritt im Gedächtnis behalten. Bei der Aufteilung sollten daher Aufgabenstatus, Delegationslogik und Abschlusskriterien in der Management-Schicht liegen und nicht auf die einzelnen Fachagenten verteilt werden.
Wie die Grenzen von Fachagenten in einem Multi-Agenten-System gezogen werden
Auch die Fachagenten in FOX basieren auf LLMs und verfügen jeweils über eigene Anweisungen, Kontexte, Skills und Tools. Sie können spezialisierte Modelle aufrufen, etwa NVIDIA Cosmos für visuelle Prüfungen oder Kumo für die Erkennung von Anomalien in Zeitreihen, und ihre Erkenntnisse anschließend an den Management-Agenten zurückgeben, der über die nächsten Schritte entscheidet.
Ob ein eigener Fachagent abgespalten werden sollte, lässt sich an drei Punkten festmachen: ob spezielle Daten oder Modelle benötigt werden, ob es eigenständige Abnahmekriterien gibt und ob möglicherweise Tools mit hohen Berechtigungen aufgerufen werden. Sind alle drei Punkte nicht erfüllt, ist es in der Regel einfacher, die Aufgabe als Skill des Management-Agenten umzusetzen.
Verwaltende und spezialisierte Agenten aufteilen: Beispiel einer SMT-Produktionslinie
Das offizielle Beispiel beginnt mit einer AOI-Warnung. Der verwaltende Agent ruft über einen MCP-Server oder eine API die Platinen-ID, die betroffenen Bauteile und die Prüfbilder ab und stößt anschließend eine Zweitbewertung an. Die Platinen-ID ist das entscheidende Feld, das sich durch den gesamten Ablauf zieht. Der Adapter muss ID, Zeitstempel, Einheiten und Quellenangaben erhalten, damit nachfolgende Agenten die Fertigungshistorie und den Maschinenzustand nachvollziehen können.
| Spezialisierter Agent | Eingabe | Aufgerufene Fähigkeit | Ausgabe | Übergaberegel |
|---|---|---|---|---|
| Agent für visuelle Inspektion | Platinenbilder, Referenzmuster, freigegebene Beurteilungskriterien | NVIDIA Cosmos | Befunde, Belege, Unsicherheit | Bestätigte Defekte gehen an Bearbeitung und Untersuchung; unklare Ergebnisse an einen Menschen |
| Flottenmanagement-Agent | Platinen-ID und Zielort des bestätigten Defekts | Im Beispiel NVIDIA Isaac Sim und ROS 2 | Ergebnis der Berechtigungs- und Fähigkeitsprüfung, Abschlussstatus | In der Anfangsphase ist vor dem Transport eine Freigabe durch Bedienpersonal nötig |
| Agent für Ursachenanalyse | Platinen-ID, Bearbeitungshistorie, Inspektions- und Testprotokolle | Kumo Anomaly, Elasticsearch | PDF-Bericht mit Quellenangaben, auffälligen Messwerten, möglichen Ursachen und Korrekturvorschlägen | Geht zur Prüfung an den Produktionslinienleiter |
Zwei Details lohnen sich hier als Vorbild. Erstens: Der Agent für visuelle Inspektion gibt nicht nur „gut“ oder „schlecht“ aus, sondern liefert zusätzlich Belege und Unsicherheiten. Nur so kann der verwaltende Agent entscheiden, welcher Weg eingeschlagen wird. Zweitens: Die Ursachenanalyse kann durch einen fehlgeschlagenen Funktionstest ausgelöst werden. Selbst wenn die optische Prüfung keinen sichtbaren Defekt findet, muss sie sich nicht auf das Ergebnis des vorherigen spezialisierten Agenten stützen.
Auch der Ermittlungsweg des Ursachenanalyse-Agenten ist klar strukturiert. Bei einem vermuteten Lötfehler lokalisiert er zunächst anhand der Ein- und Ausfahrzeiten des Reflow-Ofens die Ofentemperaturmesswerte, sucht dann mit Kumo Anomaly nach anomalen Mustern und vergleicht sie mit anderen Chargen, Prüfergebnissen und Maschinenhandbüchern. Frühere Untersuchungen können die Suchrichtung vorgeben, doch die Schlussfolgerung muss auf dem aktuellen Programm und den aktuellen Aufzeichnungen beruhen. Das senkt das Risiko, veraltete Erfahrungen ungeprüft zu übernehmen.
Zu beachten ist außerdem: Das Flottenmanagement wird im Referenzablauf in einer digitalen Zwillingsumgebung demonstriert. Beim Anschluss echter Roboter und AMRs (autonomer mobiler Roboter) ist zusätzlich eine werksspezifische Geräteintegration erforderlich. Ein bestandener Simulationstest bedeutet nicht automatisch, dass der Einsatz in der Produktionslinie möglich ist.
Wie man manuelle Prüfpunkte für Multi-Agenten einrichtet
Manuelle Prüfpunkte sind nicht automatisch besser, je mehr es davon gibt. Sind die Prüfungen zu dicht getaktet, ermüden Bediener schnell und klicken aus Gewohnheit auf „Bestätigen“. Gibt es zu wenige, können fehlerhafte Aktionen direkt die physische Produktionslinie beeinflussen. Mit dem FOX-Beispiel lässt sich die folgende Tabelle als erste Version einer Prüfmatrix verwenden.
| Entscheidungsszenario | Behandlung im Beispiel | Empfohlene Prüfmethode | Empfohlener Prüfer |
|---|---|---|---|
| Vermuteter Defekt liegt innerhalb akzeptabler Abweichung | Evidenz zurückgeben, gemäß Werksrichtlinie weiterproduzieren | Richtlinienbasiert freigeben, Datensatz aufbewahren und stichprobenartig prüfen | Qualitätsingenieur |
| Visuelles Urteil nicht eindeutig | An manuelle Nachprüfung übergeben | Manuelle Einzelfallprüfung | Qualitätsprüfer |
| Bestätigter Defekt, Transport zur Reparatur erforderlich | Im ersten Deployment muss der Bediener zuerst zustimmen | Freigabe vor der Aktion | Bediener vor Ort |
| Kartenreparatur und erneute Prüfung | Vom Bediener ausführen lassen, danach verpacken | Manuell ausführen und Ergebnis dokumentieren | Reparaturbediener |
| Ursachenanalyse und Korrekturmaßnahmen | Bericht zur Prüfung durch den Produktionsleiter ausgeben | Nach Prüfung des Berichts entscheiden | Produktionsleiter |
Die ersten beiden Spalten der Tabelle stammen aus dem offiziellen Beispiel, die letzten beiden sind unsere Empfehlungen für die Umsetzung. Bei neuen Entscheidungen außerhalb der Matrix können Sie nacheinander drei Fragen stellen:
- Ist die Aktion umkehrbar? Schreibgeschützte Abfragen und das Erzeugen von Berichten lassen sich leicht rückgängig machen; das Bewegen physischer Karten und das Ändern von Prozessparametern ist deutlich teurer.
- Wie groß ist der Wirkungsbereich? Ob nur eine einzelne Karte oder die gesamte Produktionslinie betroffen ist, sollte unterschiedliche Freigabestufen nach sich ziehen.
- Ist die Evidenz ausreichend? Bei widersprüchlicher Evidenz, fehlenden Daten oder wenn das Modell ausdrücklich Unsicherheit anzeigt, sollte an Menschen übergeben werden, statt weiter zu schließen.
Freigaberegeln sollten möglichst nicht nur in der Eingabeaufforderung stehen. FOX definiert mit einer Richtlinienebene wie OpenShell, welche Aktionen erlaubt sind und wann ein Bediener prüfen muss. So kann selbst eine fehlerhafte Modellentscheidung die Ausführungsgrenzen nicht umgehen. Die Eingabeaufforderung kann Verhalten lenken, doch die eigentliche Zugriffskontrolle sollte die Laufzeitumgebung absichern.
Multi-Agenten in der Produktion schnell einsetzen: Umsetzung in 6 Schritten
FOX ist derzeit als Early Access verfügbar. Der Blueprint enthält bereits zahlreiche Muster, doch die fabrikspezifischen Teile müssen weiterhin von Entwicklern umgesetzt werden. Wenn Sie vor dem Start die Verantwortungsgrenzen klären, vermeiden Sie, die Referenzarchitektur mit einem sofort einsatzbereiten Produkt zu verwechseln.
| Modul | Blueprint bietet | Entwickler verantwortet |
|---|---|---|
| Management-Agent | Persistente Umgebung mit Skills, Tools, Gedächtnis und Delegationsfähigkeiten | Aufgabendefinition, Abschlusskriterien, Anwendungsintegration |
| Fabrikwissen | Datenanbindung und Retrieval-Muster | Mapping von Kennungen, Zeitstempeln, Einheiten und Quellenberechtigungen |
| Spezialisierte Agenten | Beispiele für Inspektion, Ursachenanalyse, Berichte und Flottenmanagement | Fabrikspezifische Entscheidungskriterien, zusätzliche Rollen, Ausgabeprüfung |
| Geräteintegration | MCP- und API-Muster, Anbindung an ROS 2 und Isaac Sim | Anbindung physischer Geräte und Transportstrategien |
| Deployment | Konfiguration von Services, Modellendpunkten und optionalen Simulationseinheiten | Ressourcenauswahl, Endpunktkonfiguration, Prüfung der Zugriffsgrenzen |
Ob Sie FOX einsetzen oder nicht: Sie können in den folgenden 6 Schritten vorgehen:
- Einen einzelnen geschlossenen Anwendungsfall auswählen: Beginnen Sie mit einem Prozess mit klarem Auslöser, etwa „von AOI-Alarm bis Reparatur und Ursachenbericht“, und legen Sie gleichzeitig die Abschlusskriterien schriftlich fest.
- Einheitliche Datenschlüssel festlegen: Ordnen Sie MES, ERP und Maschinendatenbanken demselben Kennungssystem zu und behalten Sie Zeitstempel, Einheiten und Quellenverweise bei. Auch Handbücher und SOPs sollten in die durchsuchbare Wissensbasis aufgenommen werden.
- Ausgabevertrag für Agenten definieren: Spezialisierte Agenten sollen mindestens eine Schlussfolgerung, die Evidenzquellen und die Unsicherheit zurückgeben. Feldnamen können frei gewählt werden, müssen aber programmatisch prüfbar sein.
- Minimale Berechtigungen umsetzen: Verteilen Sie Tool- und Netzwerkzugriffsrechte nach Rolle. Die Ursachenanalyse darf beispielsweise Produktionsdaten nur lesen, während das Flottenmanagement Transporte auslösen kann; vorher müssen Berechtigungs- und Fähigkeitsprüfungen bestanden werden.
- Zuerst in Simulation oder Shadow-Modus betreiben: Lassen Sie Agenten Empfehlungen geben, aber noch keine tatsächlichen Aktionen ausführen. Menschliche Schlussfolgerungen dienen als Vergleich; prüfen Sie vor allem Fehlalarme, übersehene Fälle und fehlende Belege.
- Automatisierung schrittweise freigeben: Sehen Sie zunächst eine Freigabe vor jeder Aktion vor. Sobald die Kennzahlen stabil sind und die Verantwortlichen zustimmen, können risikoarme, umkehrbare Aktionen per Richtlinie freigegeben und stichprobenartig geprüft werden.
Für jeden Schritt sollten Audit-Einträge hinterlegt werden, einschließlich Version der Eingangsdaten, aufgerufener Tools, Modellergebnisse und freigebender Person. Die offiziellen Beispiele hängen Berichte mit Quellenangaben und auffälligen Messwerten an, damit Prüfer die Schlussfolgerungen nachvollziehen können, anstatt ihnen nur glauben oder nicht glauben zu können.
Modellauswahl und Schnittstellenkonfiguration für Multi-Agenten
FOX ermöglicht es, je nach Bereitstellungsanforderung Frontier-Modelle oder offene Modelle zu wählen. Offiziell genannte Beispiele sind GPT-6 Astra und NVIDIA Nemotron. Bei der tatsächlichen Auswahl kann die Bewertung nach Rollen getrennt erfolgen; nicht alle Agenten müssen dasselbe Modell verwenden.
| Rolle | Modellschwerpunkte | Offizielle Beispielfähigkeiten | Kanäle zur Prototypenvalidierung | Abrechnungsgrundlage |
|---|---|---|---|---|
| Manager-Agent | Planungsfähigkeit, Tool-Aufrufe, langes Kontextfenster | GPT-6 Astra, NVIDIA Nemotron | Werksinterne Endpunkte, APIYI apiyi.com usw. | Es gelten die Abrechnungsregeln des tatsächlichen Endpunkts |
| Spezialisierter Agent | Aufgabenbezogene Steuerung von Genauigkeit und Kosten | Basierend auf LLM, mit Aufruf spezialisierter Modelle | Werksinterne Endpunkte, APIYI usw. | Für den APIYI-Kanal gilt die Preisseite |
| Visuelle und Zeitreihenmodelle | Domänengenauigkeit, Bereitstellungsart | NVIDIA Cosmos, Kumo Anomaly | Vorrangige Bereitstellung nach Blueprint-Lösung | Abrechnung nach tatsächlichem Bereitstellungsplan |
Anbindungstipp: Wenn Sie zunächst mit desensibilisierten Daten die Aufgabenteilung und Eingabeaufforderungen der LLM-Schicht validieren möchten, können Sie die in diesem Artikel behandelten Modelle über APIYI aufrufen. APIYI ist mit den Schnittstellenformaten von OpenAI und Anthropic kompatibel. In der Regel müssen nur drei Angaben konfiguriert werden:
api_key,base_urlundmodel. Die konkreten Adressen und verfügbaren Modelle finden Sie in der Dokumentation: https://docs.apiyi.comPreishinweis: Modellpreise, Abrechnungslogik, Preise pro Einheit für Ein- und Ausgabe sowie Cache-Preise richten sich nach den tatsächlichen Daten auf der APIYI-Preisseite: https://docs.apiyi.com/models. Dieser Artikel nennt keine konkreten Zahlen; für eine Schätzung sollten die Aufrufvolumina getrennt nach Management- und Spezialistenebene erfasst werden.
Häufige Fragen (FAQ)
F1: Was ist ein Management-Agent in einem Multi-Agenten-System?
Er ist der Koordinator: Er versteht die Aufgabe, erstellt einen Plan, delegiert an spezialisierte Agenten und fasst die Ergebnisse zusammen. In FOX verbindet er zusätzlich Gedächtnis, Skills und Tools und läuft langfristig innerhalb der Grenzen der Zugriffsrichtlinien.
F2: Worin unterscheiden sich Management-Agent und spezialisierter Agent?
Der Management-Agent kümmert sich um die Frage „Was kommt als Nächstes?“, der spezialisierte Agent um „Was ist das fachliche Ergebnis in dieser Sache?“. Der eine behält den Gesamtprozess im Blick, der andere erledigt mit begrenztem Kontext, begrenzten Skills und Tools eine fokussierte Aufgabe und gibt die Belege an die Managementebene zurück.
F3: Welche Entscheidungen müssen in einem Multi-Agenten-System zwingend von Menschen geprüft werden?
Vorrangig sollten Fälle mit unklarem Ergebnis, Aktionen an physischen Geräten, Änderungen von Prozessparametern sowie Korrekturmaßnahmen abgedeckt werden. Das offizielle Beispiel verlangt ausdrücklich, dass unsichere Ergebnisse an Menschen weitergegeben werden, dass der Operator den ersten Transportvorgang vorab freigibt und dass der Ursachenbericht von der Produktionslinienleitung geprüft wird.
F4: Lässt sich ein Multi-Agenten-System für die Fabrik vollständig lokal betreiben?
Ja. FOX unterstützt das lokale Hosten von Agenten-Umgebung, Modellen und Datenspeicher auf einer NVIDIA DGX Station. Eine vollständig lokale Bereitstellung setzt allerdings voraus, dass sich alle Modelle und Service-Endpunkte innerhalb des Fabriknetzes befinden – nur dann bleiben Produktionsdaten, Bilder, Eingabeaufforderungen und Untersuchungsergebnisse vor Ort.
F5: Wie lässt sich die Aufgabenteilung eines Multi-Agenten-Systems schnell per API überprüfen?
Am besten baut man zunächst mit anonymisierten Beispieldaten zwei Rollen auf – Management und Fachrolle – und vergleicht, wie verschiedene Modelle die Aufgabe zerlegen und Tools aufrufen. Über APIYI apiyi.com ist der Zugang im OpenAI- oder Anthropic-kompatiblen Format möglich; die Konfiguration ist unter docs.apiyi.com beschrieben.
F6: Welche Einschränkungen gelten für extern gehostete Modelle? Und wie lassen sich die Kosten abschätzen?
Bei externen Modellen muss man bewerten, welche Daten an den Endpunkt gehen. Prozesse mit sensiblen Produktionsdaten sollten vorher anonymisiert oder auf lokale Modelle umgestellt werden. Die Kosten hängen von der Anzahl der Aufrufe und der Kontextlänge ab; bei Aufrufen über APIYI gelten die Einzel- und Cache-Preise gemäß https://docs.apiyi.com/models.
Kernaussagen zum Einsatz von Multi-Agenten im Produktivbetrieb
- Management-Agenten steuern den Prozess: Sie übernehmen zentral Planung, Delegation, Statusverfolgung und Ergebniszusammenfassung.
- Fach-Agenten übernehmen die fachliche Beurteilung: Sie werden nach Daten, Abnahmekriterien und Tool-Berechtigungen als eigenständige Rollen abgegrenzt.
- Ausgaben müssen Belege enthalten: Schlussfolgerungen sollten Quellen und Unsicherheiten nennen, damit nachgelagerte Stellen sie prüfen können.
- Prüfungen nach Risiko abstufen: Die Prüfintensität richtet sich nach Umkehrbarkeit, Tragweite und Belastbarkeit der Belege.
- Berechtigungen über Policies absichern: Zugriffsgrenzen gehören in die Laufzeitumgebung und nicht nur in die Eingabeaufforderung.
- Simulation ist nicht gleich Produktionsreife: Die Anbindung echter Geräte erfordert fabrikspezifische Integration und Freigabeprozesse.
- Im Prototyp zuerst die Aufgabenteilung validieren: Mit anonymisierten Daten lassen sich Modelle über APIYI vergleichen, bevor die Bereitstellung festgelegt wird.
Fazit
Beim Einsatz von Multi-Agenten im Produktivbetrieb geht es bei der Aufteilung vor allem um Verantwortungsgrenzen, nicht um die Anzahl der Agenten:
- Management-Agent: Behält das Gesamtziel und den Aufgabenstatus im Blick und koordiniert systemübergreifende Belege sowie die nächsten Schritte.
- Fach-Agent: Ruft für klar definierte Aufgaben spezialisierte Modelle und Tools auf und liefert überprüfbare Ergebnisse.
- Manuelle Prüfpunkte: Werden bei unsicheren Schlussfolgerungen, risikoreichen Aktionen und finalen Korrekturentscheidungen gesetzt und von der Policy-Ebene erzwungen.
Wir empfehlen, zunächst einen klar ausgelösten End-to-End-Prozess auszuwählen, im Shadow-Modus Daten-, Beleg- und Freigabeketten zu testen und die Automatisierung erst danach schrittweise freizugeben. Wenn Sie Lösungen auf LLM-Ebene schnell vergleichen möchten, können Sie über APIYI apiyi.com mit einer einheitlichen Schnittstelle Prototypen validieren; in der Produktionsphase legen Sie dann anhand der Datengrenzen die endgültige Bereitstellungsform fest.
📚 Referenzen
- NVIDIA Tech-Blog: How NVIDIA Factory Operations Blueprint Coordinates AI Agents to Investigate Production Issues
- Link:
developer.nvidia.com/blog/how-nvidia-factory-operations-blueprint-coordinates-ai-agents-to-investigate-production-issues/ -
Beschreibung: Die Fact-Check-Quelle für die FOX-Architektur, das SMT-Beispiel und die Bereitstellungsmethoden in diesem Artikel, veröffentlicht am 4. November 2026.
-
APIYI Dokumentationszentrum: Anleitung zur API-Anbindung
- Link:
docs.apiyi.com -
Beschreibung: Hier finden Sie die konkreten Konfigurationsmethoden für OpenAI- und Anthropic-kompatible Formate.
-
APIYI Preisseite: Modellliste und Abrechnungsdaten
- Link:
docs.apiyi.com/models - Beschreibung: Zur Überprüfung von Modellverfügbarkeit, Abrechnungsgrundlage, Ein- und Ausgabepreisen sowie Cache-Preisen.
Autor: APIYI Technikteam
Technischer Austausch: Kontaktieren Sie uns gerne über die Startseite von APIYI unter apiyi.com. Weitere Materialien finden Sie im Dokumentationszentrum unter docs.apiyi.com.
