KI SpotlightNewsHarnessMM soll den Tokenverbrauch beim DeepSeek Harness um 87,93 Prozent senken
Ein Preprint von Tsinghua University und Microsoft Research Asia beschreibt, wie Agent-Harnesses gespeicherte Entscheidungen wiederverwenden. Die Zahlen sind weder begutachtet noch unabhängig bestätigt.
Mit KI erstelltInhalt
◆ Fakten auf einen Blick
- Das Preprint „HarnessMM: Recursive Self-Improvement for Harness Token Efficiency“ liegt auf arXiv vor.
- Agent-Harnesses rufen das Modell nach Tool-Feedback wiederholt auf, obwohl die nächste Aktion bereits feststeht.
- Ein Controller an der Modell-Tool-Grenze ersetzt spätere Reasoning-Callbacks durch bereits aufgelöste Entscheidungen.
- Neue semantische Entscheidungen, nicht gestützte Evidenz sowie Enthaltung des Selektors rufen den ursprünglichen Akteur erneut auf.
- RSI verfeinert Begleit-Harness-Konfigurationen iterativ anhand von Trainings-Feedback; die Validierung wählt die Einsatz-Konfiguration aus.
HarnessMM soll den Tokenverbrauch beim DeepSeek Harness um 87,93 Prozent senken
Der arXiv-Preprint „HarnessMM: Recursive Self-Improvement for Harness Token Efficiency“ beschreibt, wie Agent-Harnesses deutlich weniger Tokens verbrauchen sollen. „HarnessMM“ steht für „Harness Minus Minus“. Laut Cryptobriefing wurde das Papier am 23. Oktober 2026 eingereicht. Als Autoren nennt es Yuhua Jiang, Chang Xu, Feifei Gao und Li Zhao von der Tsinghua University und Microsoft Research Asia.
Beim DeepSeek Harness sinkt der Verbrauch laut Paper von 96,28k auf 11,62k Tokens pro Aufgabe. Das sind 87,93 Prozent Ersparnis. Gleichzeitig steigt die Erfolgsquote von 71,43 auf 85,71 Prozent. Bei Codex auf HumanEval fallen die Tokens pro Aufgabe von 66,72k auf 47,02k, also 29,54 Prozent. Die Erfolgsquote bleibt dort bei 90,82 Prozent.
Gespeicherte Entscheidungen ersetzen spätere Modell-Aufrufe
Das Abstract beschreibt das Problem so: Nach einer Tool-Rückmeldung ruft der Harness das Modell erneut zum Schlussfolgern auf. Dabei hat ein früherer Aufruf die nächste Aktion oft schon festgelegt. HarnessMM setzt an dieser Stelle einen Controller an der Grenze zwischen Modell und Tool ein. Der Controller verwendet bereits aufgelöste Entscheidungen erneut und ersetzt so spätere Reasoning-Callbacks. Die Gewichte des Akteurs bleiben unverändert.
Die Methode besteht aus mehreren Bausteinen. Executable Decision Graphs speichern exakte Aktionen, wörtliche Argumente, kausale Abhängigkeiten und öffentliche Guards. Guarded Decision Reuse aktiviert diese Entscheidungen anhand beobachteter Receipts. Certified Callback Substitution führt sie über die native Schnittstelle aus und protokolliert, dass der registrierte langsame Callback entfällt. Neue semantische Entscheidungen, nicht gestützte Evidenz oder eine Enthaltung des Selektors rufen wieder den ursprünglichen Akteur auf.
Die rekursive Selbstverbesserung (RSI) verfeinert Begleitkonfigurationen anhand von Trainings-Feedback. Die Validierung wählt anschließend die Konfiguration für den Einsatz aus.
Eine separate MBPP-Ablation misst 26,91 Prozent geringere Kosten gegenüber Single-Use-Graphs und 19,52 Prozent geringere Kosten gegenüber beibehaltenen Callbacks. Das Repository nennt außerdem die visuelle Erweiterung HarnessMM-V. Deren Ergebnisse werden laut Repository getrennt von den Coding-Experimenten geführt.
Die große DeepSeek-Ersparnis stammt aus einem nicht begutachteten Preprint
Das Papier ist nicht peer-reviewed. Die Zahlen sind unabhängig weder bestätigt noch reproduziert. Der DeepSeek Harness ist ein Open-Source-Produkt von DeepSeek AI. Laut README befindet er sich in einer Developer Preview mit erwarteten inkompatiblen Änderungen. Er stammt nicht von den Paper-Autoren.
Auffällig ist der Vergleich mit Codex. Die DeepSeek-Baseline erreicht die niedrigere Erfolgsquote und verbraucht mit 96,28k mehr Tokens als Codex mit 66,72k. Ein schwacher oder ineffizienter Ausgangswert könnte den großen Effekt erklären. Das Material klärt diese Ursache nicht. Aus dem Abstract geht außerdem nicht hervor, ob der Benchmark identisch ist.
Cryptobriefing schreibt, die Erfolgsquote steige zugleich, „was bei Effizienz-Kompromissen normalerweise nicht so ist“. Das ist eine redaktionelle Wertung und kein Befund des Papers. Für Entwickler und Betreiber ergibt sich nach derzeitigem Stand kein Handlungsbedarf.
