Multi-Agent-NX-Assistent: Die Kurzfassung
Ein Multi-Agent-NX-Assistent teilt einen KI-Chatbot für Siemens NX in Rollen auf: einen Orchestrator, der über einen festen Werkzeugkatalog baut, einen Recherche-Agenten, der NX-Wissen über MCP abfragt, einen Prüfer und einen Coder als letzte Instanz. inteliScience baut ihn so, dass jede Rolle nur sieht, was sie braucht, und jede Änderung ein Undo-Schritt bleibt.
| Ein großer Chatbot | Multi-Agent-NX-Assistent | |
|---|---|---|
| Kontext | Dokumente, Flächenlisten, Bilder und Chatverlauf in einem Fenster | jede Rolle behält ihren eigenen kurzen Kontext; der Orchestrator sieht Antworten, keine Rohdaten |
| Modellkosten | das stärkste Modell liest alles | starkes Modell, wo geurteilt wird, günstigere Modelle für Abfragen und Listen |
| Prüfung | der bauende Agent bewertet seine eigene Arbeit | ein separater Prüfer mit eigenen Anweisungen |
| Fehlende Fähigkeit | das Modell improvisiert Code zur Laufzeit | eine Coder-Rolle schreibt ein Journal, erprobt es und spielt es als einen Undo-Schritt ab |
| Änderungen in NX | was auch immer der generierte Code tut | typisierte Tools, eine sichtbare Undo-Markierung pro Schritt |
Das Problem: Ein Chatbot, zu viele Aufgaben
Unser erster NX-Assistent war ein einzelnes Modell, an dem jedes Tool hing. Es funktionierte, doch an echten Teilen füllte sich sein Kontext schnell. Der Grund war banal: Eine Flächenliste eines Serienteils umfasst 20 bis 50 KB JSON, eine Antwort aus der Wissensdatenbank zieht mehrere Dokumentations-Chunks mit, und ein Screenshot eines Zeichnungsblatts kostet mehr als beides zusammen. All das landete im selben Kontextfenster wie die eigentliche Anfrage des Nutzers.
Drei Dinge gingen gleichzeitig schief. Das Modell, das entschied, was als Nächstes gebaut wird, verbrauchte seine Aufmerksamkeit für Rohdaten, die es nie wieder brauchen würde. Jede Abfrage lief auf dem stärksten Modell. Und das Modell, das ein Feature gebaut hatte, wurde gefragt, ob das Feature richtig ist – als würde man einen Konstrukteur seine eigene Zeichnung freigeben lassen.
Anthropic beschrieb im Juni 2025 dasselbe Muster für Recherche-Agenten: Sub-Agenten mit eigenen Kontextfenstern erkunden parallel und verdichten “die wichtigsten Tokens für den leitenden Recherche-Agenten”, und ihr Multi-Agent-Setup übertraf einen einzelnen Claude-Opus-4-Agenten in einer internen Recherche-Evaluierung um 90,2 Prozent (Anthropic-Engineering-Blog, abgerufen am 30. September 2026). Derselbe Artikel ist ehrlich, was die Kosten angeht: Multi-Agent-Systeme verbrauchten etwa das 15-Fache der Tokens eines Chats. Wir teilen Rollen also auf, um Kontexte sauber zu halten, nicht um mehr Modellaufrufe zu erzeugen. Diese Aufteilung ist der Kern dessen, wie wir Agentic CAD für Siemens NX an Engineering-Teams liefern.
Die Architektur eines Multi-Agent-NX-Assistenten
Das Modell schreibt zur Laufzeit kein NXOpen. Es wählt ein Tool aus einem festen Katalog, füllt Parameter aus und liest ein strukturiertes Ergebnis, und jede Änderung bleibt ein Undo-Schritt.
Vier Rollen, vier Kontexte
Jede Rolle existiert, weil sie einen anderen Kontext, ein anderes Modell oder andere Berechtigungen braucht. Traf keiner dieser drei Gründe zu, haben wir die Rolle wieder zusammengelegt.
Der Orchestrator baut
Der Orchestrator ist die einzige Rolle, die das Teil verändert. Er spricht mit dem Nutzer und entscheidet über die Reihenfolge der Arbeit.
Der Recherche-Agent hält Dokumente aus dem Weg
Diese Rolle fragt die Wissensdatenbank ab und liefert eine kurze Antwort mit Quellen, sodass Dokumentationsausschnitte aus dem Kontext des Orchestrators herausbleiben. Die Wissensdatenbank ist unser Vision4NX Connector.
Scout und Prüfer schauen hin, der Orchestrator entscheidet
Der Scout übernimmt Geometrieabfragen und antwortet in einem Satz, sodass lange Flächenlisten aus dem Kontext des Orchestrators herausbleiben.
Der Prüfer prüft, was der Orchestrator gebaut hat, gegen die Hausregeln. Er ist eine zweite Meinung mit eigenen Anweisungen, kein Nachgedanke des bauenden Agenten. Scout und Prüfer sind gebaut und werden derzeit live an echten Teilen getestet.
Der Coder ist die letzte Instanz
Nur wenn kein Tool leisten kann, was der Nutzer verlangt, übergibt der Orchestrator die Aufgabe an einen Coding-Agenten. Der Coder schreibt ein Journal, erprobt es und spielt es dann als einen Undo-Schritt ab.
Der Coder ist die neueste Rolle und im Live-Test. Solange ein CAD-Manager nicht gesehen hat, wie er sich an echten Teilen verhält, würden wir ihn außerhalb eines Pilotprojekts nicht aktivieren. Unser ausgearbeitetes NXOpen-Beispiel von Prompt zu Journal zeigt diesen Schritt isoliert.
Das läuft als POC. Was für die Produktion fehlt: rollenbezogene Tool-Berechtigungen, SSO, ein Audit-Log in der Hand Ihres CAD-Managers und der On-Premise-Betrieb der Wissensschicht. Wir schließen die Lücke von “läuft auf meinem Rechner” zu “läuft in der Konstruktionsabteilung”: so bringen wir Agentic CAD für Siemens NX in die Produktion.
Schmal und verifiziert schlägt breit und hoffnungsvoll
Das größte Risiko in einem NX-Assistenten ist kein schwaches Modell. Es ist ein Tool, das behauptet, etwas zu können, das es nie an einem echten NX getan hat.
Der von der Community entwickelte NX_MCP-Server (98 GitHub-Sterne, 20 Forks, abgerufen am 30. September 2026) beschränkt Dateiargumente auf einen Workspace und lässt standardmäßig nur 16 zertifizierte Tools aktiv, während 34 ältere Tools hinter Umgebungsflags verborgen bleiben. Sein README dokumentiert einen Batch-Workflow mit 20 Durchläufen, der im August 2026 auf NX 2506 bestanden wurde. Als wir die älteren Tools in einem Fork gegen eine laufende NX-2506-Sitzung aktivierten, riefen mehrere davon Builder-Methoden auf, die es in diesem Release nicht gibt: Fehlschläge mit selbstbewussten Beschreibungen.
Wir haben in unserem Fork zwei Tools in die zertifizierte Liste aufgenommen, Kreisskizzen und Hinterschnitterkennung, und zwar erst, nachdem beide in einer interaktiven Sitzung gelaufen waren. Unsere eigene Bridge folgt derselben Disziplin.
Ein Fehler unterbricht nie die Verbindung oder NX; er geht als Tool-Fehler mit Hinweis an das Modell zurück. Diese Schleife aus Planen, Ausführen, Verifizieren und Korrigieren stammt aus unserer Fallstudie zu hybrider agentischer KI für Siemens NX; die Aufteilung auf Rollen hat sie leichter überprüfbar gemacht, nicht grundsätzlich anders.
Worauf Sie bei einem Multi-Agent-NX-Assistenten achten sollten
Wenn Sie einen Anbieter bewerten oder selbst einen bauen wollen, trennen diese fünf Fragen eine Architektur von einer Demo:
- Kann das Modell Code ausführen, den es gerade geschrieben hat? Nur über einen abgesicherten Coder-Pfad, der ihn zuerst erprobt und als einen Undo-Schritt abspielt.
- Ist der Kontext jeder Rolle getrennt? Flächenlisten, Dokumentations-Chunks und Bilder bleiben bei der Rolle, die sie gebraucht hat.
- Ist der Prüfer unabhängig? Eigene Anweisungen, dieselben Hausregeln wie der bauende Agent.
- Ist jedes Tool auf Ihrem NX-Release verifiziert? Eine zertifizierte kurze Liste schlägt eine lange hoffnungsvolle.
- Wo läuft die Wissensdatenbank? On-Premise heißt: Die Anwendung muss der MCP-Client sein.
Punkt 1 ist der, bei dem wir keine Kompromisse eingehen würden. Für ein Single-Agent-Setup lesen Sie unsere Claude-Code-NX-Integration; für einen Server, den andere Agenten aufrufen, was ein produktionsreifer Siemens NX MCP Server braucht.
Häufig gestellte Fragen
Was ist ein Multi-Agent-NX-Assistent?
Ein Multi-Agent-NX-Assistent ist ein KI-Chatbot für Siemens NX, dessen Arbeit auf Rollen mit getrennten Kontexten verteilt ist: ein Orchestrator, der das Teil über typisierte NXOpen-Tools ändert, ein Recherche-Agent, der eine Wissensdatenbank über MCP abfragt, ein Scout für Geometrieabfragen, ein Prüfer, der Ergebnisse kontrolliert, und ein Coder, der Journale nur dann schreibt, wenn kein Tool passt.
Multi-Agent oder Single-Agent: Was ist besser für Siemens NX?
Für kurze Sitzungen an einfachen Teilen ist ein einzelner Agent einfacher und völlig ausreichend. Sobald Sitzungen an echten Teilen Dutzende Tool-Aufrufe umfassen, zahlt sich die Aufteilung aus: Der Kontext des Orchestrators bleibt klein, Abfragen laufen auf günstigeren Modellen, und ein Prüfer mit eigenem Auftrag kontrolliert die Arbeit des bauenden Agenten. Der Preis sind mehr Modellaufrufe, deshalb halten wir die Zahl der Rollen klein.
Was kostet ein Multi-Agent-Assistent im Betrieb im Vergleich zu einem einzelnen Chatbot?
Das hängt davon ab, wie oft die Rollen aufgerufen werden, nicht davon, wie viele es gibt. Anthropic hat für Multi-Agent-Recherchesysteme etwa das 15-Fache der Tokens eines Chats gemessen, doch dieses Setup erkundet bewusst parallel. In einem NX-Assistenten laufen die Spezialisten bei Bedarf auf günstigeren Modellen, Prompts werden gecacht und große Tool-Ergebnisse gekürzt. Wir protokollieren die Nutzung pro Rolle und Anfrage, sodass die Kosten jeder Rolle gemessen und nicht geschätzt sind.
Warum lässt man die KI nicht direkt NXOpen-Code schreiben?
Weil Modelle gerade bei generiertem Code API-Aufrufe halluzinieren und ungeprüfter Code in einer laufenden Sitzung ein halb gebautes Teil hinterlassen kann. Ein fester Werkzeugkatalog in C# erledigt die NXOpen-Arbeit; das Modell wählt nur aus und parametrisiert. Fehlt ein Tool, schreibt eine Coder-Rolle ein Journal, erprobt es und spielt es als einen Undo-Schritt ab.
Kann der Assistent unsere eigene Wissensdatenbank nutzen, wenn sie On-Premise läuft?
Ja, wenn die Chat-Anwendung der MCP-Client ist. Der gehostete MCP-Connector der Claude API erreicht nur öffentlich erreichbare HTTP-Server, daher muss eine On-Premise-Wissensdatenbank von der Anwendung selbst angebunden werden. Ein Recherche-Agent hält dann diese Tools und liefert dem Orchestrator Antworten mit Quellen.
Nächster Schritt
Wenn Ihr Team einen NX-Assistenten hat, der in Demos funktioniert und an echten Teilen scheitert, ist die Aufteilung in Rollen meist die Lösung und der verifizierte Werkzeugkatalog das Fundament.
Sprechen Sie mit unseren Ingenieuren über einen Multi-Agent-NX-Assistenten
