Der Harness: Das Modell ist nur der Motor
DerHarness:DasModellistnurderMotor
Zwei Anwendungen können exakt dasselbe Modell nutzen und haben trotzdem weder dieselben Fähigkeiten noch dieselbe Verlässlichkeit. Was sie trennt, ist die Schicht, über die am wenigsten gesprochen wird: der Harness.
Sie haben wahrscheinlich schon jemanden sagen hören:
« Unser Produkt nutzt GPT. »
Oder Claude. Oder Mistral. Oder Qwen.
Gut.
Aber das sagt Ihnen letztlich wenig darüber, was das Produkt wirklich tut.
Zwei Anwendungen können exakt dasselbe Modell nutzen und dennoch radikal unterschiedliche Fähigkeiten, Leistungen und sogar Verhaltensweisen haben.
Warum?
Weil zwischen Ihrer Anwendung und dem Modell eine Schicht sitzt, über die weit weniger gesprochen wird: der Harness.
Und Sie werden sehen: Es ist wahrscheinlich eine der wichtigsten Schichten der modernen KI.
Zurück zu unserem Dokument
Im ersten Artikel dieser Reihe hatten wir ein sehr einfaches Beispiel genommen: Sie laden ein großes Dokument hoch und fragen:
« Fasse mir das in 5 Punkten zusammen. »
Wir hatten gesehen, dass klassische Software schon eingreift, bevor Ihr Dokument überhaupt beim Modell ankommt:
- den Text aus dem PDF extrahieren,
- das Dokument zerlegen,
- die interessanten Passagen suchen,
- den Prompt bauen,
- die Informationen an das Modell schicken,
- seine Antwort einsammeln,
- es gegebenenfalls noch einmal machen lassen.
Damals hatte ich das schlicht die Softwareschicht genannt.
Heute setzt sich für einen großen Teil dieser Mechanik ein Begriff durch: der Harness.
Was ist denn nun ein Harness?
Sehr stark vereinfacht:
« Das Modell denkt. Der Harness organisiert seine Arbeit. »
Stellen Sie sich einen Motor mitten in Ihrer Garage vor.
Auch mit 500 PS kommen Sie damit nicht weit.
Er braucht:
- ein Lenkrad,
- ein Getriebe,
- Räder,
- Bremsen,
- Sensoren,
- einen Tank,
- ein Armaturenbrett,
- und einen Fahrer oder ein System, das entscheiden kann, wohin es geht.
Bei einem KI-Modell ist es genauso.
Das Modell kann extrem leistungsfähig sein, aber es kennt Ihre internen Dokumente nicht von selbst, es hat keinen Zugriff auf Ihr CRM, es weiß nicht zwangsläufig, wann es im Internet suchen soll, und es entscheidet nicht auf magische Weise, wie eine komplexe Aufgabe in zehn Schritte zerlegt wird.
All das muss von Software organisiert werden.
Das ist der Harness.
Und das ändert vieles daran, wie wir auf KI schauen.
Ein Modell allein ist letztlich ziemlich begrenzt
Nehmen wir ein klassisches LLM.
Sie geben ihm Text. Es gibt Ihnen Text.
Das ist natürlich schon beeindruckend.
Aber stellen Sie sich nun vor, Sie fragen es:
« Sag mir, wie viel wir dem Kunden Dupont dieses Jahr in Rechnung gestellt haben, und vergleiche das mit dem Vorjahr. »
Ihr Modell hat vermutlich keine Ahnung, wer Dupont ist.
Es kennt Ihre Rechnungssoftware nicht.
Es hat nicht die nötigen Zugriffsrechte.
Es weiß nicht, welche Datenbank es abfragen soll.
Und vor allem wollen Sie ihm wahrscheinlich nicht bei jeder Frage Ihre gesamte Buchhaltung geben.
Sie müssen ihm also eine Umgebung bauen. Zum Beispiel:
- verstehen, dass die Frage die Rechnungsstellung betrifft;
- den Kunden im CRM identifizieren;
- Ihr Buchhaltungswerkzeug aufrufen;
- nur die notwendigen Daten abrufen;
- gegebenenfalls eine Berechnung durchführen;
- die Ergebnisse an das Modell übergeben;
- prüfen, ob die Antwort das erwartete Format einhält;
- das Ergebnis dem Nutzer anzeigen.
Das Modell hat nur einen Teil der Arbeit erledigt.
Alles Übrige gehört zum Harness.
MODELL ALLEIN VS MODELL + HARNESS
MODELL ALLEIN
MIT HARNESS
HARNESS
Erste Aufgabe: den richtigen Kontext liefern
Sie haben in den letzten Jahren vielleicht sehr viel über Prompt Engineering gehört. Wie schreibt man den besten Prompt?
- „Du bist seit 25 Jahren Steuerberater …“
- „Antworte Schritt für Schritt …“
- „Wenn du die Antwort nicht kennst, sag es …“
Das ist nützlich.
Aber wir gehen gerade von Prompt Engineering zu einer viel breiteren Logik über: Context Engineering.
Die Frage lautet weniger:
« Wie soll ich meinen Satz formulieren? »
und mehr:
« Welche Informationen braucht das Modell wirklich, um diese Aufgabe zu erledigen? »
Denn sein Kontextfenster mit 300 nutzlosen Seiten zu füllen, ist selten eine gute Idee.
Der Harness kann also die relevanten Elemente auswählen:
- die Vorgaben des Unternehmens;
- den relevanten Verlauf des Gesprächs;
- bestimmte Dokumente;
- die Ergebnisse einer Suche;
- die Antworten eines Tools;
- die Arbeit aus den vorherigen Schritten.
Und dem Modell nur das übergeben, was es in genau diesem Moment braucht.
DER HARNESS WÄHLT DEN RICHTIGEN KONTEXT
ALLE QUELLEN
HARNESS
Kontextauswahl
NÜTZLICHER KONTEXT
Hier taucht insbesondere unser bekanntes RAG wieder auf, über das wir bereits gesprochen hatten. Statt dem Modell Ihre gesamte Dokumentation zu geben: Frage → Suche nach den interessanten Passagen → Modell → Antwort.
Der Harness orchestriert die Suche.
Das Modell analysiert die Informationen, die man ihm bringt.
Zweite Aufgabe: der KI Werkzeuge geben
Hier wird es deutlich interessanter.
Ein LLM kann inzwischen entscheiden:
« Um diese Frage zu beantworten, muss ich dieses Tool benutzen. »
Das kann sein:
- eine Suche im Internet durchführen;
- eine Datenbank abfragen;
- ein Dokument lesen;
- eine E-Mail verschicken;
- einen Kalender einsehen;
- Code ausführen;
- Ihr CRM aufrufen;
- eine andere interne Software starten.
Damit bekommen Sie langsam das, was man gemeinhin einen Agenten nennt.
Nehmen wir ein sehr einfaches Beispiel. Sie sagen:
« Organisiere mir nächste Woche einen Termin mit Paul. »
Das Modell kann Ihre Absicht verstehen.
Aber der Harness muss es ihm ermöglichen:
- Paul zu identifizieren;
- Ihren Kalender einzusehen;
- die freien Zeiten abzurufen;
- gegebenenfalls Pauls Kalender einzusehen;
- einen Termin vorzuschlagen;
- auf Ihre Freigabe zu warten;
- den Termin anzulegen.
Und vor allem … muss man die KI davon abhalten, Unsinn zu machen.
Sie wollen Ihrem Agenten wahrscheinlich erlauben, Ihren Kalender zu lesen. Sie haben vielleicht weniger Lust, ihm zu erlauben, sämtliche Termine zu löschen.
Auch das ist Aufgabe dieser Softwareschicht.
MCP: der USB-Anschluss unserer Agenten?
Wenn jeder Entwickler für jedes Tool eine eigene Verbindung bauen muss, erschaffen wir natürlich schnell wieder die wunderbare Welt der IT-Integrationen, in der jeder seine eigene API, sein eigenes Format und seine 453-seitige Dokumentation hat.
Unter anderem als Antwort darauf sind Protokolle wie MCP — Model Context Protocol entstanden.
Die Idee ist recht einfach: standardisieren, wie ein Agent Tools oder Ressourcen entdecken und nutzen kann.
Genau deshalb haben wir bei SOCLE unsere Agenten um diese Art von Protokoll herum gebaut: um möglichst zu vermeiden, für jede neue Fähigkeit eine eigene Integration neu zu erfinden.
Dritte Aufgabe: entscheiden, was als Nächstes kommt
Dem Modell ein Tool zu geben, ist eine Sache.
Man muss auch entscheiden, wann es genutzt wird.
Hier kommt ins Spiel, was man gemeinhin die agentische Schleife nennt. Stark vereinfacht: beobachten → nachdenken → handeln → das Ergebnis beobachten → von vorn.
DIE AGENTISCHE SCHLEIFE
Nehmen wir die Suche nach einem Restaurant. Ihr Agent könnte:
- verstehen, dass Sie ein italienisches Restaurant suchen;
- ein Suchwerkzeug benutzen;
- fünf Ergebnisse erhalten;
- feststellen, dass Sie eines wollten, das heute Abend offen hat;
- die Öffnungszeiten prüfen;
- die geschlossenen Restaurants ausschließen;
- die Verfügbarkeiten ansehen;
- Ihnen die drei besten Vorschläge präsentieren.
Wir machen also nicht mehr zwangsläufig Nutzer → Modell → Antwort, sondern Nutzer → Modell → Tool → Modell → Tool → Modell → Antwort.
Und das kann über mehrere Dutzend Schritte weitergehen.
Der Harness ist die Mechanik, die diese Schleife am Leben hält.
- Er reicht die Ergebnisse weiter.
- Er bewahrt den Zustand.
- Er kontrolliert die Zahl der Iterationen.
- Er erkennt Fehler.
- Er kann die KI auffordern, die Strategie zu ändern.
- Und vor allem entscheidet er, wann es Zeit ist aufzuhören.
Denn ein Agent, der ewig nachdenkt, ist philosophisch faszinierend, wirtschaftlich aber ziemlich katastrophal.
Und wenn ein Modell nicht reicht?
Wir können noch weiter gehen.
Warum für absolut jede Aufgabe dasselbe Modell verwenden?
Nehmen wir eine aufgezeichnete Besprechung. Wir müssen:
- eine Audiodatei verstehen;
- die Sprecher unterscheiden;
- ihre Worte transkribieren;
- bestimmte Fehler korrigieren;
- den fachlichen Kontext verstehen;
- gegebenenfalls eine Zusammenfassung erzeugen.
Ein einziges riesiges Modell könnte theoretisch versuchen, alles zu machen. Aber das ist nicht zwangsläufig die beste Lösung.
Bei SOCLE kombiniert unser Transkriptionssystem zum Beispiel mehrere Verarbeitungsschritte: Ein auf Spracherkennung spezialisierter Agent erstellt die Transkription, danach kann ein LLM-Agent eine kontextuelle Korrektur vornehmen und dabei Sprecher und fachliche Informationen berücksichtigen.
Jede Technologie wird dort eingesetzt, wo sie sinnvoll ist.
Genau das ist der Vorteil, in einem Ökosystem von Agenten statt in einem einzigen Modell zu denken.
Multi-Agenten
Und weil wir es natürlich lieben, Dinge zu verkomplizieren, sobald sie funktionieren, können wir unserem Harness mehrere Agenten geben.
Stellen Sie sich ein Team in einem Unternehmen vor. Sie haben:
- eine Juristin;
- einen Entwickler;
- eine Vertrieblerin;
- einen Buchhalter.
Sie könnten eine extrem kluge Person einstellen und von ihr verlangen, in allen vier Bereichen Expertin zu werden. Oder mehrere Spezialisten einsetzen und sie zusammenarbeiten lassen.
In einem Multi-Agenten-System ist das Prinzip ähnlich. Ein Agent kann die Anfrage entgegennehmen und sie an einen spezialisierteren Agenten weiterreichen.
EIN MULTI-AGENTEN-ÖKOSYSTEM
Text-Agent
LLM
Audio-Agent
ASR
Vision-Agent
VLM
↔ A2A
Der Harness wird damit zu einer Art Dirigent.
- Wer arbeitet?
- In welcher Reihenfolge?
- Welche Informationen müssen von einem Agenten zum anderen weitergegeben werden?
- Sollen sie parallel arbeiten?
- Wer prüft das Ergebnis?
Bei SOCLE nutzen wir insbesondere das Protokoll A2A — Agent-to-Agent, um diesen Austausch zwischen Agenten zu strukturieren.
Das Ziel bleibt dasselbe: verhindern, dass jede neue Kombination bedeutet, das Produkt komplett neu zu bauen.
Vierte Aufgabe: das richtige Modell wählen
Und hier werden Sie verstehen, warum ich Ihnen im vorigen Kapitel erklärt habe, dass ein Modell letztlich „nur ein Algorithmus“ ist.
Ihr Produkt muss nicht zwangsläufig mit GPT, Claude oder Mistral verheiratet sein, bis dass der Tod Sie scheidet.
Der Harness kann eine Abstraktionsschicht zwischen Ihrer Anwendung und Ihren Modellen bilden. Stellen Sie sich vor:
- ein kleines schnelles Modell, um eine Anfrage einzuordnen;
- ein auf Code spezialisiertes Modell, um ein Programm zu analysieren;
- ein stärkeres Modell für eine komplexe Aufgabe;
- ein multimodales Modell, um ein Bild zu verstehen;
- ein lokales Modell für bestimmte sensible Daten.
Ihr Nutzer wiederum muss überhaupt nicht wissen, dass er gerade vier verschiedene Modelle benutzt hat. Er will einfach, dass sein Problem gelöst wird.
Und das ist uns bei SOCLE besonders wichtig: wir glauben nicht, dass ein KI-Produkt um ein Modell herum gebaut werden sollte. Es sollte um einen Bedarf herum gebaut werden.
Die Modelle werden damit zu Ressourcen, die das System je nach Aufgabe auswählt.
Das stärkste Modell ist nicht immer das beste Produkt
Das ist vielleicht der wichtigste Gedanke dieses Artikels.
Stellen wir uns zwei Unternehmen vor, die exakt dasselbe Modell nutzen.
Unternehmen A
Es schickt Ihre Frage direkt mit einem riesigen 15-seitigen Prompt an das LLM.
Unternehmen B
Sein Harness:
- erkennt Ihre Absicht;
- holt nur die notwendigen Dokumente;
- wählt die richtigen Tools;
- kontrolliert deren Berechtigungen;
- nutzt für eine Teilaufgabe ein spezialisiertes Modell;
- prüft das Ergebnis;
- holt bei Bedarf eine menschliche Freigabe ein;
- protokolliert alle Schritte.
Auch deshalb wird es allmählich zu wenig, KI-Lösungen nur mit der Frage „welches LLM nutzen die?“ zu vergleichen.
Das ist, als würde man zwei Autos nur danach vergleichen, wie viel PS der Motor hat. Das zählt. Aber Sie vergessen alles drumherum.
Human-in-the-loop: manchmal soll die KI einfach fragen
Ein weiteres besonders wichtiges Element eines Harness: zu wissen, wann man nicht allein handeln sollte.
Stellen Sie sich eine KI im juristischen Kontext vor. Sie kann:
- ein Gespräch transkribieren;
- die Sprecher identifizieren;
- eine Unstimmigkeit melden;
- eine Korrektur vorschlagen.
Aber eine Aussage ohne menschliche Freigabe endgültig zu verändern, wäre offensichtlich eine sehr schlechte Idee.
Der Harness kann also Kontrollpunkte einführen: KI → Vorschlag → menschliche Freigabe → weitere Verarbeitung.
Das nennt man Human-in-the-loop.
Und anders als in manchen sehr futuristischen KI-Visionen ist das nicht zwangsläufig ein Automatisierungsmangel. Manchmal ist es genau das, was Automatisierung nutzbar macht.
Bei einem unserer Kunden im juristischen Bereich nutzen wir genau diesen Ansatz: Verschiedene Verarbeitungsschritte können vom Nutzer vor der Freigabe geprüft und korrigiert werden.
Fünfte Aufgabe: beobachten, was passiert
Das ist wahrscheinlich einer der unsexysten Aspekte von KI.
Und doch wird er unverzichtbar, sobald Sie ein System in den Produktivbetrieb bringen wollen.
Ihr Agent hat gerade eine schlechte Antwort produziert. Warum? War es:
- das Modell?
- der Prompt?
- das vom RAG geholte Dokument?
- eine schlechte Antwort eines Tools?
- ein Routing-Problem?
- ein vorheriger Schritt, der danebenlag?
- eine Information im Memory?
- ein anderer Agent?
Wenn Ihr System nur aus Frage → große Blackbox → Antwort besteht: viel Glück.
Ein industrietauglicher Harness muss deshalb auch erlauben, den Ablauf der Verarbeitung nachzuvollziehen. Bei SOCLE arbeiten wir genau daran, die einzelnen Schritte beobachtbar zu machen.
- Welcher Agent wurde aufgerufen?
- Welches Tool?
- Welches Dokument?
- Welches Modell?
- Wie lange?
- In welcher Reihenfolge?
Das erlaubt zu verstehen, was Ihre KI wirklich tut. Aber auch, ihre Kosten zu messen.
Denn eine KI, die Ihnen 3 Minuten Arbeit spart und dabei pro Anfrage 12 € Rechenleistung verbraucht, ist vielleicht nicht das fantastische Digitalisierungsprojekt aus der PowerPoint-Präsentation.
Und was ist mit der Sicherheit?
Sobald Sie einer KI Werkzeuge geben, wird die Frage natürlich kritisch.
Ein Chatbot, der eine Hauptstadt halluziniert, ist ärgerlich. Ein an Ihr IT-System angeschlossener Agent, der eine Aktion halluziniert, ist etwas problematischer.
Der Harness muss also auch Regeln durchsetzen können:
- welche Tools zugänglich sind;
- welche Aktionen eine Freigabe brauchen;
- welche Daten weitergegeben werden dürfen;
- wie viele Aktionen ausgeführt werden dürfen;
- welche Nutzer welche Rechte haben;
- welche Ergebnisse geprüft werden müssen.
Je handlungsfähiger die KI wird, desto wichtiger wird diese Schicht.
Die Sicherheit eines agentischen Systems kann also nicht allein darauf beruhen: „Wir haben das Modell im Prompt höflich gebeten, keinen Unsinn zu machen.“
Das wäre praktisch. Aber lassen wir das lieber.
Wo sitzt die Intelligenz eigentlich?
Als ChatGPT auftauchte, haben wir die gesamte Intelligenz, die wir sahen, ganz selbstverständlich dem Modell zugeschrieben. Das war logisch.
Aber je komplexer unsere Systeme werden, desto unschärfer wird die Grenze.
Ein Teil der Leistung kommt vom Modell. Ein anderer kommt:
- von der Qualität der Tools;
- vom Kontext, den man ihm liefert;
- vom Memory;
- vom RAG;
- vom Routing;
- von der Orchestrierung;
- von den Prüfschleifen;
- von den anderen Modellen ringsum.
Das KI-System wird damit wichtiger als das bloße Modell. Und das ist wahrscheinlich die spannendste Entwicklung, die wir derzeit beobachten.
Wir sind von „welches Modell nutzen Sie?“ übergegangen zu „welches System haben Sie um Ihre Modelle herum gebaut?“
Kurz gefasst
Er bringt ihm:
- Kontext;
- Dokumente;
- Memory;
- Tools;
- Regeln;
- die Fähigkeit zu handeln;
- andere Agenten;
- Kontrollmechanismen;
- Observability.
Und vor allem macht er aus einem simplen Modellaufruf ein echtes Produkt.
Auch deshalb arbeiten wir bei SOCLE vor allem an dieser Schicht. Unser Ziel ist nicht, das nächste Allzweckmodell zu bauen: Andere Unternehmen geben dafür bereits einige Milliarden aus ;)
Unsere Arbeit besteht darin, Unternehmen zu ermöglichen, rund um diese Modelle nutzbare Systeme zu bauen: Agenten, RAG, MCP-kompatible Tools, Multi-Agenten-Ökosysteme auf Basis von A2A, menschliche Kontrolle und Nachverfolgung der einzelnen Schritte.
Das Modell wird damit zu einem austauschbaren Baustein innerhalb eines größeren Systems.
Und das führt uns ganz natürlich zum nächsten Kapitel. Denn dieses ganze schöne System — die Agenten, die Tools, die nacheinander aufgerufenen Modelle — muss irgendwo laufen.
Spoiler: Es verbraucht Beton, Strom und Silizium.
Benjamin
Lust, darüber zu sprechen?
Ihr Feedback ist willkommen. Und wenn Sie sehen möchten, wie souveräne KI in der Praxis aussieht: Die Plattform steht Ihnen offen.
