Langvarige agentjobs kræver styring i laget omkring modellen
Ifølge Marktechpost er større modeller eller længere kontekstvinduer alene ikke en løsning på LLM‑agenters problemer i flertrinsopgaver over lang tid. Marktechpost argumenterer for, at forskellen skabes i harness‑laget – styringen omkring modellen. Artiklen beskriver en agent som en LLM, der kalder værktøjer i et loop, og peger på, at netop det loop bryder uden stram kontrol af kontekst, mål og state. Fire mekanismer fremhæves af Marktechpost: kontekst‑budgettering og offloading, kompaktion, memory‑strategi og eksplicit todo‑/state‑styring.
Marktechpost henviser her til AWS Samples’ designvejledning for autonome cloud‑kodningsagenter for at navngive fejltyperne. Ifølge Marktechpost er fokus for praktiske forbedringer netop disse mekanismer i harness‑laget.
Hvad er en agent i praksis
Marktechpost beskriver en agent som “an LLM calling tools in a loop”. Strømmen er enkel: mål og kontekst ind, værktøjskald, observation tilbage, ny beslutning, gentag. Denne konstruktion fungerer typisk på korte jobs; når tidsaksen bliver lang, ændres billedet ifølge Marktechpost.
Ifølge Marktechpost – med henvisning til AWS Samples’ designguide – bryder simple, “shallow” agenter forudsigeligt på lange forløb: kontekst overflow/drift, goal loss og manglende vedligeholdt state over tid. Den manuelle brief, der er vedlagt som kilde, beskriver de samme fejlformer i praksis.
Hvorfor større kontekstvinduer ikke er nok
Marktechpost sammenfatter fund fra Chromas arbejde om “Context Rot”: 18 modeller blev ifølge Marktechpost evalueret, og performance blev mere upålidelig, jo længere input – selv på enkle retrieval‑opgaver. Denne oplysning gengives sekundært via Marktechpost; Chromas primære metode er ikke gennemgået her.
Marktechpost gengiver også Anthropics forklaring: opmærksomhed skaber n^2 parvise relationer for n tokens, så yderligere tokens tærer på en endelig “attention budget”. Ifølge Marktechpost (som tilskriver Anthropics) gør det kontekst til en knap ressource med aftagende udbytte. Primærkilden fra Anthropic er ikke verificeret her.
Kvantificeringer gengivet via Marktechpost
Marktechpost refererer, at Manus rapporterer cirka 50 tool‑calls for en typisk lang opgave og en input‑til‑output token‑ratio omkring 100:1. Pointen ifølge Marktechpost er, at observationer ophobes i konteksten og skubber oprindelige instruktioner mod vinduets midte, hvor recall ifølge artiklen degraderer. Tallene er gengivet sekundært via Marktechpost; Manus’ primærmetode er ikke verificeret her.
Marktechpost sammenfatter heraf, at uden styring af kontekst og state bliver lange løb ustabile, også med større vinduer.
Mekanisme 1 – kontekst‑budgettering og offloading
Ifølge Marktechpost er kontekst‑budgettering et førstegangsansvar i et harness: at afgøre, hvad der slet ikke må ind i vinduet. Marktechpost skriver, at LangChain Deep Agents leverer to offloading‑regler med konkrete grænser. Et eksempel, som Marktechpost gengiver: når et værktøjssvar overstiger 20.000 tokens, skrives det til filsystemet og erstattes i konteksten af en sti plus et preview af de første 10 linjer. Denne regel er gengivet via Marktechpost; underliggende dokumentation fra Deep Agents er ikke gennemgået her.
Formålet, som beskrevet af Marktechpost, er at holde selve vinduet rent og erstatte store mellemresultater med lette referencer. Når agenten behøver detaljerne, kan de hentes igen fra lagring.
Mekanisme 2 – kompaktion og selektiv summarization
Når offloading ikke er tilstrækkeligt, peger Marktechpost på kompaktion: at opsummere lange logs og samtaler og starte en ny kontekst med det væsentlige. Ifølge Marktechpost kan en selektiv tilgang fastholde arkitekturvalg, uløste fejl og relevante implementeringsdetaljer, mens redundant værktøjsoutput skæres væk.
Rationalet hos Marktechpost er at holde ufravigelige regler og aktive TODO’er synlige i fuld tekst, mens støj koges ned. Det reducerer risikoen for, at mål og constraints forsvinder i mængden.
Mekanisme 3 – memory‑strategi og udskudt indlæsning
Ifølge Marktechpost arbejder flere systemer med memory‑disciplin: udskudt indlæsning af store skemaer, on‑demand hentning af fulde repræsentationer og repræsentation af store filer som referencer frem for fuld tekst i hovedløkke‑konteksten. Pointen er at undgå, at alt materiale forurener konteksten fra start.
Marktechpost fremhæver, at disse teknikker mindsker konteksttryk og gør det mere sandsynligt, at modellen fastholder mål og regler over længere tidsrum.
Mekanisme 4 – eksplicit todo‑/state, checkpoints og idempotens
Marktechpost peger på, at en eksplicit opgave‑ og system‑state – med todo‑liste, checkpoints for delmål og idempotente værktøjskald – muliggør genstart, rollback og validering. Her kobler Marktechpost til de fejlmønstre, som AWS’ designvejledning navngiver, ved at give agenten en struktureret repræsentation af mål og fremskridt, der kan genbruges hver cyklus.
Ifølge Marktechpost muliggør eksplicit state, at en agent kan vende tilbage til sidste gyldige checkpoint frem for at drive videre på en forurenet kontekst.
Hvorfor et harness prioriteres før større modeller
Marktechpost argumenterer samlet for, at et robust harness griber ind tidligt: offloading holder vinduet rent, kompaktion bevarer signalet, memory‑strategi sænker metadata‑støj, og todo‑/state‑styring fastholder målet. En modelopgradering kan være nyttig på andre dimensioner, men adresserer ifølge Marktechpost ikke i sig selv den tidslige dimension i agentløkker.
Dette perspektiv er i overensstemmelse med de failure modes, som Marktechpost beskriver, og som den manuelle brief også lister.
Praktiske implikationer ifølge kilderne
Hvis man følger de fire mekanismer, som Marktechpost oplister, peger kilderne på mere stabil drift af lange jobs: store mellemresultater parkeres uden for vinduet, kontekst renses og summeres selektivt, tunge skemaer hentes kun efter behov, og mål samt delmål holdes eksplicit adskilt fra midlertidigt værktøjsoutput.
Det overordnede råd, som kan udledes af Marktechpost og den manuelle brief, er at behandle kontekst og state som eksplicitte ressourcer gennem hele løbet – ikke som noget, der blot følger med i en voksende prompt.
Kilder og metode
Artiklen bygger på Marktechposts “Context Engineering Inside the Harness”, som samler pointer fra AWS Samples’ designvejledning samt observationer fra projekter (bl.a. Manus, Chroma, Anthropics og Deep Agents). Hvor der nævnes specifikke tal og thresholds (fx Deep Agents’ 20.000 tokens/10 linjer og Manus’ værktøjskald/token‑ratio), er de gengivet via Marktechpost; de tilhørende primærkilder/metoder er ikke gennemgået her.
Konklusionerne om fejlformer og afhjælpning er kilde‑attribuerede. De dele, hvor primærmetoder ikke er verificeret her, bør læses som foreløbige, indtil originalmaterialet er gennemset.
Konklusion
Ifølge Marktechpost – med reference til AWS’ designvejledning og de nævnte projekter – svigter simple LLM+tool‑loop‑agenter ofte på lange opgaver på grund af kontekstdrift, mål‑tab og manglende state. Den stabile vej frem beskrives som et stærkt harness med fire mekanismer: kontekst‑budgettering/offloading, kompaktion, memory‑strategi og eksplicit todo‑/state. Større vinduer og modeller kan hjælpe på visse dimensioner, men ændrer ifølge Marktechpost ikke dynamikken i en løkke, der skal holde længe.
