Coffee & Cake: Modelle, Agenten und Harnesses Canonical episode: https://move37.app/cafe/de/episodes/coffee-cake-models-agents-harnesses-de/ Published: 2026-08-17T07:47:40Z Language: de TRANSCRIPT Willkommen in Andy's Café, wo Maschinen brühen und Menschen genießen. Heute servieren wir Coffee and Cake. Modell, Agent und das System drumherum Ein Produkt mit Sprachmodell beantwortet eine Frage. Ein anderes durchsucht einen Ordner, liest ein Fehlerprotokoll, ändert eine Datei, startet einen Test und versucht nach einem Fehlschlag etwas Neues. Auf den ersten Blick scheint das Modell im zweiten Produkt viel mächtiger zu sein. Tatsächlich kann in beiden genau dasselbe Modell stecken. Der Unterschied liegt dann nicht in dem, was trainiert wurde, sondern in dem System, das dieses Modell umgibt. Um diesen Unterschied zu verstehen, müssen wir drei Dinge auseinanderhalten: das Modell, den Agenten und die Software, die den Arbeitsablauf zwischen Modell, Werkzeugen und Umgebung steuert. Die Begriffe werden nicht überall gleich verwendet. Manche Anbieter nennen schon ein Sprachmodell mit einer festen Anweisung einen Agenten. Andere verwenden das Wort erst dann, wenn das Modell seinen nächsten Schritt selbst wählen darf. Für den Alltag hilft deshalb weniger eine amtliche Definition als eine klare Funktionsbeschreibung. Das Modell ist zunächst die trainierte Komponente. Es bekommt eine Eingabe und berechnet daraus eine Ausgabe. Bei einem Sprachmodell kann die Eingabe aus einer Frage, früheren Nachrichten, Arbeitsanweisungen und Beschreibungen verfügbarer Werkzeuge bestehen. Die Ausgabe kann eine Antwort sein. Sie kann aber auch wie ein präziser Auftrag an ein Werkzeug aussehen: Öffne diese Datei. Suche nach diesem Begriff. Starte diesen Test. Eine solche Ausgabe ist noch keine Handlung. Wenn das Modell verlangt, ein Fehlerprotokoll zu lesen, hat es das Protokoll nicht selbst geöffnet. Es hat lediglich eine passende Anforderung erzeugt. Ein anderes Stück Software muss diese Anforderung erkennen, an das richtige Werkzeug weiterreichen und das Ergebnis zurückbringen. Das ist ungefähr so, als würde jemand am Telefon um eine Akte bitten. Die Bitte kann klug und genau sein. Trotzdem muss noch jemand zum Schrank gehen. Ein Agent wird erst über mehrere Schritte sichtbar. Er erhält ein Ziel, wählt eine Handlung, sieht das Ergebnis und passt sein Vorgehen daran an. Das Modell kann dabei viele Male aufgerufen werden. Nach jedem Aufruf verändert die Rückmeldung aus der Umgebung die Ausgangslage für den nächsten. Ein Agent ist also nicht einfach eine neue Sorte Modell und schon gar keine kleine Person im Computer. Entscheidend ist die Schleife aus Entscheiden, Handeln, Beobachten und erneutem Entscheiden. Nehmen wir ein kaputtes Kontaktformular. Nachrichten werden nicht mehr verschickt, aber niemand weiß warum. Der Auftrag lautet: Finde den Fehler und behebe ihn. Das Modell könnte zunächst das Fehlerprotokoll anfordern. Dort entdeckt es einen Hinweis auf eine bestimmte Datei. Es lässt die Datei öffnen, schlägt eine Änderung vor und fordert anschließend einen Test an. Der Test schlägt fehl. Nun sieht das Modell eine neue Fehlermeldung, verwirft seine erste Vermutung und untersucht eine andere Stelle. Genau darin steckt das Agentenhafte. Die einzelnen Stationen waren nicht vollständig vorgegeben. Vorher war weder klar, welche Datei betroffen ist, noch wie viele Versuche nötig sein würden. Das Modell entscheidet anhand der jeweiligen Beobachtung, was als Nächstes sinnvoll erscheint. Es kann seine Richtung ändern, ein weiteres Werkzeug wählen oder feststellen, dass ihm eine Information fehlt. Daneben gibt es feste Abläufe. Ein Programm kann immer zuerst eine Datenbank durchsuchen, danach die ersten Treffer zusammenfassen und schließlich eine E-Mail versenden. Auch in jedem dieser Schritte kann ein Sprachmodell mitarbeiten. Solange aber der Weg unveränderlich im Programm festgelegt ist, handelt es sich eher um einen festen Arbeitsablauf, oft Workflow genannt. Wenn das Modell dagegen nach den ersten Treffern entscheidet, ob es weitersucht, eine Rückfrage stellt oder den Versand abbricht, wird das System zum Agenten. Die Grenze ist fließend. Nun fehlt noch die Steuerungssoftware. Irgendein Programm muss vor jeder Runde den aktuellen Arbeitsstand zusammenstellen, das Modell aufrufen, seine Werkzeuganforderung erkennen, sie an die richtige Stelle schicken und das Ergebnis in die nächste Runde einfügen. Diese Steuerungs- und Vermittlungsschicht wird im Englischen Agent Harness genannt, meist kurz Harness. Der Begriff bezeichnet also nicht noch eine weitere Intelligenz, sondern die Software, die aus einzelnen Modellaufrufen einen fortlaufenden Arbeitsprozess macht. Ein Harness kann mehr erledigen als nur weiterleiten. Es kann festlegen, welche Anweisungen und Werkzeuge das Modell überhaupt sieht. Es kann ältere Ergebnisse auswählen oder verdichten, Fehler an das Modell zurückmelden, nach zu vielen Runden abbrechen oder vor einer folgenreichen Handlung auf eine menschliche Freigabe warten. Welche Aufgaben dazugehören, ist von Produkt zu Produkt verschieden. Deshalb ist Harness kein vollständig genormter Begriff. Auch das Harness ist nicht mit der gesamten Umgebung gleichzusetzen. Ein Werkzeug liest die Datei. Eine abgeschottete Arbeitsumgebung führt den Test aus. Ein Sitzungsprotokoll kann festhalten, was bisher geschah. Das Harness vermittelt zwischen diesen Teilen und dem Modell. Manche Produkte bündeln alles in einem Paket und nennen das Ganze Agentenplattform. Für das Verständnis bleibt die Trennung trotzdem nützlich: Das Modell erzeugt den nächsten Vorschlag, Werkzeuge führen Handlungen aus, und das Harness organisiert den Austausch. Beim Kontaktformular sieht das so aus. Das Modell fordert das Fehlerprotokoll an. Das Harness reicht die Anforderung weiter. Ein Werkzeug liest das Protokoll und liefert Text zurück. Das Harness legt diesen Text in den Kontext des nächsten Modellaufrufs. Später werden auf dieselbe Weise eine Datei geöffnet, eine Änderung ausgeführt und ein Test gestartet. Scheitert der Test, gelangt das Ergebnis wieder zum Modell. Erst dieses wiederholte Zusammenspiel ergibt den Agenten, den der Nutzer erlebt. Damit wird verständlich, warum sich zwei Produkte mit demselben Modell so unterschiedlich verhalten können. In einem Produkt sind die Werkzeuge schlecht beschrieben, wichtige Testergebnisse gehen im Kontext unter und die Schleife endet zu früh. In einem anderen bekommt das Modell klare Werkzeugbeschreibungen, relevante Rückmeldungen und genügend Gelegenheit, einen Fehler zu korrigieren. Die trainierten Gewichte sind gleich, doch die nutzbare Leistung des Gesamtsystems ist es nicht. Das gilt auch in die andere Richtung. Eine Steuerungssoftware kann viele Hilfen enthalten, weil ein bestimmtes Modell häufig an derselben Stelle scheitert. Ein neueres Modell braucht diese Hilfen vielleicht nicht mehr. Dann werden sie zu unnötigem Ballast oder lenken sogar ab. Umgekehrt werden manche Modelle gezielt darauf vorbereitet, bestimmte Formate für Werkzeuganforderungen zu verwenden. Modell und Harness lassen sich begrifflich trennen, aber nicht immer beliebig gegeneinander austauschen. Damit lösen sich einige typische Missverständnisse auf. Ein Agent muss kein eigenes, besonders trainiertes Modell sein. Ein Modell, das den Namen eines Werkzeugs ausgeben kann, hat das Werkzeug noch nicht benutzt. Ein Harness ist nicht bloß eine lange Anweisung am Anfang, denn es betreibt die Schleife und verbindet sie mit der Außenwelt. Und ein Agent braucht keine Gruppe weiterer Agenten. Ein einzelnes Modell in einer einfachen Rückkopplungsschleife genügt. Auch der Modellname allein verrät wenig über das fertige Produkt. Ohne Zugriff auf Dateien kann selbst ein starkes Modell keinen Programmfehler im Projekt beheben. Wenn entscheidende Rückmeldungen verloren gehen, kann es denselben Fehler immer wieder machen. Wer zwei Agenten vergleichen will, muss deshalb nicht nur nach dem Modell fragen, sondern auch nach den Werkzeugen, dem bereitgestellten Kontext, der Zahl möglicher Versuche und der Art, wie Fehlschläge zurückgemeldet werden. Mehr Eigenständigkeit ist dabei nicht automatisch besser. Für eine bekannte, gleichbleibende Aufgabe ist ein fester Ablauf oft schneller, günstiger und leichter vorherzusagen. Ein offener Agent kann mit Überraschungen umgehen, benötigt dafür aber mehr Modellaufrufe und kann eine falsche Vermutung über mehrere Schritte fortschreiben. Sinnvoll ist nicht das System mit der größtmöglichen Autonomie, sondern das einfachste System, das mit der tatsächlichen Unsicherheit der Aufgabe zurechtkommt. Wenn also wieder von einem Agenten die Rede ist, helfen drei Fragen. Welches Modell erzeugt die Vorschläge? Wer bestimmt den nächsten Schritt: ein fester Programmablauf, ein Mensch oder das Modell auf Grundlage neuer Beobachtungen? Und was stellt das Harness bereit: welche Werkzeuge, welchen Kontext, welche Rückmeldungen und welche Bedingungen für eine Pause oder ein Ende? Das Modell liefert die gelernte Fähigkeit. Ein Agent nutzt sie über mehrere Schritte, um auf ein Ziel hinzuarbeiten. Das Harness hält den Austausch mit Werkzeugen und Umgebung in Gang. Erst zusammen entsteht das System, das am Ende nicht nur über ein kaputtes Kontaktformular spricht, sondern tatsächlich versucht, es zu reparieren. Das war's für heute. Das Café ist immer geöffnet. Bis bald. MORE INFORMATION TEXT LICENSE This transcript, description and original Andy's Café editorial text are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). License: https://creativecommons.org/licenses/by/4.0/ Attribution: Andy's Café — https://move37.app/cafe/de/episodes/coffee-cake-models-agents-harnesses-de/ Indicate changes when adapting. Identified third-party quotations and linked source material remain under their own terms. AUDIO AND OTHER MATERIAL The composed episode has separate component terms because its piano cues are third-party material. Artwork and the Andy's Café brand are not included in the CC BY licence. Rights map: https://move37.app/cafe/welcome/#reuse Contact: hello@move37.app