Prompt → model → response
Der *Prompt* enthält Ihre Anfrage und die Anweisungen an das Modell. Das Modell verarbeitet beides und erzeugt eine Antwort. Soll ein Text entstehen, kann diese Antwort bereits eine brauchbare Ausgabe sein. Muss dagegen in einem anderen System etwas geschehen, braucht das Produkt dafür eine zusätzliche Verbindung. Geben wir dem Koch nun eine klare Arbeitsumgebung: Zutaten, Küchengeräte und Regeln. 1. Die Aufgabe steht fest: Ein Käsesandwich soll zubereitet werden. 2. Der Koch prüft die Zutaten. Sind Brot und Käse vorhanden? Hat die Person eine Allergie? Welche Regeln gelten in der Küche? 3. Er wählt die nötigen Geräte: Messer, Teller und falls das Brot getoastet werden soll, einen Sandwichtoaster. 4. Er bereitet das Käsesandwich zu. 5. Er prüft, ob die gewünschten Zutaten verwendet wurden und das Essen serviert werden kann. 6. Kann er einen Fehler beheben, tut er das. Fehlt eine geeignete Zutat, hält er an und fragt nach. 7. Er serviert das Käsesandwich. Der Harness ist in diesem Beispiel der gesamte Aufbau, der die Arbeit des Kochs steuert. Er legt fest, welche Informationen der Koch prüft, was er verwenden darf, wie das Ergebnis kontrolliert wird und wann die Aufgabe beendet ist. Die Analogie hat eine Grenze: Ein echter Koch hat Hände, ein Sprachmodell nicht. In der Software erzeugt das Modell die Anforderung, mit einem Werkzeug eine Aktion auszuführen. Das von der Anwendung oder vom Anbieter betriebene Werkzeug führt sie aus. Die Aussage des Modells „Ich habe das Käsesandwich gemacht“ beweist nicht, dass es tatsächlich fertig ist. ## Das Modell erzeugt, der Harness organisiert die Arbeit Diese Aufteilung macht die Begriffe leichter nachvollziehbar: | Bestandteil | Welche Aufgabe hat er? | Was entspricht ihm im Sandwich-Beispiel? | | --- | --- | --- | | Modell | Erzeugt Antwort, Plan oder Werkzeugaufruf. | Der Koch, der über das Vorgehen nachdenkt und es vorschlägt. | | Harness | Organisiert Modellaufrufe und den Fortschritt der Aufgabe. | Der Aufbau, der Anweisungen, Werkzeugzugriff, Prüfungen und Abbruchbedingungen verbindet. | | Werkzeuge | Lesen Informationen oder führen Aktionen aus. | Messer, Teller und Sandwichtoaster. In Software etwa Funktionen, die eine Datei lesen oder einen Datensatz anlegen. | | Zustand / Gedächtnis (*State*) | Speichert aufgabenbezogene Informationen und Fortschritt. | Bestellnotiz, Allergieangaben und der Stand der Vorbereitungen. | | Agent | Das Modell, das innerhalb dieses Systems eine Aufgabe bearbeitet. | Der Koch, der mit Informationen und Werkzeugen ausgestattet die Arbeit fortführt. | Diese Aufteilung ist ein praktisches Denkmodell, mit dem ich die Begriffe verständlich mache. Sie ist keine allgemeingültige Taxonomie. Produkte ziehen die Grenzen nicht alle an derselben Stelle. Besonders der Begriff *Agent* umfasst in manchen Quellen sowohl das Modell als auch das System darum herum. Während die Arbeit voranschreitet, kann das Modell wiederholt zum Einsatz kommen. Es interpretiert neue Informationen, schlägt den nächsten Schritt vor oder bestimmt das nötige Werkzeug. Der Harness stellt die Arbeitsstruktur bereit, in der diese Entscheidungen umgesetzt werden. In Software hinterlegte Regeln begrenzen zugleich die möglichen Schritte. Gedächtnis bedeutet nicht, dass sich das Modell von selbst an alles erinnert. Die Software speichert den Aufgabenzustand und übergibt beim nächsten Modellaufruf die relevanten Teile. Gespeicherte Informationen helfen nur, wenn sie dem Modell zum richtigen Zeitpunkt vorliegen und es sie korrekt nutzt. ## Ein Harness kann mit einem direkten API-Aufruf beginnen Ein Harness ist nicht auf Terminalbefehle, Desktop-Anwendungen oder Agenten-Frameworks für Unternehmen beschränkt. Er kann unabhängig von der sichtbaren Oberfläche direkt in einem Produkt stecken. Auch ein fertiges Softwarepaket ist keine Voraussetzung. Angenommen, ein Produkt verarbeitet zwei Arten von Anfragen: Texte zusammenfassen und in eine andere Sprache übersetzen. Je nach Aufgabenart wählt das Produkt die passende Systemanweisung und das passende Modell und übermittelt beides über die API des Anbieters. Die API ist die Schnittstelle, über die die Software den Modelldienst anfragt. Anschließend gibt das Produkt das Ergebnis an den Nutzer zurück. Eine *Systemanweisung* (*System Prompt*) legt fest, wie sich das Modell bei dieser Aufgabe verhalten soll. Bei einer Zusammenfassung können Sie vorgeben, dass die Kernaussagen erhalten bleiben. Bei einer Übersetzung soll sich die Bedeutung nicht verändern. Der Code, der Systemanweisung und Modell auswählt, ist in dem hier verwendeten praktischen Sinn bereits ein minimaler Harness für Prompt- und Modellauswahl. Dieser Aufbau muss noch keine Werkzeuge, kein dauerhaftes Gedächtnis und keine Wiederholungsschleife enthalten. Trotzdem gibt es eine Schicht, die den Modelleinsatz organisiert. Wählt der Nutzer die Aufgabenart in der Oberfläche, muss für diese Zuordnung nicht einmal ein weiteres Modell laufen. Die verschiedenen Formen des Model Routings und ihren möglichen Zusatzaufwand behandle ich ausführlicher in [„Wie sollten Anfragen auf mehrere KI-Modelle verteilt werden?“](/de/wie-sollten-anfragen-auf-mehrere-ki-modelle-verteilt-werden). Entscheidend ist hier: Schon diese einfache Auswahl gehört zur Arbeitsstruktur um das Modell. ## Wenn sich die Aufgabe über mehrere Schritte erstreckt Mit wachsender Aufgabe können Sie den Harness erweitern. Anweisungen, Dokumente und bisherige Ergebnisse für den jeweiligen Modellaufruf zusammenzustellen, wird häufig als Kontextaufbereitung bezeichnet. Werkzeuge anzubinden, abgeschlossene Schritte zu speichern, die Ausgabe zu prüfen und bei behebbaren Fehlern einen neuen Versuch zu starten, erweitert dieselbe Arbeitsstruktur. Ein mehrstufiges System mit Werkzeugen kann diesem Ablauf folgen:Task → inspect context → use tools → execute → check the result → retry when needed → finish
Das System übernimmt die Aufgabe, prüft die nötigen Informationen, führt die Aktion mit Werkzeugen aus und kontrolliert das Ergebnis. Wenn sinnvoll, versucht es den Schritt erneut und schließt danach die Arbeit ab. Werkzeugnutzung und Ausführung gehören in vielen Anwendungen zum selben Schritt. Auch das Lesen eines Dokuments kann ein Werkzeug erfordern. Diese Reihenfolge ist eine einfache Darstellung des Arbeitszyklus, kein Protokoll, dem jeder Harness folgen muss. Zur Ergebniskontrolle müssen Sie nicht immer dasselbe Modell fragen: „Hast du es richtig gemacht?“ Software kann prüfen, ob eine Datei vorhanden ist. Sie kann im zuständigen System nachlesen, ob ein Datensatz an der richtigen Stelle angelegt wurde. Ob ein Text die beabsichtigte Bedeutung bewahrt, muss unter Umständen ein Mensch beurteilen. Auch neue Versuche brauchen Grenzen. Wurde ein Datensatz angelegt, aber keine Antwort empfangen, kann eine blinde Wiederholung einen doppelten Eintrag erzeugen. Vor einem neuen Versuch sollte der Harness deshalb prüfen, was tatsächlich geschehen ist. Kommt die Aufgabe nicht mehr voran oder fehlt eine Berechtigung, muss er anhalten und an einen Menschen zurückgeben. Den nächsten Schritt bestimmen in diesem Zyklus manchmal feste Software-Regeln, manchmal interpretiert das Modell neue Informationen und trifft die Wahl. Dann wird [die Unterscheidung zwischen Arbeitsablauf und Agent](/de/wann-brauchen-sie-tatsaechlich-einen-ki-agenten) wichtig. Ein einfacher Harness verlangt nicht, die gesamte Aufgabe einem offen agierenden Agenten zu überlassen. ## Bei der Produktbewertung über das Modell hinausblicken Derselbe Koch arbeitet anders in einer Küche mit vorbereiteten Zutaten als in einer, in der er jede Zutat erst suchen muss. Ändert sich auch die Kontrolle, können sich Geschwindigkeit und Ergebnis verschieben. Bei Softwareprodukten bewirken die Informationen, die das Modell sieht, seine verfügbaren Werkzeuge und der Umgang mit Fehlern einen ähnlichen Unterschied. Deshalb sollten Sie neben dem Modellnamen auch die Arbeitsstruktur betrachten, wenn Sie bewerten, [warum dasselbe KI-Modell in Anwendungen unterschiedliche Ergebnisse liefert](/de/warum-dasselbe-ki-modell-in-anwendungen-unterschiedliche-ergebnisse-liefert). Mehr Werkzeuge oder eine längere Schleife liefern nicht automatisch ein besseres Ergebnis. Unnötige Schritte können Latenz, Kosten und Fehlerwahrscheinlichkeit erhöhen. Für eine Zusammenfassung können die richtige Anweisung, ein geeignetes Modell und eine kurze Prüfung genügen. Führt die Aufgabe Aktionen in mehreren Systemen aus, werden Kontext, Berechtigungen, Zustandsverfolgung und Verifizierung wichtiger. Sind Schritte und Regeln vollständig bekannt, kann auch eine bestehende Automatisierung ausreichen. Wählen Sie für die Bewertung eines KI-Produkts eine konkrete Aufgabe aus Ihrer eigenen Arbeit. Prüfen Sie gemeinsam, welche Informationen das Produkt nutzt, welche Aktion es tatsächlich ausführt und woran das System den Abschluss der Arbeit erkennt. Berücksichtigen Sie auch, wie viel Mitarbeitende anschließend korrigieren müssen. Der Wert eines Harnesses zeigt sich darin, ob es dazu beiträgt, die Aufgabe mit einem akzeptablen Ergebnis abzuschließen. ## Weiterführende Literatur - [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents){.dofollow target="_blank" rel="noopener"}: Zeigt grundlegende Entwurfsmuster für direkte API-Nutzung, Routing und Modelle mit Werkzeugen. Der Text ist der Architekturleitfaden eines Anbieters und definiert die hier verwendete weite Bedeutung von *Harness* nicht als Branchenstandard. - [Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview){.dofollow target="_blank" rel="noopener"}: Trennt den vom Modell erzeugten Werkzeugaufruf von der Software, die die Aktion ausführt. Am Beispiel der Claude API wird der Unterschied zwischen Werkzeugen auf Anwendungs- und Anbieterseite sichtbar. - [Effective harnesses for long-running agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents){.dofollow target="_blank" rel="noopener"}: Veranschaulicht, warum Fortschrittsaufzeichnungen und Ergebniskontrollen bei langen Aufgaben wichtig sind. Der Beitrag beruht auf der Entwicklung einer Webanwendung und zeigt nicht, dass derselbe Aufbau für jede Aufgabe überlegen ist. --- Language: German License: CC BY 4.0 License URL: https://creativecommons.org/licenses/by/4.0/ Scope: Evren Bal-authored text, unless this article expressly states otherwise. Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights. Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes. Source: https://evrenbal.com/de/was-ist-ein-ki-harness