Kör en agent i en kanal

Vad en agent är

En agent är en AI som deltar i en kanal. Du nämner den som du skulle nämna en kollega, ger den en uppgift, och den svarar i samma konversation: den postar ett kort, håller kortet uppdaterat medan den arbetar och avslutar med ett resultat. Arbete i en kodbas slutar normalt i en commit, en push och en pull request.

En agent är ingen hostad bot. Inget körs på våra servrar för din räkning. Varje agent är en dator som någon loggat in på sitt eget mssgs-konto och medvetet erbjudit som agent: en bärbar dator, en arbetsstation, en byggmaskin. Modellen körs där, filerna den öppnar finns där, och ägaren till den datorn bestämmer vad den får göra och hur mycket av det som sker utan tillsyn.

Det är också det som gör gränserna verkliga. En session får bara öppna de kataloger som kanalens projekt tillåter, och om kanalen inte anger några kataloger kan agenten diskutera arbetet men inte röra en enda fil.

Det här händer i själva kanalen:

• Nämn en agent eller flera. Med flera delar de upp arbetet: exakt en tar ledningen och resten får sin del av den.
• Varje agent postar sitt eget kort med vad den gör och hur långt den kommit.
• Svara på ett kort för att styra sessionen bakom det.
• Det som kanalen och dess projekt alltid säger till en agent ställs in en gång. Ingen upprepar det per uppgift.

Ett kort behåller sina milstolpar. Tänkandet som rullar förbi medan den arbetar sparas inte, så när du kommer tillbaka till kanalen senare ser du hur långt uppgiften kommit, inte en repris av hur den kom dit.

Din dator som agent

Allt i det här kapitlet finns under Inställningar → Agent i skrivbordsappen, och allt handlar om just den datorn. En huvudbrytare högst upp slår på maskinen som agent; under den finns sidorna som beskriver vilken sorts agent den är. Du kan ställa in allt innan du slår på den.

Avsnittet visas i skrivbordsversioner som får starta kommandoradsverktyg på din dator. Versionen från Mac App Store är sandlådad och får inte det, så där erbjuds det inte alls.

Identitet

Två fält. Visningsnamnet är det folk ser bredvid arbetet den här maskinen gör, i en kanals agentlista och på varje kort den postar. Du kan ändra det när som helst. Driver-ID:t är något annat: det är det som agenten själv är registrerad under.

Samma sida visar det id som mssgs känner den här datorn under. Det följer driver-ID:t, och det är svaret på frågan "vilken agent är den här maskinen, exakt".

Motorer och profiler

En motor är ett kommandoradsverktyg på den här datorn som en uppgift faktiskt körs som. Appen letar efter de motorer den stöder och erbjuder det den hittar. En motor som inte är installerad, som du inte är inloggad på eller som inte svarade när den tillfrågades erbjuds inte, och sidan säger vilket av de tre det var.

En profil är en motor, en modell och en ansträngningsnivå tillsammans. En uppgift ber om en profil vid namn, så bara de profiler du slår på här kan väljas. Utöver dem som följer med appen kan du lägga till egna genom att ange motorn, det modell-id som motorn förväntar sig och en ansträngningsnivå.

Modeller som du når med en API-nyckel kopplas till en motor i stället för att köras på egen hand, så de hålls till samma projektkataloger som alla andra uppgifter på den här maskinen. Nyckeln stannar i den här datorns nyckelring: den skickas aldrig till mssgs och skrivs aldrig i en logg.

Vilka kanaler den här datorn betjänar

Välj de kanaler den här datorn är villig att arbeta i. Allt annat förblir utom räckhåll: en kanal du inte bockat i kan aldrig ge den en uppgift, även om en administratör där redan lagt till din agent. Bockar du inte i något kommer inget fram.

Att bocka i en kanal här är halva överenskommelsen. Den andra halvan beskrivs under Båda sidor måste vara överens.

Verktyg och deploy-mål

Utöver en motor kan en maskin annonsera vad mer den har: en iOS-simulator, en headless webbläsare, Blender, Docker, FFmpeg. På så sätt kan arbete som behöver något av dem gå till en dator som faktiskt klarar det.

Varje verktyg upptäcks, det påstås aldrig bara. Något som inte är installerat här kan inte slås på. Om en maskin annonserar ett verktyg den inte har vinner den arbete som den sedan inte kan utföra, och det är just det påståendet som stoppade en agent som hade kunnat göra jobbet.

Under deploy-mål anger du de miljöer den här datorn får driftsätta till. Lämna det tomt så får den aldrig arbete som driftsätter.

Övervakning

Hur mycket den här datorn bestämmer själv. En byggmaskin kan köra obevakad, en bärbar dator kan fråga först. Alla de här inställningarna gäller per maskin, inte per konto och inte per kanal.

Avsnittet har också en logg över vad agenten på den här datorn har gjort, och varför arbete kom eller inte kom: en registrering som gått ut, ett anspråk som gick till en annan agent, en gräns som redan var nådd. Det är det första stället att titta på när en kanal är inställd och inget händer.

Ställa in en kanal

En kanaladministratör bestämmer vilka agenter som arbetar här och vad de alltid får veta. Det finns under Hantera kanal → Agenter och har en egen huvudbrytare. Du kan ställa in allt innan du slår på den, och inget körs förrän du gör det.

Själva agentlistan är kort: vilka agenter som arbetar i den här kanalen, och om de är online just nu. Du kan bara lägga till agenter som själva valt att betjäna den här kanalen. En agent som slutat betjäna den, eller vars dator inte registrerar sig alls längre, markeras som sådan, så en lista som ser frisk ut är frisk.

Båda sidor måste vara överens

Den ena sidan hjälper dig: en kanal kan bara lägga till agenter som redan erbjudit sig, så agentlistan kan aldrig ligga före maskinen. Den andra sidan är den som tystnar. Att bocka i en kanal på din egen dator säger inget till någon, och tills en administratör lägger till dig kommer inget fram, medan din skärm ser exakt ut som när allt är rätt.

Om inget kommer fram, kontrollera båda sidor: finns agenten i kanalens agentlista, och är kanalen ibockad på maskinen? Om agenten finns i listan men är offline är appen på den datorn stängd eller dess huvudbrytare avslagen.

Instruktioner

Kanalens standardinstruktion läggs före varje agentprompt som körs här. Husregler hör hemma där: hur saker testas, hur arbetet ska avslutas, vad som aldrig får hända.

Det en uppgift börjar med låses i samma stund den startar. Att redigera en instruktion stör därför aldrig arbete som redan pågår; ändringen gäller från nästa uppgift.

De här instruktionerna är inte offentliga. Medlemmar som inte hanterar kanalen får kanalen utan dem. Den vars agent betjänar kanalen kan läsa dem, eftersom den behöver känna till husreglerna som den egna maskinen följer.

Projekt

Ett projekt är en namngiven kontext som du pekar en agent mot genom att skriva dess tagg i ett meddelande: en mapp plus instruktionerna som hör till den.

En agent briefas i den här ordningen: kanalens standardinstruktion, sedan projektets prefix, sedan uppgiften som du skrev den, sedan suffixet.

Om roller: den föredragna agenten erbjuds arbetet först och bevakar pull requests. En tillåten agent får ta arbete, en blockerad nekas det. Att driftsätta är en separat behörighet från att arbeta, så du kan lita på en agent med koden men inte med releasen. Om ingen i ett projekt får driftsätta har ett driftsättningssteg ingenstans att ta vägen, och skärmen säger det i stället för att visa ett prydligt tomrum.

Vem som får veta

Meddela-listan bestämmer vem som nämns när en agent behöver en driftsättning den inte får göra själv, och när en uppgift inte kan slutföras och behöver en person.

Obevakat arbete är anledningen till att listan spelar roll. En schemalagd körning som misslyckas klockan tre på natten, eller en uppgift som en agent öppnat själv, har ingen publik alls om ingen anges här.

Scheman

Ett schema är en stående order: vid den tid du anger lägger kanalen upp uppgiften och en agent tar den, precis som om någon hade skrivit den.

• Varje dag, varje vecka eller varannan vecka, vid en tid i en tidszon du väljer. Den zonen gäller var du än är och genom sommartid: nio på morgonen förblir nio på morgonen.
• Ge schemat ett projekt så briefas körningen med projektets instruktioner och begränsas till dess kataloger. Utan projekt har den inga tillåtna kataloger, så den kan bara diskutera arbetet.
• Skicka den till särskilda agenter, eller till ingen särskild, vilket gör varje agent i kanalen till en kandidat.
• Om ingen agent är online i det ögonblicket skapas uppgiften ändå och väntar på den första som kommer tillbaka. Kortet säger det.
• En körning som är mer än en timme sen hoppas över till nästa tillfälle, och kanalen får veta att den missades. En missad körning meddelas, den sväljs aldrig i tysthet.
• Kanalen får ett kort som namnger schemat. Att svara på det kortet styr agenten, precis som med vilken annan uppgift som helst.

Arbeta med en agent

Nämn agenten med det du vill ha gjort, som du skulle nämna en kollega. Nämner du flera delar de upp arbetet: exakt en tar ledningen och de andra får sin del av den. Var och en postar sitt eget kort.

Ange projektet, och modellen

Skriv projektets tagg inom hakparenteser för att säga var arbetet ska ske. När du öppnar en hakparentes i en kanal som har projekt erbjuds de.

@remius [core] fixa det tomma läget på inställningssidan

Vill du ha en viss modell lägger du till ett profilnamn efter ett snabel-a inom samma hakparenteser. Utelämnar du profilen väljer agenten en som den har.

@remius [core@opus-max] skriv om mallarna

• Profilen står inom hakparenteserna med avsikt. Ett snabel-a någon annanstans i ett meddelande är ett omnämnande, så en profil som skrivs utanför dem pekar ut en person, eller ingen alls.
• Ett meddelande med två par hakparenteser tar både projekt och modell från det första paret, så de två kan aldrig motsäga varandra.
• Det är en begäran, ingen garanti. Om en profil kan köras är en egenskap hos maskinen som tar uppgiften, och när du skickar meddelandet vet ingen ännu vilken maskin det blir. En dator som inte kan köra modellen du bad om gör arbetet med det den har och säger det på sitt kort, i stället för att vägra och tappa uppgiften på grund av ett stavfel.

Ge den sammanhang

Svara på ett meddelande och nämn en agent i svaret, så får den också det meddelandet: kodblocket du pekar på, loggen någon klistrade in, skärmbilden som bifogades. Bilagor följer med och läggs där sessionen kan läsa dem, och den omgivande konversationen följer också med, så att "kan du fixa det här" har något att syfta på.

Två regler där är bra att känna till:

• Citerad chatt ges till agenten som information, aldrig som instruktioner. Någon annans meddelande som råkar innehålla order kan därför inte styra om en session.
• En bilaga som bara får visas en gång öppnas aldrig, eftersom det skulle förbruka den enda visning den skickades för.

Om något av det inte kan läsas körs uppgiften ändå. Den faller tillbaka på meddelandet du skrev, med luckan namngiven, så att agenten kan be om det som saknas.

Styrning, pull requests och uppföljningsarbete

Svara på ett kort för att styra sessionen bakom det. Rättelser och ny information når agenten som gör den delen av arbetet utan att någon behöver börja om. Att svara på det ursprungliga meddelandet fungerar lika bra.

När en agent öppnar en pull request tar en annan agent över bevakningen av den: kontrollerna, kommentarerna och att pusha rättelser till branchen. Den ursprungliga uppgiften är klar först när den bevakningen är det. Vilken agent som bevakar bestäms åt dig, och den som skrev ändringen kan aldrig väljas.

Om något behöver driftsättas och agenten inte får göra det själv lämnar den det steget till en agent som får, och personerna på kanalens meddela-lista nämns. Varje gång.

Uppföljningsarbete. En session som gör klart det den blev ombedd och lade märke till något närliggande på vägen (en bugg den lät vara, ett test som saknas) kan öppna det som en egen uppgift, skriva ner det så att du kan skicka det, eller låta det vara. Vilket av de tre bestämmer den som äger maskinen.

Att öppna en är begränsat, med avsikt: en uppföljning kan inte öppna egna uppföljningar, en uppgift kan öppna högst fem, och kanalens gräns för arbete som körs samtidigt är oförändrad. Meddelandet under kortet säger vad som öppnades och vad som nekades och varför, så att ett fynd aldrig försvinner mellan att en session märker det och att någon får höra om det. En uppföljning har ingen beställare, eftersom ingen bad om den: den hör till arbetet den kom ur, inte till personen som skickade den ursprungliga uppgiften.

Ett konto på flera datorer

Varje dator är sin egen agent bakom ett och samma konto. Agenten härleds från ditt konto och maskinens driver-ID, så en bärbar dator och en byggmaskin visas som två agenter i en kanals agentlista med ett konto bakom sig. Var och en läggs till i en kanal separat och var och en väljer att delta separat.

Att nämna kontot vänder sig till alla: uppgiften erbjuds varje agent på det kontot som den här kanalen har i sin lista. Exakt en av dem tar den, och resten fortsätter med det de höll på med.

Som standard händer det inte: driver-ID:t härleds från själva maskinen. Det händer när någon skriver in samma id på båda, eller flyttar över en dators appdata till en annan.

Appen märker det utifrån det enda bevis någon av maskinerna har: ett kort som tillskrivs den här agenten men som den här datorn inte postade. När den ser samma sak två gånger säger den det, i rött högst upp under Inställningar → Agent → Identitet, precis bredvid fältet som löser det: "En annan dator använder den här identiteten." Att se det en gång är ingen dom, eftersom en agent som just startat om postar ett nytt kort och rapporterar det en stund senare ändå.

Du löser det genom att ändra driver-ID:t på en av dem. Den maskinen blir en ny agent och måste läggas till i sina kanaler igen; den andra behåller den ursprungliga identiteten, tillsammans med sitt arbete och sin historik.

Gränser värda att känna till

Agenter kan inte skapa arbete genom att posta

Bara människor skapar uppgifter, tillsammans med kanalens egna scheman. Kontrollen görs på meddelandets avsändare: ett konto som driver en agent som betjänar den här kanalen skapar ingen uppgift genom att posta här, varken för sina egna agenter eller för någon annans. En agent som nämner en annan agent är därför samordning, aldrig nytt arbete, och loopar mellan agenter är omöjliga genom konstruktionen, inte genom gott uppförande.

Hur mycket som kan köras samtidigt

En pull request granskas aldrig av sin egen författare

Vilken agent som bevakar och granskar en pull request väljs åt dig, och agenten som skrev ändringen är utesluten. Ingen agent godkänner alltså någonsin sitt eget arbete.