Observert (2026-07-29, event github-digdir-digdir-ai-agents-104-c5116009307)
En pi-kjøring (ornith-35b) trigget av en ren statuskommentar løp i 5t01m med ~1 956 LLM-kall før den ble drept manuelt (exit 143 → ærlig error-linje, #91-fallback virket). Obduksjon av sesjonsfilen (~/.pi/agent/sessions/…/2026-07-29T09-48-41-…jsonl, 3 977 meldinger):
- De første ~16 verktøykallene var normale og varierte.
- Deretter kjørte agenten ett og samme bash-kall 1 972 ganger ordrett (
gh issue list … | awk '{print $1}' | sort -n) — og fikk identisk, gyldig svar hver gang. Ingen feil å reagere på; ren degenerert løkke på beslutningsnivå.
Hvorfor ikke bare timeout
Lokale modeller har stor legitim spredning i kjøretid (4–23 min observert på normale arbeidsordrer). En hard makstid må settes så romslig at den først redder oss etter lang tid — mens løkka over var entydig detekterbar etter ~25 sekunder (tre identiske kall på rad).
Forslag: løkkevakt i entrypoint + romslig backstop
- Løkkevakt (primær): pi appender sesjonsfilen live. En watchdog i
agents/proxy-agent/docker/entrypoint.sh (samme mønster som dagens watch-løkke) sjekker f.eks. hvert 60. sekund de siste toolCall-oppføringene i nyeste sesjonsfil. Regel (besluttet 2026-07-30): glidende vindu over de siste 10 verktøykallene — hvis ≥5 er identiske (samme verktøy + samme argumenter) → drep pi-prosessen og skriv ærlig status:"error"-resultatlinje med forklaring («løkke detektert: samme verktøykall x N av siste 10»). Vindusvarianten fanger også vekslende løkker (A-B-A-B-…), ikke bare rene repetisjoner som gårsdagens.
- Backstop (sekundær): svært romslig absolutt makstid rundt pi-kallet (f.eks. 2 timer) som fanger patologier løkkevakta ikke ser (f.eks. evig varierende men uproduktive kall). Samme ærlige feilhåndtering.
- Begge skal la
knowledge_push_pending og resten av oppryddingen i process_event kjøre som vanlig (kill av pi, aldri av containeren).
Kontekst
Observert (2026-07-29, event
github-digdir-digdir-ai-agents-104-c5116009307)En pi-kjøring (ornith-35b) trigget av en ren statuskommentar løp i 5t01m med ~1 956 LLM-kall før den ble drept manuelt (exit 143 → ærlig error-linje, #91-fallback virket). Obduksjon av sesjonsfilen (
~/.pi/agent/sessions/…/2026-07-29T09-48-41-…jsonl, 3 977 meldinger):gh issue list … | awk '{print $1}' | sort -n) — og fikk identisk, gyldig svar hver gang. Ingen feil å reagere på; ren degenerert løkke på beslutningsnivå.Hvorfor ikke bare timeout
Lokale modeller har stor legitim spredning i kjøretid (4–23 min observert på normale arbeidsordrer). En hard makstid må settes så romslig at den først redder oss etter lang tid — mens løkka over var entydig detekterbar etter ~25 sekunder (tre identiske kall på rad).
Forslag: løkkevakt i entrypoint + romslig backstop
agents/proxy-agent/docker/entrypoint.sh(samme mønster som dagens watch-løkke) sjekker f.eks. hvert 60. sekund de sistetoolCall-oppføringene i nyeste sesjonsfil. Regel (besluttet 2026-07-30): glidende vindu over de siste 10 verktøykallene — hvis ≥5 er identiske (samme verktøy + samme argumenter) → drep pi-prosessen og skriv ærligstatus:"error"-resultatlinje med forklaring («løkke detektert: samme verktøykall x N av siste 10»). Vindusvarianten fanger også vekslende løkker (A-B-A-B-…), ikke bare rene repetisjoner som gårsdagens.knowledge_push_pendingog resten av oppryddingen iprocess_eventkjøre som vanlig (kill av pi, aldri av containeren).Kontekst
agents/proxy-agent/docker/entrypoint.sher CODEOWNERS-sti, og PR Proxy-agent: reparer nesten-JSON og retry ved AGENT-RESULT-feil #111 endrer samme fil — bør tas etter at Proxy-agent: reparer nesten-JSON og retry ved AGENT-RESULT-feil #111 er merget for å unngå konflikt.