Agentic CAD für Siemens NX

Agentic CAD für Siemens NX: Assistenten, die recherchieren, bauen, prüfen und programmieren

Ein Modell, das jedes NX-Tool hält, liest zu viel, bewertet seine eigene Arbeit und kostet zu viel. Ein Team von Agenten mit klaren Rollen arbeitet besser: Einer plant und baut, einer recherchiert, einer untersucht die Geometrie, einer prüft das Ergebnis, und einer schreibt Code nur dann, wenn kein Tool passt.

Diese Seite behandelt die Agentenschicht. Die Protokoll- und Serverschicht darunter beschreibt unsere Seite zum Siemens NX MCP Server ; ein einzelner Claude-Code-Agent, der in der NX-Sitzung arbeitet, ist unsere Claude-NX-Integration; das Wissen kommt über den Vision4NX Connector. Sie alle gehören zu unserer Familie der NX-KI-Assistenten und Chatbots.

Agentic CAD in Siemens NX: die Kurzfassung

• Was es ist: ein orchestrierender Agent, der das Modell aufbaut und ändert, plus Spezialisten-Agenten, die recherchieren, Geometrie untersuchen und Ergebnisse prüfen. Sie handeln in der laufenden NX-Sitzung über einen festen Katalog von NXOpen-Tools.
• Woher das Wissen kommt: ein Recherche-Agent, der über einen MCP-Connector eine Wissensdatenbank mit Dokumentation zu NX, NXOpen und Teamcenter sowie Ihrem freigegebenen internen Material abfragt und eine kurze Antwort mit Quellen liefert.
• Wenn kein Tool passt: ein Coder-Agent schreibt ein NXOpen-Journal für genau diese Aufgabe, testet es an einer Kopie des Teils und spielt es erst dann als einzelnen Undo-Schritt in der Sitzung ab.
• Was es kontrollierbar hält: typisierte Tools statt freiem Code für die normale Arbeit, ein Undo-Schritt pro Änderung, ein lesbares Protokoll dessen, was jedes Tool berührt hat, und Bestätigung dort, wo Sie sie wollen.
• Was es nicht ist: kein Text-to-CAD, keine Batch-Fabrik und kein Ersatz für Ihre Konstrukteure. Es führt bekannte Operationen aus und prüft sie; Ihre Ingenieure verantworten die Konstruktionsabsicht und zeichnen das Ergebnis ab.

Warum ein Modell mit jedem NX-Tool nicht reicht

Der erste NX-Assistent, den die meisten Teams bauen, ist ein Sprachmodell mit einer langen Liste von Tools. Am Demo-Block funktioniert das. An einem echten Teil stößt es gleichzeitig auf drei Probleme.

Das erste ist die Datenmenge. Eine Flächen- oder Kantenliste eines echten Teils umfasst schnell Dutzende Kilobyte, und ein Blattbild ist noch größer. Das Modell liest sie einmal, und von da an reist sie bei jeder folgenden Anfrage mit. Die IDs darin sind nach der nächsten Änderung ohnehin veraltet. Das zweite ist das Urteilsvermögen: Ein Modell, das gerade eine Zeichnung gebaut hat, ist ein schlechter Prüfer genau dieser Zeichnung, weil es gegen das prüft, was es vorhatte, statt gegen das, was auf dem Blatt steht. Das dritte sind die Kosten. Jede Anfrage trägt den vollständigen Verlauf, die Anweisungen und den Werkzeugkatalog mit, und eine Arbeitssitzung braucht laut unseren Logs etwa 15 bis 30 Tool-Aufrufe.

Die Aufteilung der Arbeit löst alle drei. Der bauende Agent wird nicht mit Listen und Bildern überflutet, der prüfende Agent hat das Ergebnis nicht selbst gebaut, und das teure Modell wird nur dort eingesetzt, wo der Assistent urteilen muss.

Die Rollen in einem Multi-Agent-NX-Assistenten

Fünf Rollen: ein Orchestrator, der plant und baut, ein Recherche-Agent, der nachschlägt, ein Geometrie-Scout, der das Teil untersucht, ein Prüfer, der das Ergebnis kontrolliert, und ein Coder, der nur dann Code schreibt, wenn kein Tool passt.

Die Aufteilung ist kein festes Dogma. Ein Projekt, das nie Zeichnungen berührt, braucht keinen Zeichnungsprüfer; ein Projekt mit großer Normenbibliothek braucht vielleicht einen zweiten Recherche-Agenten. Ausführlicher erklären wir, wie wir Recherche, Aufbau, Prüfung und Coding auf Agenten verteilen und was jede Aufteilung kostet und spart.

Wie eine Agentic-CAD-Anfrage in NX abläuft

Nehmen wir eine Zeichnungsanfrage an einem geöffneten 3D-Teil: ein Blatt mit Draufsicht, Vorderansicht und den Hauptmaßen. Der Ingenieur fragt einmal; die Agenten erledigen den Rest nach einem festen Muster.

1. Kontext. Der Assistent prüft, welches Teil geöffnet ist und welche Ihrer Regeln dafür gelten.
2. Planen. Der Orchestrator legt die Reihenfolge und das Blattformat fest. Ist er unsicher, wie sich ein NX-Befehl verhält, fragt er den Recherche-Agenten, statt zu raten.
3. Geometrie finden. Der Scout findet die Bohrungen, Flächen und Kanten, die der nächste Schritt braucht.
4. Bauen. Der Orchestrator ruft die Bau-Tools auf.
5. Prüfen. Der Prüfer vergleicht das Ergebnis mit Ihren Regeln und meldet Mängel und Lücken.
6. Korrigieren oder übergeben. Der Orchestrator verschiebt, löscht oder ergänzt, was der Prüfer markiert hat, oder stoppt und fragt den Ingenieur, wenn die Regel unklar ist. Der Ingenieur sieht jeden Tool-Aufruf mit Argumenten, Ergebnis und Laufzeit.

Dasselbe Muster funktioniert für die Modellierung. An einem bestehenden Teil findet der Scout die Flächen, der Orchestrator baut die Passfedernut, die Bohrung oder die Verrundung, und das Bearbeiten eines bestehenden Features öffnet es in seinem eigenen Builder, sodass das Feature seinen Platz im Teile-Navigator behält. Für einzelne Operationen aus einem Chat-Panel ohne Agentenschicht ist unser NX Action Assistant die einfachere Lösung; für Zeichnungen, die Teil für Teil angefordert werden, siehe den Zeichnungs- und Dokumentationsassistenten.

Der Coder als Fallback: ein NXOpen-Journal, wenn kein Tool passt

Kein Werkzeugkatalog deckt alles ab. Stellt der Orchestrator fest, dass keines seiner Tools leisten kann, was der Ingenieur verlangt, kann er die Aufgabe an einen Coder-Agenten übergeben, statt zu improvisieren. Der Coder fragt die Wissensdatenbank nach den richtigen NXOpen-Aufrufen ab und schreibt ein Journal für genau diese Aufgabe.

Das Journal geht nicht direkt in Ihre Sitzung. Es läuft zuerst in einem headless NX gegen eine gespeicherte Kopie des Teils, und nur wenn es besteht, wird es in der laufenden Sitzung abgespielt, wo der gesamte Lauf ein Undo-Schritt ist. Ausgaben und Fehlermeldungen gehen an den Coder zurück, sodass aus einem fehlgeschlagenen Test eine Korrektur wird, kein Ticket. Den Prompt-to-Journal-Teil davon zeigen wir Schritt für Schritt in unserem ausgearbeiteten Prompt-to-Journal-Beispiel, und warum ungeführte Modelle API-Member erfinden, erklärt unser Beitrag KI-Codegenerierung für NX Open.

Zwei ehrliche Hinweise. Der Coder ist die neueste Rolle in unserem Stack: Er ist gebaut, und wir validieren ihn noch in Live-Sitzungen, deshalb behandeln wir ihn als Fallback, nicht als Hauptweg. Und ein Journal, das eine wiederkehrende Aufgabe löst, sollte kein Einzelstück bleiben. Es wird zu einem geprüften, typisierten Tool im Katalog – so wächst der Katalog.

NX bleibt reaktionsfähig, während die Agenten arbeiten

NX ist nur beschäftigt, während ein Tool-Aufruf ausgeführt wird; das Assistentenfenster bleibt nutzbar, während die Agenten nachdenken, und der Konstrukteur kann zwischen den Aufrufen in NX weiterarbeiten. Das Stoppen einer Anfrage beendet die Konversation. Ein Tool-Aufruf, den NX bereits gestartet hat, läuft bis zu seinem Ende und kann dann in NX rückgängig gemacht werden.

Wo wir Agentic CAD bisher gebaut haben

Zwei aktuelle Projekte, beide anonymisiert. Für einen Maschinenbauer aus der DACH-Region bauen wir nach diesem Muster eine Zeichnungsautomatisierung: Der Assistent wird an einem 3D-Teil geöffnet, erstellt das Blatt aus den eigenen Schriftfeldvorlagen des Kunden, platziert Ansichten und Mittelpunktmarkierungen und bemaßt sie nach Regeln, die aus den bestehenden Zeichnungen des Kunden abgeleitet sind, und ein Prüfer-Agent kontrolliert das Blatt gegen diese Regeln. Blätter, Ansichten und die ersten Maßtypen funktionieren; einige Maßtypen scheitern noch innerhalb der NX API und fallen auf einfachere zurück, und Toleranzen und Oberflächensymbole sind der schwierige Teil. Das sagen wir, bevor das Projekt startet.

Für einen asiatischen Hersteller hat die offene NX-MCP-Server-Linie in einer laufenden NX-Sitzung an einem Serienteil eine Formanalyse durchgeführt: Entformungsrichtung, dann Hinterschnitterkennung über die NX-eigenen Formenbau-Tools, wobei die gemeldeten Hinterschnitte und Rippen dem interaktiven Ergebnis entsprachen. Die reine NX-Seite dieser Aufgabe beschreiben wir in unserem Beitrag zur Hinterschnitterkennung in NX. Ein früheres, breiter angelegtes Projekt derselben Art – ein Assistent, der NX-Tools auswählt, ihre Parameter ausfüllt, ausführt und validiert – ist dokumentiert in unserer Fallstudie zu hybrider agentischer KI für Siemens NX.

Agentic CAD und seine Nachbarn auf dieser Website

Mehrere unserer Seiten behandeln KI, die in NX handelt. Sie beschreiben verschiedene Schichten desselben Stacks, und die meisten Projekte nutzen mehr als eine davon.

Was Agentic CAD nicht leistet

Agenten machen einen Assistenten bei mehrstufiger Arbeit leistungsfähiger. Sie machen ihn nicht zum Konstrukteur, und sie heben die Grenzen von NX oder der API nicht auf. Diese Grenzen nennen wir im ersten Gespräch.

Für Prüfungen, die laufen, während ein Konstrukteur modelliert, statt auf Anfrage, ist der ereignisgesteuerte Live Model Check Assistant das bessere Muster.

Menschliche Bestätigung und Kontrolle

Mehr Agenten dürfen nicht weniger Kontrolle bedeuten. Welche Tools frei laufen und welche auf den Ingenieur warten, ist eine Konfigurationsentscheidung pro Tool, die wir vor dem Pilotprojekt mit Ihnen treffen, kein Standardwert, von dem wir hoffen, dass er stimmt.

• Lese- und Lookup-Tools laufen frei. Geometrie auflisten, die Wissensdatenbank abfragen und Bilder aufnehmen ändert nichts am Teil.
• Jede Änderung ist ein Undo-Schritt. Jedes verändernde Tool setzt seine eigene sichtbare Undo-Markierung; eine ganze Skizze zählt als ein Schritt, ein abgespieltes Journal ebenfalls.
• Bestätigung, wo Sie sie wollen. Verändernde Tools können das OK des Ingenieurs erfordern, und der Coder startet erst nach Zustimmung des Ingenieurs, weil er Minuten brauchen kann und neuen Code schreibt.
• Nichts Verborgenes. Jeder Tool-Aufruf ist mit Argumenten, Ergebnis, der berührten Geometrie und Laufzeit sichtbar, und jede Modellanfrage wird protokolliert.
• Ihre Berechtigungen als Grundlage. Die Tools laufen in der eigenen NX-Sitzung des Ingenieurs, unter seiner Lizenz und seinen Datenberechtigungen.

Deployment-, Daten- und Hosting-Optionen

Ihre Teiledateien verlassen Ihr Netzwerk nicht, damit die Agenten mit ihnen arbeiten können. Ein Modell erreicht nur, was ein Tool zurückgibt: Feature-Namen, IDs, Messwerte, Prüfergebnisse und, wo Sie es erlauben, ein Bild eines Blatts oder einer Ansicht. Der Werkzeugkatalog, die Logs und die Anbindung der Wissensdatenbank laufen auf Ihrer Infrastruktur; der Wissens-Connector ist ein kleiner Container, der in Ihrem Netzwerk oder neben der Wissensdatenbank läuft.

Wo die Modelle laufen, wird pro Projekt entschieden. Claude-Modelle sind direkt bei Anthropic und über Cloud-Anbieter mit EU-Regionen verfügbar; der Assistent kann Modelle auch in Deutschland oder On-Premise betreiben. Da die NX-Tools und die Wissensdatenbank MCP sprechen, kann dieselbe Tool-Schicht ein lokales Modell bedienen, wenn nichts das Haus verlassen darf. Welche Rollen ein kleineres lokales Modell gut trägt, testen wir an Ihren Aufgaben, bevor wir es zusagen. Den Hintergrund zu souveränen Setups liefert unser Leitfaden zu souveräner agentischer KI in der europäischen Fertigung.

Wie wir mit Ihrem Team einen Agentic-CAD-Assistenten bauen

Der größte Aufwand steckt nicht in den Agenten. Er steckt in den Tools und den Regeln: welche NXOpen-Funktionen bereits existieren, wo Ihre Standards liegen und wie aktuell sie sind, und welche Teilezustände nie angetastet werden dürfen. Das kommt zuerst.

1. Quick-Scan mit Vor-Ort-Tag. Bis zu zwei Workshop-Tage, insgesamt fünf Tage: Kandidaten-Aufgaben, Ihre Daten und Standards, Rahmenbedingungen für das Hosting; das Ergebnis ist eine Aufgabe für den Einstieg und ein Projektplan.
2. Tool-Katalog. Ihr vorhandener NXOpen-Code, Ihre Journale und Checker werden zu typisierten Tools. Lese-Tools gehen zuerst live, damit das Team sieht, dass der Assistent seine Teile versteht, bevor er eines verändert.
3. Wissensanbindung. Der Recherche-Agent wird an die Wissensdatenbank mit NX-Dokumentation und Ihrem freigegebenen internen Material angebunden.
4. Rollen und Modelle. Welche Agenten die Aufgabe braucht, welches Modell und welchen Aufwand jeder erhält und welche Limits pro Anfrage gelten.
5. Regeln für den Prüfer. Ihre Standards, schriftlich festgehalten oder aus Referenzzeichnungen abgeleitet, werden zur Checkliste des Prüfers.
6. Pilot. Eine kleine Gruppe von Ingenieuren an echten Teilen, gemessen an erledigten Aufgaben, Befunden des Prüfers, Korrekturen und Undos.
7. Rollout. Mehr Tools, mehr Nutzer, und wiederkehrende Coder-Journale werden zu geprüften Katalog-Tools.

Starten Sie mit einer Aufgabe in Ihrem NX

Wir starten nicht mit fünf Agenten und vierzig Tools. Wir starten mit einer mehrstufigen Aufgabe, die Ihr Team wiederholt, dem NXOpen-Code, den Sie dafür schon haben, und einem Teil, das Ihren echten Teilen ähnelt – und wir fügen eine Rolle erst hinzu, wenn die Aufgabe zeigt, dass sie nötig ist.