Ein KI-Agent entspricht einem KI-Modell plus einer Steuerungseinheit: Was die Steuerungseinheit leistet und warum.
Ein Agent ist ein Modell plus eine Steuerungseinheit. Erfahren Sie, wie solche Steuerungseinheiten Werkzeuge, Speicher, Schleifen und Sicherheitsmechanismen hinzufügen, wie sich Agenten mit offener Architektur und Open-Source-Varianten unterscheiden und warum Bewertungen wichtig sind.
Eine Zeit lang wurde die Geschichte des Fortschritts in der KI durch die Veröffentlichung neuer Modelle erzählt: größere, leistungsstärkere Grundmodelle kamen alle paar Monate auf den Markt. Diese Sichtweise ist unvollständig. Ein Sprachmodell, egal ob groß oder klein, liefert rohe Intelligenz – doch inwieweit diese Intelligenz den Benutzer erreicht, hängt vom darum herum entwickelten Software-Tool ab. Dieses Tool wird als „Harness“ bezeichnet, und immer mehr Forschungsergebnisse deuten darauf hin, dass es genauso wichtig sein kann wie das darin enthaltene Modell. Jüngste Studien zur Anpassung solcher Tools an kleinere Modelle zeigen, dass ein sorgfältig abgestimmtes Tool es einem kompakten Modell ermöglichen kann, einen Großteil der Leistungsfähigkeit eines hochentwickelten Modells bei Geschäftsaufgaben zu erreichen – und das zu einem geringeren Kostenanteil. Die genauen Zahlen finden Sie in den ursprünglichen wissenschaftlichen Arbeiten, doch die Entwicklungslinie stimmt mit dem überein, was Praktiker beobachten: Das leistungsstärkste Modell erzeugt nicht immer das fähigste System.
Daher dreht sich der Wettbewerb zunehmend darum, wer das beste „Harness“ entwickelt, und nicht nur darum, wer das größte Modell baut.
Warum ein intelligentes Modell trotzdem ein „Harness“ benötigt
Ein Sprachmodell kann eine Antwort liefern. Allein kann es jedoch keine Ordner durchsuchen, zwischen Werkzeugen wählen, Arbeitsgedächtnis zwischen Aufrufen speichern, das Geschriebene überprüfen, von Fehlern wiederherstellen oder auf ein Ziel hinarbeiten. Genau diese Lücken sollen von Agenten geschlossen werden. Bei einem Agenten umgibt ein „Harness“ das Modell und wandelt dessen Intelligenz in strukturierte, wiederholbare, zielgerichtete Aktionen um.
Modell versus Agent
Ein Modell nimmt eine Eingabe entgegen und liefert eine Ausgabe – danach ist seine Aufgabe erledigt. Ein Agent arbeitet nach der ersten Antwort weiter. Er liest Dateien, verwendet Werkzeuge, führt Befehle aus, merkt sich frühere Ergebnisse, trifft Entscheidungen und setzt über mehrere Schritte hinweg bis zur Erledigung der Aufgabe fort.
Wie kann das passieren, wenn ein Modell nur zum Vorhersagen des nächsten Ausgangswerts erstellt wird? Durch das Harness, das Engineering-System um das Modell herum. Es entscheidet darüber, welcher Kontext ins Modell gelangt, welche Tools verfügbar sind, wie Toolaufrufe ablaufen, was gespeichert wird, wann das Modell erneut aufgerufen wird und welche Aktionen abgelehnt oder einer Genehmigung bedürfen.
Das Harness erstellt außerdem den Arbeitszyklus:
Der Zyklus verläuft wie folgt: Das Modell liest den Inhalt seines Kontexts, wählt eine Aktion aus, ruft ein Tool auf, prüft die Rückmeldung, integriert diese in seinen Kontext und beginnt den Zyklus erneut.
Genau dieser Zyklus unterscheidet das Beantworten von der Erledigung einer Aufgabe. Er kann auch an einen Scheduler oder einen externen Auslöser gebunden sein, sodass der Agent zu einer bestimmten Zeit oder bei einem Ereignis von selbst startet.
Die Gleichung: Agent = Modell + Harness
Das Modell ist der Teil, der vorhersagt. Basierend auf dem ihm zur Verfügung gestellten Kontext erzeugt es die nützlichste nächste Ausgabe oder Aktion. Die Umgebung ist die Software darum herum, die diese rohe Fähigkeit in kontrolliertes, mehrstufiges Verhalten umwandelt.
Betrachten Sie, was passiert, wenn dasselbe Modell in verschiedene Umgebungen eingefügt wird:
- Mit einer einfachen Chat-Umgebung ist es ein konversationeller Assistent.
- Fügen Sie Web-Suche, Informationsabruf, Bewertung von Quellen sowie Überprüfung von Zitaten hinzu, und es wird zu einem Forschungsagenten.
- Geben Sie ihm ein Repository, einen Editor, eine Terminal-Unterstützung sowie Funktionen zur Ausgabe von Testergebnissen, und es wird zu einem Programmierungsagenten.
- Vernetzen Sie es mit Kundendaten, Geschäftsregeln, Kommunikationswerkzeugen, Auslösern sowie Genehmigungsprozessen, und Sie haben einen Betriebsagenten.
Das Modell hat sich nie geändert. Der Rahmen hingegen schon. Das erklärt auch, warum zwei Produkte, die auf demselben zugrundeliegenden Modell basieren, sich sehr unterschiedlich verhalten können. Eines holt die richtigen Beweise ab, wählt das richtige Werkzeug, erholt sich von fehlgeschlagenen Versuchen, hält seinen Kontext ordentlich und überprüft das Ergebnis. Ein anderes verliert wichtige Informationen, ruft weiterhin das falsche Werkzeug auf oder erklärt den Sieg, ohne nachzuprüfen. Die Fähigkeiten eines Produkts lassen sich nicht allein anhand seines Modells beurteilen: Das Modell bestimmt, was das System verstehen kann, und der Rahmen bestimmt, was es erreichen kann.
Die Schichten voneinander unterscheiden
Menschen verwenden oft Begriffe wie Modell, Agent und Rahmen austauschbar, obwohl es sich um getrennte Schichten handelt.
Codex und Claude Code veranschaulichen dieses Muster bei Programmier-Agenten hervorragend. Beide kombinieren die eigenen Modelle des Anbieters mit einem Framework, das den Repository-Context, Dateizugriff, Tools, Shell-Befehle, Speicher, Ausführung, Testfeedback sowie Wiederholungszyklen handhabt. OpenCode, Goose, Pi, Letta und AutoGPT folgen demselben Muster wie Laufzeiten oder Frameworks; sie unterscheiden sich jedoch in den unterstützten Modellen, Tool-Setzen, Speicherkonzepten sowie in ihrem Grad an Offenheit.
Der Agent ist das vollständige System, das Modell liefert die Intelligenz, und das Framework steuert, wie diese Intelligenz mit der Außenwelt in Kontakt tritt.
Offene Gewichte und Open Source sind unterschiedliche Dinge
Produkte wie Codex und Claude Code sind fertiggestellte Agenten, bei denen das Modell sowie die zugehörige Infrastruktur von derselben Firma gemeinsam entwickelt und abgestimmt werden. Ein Agent mit offenen Gewichten hingegen kombiniert ein herunterladbares Modell mit einer vorhandenen oder individuell angepassten Infrastruktur. Dadurch haben Entwickler mehr Kontrolle über die Bereitstellung, die verwendeten Tools, den Speicherbedarf, die Privatsphäre, die Kosten sowie das Verhalten des Agenten. Die Gewichte können auf der eigenen Infrastruktur ausgeführt werden und, sofern die Lizenz es erlaubt, weiter feinabgestimmt werden. Eine typische Kombination ist Goose mit einem Modell mit offenen Gewichten wie gpt-oss-120b oder OpenCode mit einem Qwen- oder Gemma-Modell.
Ein Open-Source-Agent ist etwas anderes: Der Code der Infrastruktur ist öffentlich zugänglich. Jeder kann lesen und ändern, wie der Agent das Modell anfragt, welche Tools er bereitstellt, wie er den Speicher verwendet, wie seine Schleifen ablaufen, womit er integriert wird sowie wie er Berechtigungen und Kontexte handhabt. OpenCode, Goose und AutoGPT sind Beispiele für solche offenen Infrastrukturen.
Die beiden Eigenschaften sind unabhängig voneinander:
- Ein Open-Source-Harness kann weiterhin ein proprietäres Modell über eine API aufrufen. OpenCode kann GPT- oder Claude-Modelle steuern, sodass seine Schnittstelle, die Steuerlogik sowie die Ausführung von Tools offen sind, während das zugrunde liegende Modell geschlossen bleibt.
- Ein Open-Weight-Modell ist für sich genommen kein Agent. Ein Modell wie gpt-oss-20b kann vorhersagen und entscheiden, doch es kann weder Ordner durchsuchen, Tools ausführen, den Zustand einer Aufgabe speichern noch einen Workflow abschließen – es sei denn, ein Harness wie Goose, OpenCode oder ein benutzerdefiniertes Framework umgibt es.
Kurz gesagt: Ein Open-Source-Agent ist ein offener Harness zusammen mit einem kompatiblen Modell, während ein Open-Weight-Agent aus einem Harness sowie herunterladbaren Gewichten besteht.
Warum offene Ökosysteme wichtig sind
Mehrere Labore bringen derzeit preiswerte Modelle mit offenen Gewichten zusammen mit Open-Source-Tooling für Agenten auf den Markt und schaffen so hybride offene Ökosysteme. Solche Veröffentlichungen haben dazu geführt, dass solche offenen Lösungen auf ausgewählten Benchmark-Tests ernsthafte Konkurrenten zu proprietären Programmieragenten geworden sind, auch wenn sie nicht in allen Bereichen konsequent überlegen sind. Die eigenen Bewertungen der Anbieter zeigen oft, dass proprietäre Spitzenmodelle bei verschiedenen Programmiertests weiterhin vorn liegen. Der entscheidende Punkt ist nicht, dass ein Modell alle anderen schlägt, sondern dass ein preiswertes Modell mit offenen Gewichten, kombiniert mit einem sorgfältig entworfenen Tooling, mit teuren geschlossenen Systemen konkurrieren kann.
Was ein gutes Tooling beinhaltet
Die Leistung entsteht durch die Kombination aus Modell und Tooling, wobei das Tooling aus mehreren Komponenten besteht:
- Kontextauswahl. Entscheidung darüber, was bei jedem Aufruf des Modells verwendet wird, sodass die relevanten Dateien, Datensätze oder Dokumente vorhanden sind und Störungen vermieden werden.
Entwurfsentscheidungen, die ein Harness prägen
Jeder Framework trifft Entscheidungen, die stillschweigend eine Obergrenze dafür setzen, was der Agent tun kann, und einige davon verdienen bereits frühzeitig Aufmerksamkeit.
Wie viele Tools und wie sind sie beschrieben? Dem Modell zwanzig überschneidende Tools zu geben, schadet in der Regel mehr als fünf klar definierte Tools. Namen, Beschreibungen sowie Argumentstrukturen fungieren im Grunde als Anweisungen; unklare Tool-Definitionen führen daher zu falschen Aufrufen.
Wie viel soll gespeichert werden? Lange Historien verdrängen nützlichen Kontext. Frameworks kürzen in der Regel den Kontext, fassen ihn zusammen oder speichern Notizen außerhalb der Anweisungen und holen sie bei Bedarf wieder ab. Was gespeichert wird und für wie lange, beeinflusst maßgeblich, ob ein Agent bei einer langfristigen Aufgabe kohärent bleibt.
Wo den Menschen platzieren. Einige Aktionen, wie das Lesen einer Datei, lassen sich sicher automatisieren. Andere, wie das Löschen von Daten oder das Überweisen von Geld, erfordern eine Genehmigungsstufe. Die Einstellung dieser Regeln ist eine Entscheidung des Steuerungssystems und keine Entscheidung des Modells.
Was als abgeschlossen gilt. Eine Schleife benötigt eine Beendigungsregel, wie das Bestehen von Tests, eine überprüfte Antwort oder einen Schrittbudget. Ohne diese beendet der Agent entweder frühzeitig oder läuft weiter.
Eine praktische Art, anzufangen
Falls Sie einen Agenten entwickeln, beginnen Sie mit dem kleinstmöglichen Framework, das eine echte Aufgabe von Anfang bis Ende erledigen kann: ein Modell, zwei oder drei Tools, eine Schleife mit einer Schrittanzahlbegrenzung sowie eine schriftliche Definition des Erfolgs. Sammeln Sie anschließend zehn bis zwanzig echte Aufgaben, führen Sie sie aus, lesen Sie die Protokolle und beheben Sie zuerst die häufigsten Fehler. Der Austausch des Modells erfolgt später, sobald Sie wissen, dass das Framework nicht der begrenzende Faktor ist. Diese Reihenfolge verhindert, dass Sie Probleme, die eigentlich in den umgebenden Tools liegen, dem Modell zuschreiben.
Wie der Dateizugriff funktioniert
Ein Modell kann die Dateien auf einem Computer nicht direkt anfassen. Das Framework stellt kontrollierte Werkzeuge zur Verfügung, mit denen Verzeichnisse aufgelistet, Dateinamen gesucht, relevanter Inhalt abgerufen, Dateien geöffnet und bearbeitet, Code ausgeführt sowie Ergebnisse gespeichert werden können. Das Modell wählt anschließend aus, welche Informationen oder Aktionen es benötigt. Das Framework validiert und führt diese Anfrage aus, gibt das Ergebnis zurück und fügt es zum Kontext hinzu. Der Austausch wiederholt sich, bis das Modell entscheidet, dass die Aufgabe abgeschlossen ist:
Das Modell beantragt eine Aktion, das Framework führt sie aus, das Ergebnis wird zurückgegeben und das Modell wählt die nächste Aktion aus.
Zum Beispiel könnte ein Modell, dem die Behebung eines fehlerhaften Tests aufgetragen wird, zunächst eine Auflistung der Verzeichnisse anfordern, anschließend die Testdatei sowie das getestete Modul öffnen, eine Änderung vorschlagen und schließlich einen Testlauf beantragen. Bei jedem Schritt entscheidet das Framework, ob die Anfrage zulässig ist, führt sie aus und berichtet über das Eintretende.
Das Evaluationsframework ist genauso wichtig
Das Erstellen eines Agenten-Frameworks ist nur die halbe Miete. Die andere Hälfte besteht aus einem Evaluationsframework, das zeigt, ob der Agent funktioniert. Es prüft unter bedingungenähnlichen Produktionsumgebungen, ob das gesamte System die richtigen Werkzeuge auswählen kann, von Fehlern wiederherstellen kann, die Kosten im Griff behält, Sicherheitsregeln einhält und Aufgaben konsequent abschließt. Das ist mehr als nur das Bestehen eines isolierten Benchmarks.
Ein Agenten-Framework hat viele miteinander verbundene Komponenten, und jede davon kann der Ort sein, an dem sich Regressionen verstecken können: Anfragen, Kontextregeln, Werkzeuge, Speicherpolitiken, Planungsschleifen, Überprüfungen, Berechtigungen und Wiederherstellungsmechanismen. Ohne ein Evaluationsset kann ein Team nicht erkennen, ob eine Änderung an einer dieser Komponenten geholfen hat oder heimlich einen neuen Fehler eingeführt hat. Daher bilden die beiden Frameworks einen Feedbackkreislauf:
- Sammeln Sie repräsentative Aufgaben ein, einschließlich realistischer Arbeitsabläufe, schwieriger Fälle sowie zuvor aufgetretener Fehler.
- Führen Sie das gesamte System sowie das aktuelle Modell zusammen aus.
- Überprüfen Sie die Ergebnisse: Erfolg, Spuren, Tool-Aufrufe, Fehler, Kosten und Latenz.
- Ändern Sie einen Bestandteil – sei es ein Prompt, ein Tool, ein Modell, eine Speicherpolicy, eine Schleife oder eine Routing-Regel.
- Führen Sie die Bewertungen erneut an den zurückgehaltenen Aufgaben sowie bei Regressionsfällen durch.
- Behalten Sie nur jene Änderungen bei, die nachweislich das gewünschte Gleichgewicht aus Genauigkeit, Zuverlässigkeit, Sicherheit, Geschwindigkeit und Kosten verbessern.
Kurz gesagt: Bauen, bewerten, Fehler finden, das Framework verbessern, erneut bewerten.
Auswertung einer Spur
Die Bewertung fällt am leichtesten, wenn man erkennen kann, was der Agent tatsächlich getan hat. Ein nützliches Protokoll dokumentiert jeden Modellaufruf, das angeforderte Tool, die Argumente, das zurückgegebene Ergebnis, die verwendeten Token sowie die benötigte Zeit. Wenn eine Aufgabe fehlschlägt, sollte man im Protokoll nach dem ersten Fehlerschritt suchen und nicht nach dem letzten. Oft liegt die Ursache bereits früh: ein fehlendes Datei im Kontext, eine unklare Toolbeschreibung oder eine falsche Annahme, die alle späteren Schritte beeinflusst. Die Behebung dieses einen Problems behebt in der Regel eine ganze Reihe von Fehlern – deshalb ist die Überprüfung des Protokolls eine der produktivsten Gewohnheiten, die ein Team annehmen kann.
Ist das Modell noch wichtig?
Ja. Neuere Modelle verbessern kontinuierlich ihr Fähigkeitsprofil in Bereichen wie logisches Denken, Programmieren, Befolgung von Anweisungen, Genauigkeit bei Tool-Aufrufen, Kontextkapazität, Geschwindigkeit, Kosteneffizienz sowie multimodalen Fähigkeiten, und ein Framework kann nicht zuverlässig eine Fähigkeit schaffen, die dem Modell fehlt. Doch das Modell ist nicht mehr das gesamte Produkt.
Wenn mehrere Modelle für eine Aufgabe ausreichend gut sind, kann das Framework den größten Teil des verbleibenden Unterschieds zwischen den Produkten ausmachen. Die Suche nach der richtigen Datei, Tools mit offensichtlichen Abläufen, eine Zustandsverwaltung, die abgeschlossene Arbeiten speichert, eine Überprüfung, die fehlerhafte Änderungen erkennt, Berechtigungen, die gefährliche Schritte verhindern, sowie Mechanismen zur Wiederherstellung nach Fehlern tragen alles dazu bei.
Das deutet auf eine einfache Arbeitsteilung hin, die auch eine praktische Checkliste für die Überprüfung jedes Agentenprojekts darstellt. Fragen Sie nach dem, was das Modell plausibel leisten kann, was das Harness hinzufügen muss, damit diese Fähigkeit zuverlässig zum Vorschein kommt, und welche Belege die Evaluierungen dafür liefern.
- Das Modell definiert die oberste Grenze dessen, was das System leisten kann.
- Das Harness wandelt diese Grenze in zuverlässige, wiederholbare Ergebnisse um.
- Die Evaluierung bestätigt, ob das fertige System tatsächlich die versprochenen Leistungen erbringt – was eine andere Frage ist als die, ob das Modell intelligent ist.
Deshalb konzentriert sich so viel Anwendungsentwicklung heutzutage auf Harnesses und Evaluierungen. Im Harness schafft ein Team einen nachhaltigen Vorteil durch private Kontexte, sicherere Tools, branchenspezifische Arbeitsabläufe, Speicherfunktionen, Fehlerbehebung und eine gute Benutzererfahrung.
Die Antwort auf die zentrale Frage
Kann ein Modell ohne „Gehäuse“ zu einem echten, funktionalen Agenten werden? Nein. Ein Modell allein verfügt nicht über die Umgebung, um Aktionen auszuführen, auf externe Systeme zuzugreifen, abgeschlossene Schritte zu merken, die Auswirkungen seiner Entscheidungen zu beobachten und weiterhin auf ein Ziel hinzuarbeiten. Das Modell ist das Gehirn und das Rechenwerkzeug. Das „Gehäuse“ hingegen sind Körper, Werkzeuge, Gedächtnis, Rückkopplungsschleifen, Berechtigungen und Schutzmechanismen, die Vorhersagen in kontrollierte Aktionen umwandeln.
Oder auf einen Nenner gebracht: Ein KI-Agent ist ein KI-Modell plus ein „Gehäuse“.