Für Wen Ist Agent Trace?

2026-01-30 · 5 min read

Cursor veröffentlichte Agent Trace, eine offene Spezifikation zur Verfolgung, welcher Code in einem Repo von einem LLM geschrieben wurde. Es zeichnet das Modell, das Tool, das Gespräch und die exakten Zeilenbereiche auf — alles wird an eine JSONL-Datei in Ihrem Projekt angehängt.

Der Pitch: “Da Agenten immer mehr Code schreiben, ist es wichtig zu verstehen, was von KI im Gegensatz zu Menschen stammt.”

Ich habe Zeit damit verbracht, die Spezifikation und die Referenzimplementierung zu lesen. Die Technik ist solide — sauberes Schema, durchdachte Erweiterbarkeit, gute Partnerliste (Amp, Amplitude, Cloudflare, Cognition, Google, Vercel). Aber ich kam immer wieder auf eine Frage zurück: was macht man mit diesen Daten?

Was Es Erfasst

Jedes Mal, wenn ein LLM eine Datei bearbeitet, wird ein Hook ausgelöst und ein Trace aufgezeichnet: welches Modell, welches Tool, welche Zeilen, welches Gespräch. Die Referenzimplementierung verarbeitet Ereignisse sowohl von Cursor als auch von Claude Code:

// Aus dem Referenz-Hook — Ereignisse fließen über stdin ein
appendTrace(createTrace("ai", input.file_path!, {
  model: input.model,
  rangePositions,
  transcript: input.transcript_path,
  metadata: { conversation_id: input.conversation_id, generation_id: input.generation_id },
}));

Die Spezifikation definiert vier Contributor-Typen — human, ai, mixed, unknown — und unterstützt Zuordnung auf Zeilenebene mit Content-Hashes zur Verfolgung von Code, der sich bewegt. Sie ist anbieterunabhängig, VCS-agnostisch und über Metadaten mit Namespaces erweiterbar.

Als Datenformat ist es gut gestaltet. Die Frage ist, was es ermöglicht.

Die Zuordnungsherausforderung

Die Spezifikation modelliert Urheberschaft als Klassifizierung. Aber LLM-gestütztes Programmieren ist ein Gespräch. Sie beschreiben, was Sie wollen. Das LLM generiert etwas. Sie bearbeiten die Hälfte davon, lehnen eine Funktion ab, bitten um eine Überarbeitung, akzeptieren den zweiten Versuch und beheben dann manuell einen Grenzfall. Später refactort ein anderes LLM den gesamten Block.

Wer hat diesen Code geschrieben? Die Grenze zwischen menschlicher und LLM-Urheberschaft ist verschwommen, und sie wird immer verschwommener. Der meiste echte Code wird als mixed enden, und wenn fast alles mixed ist, sagt die Klassifizierung nicht viel aus.

Zuordnung auf Zeilenebene hat auch ein Haltbarkeitsproblem. Ein Trace sagt “Claude schrieb Zeilen 10-50 bei Commit abc123.” Zwei Commits später formatiert jemand diesen Block neu oder extrahiert eine Funktion daraus. Die Antwort der Spezifikation ist, durch git blame zu verketten, und Content-Hashes können helfen, Code zu verfolgen, der sich bewegt. Aber in Workflows mit Rebases und Squash-Merges bricht die Kette. Dies sind schwierige Probleme — die Art, die eine frühe RFC aufwerfen sollte.

Die Fehlende Aktion

Die Spezifikation lehnt die offensichtlichen Verwendungen explizit ab: nicht für Code-Eigentum, nicht für Qualitätsbewertung, nicht für Herkunft von Trainingsdaten. Sie sagt “Transparenz”. Aber Transparenz ist ein Mittel, kein Zweck.

Wenn der Code Review und Tests besteht, was ändert sich dann, weil ein LLM ihn geschrieben hat? Wenn er fehlerhaft ist, beheben Sie ihn trotzdem. Die Spezifikation verbindet Attribution nie mit einer konkreten Aktion. Daten gehen rein, aber es gibt keinen definierten Weg, Antworten herauszubekommen. Das ist die Lücke — nicht das Format, sondern der Anwendungsfall.

Wo Es Interessant Wird

Das ist es, worauf Agent Trace meiner Meinung nach tatsächlich hinweist, auch wenn die Spezifikation es noch nicht sagt.

Hinter jeder LLM-generierten Funktion stecken Reasoning-Token, Irrwege, Wiederholungen, Kontextwechsel und Tool-Aufrufe. Ein Agent produziert nicht nur Code — er durchläuft einen Prozess, um dorthin zu gelangen. Er liest Dateien, missversteht eine Schnittstelle, geht zurück, probiert einen anderen Ansatz, führt einen Test aus, behebt den Fehler und landet bei einer Lösung. Dieser Prozess ist im endgültigen Diff unsichtbar.

Der Hook erfasst bereits mehr als nur Attribution. Schauen Sie sich die Eingabe-Oberfläche an:

interface HookInput {
  hook_event_name: string;
  model?: string;
  transcript_path?: string | null;
  conversation_id?: string;
  generation_id?: string;
  session_id?: string;
  file_path?: string;
  edits?: FileEdit[];
  command?: string;
  duration?: number;
  is_background_agent?: boolean;
  composer_mode?: string;
  tool_name?: string;
  tool_input?: { file_path?: string; new_string?: string; old_string?: string; command?: string };
  tool_use_id?: string;
}

Modell, Sitzung, Gespräch, Tool, Befehl, Dauer, ob es ein Hintergrund-Agent ist, der Composer-Modus, jeder Tool-Aufruf mit seiner Eingabe. Dies sind nicht nur Attributionsdaten. Dies sind Prozessdaten. Und Prozessdaten sind dort, wo der wirkliche Wert liegt:

Bewertungen. Welche Modelle haben Schwierigkeiten mit welchen Mustern? Eine Funktion, die einen Versuch brauchte, ist anders als eine, die zwölf Versuche brauchte — auch wenn die Ausgabe identisch ist. Nicht “wer hat es geschrieben”, sondern “wie schwer war es zu produzieren.”
Agent-native Codebasen. Wenn Agenten durchweg mit einem Modul kämpfen — viele Irrwege, hohe Wiederholungsraten, wiederholte Kontextverwirrung — ist das ein Signal, dass der Code nicht für die Funktionsweise von Agenten strukturiert ist. Sie können für Klarheit, bessere Schnittstellen, explizitere Verträge refactoren. Die Trace-Daten werden zu einer Karte, wo Ihre Codebasis der LLM-Zusammenarbeit feindlich gegenübersteht.
Prozessoptimierung. Welche Tool-Konfigurationen produzieren besseren Code beim ersten Versuch? Welche Prompting-Muster reduzieren das Zurückverfolgen? Diese Fragen können Sie nicht aus der Zeilenzuordnung beantworten. Sie brauchen die Reise, nicht das Ziel.

Die Richtige Frage

Agent Trace ist noch früh. Es ist eine RFC mit echten Herausforderungen rund um Attributionsmodellierung, Bereichsdauerhaftigkeit und Abfragesemantics. Aber der Instinkt ist richtig — da LLMs mehr Code schreiben, brauchen wir strukturierte Daten darüber, wie das geschieht.

Die nützlichste Version dieser Spezifikation ist vielleicht nicht “was hat das LLM geschrieben?”, sondern “wie ist das LLM dorthin gekommen?”. Das Hauptbuch auf Zeilenebene ist ein Ausgangspunkt. Der Prozess-Trace — das Reasoning, die Iterationen, die Kosten des Erreichens einer Lösung — ist, wo dies zu etwas wird, das Teams tatsächlich verwenden, um besseren Code mit LLMs zu schreiben.

Das ist die Spezifikation, auf der ich aufbauen möchte.