AIcodeIT als Schnittstelle zum Engineering-Wissen

AIcodeIT als Schnittstelle zum Engineering-Wissen

Multi-Agenten-Systeme für die teilautomatisierte Auslegung im Application Engineering

Management Summary

Unternehmen des Anlagen- und Produktengineerings stehen vor einem Dilemma: Das Wissen für kundenspezifische Auslegungen ist vorhanden – verteilt auf wenige Fachexperten, komplexe Simulationswerkzeuge und lizenzbeschränkte Software. Gleichzeitig steigen Anfragenvolumen und Änderungsdynamik. Dieses Whitepaper beschreibt einen Multi-Agenten-Ansatz, der Engineering-Wissen, Vorgehensmuster und Werkzeuge über eine einheitliche Schnittstelle verfügbar macht – auditierbar, schrittweise einführbar und ohne Vertrauensvorschuss in „eine KI, die alles kann“.

1. Problemstellung: Der Engpass im Application Engineering

Die Anpassung bestehender Produkte und ihre Kombination zu Systemen sind komplexe technische Aufgaben, die typischerweise Application Engineers gemeinsam mit Fachexperten der Entwicklung lösen. In der Praxis zeigen sich fünf wiederkehrende Probleme:

• Begrenzte Ressourcen: Für Kundenanfragen und Auslegungen steht zu wenig qualifizierte Kapazität zur Verfügung.
• Komplexitätsfalle der Tools: Die genauesten Werkzeuge erfordern eigene Experten. Falsche Parameter oder unberücksichtigte Werkzeugeigenheiten führen zu unbrauchbaren Ergebnissen.
• Lizenz- und Pflegeproblematik: Leistungsfähige Tools stehen nicht jedem zur Verfügung; einfache Tools werden nicht gepflegt oder passen nicht zum Anwendungsfall.
• Ungeprüfte Standardlösungen: Aus Zeitdruck werden Standardlösungen kombiniert, ohne deren Eignung zu verifizieren.
• Änderungsdynamik: Anforderungen ändern sich im Kundendialog schnell – die Auslegung wird nicht nachgezogen.

2. Lösungsansatz: Eine Software als Schnittstelle

Die Kernidee ist eine Software, die Wissensquellen, Vorgehensmuster und (Simulations-)Werkzeuge orchestriert und die Auslegung teilautomatisiert:

• Application Engineers greifen auf die Werkzeuge der Experten und deren Wissen zu.
• Auslegungen werden analysiert; Verbesserungsvorschläge, Fehler und Abweichungen von Anforderungen werden automatisch erkannt.
• Stücklisten und Spezifikationen werden automatisiert erstellt.
• Standardisierte Auslegungen und Berechnungen laufen in definierten Workflows – mit konstanter Qualität, während Detailfragen gezielt vertieft werden können.

3. Architektur in AIcodeIT: Multi-Agenten statt Monolith

Das Multi-Agenten-Konzept von AIcodeIT bildet den Lösungsansatz direkt ab:

• Spezialagenten pro Wissensdomäne: Sie beherrschen Daten, Dokumente, Vorgehensmodelle und Werkzeuge ihrer Domäne und lassen sich gezielt testen und trainieren.
• Integrationsexperten für komponentenübergreifende Themen – analog zu den Spezialagenten, auf Systemebene.
• Moderatoren als Kommunikationsschnittstelle zum Anwender: Sie übersetzen Anfragen in Workflows, Experten- oder Teamanfragen.
• Workflows mit Quality Gates: Sie sichern Abläufe und kombinieren LLMs, Agenten und klassische Programmierung – deterministisch, wo Determinismus gefragt ist.

3.1 Die Anatomie eines Spezialagenten

Jeder Agent wird im Framework als eigenständiger, wiederverwendbarer Baustein konfiguriert. Fünf Elemente bestimmen seine Fähigkeiten:

• Basisdaten: Name, Rolle, Ziel und fachlicher Hintergrund – die Identität des Agenten, unabhängig vom konkreten Auftrag.
• Modellwahl: Jeder Agent kann auf einem eigenen Server mit einem zur Aufgabe passenden LLM betrieben werden – von Frontier-Modellen bis zu Open-Source-Modellen, lokal oder extern.
• Prompt-Struktur: Anweisungen folgen einem festen Aufbau: Scope, Eingaben & Ausgaben, Tool-Hierarchie, Tool-Grenzen, Ablauf, harte und weiche Regeln, Fehlerbehandlung und Eskalation. Das erleichtert Wartung und Fehlersuche.
• Wissensbasis: Eine Vektordatenbank mit Literatur, Arbeitsanweisungen und Domänenwissen. Jeder Agent greift nur auf das Wissen zu, das für seine Domäne sinnvoll ist; gemeinsame Prozessvorgaben lassen sich ergänzen.
• Skills und Tools: Wiederverwendbare Vorgehensweisen werden als Markdown-Dateien bei Bedarf geladen. Tools erlauben Simulationen, Datenbankzugriffe und Berechnungen. Jeder Agent erhält nur, was er für seine Aufgabe benötigt.

Entscheidend ist die Trennung: Die Konfiguration beschreibt den Spezialisten allgemein – konkrete Anforderungen, Werte und Prioritäten werden erst mit dem jeweiligen Arbeitsauftrag übergeben. So bleibt derselbe Agent über Projekte und Teams hinweg wiederverwendbar, ohne dass seine Identität neu beschrieben werden muss.

Konfiguration eines Agenten im AIcodeIT-Framework

3.2 Zwei Wege der Interaktion

Das Framework unterstützt zwei Formen der Zusammenarbeit:

• Direkter Dialog: Die Anfrage geht über die API an das Team. Ein Moderator kategorisiert die Aufgabe, ergänzt Kontext und legt Ziele sowie erste Verantwortlichkeiten fest. Die Agenten arbeiten anschließend frei im Rahmen ihrer Fähigkeiten. Dieser Weg eignet sich für explorative Fragestellungen, bei denen Rückfragen und Teilaufgaben erst während der Bearbeitung entstehen.
• Definierter Workflow: Alternativ lässt sich ein klarer Ablauf vorgeben – kombinierbar aus Code-Elementen, LLM-Aufrufen, Einzelagenten und vollständigen Teamaktionen. Code-Elemente halten den Ablauf transparent; protokollierte Agentenaktionen machen ihn überprüfbar. Auditierbarkeit entsteht dabei nicht automatisch durch mehrere Agenten, sondern durch dokumentierte Eingaben, Tool-Aufrufe, Ergebnisse und Freigaben.

Der Ansatz ist praxiserprobt: Im AIcodeIT-Framework wurde ein Agententeam aus fünf Spezialisten aufgebaut – PowerElectronicDesignEngineer (Systemauslegung), ControlEngineer (Regelung), MatlabSimulinkExpert (Simulation) sowie je ein Experte für Induktivitäten und Kondensatoren. Das Team hat die Auslegung eines Buckconverters durchgeführt.

Anforderungen: 48 V auf 12 V, 20 A nominal, 100 kHz Schaltfrequenz, 10 % Stromripple, 5 % Spannungsripple. Induktivität und Kapazität sollten so klein wie nötig gewählt werden.

Dokumentierte Ergebnisse (verwendete Modelle: Qwen3.6-27B): L = 46 µH, C = 18,84 µF, PI-Regler Kp = 0,627, Ki = 4734 s⁻¹. Die Regelungsparameter zeigen: Die Werte wurden am Arbeitspunkt auch hinsichtlich der Regelung optimiert.

Anschlussaufgabe: Auf Basis des L-Werts legte das Team eine Spule mit mindestens 27 A Sättigungsstrom aus – drei Kernvarianten, wobei die Verringerung der Verluste Vorrang vor der Baugröße hatte:

Merkmal	Variante 1: Ferrit-Kern (optimal für Verluste)	Variante 2: Hochfluss-Kern (kompakt)	Variante 3: Eisenpulver-Kern (Kosten/Verfügbarkeit)
Kern	Ferroxcube 3C90, E55/28/20	Magnetics High Flux, H110001	Micrometals Iron Powder, I55-52
Material	Ferrit (niedrige Kernverluste)	Nickel-Eisen (hohe Sättigung)	Eisenpulver (verteilter Spalt)
Luftspalt	2,4 mm	—	—
Windungen	118	42	65
Sättigungsstrom	28,5 A (bei 20,98 A noch > 90 % L)	45 A	32 A
Verluste (Kern + Kupfer)	ca. 0,8 W	ca. 1,5 W	ca. 2,2 W
Abmessungen	55 × 28 × 20 mm	28 × 28 × 28 mm (geschätzt)	55 × 55 × 25 mm

Einordnung: Die Tabelle gibt die dokumentierte Agentenausgabe wieder, keine verifizierten Bauteildaten. Vor einer Bauteilauswahl sind Herstellerdaten, Sättigungsverhalten und Verluste fachlich zu prüfen. Genau darin liegt der Nutzen: Aus der Anforderung entsteht eine quantifizierte Liste prüfbarer Entwürfe – die Validierung bleibt Aufgabe der Fachkräfte

5. Vorteile des Ansatzes

• Flexibel und erweiterbar: Start in einer Subdomäne oder Komponente; Erweiterung um weitere Experten, Workflows und Tools jederzeit möglich.
• Passgenaue Modellwahl: Jedem Agenten wird das benötigte LLM zugeordnet – Frontier-Modelle (Claude, ChatGPT) oder Open Source (z. B. Qwen), lokal oder extern. Bessere Modelle migrieren pro Agent nach.
• Auditierbarkeit: Jeder Agent ist ein prüfbarer Spezialist. Agententätigkeiten, Workflow-Schritte, Tool-Aufrufe und Moderatorenentscheidungen werden dokumentiert.
• Vertrauen durch Zurückhaltung: KI nur dort, wo sie gebraucht wird – alles andere läuft über bewährte, validierte Unternehmenswerkzeuge.
• Wissen wächst mit: Neue Dokumente und Firmenwissen werden den Agenten leicht bereitgestellt. Fachexperten können Vorgehensweisen als Skills übergeben und an den Agenten testen – im Idealfall entsteht „ihr“ Fachassistent.

6. Umsetzungsfahrplan

1. Bestandsaufnahme: Sichtung vorhandener Wissensquellen, Tools und Vorgehensmodelle.
2. Minimaler Start: Ein bis zwei Fachexperten als Spezialagenten abbilden und ins Framework integrieren.
3. Erster Anwendungsfall: Aus dem minimalen Setup entsteht sehr schnell ein produktiv nutzbarer Fall.
4. Skalierung: Schrittweise Erweiterung um Domänen, Integrationsexperten, Workflows und Quality Gates.

7. Fazit

Engineering-Wissen muss nicht in Köpfen und Lizenzdatenbanken warten. Mit einem Multi-Agenten-System als Schnittstelle wird es dort verfügbar, wo Kundenanfragen entstehen – auditierbar, erweiterbar und ohne Abhängigkeit von einer einzelnen KI. Der Einstieg ist klein, der Hebel groß.

Interesse an einem Pilot? Wir starten mit einem Fachexperten Ihrer Wahl – und liefern in wenigen Wochen einen ersten Anwendungsfall.