Aina päällä oleva tekoälyagentti on agentti, joka voi pysyä vastuussa työstä silloinkin, kun yhtään keskustelua ei ole auki. Se voi säilyttää tehtävän tilan, odottaa ajan kulumista tai ulkomaailman muutosta, jatkaa sopivassa ympäristössä ja palauttaa ohjat, kun seuraava päätös kuuluu ihmiselle.
”Aina päällä” ei tarkoita, että suuri kielimalli ajattelisi taukoamatta. Se ei tarkoita, että tietokoneen pitäisi kuluttaa resursseja täydellä teholla vuorokauden ympäri. Eikä sen pitäisi tarkoittaa, että agentti lähettää jatkuvasti viestejä tai toimii ilman lupaa. Hyödyllinen lupaus on jatkuvuus: vastuu pysyy elossa, vaikka suurin osa järjestelmästä nukkuu.
Kehotteen ajastaminen tai chat-historian säilyttäminen ei vastaa käytännön kysymyksiin: mikä säilyy uudelleenkäynnistyksen yli, mikä herättää agentin, missä se jatkaa työtä ja miten käyttäjä voi pysäyttää sen? Vastaukset näihin kysymyksiin tekevät ”24/7”:stä järjestelmän ominaisuuden eikä iskulausetta.
Aina päällä tarkoittaa jatkuvuutta, ei käyttöaikaa
Käyttöaika kertoo, onko prosessi käynnissä. Jatkuvuus kertoo, onko työllä yhä vastuunkantaja ja kelvollinen seuraava askel.
Kuvittele pyytäväsi agenttia seuraamaan allekirjoitetun sopimuksen palautumista, päivittämään julkaisun tarkistuslistan, kun sopimus saapuu, ja valmistelemaan sinulle seuraavan päätöksen. Sopimus voi palata huomenna tai ensi viikolla. Odotuksen aikana hyödyllistä päättelyä ei tapahdu. Agentti ei tarvitse avointa chattia, lämpimänä pidettävää mallin istuntoa tai selainta, joka päivittää saapuneet-kansion joka minuutti. Se tarvitsee pysyvän merkinnän vastuusta ja luotettavan tavan, jolla olennainen tapahtuma saa vastuun taas liikkeelle.
Ero näkyy selvästi vikatilanteessa. Prosessi voi olla jatkuvasti käynnissä ja silti kadottaa tehtävän kaatumisen jälkeen. Toinen järjestelmä voi skaalautua nollaan tunneiksi, koota sitten tilansa uudelleen ja jatkaa oikein, kun tapahtuma saapuu. Jälkimmäinen on merkityksellisemmässä mielessä aina päällä.
Siksi pysyvien agenttien infrastruktuuri erottaa odottamisen laskennasta. Microsoftin nykyinen Agent Frameworkin Durable Extension kuvaa esimerkiksi agentteja, jotka säilyttävät tilansa workerien suorituskertojen välillä, pysähtyvät kuluttamatta laskentaa tai mallin tokeneita ja jatkavat ulkoisista tapahtumista. Googlen opas pitkäkestoisista agenteista, jotka jatkavat tapahtumien ohjaamina, näyttää saman periaatteen pysyvillä checkpointeilla ja webhookeilla. Toteutuksen yksityiskohdat vaihtelevat, mutta arkkitehtuurin opetus pysyy: aina päällä oleva vastuu ei vaadi aina käynnissä olevaa mallia.
Kuusi ehtoa uskottavan aina päällä olevan agentin takana
Mikään yksittäinen ominaisuus ei tee agentista aina päällä olevaa. Ominaisuus syntyy, kun kuusi ehtoa toimii yhdessä.
Jatkuva identiteetti kantaa vastuun
Järjestelmä tarvitsee vakaan identiteetin, johon viestit, tapahtumat, oikeudet, tehtävät ja käyttäjän odotukset voidaan liittää. Jos jokainen keskustelu luo erillisen agentin ilman yhteistä toimintakontekstia, myöhemmillä tapahtumilla ei ole ketään herätettävänä eikä kukaan vastaa työn jatkamisesta.
Jatkuva identiteetti ei vaadi rajatonta muistia. Se tarkoittaa, että käyttäjä voi palata saman agentin luo ja että järjestelmä tietää, mitkä vastuut sille kuuluvat. Henkilökohtaisilla tiedoilla, keskusteluhistorialla ja tehtävän tilalla voi yhä olla eri elinkaaret ja hallintakeinot.
Työtila selviää joutoajan yli
Tehtävän pitää säilyttää enemmän kuin aloituskehotteensa. Jatkamiseen tarvittava tila voi sisältää tavoitellun lopputuloksen, valmiit toimet, työn alla olevat tuotokset, rajoitteet, nykyisen esteen ja kelvollisen seuraavan askeleen.
Tilan pitäisi olla niin pysyvä, että se kestää tavalliset keskeytykset: suljetun selaimen, lepotilassa olevan tietokoneen, käyttöön otetun päivityksen, workerin uudelleenkäynnistyksen tai usean päivän kulumisen. Keskusteluloki voi auttaa kokoamaan uudelleen, mitä tapahtui, mutta uudelleen kokoaminen ei ole sama kuin palautuminen. Uskottava järjestelmä tietää, mikä tila on määräävä, sen sijaan, että se pyytäisi mallia päättelemään totuuden pitkästä keskustelusta aina herätessään.
Syvempi mekanismi, jolla yksi tehtävä kannetaan riippuvuuksien yli, on eri kysymys kuin tämän luokan määritelmä. Tällä tasolla koe on yksinkertaisempi: pystyykö järjestelmä säilyttämään tarpeeksi kelvollista tilaa jatkaakseen ilman uutta perehdytystä?
Aika ja tapahtumat voivat palata järjestelmään
Ulkomaailman työ ei etene vain silloin, kun käyttäjä lähettää viestin. Määräajat koittavat. Tiedostot muuttuvat. Vastauksia saapuu. Laite palaa verkkoon. Hyväksyntä kirjataan toiseen sovellukseen.
Aina päällä oleva agentti tarvitsee siksi enemmän kuin vuorovaikutteisen syöttökentän. Se tarvitsee reitin, jota pitkin ajastin tai ulkoinen tapahtuma saavuttaa vastuun, johon se vaikuttaa. Reitti voi olla webhook, viestijono, aikataulu, liitin tai kapeasti rajattu valvontaprosessi. Tärkeää on, että tapahtuma voidaan liittää oikeaan agenttiin ja oikeaan tilaan.
Tämä ei tarkoita, että jokainen tapahtuma ansaitsisi täyden päättelykierroksen. Tapahtumien ohjaama toiminta on arvokasta juuri siksi, että suurin osa järjestelmästä voi pysyä hiljaa, kunnes on arvioitavaa työtä. Sen ratkaiseminen, pitäisikö tietyn tapahtuman herättää pääagentti, ja pitäisikö herätyksen keskeyttää ihminen, on erillinen toimintaperiaatteiden kysymys, eri asia kuin itse aina päällä olevan järjestelmän määrittely.
Suoritusympäristö on saatavilla, kun työ jatkuu
Seuraavan askeleen muistaminen ei riitä, jos agentilla ei ole paikkaa, jossa sen voisi tehdä. Osa työstä onnistuu API:n kautta. Muu työ vaatii selaimen, pilvitietokoneen, paikallisen koneen tai erikoistuneen agenttiajoympäristön. Ympäristön täytyy olla saatavilla, kun vastuu taas aktivoituu, ja siinä on oltava seuraavan askeleen vaatimat tiedostot, työkalut ja oikeudet.
”Saatavilla” ei tarkoita jatkuvasti käynnissä. Pilvitietokone voi nukkua tallennustilansa säilyttäen ja herätä tarvittaessa. Paikallinen kone voi olla irti verkosta, kunnes jokin tehtävä tarvitsee sitä. Tärkeää on, että agentti tunnistaa tarvittavan ympäristön ja käsittelee sen puuttumisen rehellisesti.
Ympäristön rajat ovat myös osa oikeellisuutta. Comman laitedokumentaatiossa sanotaan, ettei Salix siirrä työtä hiljaa offline-tilassa olevalta laitteelta toiselle tietokoneelle. Pyyntö voi epäonnistua ja sitä voidaan yrittää uudelleen, kun laite palaa. Se on vähemmän taianomaista kuin teeskennellä kaikkien tietokoneiden olevan keskenään vaihdettavissa, mutta se säilyttää paikan, pääsyn ja suoritusehdot, joista työ riippuu.
Palautuminen on osa tavallista toimintaa
Aina päällä oleva järjestelmä kohtaa ennen pitkää uudelleenkäynnistyksen, kahdentuneen tapahtuman, saavuttamattoman palvelun, vanhentuneet tunnukset tai katkenneen yhteyden. Luotettavuus ei siksi voi riippua siitä, että yksi prosessi pysyisi virheettömänä ikuisesti.
Järjestelmä tarvitsee palautumisreitin: pysyvän tilan, checkpointit tai vastaavan totuuden lähteen; ylärajalla rajatut uudelleenyritykset; keinon välttää ulkoisen toimen toistaminen; ja näkyvän virhetilan, kun automaattinen palautuminen ei ole enää turvallista. Uudelleenkäynnistys, joka hiljaa unohtaa jo vahvistetun, ei ole palautumista. Ei myöskään loputon uudelleenyritysten silmukka, joka kuluttaa resursseja muuttamatta lopputulosta.
Comman Loop-dokumentaatio antaa konkreettisen esimerkin. Loop voi tallentaa checkpointin ja saada sen takaisin käynnistyessään uudelleen. Vian jälkeen Salix käynnistää sen uudelleen tuosta checkpointista rajatun uudelleenyrityskäytännön puitteissa; toistuvat epäonnistumiset pysäyttävät Loopin ja ilmoittavat agentille. Koko toteutus pysyvine tapahtumineen, kaksoiskappaleiden poistoineen, sijoitteluineen ja kykyjen rajoineen selitetään artikkelissa Ohjelmoitavat tapahtumasilmukat hajautetulle agenttikehyksellemme. Tuotetta arvioidessa kannattaa tarkistaa, ovatko keskeytys ja palautuminen suunniteltuja tiloja eivätkä yllätyksiä.
Käyttäjä voi nähdä ja rajata jatkuvuuden
Jatkuvuus tekee hallinnasta tärkeämpää. Kertaluonteinen chat päättyy itsestään. Taustalla olevalle vastuulle tarvitaan ymmärrettävä laajuus, näkyvä tila ja virtakytkin, joka oikeasti toimii.
Käyttäjien pitäisi nähdä, mistä agentti vastaa, mitä lähteitä se seuraa, mitä ympäristöä se saa käyttää ja millaiset valtuudet sillä siellä on. Heidän pitäisi voida keskeyttää tai lopettaa vastuu, perua pääsy ja ottaa talteen jo tuotettu työ. Järjestelmän pitäisi tuoda esiin virheet ja seuraukselliset päätökset sen sijaan, että se pitäisi hiljaisuutta todisteena siitä, että kaikki on hyvin.
Siksi aina päällä ja autonominen eivät myöskään ole synonyymejä. Jatkuvuus kertoo, että järjestelmä voi pysyä saatavilla. Autonomia kuvaa, mitä päätöksiä tai toimia se saa tehdä kysymättä. Agentti voi olla hyvin pitkäjänteinen ja tarkoituksella varovainen: se voi valmistella, tarkistaa, järjestellä ja odottaa ja palauttaa samalla ulkoiset sitoumukset tai peruuttamattomat valinnat käyttäjälle.
Neljä toimintatilaa, ei yhtä loputonta ajoa
Ilmaus ”aina päällä” antaa ymmärtää yhden yhtäjaksoisen toiminnan. Käytännössä hyödyllinen agentti liikkuu eri tilojen välillä.
Se voi olla työssä, jolloin malli ja työkalut vievät tehtävää aktiivisesti eteenpäin. Se voi odottaa, koska jokin hetki, tapahtuma, ympäristö tai ihmisen päätös ei ole vielä saapunut. Kevyt vahti voi valvoa kapeaa ehtoa herättämättä pääagenttia. Tai vastuu voi olla pysäytetty, koska käyttäjä lopetti sen tai vika ylitti turvallisen palautumiskäytännön.
Nämä tilat ovat yhtä tärkeitä kustannusten ja huomion kuin luotettavuuden kannalta. Mallin päättely, pilvilaskenta, tapahtumien vastaanotto, tallennus ja kolmansien osapuolten API:t voidaan laskuttaa eri tavoin. Tuotteen ei pitäisi niputtaa niitä varauksettomaksi väitteeksi, että ”agentti toimii 24/7”. Hiljainen taustavastuu voi käyttää tallennus- ja valvontaresursseja käyttämättä yhtään suuren mallin tokenia; aktiivinen tehtävä voi kuluttaa sekä malli- että laskentaresursseja; pysäytetyn vastuun ei pitäisi kuluttaa kumpaakaan säilytetyn tilan lisäksi.
Comma heijastaa tätä erottelua omassa ajoympäristössään. Salix ajaa agenttia jatkuvasti lämpimänä pidettävän hiekkalaatikon ulkopuolella. Kun tarvitaan työtä tietokoneella, se voi herättää pilvessä olevan virtuaalikoneen, jonka tallennustila säilyy käyttökertojen välillä. Jatkuvaa huomiota varten pienet Loopit voivat seurata tapahtumia pitämättä agentin pääsilmukkaa aktiivisena. Pääsilmukka käynnistyy vasta, kun Loop toteaa agentin tarpeelliseksi.
Arkkitehtuuri on Comman toteutus, ei yleispätevä määritelmä. Toinen tuote voi käyttää pysyviä työnkulkuja, jonoja, serverless-funktioita tai pitkäkestoisia workereita. Koe on se, säilyttääkö koko järjestelmä vastuun joutoaikojen yli, ei se, käyttääkö se tiettyä ajoympäristöä.
Aina päällä, ajastettu ja pitkäkestoinen ovat eri lupauksia
Ajastettu automaatio suorittaa ohjeen tunnettuna hetkenä. Se voi olla erittäin hyödyllinen ylläpitämättä jatkuvaa agentti-identiteettiä tai reagoimatta suunnittelemattomiin muutoksiin. Jos päivittäinen ajo tuottaa raportin kiinteistä syötteistä, aikataulu voi olla kaikki, mitä järjestelmä tarvitsee.
Pitkäkestoinen työnkulku voi säilyttää tilansa usean vaiheen yli ja odottaa signaalia. Siitä tulee agenttimainen, kun mallit osallistuvat tiedon tulkintaan, työkalujen valintaan tai suunnitelman mukauttamiseen. Siitä tulee merkityksellisessä mielessä aina päällä oleva, kun tuo pysyvä työnkulku kuuluu jatkuvalle agentille, joka voi vastaanottaa uusia olennaisia tapahtumia ja toimia käyttäjän määräämissä rajoissa.
Myös chatbot voi muistaa aiemmat keskustelut ja tarjota muistutuksia. Nämä ominaisuudet parantavat käyttäjän kokemaa jatkuvuutta, mutta ne eivät yksinään todista, että työ jatkuu chatin ulkopuolella. Ratkaiseva kysymys ei ole, muistaako järjestelmä sinusta jotain. Se on, voiko aktiivinen vastuu odottaa, jatkaa, toipua ja saavuttaa valtuutetun ympäristön ilman, että se luodaan käsin uudelleen.
Ero estää myös rakentamasta liikaa. Kaikki pyynnöt eivät tarvitse aina päällä olevaa agenttia. Kertaluonteinen selitys, uudelleenkirjoitus, laskelma tai ideointi hoituu usein paremmin vuorovaikutteisella mallilla. Aina päällä oleva toiminta on monimutkaisuutensa arvoista, kun lopputulos riippuu ajasta, ulkoisista muutoksista, useista työympäristöistä tai vastuusta, joka jää auki nykyisen keskustelun päätyttyä.
Käytännöllinen jatkuvuuskoe
Arvioidaksesi ”aina päällä” olevaa tuotetta anna sille yksi realistinen vastuu, jossa on odotusvaihe. Pyydä sitä valvomaan määriteltyä ehtoa, valmistelemaan seuraava askel ja pysähtymään ennen seurauksellista toimea.
Tutki sitten, mitä tuote pystyy näyttämään. Mihin tehtävä tallentuu, kun suljet käyttöliittymän? Mikä ehto tarkalleen saa sen taas liikkeelle? Tietääkö se, missä ympäristössä työaineisto on? Pystyykö se jatkamaan uudelleenkäynnistyksen jälkeen toistamatta valmiita toimia? Mitä tapahtuu, jos tapahtuma tulee kahdesti tai tarvittava laite on offline? Voitko keskeyttää valvonnan, perua pääsyn tai lopettaa tehtävän poistamatta koko historiaasi?
Katso lopuksi, mitä sinulle asti tulee. Järjestelmä, joka välittää jokaisen tapahtuman, on rakentanut ilmoitusputken, ei välttämättä agenttia. Järjestelmä, joka toimii jokaisen tapahtuman kohdalla, on sekoittanut saatavuuden ja valtuudet. Hyödyllinen aina päällä oleva agentti yhdistää muutoksen olemassa olevaan vastuuseen, tekee jo sallitun työn ja pyytää huomiota vain, kun huomio muuttaa lopputulosta.
Miten Comma pysyy saatavilla metelöimättä
Comma on maksuton, avoimen lähdekoodin henkilökohtainen agentti, joka on suunniteltu yhden keskusteluista ja laitteista toiseen jatkuvan agentin ympärille. Nopeat kysymykset voivat jäädä chattiin, kun taas isommista vastuista tulee Taskeja. Comma voi työskennellä yhdistetyissä sovelluksissa ja tiedostoissa, liitetyllä Macilla tai Linux-laitteella tai pilvitietokoneella, joka herää tarvittaessa.
Sen aina päällä oleva kerros on Salix. Comma-agentti voi luoda Loopin seuraamaan rajattua lähdettä, kuten saapuneet-kansiota, repositoriota, syötettä, API:a tai webhookia. Loop toimii erillään päättelyn pääsilmukasta, voi ylläpitää pientä checkpointia ja voi ilmoittaa agentille, kun työ sitä vaatii. Koska pääagentin ei tarvitse tarkastella jokaista hiljaista jaksoa, ”aina saatavilla” ei muutu muotoon ”kuluttaa aina mallin tokeneita”. Loop voi silti kutsua nopeaa päätösmallia tai muuta palvelua, joten taustatyö ei ole automaattisesti ilmaista; kustannukset riippuvat siitä, mitä Loop oikeasti tekee.
Sama jatkuvuus pysyy käyttäjän hallinnassa. Liitetyt tietokoneet aloittavat vain luku -tilassa, kunnes käyttäjä sallii toiminnot, ja laitepääsyn voi perua. Loopeilla on kykyjen ja herätysten rajat. Isompi Task voi palata tilaan Needs Review, kun päätös kuuluu ihmiselle. Comman voi myös ajaa omalla palvelimella, mutta silloin ylläpitäjä vastaa saatavuudesta, päivityksistä, varmuuskopioista, mallin asetuksista ja muusta infrastruktuurista, jota asennuksen pitäminen käynnissä vaatii.
Comman lähestymistapa on yksi vastaus tämän luokan keskeiseen ongelmaan: anna vastuun säilyä ja anna kalliin laskennan, mallien ja käyttäjän huomion levätä, kunnes niitä todella tarvitaan.
Usein kysytyt kysymykset
Ajaako aina päällä oleva tekoälyagentti mallia 24/7?
Ei. Hyvin suunniteltu järjestelmä voi säilyttää tilansa ja kuunnella ajastimia tai tapahtumia, kun päämalli on toimettomana. Malli käynnistyy, kun järjestelmä tarvitsee päättelyä tai tuottamista. Kevyt valvonta, tallennus ja ulkoiset palvelut voivat silti kuluttaa resursseja agentin odottaessa.
Onko aina päällä oleva agentti sama asia kuin autonominen agentti?
Ei. Aina päällä kuvaa jatkuvuutta ja saatavuutta ajan yli. Autonomia kuvaa, mitä agentti saa päättää tai tehdä ilman ihmisen hyväksyntää. Aina päällä oleva agentti voi toimia kapein valtuuksin ja palauttaa seurauksellisia päätöksiä käyttäjälle.
Onko ajastettu tekoälytehtävä aina päällä oleva agentti?
Ei välttämättä. Aikataulu voi käynnistää tilattoman kehotteen tiettyyn aikaan. Aina päällä oleva agentti säilyttää lisäksi vastuun ja olennaisen tilan, voi reagoida sopiviin ulkoisiin tapahtumiin, toipuu keskeytyksistä ja jatkaa pysyvien käyttäjän hallintakeinojen rajoissa.
Pitääkö agentin tietokoneen olla päällä?
Se riippuu tarvittavasta ympäristöstä. Pilvessä tai palvelimella tehtävä työ voi jatkua, vaikka henkilökohtainen kannettava on kiinni. Työ, joka riippuu vain tietyllä paikallisella laitteella olevista tiedostoista tai sovelluksista, joutuu odottamaan sitä laitetta. Jotkin pilviympäristöt voivat nukkua toimien välillä tallennustilansa säilyttäen.
Mitä tapahtuu, kun aina päällä oleva agentti epäonnistuu?
Järjestelmän pitäisi palautua tunnetusta checkpointista tai pysyvästä tilasta, välttää jo tehtyjen ulkoisten toimien toistamista ja käyttää rajattuja uudelleenyrityksiä. Jos se ei voi palautua turvallisesti, sen pitäisi pysähtyä näkyvästi ja kertoa agentille tai käyttäjälle, mikä epäonnistui, sen sijaan että se yrittäisi loputtomasti uudelleen tai hylkäisi vastuun hiljaa.
Voinko sammuttaa aina päällä olevan agentin?
Taustavastuun pitäisi voida keskeyttää tai lopettaa ja sen käyttämän pääsyn pitäisi voida perua. ”Aina päällä” tarkoittaa saatavilla silloin, kun se on valtuutettu, ei mahdotonta pysäyttää. Commassa Loopit voi keskeyttää tai poistaa, ja yhdistettyjen laitteiden pääsyn voi perua.
Agentti voi nukkua; vastuu ei voi kadota
Aina päällä olevaa tekoälyagenttia ei määritä jatkuva mallin toiminta. Sen määrittää katkeamaton vastuun ketju: vakaa vastuunkantaja, pysyvä tila, reitti, jolla aika ja tapahtumat merkitsevät jotain, saatavilla oleva suoritusympäristö, palautettava toiminta ja hallintakeinot, jotka pysyvät käyttäjällä.
Kun nämä osat ovat olemassa, suurin osa järjestelmästä voi olla hiljaa suurimman osan ajasta. Malli voi pysähtyä. Pilvitietokone voi nukkua. Käyttäjä voi sulkea sovelluksen. Työ jatkuu, koska vastuu on yhä tallella, ei siksi, että joku muisti kirjoittaa ”jatka”.
