---
title: "Computer Use vs. BIM API: Wie KI-Agenten CAD steuern"
description: "Können KI-Agenten CAD steuern? Computer Use auf der GUI, Tool-API oder MCP in Desktop-BIM und ein Gebäudeprogramm, das ein BIM-Kernel prüft, im Vergleich."
url: https://buildify.cz/de/computer-use-vs-bim-api
source: https://buildify.cz/computer-use-vs-bim-api.de.md
language: de-DE
publisher: Buildify (Buildify Digital s.r.o.)
dateModified: 2026-09-27
keywords: ["Computer Use CAD", "KI-Agent CAD steuern", "KI-Agent BIM API", "MCP Server BIM", "LLM Tool Calling BIM", "programmierbares BIM-Modell", "BIM-Kernel Prüfung", "GUI-Automatisierung vs API", "computer use CAD", "AI agent BIM API"]
license: "Volně citovatelné s uvedením zdroje / freely quotable with attribution"
---

# Computer Use vs. BIM API: drei Wege, wie ein KI-Agent ein Modell baut

> Ein KI-Agent kann sich durch eine CAD-Oberfläche klicken, die Tool-API einer Desktop-BIM-Software aufrufen oder das Gebäude als Programm schreiben, das ein BIM-Kernel ausführt und prüft. Alle drei Wege liefern ein Modell. Sie unterscheiden sich darin, was der Agent sieht, was ein Schritt kostet, wie Fehler zurückkommen und ob sich das Ergebnis wiederholen lässt.

- In BIM Harness schreibt der Agent ein Skript in einem Gebäudedialekt mit mehr als hundert Verben
- Ein Einfamilienhaus steht auf dem Kernel in rund 7 Sekunden - langsam ist das Sprachmodell
- Fehler kommen als benannte Befunde wie door.obstructed zurück, nicht als Screenshot zum Deuten
- Dasselbe Skript auf demselben Kernel baut dasselbe Modell

Zugang zu BIM Harness erhalten: https://buildify.cz/de/bim-harness#waitlist

## Können KI-Agenten CAD steuern?

> Computer Use automatisiert die Bedienung von Software. BIM Harness macht das Gebäudemodell selbst programmierbar: Der Agent schreibt ein Gebäudeprogramm, ein BIM-Kernel führt es aus und liefert benannte Befunde zurück.

Ja, KI-Agenten können CAD steuern - und zwar auf mehr als eine Weise. Ein multimodales Modell kann den Bildschirm betrachten und Maus und Tastatur bedienen wie ein Mensch. Ein Modell kann Funktionen aufrufen, die eine Desktop-BIM-Software über ein Plugin oder einen Model-Context-Protocol-Server (MCP) bereitstellt. Oder ein Modell schreibt das Gebäude direkt als Code in einer Fachsprache, und ein BIM-Kernel macht daraus ein Modell.

Das sind keine konkurrierenden Marken derselben Idee. Sie liegen auf verschiedenen Ebenen. Die erste automatisiert die Benutzeroberfläche. Die zweite automatisiert die Software dahinter, Aufruf für Aufruf. Die dritte verlagert die Arbeit dorthin, wo das Modell tatsächlich definiert ist: in das Objektmodell und seine Regeln. Welcher Weg passt, hängt davon ab, was die Software anbietet und was Sie zurückbekommen müssen.

## Drei Wege, verglichen an dem, was für ein Modell zählt

Verglichen wird der Weg, nicht ein bestimmtes Produkt. Jeder Weg lässt sich gut oder schlecht umsetzen; die Tabelle zeigt, was jeder davon dem Agenten strukturell zur Verfügung stellt.

| Aspect | Computer Use auf der GUI | Tool-API / MCP von Desktop-BIM | Gebäudeprogramm + BIM-Kernel |
| --- | --- | --- | --- |
| Was der Agent erzeugt | Klicks, Tastatureingaben und Dialogeingaben | Eine Folge von Tool-Aufrufen | Ein Skript in einem Gebäudedialekt |
| Was der Agent sieht | Screenshots der Oberfläche | Rückgabewerte jedes Aufrufs | Benannte Befunde eines Prüfers, getrennt in Autoren- und Engine-Befunde |
| Kosten pro Schritt | Ein Modellaufruf pro Bildschirminteraktion | Ein Modellaufruf pro Tool-Aufruf | Der Kernel führt das ganze Skript aus; das Modell wird zum Schreiben und Reparieren aufgerufen |
| Fehlerbehebung | Fehlklick oder unerwarteten Dialog bemerken, dann erneut versuchen | Fehlermeldung des Aufrufs lesen | Benannten Befund lesen (door.obstructed, clash.hard) und gezielt ändern |
| Wiederholbarkeit | Hängt von Bildschirmzustand, Fensterlayout und Timing ab | Hängt von Aufrufreihenfolge und Anwendungszustand ab | Dasselbe Skript auf demselben Kernel baut dasselbe Modell |
| Versionierung | Eine Aufzeichnung von Aktionen | Ein Protokoll von Aufrufen | Eine Textdatei, die Sie vergleichen, lesen und bearbeiten können |
| Wo es am besten passt | Software, die ihre Funktionen nur über eine GUI anbietet | Steuerung einer bestehenden Desktop-BIM-Installation | Ein ganzes Gebäude samt Systemen generieren und regenerieren |

Kostenfaktoren nennen wir hier bewusst nicht. Sicher ist die Struktur: Ein GUI-Weg bezahlt jede Interaktion, ein Programm-Weg bezahlt das Schreiben des Programms.

## Computer Use: wertvoll, wo die GUI die einzige Tür ist

Mit Computer Use bedient ein Modell Software wie ein Mensch: Screenshot aufnehmen, entscheiden, wohin geklickt wird, Menü öffnen, Dialog ausfüllen, bestätigen, nächster Screenshot. Für sehr viel Software ist das der einzige Zugang. Alte Werkzeuge, interne Anwendungen und Programme ohne Skriptschnittstelle bieten ihre Funktionen nur über den Bildschirm an. Für sie ist ein Agent, der sehen und klicken kann, ein echter Fortschritt.

Bei Gebäudemodellen kommen die Grenzen von der Oberfläche, nicht vom Agenten. Eine über einen Dialog gesetzte Wand bleibt eine über einen Dialog gesetzte Wand - was passiert ist, erfährt der Agent, indem er wieder Pixel betrachtet. Jeder Schritt ist ein Modellaufruf. Ein unerwartetes Pop-up, eine andere Fenstergröße oder ein langsamer Bildaufbau verändern, was der nächste Screenshot zeigt. Und die Arbeit ist als Folge von Interaktionen festgehalten, nicht als Beschreibung des Gebäudes, die jemand lesen und ändern kann.

## Eine Tool-API oder MCP auf bestehender Desktop-BIM-Software

Der zweite Weg überspringt die Pixel. Die Desktop-Anwendung oder ein Plugin dafür stellt Funktionen wie „Wand erstellen“ oder „Räume auflisten“ bereit, und das Sprachmodell ruft sie als Tools auf. MCP-Server für etablierte Desktop-BIM-Werkzeuge - Autodesk liefert inzwischen einen aus - sind das bekannteste Beispiel für diesen Ansatz. Das ist ein sinnvoller Weg, einen Agenten in einen Workflow zu bringen, der ohnehin in dieser Software stattfindet.

Der Agent bekommt jetzt strukturierte Rückgabewerte statt Screenshots, und das ist eine echte Verbesserung. Die Form der Arbeit bleibt jedoch gleich: Das Modell setzt Aufrufe nacheinander gegen eine laufende Anwendung ab, und das Gebäudemodell existiert nur als der Zustand, den diese Aufrufe hinterlassen. Der Agent arbeitet in einem Werkzeug, das für einen menschlichen Bediener entworfen wurde.

## Ein Gebäudeprogramm, ausgeführt von einem Kernel mit Prüfer

> In BIM Harness schreibt die KI ein Programm, keine Geometrie: ein Skript im Harness-Gebäudedialekt mit Aufrufen wie api.wall, api.space und api.door, das der parametrische Harness-Kernel ausführt und prüft.

Der dritte Weg behandelt das Gebäude als etwas, das man schreibt, nicht als etwas, das man klickt. Der Agent bedient keine Anwendung. Er schreibt ein Skript, der Kernel baut daraus ein parametrisches Objektmodell, und ein Prüfer meldet, was nicht stimmt - in Begriffen, mit denen der Agent arbeiten kann. Der Kernel ist der schnelle, günstige Teil. In einem echten Produktionslauf eines Einfamilienhauses dauerte der Aufbau des Modells im Browser rund 7 Sekunden und die Verlegung der TGA rund 6 Sekunden; fast die gesamte Laufzeit entfiel auf das Nachdenken des Sprachmodells.

Das funktioniert nur, weil der Kernel dafür geschrieben wurde. BIM Harness steht auf einem eigenen parametrischen Kernel, von Grund auf geschrieben, nicht auf einem Plugin für fremdes CAD. Dieselbe Scripting API, mit der der Agent baut, steht Menschen im Editor zur Verfügung: Was der Agent kann, können Sie auch.

## Was der Agent schreibt

Ein gekürzter Ausschnitt aus einem echten, gegen den Kernel getesteten Skript. Die Tür hängt über ihre id an einer Wand - eine Beziehung, kein Koordinatenpaar, das das Modell treffen muss.

```js
const ground = api.ensureStorey('Erdgeschoss', 0);
const W = 12, D = 8, H = 3.4;
const outline = [[0,0],[W,0],[W,D],[0,D]];
api.floorAssembly({ slabOutline: outline, wallOutline: outline, storey: ground });
const south = api.wall({ start: [0,0], end: [W,0], storey: ground, height: H });
api.wall({ start: [W,0], end: [W,D], storey: ground, height: H });
api.wall({ start: [W,D], end: [0,D], storey: ground, height: H });
api.wall({ start: [0,D], end: [0,0], storey: ground, height: H });
const partition = api.wall({ start: [W/2,0], end: [W/2,D], storey: ground, height: H, thickness: 0.15 });
api.space({ outline: [[0,0],[W/2,0],[W/2,D],[0,D]], storey: ground, height: H, name: 'Halle', type: 'hall' });
api.space({ outline: [[W/2,0],[W,0],[W,D],[W/2,D]], storey: ground, height: H, name: 'Arbeitszimmer', type: 'office' });
api.door({ wall: partition.id, offset: D/2, width: 0.9 });
api.door({ wall: south.id, offset: W/4, width: 1.4 });
api.window({ wall: south.id, offset: 3*W/4, width: 1.2, sill: 0.9 });
```

Vierzehn Zeilen beschreiben ein Geschoss, seine Wände, zwei Räume als IFC-Spaces, zwei Türen und ein Fenster. Über eine GUI ist dasselbe Ergebnis eine lange Folge einzelner Interaktionen.

## Wo sich der Unterschied in der Praxis zeigt

- **Beobachtbarkeit** - Ein Screenshot sagt dem Agenten, wie der Bildschirm aussieht. Ein Prüfer sagt ihm, was am Gebäude nicht stimmt: clash.hard, door.obstructed, stair.throughFabric, room.accessEnvelope. Die Befunde sind maschinenlesbar und getrennt in Autorenbefunde, die das Modell beheben soll, und Engine-Befunde.
- **Wiederholbarkeit** - Das Sprachmodell ist nicht deterministisch, die Ausführung schon. Dasselbe Skript auf demselben Kernel baut dasselbe Modell, und TGA-Trassierung und Kollisionsauflösung erledigen deterministische Resolver, nicht das Sprachmodell.
- **Kosten pro Schritt** - Auf dem GUI-Weg ist jede Interaktion ein Modellaufruf. Ein Programm ist ein Artefakt, das der Kernel in Sekunden ausführt; bezahlt wird das Modell für das Schreiben und Reparieren des Programms, nicht dafür, jede Wand einzeln an ihren Platz zu schieben.
- **Fehlerbehebung** - Kann ein Verb nicht tun, was verlangt wurde, verweigert der Kernel mit Namen. In einem Produktionslauf antwortete der Kernel: „api.gable: the roof given does not cover this wall ... It was not built.“ Das Modell schrieb diesen Teil des Skripts neu.
- **Versionierung** - Ein Skript ist Text. Es lässt sich vergleichen, prüfen und bearbeiten. Der Agent liest sein eigenes Skript zurück und ändert es gezielt, statt alles neu zu schreiben oder eine Klicksitzung erneut abzuspielen.

## Wie ein Fehler auf dem Programm-Weg behoben wird

Die Schleife des Agenten ist kurz und explizit. Übernommen wird erst, wenn der Probebau besteht.

1. **Probebau** - Der Kernel baut und prüft das Skript. Nichts wird ins Projekt übernommen.
2. **Benannte Befunde** - Der Prüfer liefert Befunde wie door.obstructed oder clash.hard, jeweils mit ihrer Ursache verknüpft.
3. **Reparaturplan** - Die Befunde fließen in einen Reparaturplan für die nächste Runde, damit der Agent weiß, was er ändern soll und warum.
4. **Gezielte Änderung** - Der Agent liest sein Skript zurück und ändert die betroffenen Zeilen - der Rest des Gebäudes bleibt unberührt.
5. **Live-Build** - Das korrigierte Skript läuft als Live-Build und wird zu dem Modell, das Sie öffnen, bearbeiten und nach IFC4X3 exportieren.

## Der Agent neben dem Modell, das er gebaut hat

![BIM-Harness-Editor mit dem KI-Assistenten neben einem generierten mehrgeschossigen Gebäude](https://buildify.cz/screenshots/harness-ai.webp)

Das Panel des KI-Assistenten neben einem generierten Gebäude im BIM-Harness-Editor. Die Oberfläche ist tschechisch; dahinter steht ein IFC-Modell, das Sie öffnen, von Hand bearbeiten und exportieren können.

> Computer Use automatisiert die Bedienung von Software. BIM Harness macht das Gebäudemodell selbst programmierbar.

## Welcher Weg der richtige ist

Hat die Software, die Sie automatisieren wollen, weder API noch Skriptschnittstelle, ist Computer Use oft der einzige praktikable Weg - und ein guter. Arbeitet Ihr Team bereits in einem etablierten Desktop-BIM-Werkzeug und wünscht sich dort einen Assistenten, hält eine Tool-API oder ein MCP-Server auf diesem Werkzeug alle in vertrauter Software.

Geht es darum, ein ganzes Gebäude zu generieren - Geschosse, Tragwerk, Räume, Fassade, Dach und TGA-Systeme - und es danach immer wieder zu ändern, skaliert der Programm-Weg. Das Gebäudemodell lebt als lesbares Skript und parametrisches Objektmodell, der Kernel erledigt die Geometrie, und das Ergebnis ist offenes IFC4X3, das etablierte Desktop-BIM-Werkzeuge und CDEs übernehmen.

## Häufige Fragen

### Was ist der Unterschied zwischen Computer Use und einer API für CAD?

Mit Computer Use bedient ein KI-Modell CAD-Software über ihre grafische Oberfläche: Es nimmt Screenshots auf, bewegt die Maus, öffnet Menüs und füllt Dialoge aus, mit einem Modellaufruf pro Interaktion. Auf dem API-Weg ruft das Modell die Funktionen der Software direkt auf und liest strukturierte Ergebnisse. BIM Harness geht eine Ebene weiter: Das Modell schreibt ein Gebäudeprogramm, das ein BIM-Kernel als Ganzes ausführt und prüft.

### Können KI-Agenten CAD- und BIM-Software steuern?

Ja. Agenten können CAD per Computer Use über den Bildschirm bedienen, Funktionen einer Desktop-BIM-Software über ein Plugin oder einen MCP-Server aufrufen oder das Gebäude als Code für einen BIM-Kernel schreiben. BIM Harness nutzt den dritten Ansatz: Der Agent schreibt ein Skript in einem Gebäudedialekt mit mehr als hundert Verben, und der eigene parametrische Kernel baut und prüft das Modell.

### Ist Computer Use ein schlechter Weg, BIM zu automatisieren?

Nein. Computer Use ist wertvoll für Software, die ihre Funktionen nur über eine grafische Oberfläche anbietet und keine API hat. Die Grenzen bei Gebäudemodellen sind struktureller Art: Der Agent sieht Screenshots statt des Modells, bezahlt einen Modellaufruf pro Interaktion und hängt vom Bildschirmzustand ab. Wo es ein programmierbares Modell und einen Prüfer gibt, kann der Agent stattdessen mit strukturierten Befunden arbeiten.

### Worin unterscheidet sich BIM Harness von einem MCP-Server für Desktop-BIM-Software?

Ein MCP-Server ist ein Beispiel für den Tool-API-Ansatz: Ein Sprachmodell ruft Funktionen einer etablierten Desktop-BIM-Anwendung einzeln auf. BIM Harness steuert keine andere Anwendung. Sein Agent schreibt ein Gebäudeprogramm, das der von Grund auf geschriebene parametrische Harness-Kernel ausführt und prüft. Die Ergebnisse treffen sich bei IFC: Harness exportiert IFC4X3, das Werkzeuge von Autodesk und Archicad übernehmen.

### Warum ist ein Gebäudeprogramm wiederholbarer als GUI-Automatisierung?

Eine GUI-Sitzung hängt von Bildschirmzustand, Fensterlayout, Dialogen und Timing ab, eine Wiederholung kann also anders verlaufen. In BIM Harness ist die Ausführung deterministisch: Dasselbe Skript auf demselben Kernel baut dasselbe Modell, und TGA-Trassierung und Kollisionsauflösung erledigen deterministische Resolver. Das Sprachmodell, das das Skript schreibt, ist nicht deterministisch - was es geschrieben hat, läuft aber jedes Mal gleich.

### Wie erfährt der Agent, dass etwas schiefgelaufen ist?

Der Prüfer von BIM Harness liefert benannte, maschinenlesbare Befunde, getrennt in Autorenbefunde (Entwurfsfehler, die das Modell beheben soll) und Engine-Befunde. Beispiele sind clash.hard, door.obstructed, stair.throughFabric und room.accessEnvelope. Kann ein Verb nicht tun, was verlangt wurde, verweigert der Kernel mit Namen und baut es nicht. Die Befunde fließen in einen Reparaturplan, und der Agent ändert die betroffenen Zeilen.

## Verwandte Themen

- [was AI-native BIM bedeutet](https://buildify.cz/de/ai-native-bim)
- [ein BIM-Modell mit derselben API skripten, die der Agent nutzt](https://buildify.cz/de/bim-scripting)
- [wie die Schleife des BIM-Agenten Schritt für Schritt funktioniert](https://buildify.cz/de/ai-bim-agents)
- [Text-to-BIM aus einem schriftlichen Briefing](https://buildify.cz/de/text-to-bim)
- [warum ein generiertes 3D-Mesh kein BIM-Modell ist](https://buildify.cz/de/text-to-3d-vs-text-to-bim)

## Lassen Sie den Agenten das Gebäude schreiben, nicht klicken

BIM Harness gibt der KI einen Gebäudedialekt, einen parametrischen Kernel und einen Prüfer - und Ihnen dieselbe Scripting API, den vollständigen Browser-Editor und am Ende offenes IFC4X3.

Zugang zu BIM Harness erhalten: https://buildify.cz/de/bim-harness#waitlist

---

Zdroj / Source: https://buildify.cz/computer-use-vs-bim-api · Kontakt: kluch@buildify.cz · Buildify Digital s.r.o., IČO 29541743, Korunní 2569/108, 101 00 Praha 10, Česká republika.