En altid tændt personlig agent bør ikke opføre sig som et notifikationsfeed med bedre grammatik. Dens opgave er ikke at reagere synligt på hver ny e-mail, hvert issue, hver prisændring, hver dokumentredigering eller hver kalenderopdatering. Dens opgave er at holde vagt, mens du er optaget af andet, genkende den lille del af ændringerne, der ændrer, hvad der bør ske næste gang, og bringe det rigtige arbejde frem igen på det rigtige tidspunkt og på det rigtige niveau.
Det gør »hvornår bør agenten vågne?« til et designspørgsmål og ikke kun et spørgsmål om ydeevne. Vågner den for ofte, bliver agenten endnu en kilde til støj. Holder den sig for ihærdigt i ro, overser den netop den grund, du bad den holde øje i første omgang. Handler den uden en klar grænse, bliver et nyttigt baggrundssystem til et problem med bemyndigelse.
Det rigtige svar er en række beslutninger. En ny hændelse fortjener måske ingen reaktion, en senere gennemgang, en tur fra hovedagenten eller din egen direkte vurdering. Det er forskellige udfald, og en troværdig agent bør ikke slå dem sammen til ét.
Altid tændt bør betyde kontinuitet, ikke afbrydelse
»Altid tændt« er værdifuldt, fordi verden ikke organiserer sig i chatsessioner. En pull request kan fejle, efter at du har klappet din bærbare sammen. En leverandør kan ændre en leveringsdato, mens du sidder i et møde. En kontrakt kan blive underskrevet tre dage efter, at I sidst talte om den. Agenten har brug for kontinuitet hen over de huller, hvis den skal bære et fortløbende ansvar.
Kontinuitet kræver ikke konstant ræsonnement. De fleste hændelser er dubletter, rutinemæssige bekræftelser, irrelevante ændringer eller information, der stadig er nyttig senere. At vække en stor model for hver hændelse spilder regnekraft, men den største omkostning ligger i adfærden: Hvis hver opvågning bliver til en besked, bruger agenten brugerens opmærksomhed, som om den var gratis.
Forskning i notifikationer på arbejdspladsen har længe fundet den samme spænding. Folk værdsætter passiv opmærksomhed, men notifikationer forstyrrer den opgave, de er fokuseret på. Forskning i begrænset udskydelse viser også, hvorfor »nu eller aldrig« er det forkerte valg: En advarsel kan udskydes inden for en kendt grænse, så opmærksomheden bevares, uden at hver ankomst behandles som akut.
En altid tændt agent bør derfor holde tre ure adskilt:
tidspunktet, hvor en hændelse ankommer;
tidspunktet, hvor agenten skal ræsonnere om den;
tidspunktet, hvor brugeren skal vide det eller træffe en beslutning.
Nogle gange er alle tre med det samme. Som regel er de ikke.
En opvågning er ikke en notifikation, og en notifikation er ikke en tilladelse
Den vigtigste grænse er let at overse. At opdage en hændelse, vække hovedagenten, give brugeren besked og udføre en ekstern handling er fire adskilte trin.
Forestil dig, at Comma følger en pull request. En ny reviewkommentar kommer ind. Overvågningsprocessen kan først afgøre, om kommentaren ændrer noget relevant. Gør den det, kan hovedagenten vågne og se på pull requesten, diskussionen omkring den og den Task, den hører til. Måske kan agenten opdatere et udkast eller forberede en rettelse uden at afbryde dig. Måske skal den fortælle dig, at vinduet for merge er i fare. Eller måske når den frem til en beslutning – som at acceptere en sikkerhedsmæssig afvejning – der tilhører dig.
Ingen af de konklusioner følger alene af, at kommentaren kom ind.
Sådan er Commas arkitektur tænkt til at fungere. Et let Loop holder vagt og vækker kun hovedagenten, når det er nødvendigt; derefter tager hovedagenten sig af det arbejde, der kræver kontekst. De tekniske detaljer, herunder hvordan Loops filtrerer hændelser, fjerner dobbelte opvågninger og kører inden for kvoter, er beskrevet i Programmerbare event-loops til vores distribuerede agent-harness. Princippet for læseren er enklere: En hændelse er et bevis, ikke en instruks, og en opvågning er en anmodning om at undersøge, ikke en tilladelse til at handle.
De fire test for at vække hovedagenten
En nyttig politik for opvågning kan udtrykkes som fire test. De er ikke et pointskema, hvor en høj samlet score automatisk vinder. Hver test fjerner en anden slags falsk alarm.
1. Har noget ændret sig væsentligt?
Den første test handler om tilstand, ikke om aktivitet. En ny besked er aktivitet. En frist, der rykker frem, en forhindring, der dukker op, en godkendelse, der kommer ind, eller en lovet betingelse, der bliver opfyldt, er en ændring af tilstanden.
Agenten bør forholde sig i ro, når den nye hændelse gentager det, den allerede ved, kvitterer for en besked uden at ændre planen eller ligger uden for det ansvar, den blev bedt om at overvåge. Stabile id’er og fjernelse af dubletter hjælper på systemniveau, men semantisk gentagelse kræver stadig dømmekraft: To forskellige beskeder kan formidle det samme »intet nyt«.
Den test forhindrer, at bevægelse giver sig ud for at være fremskridt.
2. Påvirker ændringen et aktivt mål eller en aktiv begrænsning?
Hvad der er væsentligt, er personligt. Et fald i en flypris er ikke vigtigt i sig selv; det betyder noget, hvis prisen falder under det budget, brugeren har sat for en rejse, vedkommende stadig har tænkt sig at tage på. Et fejlet build betyder noget forskelligt på en opgivet branch, en eksperimenterende branch og en releasekandidat.
Agenten har brug for målet, den aktuelle plan, de relevante begrænsninger og nok oplysninger om oprindelse til at vide, hvor de fakta kommer fra. Uden den kontekst kommer »vigtigt« let til at betyde dramatisk i almindelighed i stedet for nyttigt i den konkrete sag.
Det er også her, omfanget beskytter tilliden. Et Loop, der følger ét repository, bør ikke gøre en flygtig omtale af et andet projekt til en ny opgave. Indkommende indhold kan oplyse det overvågede ansvar; det kan ikke i stilhed udvide det.
3. Er der et vindue for handling?
Nogle ændringer betyder noget, men kræver ikke ræsonnement nu. En rapport, der skal gennemgås fredag, kan vente i et sammendrag. En forsinket forsendelse bliver måske først relevant, hvis den truer en afhængig begivenhed. Omvendt kan et aflyst møde, der frigør et sjældent bookingvindue, eller en regression i produktion, der spreder sig til flere brugere, miste værdi for hvert minuts forsinkelse.
Spørgsmålet er ikke bare »Er det akut?«. Det er: Ville ræsonnement nu skabe en bedre mulighed end ræsonnement senere?
Hvis ja, så væk hovedagenten. Hvis informationen stadig kan bruges lige så godt senere, så udskyd den til et naturligt kontrolpunkt, eller saml den med relaterede opdateringer. Hvis ingen handling er mulig, og ingen plan ændrer sig, så registrér den, og forhold dig i ro.
4. Hvem ejer den næste beslutning?
Når hovedagenten har samlet konteksten, bør den afgøre, hvem der har bemyndigelse til det næste trin.
Rutinemæssigt arbejde, der kan fortrydes og ligger inden for brugerens instruks, kan ofte fortsætte uden afbrydelse. Agenten kan opdatere sine noter til Tasken, forberede en sammenligning eller skrive et udkast til et svar. En beslutning med konsekvenser, en tvetydig beslutning eller en beslutning, der afhænger af præferencer, bør gå tilbage til brugeren. I Comma kan arbejde, der kræver en menneskelig beslutning, vente i Needs Review i stedet for at blive gættet igennem eller markeret som færdigt.
God eskalering er konkret. Den skal sige, hvad der har ændret sig, hvorfor det ændrer planen, hvad agenten allerede har tjekket, hvilken beslutning der er brug for, og hvornår beslutningen ikke længere er nyttig. »Hvad vil du gøre?« er ikke en overlevering; det er en ufærdig analyse.
Fire legitime udfald – ikke kun vågen eller sovende
Når testene er anvendt, har agenten fire nyttige svar.
Forholde sig i ro. Intet relevant har ændret sig, hændelsen er en dublet, eller den ligger uden for overvågningen. Ro bør være en bevidst konklusion med nok internt spor til at kunne fejlfinde – ikke fraværet af behandling.
Udskyde eller samle. Ændringen er relevant, men dens værdi overlever en forsinkelse. Føj den til det næste kontrolpunkt for Tasken, et overblik eller et kort sammendrag. Udskydelse kræver en grænse: »Senere« bør betyde et kendt tidspunkt eller en kendt betingelse, ikke en efterslæbning uden ejer.
Vække hovedagenten. Hændelsen kan ændre planen, kræver bredere kontekst eller er for usikker til det lette filter. Det er passende at vække, selv når det endelige resultat er ro; hovedagenten kan undersøge sagen og konkludere, at der ikke er brug for nogen besked til brugeren.
Give kontrollen tilbage til brugeren. Agenten er nået frem til en beslutning, der handler om bemyndigelse, risiko, smag eller en afvejning, som kun brugeren kan foretage. Den bør bevare det arbejde, der allerede er gjort, og fremlægge den mindste beslutning, der får arbejdet videre.
Den firedelte model gør usikkerhed til at håndtere. En overvågningsproces behøver ikke foregive sikkerhed, når beviserne er svage. Den kan vække hovedagenten til et grundigere tjek. Hovedagenten behøver til gengæld ikke opfinde autonomi, når en beslutning tilhører brugeren.
Sikkerhed bør ændre ruten, ikke skjule hændelsen
Et altid tændt system tager nogle gange fejl. Den farlige fejl er ikke bare en falsk alarm; det er en hændelse, der selvsikkert bliver undertrykt, så brugeren aldrig får mulighed for at hente den tilbage.
Commas standardholdning afspejler den asymmetri. Når Loops bruger Jev til at screene en fulgt pull request, et issue eller en tråd, kræver »forholde sig i ro« høj sikkerhed. Usikkerhed og fejl går til hovedagenten, som er instrueret i at kontrollere kilden, før den skriver til brugeren. Jev kan klassificere; den kan ikke sende beskeder, ændre ekstern tilstand eller give sig selv mere adgang. Den nuværende adfærd og de nuværende begrænsninger er dokumenteret i Mød Salix, Commas agent-harness og i dokumentationen for Loops.
Det design fjerner ikke fejl. En selvsikker, men forkert beslutning om at forholde sig i ro kan stadig skjule en opdatering. Det lægger dog usikkerheden på den sikrere rute: grundigere undersøgelse frem for stille afvisning. Brugere bør også kunne sætte en overvågning på pause eller slette den, indsnævre dens omfang og tage den operationelle adgang tilbage. En agent gør sig fortjent til at være til stede i baggrunden ved at gøre den tilstedeværelse til at efterprøve og fortryde.
En god afbrydelse kommer med arbejdet allerede gjort
Værdien af en altid tændt personlig agent er ikke, at den opdager ting før dig. Det gør overvågningsværktøjer allerede. Værdien er, at den kan forbinde ændringen med et aktivt ansvar og mindske det arbejde, der kræves af dig.
En nyttig afbrydelse kunne i sit indhold lyde sådan her:
Revieweren har bedt om en ændring af godkendelsesflowet. Den blokerer det releasekriterium, du har sat for torsdag. Jeg har tjekket den aktuelle branch og genskabt problemet. Jeg har forberedt en patch og tests; at godkende kompatibilitetsafvejningen er den eneste beslutning, jeg har brug for fra dig, før jeg anvender den.
Den besked indeholder kontekst, konsekvens, gennemført undersøgelse, et foreslået næste trin og en klar beslutningsgrænse. Den beder ikke brugeren om selv at stykke sammen, hvorfor hændelsen betyder noget. Den forveksler heller ikke en plausibel næste handling med tilladelse til at udføre den.
Den samme standard gælder, når agenten vælger ikke at afbryde. En udskudt opdatering bør dukke op igen ved det lovede kontrolpunkt. En beslutning om at forholde sig i ro bør kunne efterprøves. En Task, der kræver en vurdering, bør vente synligt og ikke forsvinde i en uendelig samtale.
Målet er rolig kontinuitet
En altid tændt agent bør skabe kontinuitet uden at kræve konstant opmærksomhed. Det ydre system overvåger billigt og snævert. Hovedagenten vågner, når en ændring kan ændre planen. Den undersøger, før den afbryder. Den fortsætter rutinemæssigt arbejde, der kan fortrydes, når brugeren allerede har givet bemyndigelsen, og den giver valg med konsekvenser tilbage med det relevante arbejde vedlagt.
Den oplevelse, der kommer ud af det, er ikke en agent, der taler mere. Det er en agent, der kan bevare ansvaret, mens den er stille – og som ved præcis, hvornår stilhed ikke længere er nyttig.
Ofte stillede spørgsmål
Hvad kører, før hovedagenten vågner?
I Comma overvåger et let Loop den valgte indbakke, det valgte repository, feed, API eller webhook. Dets program kan anvende deterministiske regler og kan bede Jev om en hurtig, typet beslutning. Hovedagenten og dens større kontekst kører kun, når Loopet sender en opvågning til en dybere undersøgelse eller handling.
Bør hver opvågning af agenten blive til en notifikation til brugeren?
Nej. En opvågning lader hovedagenten se på konteksten og afgøre, hvad hændelsen ændrer. Den kan fortsætte arbejdet i baggrunden, udskyde en opdatering eller konkludere, at brugeren ikke behøver at blive afbrudt. Brugerens opmærksomhed bør kun efterspørges, når viden eller vurdering er tidsfølsom.
Hvad bør der ske, når agenten er usikker?
Usikkerhed bør flytte hændelsen til en mere kompetent beslutningstager. Et let filter kan vække hovedagenten; hovedagenten kan kontrollere kilden, samle kontekst og enten fortsætte inden for sin bemyndigelse eller spørge brugeren. Usikkerhed bør ikke laves om til en selvsikker beslutning om at forholde sig i ro eller til en uautoriseret handling.
Hvordan kan en bruger stoppe en altid tændt overvågning?
Du kan bede Comma om at sætte et Loop på pause eller slette det. Adgangen til forbundne computere kan også sættes tilbage til skrivebeskyttet ved at slå operationer fra. Et altid tændt ansvar bør altid have et forståeligt omfang, en synlig tilstand og en praktisk slukknap.
Gør et signal til et nyttigt næste trin
Start med én kilde til hændelser, og skriv ned, hvad der væsentligt ville ændre din plan, hvor længe vinduet for handling står åbent, og hvilken beslutning der skal forblive din. Udforsk Commas Agent for at se, hvordan proaktiv opmærksomhed hænger sammen med Tasks og gennemgang, eller læs dokumentationen for Loops for den nuværende overvågningsmodel og dens begrænsninger.
