Das Gatter, das 43 bestandene Tests meldete und keinen einzigen ausführte

Datadog hat vergangene Woche einen Text darüber veröffentlicht, wie man Golden Paths für autonome Agenten anpasst. Sorgfältige Arbeit, und die zentrale Anweisung teile ich: die Plattform muss die Verträge durchsetzen, nicht der Agent. Ein Agent, der sich selbst überwachen soll, ist ein Zeuge, der über sein eigenes Alibi aussagt.

Der Artikel nennt acht Anforderungen an einen agentenfähigen Pfad. Eine davon ist verpflichtende Telemetrie je Lauf: Modellaufrufe, Werkzeugwahl, geholter Kontext, Latenz, Fehler, Wiederholungen, Bewertungen, Kosten. Eine andere ist ein Audit-Ereignis je Handlung, verknüpft mit der Aufgabenidentität, die sie ausgelöst hat.

Ich habe meinen eigenen Bau nach Läufen durchsucht, die keine Nachweise erzeugt haben. Ich habe keinen gefunden. Gefunden habe ich vier Fälle, in denen die Nachweise genau wie vorgeschrieben entstanden, von einer Plattform durchgesetzt statt von einem Agenten, in jedem Feld vollständig, und falsch.

Die Suite, die bestand, ohne zu laufen

Die End-to-End-Suite fährt jede Route in einem echten Browser ab und sichert zu: keine Fehlerseiten, keine Konsolenfehler, keine 4xx und 5xx. Sie ist das einzige Gatter im Stapel, das nach dem Produkt fragt statt nach dem Code.

Sie erklärte keine Abhängigkeit auf die Anwendung, die sie prüft. Ihr Cache-Schlüssel enthielt das Frontend also nie, und der Task Runner tat, wofür ein Task Runner gebaut ist: er erkannte eine unveränderte Eingabe und übersprang die Arbeit.

FULL TURBO
43 passed

Ausgeführt wurde nichts. Gelogen ist die Zeile trotzdem nicht. Dreiundvierzig Tests sind bestanden, beim letzten Lauf, wann immer der war. Der Nachweis ist zutreffend über einen Lauf, der irgendwann stattfand, und schweigt darüber, welcher es war.

Sie wurde grün auf einem kaputten Diagramm und dann noch einmal grün auf dem Commit, der das Diagramm reparierte. Zwei entgegengesetzte Zustände des Produkts, ein Urteil.

Alles, was Datadog verlangt, war vorhanden. Es gab eine Aufgabenidentität, eine aufgezeichnete Ausgabe, eine Plattform, die den Vertrag durchsetzte, und einen Lauf, dessen Telemetrie jedes Dashboard anstandslos angenommen hätte.

Drei weitere derselben Form

• Eine Maschinengrenze, gemeldet als Produktfehler. Playwrights voreingestellte Worker-Zahl brachte den Entwicklungs-Proxy um: acht Worker auf einer Maschine mit sechzehn Kernen erledigten ihn in drei von drei Läufen, die Antwortzeiten stiegen von 60 ms auf 890 ms, danach wurde jede weitere Anfrage abgewiesen. Die Suite zeichnete Fehler, Wiederholungen und Latenz auf, alle echt. Zugeschrieben hat sie sie der Anwendung. Auf vier Worker gedeckelt überlebte sie drei von drei.
• Ein Linter, rot auf dem eigenen Auspuff. Der Formatierer prüfte test-results/.last-run.json mit, eine Datei, die Playwright nach jedem Lauf schreibt. Das Linting wurde rot wegen einer Ausgabe, die kein Mensch erzeugt hatte. Ein Audit-Ereignis über das Audit-System.
• Eine Optimierung, wirkungslos in der einzigen Umgebung, auf die es ankam. Preload-Hinweise trugen crossorigin nur, wenn die API auf einer anderen Origin lag. In der Entwicklung läuft die API auf eigenem Port, die Bedingung nahm also immer diesen Zweig und der Test lief grün. In Produktion, gleichursprünglich, meldeten alle vier Hinweise „preloaded but not used". Die Reparatur brachte das LCP von 600 ms auf 464 ms.

In jedem Fall erzeugte der Lauf Nachweise. In jedem Fall setzte eine Plattform etwas durch. In jedem Fall war das Durchgesetzte nicht das, was irgendjemand wollte.

Die Anforderung, die fehlt

Datadogs Liste dreht sich darum, dass Nachweise entstehen, aufbewahrt und verknüpft werden. Jeder Punkt setzt voraus, dass ein Signal, einmal abgegeben, das bedeutet, was sein Name sagt.

Die neunte Anforderung, und ich würde sie über mehrere der anderen acht stellen:

Jede Kontrolle muss einmal beim Scheitern beobachtet worden sein, bevor man ihr traut.

Nicht getestet. Beobachtet. Schreib die verletzende Eingabe, sieh zu, wie das Gatter rot wird, repariere es und sieh zu, wie es grün wird. Ein Gatter, das man nie hat scheitern sehen, ist keine Kontrolle, sondern eine Verzierung, die zufällig die richtige Farbe hat.

Das ist keine theoretische Sorge. In derselben Codebasis waren zwei Anläufe für eine einzige Lint-Regel stillschweigend wirkungslos, einer wegen eines ungültigen Schemas, einer weil er außerhalb des Konfigurationsaufrufs stand. Beide linteten grün. Beide fingen nichts. Der einzige Unterschied zu einer funktionierenden Regel war, dass niemand einer von beiden beim Auslösen zugesehen hatte.

Der Cache-Schlüssel-Fehler wurde auf demselben Weg repariert. Nicht dadurch, die Konfiguration so lange zu lesen, bis sie richtig aussah, sondern dadurch, dieselbe Änderung zweimal zu machen und dem Task-Hash beim Wechseln zuzusehen. Zwei Hashes, zwei Läufe, eine Beobachtung. So viel ist „die Plattform setzt es durch" wert, sobald man nachgesehen hat.

Warum Agenten das verschärfen

Ein Mensch, der eine Suite laufen lässt, die alles übersprungen hat, merkt es meistens, weil die verstrichene Zeit nicht stimmt. Dreiundvierzig Browsertests sind nicht sofort fertig, und der Körper weiß das, auch wenn das Auge es nicht sieht.

Ein Agent hat diese Ahnung nicht. Er liest den Exit-Code. Das ist seine gesamte Beziehung zu deinem Gatter, und genau diese Beziehung ist in Datadogs Entwurf vorgesehen: deterministische Kontrollen zwischen dem probabilistischen Schritt und der folgenreichen Handlung.

Damit wächst der Schadensradius eines lügenden Gatters mit dem Grad der Automatisierung ringsum. Das grüne Häkchen, das ein Mensch als eine Eingabe unter mehreren behandelt, ist für den Agenten die einzige.

Next

Der Rat in diesem Artikel ist richtig, und ich arbeite lieber in einem System, das ihm folgt, als in einem, das es nicht tut. Die Lücke liegt nicht in dem, was er verlangt. Sie liegt in der Annahme darunter: dass die Schwierigkeit darin bestehe, Nachweise entstehen zu lassen, und nicht darin, Nachweise zu bekommen, die auf eine Art falsch sein können, die man bemerkt.

Alle vier Fälle stammen aus einem dreitägigen Bau, über den ich in dem Text über PostHogs Agenten-Regeln am selben Produkt geschrieben habe. Der nächste Text dieser Reihe nimmt Datadogs andere Veröffentlichung, den State-of-AI-Engineering-Report, und hält dessen Fehlerzahlen gegen eigene Messungen.

Wenn du eine Sache mitnimmst: nimm dir das Gatter, dem du am meisten vertraust, und versuch heute, es absichtlich zum Scheitern zu bringen. Gelingt es nicht, hast du kein funktionierendes Gatter gefunden, sondern eines, das du nie hast arbeiten sehen.