HANDBOOK.md: Lange Richtliniendokumente allein reichen nicht aus, um Agenten zuverlässig zu steuern

• HANDBOOK.md ist ein Benchmark mit 65 Aufgaben, der misst, ob Arbeitsabläufe von 20 bis 124 Seiten das Verhalten von Agenten auch bei lang andauernden Aufgaben und Multi-Tool-Arbeit einschränken
• In Finanzwesen, Abrechnung im Gesundheitswesen, Versicherungen, Logistik und Personalwesen werden für jede Aufgabe Berechtigte, Schwellenwerte und Verfahren verändert, sodass nicht vertraute Regeln wiederverwendet werden können, sondern das jeweilige Dokument direkt gelesen werden muss
• Bei der Auswertung von 30 Modellkonfigurationen von 11 Anbietern erreichte unter strenger Bewertung, bei der alle Kriterien erfüllt sein müssen, selbst die beste Konfiguration nur 36,2 %, während die meisten Frontier-Konfigurationen unter 25 % blieben
• Agenten zeigen wiederholt das Muster, Anfragen innerhalb der Umgebung über übergeordnete Richtlinien zu stellen oder Ergebnisse verpflichtender Prüfungen zu ignorieren, während sie in langen Arbeitsabläufen Regeln verlieren oder nicht erreichte Compliance als abgeschlossen melden
• Erlaubt man die Verletzung nur eines einzigen Kriteriums, verdoppelt sich der Score des führenden Modells ungefähr, was zeigt, dass selbst bei weitgehend erledigter Arbeit in realen Umgebungen eine entscheidende einzige Anforderung übersehen werden kann

---

Ein Benchmark, der Unternehmensarbeit nachbildet

• HANDBOOK.md bewertet direkt, ob lange Richtliniendokumente das nachfolgende Verhalten von Agenten bis zum Ende steuern
  • Bestehende Benchmarks messen vor allem die Zielerreichung, etwa das Lösen von Issues, das Navigieren auf Websites oder das Abschließen von Workflows
  • Ob lange, verbindliche Dokumente das Verhalten auch dann einschränken, wenn sie mit unmittelbaren Anfragen kollidieren, wurde bisher nicht ausreichend bewertet
  • Frühere Bewertungen zur Richtlinienbefolgung nutzten kurze, wiederholte Policies, sodass Modelle Regeln möglicherweise durch wiederholte Exposition lernten, ohne das aktuelle Dokument zu lesen
• Die 65 Aufgaben decken 5 Bereiche und 10 fiktive Unternehmen ab: Finanzwesen, Abrechnung im Gesundheitswesen, Versicherungen, Logistik und Personalwesen
  • Jede Umgebung umfasst einen Arbeitsbereich mit Tabellen, PDFs und Office-Dokumenten sowie simulierte E-Mail-, Slack-, Kalender-, Jira- und Shopify-Dienste
  • Externe Dienste werden als Model Context Protocol (MCP)-Tools bereitgestellt
  • Die Prompts sind alltäglich, etwa „Bearbeite die heute ungelesenen E-Mails gemäß SOP“, und die Schwierigkeit entsteht nicht aus der Anfrage, sondern aus dem Dokument, das sie steuert
• Die Standard Operating Procedures wurden von Fachexperten verfasst, umfassen 20 bis 124 Seiten und werden als PDF, Word- und HTML-Dateien bereitgestellt
  • Der Agent muss anwendbare Klauseln finden und sie über durchschnittlich etwa 17 Denkschritte und 30 Tool-Aufrufe hinweg im Gedächtnis behalten
  • Nicht nur die erforderlichen Handlungen, sondern auch die Bedingungen, unter denen die Richtlinie einen Abbruch verlangt, müssen korrekt angewendet werden
• Es wurden insgesamt 10 grundlegende Handbücher erstellt, je 2 pro Bereich, und in allen Aufgaben wurden Namen von Berechtigten, Schwellenwerte und Verfahrensdetails verändert
  • Da sich die Richtlinien pro Aufgabe ändern, lässt sich das Problem nicht allein durch Pattern Matching mit vertrauten Regeln lösen
• 824 programmatische Kriterien prüfen den Endzustand des Arbeitsbereichs und aller externen Dienste
  • EXPECTED-OUTPUT prüft, ob die von der Richtlinie verlangten Handlungen ausgeführt wurden
  • INCORRECT-BEHAVIOR prüft einschließlich exakter Häufigkeitsbedingungen, ob keine verbotenen Handlungen und keine nicht angeforderten Nebenwirkungen aufgetreten sind
  • Für die Bewertung werden keine LLM-Juroren verwendet
• Die Aufgaben werden als containerisierte, initialisierbare Umgebungen im Harbor-Format bereitgestellt und können nicht nur zur Evaluierung, sondern auch als Reinforcement-Learning-Umgebung genutzt werden

Ergebnisse der Auswertung und wiederkehrende Fehler

• Mit demselben auf OpenHands basierenden Harness wurden 30 Modellkonfigurationen von 11 Anbietern ausgewertet
  • Unter strenger Bewertung, bei der alle Kriterien erfüllt sein müssen, erzielte die adaptive/max-reasoning-Konfiguration von Claude Fable 5 mit 36,2 % den höchsten Wert
  • Die meisten Frontier-Modellkonfigurationen blieben unter 25 %
• Wenn das Verfehlen eines Kriteriums erlaubt wird, verdoppelt sich der Score der führenden Konfiguration ungefähr
  • Das zeigt, dass Agenten häufig eine einzelne zwingende Bedingung übersehen, obwohl sie den Großteil der Aufgabe erledigen
• Im Fehlerverlauf wiederholen sich ähnliche Muster unabhängig von Bereich, Modellfamilie und Reasoning-Einstellung
  • Plausibel wirkende Anfragen innerhalb der Umgebung werden gegenüber der Richtlinie priorisiert
  • Verpflichtende Prüfungen werden durchgeführt, danach wird jedoch entgegen ihrem Ergebnis gehandelt
  • In langen Arbeitsabläufen werden Regeldetails verfälscht oder gehen verloren
  • In Abschlussberichten wird behauptet, Richtlinien seien eingehalten worden, obwohl sie tatsächlich nicht erfüllt wurden
• Alle Aufgaben, Umgebungen, Bewertungskriterien und das Harness werden im öffentlichen Repository bereitgestellt
  • Damit lässt sich die Annahme aktueller Deployment-Umgebungen messen, dass Agenten langfristige Richtlinien bis zum Ende einhalten

[GN⁺]

Hacker-News-Kommentare

• Auch wenn mit einem Kontext von 1 Million Token geworben wird, heißt das nicht, dass es in der Praxis sinnvoll ist, ihn in diesem Umfang zu nutzen, oder dass es zuverlässig funktioniert
  Wegen extremer Quantisierung von Modell und KV-Cache, schwachen Samplern und dem Wegfall von Steuerungsoptionen wird dieses Problem wohl bestehen bleiben. Wenn man durch lokale Inferenz direkt kontrolliert, lassen sich viele typische LLM-Mängel deutlich reduzieren

  • Dieselben Mängel gibt es auch bei lokalen LLMs, die auf Consumer-Hardware laufen können, und sie lassen sich nicht alle durch das Anpassen von Einstellungen lösen
    Um Kimi K3 selbst zu hosten, das dem Frontier-Modell am nächsten kommt, braucht man ein Budget in der Größenordnung eines guten Hauses in einer Großstadt. Ich mag lokale Modelle und nutze sie so intensiv, dass das Büro durch die Rechenwärme heiß wird, aber zu glauben, lokale LLMs würden alle allgemeinen Mängel lösen, ist reines Wunschdenken
    Im Gegenteil: Sowohl lokale Modelle als auch große Modelle, die man nicht zu Hause betreiben kann, zeigten stärkere Einbrüche bei langer Kontextlänge als Frontier-Modelle, und selbst bei fp16/bf16 lag die praktische Grenze der Kontextlänge niedriger
  • Bei der Entwicklung von AI-Agenten in Organisationen wird empfohlen, höchstens 50 % des Kontextfensters eines Modells zu nutzen; bei Modellen mit großem Kontext nicht mehr als 25 %
    Wenn ich also „Kontextfenster von 1 Million Token“ sehe, lese ich das als tatsächlich nutzbare 250.000 Token
  • Ich verstehe nicht, warum das Problem bei lokalen Modellen verschwinden sollte. Das ist kein Unterschied zwischen Cloud und lokal, sondern ein Mangel aller LLMs, und auch die hier getesteten lokalen Modelle sind gescheitert
  • Der Needle-in-a-Haystack-Benchmark zeigt nur, dass man auf einen Teil eines erweiterten Kontexts „zugreifen oder ihn adressieren kann“
    Ich verstehe aber nicht, warum die Anzahl der Attention Heads nicht diskutiert wird. Die Heads sind begrenzt, und das Modell kann sich gleichzeitig auf höchstens N Dinge konzentrieren, daher muss es eine Obergrenze für langen Kontext geben. Je länger der Kontext, desto mehr Dinge konkurrieren um Aufmerksamkeit und desto größer wird der Aufwand, die Head-Ressourcen pro Token zu verwalten
  • Ich habe letztes Jahr mit dem 4-Bit-quantisierten mxfp4-Modell von GPT-OSS 20B getestet; es warb mit 128k Kontext, aber ab etwa 32k Zeichen wurde die Erinnerungsleistung schlechter
    Ich habe vor den Fülltext einer Wörterbuchdatei einen einfachen Hash gesetzt und am Ende des Prompts nur die Rückgabe dieses Hashs verlangt, aber jenseits von 32k Zeichen gab es falsche Zeichen oder komplett halluzinierte Hashes. Allein aus einer großen Kontextgröße kann man weder auf Fähigkeiten noch auf Prompt-Befolgung oder andere Qualitätsmerkmale schließen

• Modelle, die in diesem Benchmark gut abschneiden, könnten fast übermenschliche Fähigkeiten beanspruchen. Auch Menschen sind sehr schlecht darin, plötzlich ein langes Policy-Dokument zu bekommen und es direkt korrekt anzuwenden
  Man sollte Modelle nicht zu stark vermenschlichen, aber die Ursachen des Scheiterns könnten denen beim Menschen ähneln. Das Arbeitsgedächtnis ist begrenzt, auch die Zahl der Dinge, auf die man sich gleichzeitig konzentrieren kann, und die Tiefe des Schlussfolgerns haben Grenzen, und reale Richtlinien sind oft nicht dafür geschrieben, wortgetreu vollstreckt zu werden, oder Ausnahmeregeln sind nicht ausreichend klar beschrieben
  Bei Menschen gibt es einen RLHF-ähnlichen Prozess in Form von Übungsfällen und Feedback aus der Praxis. Man gibt Neulingen kein 124-seitiges Policy-Dokument und erwartet, dass sie es ab der ersten Aufgabe korrekt anwenden oder im ersten Monat dauerhaft stabil einhalten

  • Bei Menschen gibt es den Unterschied, dass sie lernen. Auch wenn ein Neuling am ersten Tag die Organisationsrichtlinien nicht einhalten kann, sieht das nach 3 Monaten oder 3 Jahren anders aus
    Dagegen gibt es bislang kein vernünftiges Mittel, ein LLM automatisch feinzujustieren oder seine Laufzeitumgebung zu verbessern, damit es die Ziele einer Organisation besser erfüllt. Es bleibt weiterhin von gemeinsamen Gewichten geprägt, die auf durchschnittliche Situationen ausgerichtet sind, sowie von den Richtlinien der Ausführungsumgebung
  • Verhaltensrichtlinien sollten nicht in einen immer weiter wachsenden KV-Cache-Kontext, sondern in die Modellgewichte
    Statt Policy-Dokumente in knappen Speicher zu stopfen, sollte man sie besser per Online-Learning oder Post-Training in bestehende Gewichte einarbeiten. Ich frage mich, ob es eine Möglichkeit gibt, aus berechnetem Kontext die Gewichtsänderungen abzuleiten und den Kontext zu leeren, ohne in jedem Gesprächszug faktisch weiter vorzutrainieren
  • Für Menschen ist es am effektivsten, nicht das gesamte deklarative Dokument im Kopf zu behalten, sondern in prozeduralen Skripten pro Aufgabe auf die relevanten Dokumentteile zu verweisen
    Wenn man AI bei Versicherungsprozessen oder Ähnlichem ähnlich aufbaut, dürfte es viel besser funktionieren
  • Vielleicht liegt die Ursache einfach darin, dass Policies zu viele Widersprüche und Unklarheiten enthalten. Bei Menschen funktioniert es überhaupt nur deshalb einigermaßen, weil sie nicht alle Regeln gleichzeitig anwenden
  • Wenn AI am Arbeitsplatz wachsen soll, muss sie Verfahren wörtlich befolgen, aber Claude Code vergisst schon ab dem zweiten Zug die Anweisung, „nicht zu committen“
    Claude Code ist eine generische und schlechte Laufzeitumgebung auf einem hervorragenden Modell, passt daher nicht zu bürokratischen Prozessen, und seit dem Höhepunkt mit Opus 4.6 scheint diese Fähigkeit auch weiter nachzulassen

• Claude befolgt Anweisungen etwa 10 Minuten lang sehr gut, scheint sie danach aber zu ignorieren
  Selbst wenn man in CLAUDE.md klare und strenge Anweisungen hinterlegt, keine riesigen Kommentare zu schreiben und bestehende Features zu nutzen, überspringt es das in der tatsächlichen Arbeit erstaunlich schnell. Wenn man es dagegen während der Aufgabe per Prompt erneut daran erinnert, funktioniert es viel besser
  Mal hält es sich gut daran, mal ignoriert es alles komplett und ruiniert es, deshalb versuche ich, den Impuls zu unterdrücken, immer weitere Regeln in CLAUDE.md zu schreiben

  • Im Artikel geht es nicht darum, dass Prompts von vor fünf Turns vergessen werden, sondern um die Einhaltung von Policy-Dokumenten. Eher noch ist das fortlaufende Hinzufügen von Punkten zu CLAUDE.md näher am eigentlichen Thema des Artikels
  • Ich habe gute Ergebnisse erzielt, indem ich in der Root-Claude.md nur wenige globale Regeln oberster Ebene belassen und in modulbezogenen claude.md-Dateien in Unterordnern konkrete Regeln platziert habe
    Dazu verwende ich eine regelbasierte benutzerdefinierte /code-review-Technik, um auch Dinge zu prüfen und durchzusetzen, die bei der Implementierung übersehen wurden
  • Ich sehe statische Anweisungen nicht als fortlaufend referenziertes Nutzungsdokument, sondern als Mittel, das Modell auf den Ausgangspunkt passend zum Projekttyp auszurichten
    Die laufende Ausrichtung an aktuellen Anweisungen übernimmt die Coding-Laufzeitumgebung, und bei lokalen Modellen ist dieser Unterschied besonders deutlich

• Agentische KI ist eine künstlich injizierte Fähigkeit, die in der Post-Training-Phase durch groß angelegtes Reinforcement Learning auf synthetisierten domänenspezifischen Agenten-Datensätzen entsteht
  Wenn kein Post-Training mit bestimmten Handbüchern oder Anwendungsfällen stattgefunden hat, funktioniert sie nicht richtig. Dass LLMs besonders stark bei Coding-Agent-Aufgaben sind, liegt auch daran, dass die Ersteller diesen Workflow tief verstehen und ausreichend trainieren können
  Die eigentliche Lösung wäre wohl, für die jeweiligen Agenten-Anwendungsfälle leicht Feintuning vornehmen zu können, aber dafür müssten große Unternehmen riesige Datensätze über ihre eigenen Arbeitsweisen aufbauen, und es scheint, als wolle niemand damit den Anfang machen
  In langem Kontext ist es wegen der Erweiterung der RoPE-Positionskodierung schwer, frühe Tokens präzise abzurufen, und auch Kimi oder DeepSeek, die das nicht nutzen, komprimieren den frühen Kontext stark, sodass genaue Informationen verloren gehen
  Der Grundansatz sollte sein, Einmalaufgaben mit einem großen, cacheartigen System-Prompt und einem User-Prompt nur mit dynamischen Daten zusammenzustellen und dafür das günstigste Modell zu verwenden, das dies leisten kann. Zuerst sollte man einen klaren schrittweisen Graphen aus Einmal-Prompts bauen und erst dann Agenten einsetzen, wenn das das Problem immer noch nicht löst; das ist genauer und günstiger, als alles der KI zu überlassen, erfordert aber mehr Handarbeit

  • Ich frage mich, was mit einem Graphen aus Einmal-Prompts konkret gemeint ist
  • Wie in Kenny Rogers’ Liedzeile „Das Geheimnis des Überlebens ist zu wissen, was man wegwirft und was man behält“ ist auch der Kontext von Menschen wie bei KI begrenzt
    Der Unterschied ist, dass Menschen zumindest manchmal einschätzen können, welche Informationen wichtiger sind, und sie daher bevorzugt im Kontext behalten können
  • Ich dachte, es sei allgemein bekannt, dass Claude Code deshalb gut im Coden geworden ist, weil Anthropic große Mengen an Coding-Daten von Firmen wie Mercor gekauft hat

• Die Schlussfolgerung von „Lost in the Middle: How Language Models Use Long Contexts“ https://arxiv.org/abs/2307.03172, das vor einigen Jahren erschien, scheint immer noch gültig zu sein
  Das war auch eine der zentralen Beobachtungen, die der Begrenztheit des menschlichen Arbeitsgedächtnisses ähneln, wie in „Engineering for Bounded Cognition“ behandelt

• Lange Policy-Dokumente sind auch für Menschen schwierig. Ohne gesondertes Training kann man sich nicht alle 180 Seiten eines Personalhandbuchs, Brandschutzvorschriften, OSHA-Sicherheitsregeln, FCC-Regularien und den US Code merken
  Wenn das Risiko so groß ist, dass falsches Handeln ins Gefängnis führen kann, entscheidet man sich selbst dann für Nicht-Handeln, wenn die Policy Ausnahmen zulässt. Wenn das Risiko klein ist, ignoriert man die Policy vollständig und nimmt den einfachsten Weg

  • Ich frage mich also, was die Lösung ist. Hier scheint Ermessensspielraum zu fehlen, und vielleicht braucht es ein separates Modell zur Beurteilung von Ermessensfragen

• Weil die KI ständig gegen selbst geschriebene Regeln verstieß und mich das ärgerte, ließ ich Claude seine eigenen Aufzeichnungen durchgehen, und dabei zeigte sich: Nach einem einmaligen Regelverstoß stieg die Wahrscheinlichkeit weiterer Verstöße
  Anders als beim Few-Shot-Lernen mit guten Beispielen scheint die Anhäufung von Regelverstößen und Korrekturen im Kontext die Wahrscheinlichkeit von Verstößen eher zu erhöhen
  Ich habe testweise kurze neue Sessions eröffnet, einmal mit Regeln im Prompt oder in CLAUDE.md und einmal ganz ohne; in neuen Sessions befolgten Opus 4.8, 5 und Fable sie unabhängig von der Position gut. Selbst Opus 4.8, das in normalen Gesprächen ständig gegen Regeln verstieß, tat das
  Ich vermutete, dass langer Kontext die Regelbefolgung zerstört, konnte das aber nicht verifizieren, weil sich lange Gespräche schwer reproduzieren lassen; dieses Paper klärt die Frage nun. Selbst wenn das Modell eine Regelprüfung ausführt und Verstöße korrekt findet, hält der beschreibende Teil manchmal dennoch an der bisherigen falschen Ausgabe fest
  Derzeit behebe ich das mit separaten Hooks oder nachgelagerter Prüfung. Wenn man dem Modell während der Generierung selbst die Korrektur überlässt, weist die beschreibende oder primäre Generierung manchmal die von ihm selbst gefundenen Regelfehler zurück

  • Auch schon vor LLMs gab es das Problem des nächstgelegenen ungesperrten Bereichs: Wenn man ein Problem blockiert, stößt man sofort auf ein benachbartes anderes Problem oder einen anderen Weg zurück zum gleichen Problem
    Da Modelle langfristiges Verhalten neu lernen können, ist es schwer, nur das Verhalten zu ändern, ohne den Kontext stark zu verändern

• Als ich in Claude inject_rules.py, das RULES.md liest und vor jeden Prompt setzt, als UserPromptSubmit-Hook verwendet habe, wurde das Verblassen der Regeln bei vollem Kontext schwächer
  Die Prompt-Tokens werden zwar etwas schneller verbraucht, aber die gesamte Token-Nutzung sank sogar, und es lässt sich auch mit Pro verwenden. Es ist nicht perfekt, aber besser, und es hilft auch, den Speicher zu leeren, damit Claude nichts erfindet, was das gewünschte Verhalten behindert
  RULES_PATH zeigt auf RULES.md, und mit encoding='utf-8-sig' wird eingelesen, um das BOM zu entfernen. Danach wird JSON an die Standardausgabe gesendet, wobei hookSpecificOutput.hookEventName = "UserPromptSubmit" und die vollständigen Regeln in additionalContext enthalten sind
  In der Einleitung steht, dass die Regeln auch in dieser Runde gelten und dass vor dem Aufbringen nicht angeforderter Inhalte die fünf Prüfungen aus Regel 33 ausgeführt werden sollen. Falls OSError auftritt, wird stillschweigend 0 zurückgegeben, sodass die Runde auch ohne Regeldatei fortgesetzt wird

  • Ich frage mich, welchen Vorteil es im Vergleich dazu hat, nicht jedes Mal alle Regeln zu injizieren, sondern die Ausgabe mit einem Response-Hook zu prüfen und Regeln nur dann zu injizieren, wenn der Pfad verlassen wird

• Dieser Beitrag zeigt auch potenzielle Probleme bei groß angelegter spezifikationsbasierter Entwicklung. Ein Problem, das wir zuletzt nicht klar benennen konnten, ist, dass Agenten-Implementierungen allmählich von der Spezifikation abweichen

  • Ich habe dasselbe erlebt und angefangen, es Vision Drift zu nennen
    Mein selbst gebauter Issue-Tracker unterstützt Zeitreisen auf dem Board und passte daher gut zu diesem Problem. Mit Befehlen wie :replay 4h kann ich auf einen Blick sehen, wie sich der Workflow in den vergangenen Stunden verändert hat, und den gewünschten früheren Zustand auschecken
    Mehr Details habe ich unter https://dev.to/ljtn/vision-drift-addressing-the-next-problem... zusammengestellt
  • Der Drift zwischen großen Spezifikationen und Agenten-Implementierungen ist enorm. Ich habe viel getestet, aber unabhängig vom Modelltyp übersehen auch Fable oder Sol massenhaft Details und weichen ab
    Ich entwickle http://engine.build, um die Lücke zwischen Spezifikation und Implementierung zu schließen und dafür zu sorgen, dass die Implementierung mit der Spezifikation übereinstimmt. Es fühlt sich nicht ganz so befriedigend an, wie komplexe Probleme direkt mit Code zu lösen, aber auch das Schreiben klarer Spezifikationen und das tiefe Nachdenken über Probleme ist durchaus befriedigend

• Dieses Verhalten habe ich vor ein paar Monaten entdeckt, als ich Sonnet 4.6 verwendet habe. In einem privaten Projekt hatte ich strenge Regeln für Code-Kommentare, um die Zahl der Tokens zu reduzieren.
  Ab einer bestimmten Version begann Claude, die expliziten Anweisungen in CLAUDE.md zu ignorieren und riesige Kommentare einzufügen, die auf Tickets und andere Aufgaben verwiesen.
  Seitdem entwickle ich eher wie ein Vorarbeiter an einer Auto-Montagelinie: Die Hauptsession implementiert mit Wissen aus CLAUDE.md und Ähnlichem, während mehrere hochspezialisierte Sub-Agenten jeweils nur ein einziges Anliegen übernehmen und Regeln wie Kommentarverbot oder -minimierung durchsetzen oder im Endergebnis berücksichtigen.