Kallis tuotantotekoälyn virhe näyttää usein tältä: on tiistaiyö kello 3 AM, ja asiakaspalveluagentti jää loputtomaan silmukkaan. Se kutsuu samaa työkalua, saa saman virheen, yrittää hieman eri parametrilla, saa saman virheen ja toistaa. Satoja kertoja minuutissa. Aamulla tiimiä odottaa mallista ja kutsutiheydestä riippuen yllättävä neli- tai viisinumeroinen lasku.
Tämä ei ole harvinaista. Silmukoihin jäävät agentit ovat yleisimpiä ja vakavimpia tuotantovirheitä. Ne ovat salakavalia, koska agentti näyttää usein toimivan: se tekee toimintoja ja kutsut onnistuvat tai epäonnistuvat ennakoitavasti. Vasta jäljestä näkee saman mallin toistuvan.
Ikuiset silmukat estävien agenttien rakentaminen vaatii tietoisia arkkitehtuurivalintoja. Useimmat agenttivirheet ovat ennakoitavia, ja niiden torjuntamallit tunnetaan. Luotettavia agentteja julkaisevat tiimit toteuttavat nämä mallit kurinalaisesti.
Tässä artikkelissa käsitellään silmukoiden syyt, ne estävät arkkitehtuurimallit sekä silmukan läpi päästessä sen havaitsevat operatiiviset suojamekanismit.
Miksi agentit jäävät silmukkaan
Silmukoiden taustalla on useita mekanismeja:
1. Epäselvyys edistymisestä
Agentilla ei ole selvää käsitystä siitä, onko se edistynyt. Se kokeilee jotain, tarkastelee tulosta ja päättää kokeilla muuta. Ilman eksplisiittistä seurantaa ”kokeile muuta” voi tarkoittaa samaa asiaa hieman eri tavalla.
2. Lopetusehtojen puute
Agentin kehote käskee auttamaan käyttäjää mutta ei lopettamaan, kun X toteutuu. Ilman selvää lopetusta agentti jatkaa auttamista: etsii vielä yhden tiedon, kokeilee vielä yhtä työkalua ja tarkentaa lisää.
3. Uudelleenyritysten häiriö
Virheen jälkeen agentti yrittää luontevasti uudelleen. Ilman uudelleenyritysbudjettia samaa virhettä voidaan yrittää loputtomasti. Agentti tulkitsee tilanteen muodossa ”en ole vielä onnistunut”, ei ”olen jo kokeillut tätä 10 kertaa”.
4. Tilan unohtaminen
Agentin työmuisti sisältää vain viimeisimmät vuorot. Jos silmukassa on ollut 20 yritystä, agentti voi nähdä kontekstissa vain viimeiset 5 eikä ulkopuoliselle jo selvää mallia.
5. Työkalun epäjohdonmukaisuus
Työkalu palauttaa epäselviä tai ristiriitaisia tuloksia. Agentti yrittää uudelleen, saa edelleen epäselvän tuloksen, epäilee aiempaa tulkintaansa ja kokeilee toisin. Tulos pysyy epäselvänä. Silmukka jatkuu.
6. Liiallinen optimismi
Agentin koulutus tekee siitä sinnikkään. Se jatkaa yrittämistä tilanteessa, jossa pitäisi pysähtyä ja pyytää apua. Ongelma korostuu pitkissä tehtävissä, joissa pienet epäselvyydet kertautuvat.
7. Tavoitteen ajautuminen
Agentti kadottaa vähitellen alkuperäisen tavoitteensa. Se haarautuu alitehtäviin ja niiden alitehtäviin sekä tutkii sivuavia aiheita palaamatta päätavoitteeseen.
Eri agentit epäonnistuvat eri tavoin. Puolustuskeinot ovat osittain samoja.
Malli 1: tiukat vaihebudjetit
Yksinkertaisin ja tärkein suoja on vaiheiden enimmäismäärä. Agentilla on esimerkiksi 20 työkalukutsua. Vaiheita on 20, ja sen jälkeen agentin on tuotettava lopullinen vastaus tai eskaloitava.
Toteutus:
def agent_loop(query, max_steps=20):
messages = [{"role": "user", "content": query}]
for step in range(max_steps):
response = call_llm(messages, tools=available_tools)
if response.is_final_answer:
return response.content
result = execute_tool(response.tool_call)
messages.append(response)
messages.append({"role": "tool", "content": result})
# Hit budget — force final answer
return force_final_answer(messages)
Budjetti sovitetaan tehtävään. Yksinkertaiset tehtävät: 5-10 vaihetta. Monimutkaiset usean lähteen tehtävät: 20-30. Avoin tutkimus: 50+. Raja on kuitenkin aina olemassa.
Budjetin täyttyessä agentti tuottaa parhaan mahdollisen vastauksen nykyisillä tiedoilla tai eskaloi ihmiselle.
Tämä yksittäinen malli estää useimmat tuhoisat silmukat. Toteuta se aina.
Muunnelmat
Tokenbudjetti. Rajoita vaiheiden lisäksi tai sijasta tokenien kokonaismäärää. Tämä estää agenttia käyttämästä harvoja mutta 50K tokenin päättelyvaiheita.
Kustannusbudjetti. Muunna vaihe- tai tokenbudjetti euroiksi. Näin budjetin ylitys ei jää abstraktiksi.
Aikabudjetti. Seinäaikaraja sopii käyttäjäpolkuihin, kuten ”vastaa 30 sekunnissa”.
Useimmilla tuotantoagenteilla on kaikki neljä budjettia jossain muodossa. Minkä tahansa täyttyminen lopettaa ajon.
Malli 2: edistymisen seuranta
Pelkkä budjetti ei kerro agentille, että se on jumissa. Se vain pysäyttää agentin lopulta. Edistymisen seuranta auttaa agenttia tunnistamaan silmukan ja poistumaan siitä.
Yksinkertaisessa toteutuksessa agentti ylläpitää eksplisiittistä edistymislokia. Jokaisessa vaiheessa se kirjaa saamansa uuden tiedon tai tapahtuneen muutoksen.
Step 1: Searched for customer "Smith". Found 12 matches.
Step 2: Filtered to active accounts. 4 remain.
Step 3: Checked recent activity. Customer 234 had a recent ticket about pricing.
Step 4: Pulled the ticket details. The complaint was about a recent price change.
Step 5: Drafted response. Ready to send.
Jokainen vaihe lisää uutta tietoa. Jos agentti tekee vaiheen 6 eikä edistymisloki muutu — sama haku, samat tulokset ja sama johtopäätös — se polkee paikallaan.
Kehotteeseen voidaan lisätä:
Before deciding the next action, summarize what you've learned in the last few steps. If you haven't gained new information in the last 3 steps, stop and either:
- Produce your best answer with current information.
- Escalate the issue: explain what you've tried and what's missing.
Näin edistymisen puute tulee agentille näkyväksi, jotta se voi reagoida.
Malli 3: toiston tunnistus
Joskus agentti toistaa täsmälleen saman työkalukutsun. Tämä on helppo havaita ohjelmallisesti.
def detect_repeat(history):
recent_calls = [c for c in history[-5:] if c.is_tool_call]
if len(recent_calls) < 3:
return False
call_signatures = [(c.tool, json.dumps(c.args, sort_keys=True)) for c in recent_calls]
return len(set(call_signatures)) < len(call_signatures) / 2
Kun toisto havaitaan, puutu siihen:
- Lisää viesti: ”Olet kutsunut tätä työkalua näillä parametreilla äskettäin. Tulokset eivät ole muuttuneet. Kokeile toista lähestymistapaa tai lopeta.”
- Tai pakota lopetus.
Tämä tunnistaa ilmeisimmät silmukat automaattisesti.
Malli 4: jumittumisen tunnistus
Täsmällisen toiston lisäksi voit tunnistaa hienovaraisempia jumitiloja:
Mallintunnistus. Arvioi erillisellä LLM-kutsulla: ”Edistyykö tämä agentti viimeisten 5 vaiheen perusteella?” Jos ei, katkaise ajo.
def is_stuck(history):
recent = format_history(history[-5:])
response = call_llm(
system="You are evaluating whether an agent is making progress.",
user=f"Recent agent steps:\n{recent}\n\nIs the agent making meaningful progress or stuck in a loop? Answer: progressing | stuck."
)
return response.content.strip() == "stuck"
Aja tarkistus muutaman vaiheen välein. Jos tulos on ”stuck”, puutu ajoon.
Työkalujen monipuolisuus. Jos agentti on kutsunut vain 1 työkalua 5+ vaiheessa, tilanne on epäilyttävä. Pakota se kokeilemaan muuta tai lopettamaan.
Virhemallit. Jos sama työkalu on palauttanut saman virheen 3+ kertaa, lopeta sen käyttö. Uudet yritykset eivät auta agenttia selvittämään puuttuvaa syötettä.
Malli 5: reflektointipisteet
Pakota agentti reflektoimaan eksplisiittisesti tietyissä ajon kohdissa.
After every 5 steps, the agent must produce a reflection:
1. What was my original goal?
2. What have I learned so far?
3. What do I still need to know?
4. Am I making progress, or repeating?
5. Should I continue or stop?
Reflektointi pakottaa agentin irtautumaan seuraavan välittömän toiminnon pohdinnasta ja arvioimaan kokonaisuutta.
Tämä on erityisen tehokasta pitkissä tehtävissä. Ilman pakotettua reflektointia agentit ajautuvat sivuun, mutta sen avulla ne tunnistavat ajautumisensa.
Malli 6: tavoitteen ankkurointi
Pitkissä agenttiajoissa alkuperäinen tavoite katoaa. Agentin konteksti-ikkuna täyttyy välivaiheista, ja alkuperäinen kysymys jää pieneksi osaksi suurta kontekstia.
Torju tätä ankkuroimalla tavoite toistuvasti:
- Lisää alkuperäinen tavoite jokaisen järjestelmäviestin alkuun.
- Pyydä agenttia toistamaan tavoite N vaiheen välein.
- Käytä erillistä tavoiteseurantaa, joka vahvistaa jokaisen vaiheen vastaavan tavoitetta.
Esimerkki kehotteen lisäyksestä:
Original goal: [verbatim user request]
Before each action, confirm:
- Is this action helping me toward the original goal?
- If yes, proceed.
- If no, return to the goal directly.
Malli 7: alitehtävien rajaaminen
Pitkät agenttiajot jakautuvat luontevasti alitehtäviin. Ilman rakennetta alitehtävät voivat synnyttää omia alitehtäviään rekursiivisesti, kunnes agentti eksyy.
Määritä rakenne:
- Agentti tunnistaa alitehtävät eksplisiittisesti.
- Jokaisella alitehtävällä on oma budjetti.
- Alitehtävän valmistuttua tai epäonnistuttua agentti palaa päätehtävään.
- Alitehtävät eivät saa synnyttää rajattomasti uusia alitehtäviä.
LangGraphin kaltaiset kehykset pyrkivät formalisoimaan tämän tilakoneeksi, jossa jokainen solmu on selvä vaihe ja siirtymät ovat eksplisiittisiä.
Monimutkaisille agenteille rakenne on välttämätön. Yksinkertaisille se on ylimitoitettu.
Malli 8: poistumistiet
Jumittunut agentti tarvitsee eksplisiittisiä tapoja lopettaa:
Eskalointi. ”En pysty suorittamaan tehtävää. Tässä ovat kokeilemani asiat ja puuttuvat tiedot.” Agentti lopettaa ja tuo ongelman näkyviin.
Osittainen valmistuminen. ”Olen tehnyt osat A ja B. X estää osan C.” Agentin ei tarvitse onnistua kokonaan, vaan se voi tuottaa hyödyllisen osatuloksen.
Tarkennus. ”Tarvitsen käyttäjältä lisätietoa: …” Agentti pysähtyy ja kysyy.
Näiden pitää olla agentin ensisijaisia vaihtoehtoja, ei viimeisiä keinoja. Kehotteen pitää mainita ne ja kannustaa käyttämään niitä jumitilanteessa.
Hyödyllinen lisäys kehotteeseen:
If you encounter any of these situations, stop trying and respond appropriately:
- A tool consistently returns the same error.
- You've tried 3 different approaches without progress.
- You need information only the user can provide.
- The task is more complex than your tools support.
In these cases:
- For tool errors: explain the issue, suggest the user contacts support.
- For lack of progress: report what you've tried and ask for guidance.
- For missing information: ask the user a specific question.
- For complexity: escalate to human assistance with a summary.
Malli 9: luottamuksen huomioivat toiminnot
Agentin pitäisi tunnistaa, milloin se on varma ja milloin ei. Toimiminen pienellä luottamuksella käynnistää silmukoita.
Yksi malli vaatii eksplisiittisen luottamusarvion ennen jokaista seurauksellista toimintoa.
Before calling delete_record, state your confidence on a 1-5 scale that this is the right action. If <4, do not call. Instead, ask for human confirmation.
Tämä toimii erityisen hyvin tuhoisissa tai kalliissa toiminnoissa. Agentin on sitouduttava suureen luottamukseen ennen niiden tekemistä.
Reflektointiin yhdistettynä malli tunnistaa tilanteet, joissa agentti vain kokeilee asioita suunnitelman toteuttamisen sijasta.
Malli 10: työkalutason suojaukset
Agenttitason mallien lisäksi itse työkaluissa voi olla suojauksia:
Istuntokohtainen nopeusrajoitus. Työkalua voi kutsua istunnossa vain N kertaa. Sen jälkeen se palauttaa nopeusrajoituksen ja pakottaa agentin toimimaan toisin.
Idempotenssi. Toistuvat identtiset kutsut palauttavat välimuistituloksen suorittamatta toimintoa uudelleen. Tämä estää työkalua kuormittavat silmukat.
Kustannusrajat. Kalliilla työkaluilla, kuten raskailla tietokantakyselyillä ja maksullisilla kolmannen osapuolen API:illa, on istuntokohtaiset rajat.
Virheiden katkaisijat. Istunnossa 3 kertaa epäonnistunut työkalu poistetaan käytöstä. Agentti ei voi enää kutsua sitä.
Nämä täydentävät agenttitason malleja. Agentti voi yrittää jäädä silmukkaan, mutta työkalu estää sen.
Malli 11: ulkoinen seuranta
Agentin sisäisten mallien lisäksi ulkoinen valvonta tunnistaa läpi pääsevät ongelmat.
Valvontaprosessi seuraa kaikkia käynnissä olevia agentteja. Se tarkistaa:
- Agenttikohtaisen vaihemäärän.
- Agenttikohtaisen tokenien käytön.
- Agenttikohtaisen kustannuksen.
- Agenttikohtaisen keston.
- Työkalukutsujen mallit.
Kun agentti ylittää jonkin rajan, lopeta se ja lähetä hälytys.
Toteutuksessa:
- Aikasarjatietokanta seuraa agenttimittareita.
- Säännöt käynnistävät lopetuskäskyjä, kuten ”jos agentti on ollut käynnissä > 5 minuuttia, lopeta”.
- Pieni palvelu valvoo ja pakottaa säännöt.
Tämä on välttämätöntä järjestelmissä, joissa ajetaan samanaikaisesti paljon agentteja.
Malli 12: ihminen osana valvontaa
Lisää suuren riskin agenteille ihmisen tarkistuspisteitä. Agentti etenee tarkistuspisteeseen ja odottaa ihmisen hyväksyntää.
Tyypillisiä tarkistuspisteitä:
- Ennen tuhoisia toimintoja.
- Päätöksen jälkeen, jos sitä ei voi perua.
- Pitkän tehtävän tärkeissä virstanpylväissä.
- Luottamuksen heiketessä.
Kyse ei ole epäluottamuksesta vaan virheiden havaitsemisesta silloin, kun niiden korjaaminen on edullista.
Käytännöllisessä työnkulussa agentti tekee valmistelun itsenäisesti, esittää yhteenvedon ja ehdotetut toimet, ihminen hyväksyy ja agentti suorittaa. Ihminen osallistuu päätöksiin, ei jokaiseen vaiheeseen.
Läpikäyty esimerkki: pitkään toimiva tutkimusagentti
Havainnollistetaan malleja todellisella agentilla:
Tehtävä: tutki kilpailijaa ja laadi muistio.
Arvioitu työ: 10-30 verkkohakua, 20-50 sivun lukeminen ja synteesi 1000 sanan muistioksi.
Käytetyt mallit:
-
Vaihebudjetti: yhteensä 60 vaihetta.
-
Tokenbudjetti: 300K tokenia kontekstiin ja toimintoihin. Jos raja ylittyy, tiivistä nykyiset löydökset ja jatka.
-
Kustannusbudjetti: €2 ajoa kohti. Jos raja ylittyy, lopeta ja palauta osittainen muistio.
-
Aikabudjetti: 5 minuuttia seinäaikaa.
-
Edistymisen seuranta: agentti päivittää jokaisessa vaiheessa löydöslokia uudella tiedolla. Jos 3 vaihetta kuluu ilman uusia löydöksiä, poistu.
-
Toiston tunnistus: jos sama hakukysely ajetaan kahdesti samankaltaisin tuloksin, pakota toinen lähestymistapa.
-
Reflektointipisteet: agentti arvioi edistymistä ja jäljellä olevaa työtä 10 vaiheen välein.
-
Tavoitteen ankkurointi: alkuperäinen muistion tavoite jokaisen järjestelmäviestin alussa.
-
Poistumistiet: sekä ”minulla on tarpeeksi tietoa” että ”en löydä riittävästi tietoa” lopettavat agentin hallitusti.
-
Ulkoinen valvonta: riippumaton valvoja lopettaa budjetit ylittävät agentit.
Tulos: mediaaniajoaika 3 minuuttia ja mediaanikustannus €0.40. Silmukoiden tai aikakatkaisujen osuus < 1%. Muistiot ovat 700-1200 sanaa pitkiä, tosiasioihin perustuvia ja hyödyllisiä lähtökohtia.
Ilman malleja ajo kestää toisinaan 30 minuuttia, maksaa toisinaan €20+ ja voi rikkoa istunnon. Mallit pienentävät jakauman häntää huomattavasti.
Tunnistus tuotannossa
Malleista huolimatta ongelmia pääsee joskus läpi. Tunnista ne:
Hälytykset pitkistä agenttiajoista. Hälytä kaikista agenteista, joiden kesto on > 2x mediaani.
Hälytykset kustannuspiikeistä. Agenttikohtainen tai yhteenlaskettu kustannus ylittää rajan.
Hälytykset toistomalleista. Työkalukutsujen mallit viittaavat silmukkaan.
Pitkien jälkien päivittäinen tarkastus. Ihminen vilkaisee päivän 10 pisintä jälkeä. Näin löytyvät arvioinneilta huomaamatta jäävät ongelmat.
Koostemittarit: silmukoiden osuus ajan mittaan. Tämä paljastaa mallipäivityksen tai kehotemuutoksen kaltaisen muutoksen, joka lisää silmukoita.
Hyödyllinen hallintapaneeli näyttää agenttiajojen pituusjakauman. Jakauman häntä kertoo silmukoiden yleisyydestä.
Yleiset virheet
Muutamia toistuvasti havaitsemiamme malleja:
Virhe 1: ei vaihebudjettia. ”Lisäämme sen tarvittaessa.” Sitten agentti jää silmukkaan kello 3 AM, ja toivot lisänneesi sen. Lisää se aina ensimmäisestä päivästä lähtien.
Virhe 2: liian suuret budjetit. ”100 vaihetta varmasti riittää”, mutta silmukka täyttää ne. Aseta budjetti arvoon 2-3x mediaani, älä pahimman tapauksen mukaan.
Virhe 3: ei ulkoista valvontaa. Agentin luotetaan lopettavan itse. Joskus se ei lopeta. Ulkoinen valvonta on tuotannossa välttämätön.
Virhe 4: silmukat tunnistetaan mutta niitä ei analysoida. Valvonta lopettaa silmukan ja tiimi jatkaa eteenpäin. Sama silmukka toistuu seuraavalla viikolla. Tee aina jälkianalyysi: mikä käynnisti silmukan, mikä muuttui ja voidaanko koko virheluokka estää?
Virhe 5: liiallinen reflektointi yksinkertaisissa tehtävissä. Reflektointi 5 vaiheen välein 5-vaiheisessa tehtävässä lisää työtä ilman hyötyä. Sovita se tehtävän monimutkaisuuteen.
Virhe 6: tavoite katoaa pitkässä kontekstissa. Vaiheessa 1 kerran mainittu tavoite ei säily vaiheeseen 50. Ankkuroi se säännöllisesti uudelleen.
Virhe 7: agentin omiin edistymisraportteihin luotetaan. Agentit ilmoittavat edistyvänsä silloinkin, kun eivät edisty. Varmenna ulkoisesti mahdollisuuksien mukaan.
Virhe 8: agenttien sallitaan kutsua itseään rekursiivisesti. ”Jaa tehtävä aliagenteille” voi synnyttää eksponentiaalisesti agentteja. Jos sallit tämän, budjetoi se tiukasti.
Milloin silmukat ovat hyväksyttäviä
Kaikki silmukat eivät ole huonoja. Jotkin tehtävät vaativat perustellusti useita iteraatioita:
- Koodin iteratiivinen kehitys: kirjoita, testaa, korjaa ja toista.
- Haarautuva monivaiheinen tutkimus.
- Optimointitehtävät: kokeile muunnelmia, arvioi ja paranna.
Näissä silmukka on työtä eikä virhe. Mallit muuttuvat:
- Väljät vaihebudjetit (50-200 vaihetta).
- Eksplisiittinen kehystys iteraatioksi, ei silmukaksi.
- Laadun parantumisen seuranta: jokaisen iteraation pitäisi parantaa mittaria.
- Tiukka lopetus parannuksen tasaantuessa.
Periaate on erottaa tarkoituksellinen iteratiivinen työ tahattomista silmukoista ja soveltaa malleja tilanteen mukaan.
Tuotannon tarkistuslista
Ikuiseen silmukkaan jäävät agentit ovat ennakoitavia, yleisiä ja estettävissä. Mallit tunnetaan: vaihebudjetit, edistymisen seuranta, toiston tunnistus, reflektointi, tavoitteen ankkurointi, poistumistiet, työkalujen suojaukset ja ulkoinen valvonta.
Ne eivät ole valinnaista viimeistelyä. Ne erottavat julkaistavat agentit agenteista, jotka tuottavat yllättäviä nelinumeroisia laskuja.
Jokaisen tuotantoagentin tarkistuslista:
- Vaiheiden enimmäisbudjetti.
- Tokenien enimmäisbudjetti.
- Kustannusten enimmäisbudjetti.
- Ajan enimmäisbudjetti.
- Toistuvien kutsujen tunnistus.
- Edistymisen seuranta.
- Säännöllinen reflektointi.
- Tavoitteen ankkurointi.
- Useita poistumisteitä.
- Lopetuskykyinen ulkoinen valvonta.
Jokainen niistä on helppo toteuttaa. Yhdessä ne erottavat ”tämän agentin jättäminen päälle on vaarallista” -tilanteen ”tämä agentti on tuotannossa luotettava” -tilanteesta.
Rakenna mallit sisään ja testaa ne. Poistamasi häntäriski on moninkertaisesti työn arvoinen.



