Agent-Harness-Design: Das richtige Modell wählen

Modellrouting ist eine Frage der betrieblichen Steuerung, kein Wettbewerb um Ranglistenplätze. Datenschutz und Vorgaben zum geografischen Speicher- und Verarbeitungsort bestimmen zuerst den zulässigen Modellpool; Aufgabenerfolg und Ausgabequalität entscheiden, was innerhalb dieses Pools funktioniert. Erst danach sollten Teams Tokens, Latenz und Kosten optimieren. Lokale Modelle können wirksam sein, benötigen jedoch meist eine stärkere Aufgabenzerlegung, Retrieval und deterministische Verifikation.

Der Agent Harness ist die produktive Einheit

Ein KI-Agent im Unternehmen ist kein Modell mit einem langen System-Prompt. Seine Ausführungsumgebung, der Agent Harness, umfasst die Annahme von Anfragen, den Kontextaufbau, Richtlinienprüfungen, die Modellausführung, Werkzeugzugriff, Zustand, Verifikation, Wiederholungslogik, Beobachtbarkeit und Eskalation. Das Modell ist darin eine austauschbare Komponente.

Modellvergleiche außerhalb des Agent Harness sagen Ergebnisse im Produktivbetrieb häufig schlecht voraus. Ein Modell kann im Benchmark überzeugen und an den Formaten, Berechtigungen, Begriffen oder Abläufen eines Unternehmens scheitern. Ein anderes wirkt im offenen Chat schwächer, arbeitet aber zuverlässig, wenn die Aufgabe zerlegt, Nachweise abgerufen und Ausgaben anhand deterministischer Vorgaben geprüft werden.

Das „beste Modell“ zu wählen, ist daher die falsche Abstraktion. Wir wählen einen zulässigen Ausführungspfad für eine definierte Aufgabe. Dieser kann ein Modell, mehrere spezialisierte Aufrufe, ein lokales oder extern betriebenes Modell oder überhaupt kein Modell nutzen. Erfolg liegt erst vor, wenn die Aufgabe einen verifizierten Geschäftszustand erreicht.

Die Architektur sollte diese Austauschbarkeit ausdrücklich abbilden. Eine threadbasierte Betriebsschicht für KI trennt Nutzerkontext und ausführende Komponente, sodass Routing, Zustand, Autorisierung und Verifikation bei einem Modellwechsel stabil bleiben.

Prüfpunkt eins: Datenschutz, Speicher- und Verarbeitungsort sowie vertragliche Zulässigkeit

Routing beginnt vor der Qualitätsprüfung mit der Frage, ob ein Modellendpunkt die Daten erhalten und die Aktion ausführen darf.

Für jede Aufgabenklasse definieren wir ein Zulässigkeitsprofil. Es umfasst:

• Datenklasse und Vorhandensein personenbezogener, vertraulicher, regulierter oder exportkontrollierter Informationen;
• vorgeschriebene Verarbeitungs- und Speicherregionen;
• Bedingungen für Aufbewahrung, Protokollierung, Trainingsnutzung und Löschung;
• Unterauftragsverarbeiter und Vorgaben für grenzüberschreitende Übertragungen;
• Anforderungen an Verschlüsselung, Identität und Zugriffskontrolle;
• Pflichten zu Audit-Protokollen und Vorfallmeldungen;
• ob Werkzeuge Produktivsysteme lesen oder verändern dürfen;
• Zulässigkeit der Weitergabe abgerufener Dokumente aus einer kontrollierten Umgebung.

Das sind Routing-Vorgaben, kein nach dem Start angehängter Richtlinienabsatz. Enthält eine Aufgabe Daten mit eingeschränkter Nutzung, muss der Router Endpunkte ausschließen, die das Profil nicht erfüllen. Das Entfernen sensibler Angaben kann manchmal eine weniger eingeschränkte Folgeaufgabe ermöglichen. Dieses Verfahren muss jedoch zuverlässig, protokolliert und für die betroffenen Formate getestet sein. Einen Namen zu ersetzen, während eine eindeutige Kontonummer oder eine wirtschaftlich sensible Kombination von Fakten erhalten bleibt, ist keine wirksame Anonymisierung.

Die Vorgaben zum Speicher- und Verarbeitungsort gelten auch für den umgebenden Agent Harness. Prompts an einen freigegebenen regionalen Endpunkt zu senden, reicht nicht, wenn Ausführungsprotokolle, Vektorindizes, Fehlerprotokolle oder Warteschlangen für menschliche Prüfungen anderswo gespeichert werden. Wir prüfen den gesamten Datenpfad: Anfrageannahme, temporäre Dateien, Retrieval, Inferenz, Werkzeugergebnisse, Beobachtbarkeit, Backups und Supportzugriff.

Dieser Prüfpunkt erzeugt erlaubte Routen, wählt aber keinen Gewinner. Ein lokales Modell kann für eine Aufgabe vorgeschrieben, für eine andere optional und für eine dritte ungeeignet sein. Richtlinien begrenzen die Auswahl; Nachweise vervollständigen sie.

Prüfpunkt zwei: Aufgabenerfolg, dann Qualität

Im zulässigen Pool prüfen wir zuerst den Aufgabenerfolg: Hat der Workflow den beabsichtigten Zustand erreicht? Für eine Recherche kann das eine belegte Antwort mit auflösbaren Quellenverweisen sein, für eine Extraktion ein schemakonformer Datensatz mit Bezug zu konkreten Quellpassagen. Eine operative Aktion kann einen gültigen Plan für einen Probelauf ohne Änderungen, eine freigegebene Zustandsänderung und eine erfolgreiche Kontrolle des Ergebnisses erfordern.

Aufgabenerfolg geht über Antwortqualität hinaus. Eine elegante Antwort, die nicht geparst werden kann, nicht verfügbare Nachweise zitiert oder ein verbotenes Werkzeug aufruft, ist eine gescheiterte Ausführung. Umgekehrt kann eine knappe Ausgabe erfolgreich sein, wenn sie den Prozess zuverlässig abschließt.

Wir definieren anhand repräsentativer Arbeit ein Evaluationsset. Jeder Fall enthält die Eingabe, zulässige Nachweise, den erwarteten Zustandsübergang, zwingende Fehlerkriterien und ein Bewertungsraster. Das Set sollte umfassen:

• häufige Standardfälle;
• Grenzfälle nahe einer Richtlinien- oder Qualitätsgrenze;
• fehlende, veraltete, doppelte oder widersprüchliche Eingaben;
• Ausfälle von Werkzeugen und Abhängigkeiten;
• Prompt-Injection-Versuche oder Angriffe über nicht vertrauenswürdige Inhalte;
• Fälle, in denen zwingend auf die Ausführung verzichtet oder eskaliert werden muss;
• relevante Sprach- und Formatvariation.

Harte Vorgaben werden vor subjektiven Präferenzen bewertet. Schemagültigkeit, korrekte Werkzeugwahl, Einhaltung der Autorisierung, belegte Quellenverweise und ein gegebenenfalls erforderlicher Verzicht auf die Ausführung gelten als bestanden oder nicht bestanden. Inhaltliche Vollständigkeit, Klarheit und Nutzen können nach einem Bewertungsraster beurteilt werden. Elegantere Prosa gleicht eine geringere Quote verifizierter Aufgabenabschlüsse nicht aus.

Domänenspezifische Agent Skills stabilisieren diese Evaluation, weil Verfahren und erforderliche Prüfungen als explizite Artefakte vorliegen, statt in jedem Gespräch neu erarbeitet zu werden.

Prüfpunkt drei: Tokens, Latenz und Kosten

Erst wenn Routen die Erfolgs- und Qualitätsanforderungen erfüllen, optimieren wir ihre Effizienz. Entscheidend sind die Kosten je verifizierter Aufgabe, nicht der Preis je Eingabe-Token.

Ein günstigeres Modell kann teurer werden, wenn es Wiederholungsversuche, Prüfungen oder nachgelagerte Korrekturen benötigt. Eine schnelle Erstantwort kann eine schlechte Gesamtlatenz verbergen, wenn der Agent Harness ungültige Ausgaben wiederholt reparieren muss. Ein größeres Kontextfenster kann zum wahllosen Laden von Daten verleiten und dadurch Kosten und Fehlerrisiken erhöhen.

Wir messen:

Dimension	Kennzahl auf Ebene des Agent Harness
Erfolg	verifizierte Abschlüsse je zulässigem Versuch
Qualität	Abnahme im ersten Durchlauf, Fehlerschwere und Anteil durchgelassener Fehler
Tokens	Tokens für Eingaben, zwischengespeicherte Eingaben, Ausgaben und Wiederholungsversuche je verifiziertem Abschluss
Latenz	Median und lange Laufzeiten am oberen Ende der Verteilung vom Auslöser bis zum verifizierten Zustand
Kosten	Inferenz, Retrieval, Werkzeuge, Prüfung und Nacharbeit je verifiziertem Abschluss
Stabilität	Leistungsschwankungen über Zeit, Formate und Nachfrageklassen

Normalisierte Indizes machen interne Vergleiche verständlich, ohne falsche Präzision zu suggerieren. Wir setzen die aktuelle freigegebene Route für qualitätsbereinigte Kosten und Gesamtlatenz auf Baseline = 100. Ein Kandidat ist nur nützlich, wenn sein niedrigerer Kostenindex keine schlechtere Erfolgsquote, höhere Ausnahmelast oder längere Prüfzeit verdeckt. Die zugrunde liegenden Zählwerte und Definitionen bewahren wir für Audits auf, auch wenn externe Berichte normalisierte Werte verwenden.

Danach optimieren wir gezielt: Prompt-Caching kann wiederholten Richtlinienkontext reduzieren, kürzere abgerufene Passagen können Ablenkung vermindern, und parallele lesende Werkzeugaufrufe können die Latenz verbessern. Ein kleineres Modell kann die Klassifikation übernehmen, während eine leistungsfähigere Route mehrdeutige Syntheseaufgaben bearbeitet. Deterministischer Code kann einen Inferenzaufruf vollständig ersetzen.

Aufgaben routen, nicht Nutzer

Statisches Routing nach Abteilung verschwendet Fähigkeiten und Geld. Dieselbe Person kann eine öffentliche Zusammenfassung, einen vertraulichen Vergleich, einen Datenabgleich und eine Schreibaktion im Produktivsystem anfordern – Aufgabenklassen mit unterschiedlichen Anforderungen an Zulässigkeit, Qualität und Befugnis.

Das Routing folgt einer strukturierten Aufgabenbeschreibung:

task_type: extract | classify | synthesize | plan | act | verify
data_class: public | internal | confidential | restricted
residency: approved_regions
authority: read | recommend | dry_run | approved_write
evidence: source_ids and freshness requirements
output_contract: schema or rubric version
risk: consequence and reversibility
latency_budget: interactive | asynchronous | batch

Der Router sollte möglichst deterministisch sein. Datenklasse, Speicher- und Verarbeitungsort sowie Befugnis sind Richtlinienentscheidungen. Sie dürfen nicht davon abhängen, ob ein Modell eine Anfrage als „sensibel“ einschätzt. Ein Klassifikator kann die Anfrageannahme unterstützen; bei Unsicherheit muss die sicherere Route gewählt oder eine konkrete Rückfrage gestellt werden.

Die Modellwahl erfolgt anschließend innerhalb des erlaubten Zweigs. Pro Route speichern wir Richtlinienversion, Modellversion, Prompt- oder Skill-Version, Kennungen der abgerufenen Nachweise, Werkzeugaufrufe, Ergebnisse der Prüfkomponenten und Endzustand. Dieses Protokoll macht Fehler diagnostizierbar und Vergleiche reproduzierbar.

Warum lokale Modelle einen anderen Agent Harness benötigen

Lokale Inferenz wird oft so diskutiert, als reiche es, denselben Prompt von einem extern betriebenen Endpunkt auf lokale Hardware zu verschieben. Das ist selten der Fall. Lokale Modelle können eine starke Datenschutzkontrolle, kalkulierbare Grenzkosten, Offline-Betrieb und geringe Latenz für begrenzte Aufgaben bieten. Zugleich können sie Anweisungen weniger zuverlässig befolgen, Werkzeuge schlechter auswählen, bei langen Kontexten unzuverlässiger sein oder weniger konsistent mit mehreren Sprachen umgehen als die jeweils stärksten extern betriebenen Alternativen.

Die richtige Antwort ist, diese Unterschiede nicht zu verbergen, sondern den Agent Harness anzupassen.

Stärker zerlegen

Geben Sie dem Modell jeweils eine begrenzte Umwandlungsaufgabe. Trennen Sie Dokumentauswahl, Extraktion, Klassifikation, Entwurf und Verifikation. Jede Stufe sollte eng definierte Ein- und Ausgabeanforderungen haben. Das reduziert gleichzeitige Anweisungen und schafft Prüfpunkte, an denen deterministische Kontrollen die Weitergabe von Fehlern stoppen können.

Ein lokaler Pfad kann zunächst relevante Abschnitte auswählen, dann Aussagen in ein Schema extrahieren, jede Aussage einer Quellpassage zuordnen und nur aus akzeptierten Aussagen einen Entwurf formulieren. Das erfordert mehr Orchestrierung als ein großer Prompt, lässt sich aber leichter bewerten und korrigieren.

Weniger, aber besser abrufen

Ein gesamtes Repository oder eine Dokumentensammlung in den Kontext zu laden, ist kein Retrieval: Es verlagert das Auswahlproblem auf das Modell. Lokale Routen profitieren von strukturierten Indizes, Metadatenfiltern, Aktualitätsvorgaben und kurzen Nachweispaketen. Retrieval sollte Quellenkennungen und Passagen liefern, damit nachgelagerte Prüfungen die Quellenbindung der Antwort bestätigen können.

Die praktischen Muster für einen lokalen KI-Assistenten mit Retrieval und Websuche zeigen, warum lokale Inferenz eine Werkzeug- und Nachweisschicht benötigt und nicht allein auf dem Modellwissen beruhen kann.

Deterministisch verifizieren

Nutzen Sie nach Möglichkeit Schemas, Parser, Listen zulässiger Werte, Datenbankbedingungen, Berechnungen, Systeme zur Richtlinienprüfung und Kontrollen nach einer Änderung. Ein Modell kann eine Änderung vorschlagen; Code sollte bestätigen, dass Pflichtfelder vorhanden sind, Kennungen aufgelöst werden können, Summen übereinstimmen, Berechtigungen die Aktion erlauben und der Zustand danach dem freigegebenen Plan entspricht.

Für nicht deterministisch prüfbare Inhalte braucht es ein Bewertungsraster und einen unabhängigen Prüfpfad. Derselbe Aufruf darf seine Ausgabe nicht zugleich erzeugen, bewerten und freigeben. Ein modellbasierter Evaluator muss anhand menschlicher Urteile kalibriert werden und außerhalb der abschließenden Befugnisentscheidung bleiben.

Kaskaden, Ausweichrouten und Verzicht auf die Ausführung

Ein nützlicher Router schickt nicht jede zulässige Aufgabe an das stärkste Modell. Eine Kaskade beginnt mit der günstigsten Route, die die Abnahmeanforderungen für diese Aufgabenklasse bereits erfüllt hat, und eskaliert bei beobachtbaren Fehlern.

Die Signale sollten konkret sein: ein nach Reparatur weiterhin ungültiges Schema, fehlende Nachweise, widersprüchliche Quellen, niedrige kalibrierte Konfidenz, ein nicht verfügbares Werkzeug, eine Richtliniengrenze oder eine fehlgeschlagene Verifikation. Die Tokenzahl allein ist kein Qualitätssignal. Auch die verbale Unsicherheitsangabe des Modells ist keines, solange sie nicht für die Aufgabe kalibriert wurde.

Ausweichrouten müssen inhaltlich konsistent bleiben. Scheitert die primäre Route an Vorgaben zum Speicher- und Verarbeitungsort, darf die Ausweichroute diese nicht ignorieren. Ist ein Werkzeugaufruf nicht verfügbar, darf eine reine Chatroute nicht so tun, als wäre die Aktion erfolgt. Veraltete Nachweise werden durch ein stärkeres Modell nicht aktuell.

Auf die Ausführung zu verzichten, ist erfolgreich, wenn die Aufgabenvereinbarung eine Eskalation verlangt. Deshalb zählen wir „korrekt verweigert oder eskaliert“ als Aufgabenerfolg. Andernfalls belohnt der Routing-Druck Systeme für Arbeit jenseits ihrer Nachweise oder Befugnisse.

Zustand, Versionen und Reproduzierbarkeit

Modelle und Endpunkte ändern sich. Auch bei unverändertem Modellnamen kann sich das Verhalten durch eine neue Version, Ausführungskonfiguration, einen System-Prompt, Retrieval-Index, eine Werkzeugdefinition oder Richtlinie verschieben. Der Agent Harness muss die gesamte Ausführungsvereinbarung versionieren.

Mindestens erfassen wir:

• Aufgaben- und Richtlinienversion;
• Modellanbieter, Endpunktregion und Modellversion;
• Versionen von Prompt, Skill und Werkzeugschema;
• Retrieval-Abfrage, Quellenkennungen und Aktualitätszeitstempel;
• Sampling-Einstellungen und Zeitlimits;
• Versionen und Ergebnisse der Prüfkomponenten;
• Wiederholungs-, Ausweich- und menschliche Prüfereignisse;
• abschließende Aktion und Nachweis der Ergebniskontrolle.

Betriebliche Reproduzierbarkeit entsteht aus Eingaben, Konfiguration, externen Aktionen und Verifikationsnachweisen, nicht aus einer uneingeschränkten Speicherung interner Gedankengänge. Sensible Ausführungsprotokolle unterliegen den betrieblichen Regeln zur Datenminimierung und Aufbewahrung.

Die Verfahrensdisziplin beim Anpassen eines projektspezifischen Agenten ist hier relevant: Persistente Arbeitsumgebungen und wiederverwendbare Verfahren helfen nur, wenn Änderungen, Parallelität und Fehlermuster beobachtbar bleiben.

Ein praktischer Auswahlprozess

Wir verwenden einen gestuften Auswahlprozess:

1. Aufgabenklassen definieren. Extraktion, Synthese, Planung, Aktion und Verifikation trennen und nicht zu einem einzigen Wert mitteln.
2. Zulässigkeitsprüfungen anwenden. Routen ausschließen, die Datenschutz-, Anforderungen an den Speicher- und Verarbeitungsort, vertragliche Anforderungen oder Befugnisanforderungen verletzen.
3. Evaluationsset aufbauen. Repräsentative Fälle, Grenzfälle, Angriffsversuche und zwingende Eskalationsfälle mit einem unveränderlichen Nachweisstand verwenden.
4. Im echten Agent Harness testen. Retrieval, Werkzeuge, Zeitlimits, Wiederholungsversuche und Prüfkomponenten einbeziehen.
5. Harte Fehler prüfen. Routen verwerfen, die Anforderungen an Schema, Nachweise, Autorisierung oder den Verzicht auf Ausführung verletzen.
6. Erfolg und Qualität bewerten. Sowohl die Durchschnittsleistung als auch die seltenen Fälle mit schweren Fehlern prüfen.
7. Gesamteffizienz messen. Tokens, Latenz, Inferenzkosten, Prüfzeit, Wiederholungsversuche und Nacharbeit je verifiziertem Abschluss vergleichen.
8. Im Parallelbetrieb ohne Änderungen oder im Probelauf pilotieren. Schwankungen der tatsächlichen Nachfrage ohne unverifizierte Schreibaktionen beobachten.
9. Je Aufgabenklasse freigeben. Route, Grenzen, Ausweichroute und Ablaufdatum der Entscheidung dokumentieren.
10. Kontinuierlich neu prüfen. Bei Modellwechseln, Abweichungen, neuen Datenklassen, wiederholten Ausnahmen oder wesentlichen Preisänderungen erneut prüfen.

Das Ergebnis ist eine versionierte Routing-Richtlinie, kein dauerhaftes Ranking.

Die Entscheidungsregel

Die Reihenfolge ist der Kern verantwortungsvollen Modellroutings: Datenschutz, Speicher- und Verarbeitungsort sowie vertragliche Prüfkriterien bestimmen, was erlaubt ist. Verifizierter Aufgabenerfolg und Qualität bestimmen, was die Aufgabe bewältigt. Tokens, Latenz und Gesamtkosten bestimmen, was unter den verbleibenden Routen effizient ist.

Eine umgekehrte Reihenfolge führt zu vorhersehbaren Fehlern. Kostenorientiertes Routing schickt sensible Aufgaben an unzulässige Endpunkte oder minderwertige Ergebnisse in teure Prüfschleifen. Modellorientiertes Routing richtet Prozesse auf einen bevorzugten Anbieter aus. Benchmarkorientiertes Routing optimiert für Aufgaben, die das Unternehmen möglicherweise gar nicht bearbeitet.

Wir bauen den Agent Harness so, dass Modelle wechseln können, ohne Richtlinien, Zustand oder Nachweise aufzulösen. Extern betriebene Modelle, lokale Modelle und deterministische Dienste haben jeweils ihre Rolle. Richtig ist das kleinste zulässige System, das die definierte Aufgabe innerhalb der Qualitätsgrenze abschließt und das Ergebnis nachweist.

Weiterführende Beiträge

• Referenzarchitektur für eine threadbasierte Betriebsschicht für KI – Routing, typisierter Zustand, Autorisierung, Ausführung und Verifikation
• Agent Skills für domänenspezifische Geschäftsprozesse entwickeln – Verfahren und fachliche Prüfungen in expliziten Artefakten festhalten
• Lokalen KI-Assistenten mit Websuche aufbauen: MCP + Ollama einrichten – praktisches Muster für lokale Inferenz, Retrieval und Werkzeuge