Werden intelligentere Modelle das Einsatzgebiet der Agenten verringern oder es wichtiger machen?

Vor einigen Jahren bedeutete die Verbesserung einer KI-Funktion hauptsächlich die Verbesserung des Modells: Man wählte ein stärkeres Modell, justierte es feinab, fütterte es mit saubereren Daten und stellte es über eine API zur Verfügung. Heute kann ein Produktionsystem um ein Modell Suchfunktionen, Speichermöglichkeiten, Werkzeuge, Planungsfunktionen, Bewertungsmethoden, Überwachungsmöglichkeiten, Schutzmechanismen, Wiederholungsversuche, Kontextverwaltung sowie mehrere kooperierende Agenten umfassen. Der Sammelbegriff für diese umgebende Schicht ist „Harness“. Das wirft eine praktische Frage für alle auf, die entscheiden müssen, wo sie ihre Entwicklungszeit investieren sollen: Wenn sich die Modelle weiter verbessern, wird diese Schicht dann dünner werden oder zu dem wichtigsten Teil des Systems? Dieser Artikel erörtert beide Seiten der Argumentation und endet mit einer Methode, um herauszufinden, welche Teile des eigenen „Harness“ voraussichtlich schrumpfen und welche wachsen werden.

Was ein Harness ist – und was er nicht ist

Ein Harness ist die Software um ein Modell herum, die es ermöglicht, eine Aufgabe zuverlässig auszuführen. Das Modell liefert die Logik; der Harness schafft die Bedingungen, unter denen diese Logik nützliche Ergebnisse erzeugt. In der Praxis bündelt er mehrere Aspekte: Zugriff auf Tools und APIs; Abruf, Kontext und Speicherung; Aufteilung der Arbeit in geplante Schritte sowie Überwachung des Zustands; Überprüfung der Ausgaben, Rückgabe von Fehlern und erneute Versuche; Durchsetzung von Berechtigungen und Schutzmaßnahmen sowie Messung und Beobachtung dessen, was geschieht.

Der wichtige Punkt ist, dass ein Harness nicht versucht, das Modell intelligenter zu machen. Sein Ziel ist ein System, das insgesamt leistungsfähiger, zuverlässiger und sicherer ist. Betrachten wir Text-zu-SQL. Ein Modell weiß möglicherweise bereits, wie man eine Abfrage schreibt. Der Harness übermittelt ihm das Schema, ermöglicht es ihm, Metadaten der Tabellen zu inspizieren, führt die Abfrage aus, fängt Fehler auf, gibt das Ergebnis oder die Fehlernachricht zurück, triggert bei Bedarf einen Neversuch und hilft dabei zu beurteilen, ob die endgültige Antwort gut genug ist. Das Modell denkt nach; der Harness stellt den Zyklus um dieses Denken bereit. Dieser Zyklus ist am wichtigsten, sobald das Modell mehr tut als nur Text zu erzeugen.

Für einen genaueren Blick darauf, wie sich die Verantwortlichkeiten zwischen Modell und Rahmenwerk in einem einzelnen Agenten aufteilen, lesen Sie woher ein toxisches AI-Verhalten eigentlich kommt. Der Fokus liegt hier darauf, wie sich diese Aufteilung im Laufe der Zeit verändert.

Der Argument für ein einfacheres Rahmenwerk

Es ist völlig vernünftig anzunehmen, dass bessere Modelle weniger Unterstützung benötigen. Stellen Sie sich ein Modell vor, das zuverlässig all das folgende leistet:

• Komplexe Anweisungen befolgt.
• Das Relevanten behält.
• Das richtige Werkzeug wählt.
• Aufgaben mit vielen Schritten plant.
• Sich erholt, wenn etwas fehlschlägt.
• Sieht seine eigenen Ausgaben überprüft.
• Erkennen kann, wenn es unsicher ist.
• Den Zustand bei lang andauernden Aufgaben verfolgt.

Mit einem solchen Modell erscheint ein Großteil der heutigen Orchestrierung überflüssig. Stärkere Schlussfolgerungsmechanismen verringern den Bedarf an expliziten Planungsschichten. Bessere Nutzung nativer Tools reduziert die notwendige manuelle Logik zur Auswahl der Tools. Eine bessere Handhabung langer Kontexte verringert den Bedarf an aufwendigen Speichersystemen. Zuverlässige Selbstbewertung reduziert den Bedarf an externen Validierungsprozessen.

Dies könnte tatsächlich eintreten – und an manchen Stellen ist es bereits der Fall: Prompt-Tricks sowie Parsing-Lösungen, die für frühere Modelle unerlässlich waren, sind heute oft nicht mehr notwendig. Es ist plausibel, dass die besten Lösungen der Zukunft viel einfacher gestaltet sein werden als viele der heutigen. Das ist jedoch nur die eine Seite der Medaille.

Fähigkeiten erweitern den Anwendungsbereich

Wenn ein Modell deutlich leistungsfähiger wird, nutzen Teams diese Fähigkeiten selten nur dazu, dieselbe Arbeit günstiger zu erledigen. Stattdessen richten sie sie auf schwierigere Probleme aus.

• Ein Modell, das in der Lage ist, ein Dokument zusammenzufassen, wird bald dazu aufgefordert werden, hunderte zu analysieren.
• Ein Modell, das eine einzige SQL-Anfrage schreiben kann, wird dazu aufgefordert werden, ein unternehmerisches Problem zu untersuchen, das mehrere Systeme umfasst.
• Ein Modell, das eine API aufrufen kann, wird mit einer ganzen Softwareumgebung konfrontiert.

Das Aufgabenspektrum wächst mit den Fähigkeiten, und das verändert die Aufgabe des Systems. Die Frage verschiebt sich von der Fähigkeit des Modells, eine Anfrage zu beantworten, hin dazu, ob das System es dem Modell ermöglichen kann, ein Ziel sicher und zuverlässig zu erreichen. Das sind unterschiedliche Ingenieurprobleme: Das erste betrifft die Intelligenz, das zweite Kontrolle, Vertrauen und Rechenschaftspflicht.

Fähige Agenten stellen systemrelevante Fragen

Nehmen wir an, einem immer leistungsfähigeren Agenten werden ein Browser, eine Datenbank, interne APIs, Dateien, die Ausführung von Code, Kommunikationswerkzeuge sowie Langzeitgedächtnis zur Verfügung gestellt. Intelligenz ist dann nicht mehr der begrenzende Faktor. Man muss nun Fragen beantworten wie:

• Welche Aktionen darf der Agent ausführen?
• Welche Informationen darf er einsehen?
• Wann muss er eine Genehmigung anfordern?
• Was passiert, wenn ein Werkzeug versagt?
• Wie werden Schleifen und wiederholte Aktionen verhindert?
• Wie kann jemand nachvollziehen, warum der Agent eine bestimmte Entscheidung getroffen hat?
• Wie bewertet man einen Arbeitsablauf, der 30 Minuten dauert anstelle einer einzigen Antwort zu liefern?
• Was geschieht, wenn das Modell falsch liegt, aber zuversichtlich ist?

Niels von diesen Problemen lässt sich durch ein intelligenteres Modell lösen. Ein leistungsstärkeres Modell kann die letzte Frage sogar verschlimmern, da fließende, selbstsichere Fehler schwerer zu erkennen sind. Es handelt sich dabei um Systemprobleme, und genau hier gewinnt das Harness an Bedeutung statt an Bedeutung zu verlieren.

Von Orchestrierung zur Umgebungsplanung

Viele Agentenframeworks konzentrieren sich heutzutage auf die Orchestrierung: Die Entscheidung darüber, was als Nächstes passiert, welches Tool aufgerufen wird und was an das Modell zurückgegeben wird. Da sich die Modelle immer besser selbst planen können, ist genau diese Sequenzierungslogik der Teil, der am ehesten schrumpfen wird. Was bleibt und wächst, ist eher mit der Umgebungsplanung verbunden. Das Harness definiert:

• Tools: womit der Agent interagieren kann.
• Kontext: welche Informationen ihm angezeigt werden.
• Zustand: was er zwischen den Schritten behält.
• Berechtigungen: was er ändern darf.

Feedback: Wie es erkennt, dass etwas schiefgelaufen ist.

Evaluation: Wie der Erfolg gemessen wird.

Boundaries: Wann es aufhören muss oder die Kontrolle an einen Menschen übergeben soll.

In dieser Struktur gewinnt das Modell Autonomie, während der Rahmen die Grenze um diese Autonomie darstellt. Man hört auf, den Weg zu definieren, den der Agent nimmt, und beginnt stattdessen, den Raum zu gestalten, durch den er sich bewegt.

Komplexität neigt dazu, sich zu verlagern, nicht zu verschwinden

In der Softwareentwicklung gibt es ein bekanntes Muster: Wenn eine Schicht einfacher wird, verlagert sich die Komplexität in der Regel an einen anderen Ort, anstatt zu verschwinden. Abstraktionen verbergen Komplexität – sie löschen sie nicht. Verwaltete Datenbanken beseitigten nicht die Notwendigkeit, Indexe zu verstehen, und Cloud-Plattformen beseitigten nicht die Notwendigkeit einer Kapazitätsplanung.

Agenten werden voraussichtlich denselben Weg einschlagen. Bessere Modelle könnten einen Teil der manuell erstellten Agentenlogik überflüssig machen, während gleichzeitig die Nachfrage nach stärkerer Bewertung, Sicherheit, Beobachtbarkeit, Speichermanagement, Kostenkontrolle, Zuverlässigkeitsengineering sowie Unterstützung für langlaufende Aufgaben zunimmt. Das Framework könnte für den Anwendungsentwickler weniger sichtbar werden, möglicherweise weil Anbieter und Frameworks es übernehmen, während es gleichzeitig eine zentrale Rolle bei dem Verhalten des Systems einnimmt. Eine einfachere Entwicklererfahrung bedeutet nicht unbedingt eine einfachere Architektur dahinter.

In mancher Hinsicht weniger wichtig, in anderen mehr

Die ehrliche Antwort lautet nicht „das eine“ oder „das andere“. Der Harness verliert an Bedeutung als Mittel, um schwache Modelle manuell auszugleichen. Er gewinnt an Bedeutung als Grundlage, die es fähigen Modellen ermöglicht, in der realen Welt zu funktionieren, ohne unsicher, unzuverlässig oder verschwenderisch zu werden. Zukünftige Harnesses könnten eine weniger starre Orchestrierung sowie deutlich anspruchsvollere Bewertungsmechanismen, Berechtigungen, Zustandsverwaltung, Feedback-Systeme, Überwachungsfunktionen und Umweltsteuerungen bieten.

Eine grobe Entwicklung sieht so aus:

• Zuvor: Das Modell war fast direkt mit der Anwendung verbunden.
• Heute: Das Modell befindet sich hinter Prompts, RAG-, Tools-, Agenten- und Bewertungssystemen, bevor es die Anwendung erreicht.
• In Zukunft: Das Modell und der Harness bilden gemeinsam ein autonomes System.

Der letzte Schritt ist der entscheidende. Sobald KI von der Erstellung von Antworten zur Ausführung von Aktionen übergeht, lautet die zentrale Frage nicht mehr nur, wie intelligent das Modell ist, sondern auch, wie gut die Umgebung um es herum konzipiert wurde.

Eine praktische Prüfung für Ihr eigenes System

Um zu entscheiden, wohin investiert werden soll, ordnen Sie jedes Komponenten Ihres Systems einer von zwei Gruppen zu:

• Kompensatorische Komponenten existieren, weil das aktuelle Modell in bestimmten Bereichen schwach ist: starre schrittweise Planer, aufwändige Logiken zur Auswertung und Korrektur von Ergebnissen, toolbasiertes Routing nach Schlüsselwörtern sowie Workarounds für Anfragen. Halten Sie diese Komponenten einfach und leicht lösbar und testen Sie sie erneut, sobald Sie Modelle aktualisieren, denn sie neigen am meisten dazu, zu Ballast zu werden.

Beständige Komponenten existieren, weil die Aufgabe reale Folgen hat: Berechtigungen und Sandboxing, Freigabeprozesse, Prüfprotokolle und Rückverfolgungsmöglichkeiten, Kosten- sowie Schleifenlimits, Bewertungssuiten und Zustandspersistenz. Investieren Sie angemessen in diese Aspekte, denn ein leistungsstärkeres Modell erhöht ihren Wert statt ihn zu verringern.

Ein nützliches Kriterium ist die Frage, ob eine Komponente weiterhin benötigt würde, wenn das Modell beim Schlussfolgern perfekt wäre. Wenn die Antwort ja lautet – wie bei der Zugriffskontrolle, der Nachvollziehbarkeit und der Erfolgsmessung – gehört sie zum langfristig stabilen Kern des Systems.

Kernpunkte

• Ein Framework macht das Modell nicht intelligenter; es sorgt dafür, dass das gesamte System leistungsfähiger, zuverlässiger und sicherer wird.
• Bessere Modelle werden voraussichtlich die Orchestrierungs- und Workaround-Logik reduzieren, wofür es sich lohnt, im Voraus zu planen.
• Höhere Leistungsfähigkeit erfordert größere Umfangsbetrachtungen, was Fragen zu Berechtigungen, Fehlerbehandlung, Bewertung und Rechenschaftspflicht aufwirft, die durch keine Verbesserung des Modells beantwortet werden können.
• Der Ansatz wandelt sich von der Schritt-für-Schritt-Programmierung hin zur Gestaltung der Umgebung: Werkzeuge, Kontext, Zustand, Berechtigungen, Rückmeldungen, Bewertung und Grenzen.
• Erwarten Sie, dass die Komplexität in die Infrastruktur übergeht anstatt zu verschwinden, und entwickeln Sie die dauerhaften Bestandteile Ihres Ansatzes unter Berücksichtigung dieses Aspekts.