🤖 AI

CAX-Agent: A Lightweight Agent Harness for Reliable APDL Automation

Dieser Beitrag stellt CAX-Agent vor, ein leichtgewichtiges Framework zur Erhöhung der Zuverlässigkeit der APDL-Automatisierung durch Implementierung einer mehrschichtigen Architektur mit einer Wiederherstellungsleiter, wobei empirische Benchmarks zeigen, dass eine modellgetriebene Regeneration die regelbasierten oder ohne Wiederherstellung arbeitenden Strategien bei der Aufgabenabschlussrate und der Reduktion von Eingriffen deutlich übertrifft.

Ursprüngliche Autoren: Chenying Lin, Yichen Hai, Yi He, Ran Wang, Haiyan Qiang, Liang Yu

Veröffentlicht 2026-05-18

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Chenying Lin, Yichen Hai, Yi He, Ran Wang, Haiyan Qiang, Liang Yu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, einem brillanten, aber leicht impulsiven Architekten (der KI) beizubringen, eine Brücke mit Hilfe eines sehr strengen, altmodischen Bauhandbuchs (der Software namens MAPDL) zu bauen. Der Architekt ist hervorragend im Erstellen von Bauplänen, doch wenn das Handbuch meldet „Fehler: Balken zu dünn", könnte der Architekt verwirrt sein, versuchen, einen neuen Plan zu schreiben, der denselben Fehler enthält, oder einfach ganz aufgeben.

Diese Arbeit stellt CAX-Agent vor, einen „Baustellenleiter", der zwischen dem Architekten und dem Handbuch sitzt, um sicherzustellen, dass die Brücke tatsächlich gebaut wird.

Hier ist die Aufschlüsselung, wie es funktioniert und was die Forscher herausfanden, unter Verwendung einfacher Analogien:

1. Das Problem: Die „Einmal-und-fertig"-Falle

Normalerweise versucht eine KI, wenn Sie sie bitten, Code für eine Simulation zu schreiben, es einmal. Wenn der Computer „Fehler" meldet, gerät die KI oft in Panik oder stoppt. Das gesamte Projekt scheitert.

Die Sichtweise der Arbeit: Ohne einen Manager, der Fehler auffängt, stoppt ein einziger Fehler die gesamte Pipeline.

2. Die Lösung: Die „Agent-Harnisch" (Der Baustellenleiter)

Anstatt die KI wild laufen zu lassen, bauten die Autoren einen Harnisch. Stellen Sie sich dies als einen strengen Baustellenleiter vor, der:

Die KI beobachtet: Er sieht, was die KI schreibt.
Das Handbuch prüft: Er führt den Code aus und liest die Fehlermeldungen.
Den nächsten Zug entscheidet: Wenn ein Fehler auftritt, entscheidet der Manager, ob er ihn mit einer schnellen Regel beheben oder die KI bitten soll, es erneut zu versuchen.

Das System besteht aus drei Schichten:

Die KI (Der Architekt): Schreibt den Code.
Der Harnisch (Der Manager): Organisiert die Arbeit, prüft auf Fehler und verwaltet Wiederholungsversuche.
Der Solver (Das Bauunternehmen): Baut die Simulation tatsächlich.

3. Die „Rettungsleiter" (Wie sie Fehler beheben)

Wenn das Bauunternehmen auf ein Hindernis stößt, hat der Manager eine „Leiter" von Möglichkeiten, um es zu beheben, beginnend mit den einfachsten bis zu den schwierigsten:

Sprosse 1 (Regeln): „Oh, das Netz ist zu groß? Lassen Sie uns die Zahlen einfach automatisch kleiner machen." (Wie ein vorgefertigter Spickzettel).
Sprosse 2 (Modell): „Das Fehlerprotokoll besagt, dass der Balken falsch ist. KI, lies diesen Fehler und schreibe den Plan selbst um."
Sprosse 3 (Kontext): „Lassen Sie uns der KI mehr Details über das Problem geben."
Sprosse 4 (Mensch): „Okay, wir stecken fest. Rufen Sie einen menschlichen Ingenieur."

4. Das Experiment: Ein Rennen zwischen drei Teams

Die Forscher testeten drei verschiedene Methoden zum Umgang mit Fehlern an 50 einfachen Brückenbauaufgaben (Balken, Platten und Zylinder). Sie führten jede Aufgabe dreimal aus, um sicherzugehen.

Team A (Keine Wiederherstellung): Die KI versucht es einmal. Wenn sie scheitert, stoppt sie.
- Ergebnis: Wie ein Fahrer, der über ein Schlagloch fährt und sofort das Auto anhält. Sie scheiterten häufig.
Team B (Nur Regeln): Die KI versucht es einmal. Wenn sie scheitert, wendet der Manager eine strikte, vordefinierte Regel an, um es zu beheben (z. B. „Wenn Fehler X, dann Y").
- Ergebnis: Besser als Team A, aber die Regeln waren zu starr. Manchmal passte der „Spickzettel" nicht zum spezifischen Problem.
Team C (Nur Modell): Die KI versucht es einmal. Wenn sie scheitert, zwingt der Manager die KI, die Fehlermeldung zu lesen und den Code selbst umzuschreiben, bis zu dreimal.
- Ergebnis: Dieses Team gewann mit großer Mehrheit. Die KI war intelligent genug zu verstehen, warum sie scheiterte, und es kreativ zu beheben.

5. Die Ergebnisse: Warum „Nur Modell" gewann

Die Forscher ließen zwei menschliche Gutachter die finalen Baupläne bewerten (blind, damit sie nicht wussten, welches Team sie erstellt hatte) und sie punkten.

Erfolgsrate: Team C (Nur Modell) hatte 93 % Erfolg. Team B (Regeln) hatte 77 % Erfolg, und Team A (Keine Wiederherstellung) nur 69 %.
Autonomie: Team C erledigte die Arbeit, ohne dass ein Mensch eingreifen musste, in 84 % der Fälle. Team B und Team A benötigten menschliche Hilfe in 100 % der Fälle, wenn sie scheiterten.
Der „menschliche" Faktor: Das Team „Nur Regeln" benötigte tatsächlich einen Menschen, um die Korrektur zu bestätigen, bevor es erneut versuchte, weshalb ihre „Null-Eingriff"-Bewertung 0 betrug. Das KI-gesteuerte Team reparierte Dinge selbstständig.

6. Der Haken (Einschränkungen)

Die Autoren sind ehrlich bezüglich der Grenzen ihrer Studie:

Einfache Aufgaben: Sie testeten nur einfache, geradlinige Strukturen (wie gerade Balken). Sie testeten keine komplexen, verdrehten oder „unordentlichen" realen Ingenieurprobleme.
Spezifische Werkzeuge: Sie verwendeten nur eine spezifische Software (MAPDL) und ein spezifisches KI-Modell.
Das „Dünne-Wand"-Problem: Selbst das gewinnende Team hatte Schwierigkeiten mit sehr dünnen, empfindlichen Teilen, die schwer zu vernetzen sind (wie ein sehr dünnes Blech). Die KI konnte manchmal nicht herausfinden, wie sie das Gitter für diese spezifischen Formen erstellen sollte.

Das Fazit

Diese Arbeit beweist, dass Sie, wenn Sie eine KI dazu bringen wollen, Ingenieursimulationen zu automatisieren, ihr nicht einfach erlauben können, Code zu schreiben und auf das Beste zu hoffen. Sie benötigen einen Manager (den Harnisch), der die KI zwingt, ihre eigenen Fehler zu lesen und es erneut zu versuchen.

Während einfache „Spickzettel" (Regeln) ein wenig helfen, ist es der einzige Weg, ein System zu erhalten, das zuverlässig funktioniert, ohne dass ein Mensch jedes Mal die Hand halten muss, wenn es strauchelt, die KI ihre eigenen Fehler zu denken und ihren Plan neu zu schreiben.

Technische Zusammenfassung: CAX-Agent für zuverlässige APDL-Automatisierung

Problemstellung

Große Sprachmodelle (LLMs), die für die Finite-Elemente-Simulation in der mechanischen Analyse und Konstruktion (MAPDL) eingesetzt werden, sehen sich erheblichen Zuverlässigkeitsproblemen gegenüber. Zwar können LLMs Code generieren, doch fehlt es ihnen oft an der für ingenieurtechnische Workflows erforderlichen strukturierten Ausführungskontrolle, der Werkzeugkapselung und den Fehlerwiederherstellungsmechanismen. In Simulationspipelines sind Laufzeitfehler – wie etwa Gittergenerierungsfehler, Konvergenzprobleme oder fehlende Ergebnisse – selbst bei strukturell einfachen Aufgaben häufig. Ohne explizite Wiederherstellungsmechanismen führt ein einzelner Fehler zum Abbruch der gesamten Pipeline. Bestehende Agent-Frameworks erwarten häufig, dass das LLM seine eigene Ausführung verwaltet, was nicht das notwendige ingenieurtechnische Gerüst für eine robuste, wiederholbare Automatisierung bietet. Es fehlt an kontrollierten, empirischen Belegen, die verschiedene Wiederherstellungsrichtlinien (z. B. regelbasiert versus modellgesteuert) unter wiederholten Bedingungen mit menschlich validierten Ergebnissen vergleichen.

Methodik

Systemarchitektur: CAX-Agent

Die Arbeit stellt CAX-Agent vor, ein leichtgewichtiges, domänenspezifisches Agenten-Steuerungssystem, das speziell für die APDL-Automatisierung entwickelt wurde und nicht auf die Anpassung eines generischen Frameworks setzt. Die Architektur ist in drei Schichten gegliedert:

LLM-Dienste-Schicht: Umfasst ein lokales, leichtgewichtiges Modell (Qwen-27B) für eine schnelle Erstgenerierung und eine externe API mit hoher Leistungsfähigkeit (Claude Sonnet 4.6) für komplexe Schlussfolgerungen und Reparaturen.
Agenten-Steuerung (Orchestrator): Dieses Middleware-System verwaltet Werkzeug-Lebenszyklen, Workflow-Zustände und Fehlerdiagnose. Entscheidend ist, dass der Orchestrator – und nicht das LLM – die Wiederholungsquoten, die Werkzeugverteilung und die Stoppbedingungen kontrolliert. Er implementiert eine Wiederherstellungsleiter, die von deterministischen Regel-Patches zu modellgesteuerten Neugenerierungen, Kontextanreicherung und schließlich menschlichem Eingreifen eskaliert.
Solver-Backend: Eine einheitliche Schnittstelle zur Verbindung mit MAPDL-Engines (PyMAPDL, CLI oder Fallback-Modi).

Experimentelles Design

Die Studie bewertet drei unterschiedliche Wiederherstellungsstrategien anhand eines Benchmarks mit 50 Standardaufgaben für Strukturmechanik (Balken, Platten, Zylinder unter statischer, modalen und thermischer Belastung). Die Aufgaben sind absichtlich einfach gehalten, um den Effekt der Wiederherstellungsrichtlinie von der Aufgabenschwierigkeit zu isolieren.

Keine Wiederherstellung: Einmalige Ausführung ohne Reparaturversuche.
Nur Regeln: Deterministische, log-basierte Korrektur mittels vier String-Transformationsregeln (z. B. Verdopplung der Elementgröße bei Gitterfehlern, Einfügen von Zeitschritten bei Konvergenzproblemen) ohne zusätzliche Modell-Schlussfolgerungen.
Nur Modell: Fehlerprotokoll-konditionierte Neugenerierung durch das Modell mit begrenzten Wiederholungen (bis zu 3 erzwungene Wiederholungs-Runden), wobei das LLM das Fehlerprotokoll liest, den Fehler diagnostiziert und das Skript neu generiert.

Evaluierungsmetriken

Jeder der insgesamt 450 Testläufe (50 Aufgaben × 3 Strategien × 3 Wiederholungen) wurde anhand folgender Metriken bewertet:

Aufgaben-Score ( $t_i$ ): Ein vom Menschen bewerteter Score (0–4) für Richtigkeit und Vollständigkeit des Ausgabebildes.
Autonomie-Score ( $a_i$ ): Ein vom System abgeleiteter Score (0–3), basierend darauf, ob ein manueller Eingriff erforderlich war.
Wiederherstellungs-Effizienz-Score ( $e_i$ ): Basierend auf Wiederholungszahlen und Solver-Ergebnissen.
Gesamtscore ( $q_i$ ): Die Summe der oben genannten Werte ( $t_i + a_i + e_i$ ), reichend von 0 bis 10.
Abschlussrate: Binäre Metrik, die angibt, ob mindestens ein Nachverarbeitungsbild erzeugt wurde.
Statistische Analyse: Paarweise Vergleiche unter Verwendung von Cliff's $\delta$ (Effektgröße) und dem Mann–Whitney-U-Test, wobei die Übereinstimmung zwischen den Bewertenden durch den quadratisch gewichteten Cohen's $\kappa$ (0,84) gemessen wurde.

Hauptbeiträge

CAX-Agent-Architektur: Eine dreischichtige, MAPDL-native Agenten-Steuerung mit einer Wiederherstellungsleiter und einem orchestriererzentrierten Kontrollmodell, das die semantische Reparatur (LLM) von der Ausführungskontrolle (Steuerung) trennt.
Kontrollierte empirische Evaluation: Eine rigorose, wiederholte Vergleichsstudie dreier Wiederherstellungsstrategien an 50 standardisierten APDL-Aufgaben unter Verwendung einer blinden menschlichen Bewertung und einer Übereinstimmungsvalidierung zwischen den Bewertenden.
Empirische Evidenz: Der Nachweis, dass modellgesteuerte Wiederherstellung sowohl regelbasierte Reparaturen als auch Baselines ohne Wiederherstellung bei Abschlussraten, Ausgabequalität und Autonomie deutlich übertrifft.

Ergebnisse

Die Strategie Nur Modell erzielte in allen Metriken eine überlegene Leistung im Vergleich zu Nur Regeln und Keine Wiederherstellung:

Abschlussrate: Nur Modell (0,9267) schnitt signifikant besser ab als Nur Regeln (0,7733) und Keine Wiederherstellung (0,6933). Die 95%-Konfidenzintervalle für Nur Modell überlappten nicht mit den Baselines.
Aufgabenqualität: Nur Modell erreichte einen durchschnittlichen Aufgaben-Score von 3,59/4, verglichen mit 3,17/4 für Nur Regeln und 2,74/4 für Keine Wiederherstellung.
Gesamtscore: Nur Modell erzielte 9,16/10, signifikant höher als Nur Regeln (7,03/10) und Keine Wiederherstellung (5,60/10).
Rate ohne Eingriff: Nur Modell erreichte 0,84, während Nur Regeln 0,00 erreichte. Die Arbeit stellt fest, dass der Null-Score von Nur Regeln seine Designeigenschaft widerspiegelt, die einen menschlichen Bestätigungsschritt vor der Neuausführung erfordert und somit einen vollständig autonomen Betrieb verhindert.
Effektgrößen: Zwischen Nur Modell und den anderen Strategien wurden große Effektgrößen beobachtet (Cliff's $\delta$ = 0,81–0,87), was auf eine hohe Wahrscheinlichkeit hindeutet, dass ein zufällig ausgewählter Nur-Modell-Lauf einen Nur-Regeln-Lauf übertrifft.

Fehleranalyse: Restfehler konzentrierten sich auf statische strukturelle Einstellungen, insbesondere solche mit dünnwandigen oder gittersensitiven geometrischen Merkmalen. Es wurde festgestellt, dass deterministische Regeln für langschwänzige Solver- und Skriptpfadfehler unzureichend sind, während modellgesteuerte Reparaturen sich an breitere Fehlermuster anpassten.

Bedeutung und Behauptungen

Die Arbeit behauptet, dass CAX-Agent zeigt, wie ein leichtgewichtiges, domänenspezifisches Steuerungssystem MAPDL-Simulationen von verstreuten, unzuverlässigen LLM-Aufrufen in einen standardisierten, nachvollziehbaren und wiederholbaren ingenieurtechnischen Workflow verwandeln kann.

Zu den wichtigsten Erkenntnissen gehören:

Notwendigkeit von Wiederherstellung: Explizite Wiederherstellungsmechanismen sind zentral für die Systemzuverlässigkeit; ohne sie führt ein einzelner Fehler zum Abbruch von Pipelines.
Überlegenheit modellgesteuerter Reparaturen: Obwohl deterministische Regeln eine gewisse Verbesserung gegenüber keiner Wiederherstellung bieten, erhöhen sie die Ausgabequalität nicht zuverlässig oder erreichen keine volle Autonomie. Modellgesteuerte Wiederherstellung ist die praktischste Standardstrategie für den aktuellen CAX-Einsatz.
Orchestrator-zentrierte Kontrolle: Die Trennung der Schlussfolgerungen des LLM von der Ausführungskontrolle der Steuerung (Wiederholungsquoten, Stoppbedingungen) bietet Verhaltensgarantien, die allein durch Prompting nicht erreicht werden können.
Methodologischer Beitrag: Die Studie liefert eine reproduzierbare Vorlage für die empirische Evaluierung von Steuerungen (kontrollierte Ablation, wiederholte Läufe, mehrdimensionale Bewertung), die auf andere Steuerungskomponenten und Simulations-Backends angewendet werden kann.

Die Autoren bewahren bezüglich des Umfangs Bescheidenheit und stellen fest, dass der Benchmark einfache Geometrien und lineare Elastizität verwendet. Sie geben an, dass eine Validierung an größeren, diverseren Benchmarks und über mehrere Solver-Backends hinweg erforderlich ist, bevor eine praktische Implementierung in komplexen industriellen Umgebungen möglich ist. Dennoch wird die Kernaussage – dass modellgesteuerte Wiederherstellung unter kontrollierten Bedingungen regelbasierte und nicht-wiederherstellende Ansätze übertrifft – als robust und statistisch signifikant dargestellt.