Læs Claudes stop_reason før et svar markeres færdigt
En intern assistent skal skrive et beslutningsnotat, men svaret stopper midt i en sætning. Hvis integrationen blot gemmer enhver modtaget tekst som færdig, bliver et teknisk svar til en misvisende leverancestatus. Kontrollér afslutningsårsagen og selve indholdet.
Skeln mellem afsluttet og afkortet
Claudes Messages API har feltet stop_reason i vellykkede svar. end_turn betyder, at svaret sluttede naturligt. max_tokens betyder, at outputgrænsen blev nået, mens model_context_window_exceeded betyder, at kontekstvinduet blev fyldt. De sidste to kræver håndtering af et afkortet svar.
Vores anbefaling er at gemme afslutningsårsagen sammen med den interne kørselsstatus. En tom tekst bør også fanges: dokumentationen beskriver, at end_turn i nogle situationer kan returneres uden egentligt indhold. Ingen af værdierne erstatter kontrol af, om opgaven er besvaret.
Hold ventende værktøjer ude af færdigkøen
tool_use betyder, at modellen kalder et værktøj. pause_turn kan opstå, når en serverværktøjsløkke når sin iterationsgrænse, og dokumentationen beskriver, hvordan samtalen fortsættes. Begge kræver særskilt håndtering i integrationen.
Lad kun tilladte værktøjshandlinger blive udført, og bevar deres resultater i forløbet. Hvis et værktøj kan ændre et eksternt system, skal udvikleren afklare gentagelser før automatisk retry. En ny modelanmodning bør ikke utilsigtet udføre den samme eksterne handling igen.
Afprøv de statusser brugeren møder
Lav afgrænsede prøver for et normalt svar, et afkortet svar og et forløb, der afventer et værktøjsresultat. Brug ufarlige testdata. Kontrollér den synlige status efter frisk indlæsning, så brugeren kan skelne mellem færdig, igangværende og kræver handling.
Vores forslag er at definere leverancens indholdskrav separat: eksempelvis en konklusion, dens grundlag og uafklarede spørgsmål. Markér først notatet som klar til gennemgang, når både forløbet og indholdet opfylder de krav. Det gør en driftsfejl synlig uden at opfinde en færdig besvarelse.