En alltid påslått personlig agent bør ikke oppføre seg som en varslingsstrøm med bedre grammatikk. Jobben dens er ikke å reagere synlig på hver ny e-post, hver sak, hver prisendring, hver dokumentredigering eller hver kalenderoppdatering. Jobben dens er å holde vakt mens du er opptatt med annet, kjenne igjen den lille delen av endringene som påvirker hva som bør skje videre, og løfte riktig arbeid fram igjen til riktig tid og på riktig nivå.
Det gjør «når bør agenten våkne?» til et designspørsmål, ikke bare et spørsmål om ytelse. Våkner den for ofte, blir agenten enda en støykilde. Holder den seg for ihuga i ro, går den glipp av nettopp grunnen til at du ba den holde øye i utgangspunktet. Handler den uten en tydelig grense, blir et nyttig bakgrunnssystem et problem med fullmakter.
Det riktige svaret er en rekke beslutninger. En ny hendelse fortjener kanskje ingen reaksjon, en senere gjennomgang, en runde fra hovedagenten eller din egen direkte vurdering. Det er ulike utfall, og en pålitelig agent bør ikke slå dem sammen til ett.
Alltid påslått bør bety kontinuitet, ikke avbrytelser
«Alltid påslått» er verdifullt fordi verden ikke organiserer seg i chatteøkter. En pull request kan feile etter at du har lukket den bærbare. En leverandør kan endre en leveringsdato mens du sitter i møte. En kontrakt kan bli signert tre dager etter at dere sist snakket om den. Agenten trenger kontinuitet over disse hullene hvis den skal bære et pågående ansvar.
Kontinuitet krever ikke kontinuerlig resonnering. De fleste hendelser er duplikater, rutinemessige bekreftelser, irrelevante endringer eller informasjon som fortsatt er nyttig senere. Å vekke en stor modell for hver hendelse sløser med regnekraft, men den største kostnaden ligger i atferden: Hvis hver oppvåkning blir en melding, bruker agenten brukerens oppmerksomhet som om den var gratis.
Forskning på varsler på arbeidsplassen har lenge funnet den samme spenningen. Folk setter pris på å være passivt orientert, men varsler forstyrrer oppgaven de konsentrerer seg om. Forskning på begrenset utsettelse viser også hvorfor «nå eller aldri» er feil valg: Et varsel kan utsettes innenfor en kjent grense, slik at man forblir orientert uten at hver ankomst behandles som akutt.
En alltid påslått agent bør derfor holde tre klokker adskilt:
tidspunktet en hendelse kommer inn;
tidspunktet agenten må resonnere om den;
tidspunktet brukeren må vite det eller ta en beslutning.
Noen ganger er alle tre med en gang. Som regel ikke.
En oppvåkning er ikke et varsel, og et varsel er ikke en tillatelse
Den viktigste grensen er lett å overse. Å oppdage en hendelse, vekke hovedagenten, varsle brukeren og utføre en ekstern handling er fire separate trinn.
Tenk deg at Comma følger en pull request. En ny gjennomgangskommentar kommer inn. Overvåkingsprosessen kan først avgjøre om kommentaren endrer noe relevant. Gjør den det, kan hovedagenten våkne og se på pull requesten, diskusjonen rundt og oppgaven den hører til. Kanskje kan agenten oppdatere et utkast eller forberede en rettelse uten å avbryte deg. Kanskje må den si fra om at vinduet for sammenslåing er i fare. Eller kanskje kommer den fram til en beslutning – som å godta en sikkerhetsmessig avveining – som tilhører deg.
Ingen av disse konklusjonene følger av at kommentaren kom inn alene.
Commas arkitektur er ment å fungere etter dette skillet. En lett Loop holder vakt og vekker hovedagenten bare når det trengs; deretter gjør hovedagenten arbeidet som krever kontekst. De tekniske detaljene, blant annet hvordan Loops filtrerer hendelser, fjerner doble oppvåkninger og kjører innenfor kvoter, er beskrevet i Programmerbare hendelsesløkker for vår distribuerte agentharness. Prinsippet for leseren er enklere: En hendelse er et bevis, ikke en instruks, og en oppvåkning er en forespørsel om å undersøke, ikke en tillatelse til å handle.
De fire testene for å vekke hovedagenten
En nyttig regel for oppvåkning kan uttrykkes som fire tester. De er ikke et poengskjema der en høy sum automatisk vinner. Hver test fjerner en annen type falsk alarm.
1. Har noe endret seg vesentlig?
Den første testen handler om tilstand, ikke aktivitet. En ny melding er aktivitet. En frist som flyttes fram, en hindring som dukker opp, en godkjenning som kommer inn eller en lovet betingelse som blir oppfylt, er en endring i tilstanden.
Agenten bør holde seg i ro når den nye hendelsen gjentar det den allerede vet, bare bekrefter en melding uten å endre planen, eller ligger utenfor ansvaret den ble bedt om å overvåke. Stabile identifikatorer og fjerning av duplikater hjelper på systemnivå, men semantisk gjentakelse krever fortsatt skjønn: To ulike meldinger kan formidle det samme «ingenting nytt».
Denne testen hindrer at bevegelse later som den er framdrift.
2. Påvirker endringen et aktivt mål eller en aktiv begrensning?
Hva som er vesentlig, er personlig. At en flypris faller, er ikke viktig i seg selv; det betyr noe hvis prisen faller under budsjettet brukeren har satt for en reise vedkommende fortsatt har tenkt å ta. En mislykket build betyr ulike ting på en forlatt gren, en utforskende gren og en utgivelseskandidat.
Agenten trenger målet, den gjeldende planen, de relevante begrensningene og nok opplysninger om opphav til å vite hvor disse faktaene kommer fra. Uten den konteksten kommer «viktig» lett til å bety dramatisk generelt heller enn nyttig i det konkrete tilfellet.
Det er også her omfanget beskytter tilliten. En Loop som følger ett repository, bør ikke gjøre en flyktig omtale av et annet prosjekt til et nytt oppdrag. Innkommende innhold kan informere ansvaret som overvåkes; det kan ikke i stillhet utvide det.
3. Finnes det et handlingsvindu?
Noen endringer betyr noe, men krever ikke resonnering nå. En rapport som skal gjennomgås fredag, kan vente i en oppsummering. En forsinket forsendelse blir kanskje først relevant hvis den truer en avhengig hendelse. Motsatt kan et avlyst møte som frigjør et sjeldent bookingvindu, eller en regresjon i produksjon som sprer seg til flere brukere, miste verdi for hvert minutt med forsinkelse.
Spørsmålet er ikke bare «Haster dette?». Det er: Vil resonnering nå gi et bedre alternativ enn resonnering senere?
Hvis ja, vekk hovedagenten. Hvis informasjonen vil være like brukbar senere, utsett den til et naturlig kontrollpunkt, eller samle den med relaterte oppdateringer. Hvis ingen handling er mulig og ingen plan endres, registrer den og hold deg i ro.
4. Hvem eier den neste beslutningen?
Når hovedagenten har samlet konteksten, bør den avgjøre hvem som har fullmakt til neste trinn.
Rutinemessig arbeid som kan angres og ligger innenfor brukerens instruks, kan ofte fortsette uten avbrytelse. Agenten kan oppdatere notatene for oppgaven, forberede en sammenligning eller skrive et utkast til et svar. En beslutning med konsekvenser, en tvetydig beslutning eller en beslutning som avhenger av preferanser, bør gå tilbake til brukeren. I Comma kan arbeid som trenger en menneskelig beslutning, vente i Til gjennomgang i stedet for å bli gjettet seg gjennom eller markert som ferdig.
God eskalering er konkret. Den bør si hva som har endret seg, hvorfor det endrer planen, hva agenten allerede har sjekket, hvilken beslutning som trengs, og når beslutningen ikke lenger er nyttig. «Hva vil du gjøre?» er ikke en overlevering; det er en uferdig analyse.
Fire legitime utfall – ikke bare våken eller sovende
Når testene er brukt, har agenten fire nyttige svar.
Holde seg i ro. Ingenting relevant har endret seg, hendelsen er et duplikat, eller den ligger utenfor overvåkingen. Ro bør være en bevisst konklusjon med nok internt spor til å finne feil – ikke fravær av behandling.
Utsette eller samle. Endringen er relevant, men verdien overlever en forsinkelse. Legg den til neste kontrollpunkt for oppgaven, en orientering eller en kort oppsummering. Utsettelse trenger en grense: «Senere» bør bety et kjent tidspunkt eller en kjent betingelse, ikke en etterslepsliste uten eier.
Vekke hovedagenten. Hendelsen kan endre planen, krever bredere kontekst eller er for usikker for det lette filteret. Det er riktig å vekke selv når sluttresultatet er ro; hovedagenten kan undersøke og konkludere med at det ikke trengs noen melding til brukeren.
Gi kontrollen tilbake til brukeren. Agenten har kommet fram til en beslutning som gjelder fullmakt, risiko, smak eller en avveining bare brukeren kan gjøre. Den bør ta vare på arbeidet som allerede er gjort, og legge fram den minste beslutningen som får arbeidet videre.
Denne firedelte modellen gjør usikkerhet håndterbar. En overvåkingsprosess trenger ikke late som den er sikker når bevisene er svake. Den kan vekke hovedagenten for en grundigere sjekk. Hovedagenten trenger på sin side ikke finne på autonomi når en beslutning tilhører brukeren.
Sikkerhet bør endre ruten, ikke skjule hendelsen
Et alltid påslått system tar noen ganger feil. Den farlige feilen er ikke bare en falsk alarm; det er en hendelse som blir trygt undertrykt, slik at brukeren aldri får sjansen til å hente den tilbake.
Commas standardholdning gjenspeiler denne asymmetrien. Når Loops bruker Jev til å sile en fulgt pull request, en sak eller en tråd, krever «holde seg i ro» høy sikkerhet. Usikkerhet og feil går til hovedagenten, som er instruert om å kontrollere kilden før den skriver til brukeren. Jev kan klassifisere; den kan ikke sende meldinger, endre ekstern tilstand eller gi seg selv mer tilgang. Gjeldende atferd og begrensninger er dokumentert i Møt Salix, Commas agentharness og i dokumentasjonen for Loops.
Denne utformingen fjerner ikke feil. En selvsikker, men feil beslutning om å holde seg i ro kan fortsatt skjule en oppdatering. Den legger likevel usikkerheten på den tryggere ruten: grundigere undersøkelse i stedet for stille avvisning. Brukere bør også kunne sette en overvåking på pause eller slette den, snevre inn omfanget og ta tilbake den operative tilgangen. En agent gjør seg fortjent til å være til stede i bakgrunnen ved å gjøre den tilstedeværelsen mulig å etterprøve og angre.
En god avbrytelse kommer med arbeidet allerede gjort
Verdien av en alltid påslått personlig agent er ikke at den oppdager ting før deg. Det gjør overvåkingsverktøy allerede. Verdien er at den kan knytte endringen til et aktivt ansvar og redusere arbeidet som kreves av deg.
En nyttig avbrytelse kan i innhold lyde omtrent slik:
Gjennomgåeren har bedt om en endring i autentiseringsflyten. Den blokkerer utgivelseskriteriet du satte for torsdag. Jeg har sjekket den gjeldende grenen og gjenskapt problemet. Jeg har forberedt en patch og tester; å godkjenne kompatibilitetsavveiningen er den eneste beslutningen jeg trenger fra deg før jeg tar den i bruk.
Meldingen inneholder kontekst, konsekvens, fullført undersøkelse, et foreslått neste trinn og en tydelig beslutningsgrense. Den ber ikke brukeren om selv å rekonstruere hvorfor hendelsen betyr noe. Den forveksler heller ikke en plausibel neste handling med tillatelse til å utføre den.
Den samme standarden gjelder når agenten velger å ikke avbryte. En utsatt oppdatering bør dukke opp igjen ved det lovede kontrollpunktet. En beslutning om å holde seg i ro bør kunne etterprøves. En oppgave som trenger en vurdering, bør vente synlig og ikke forsvinne i en endeløs samtale.
Målet er rolig kontinuitet
En alltid påslått agent bør skape kontinuitet uten å kreve kontinuerlig oppmerksomhet. Det ytre systemet overvåker billig og snevert. Hovedagenten våkner når en endring kan endre planen. Den undersøker før den avbryter. Den fortsetter rutinemessig arbeid som kan angres når brukeren allerede har gitt fullmakten, og gir tilbake valg med konsekvenser med det relevante arbeidet vedlagt.
Opplevelsen som kommer ut av dette, er ikke en agent som snakker mer. Det er en agent som kan beholde ansvaret mens den er stille – og som vet nøyaktig når stillhet ikke lenger er nyttig.
Vanlige spørsmål
Hva kjører før hovedagenten våkner?
I Comma overvåker en lett Loop den valgte innboksen, repositoryet, strømmen, API-et eller webhooken. Programmet dens kan bruke deterministiske regler og kan be Jev om en rask, typet beslutning. Hovedagenten og den større konteksten dens kjører bare når Loopen sender en oppvåkning for en dypere undersøkelse eller handling.
Bør hver oppvåkning av agenten bli et varsel til brukeren?
Nei. En oppvåkning lar hovedagenten se på konteksten og avgjøre hva hendelsen endrer. Den kan fortsette arbeidet i bakgrunnen, utsette en oppdatering eller konkludere med at brukeren ikke trenger å bli avbrutt. Brukerens oppmerksomhet bør bare etterspørres når det å vite eller vurdere noe er tidskritisk.
Hva bør skje når agenten er usikker?
Usikkerhet bør flytte hendelsen til en mer kompetent beslutningstaker. Et lett filter kan vekke hovedagenten; hovedagenten kan kontrollere kilden, samle kontekst og enten fortsette innenfor fullmakten sin eller spørre brukeren. Usikkerhet bør ikke gjøres om til en selvsikker beslutning om å holde seg i ro eller til en handling uten tillatelse.
Hvordan kan en bruker stoppe en alltid påslått overvåking?
Du kan be Comma om å sette en Loop på pause eller slette den. Tilgangen til tilkoblede datamaskiner kan også settes tilbake til skrivebeskyttet ved å slå av operasjoner. Et alltid påslått ansvar bør alltid ha et forståelig omfang, en synlig tilstand og en praktisk av-bryter.
Gjør et signal om til et nyttig neste trinn
Begynn med én kilde til hendelser, og skriv ned hva som vesentlig ville endret planen din, hvor lenge handlingsvinduet står åpent, og hvilken beslutning som må forbli din. Utforsk Commas Agent for å se hvordan proaktiv oppmerksomhet henger sammen med oppgaver og gjennomgang, eller les dokumentasjonen for Loops for den gjeldende overvåkingsmodellen og begrensningene.
