Das AI-Agent-Glossar, übertragen auf die Produktionsinfrastruktur

Das Feld der Agenten hat ein Vokabularproblem. Nach einer Phase, in der „Harness“, „Scaffold“, „Skill“ und „Agent“ in jedem Gespräch etwas anderes bedeuteten, hat Hugging Face ein weit verbreitetes Glossar veröffentlicht, das dem Feld ein nützliches Arbeitsvokabular an die Hand gibt. Es lohnt sich zu lesen. Aber ein Glossar beantwortet die Frage: „Was bedeutet dieses Wort?“ — und die nächste Frage, mit der sich Plattform-Teams tatsächlich auseinandersetzen müssen, lautet: „Wo befindet sich dieses Ding in meinem Stack?“ Dieser Beitrag nimmt dieses Arbeitsvokabular auf und ordnet jeden Begriff der Komponente der Produktionsinfrastruktur zu, die ihn implementiert. Die Wörter stammen aus einem sich herausbildenden Community-Vokabular; die konkrete Verdrahtung ist das, was Produktionsteams umsetzen müssen.

Elif, eine Platform Engineering-Leiterin, beobachtete, wie ein Steering-Meeting vierzig Minuten mit einer Frage verbrachte, die eigentlich keine fünf Minuten hätte dauern dürfen: „Wie viele Agenten haben wir?“ Das Engineering zählte Harness-Deployments und nannte die Zahl neun. Das Data-Team zählte Prompts mit Tools und sprach von dreißig und ein paar Zerquetschten. Eine Vendor-Folie zählte jeden Workflow mit einem LLM-Aufruf und kam auf zweihundert. Niemand lag nach seiner eigenen Definition falsch; niemand teilte eine gemeinsame Definition. Dasselbe Meeting stolperte über die Frage, ob ein „Skill“ ein Tool sei, ob der neue „Sub-Agent“ für Inventarzwecke ein Agent sei und was genau das Team eigentlich kaufte, wenn bei einem Produkt „Harness enthalten“ stand. Elifs Schlussfolgerung war nicht, dass ihre Kollegen nachlässig waren. Es lag daran, dass sich die Begriffe des Fachbereichs schneller entwickelt hatten als das gemeinsame Verständnis — und dass jedes Architekturgespräch verdeckt zu einem Vokabelstreit werden würde, solange die Wörter nicht fest an Dingen im Stack verankert waren.

Die Community hat daran gearbeitet, diese Definitionen zu klären — am deutlichsten sichtbar im Agenten-Glossar von Hugging Face, das aus genau dieser Verwirrung auf der ICLR 2026 hervorgegangen ist und auf das wir uns im Folgenden stützen (und das wir zitieren) werden. Was dieser Beitrag hinzufügt, ist die zweite Spalte, die Elif fehlte: für jeden Begriff die Produktionskomponente, die ihn implementiert, und die Governance, die an ihn gebunden ist, sobald er reale Infrastruktur und nicht nur eine Diagrammbeschriftung ist. Dies ist kein Ersatz für das Hugging Face-Glossar; es ist die Infrastrukturspalte daneben. Wir gehen den Stack von innen nach außen durch — Modell, Scaffold, Harness, Agent — und behandeln dann das Arbeitsvokabular rundherum: Context Engineering, das Tool/Skill/Sub-Agent-Spektrum, Policy und die Trainingsbegriffe, die sich auch in der Produktion als wichtig erweisen. Auf diesen Beitrag folgen vier Vertiefungen; dies ist die Übersichtskarte.

1. Modell: Der kleinste Teil des Systems

Beginnen wir dort, wo das Glossar beginnt. Das Modell ist das LLM selbst: Text rein, Text raus, kein Speicher zwischen den Aufrufen, kein Loop, keine Fähigkeit, tatsächlich etwas auszuführen. Es kann die Absicht äußern, ein Tool aufzurufen — eine strukturierte Anforderung ausgeben —, aber etwas außerhalb des Modells muss dieses Tool ausführen und das Ergebnis zurückliefern. Das Modell als „den Agenten“ zu bezeichnen, ist der grundlegende Kategorienerror: Das Modell ist die Reasoning Engine, und für sich allein beantwortet es einen Prompt und stoppt.

Produktionstechnisch gesehen ist das Modell auch der austauschbarste Teil — was genau der Grund ist, warum es hinter einer Abstraktion sitzen sollte. Auf TrueFoundry werden Modelle namentlich über eine einzige OpenAI-kompatible API des AI Gateways adressiert: kommerzielle Frontier-Modelle, selbstgehostete Open-Weight-Modelle und feingetunte Checkpoints hinter einer gemeinsamen Gateway-Schnittstelle, wobei RBAC, Budgets, Observability und Guardrails zentral dort angewendet werden, wo der Datenverkehr durch das Gateway fließt. Die architekturelle Konsequenz aus „das Modell ist nur eine Komponente“ ist, dass sein Austausch eine bloße Konfigurationsänderung sein sollte — das Thema unseres Beitrags zu unified APIs — und alles andere in diesem Glossar ist das, was beim Austausch bestehen bleibt.

2. Scaffold und Harness: Die zwei Schichten, die jeder verwechselt

Hier ist die Unterscheidung, für die das Glossar existiert, und diejenige, die in der Praxis die größte Verwirrung stiftet. Das Scaffold ist die verhaltensdefinierende Schicht, von der das Modell ausarbeitet: der System-Prompt, die Tool-Beschreibungen, die Ausgabeformate, denen es folgen soll, die Regeln für das, was über Schritte hinweg mitgeführt wird. Es prägt, wie das Modell seine Welt wahrnimmt. Das Harness ist die Ausführungsschicht, die den Agenten zum Laufen bringt: der Loop, der das Modell aufruft, seine Tool-Anforderungen parst, sie tatsächlich ausführt, Ergebnisse zurückliefert, Fehler behandelt und entscheidet, wann gestoppt wird. Scaffold ist Anweisung; Harness ist Maschinerie. Produkte wie Claude Code verwenden „Harness“ oft salopp für alles, was nicht das Modell ist, was als Kurzform völlig in Ordnung ist — die Unterscheidung zeigt ihren Wert, wenn man die Schichten getrennt analysieren muss, und in der Produktion tut man das ständig: Eine Prompt-Änderung ist eine Scaffold-Änderung, die in Minuten bereitgestellt werden kann; eine Änderung an den Abbruchbedingungen oder der Fehlerbehandlung ist eine Harness-Änderung mit entsprechendem Auswirkungsradius.

Auf TrueFoundry haben die beiden Schichten zwei verschiedene Orte, was für sich genommen schon klärend wirkt. Scaffold-Artefakte — Anweisungen, Prompt-Versionen, Tool-Beschreibungen, Skills — sind verwaltete Inhalte: versioniert, überprüfbar, RBAC-gesteuert. Das Harness ist die verwaltete Runtime: Das Agent Harness von TrueFoundry führt den Plan→Act→Observe-Loop aus, führt Tools über gesteuerte Gateways aus, verwaltet die Sandbox, setzt Genehmigungsschritte durch und zeichnet die Schritte gesteuerter Agent-Harness-Läufe auf. Sie erstellen das Scaffold; die Plattform betreibt das Harness. Die auf diesen Beitrag folgende Vertiefung befasst sich ausschließlich mit dieser Trennung und der Disziplin, die in der Community nun als Harness Engineering bezeichnet wird.

2. Agent: Die Gleichung und was sie Ihnen bringt

Mit diesen beiden benannten Schichten hört der Agent auf, etwas Mystisches zu sein: Ein Agent ist ein Modell plus alles drumherum, was es ihm ermöglicht zu handeln, anstatt nur zu antworten — das Konzept, das die Community kurz als Agent = Modell + Harness zusammenfasst. Der Ursprung liegt im Reinforcement Learning, wo ein Agent einfach das ist, was Beobachtungen aufnimmt und in einem Loop Aktionen zurückgibt; die LLM-Variante behält diesen Loop bei und füllt den Schritt „Entscheiden“ mit einem Modell. Aus dieser Gleichung ergeben sich zwei praktische Konsequenzen, die beide verinnerlicht werden sollten.

Erstens: Was Benutzer als „Agentenprodukt“ erleben, ist oft das Harness und das Scaffold um das Modell herum. Wenn sich zwei Produkte, die auf demselben zugrunde liegenden Modell aufbauen, völlig unterschiedlich anfühlen, liegt der Unterschied im Harness und im Scaffold — ihrem Loop-Design, ihrem Kontextmanagement, ihren Tool-Sets. Das Modell, das Harness und das Produkt sind drei verschiedene Dinge, und die Bewertung „eines Agenten“, ohne anzugeben, in welchem Harness er gelaufen ist, ist nahezu aussagelos. Zweitens wird eine Inventarisierung überhaupt erst möglich. Elifs Frage „Wie viele Agenten haben wir?“ lässt sich beantworten, sobald ein Agent ein konkretes, registriertes Objekt ist: eine Definition (Modell + Scaffold + Tool-Freigaben) plus eine Runtime. Für Agenten, die über das Agent Harness von TrueFoundry laufen, wird der Agent zu einer registrierten Definition, die ein Modell, MCP-Server und Skills namentlich referenziert, wobei Anmeldeinformationen in der Gateway-Ebene aufbewahrt werden, anstatt in der Definition eingebettet zu sein — was den gesteuerten Teil der Agentenlandschaft zählbar und auditierbar macht, anstatt Gegenstand einer Vokabeldebatte zu sein.

Eine Agentendefinition mit Erläuterungen aus dem Glossar (exemplarisch)

Tritt man einen Schritt von der Runtime zurück, ordnet sich das gesamte Vokabular auf dieselbe Weise an: Jeder Begriff auf der linken Seite ist ein Konzept, und jeder hat rechts ein konkretes Zuhause in der Produktion.

4. Context Engineering und die zwei Speicherarten

Context Engineering ist die Disziplin der Entscheidung, was das Modell bei jedem Schritt sieht: welche Anweisungen, welche Tool-Beschreibungen, welcher Ausschnitt des Verlaufs, welche abgerufenen Fakten. Es ist keine einmalige Prompt-Entscheidung, denn in einem Agenten ist der Kontext dynamisch — die Ausgabe jedes Durchgangs prägt die Eingabe des nächsten Durchgangs, und ein Harness, das dieses Anwachsen nicht aktiv verwaltet, muss zusehen, wie sein Agent degradiert, während sich das Kontextfenster füllt. Das Glossar unterteilt die Speicherseite sauber: Das Kurzzeitgedächtnis ist das, was während eines Laufs im Fenster bleibt; das Langzeitgedächtnis bleibt über Sitzungen hinweg extern bestehen und wird bei Relevanz wieder abgerufen.

In der Produktion liegt dies in der Verantwortung des Harnesses, nicht des Prompt-Autors — kein Mensch kann den Kontext eines 40-Schritte-Laufs manuell pflegen. Das Agent Harness von TrueFoundry bietet eine Context-Engineering-Suite, die diese Kuratierung automatisch übernimmt: Kompaktierung fasst ein langes Transkript zusammen und setzt es fort; Offloading großer Ergebnisse hält eine riesige Tool-Antwort aus dem Fenster fern und lädt sie bei Bedarf; der Code-Modus ermöglicht es dem Agenten, umfangreiche Daten mit Code zu verarbeiten, anstatt sie in den Kontext einzulesen; Sub-Agenten (nächster Abschnitt) isolieren Teilaufgaben in frischen Fenstern. Wir behandeln das Fehlermuster, das dadurch verhindert wird — in der Community als Context Rot bezeichnet — in einem eigenen Beitrag; hier geht es um die Zuordnung: „Context Engineering“ bezeichnet Arbeit, die in einer verwalteten Runtime das Harness für Sie erledigt.

5. Tool, Skill, Sub-Agent: Das Delegationsspektrum

Die praktisch nützlichste Klarstellung des Glossars ist die Trennung zwischen drei Dingen, die alle nach „der Agent tut etwas“ aussehen. Ein Tool ist eine Aktion: ein einzelner Funktionsaufruf — führen Sie diesen Befehl aus, fragen Sie diese API ab —, der vom Harness ausgeführt und zurückgemeldet wird. Ein Skill ist paketiertes Wissen: eine wiederverwendbare, strukturierte Prozedur für ein mehrstufiges Ziel („untersuche den Bug, stelle eine Hypothese auf, schreibe den Fix“), die bei Bedarf in den Kontext geladen und nicht als einzelner Aufruf ausgeführt wird. Ein Sub-Agent ist ein Reasoning-Delegierter: ein Agent, der von einem anderen Agenten aufgerufen wird, mit eigenem Modell, Scaffold und Kontext, der die Teilaufgabe unabhängig bearbeitet und ein Ergebnis zurückliefert. Die Grenze verschiebt sich zwischen verschiedenen Frameworks — das Glossar räumt das ehrlich ein —, aber das Spektrum selbst ist stabil: Aktion, Prozedur, Delegierter.

Der Grund, warum die Unterscheidung in der Produktion wichtig ist, liegt darin, dass jede Stufe eine andere Governance erfordert. Ein Tool benötigt Authentifizierung und Autorisierung pro Aufruf — was das MCP Gateway bietet: Registry, zentrale Authentifizierung, Tool-basiertes RBAC, Pre-/Post-Call Guardrails. Ein Skill benötigt Versionierung und Herkunftsnachweis (Provenance) — wer hat diese Prozedur geschrieben, welche Version führt ein Agent aus —, was das Skills Registry von TrueFoundry bietet: versionierte SKILL.md-Artefakte mit RBAC, die bei Bedarf eingebunden werden. Ein Sub-Agent benötigt Identität und abgegrenzten Kontext — seinen eigenen Trace, seine eigenen Berechtigungen, Isolierung vom Fenster des Parent-Agenten —, was das Agent Harness nativ bietet. Flacht man das Spektrum zu bloßen „Tools“ ab, steuert man einen Reasoning-Delegierten wie einen Funktionsaufruf; die Vertiefung zu diesem Spektrum analysiert jede Stufe im Detail.

6. Policy: Verhalten steckt nicht in den Gewichten

Policy ist der unauffälligste Begriff des Glossars und für Betriebsteams vielleicht der wichtigste. Aus dem RL entlehnt, ist eine Policy das Verhalten selbst — was das System in jeder Situation tun wird. Der entscheidende Satz lautet, dass bei LLM-Agenten nur ein Teil der Policy in den Modellgewichten liegt: Der Rest wird durch das Scaffold und das Harness bestimmt. Derselbe Checkpoint hinter einem anderen System-Prompt, anderen Tool-Beschreibungen oder einem anderen Loop ist verhaltensbezogen eine andere Policy. Eine Policy ist kein Agent — die Policy ist das Verhalten; der Agent ist das bereitgestellte System, dessen Verhalten sie beschreibt.

Nimmt man das ernst, löst sich eine häufige betriebliche Gewohnheit auf: das Nachverfolgen von „welche Modellversion ist in Prod“, als ob damit die Frage beantwortet wäre, „was das System tun wird“. Es beantwortet ein Drittel der Frage. Die Übersetzung von „Policy“ für die Produktion lautet, dass der gesamte verhaltensbestimmende Stack — Modellname, Prompts, Tool-Set und -Beschreibungen, Skills, Harness-Konfiguration — ein zusammenhängendes, versioniertes Objekt ist, das gezielt geändert und gemeinsam auf Regressionen getestet wird. Denn eine einzeilige Prompt-Änderung ist genau wie ein Modellaustausch eine Policy-Änderung. Das ist das Argument des vierten Beitrags in dieser Serie; die Infrastruktur, die dies handhabbar macht, sind Definitions-as-Artifacts (die deklarative Agentendefinition des Agent Harness), Prompt-Versionierung und der Online-Evaluations-Loop, der Verhaltensänderungen erfasst, egal welche Schicht sie verursacht hat.

7. Die Trainingsbegriffe, die Sie weiterhin brauchen: Rollout und Reward

Der letzte Abschnitt des Glossars behandelt das RL-Trainingsvokabular — Environment, Trainer, Rollout, Reward — und es ist verlockend für ein Produktionsteam, diesen zu überspringen. Tun Sie es nicht, denn zwei dieser Begriffe beschreiben Dinge, die Sie bereits haben. Ein Rollout ist ein vollständiger Agentenlauf von Anfang bis Ende: was der Agent gesehen hat, was er getan hat, was zurückkam, Schritt für Schritt. Produktionsteams nennen das einen Trace. Ein Reward ist die Bewertung, die angibt, ob ein Lauf gut war — überprüfbar (Tests bestanden, Antwort stimmt überein) oder gelernt (Präferenzen, LLM-as-a-Judge). Die Trainings-Pipeline und der Produktions-Loop haben dieselbe Struktur; die eine aktualisiert Gewichte, die andere aktualisiert Dashboards.

Die Konsequenz ist bedenkenwert: Wenn Ihr Harness vollständige, schrittweise Traces aufzeichnet und Ihre Evaluationsschicht diese bewertet, sammeln Sie bereits das Rohmaterial für Rollout/Reward-Datensätze — Traces plus Qualitätssignale, die für Feintuning oder Verbesserungen im RL-Stil kuratiert werden können. Teams, die Open-Weight-Modelle selbst hosten (unser Beitrag zum Selbsthosten), können diesen Loop gezielt schließen: Traces aus dem Agent Harness, Bewertungen aus der Eval-Schicht, Feintuning auf TrueFoundry, der verbesserte Checkpoint bereitgestellt unter demselben Gateway-Namen. Der letzte Beitrag dieser Serie behandelt diesen Loop in vollem Umfang. Die Lektion bezüglich des Vokabulars ist einfacher: „Rollout“ und „Reward“ sind kein Trainingsjargon anderer Leute — sie sind Ihre Observability, aus der Zukunft betrachtet.

8. Warum ein gemeinsames Vokabular eine Architekturentscheidung ist

Elifs vierzigminütiges Meeting war nicht durch Unwissenheit verschwendet; es war durch Zweideutigkeit verschwendet, und Zweideutigkeit im Vokabular wird zu Zweideutigkeit in Systemen. Wenn „Agent“ keinen festen Bezugspunkt hat, kann kein Agenteninventar existieren. Wenn „Harness“ ein Produkt, einen Loop oder alles-außer-dem-Modell bedeuten kann, ist ein Buy-versus-Build-Gespräch über Harnesses in Wahrheit drei Gespräche unter einem Deckmantel. Wenn „Skill“ und „Tool“ verschwimmen, verschwimmt das Governance-Modell mit ihnen — und ungesicherte Funktionen sind genau der Ursprung von Wildwuchs und Shadow-Agent-Problemen. Die Festlegung der Wörter ist der günstige erste Schritt zur Festlegung der Architektur.

Die Zuordnung, die dieser Beitrag hinzufügt, ist der zweite Schritt: Jeder Begriff sollte eine Adresse haben. Auf TrueFoundry hat er eine — Modelle hinter dem AI Gateway, Tools hinter dem MCP Gateway, Skills im Skills Registry, der Loop und Sub-Agenten im Agent Harness, Context Engineering als Harness-Maschinerie, Policy als versioniertes Ganzes, Rollouts als Traces, die die Evaluation speisen. Nichts davon erfordert zwingend TrueFoundry; es erfordert irgendeine konkrete Antwort auf die Frage: „Wo befindet sich dieses Wort und wer steuert es dort?“ Die vier folgenden Beiträge behandeln die gehaltvollsten Begriffe einzeln: Harness versus Scaffold, das Tool/Skill/Sub-Agent-Spektrum, Policy als das, was Sie tatsächlich versionieren, und der Rollout-to-Reward-Loop in der Produktion.

9. Häufig gestellte Fragen (FAQ)

Ist „Agent = Modell + Harness“ die offizielle Definition? Es gibt kein offizielles Gremium, und das Glossar selbst weist sorgfältig darauf hin, dass vielen Begriffen allgemein akzeptierte Definitionen fehlen — verschiedene Frameworks verwenden dieselben Wörter tatsächlich unterschiedlich. Es ist am besten als nützliches Arbeitsmodell zu verstehen, und zwar als ein praxistaugliches: Es trennt die Reasoning Engine sauber von der Maschinerie, die sie handeln lässt, was genau die Trennung ist, die eine Produktionsarchitektur benötigt. Betrachten Sie es als Arbeitsmodell, zitieren Sie die Quelle und rechnen Sie mit Weiterentwicklungen.

Wo endet das Scaffold und wo beginnt das Harness? Die sauberste Trennlinie: Scaffold ist das, wovon das Modell ausarbeitet (Prompts, Tool-Beschreibungen, Formate — Inhalt), Harness ist das, was den Agenten ausführt (der Loop, Ausführung, Fehlerbehandlung, Stoppen — Maschinerie). Produkte verwenden oft „Harness“ für beides, was so lange in Ordnung ist, bis Sie das eine ohne das andere ändern müssen. In der Praxis ist die Linie auch eine Zuständigkeitslinie: Autoren besitzen das Scaffold; die Plattform besitzt das Harness.

Ist ein Sub-Agent aus der Perspektive des Aufrufers nicht einfach ein Tool? Mechanisch wird er oft wie ein solches aufgerufen, weshalb die Begriffe verschwimmen. Der Unterschied liegt in dem, was auf der anderen Seite steht: Ein Tool führt eine Funktion aus; ein Sub-Agent betreibt Reasoning — er hat sein eigenes Modell, Scaffold, seinen eigenen Kontext und möglicherweise seine eigenen Tools. Dieser Unterschied ist für den aufrufenden Code unsichtbar, aber für die Governance gewaltig: Ein Sub-Agent benötigt eine eigene Identität, eigene Berechtigungen und sein eigenes Tracing, nicht nur einen Eintrag in der Tool-Liste des Parent-Agenten.

Benötigen Produktionsteams wirklich die RL-Begriffe? Zwei davon, ja. In Produktionsbegriffen entspricht ein Rollout einem Trace und ein Reward einem Eval-Score — Vokabular für Dinge, die Sie bereits erzeugen. Die Trainingsperspektive zu kennen ist an dem Tag wichtig, an dem sich Ihre Agenten aus ihrer eigenen Historie heraus verbessern sollen: Vollständige Traces plus Qualitätsscores sind das Rohmaterial, und Teams, die diese gut erfasst haben, verfügen über einen Datensatz, wo andere nur Logs haben.

Verändert die Standardisierung des Vokabulars tatsächlich etwas an der Technik? Indirekt, aber erheblich. Gemeinsame Begriffe machen das Inventar zählbar („Agent“ = registrierte Definition + Runtime), machen die Beschaffung vergleichbar (jede Zusage wie „Harness enthalten“ lässt sich in Loop, Sandbox, Genehmigungen und Traces zerlegen) und machen Governance zuweisbar (die Adresse jedes Begriffs hat einen Verantwortlichen). Elifs Meeting-Problem war ein Systemproblem, das wie ein Semantikproblem aussah — das sind sie meistens.

Ein Glossar ist eine Legende für eine Karte; dieser Beitrag hat versucht, die Karte zu zeichnen. Das Vokabular der Community — Modell, Scaffold, Harness, Agent, Skill, Sub-Agent, Policy, Rollout, Reward — beschreibt eine Produktionsarchitektur Begriff für Begriff erstaunlich gut, solange jeder Begriff eine Adresse erhält. Geben Sie ihm eine, und die Wörter hören auf, Gegenstand von Diskussionen zu sein, und werden zum eigentlichen Design.

Referenzen

• Hugging Face — „Harness, Scaffold, and the AI Agent Terms Worth Getting Right“ (Mai 2026) — das Glossar, das dieser Beitrag auf die Infrastruktur überträgt; Definitionen mit Quellenangabe paraphrasiert.
• TrueFoundry Agent Harness — verwalteter Loop, Sandbox, Genehmigungen, Context-Engineering-Suite, Sub-Agenten, Traces.
• TrueFoundry AI Gateway und MCP Gateway — wo Modelle bzw. Tools verortet sind.
• Was ist ein Agent Harness? — die Vertiefung auf Produktebene, die zu dieser Vokabularübersicht passt.
• Online-Evaluation am Gateway — die Produktions-„Reward“-Schicht.

Elif ist ein illustratives Beispiel und keine spezifische Person, Organisation oder ein realer Vorfall. Die Definitionen in diesem Beitrag wurden aus dem Agenten-Glossar von Hugging Face (Mai 2026) sowie der dort zitierten breiteren Community-Diskussion paraphrasiert und entsprechend zitiert; das Glossar selbst merkt an, dass vielen Begriffen allgemein akzeptierte Definitionen fehlen und die Verwendung je nach Framework variiert. Die genannten TrueFoundry-Funktionen spiegeln die öffentliche Produktdokumentation zum Zeitpunkt der Erstellung wider; prüfen Sie spezifische Details anhand der aktuellen Dokumentation.

‍