ทำไมการตรวจงานคือคอขวดของ AI agent และจะทำให้มันตรวจเองได้อย่างไร?

Von Nokka (นก-กา) | Datenprüfung am 25. Oktober 2026 · Teil 4 von 6 der Serie „Eine Person mit einem Agent-Team“

Dieser Artikel wurde von einer KI verfasst (deepseek-v4.1-flash · Modellanbieter: ollama-cloud) über den Hermes Agent, unter menschlicher Kontrolle und Qualitätsprüfung durch Nokka (นก-กา).

Der Satz, der meiner Meinung nach dieses gesamte Kapitel zusammenfasst, steht im pstack-Handbuch und besteht aus einer einzigen Zeile.

Wenn Sie weiterhin „sieht ungefähr okay aus“ als Beurteilungsmaßstab verwenden, werden Sie niemals in der Lage sein, Agenten wirklich selbstständig arbeiten zu lassen.

Das pstack-Handbuch schreibt direkt, dass die Prüfung der langsamste Schritt in der Arbeit eines Agenten ist, weil es der Schritt ist, der meistens auf einen Menschen wartet.

Wenn der Agent selbst prüfen kann, entkommen Sie Ihrer Position als Engpass; überspringt man diesen Schritt jedoch, führt die Erhöhung der Agentenanzahl nur zu einer entsprechend wachsenden Menge ungeprüfter Arbeit.

Ich glaube, das ist der Grund, warum viele Teams Agenten ausprobiert haben und sich wieder zurückgezogen haben: Sie haben die Produktionskapazität erhöht, aber der Engpass auf der Prüfseite blieb unverändert.

In Teil 2 habe ich bereits das Gleichnis vom drei Minuten gekochten Ei erzählt; jetzt möchte ich erläutern, was es in der Praxis bedeutet.

Wenn das Reproduzieren eines Bugs 20 Minuten dauert und Sie die Einzige oder der Einzige sind, der das kann, dann beschleunigt es die Arbeit nicht, wie schnell der Code auch behoben wird, weil die Warteschlange bei Ihnen hängen bleibt.

Die Lösung besteht daher nicht darin, weitere Agenten zu kaufen, sondern dem Agenten beizubringen, den Schritt zu übernehmen, den bisher Sie erledigt haben.

Das Handbuch empfiehlt, die Bedeutung von „fertig“ bereits im ersten Prompt in Formulierungen festzulegen, die genau zur Aufgabe passen.

/poteto-mode füge einen JSON-Output für diesen Befehl hinzu, der ursprüngliche Text muss byteidentisch bleiben, das JSON muss sich parsen lassen, beide Varianten müssen mit dem Beispielprojekt lauffähig sein, bring mir den Nachweis dazu Enter fullscreen mode Exit fullscreen mode Auf diese Weise hat der Agent drei Kriterien, die sich ausführen und prüfen lassen, statt eines Gefühls, das man erraten muss.

Wenn sich ein Kriterium nicht ausführen lässt, sollte eine gute Antwort sagen „nicht ermittelbar“ und nicht melden, dass alles fertig ist.

Dieser Punkt gefällt mir, weil er die Gewohnheit der meisten Werkzeuge umkehrt, die gewöhnlich zu ihren eigenen Gunsten antworten.

Wenn ein Pixel-für-Pixel-Bildvergleich nötig ist, empfiehlt das Handbuch, das Playbook visual-parity gegen einen fixierten Baseline zu verwenden, statt es mit dem menschlichen Auge zu prüfen.

Das Problem, das der Skill benchmark-checklist abfangen soll, sind Vorher-Nachher-Zahlen, denn sie sind der fehleranfälligste Nachweis.

Ein noch warmer Cache, ein anderer Build oder Code, der im Messzeitraum nicht ausgeführt wurde, können jeweils zu einer Scheingeschwindigkeit führen.

Der Skill benchmark-checklist stellt sieben Fragen, angefangen von: Was ist der limitierende Faktor der Zahlen? Warum ist es nicht doppelt so schnell? Laufen alle Seiten mit derselben Konfiguration wie in der echten Umgebung? Liegen die Ergebnisse über einer physikalischen Grenze wie Festplatten-Bandbreite oder Kernanzahl? Gibt es Fehler oder falsche Rückgabewerte? Welchen Median liefert das mehrmalige abwechselnde Wiederholen? Findet die gemessene Arbeit im Zeitraum tatsächlich statt? Und ist das Ergebnis wirklich relevant auf dem End-to-End-Pfad, auf dem Nutzer warten müssen?

Die Antwort muss lauten: schneller, langsamer, kein Unterschied oder nicht ermittelbar, zusammen mit der Anzahl der Durchläufe und dem Wertebereich; wenn sich der limitierende Faktor nicht angeben lässt, muss die Antwort „nicht ermittelbar“ lauten.

Das Beispiel im Handbuch ist ein noch warmer Cache, der die Zahlen gut aussehen lässt, und genau deshalb stimme ich dieser Regel zu.

Der Skill create-verification-skill schreibt Dateien für das Projekt mit fünf Pflichtabschnitten: Launch, Doctor, Drive, Evidence und Cleanup, plus einem Helpers-Abschnitt, wenn der Skill Skripte beilegt.

Gleichzeitig erzeugt er eine Feature-Map im Ordner features, in der festgehalten wird, was die App kann, und welches Ergebnis beweist, dass dieses Feature funktioniert.

Vor der Übergabe muss er sich selbst einen vollen Durchlauf beweisen: die App öffnen, die Bereitschaft prüfen, ein Feature durchlaufen, Nachweise sammeln, die Umgebung aufräumen und bestätigen, dass die Nachweise nach dem Aufräumen noch vorhanden sind.

Schlägt dieser Nachweis fehl, sagt das Handbuch unmissverständlich, dass man seine Ergebnisse nicht verwenden soll.

Die App verändert sich laufend, daher kann die Feature-Map veralten; das Handbuch empfiehlt, maintain-verification-skill mindestens einmal täglich auszuführen oder es als Automatisierung einzurichten.

Das Ergebnis hat drei Formen: clean bedeutet vollständig und nichts zu korrigieren, changed bedeutet ein PR, der nur den Ordner dieses Skills ändert, und blocked bedeutet, etwas blockiert und muss einer Person gemeldet werden.

Wichtig ist, dass er den Produktionscode niemals ändern darf, und falls er einen echten Regression findet, muss er sie melden, nicht durch eine Dokumentationsänderung überdecken.

Ich denke, das ist ein Standard, den die meisten Teams noch nicht haben, und der Grund, warum viele Agent-Aufgaben mit dem Wort „getestet“ enden, ohne dass sich das im Nachweis überprüfen lässt.

Das Handbuch führt aus, dass manche Bugs auf Pfaden liegen, die niemand geht, etwa zwei ineinander verschachtelte Retry-Versuche, ein Lock, der mitten im Schreiben abläuft, oder Ereignisse in falscher Reihenfolge.

Für Code, bei dem solche Fehler teuer sind, gibt es den Skill create-formal-verification-skill, der Ziele selbst aus dem Code auswählt und dann die Werkzeuge je nach Fragestellung wählt.

Lautet die Frage „Können Ereignisse ihre Reihenfolge tauschen?“, ist das passende Werkzeug ein Model Checker wie TLA+.

Und er muss zeigen, dass die Eigenschaft auf einer absichtlich fehlerhaft gemachten Codeversion bricht, denn eine Prüfung, die nie einen Fehler gesehen hat, beweist nichts.

In Teil 2 habe ich diese Zahl bereits genannt, aber ich möchte auf die Prüfmethodik zurückkommen.

Ihr Agent erstellte ein Skript, das die computed styles zwischen dem alten SCSS und dem neuen StyleX vergleicht und Screenshots der gemessenen Zustände vollständig gegenüberstellt.

Bei der Anwendung auf den gesamten Codebestand fanden sich noch Bugs bei z-index, Klassen, die von anderer Stelle verwendet wurden, und verborgene Kämpfe um die Specificity.

Deshalb änderte sie die Automatisierung, sodass sie immer nur ein Leaf Component verschiebt, Bilder von hover, focus, active, disabled und den spezifischen Zuständen dieser Komponente aufnimmt, vollständig in light, dark und high contrast, und ein zweiter Agent die gesammelten Medien prüft.

Das Ergebnis sind kleine PRs mit vollständigen Bildern und Videos statt eines riesigen PRs, den man kaum noch nachprüfen kann.

Erstens: Schreiben Sie Fertig-Kriterien als Zahl oder Bedingung. Wenn Sie schreiben „mach es schneller“, rät der Agent für Sie.

Zweitens: Sammeln Sie bei jedem Auftrag Nachweise. Verlangen Sie Screenshots, Videos oder die Ausgabe eines Befehls, nicht eine Beschreibung.

Drittens: Machen Sie die Prüfung zu einem Skript. Beginnen Sie mit einem einzigen Befehl, der die App öffnet und ein Feature durchläuft, und erweitern Sie ihn erst danach.

Ich wende diese drei Punkte auch auf meine eigenen Schreibarbeiten an: Kriterien für bestanden werden vorab festgelegt, und die Prüfnachweise werden jedes Mal aufbewahrt.

Jetzt wissen wir, wie man prüft, aber es bleibt eine größere Frage: Wenn ein Agent arbeiten soll, ohne dass wir dabei zusehen, was muss dann alles vorbereitet werden?

In Teil 5 gehe ich auf das Playbook zu autopilot, orchestrate und Overnight-Runs ein: An welchen Stellen kann die Arbeit stocken und was geht häufig schief?

Ich schreibe Teil für Teil und berichte Ihnen wie gewohnt über den Fortschritt.

Cursor (2026), Verify the result and open a PR (pstack-Anleitung, Teil 6). Lauren Tan (24. Juni 2026), Loops You Can Trust. Cursor (2026), pstack-Skill: create-verification-skill. Cursor (2026), pstack-Skill: benchmark-checklist.