På denne siden
Et kodeeksempel fra hukommelsen kan få en kundeoppdatering til å se enkel ut. I dette tenkte tilfellet lager en agent et utkast fra minnet. Metodenavnet virker rimelig. Feltene ser kjente ut. Testoppsettet godtar forespørselen. Den virkelige leverandørkontrakten ble endret etter at eksempelet ble skrevet.
Feilen begynte før kallet. Agenten brukte hukommelse der den trengte en gjeldende kilde.
En presentasjon om agenter og API-er som endrer seg argumenterer for å hente akkurat avsnittet som svarer på oppgaven. Prinsippet er særlig nyttig for integrasjoner, der en API-definisjon er en kontrakt i bevegelse, ikke bare bakgrunnslesing.
Et troverdig kall er ikke en kontrakt
Store modeller lærer av kode, dokumentasjon og diskusjoner fra ulike tidspunkter. Eksemplene kan fortsatt være nyttige for form og skrivemåte. De kan ikke fastslå hva en leverandør godtar i dag, på versjonen appen bruker, i kontoen som er koblet til synkroniseringen.
Shopifys guide til API-versjonering beskriver kvartalsvise utgivelser og versjonsspesifikke endringsnotater. En utvikler kan velge en støttet versjon og så lese endringene som er relevante ved oppgradering. Versjonen i forespørselen betyr mer enn modellens minne om «Shopify-API-et».
Brevos referanse for å opprette kontakter legger til et lag: Egendefinerte attributter må finnes på kontoen, og verdier som ikke passer til en definert type, kan bli ignorert. Et generelt API-skjema kan ikke fortelle agenten hvilke attributter akkurat denne kontoen har opprettet. Det krever et oppslag eller en kontroll avgrenset til kontoen.
Den gjeldende kontrakten har minst to deler: Leverandørens publiserte operasjon og objektene som er konfigurert på kontoen. Agenten trenger begge når oppgaven avhenger av begge.
Versjon og kontoavgrensning bør følge med svaret som ble hentet. En riktig beskrivelse av en operasjon i én API-versjon kan være feil i en annen. Et riktig attributtnavn på én Brevo-konto finnes kanskje ikke på den neste. Ta med valgt versjon og kontoens identifikator i testgrunnlaget, og la testen feile hvis en av dem er ukjent. Assistenten bør ikke løse usikkerheten ved å gjette ut fra et lignende eksempel.
Hent den lille delen du bruker
En dårlig løsning er å lime ti tusen operasjonsdefinisjoner inn i hver runde av samtalen med agenten. Da får modellen mer tekst å søke i, flere gamle avsnitt å forveksle og mindre plass til selve oppgaven. Be om operasjonen som flytter denne posten, og reglene som avgjør om den lykkes.
For en kontaktoppdatering kan det relevante materialet være operasjonens sti, tillatte felt, påkrevd identifikator, regler for attributttyper og gjeldende API-versjon. Gi agenten disse avsnittene med nettadressene til kildene. La resten være tilgjengelig for andre spørsmål.
Tajos guide til Brevo-API-et kan hjelpe leseren å orientere seg hos leverandøren. Den offisielle referansen bør avgjøre et konkret kall før produksjonskode bruker det. Leseren trenger en kilde som kan åpnes på nytt når leverandøren endrer noe.
Et kodearkiv kan gjøre dette gjentakbart. Registrer den låste versjonen, hashverdien til spesifikasjonen som er lagt i arkivet, og datoen den ble kontrollert. En endret hashverdi beviser ikke en inkompatibel endring. Den forteller den ansvarlige hva som må sammenlignes. En modell kan oppsummere den relevante forskjellen. Tester bør likevel kjøre operasjonene en fungerende synkronisering er avhengig av.
Behandle den genererte forespørselen som en hypotese med tre kontroller. Først: Stemmer den med den offisielle operasjonen og den låste versjonen? Deretter: Har den tilkoblede kontoen objektene forespørselen forutsetter? Til slutt: Etterlater en avgrenset kjøring forventet tilstand? En skjemasjekk kan svare på det første, et kontooppslag på det andre og en lesing etter skriving på det tredje. Ingen av dem erstatter de to andre.
- Leverandørens operasjon versjon · felt
Hva det publiserte API-et godtar
- Tilkoblet konto attributt · type
Hva som finnes på denne kontoen
- Avgrenset kjøring skriv · les tilbake
Hva som faktisk ble endret
Ikke forveksle søk med bevis for utførelse
En rimelig innvending er: «Offisiell dokumentasjon kan ligge etter tjenesten i drift.» Det kan den. Å lese dokumentasjonen er nødvendig, men ikke nok. En kontraktstest bør sende en avgrenset forespørsel gjennom samme klientkode og sjekke både svaret og tilstanden i målsystemet. Hvis tjenesten oppfører seg annerledes, registrer avviket og avgrens operasjonen som er berørt.
En agent bør også stoppe når kontrakten er tvetydig. En gjettet feltmapping brukt på mange kontakter er dyrere enn én gjennomgang av feltdefinisjonen. Guiden til å integrere flere bedriftsverktøy starter med å finne fasiten for hvert dataobjekt. Oppdaterte API-opplysninger er den samme disiplinen brukt på operasjonene som flytter objektet.
Kostnaden er å holde referanser og tester oppdatert. Alternativet er å betale for den samme gamle antakelsen for hver post en synkronisering berører.
Modellen kan huske ideen. Den må lese kontrakten og sjekke kontoen den er i ferd med å endre.
Dette trenger ikke gjøre hver handling treg. Mellomlagre det avgrensede, versjonsmerkede avsnittet og kontoskjemaet til en kjent hendelse gjør dem ugyldige, eller til et valgt tidspunkt for oppdatering. Lagre kilde og tidspunkt for innhenting sammen med beslutningen. Da betales prisen for et nytt oppslag når kontrakten kan ha endret seg, ikke for hver gjentatte rad i en allerede godkjent synkronisering.
Ofte Stilte Spørsmål
Hvorfor kan en AI-assistent ta feil om et API?
Treningen og lagrede eksempler kan være eldre enn leverandørens gjeldende skjema, versjon eller kontospesifikke konfigurasjon. Den nåværende offisielle kontrakten må leses for den aktuelle operasjonen.
Løser det problemet å låse en API-versjon?
Det gjør kontrakten stabil en stund, men versjoner eldes og kontokonfigurasjon betyr fortsatt noe. Følg med på hvilken versjon som støttes, og les endringsnotatene når du bytter.
Hva bør en agent hente?
Den avgrensede definisjonen av operasjonen, påkrevde felt og relevante versjonsnotater, med kildelenke og dato. Ikke last inn hele leverandørkatalogen for å svare på ett kall.