Der verborgene Token-Verbrauch: Wie Zwischenergebnisse den Kontext Ihres KI-Agenten aufblähen

Dieser Beitrag knüpft an unsere frühere Untersuchung zum Kontextverbrauch von MCP an und betrachtet ein weniger offensichtliches, aber ebenso teures Problem: Zwischenergebnisse in mehrstufigen Tool-Workflows.

Kurze Auffrischung: Was ist MCP?

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Agenten externe Tools anbinden: Datenbanken, APIs und Dateisysteme über eine einheitliche Schnittstelle. Statt für jedes Tool eine eigene Integration zu bauen, implementieren Entwickler MCP einmal und erhalten Zugang zu einem ganzen Ökosystem.

Wie wir aber im ersten Beitrag dargestellt haben, verbrauchen MCP-Tool-Definitionen Kontext. Wenn Sie das Kontextfenster nicht sorgfältig steuern, geht leicht der Großteil Ihres Kontexts für Tool-Definitionen drauf, sodass für den Prompt des Nutzers kaum noch Aufmerksamkeit übrig bleibt.

Das heutige Problem ist anders gelagert: Was passiert, wenn diese Tools tatsächlich laufen?

Wie Tool-Aufrufe wirklich funktionieren

Bevor wir uns dem Problem widmen, sehen wir uns die Mechanik an. Das Engineering-Team von Cloudflare erklärt das in seinem Beitrag zu Code Mode anschaulich.

Wenn ein LLM ein Tool aufrufen will, gibt es spezielle Tokens aus, die signalisieren: "Das ist eine Tool-Anfrage." Diese Tokens haben kein textliches Äquivalent: Das LLM ist darauf trainiert, sie zu erzeugen, wenn es ein Tool aufrufen will. Die Agenten-Umgebung fängt diese Tokens ab, führt das Tool aus und speist das Ergebnis über eine weitere spezielle Token-Sequenz zurück in das Kontextfenster des LLM.

User: "What's the weather in Austin?"

LLM output:
I will use the Weather MCP server to find out the weather.
<tool_call>{"name": "get_current_weather", "args": {"location": "Austin, TX"}}</tool_call>

[Agent executes tool, returns result]

<tool_result>{"location": "Austin, TX", "temperature": 93, "conditions": "sunny"}</tool_result>

LLM continues:
It's 93°F and sunny in Austin.

Für einzelne Tool-Aufrufe funktioniert das gut. Das Problem entsteht, wenn Tools verkettet werden müssen.

Das Problem der Zwischenergebnisse

Nehmen wir dieses Szenario aus Anthropics Beitrag zu Code Execution with MCP: "Lade mein Meeting-Transkript aus Google Drive herunter und hänge es an den Salesforce-Lead an."

Ihr Agent muss:

das Dokument aus Google Drive holen
dessen Inhalt an die Salesforce-API übergeben

Folgendes passiert dabei:

TOOL CALL: b.getDocument(documentId: "abc123")
   → Returns full transcript content
    (This entire output enters the LLM's context window)

TOOL CALL: salesforce.updateRecord(
      objectType: "Lead",
      recordId: "00Q5f...",
      data: { "Notes": [full transcript content written out again] }
   )

Das Transkript läuft zweimal durch das Kontextfenster des LLM. Das Modell liest das gesamte Dokument, nur um es in den nächsten Tool-Aufruf zu kopieren. Bei langen Dokumenten wie dem Transkript eines zweistündigen Meetings bedeutet das die Verarbeitung von zehntausenden zusätzlichen Tokens. Bei noch größeren Dokumenten kann das die Kontextgrenzen vollständig sprengen und den Workflow zum Scheitern bringen.

Das Muster skaliert schlecht

Reale Agenten-Workflows umfassen oft mehr als zwei Schritte. Jeder Schritt zwingt das gesamte Zwischenergebnis durch das Kontextfenster des Modells, selbst wenn das LLM nur eine Zusammenfassung oder einen Teil davon braucht. Sie bezahlen für Tokens, die keinem Zweck des Reasonings dienen: Sie werden nur von A nach B kopiert.

Hinzu kommt, dass Modelle eher Fehler machen, wenn sie große Dokumente oder komplexe Datenstrukturen zwischen Tool-Aufrufen kopieren.

Warum nicht ein kombiniertes Tool schreiben?

Sie denken vielleicht: "Dann baue ich eben ein Tool, das beide Schritte intern erledigt."

Dieser Ansatz skaliert schlecht. Bei vielen Tools, die sich in verschiedenen Kombinationen verketten lassen, bräuchten Sie viele Kombinations-Tools. Ihr MCP-Server wird schwerer zu warten, und die Tool-Definitionen selbst verbrauchen genau den Kontext, den Sie einsparen wollen.

Lösungen: Zwischenergebnisse aus dem Kontext heraushalten

Anthropic und Cloudflare sind auf dieselbe Erkenntnis gekommen: Lassen Sie das LLM Code schreiben, statt Tools direkt aufzurufen.

Code-Ausführung als Orchestrierung

Statt dass das LLM Tools einzeln über spezielle Tokens aufruft, schreibt es ein Skript, das den gesamten Workflow orchestriert. Das Skript läuft in einer Sandbox-Umgebung und ruft Tools über API-Bindings auf. Nur das Endergebnis gelangt in den Kontext des LLM.

# LLM generates this code:
transcript = await gdrive.get_document("abc123")
await salesforce.update_record(
   object_type="Lead",
   record_id="00Q5f...",
   data={"Notes": transcript}
)
print("Lead updated successfully")

Das Transkript berührt das Kontextfenster des LLM nie. Es fließt vollständig innerhalb der Ausführungsumgebung von Google Drive nach Salesforce. Das Modell sieht nur die finale Ausgabe.

Dieser Ansatz nutzt eine zentrale Stärke: LLMs haben in ihren Trainingsdaten enorme Mengen an realem Code gesehen. Tool-Aufrufe stützen sich dagegen auf synthetische Trainingsdaten, die eigens erstellt wurden, um dem Modell ein Format beizubringen, das ihm selten begegnet ist.

Programmatische Tool-Aufrufe

Anthropics Programmatic Tool Calling formalisiert dieses Muster. Tools werden mit allowed_callers: ["code_execution"] markiert, damit sie aus einer Sandbox-Python-Umgebung heraus aufgerufen werden können.

Wenn der Code ein Tool aufruft, verarbeitet das Skript das Ergebnis und nicht das Modell:

Der durchschnittliche Token-Verbrauch sank bei komplexen Recherche-Aufgaben von 43.588 auf 27.297 Tokens (37 % weniger)
Die Genauigkeit beim Abruf internen Wissens stieg von 25,6 % auf 28,5 %
Die Werte im GIA-Benchmark stiegen von 46,5 % auf 51,2 %

Anschauliches Beispiel: Prüfung der Budget-Einhaltung

Sehen wir uns ein konkretes Beispiel an: "Welche Teammitglieder haben ihr Reisebudget für Q3 überschritten?"

Traditioneller Ansatz:

Fetch team members                              →  Tool result enters context
For each member, fetch Q3 expenses              →  All expense line items enter context
Fetch budget limits                             →  More context consumption
LLM manually sums and compares each person      →  Error-prone, slow

Mit Code-Ausführung:

team = await get_team_members("engineering")
expenses = await asyncio.gather(*[
   get_expenses(m["id"], "Q3") for m in team
])
budgets = {level: await get_budget(level) for level in set(m["level"] for m in team)}

exceeded = [
   {"name": m["name"], "spent": sum(e["amount"] for e in exp), "limit": budgets[m["level"]]}
   for m, exp in zip(team, expenses)
   if sum(e["amount"] for e in exp) > budgets[m["level"]]["travel_limit"]
]
print(json.dumps(exceeded))

Das LLM sieht nur das gefilterte Endergebnis: nicht jeden einzelnen Ausgabenposten, der unterwegs verarbeitet wurde.

Token-Caching: eine ergänzende Strategie

Token-Caching hilft, wenn dieselben Tool-Definitionen oder Prompts über mehrere Anfragen hinweg auftauchen.

Caching löst das Problem der Zwischenergebnisse jedoch nicht: Es betrifft wiederholte statische Inhalte, nicht die dynamischen Daten, die zwischen Tools fließen. Setzen Sie beide Strategien gemeinsam ein.

Dateibasierte Zwischenspeicherung

Für Workflows, in denen das LLM Zwischenergebnisse gezielt prüfen muss, sollten Sie sie in Dateien schreiben:

# Write large result to file
with open("/workspace/data.json", "w") as f:
   json.dump(large_result, f)

# LLM can now use file tools to read specific portions
# Only what's actually needed enters context

Dieses Muster funktioniert besonders gut in Kombination mit Tools wie jq für die JSON-Verarbeitung oder gängigen Text-Werkzeugen zum Filtern: So zieht der Agent genau das heraus, was er braucht.

Überlegungen zur Umsetzung

Sandboxing

Das Ausführen von LLM-generiertem Code erfordert sichere Isolation. Cloudflares Ansatz nutzt V8-Isolates, die sie als "far more lightweight than containers" beschreiben: Ein Isolate startet in wenigen Millisekunden und braucht nur ein paar Megabyte Speicher. Weitere Optionen sind Container oder Serverless-Funktionen.

Vorteile für den Datenschutz

Code-Ausführung kann den Datenschutz verbessern. Zwischenergebnisse bleiben standardmäßig in der Sandbox: Sensible Daten gelangen nur dann in den Kontext des Modells, wenn sie ausdrücklich protokolliert werden. Der MCP-Client kann PII sogar tokenisieren, bevor sie das Modell erreichen, und erst beim Schreiben an freigegebene Ziele wieder detokenisieren. Produktive Deployments sollten zusätzliche Härtung umfassen: Ressourcenlimits, Netzwerkisolation und regelmäßige Sicherheits-Audits der Ausführungsumgebung.

Wann sich welcher Ansatz eignet

Traditionelle Tool-Aufrufe eignen sich gut für:

einfache Aufrufe einzelner Tools
Aufgaben, bei denen das LLM über Zwischenergebnisse nachdenken muss
schnelle Abfragen mit kleinen Antworten

Code-Ausführung ist von Vorteil, wenn:

große Datensätze verarbeitet werden, aus denen Sie Aggregate oder Zusammenfassungen brauchen
mehrstufige Workflows mit voneinander abhängigen Tool-Aufrufen laufen
Ergebnisse gefiltert oder transformiert werden, bevor das LLM sie sieht
Operationen über viele Elemente hinweg parallelisiert werden

Fazit

Das Problem der Zwischenergebnisse wird sichtbar, sobald Agenten über einfache Abfragen mit einem einzelnen Tool hinausgehen und zu komplexen, mehrstufigen Workflows übergehen.

Die zentrale Erkenntnis von Anthropic und Cloudflare: LLMs müssen keine Daten sehen, über die sie nicht nachdenken. Wenn ein Tool-Ergebnis nur an ein weiteres Tool durchgereicht wird, behalten Sie es in einer Ausführungsumgebung, in der Code den Transfer übernimmt.

Je komplexere Workflows Agenten übernehmen, desto wichtiger wird der effiziente Umgang mit Kontext. Die Kombination aus bedarfsgesteuerter Tool-Erkennung und code-basierter Orchestrierung liefert die Bausteine für Agenten, die skalieren.