Start/Forschung/Papers/Externalization in LLM Agents: Der theoretische Rahmen hinter Memory, Skills, Protocols und Harness
9. April 2026

Externalization in LLM Agents: Der theoretische Rahmen hinter Memory, Skills, Protocols und Harness

Waehrend die Praxis seit Monaten ueber Claude-Code-Skills, CLAUDE.md-Dateien, MCP-Server und Harness Engineering diskutiert, fehlte dem Feld eine saubere Theorie. Dieses Paper schliesst die Luecke. Chenyu Zhou, Huacan Chai, Wenteng Chen und 19 weitere Autoren aus Shanghai Jiao Tong University und Umfeld legen auf 54 Seiten ein konzeptionelles Review vor, das die verschiedenen Stroemungen der letzten zwei Jahre unter einem gemeinsamen Begriff buendelt: Externalisierung. Der zentrale Anspruch lautet, dass moderne LLM-Agenten nicht mehr primaer durch veraenderte Modellgewichte besser werden, sondern durch eine Neuorganisation der Laufzeitumgebung um das Modell herum. Was frueheren Systemen als interne Faehigkeit abverlangt wurde, wandert heute nach aussen -- in Memory-Stores, wiederverwendbare Skills, Interaktionsprotokolle und das Harness, das diese Module zuverlaessig macht.

Kernaussagen

Der begriffliche Dreh- und Angelpunkt des Papers ist das Konzept des kognitiven Artefakts aus der Kognitionswissenschaft. Die Autoren argumentieren, dass Agent-Infrastruktur nicht einfach Zusatzkomponenten bereitstellt, sondern kognitive Lasten transformiert: Probleme, die dem Modell intern schwer fallen, werden in Formen ueberfuehrt, die es zuverlaessig loesen kann. Unter dieser Linse zerlegen die Autoren das Agentensystem in drei gekoppelte, aber klar unterscheidbare Formen der Externalisierung.

Memory externalisiert Zustand ueber die Zeit. Alles, was ein Agent sitzungsuebergreifend wissen muss -- vergangene Entscheidungen, gelernte Fakten, Nutzerpraeferenzen, episodische Spuren vergangener Laeufe -- gehoert nicht in die Gewichte und auch nicht permanent in das Kontextfenster. Es gehoert in einen externen Speicher mit klaren Schreib-, Lese- und Vergessens-Operationen.

Skills externalisieren prozedurales Wissen. Was ein Agent tun kann, wird nicht laenger als Faehigkeit des Modells verstanden, sondern als wiederverwendbares, benennbares Artefakt. Ein Skill ist eine kodifizierte Prozedur, die der Agent bei Bedarf laedt, ausfuehrt und wieder ablegt. Die Analogie zur menschlichen Expertise ist zentral: Erfahrene Ingenieure wissen nicht mehr, sondern haben bessere Playbooks.

Protocols externalisieren Interaktionsstruktur. Wie ein Agent mit Werkzeugen, anderen Agenten oder Umgebungen kommuniziert, ist keine emergente Modell-Eigenschaft mehr, sondern ein vereinbarter, versionierter Vertrag. MCP ist hier das offensichtliche, aber nicht das einzige Beispiel -- jedes stabile Tool-Call-Schema, jede Multi-Agent-Nachrichtenkonvention ist Protokoll-Externalisierung.

Daraus folgt die vierte Ebene: Harness Engineering als Vereinigungsschicht. Memory, Skills und Protocols sind nur dann nuetzlich, wenn sie in ein gemeinsames, governable Ausfuehrungsmodell eingebettet sind. Das Harness ist die Instanz, die koordiniert, wann welche Erinnerung gezogen, welcher Skill geladen und welches Protokoll benutzt wird. Ohne diese Vereinigungsschicht bleiben die drei Formen der Externalisierung lose Werkzeugkasten-Elemente.

Historisch zeichnet das Paper eine klare Progression: Weights -> Context -> Harness. Erste Generation LLM-Anwendungen verbesserten Modelle durch Training und Fine-Tuning. Die zweite Welle optimierte den Kontext -- Prompting, RAG, Few-Shot-Beispiele. Die dritte Welle, in der wir jetzt stehen, baut die Laufzeitumgebung um. Das ist keine blosse Chronik, sondern ein Argument: Jede Welle hat einen abnehmenden Grenzertrag, und die aktuelle Engpass-Stelle sitzt im Harness.

Bemerkenswert ist die Diskussion des Trade-offs zwischen parametrischer und externalisierter Faehigkeit. Die Autoren stellen die Frage, welche Kompetenzen ein Modell selbst mitbringen muss, damit externalisierte Strukturen ueberhaupt funktionieren -- und welche Kompetenzen sich lohnenderweise nach aussen verlagern lassen. Am Horizont zeichnen sie selbst-evolvierende Harnesses und geteilte Agent-Infrastruktur als offene Forschungsrichtungen, dazu ungeloeste Fragen rund um Evaluation, Governance und die langfristige Ko-Evolution von Modellen und externer Infrastruktur.

Methodik

Es handelt sich um ein konzeptionelles Review, keine empirische Arbeit. Das Paper liefert keine Benchmarks, keine Ablationen und keine Messwerte. Was es liefert, ist eine Taxonomie und ein Rahmenwerk. Die 54 Seiten ordnen die verstreute Literatur zu Memory-Systemen, Skill-Bibliotheken, Tool-Protokollen und Harness-Engineering unter einer gemeinsamen theoretischen Klammer und zeichnen nach, wie die drei Formen der Externalisierung im Betrieb ineinandergreifen. Der Anspruch ist explizit systems-level: nicht einzelne Komponenten zu optimieren, sondern das Zusammenspiel zu erklaeren.

Relevanz fuer die Praxis

Das Paper fordert einen klaren Mental Shift. Wer heute Claude Code, Cursor oder Codex ernsthaft betreibt, hoert auf zu fragen, ob das Modell etwas kann -- und beginnt zu fragen, welche Externalisierungs-Entscheidung der eigene Projektkontext erfordert. Der Dreiklang laesst sich direkt auf die Konfigurationsartefakte abbilden, die im Wiki bereits dokumentiert sind.

Memory-Ebene. CLAUDE.md, Memory-Files, Session-Protokolle, Projekt-Wikis wie dieses hier sind keine Notizen, sondern externalisierter Zustand ueber die Zeit. Der Mental Shift: Diese Dateien sind nicht Dokumentation, sie sind ein kognitives Artefakt, das dem Agenten eine Last abnimmt. Die in Agent-Memory ohne Hype besprochenen Patterns -- Kurzzeit als Context-Management, Langzeit als Tool-Call -- fallen exakt unter die Memory-Externalisierungs-Taxonomie des Papers. Ebenso das in Beyond RAG beschriebene Memory-Agent-Pattern.

Skills-Ebene. Claude-Code-Skills, Slash-Commands, wiederverwendbare Prompt-Templates, Makefile-Targets fuer Agenten, dokumentierte Playbooks -- all das ist prozedurales Wissen, das bewusst aus dem Modell herausgezogen und in ein benanntes, versionierbares Artefakt gepackt wird. Der Mental Shift: Ein neuer Skill ist nicht dasselbe wie ein besserer Prompt. Er ist eine Investition in ein persistentes Artefakt, das ueber viele Agent-Interaktionen hinweg dieselbe Last abnimmt.

Protocols-Ebene. MCP-Server, Tool-Schemas, strukturierte Tool-Outputs, Agent-zu-Agent-Nachrichten in Multi-Agent-Harnesses. Wer einen MCP-Server schreibt, externalisiert Interaktionsstruktur. Wer sich dabei auf stabile Vertraege committet, baut an der dritten Saeule -- und macht es erst moeglich, dass Memory- und Skill-Artefakte modellunabhaengig bleiben.

Harness-Ebene. Die Vereinigungsschicht ist genau das, was die AI-Radar-Artikel zu Harness Engineering und Token-Billionaires praktisch beschreiben. Das Paper liefert dafuer die Begruendung: Tests, CI/CD, Build-Constraints, Observability sind nicht optionale Infrastruktur, sondern die Schicht, die Memory, Skills und Protocols ueberhaupt erst zu einem governable System verbindet.

Die Kernfrage, die dieses Paper an jede Agenten-Konfiguration stellt, lautet: Welche Faehigkeit kompensiere ich gerade dadurch, dass ich es in den Prompt schreibe -- und welches externalisierte Artefakt waere die richtige Antwort? Wer die Antwort konsequent verfolgt, landet nicht bei besseren Prompts, sondern bei besseren Memory-Stores, besseren Skills, besseren Protokollen und einem besseren Harness. Genau diese Verschiebung ist der Mental Shift, den das Paper einfordert.

Quellen

Nach oben