Por Kiu Estas Agent Trace?

Cursor publikigis Agent Trace, malferman specifikaĵon por spuri kiun kodon en deponejo estis skribita de LLM. Ĝi registras la modelon, la ilon, la konversacion kaj la ĝustajn liniintervallojn — ĉio aldonita al JSONL-dosiero en via projekto.

La prezento: “Ĉar agentoj skribas pli da kodo, gravas kompreni kio venis de AI kontraŭ homoj.”

Mi pasigis tempon legante la specifikaĵon kaj la referencan efektivigon. La inĝenierado estas solida — pura skemo, pripensita etendeblo, bona partnerlisto (Amp, Amplitude, Cloudflare, Cognition, Google, Vercel). Sed mi daŭre reiris al unu demando: kion vi faras kun ĉi tiuj datumoj?

Kion Ĝi Kaptas

Ĉiufoje kiam LLM redaktas dosieron, hoko ekfunkcias kaj registras spuron: kiu modelo, kiu ilo, kiuj linioj, kiu konversacio. La referenca efektivigo traktas eventojn de kaj Cursor kaj Claude Code:

// El la referenca hoko — eventoj fluas tra stdin
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 },
}));

La specifikaĵo difinas kvar kontribuanttipojn — human, ai, mixed, unknown — kaj subtenas lininivelaj atribuon kun enhavhaketoj por spuri kodon kiu moviĝas. Ĝi estas vendantneutrala, VCS-agnostika kaj etendebla per nomspacitaj metadatumoj.

Kiel datumformato, ĝi estas bone projekcita. La demando estas kion ĝi ebligas.

La Atribua Defio

La specifikaĵo modelas aŭtorecon kiel klasifikon. Sed LLM-asistita programado estas konversacio. Vi priskribas kion vi volas. La LLM generas ion. Vi redaktas duonon de ĝi, malakceptas funkcion, petas revizion, akceptas la duan provon, kaj poste permane riparas ekstreman kazon. Poste, alia LLM refaktorigas la tutan blokon.

Kiu skribis tiun kodon? La limo inter homa kaj LLM-aŭtoreco estas malklara, kaj ĝi fariĝas pli malklara. Plej multa reala kodo finiĝos kiel mixed, kaj se preskaŭ ĉio estas mixed, la klasifiko ne multe diras al vi.

Lininivelaj atribuo ankaŭ havas daŭrotempan problemon. Spuro diras “Claude skribis liniojn 10-50 ĉe enmeto abc123.” Du enmetojn poste, iu reformatigas tiun blokon aŭ ekstraktas funkcion el ĝi. La respondo de la specifikaĵo estas ĉenigi tra git blame, kaj enhavhaketoj povas helpi spuri kodon kiu moviĝas. Sed en laborfluo kun rebase kaj squash-merge, la ĉeno rompiĝas. Ĉi tiuj estas malfacilaj problemoj — la tipo kiun frua RFC devus surfacigi.

La Mankanta Ago

La specifikaĵo eksplicite malkonfesas la evidentajn uzojn: ne por kodposedado, ne por kvalitotaksado, ne por trejndatuma deveno. Ĝi diras “travideblecon”. Sed travidebleco estas rimedo, ne celo.

Se la kodo pasas revizion kaj testojn, kio ŝanĝiĝas ĉar LLM skribis ĝin? Se ĝi estas cima, vi riparas ĝin sendepende. La specifikaĵo neniam konektas atribuon al konkreta ago. Datumoj eniras, sed ne estas difinita maniero ricevi respondojn. Tio estas la breĉo — ne la formato, sed la uzkazo.

Kie Ĝi Fariĝas Interesa

Jen kion mi pensas Agent Trace efektive indikas, eĉ se la specifikaĵo ankoraŭ ne diras ĝin.

Malantaŭ ĉiu LLM-generita funkcio estas rezonaj ĵetonoj, malĝustaj turnoj, reprovoj, kuntekstŝanĝoj kaj ilalvokoj. Agento ne nur produktas kodon — ĝi trairas procezon por atingi ĝin. Ĝi legas dosierojn, miskomprenas interfacon, retroiras, provas alian aliron, rulas teston, riparas la malsukceson kaj atingas solvon. Tiu procezo estas nevidebla en la fina diff.

La hoko jam kaptas pli ol nur atribuon. Rigardu la enigsuprfacon:

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;
}

Modelo, seanco, konversacio, ilo, komando, daŭro, ĉu ĝi estas fona agento, la komponista reĝimo, ĉiu ilalvoko kun sia enigaĵo. Ĉi tiuj ne estas nur atribuaj datumoj. Ĉi tiuj estas procezdatumoj. Kaj procezdatumoj estas kie loĝas la vera valoro:

• Taksadoj. Kiuj modeloj luktas kun kiuj ŝablonoj? Funkcio kiu bezonis unu provon estas malsama de tiu kiu bezonis dek du reprovoj — eĉ se la eligo estas identa. Ne “kiu skribis ĝin” sed “kiom malfacila estis produkti ĝin.”
• Agentnativaj kodbazoj. Se agentoj konsistente luktas kun modulo — multaj malĝustaj turnoj, altaj reproptarifoj, ripetita kunteksta konfuzo — tio estas signalo ke la kodo ne estas strukturita por kiel agentoj funkcias. Vi povas refaktoriigi por klareco, pli bonaj interfacoj, pli eksplicitaj kontraktoj. La spurdatumoj fariĝas mapo de kie via kodbabo estas malamika al LLM-kunlaboro.
• Procezoptimumigo. Kiuj ilkonfiguroj produktas pli bonan unuaprovan kodon? Kiuj instigŝablonoj reduktas retroiradon? Vi ne povas respondi ĉi tiujn el liniatribuo. Vi bezonas la vojaĝon, ne la celon.

La Ĝusta Demando

Agent Trace estas frua. Ĝi estas RFC kun realaj defioj ĉirkaŭ atribumodeligado, intervaldaŭreco kaj demandosemantikoj. Sed la instinkto estas ĝusta — ĉar LLM skribas pli da kodo, ni bezonas strukturitajn datumojn pri kiel tio okazas.

La plej utila versio de ĉi tiu specifikaĵo eble ne estas “kion la LLM skribis?” sed “kiel la LLM atingis ĝin?” La lininivelaj ĉeflibroj estas startpunkto. La procesospuro — la rezonado, la iteracioj, la kosto atingi solvon — estas kie ĉi tio fariĝas io kion teamoj efektive uzas por skribi pli bonan kodon kun LLM.

Tio estas la specifikaĵo sur kiu mi volus konstrui.