Denken Sie an ACE? Wir können es mit weniger Tokens schaffen.
Denken Sie an ACE? Ein kürzlich erschienener IBM-Research-Blogbeitrag vom 11. August 2026 untersucht, wie lokale Modelle denselben Effekt mit weniger Tokens erzielen können. Der Artikel beleuchtet praktische Strategien zur Token-Reduktion und deren Auswirkungen auf die Effizienz von On-Device-KI und bietet eine wertvolle Perspektive für Entwickler und Forscher, die in Umgebungen mit begrenzten Ressourcen arbeiten.
Tags
Kurze Zusammenfassung
Denken Sie an ACE? Ein kürzlich erschienener IBM-Research-Blogbeitrag vom 11. August 2026 untersucht, wie lokale Modelle denselben Effekt mit weniger Tokens erzielen können. Der Artikel beleuchtet praktische Strategien zur Token-Reduktion und deren Auswirkungen auf die Effizienz von On-Device-KI und bietet eine wertvolle Perspektive für Entwickler und Forscher, die in Umgebungen mit begrenzten Ressourcen arbeiten.
Denken Sie an ACE? Wir schaffen das mit weniger Tokens
Wenn wir einen KI-Agenten entwerfen, dominiert jede Review dieselbe Frage: „Wird es passen?" Wird der System-Prompt passen? Werden die abgerufenen Belege passen? Werden die zwölf Zwischenschritte des Denkens passen? Meistens ist die Antwort, die wir wählen, einen größeren Kontextfenster zu kaufen. Aber es gibt eine leisere, oft bessere Alternative: dem Agenten beibringen, von vornherein weniger Tokens auszugeben.
Diese Alternative ist das Thema von „Thinking of ACE? We Can Do It with Fewer Tokens", einem technischen Beitrag, den IBM Research am 11.08.2026 unter https://huggingface.co/blog/ibm-research/altk-evolve-sldd im Hugging-Face-Blog veröffentlicht hat. Der Beitrag argumentiert, dass agentisches Kontext-Engineering – die Disziplin, zu verwalten, was ein Agent liest und schreibt – nicht mit immer größeren Kontextbudgets gleichgesetzt werden muss. Dieser Artikel ist ein praktischer Begleiter zu dieser Idee. Er erklärt, warum Token-Effizienz das Rückgrat zuverlässiger Agenten ist, und führt Sie durch einen kleinen, konkreten Werkzeugkasten zum Messen und Reduzieren des Token-Verbrauchs Ihres eigenen Agenten.
Bevor wir weitermachen, eine Anmerkung zum Umfang. Die verifizierten Fakten über die Quelle sind ihr Titel, ihr Veröffentlichungsdatum und ihre URL. Die folgende technische Interpretation stammt von mir, und die Codebeispiele sind ein allgemeiner Aufbau, keine Auszüge aus dem Beitrag.
Warum Kontext-Engineering ein Token-Problem ist, kein Speicherproblem
Ein Agent ist eine Schleife. Er liest, denkt, ruft Werkzeuge auf, liest die Ergebnisse, denkt erneut nach und wiederholt das, bis er eine Antwort erzeugt. Jeder Durchlauf durch die Schleife fügt Tokens zum nächsten Durchlauf hinzu:
- Der System-Prompt wird in jeder Runde bezahlt.
- Abgerufene Dokumente werden normalerweise vollständig injiziert.
- Werkzeugausgaben werden oft wörtlich zurückgegeben, egal wie groß sie sind.
- Der eigene Gedankengang des Agenten wird gespeichert und abgespielt, damit er kohärent bleibt.
Das Ergebnis ist, dass eine einfache Aufgabe mit drei Werkzeugaufrufen Zehntausende Tokens an Kontext erzeugen kann, obwohl die nutzbringende Information in ein paar Hundert passen könnte. Das ist kein Speicherproblem – das Modell kann sich alles merken. Es ist ein Budgetproblem. Jedes zusätzliche Token erhöht Kosten, Latenz und Rauschen. Und Rauschen ist nicht harmlos: In der Praxis ist ein Modell oft wesentlich schlechter darin, eine einzelne relevante Tatsache zu extrahieren, wenn diese in irrelevantem Text vergraben ist. Ingenieure nennen das manchmal den „Lost-in-the-Middle"-Effekt, und er wird schlimmer, je größer die Kontexte werden.
Agentic Context Engineering (ACE) behandelt Kontext, wie der Name schon sagt, als etwas, das wir entwerfen und pflegen, nicht als etwas, das einfach akkumuliert. Ein gut entwickelter Agentenkontext ist kompakt, aktuell und ausreichend. Er enthält nur das, was der nächste Schritt braucht, nicht alles, was der Agent jemals gesehen hat. Hier macht der IBM-Research-Beitrag seine Aussage: Mit diszipliniertem Kontext-Engineering können Sie agentische Arbeitslasten mit deutlich weniger Tokens betreiben – ohne Einbußen bei der Aufgabengualität. Der Titel des Beitrags ist die These: „We can do it with fewer tokens."
Das Kern-Playbook: Sechs Gewohnheiten token-effizienter Agenten
Die folgenden Prinzipien sind eine allgemeine Synthese von ACE-Best Practices. Sie stimmen mit der Ausrichtung des Quellbeitrags überein, sind aber keine Zusammenfassung seiner internen Details.
- Strukturierten Zustand bevorzugen statt Rohverlauf. Statt das vollständige Transkript bei jedem Schritt abzuspielen, führen Sie einen kompakten Statusblock: was der Agent weiß, was er versucht hat, was fehlgeschlagen ist und was als Nächstes kommt.
- Werkzeugausgaben an der Grenze kürzen. Das Werkzeug gibt zurück, was es zurückgibt; der Kontext muss nicht alles davon enthalten. Schneiden Sie die Nutzlast, bevor sie überhaupt ins Gespräch gelangt.
- Vor dem Speichern zusammenfassen. Jedes Mal, wenn der Agent eine Teilaufgabe abschließt, komprimieren Sie das Ergebnis zu einem einzeiligen Ledgereintrag. Lassen Sie die Details sterben, nachdem sie ihren Zweck erfüllt haben.
- Eng und häufig abrufen. Statt zu Beginn der Sitzung ein großes Korpus zu injizieren, holen Sie kleine Chunks genau rechtzeitig, nahe an dem Moment, an dem sie gebraucht werden.
- System-Prompt budgetieren. Jeder Satz im Prompt konkurriert um das Arbeitsgedächtnis. Wenn eine Regel verkürzt werden kann, ohne an Genauigkeit zu verlieren, verkürzen Sie sie. Wenn ein Beispiel redundant ist, löschen Sie es.
- Alles messen. Sie können Token-Verbrauch nicht verwalten, den Sie nicht sehen. Zählen Sie Tokens pro Schritt, pro Schleife und pro Sitzung, bis die Gewohnheit automatisch wird.
Diese Gewohnheiten sind billig umzusetzen und sofort wirksam. Der Rest dieses Artikels zeigt die konkreten Mechanismen.
Anforderungen
Um den Beispielen in diesem Artikel zu folgen, benötigen Sie:
- Python 3.10 oder neuer.
- Ein Werkzeug für virtuelle Umgebungen wie
venv. - Die Hugging-Face-Bibliotheken
transformersunddatasets. - Optional
tiktokenzum Token-Zählen mit OpenAI-kompatiblen Modellen. - Einen API-Schlüssel nur, wenn Sie gegen ein gehostetes Modell testen möchten; alle Beispiele laufen lokal.
Der Aufbau verwendet bewusst offene, lokale Werkzeuge. Token-Messung erfordert keine GPU, und Sie können jedes Beispiel auf einem Laptop während einer Kaffeepause ausführen.
Schritt-für-Schritt-Installation
Erstellen Sie zuerst eine isolierte virtuelle Umgebung, damit die von uns installierten Pakete nicht mit dem Rest Ihres Systems interferieren:
python -m venv ace-envDies erstellt einen Ordner namens ace-env, der eine eigene Python-Binärdatei und ein eigenes Bibliotheksverzeichnis enthält.
Aktivieren Sie die Umgebung. Der Befehl unterscheidet sich je nach Betriebssystem; unter Linux und macOS:
source ace-env/bin/activateUnter Windows:
ace-env\Scripts\activateNach der Aktivierung sollte Ihre Shell-Eingabeaufforderung (ace-env) am Anfang anzeigen.
Aktualisieren Sie pip auf die neueste Version, damit die Abhängigkeitsauflösung gut funktioniert:
pip install --upgrade pipInstallieren Sie die Kernpakete. transformers gibt uns Tokenizer und Modul-Werkzeuge, während datasets praktisch zum Laden kleiner Evaluierungskorpora ist:
pip install transformers datasetsWenn Sie mit OpenAI-APIs arbeiten und Tokens mit derselben Tokenizer-Familie zählen möchten, die die API verwendet, installieren Sie zusätzlich tiktoken:
pip install tiktokenÜberprüfen Sie die Installation, indem Sie die Bibliotheken importieren und ihre Versionen ausgeben:
python -c "import transformers; import datasets; print('transformers', transformers.__version__); print('datasets', datasets.__version__)"Wenn Sie tiktoken installiert haben, überprüfen Sie es auf dieselbe Weise:
python -c "import tiktoken; print('tiktoken', tiktoken.__version__)"Die Einrichtung ist abgeschlossen. Es gibt keinen Server zu starten und kein Modell herunterzuladen; Token-Zählung funktioniert vollständig offline.
Verwendungsbeispiele
1. Zählen Sie Tokens, bevor Sie entwerfen
Die erste Gewohnheit ist Messung. Bevor Sie entscheiden können, ob ein Kontext aufgebläht ist, brauchen Sie eine zuverlässige Methode, um die Tokens in Ihren Prompts und Werkzeugausgaben zu zählen. Die folgende Funktion verwendet einen Hugging-Face-Tokenizer:
from transformers import AutoTokenizer
def count_tokens(text: str, model_id: str = "gpt2") -> int:
tokenizer = AutoTokenizer.from_pretrained(model_id)
return len(tokenizer.encode(text, add_special_tokens=False))
example = "RESULT: invoice_2024_05_221.pdf contains 4 line items totaling $12,500."
print(count_tokens(example))Der gpt2-Tokenizer ist ein häufig verwendeter lokaler Stellvertreter für viele moderne Modelle und läuft ohne API-Schlüssel. Wenn Ihr Zielmodell bekannt ist, ersetzen Sie model_id durch den Tokenizer-Namen dieses Modells.
2. Werkzeugausgaben an der Grenze kürzen
Wenn ein Werkzeug einen großen JSON-Blob zurückgibt, ist es verlockend, das Ganze zu injizieren. Eine einfache Kürzungsfunktion behält Kopf und Ende, wo normalerweise wichtige Metadaten leben, und entfernt die Mitte:
def trim_tool_output(output: str, keep: int = 400) -> str:
if len(output) <= keep:
return output
half = keep // 2
return (
output[:half]
+ f"\n...[trimmed {len(output) - keep} characters]...\n"
+ output[-half:]
)
large_http_body = '{"status": "ok", "items": [' + ','.join(f'{{"id": {i}}}' for i in range(1000)) + ']}'
print(trim_tool_output(large_http_body, keep=300))Dies bewahrt die Struktur und die Grenzen der Nutzlast, während der repetitive Mittelteil verworfen wird. Wenden Sie diese Funktion in einer Agentenschleife an dem Punkt an, an dem das Werkzeugergebnis in den Kontext eingefügt wird, nicht später. Sobald die Rohausgabe gekürzt wurde, bewahren Sie nicht auch die ungekürzte Version irgendwo „für alle Fälle" auf – das würde den Zweck zunichtemachen.
3. Gesprächsverlauf durch ein Status-Ledger ersetzen
Das häufigste Token-Leck in agentischen Systemen ist das vollständige Transkript. Statt jede Nachricht, jeden Werkzeugaufruf und jede Reflexion zu speichern, pflegen Sie ein kurzes Ledger, das nach jedem Schritt aktualisiert wird:
class AgentLedger:
def __init__(self, max_entries: int = 5):
self.entries = []
self.max_entries = max_entries
def record(self, step: int, action: str, conclusion: str) -> None:
self.entries.append(f"step {step}: ran {action} -> {conclusion}")
self.entries = self.entries[-self.max_entries:]
def render(self) -> str:
return "\n".join(self.entries)
ledger = AgentLedger(max_entries=3)
ledger.record(1, "search", "found 3 candidates")
ledger.record(2, "read_doc", "candidate A missing license")
ledger.record(3, "verify", "candidate B is valid")
ledger.record(4, "summarize", "ready to answer")
print(ledger.render())Der Agent verliert den Zugriff auf das rohe Denken der ersten drei Schritte, behält aber, was wichtig ist: was er getan hat und was er geschlussfolgert hat. Für viele Aufgaben reicht das für kohärentes Langzeithorizont-Verhalten. Die Token-Kosten des Ledgers wachsen linear mit der Anzahl der Einträge – nicht mit der Länge des vollständigen Transkripts. Dies ist die einzige effektivste Änderung, die Sie an einem bestehenden Agenten vornehmen können.
4. Einen kompakten System-Prompt bauen
System-Prompts werden in jeder Runde bezahlt, daher werden ihre Token-Kosten mit der Anzahl der Schleifen vervielfacht, die der Agent läuft. Ein guter Prompt ist präzise: Er gibt die Rolle des Agenten, das Format jedes Schritts und die Budgetregeln an. Ein schlechter Prompt vergräbt diese Anweisungen in Beispielen und Einschränkungen. Eine minimale Vorlage demonstriert das Prinzip:
SYSTEM_PROMPT = """You are a research assistant.
Work in steps. After each step, write a single line:
[step N] <action> -> <conclusion>
Keep the ledger under 10 lines. Do not recap old steps."""
print(count_tokens(SYSTEM_PROMPT))Die genaue Formulierung wird für Ihre Aufgabe anders sein, aber die Disziplin ist dieselbe: Wenn ein Satz entfernt werden kann, ohne das beobachtete Verhalten zu ändern, entfernen Sie ihn. Im Zweifel führen Sie einen kleinen A/B-Test mit und ohne den Satz durch und vergleichen die Erfolgsraten der Aufgabe, nicht Ihre Intuition.
Alles zusammenfügen
Wenn Sie diese Praktiken kombinieren, ist die Wirkung kumulativ. Ein typischer Agentenlauf könnte so aussehen:
- Der System-Prompt hat 150 Tokens statt 800.
- Werkzeugausgaben werden auf jeweils 400 Zeichen gekürzt statt auf 5.000.
- Der Gesprächsverlauf ist ein fünfzeiliges Ledger statt eines 40-Runden-Transkripts.
- Der Abruf holt drei kurze Chunks statt zehn langer Dokumente.
Dieselbe Aufgabe läuft nun mit einer Größenordnung weniger Tokens. Die Latenz sinkt, weil die Eingabeverarbeitung schneller ist. Die Kosten sinken, weil die Eingabepreisgestaltung über die Runden multiplikativ ist. Und in vielen Fällen verbessert sich die Qualität, weil das Modell nicht mehr gezwungen ist, in einem Meer aus Rauschen nach einem Signal zu suchen.
Es gibt Grenzen. Einige Aufgaben erfordern wirklich lange Dokumente im Kontext, und aggressive Komprimierung kann den exakten Wortlaut verlieren, den der Agent braucht. Zitierlastige Rechtsanalysen zum Beispiel verlangen möglicherweise wörtlichen Quelltext. Das Ziel ist nicht null Tokens; es ist der kleinste Kontext, der die Aufgabe zuverlässig abschließt. Das ist die praktische Definition von richtig gemachtem ACE: nicht „wie viel kann das Modell halten", sondern „wie wenig braucht die Aufgabe tatsächlich".
Eine nützliche Übung ist, einen Ihrer bestehenden Agenten zu nehmen, ihn mit einem Standardtestfall auszuführen und die insgesamt verbrauchten Tokens von Anfang bis Ende zu zählen. Wenden Sie dann die vier obigen Beispiele einzeln an und führen Sie den Testfall nach jeder Änderung erneut aus. Sie werden schnell entdecken, welcher Schritt in Ihrer Pipeline der größte Verbraucher ist – und ob er sich seinen Platz im Kontext je verdient hat.
Fazit
Agentisches Kontext-Engineering wird oft als Problem des Maßstabs formuliert: größere Modelle, größere Fenster, größere Budgets. Der IBM-Research-Beitrag „Thinking of ACE? We Can Do It with Fewer Tokens" vertritt den gegenteiligen Standpunkt, und der praktische Werkzeugkasten in diesem Artikel folgt derselben Richtung. Token-Effizienz ist keine Leistungsoptimierung, die Sie anwenden, nachdem der Agent gebaut ist. Sie ist eine Entwurfsbeschränkung, die Sie ab dem ersten Prompt anwenden.
Beginnen Sie damit, zu messen, was Ihr Agent tatsächlich ausgibt. Kürzen Sie dann, was er nicht braucht. Ersetzen Sie dann rohen Verlauf durch Struktur. Sie werden mit ziemlicher Sicherheit feststellen, dass der Agent viel mehr mit sich herumtrug, als er je verwendete – und dass weniger Tokens, gezielt eingesetzt, genug sind.



