Gennemgang af en komplet prøveeksamen

Scenarie 1, kundesupportagent. En supportagent kalder værktøjer i en løkke. Teamet spørger, hvordan løkken skal afgøre, at den er færdig.

• A) Gennemsøg assistentens tekst efter "resolved" eller "done".
• B) Stop efter en fast grænse på 10 iterationer.
• C) Undersøg stop_reason; fortsæt, mens den er tool_use, og afslut ved end_turn.
• D) Stop, så snart et værktøj returnerer et resultat.

Arbejd dig gennem det: A er tekstfortolkning (uhensigtsmæssigt mønster). B behandler grænsen som det primære stop (grænser er kun et sikkerhedsnet). D stopper for tidligt — ét værktøjsresultat afslutter sjældent opgaven. Løkken er modelstyret via stop_reason.

Svar: C.

Eksamen tester dette gentagne gange, fordi det er grundlaget for agentbaseret design. Beslutninger styres af modellen; hårdkodning er reserveret til garantier. Modellen udsender en struktureret stop_reason på hver omgang — det er kontrakten, så brug den i stedet for at opfinde en heuristik over fri tekst.

• end_turn — opgaven er færdig, afslut løkken.
• tool_use — kør de ønskede værktøjer, føj resultaterne til historikken, og anmod igen.
• max_tokens — outputtet blev afkortet; hæv budgettet eller fortsæt.
• stop_sequence — en konfigureret stopstreng blev fundet.

Grænsen for iterationer er din sikkerhedssele mod en løbsk løkke. Den beskytter dig; den beslutter ikke for dig.

Scenarie 1 fortsat. Politik: Refusioner over $500 skal blokeres. Hvor hører denne regel hjemme?

• A) I systemprompten: "Udsted aldrig en refusion over $500."
• B) I en PostToolUse- eller hook til udgående kald, der deterministisk blokerer handlingen.
• C) Bed modellen vurdere sin egen tillid, før den udsteder en refusion.
• D) Et few-shot-eksempel, der viser en afvist refusion på $600.

A og D er udelukkende promptbaserede — omkring 90 % pålidelige, hvilket er uacceptabelt, når fejl har økonomiske eller juridiske konsekvenser. C er tillidsbaseret gating (uhensigtsmæssigt mønster). En hook håndhæver reglen 100 % deterministisk.

Svar: B.

Gør dig beslutningsgrænsen, som eksamen elsker, til en del af din tænkning:

• Hooks = 100 % deterministiske. Brug dem, når fejl har økonomiske, juridiske eller sikkerhedsmæssige omkostninger.
• Prompts = ~90 % sandsynlighedsbaserede. De er fine til tone, formatering og blød vejledning.

Et beslægtet korrekt mønster er den programmatiske forudbetingelse: Bloker process_refund, indtil get_customer har returneret en bekræftet identitet. Det er en deterministisk garanti, som promptvejledning ikke kan give dig. Når en valgmulighed siger "instruer modellen i altid at..." om en hård regel, skal du mistænke en afledningsmanøvre.

Scenarie 3, forskningssystem med flere agenter. En hub-og-ege-koordinator uddelegerer delopgaver til underagenter. En underagent bliver ved med at producere resultater, der ikke er relevante for emnet. Hvad er den mest sandsynlige årsag?

• A) Underagenter arver ikke koordinatorens samtalehistorik, og prompten manglede den nødvendige kontekst.
• B) Task-kaldene blev kørt parallelt i stedet for sekventielt.
• C) Koordinatoren glemte at analysere underagentens tekst for "complete".
• D) Underagenten havde kun 4 værktøjer i stedet for 18.

B er fint — parallelle Task-kald er en funktion. C er et uhensigtsmæssigt mønster med tekstfortolkning. D er omvendt (4-5 værktøjer er optimalt; 18 eller flere forringer valget). Det afgørende faktum er: Underagenter starter uden historik; videregiv al kontekst eksplicit.

Svar: A.

Koordinatoren i en hub-and-spoke-arkitektur har fem opgaver: opdele, delegere, aggregere, dirigere og håndtere fejl. To detaljer, der ofte testes til eksamen, følger med dette scenarie:

• Definér hver underagent med mindst mulige privilegier — name, description, system_prompt, allowed_tools afgrænset til dens rolle.
• Ved fejl i en underagent skal du returnere delvise resultater plus en dækningsannotering ("kilde X er utilgængelig") i stedet for at afbryde hele arbejdsgangen eller skjule hullet ved stiltiende at udelade det.

Forskningssvar skal også indeholde dokumentation af ophav: påstand → kilde-URL, dokumentnavn, citat, udgivelsesdato. Modstridende statistikker skal annoteres og ikke løses vilkårligt — datoer forklarer ofte konflikten.

Scenarie 5, Claude Code til CI/CD. Du tilføjer en automatiseret kodegennemgang til en pipeline før sammenlægning. Hvilken opsætning er korrekt?

• A) Kør interaktivt, og videresend TUI-outputtet til en logfil.
• B) Brug -p med --output-format json i en ny, isoleret session, adskilt fra enhver genereringskontekst.
• C) Indsend ændringerne til Message Batches API for at spare 50 %.
• D) Genbrug den samme session, som genererede koden, så den har hele konteksten.

A er ikke ikke-interaktiv. C er forkert — Batch har ingen SLA for latenstid og er beregnet til ikke-blokerende opgaver, aldrig som en kontrol før sammenlægning. D er selvgennemgang i samme session (forfatteren vil ikke udfordre sin egen argumentation). En uafhængig, isoleret gennemgang er det rigtige valg.

Svar: B.

Distraktoren med Batch API dukker op i flere scenarier, så fastslå reglen. Message Batches er 50 % billigere med et tidsvindue på op til 24 timer, ingen SLA for latenstid og ingen værktøjskald over flere ture.

• Rigtig anvendelse: natlige kontroller, masseoprettelse af rapporter og ikke-blokerende berigelse. Knyt resultaterne sammen via custom_id; indsend kun fejlene igen.
• Forkert anvendelse: alt, der blokerer eller er tidsfølsomt — kontroller før sammenlægning, svar til live-support og en interaktiv agenttur.

For at reducere falske positiver i CI-gennemgangen skal du angive eksplicitte kriterier ("markér kun, når en kommentar modsiger koden") i stedet for vage instruktioner som "vær mere præcis".

Scenarie 6, struktureret dataudtræk. Du udtrækker fakturadata via et JSON Schema til værktøjsbrug. En faktura har nogle gange ikke feltet purchase_order. Hvordan modellerer du det?

• A) Markér purchase_order som obligatorisk, så modellen aldrig springer det over.
• B) Lad det være valgfrit; kræv kun felter, der altid er til stede.
• C) Tving tool_choice: "auto", så modellen kan svare i prosa.
• D) Fjern skemavalideringen, og prøv igen ved enhver fortolkningsfejl.

A tvinger modellen til at opdigte et manglende felt — den klassiske skemafælde. C garanterer ikke et struktureret resultat. Det rigtige er aldrig at kræve et felt, der muligvis mangler, og at bruge tool_choice: "any" for at garantere et værktøjskald.

Svar: B.

Du har netop arbejdet med fem scenariespørgsmål. Tag disse reflekser med til den rigtige eksamen:

• Løkkestyring: styr efter stop_reason (end_turn), aldrig efter tekstfortolkning; grænser er kun et sikkerhedsnet.
• Faste regler: brug hooks og programmatiske forudsætninger til økonomi, jura og sikkerhed; brug kun prompter til bløde retningslinjer.
• Flere agenter: underagenter arver ingen historik — videregiv konteksten eksplicit; returnér delvise resultater med dækningsannoteringer.
• CI/CD: -p --output-format json, isoleret/uafhængig gennemgang; brug kun Batch API til ikke-blokerende opgaver.
• Skemaer: kræv aldrig et felt, der muligvis mangler; tool_choice: "any" garanterer struktur; genforsøg med tilbagemelding retter format- og regnefejl, ikke manglende data.

Besvar hvert spørgsmål, fjern først de nævnte uhensigtsmæssige mønstre, og 720 er helt inden for rækkevidde. Bestå den.