Hva en kontekstmotor faktisk gir deg: Vi kjørte 22 AI-kodeanmeldere på fem forskjellige måter

AI Agents Context Engineering MCP Agentic Workflows

Vi ga den samme kodeanmeldelsesoppgaven til 22 AI-agenter. Samme pull request, samme festnet commit, samme prompt, samme modell — den eneste variabelen var hvordan hver agent lastet inn prosjektets regler. Den billigste konfigurasjonen viste seg å være den mest grundige, og grunnen til det sier noe generelt om kontekstingeniering.

TL;DR: En kontekstmotor-digest pluss en direkte lesing av policyfilen for maskinlesbar slo alle andre strategier: $1,56 per anmeldelse og 9,6/13 verifiserte funn — billigere enn å lese dokumentene ($2,30, 8,6/13) og bedre enn digest alene ($1,77, 7,8/13). Lesing av alt scoret dårligst av alt (7,4/13). Alle 22 agenter kjørte på Claude Opus 4.8, og 21 av 22 kom til samme konklusjon.

Hva: en harness, en kontekstmotor og en pull request

Hva er en “harness”?

Hver seriøs forsøk på å la AI-agenter arbeide i et produksjonsdepot vokser to lag med styring.

Prosalaget — konvensjoner, arkitekturregler, teststandarder. I vårt depot er det CLAUDE.md og docs/**: “backend er snake_case,” “domene importerer aldri infrastruktur,” “alle rutehåndtakere er async.” Mennesker leser det; agenter blir fortalt å lese det også.

Det maskinlesbare lagetharness-konfigurasjonen. Vår er en enkelt JSON-fil som klassifiserer hver sti i depotet i risikonivåer og knytter gjennomtvingbare porter til hvert nivå. CI leser det. Sammenslåingspolicy leser det. Det er ikke råd — det er policy:

"tier3": {
  "requiredChecks": [
    "lint", "test", "build", "review-agent",
    "harness-smoke", "manual-approval", "expanded-coverage"
  ],
  "mergePolicy": {
    "minApprovals": 2,
    "requireReviewAgent": true,
    "allowSelfMerge": false
  }
}

(Terminologimerknad: “harness” navngir også agent kjøretiden selv — stillasseringen av verktøy, ferdigheter og MCP-servere en agent handler gjennom, som i harnext , “kodingsagent-harnessen.” I dette innlegget er harness-konfigurasjonen depoets policyfil som en slik kjøretid og CI begge håndhever.)

En kodeanmeldere — menneske eller agent — kan ikke bedømme “er denne PR tillatt å slå sammen?” uten denne filen. En Tier-3 PR med review-agent-sjekken hoppet over er et policybrudd selv om hver test er grønn. Husk dette eksempelet; det avgjør eksperimentet.

Fordi begge lagene finnes, krever depotet en port: ingen agent starter arbeid før den laster inn denne konteksten — og beviser at den gjorde det, via en bekreftelsesblokk som anmeldere sjekker. Spørsmålet dette innlegget besvarer er ganske enkelt: hva er den billigste riktige måten å tilfredsstille denne porten?

Møt harnext og meaninggrid

meaninggrid er den hostede kontekstmotoren fra harnext , QualityUnits MIT-lisensierte, leverandøragnostiske kodingsagent-harness (seks verktøy — les, skriv, rediger, bash, ferdighet, mcp — npm i -g harnext). Leverandørens pitch for kontekstmotoren er direkte: “hjernen til agenten din.” Kilder strømmer inn i en kontinuerlig oppdatert indeks — “nettet” — og per spørring trimmer motoren den til “token-effektiv kontekst, ledningsrett inn i harness”: kontinuerlig indeks, relevansorangering, dedup og cache. harnext sitt hovedtall er −89% tokens per spørring i gjennomsnitt. Det er leverandørens påstand; ett formål med dette eksperimentet var å måle, med våre egne tall på en faktisk oppgave, hva den slags kompresjon faktisk sparer — og hva det koster.

I vår distribusjon leser nettet inn depoets prosa-dokumentasjon; hver innlesning produserer et uforanderlig, versjonert øyeblikksbilde. Agenter spør det over MCP (meaninggrid.harnext.dev/mcp) med et enkelt context_research-kall og mottar en syntetisert, sitert digest stemplet med snapshot_id, som agenten må sitere i sin bekreftelsesblokk — revisjonsbar kontekst gjort konkret.

Context engine pipeline: prose docs flow through ingest, versioned snapshot and context_research into the agent, while the machine-readable policy file is read directly

Hva porten produserer — bekreftelsesblokken (eksempel; prosjektspesifikker utelatt):

Loaded via: optimized hybrid (context-engine digest + policy file only).

- context_research call #1 (conventions / layering / testing / security /
  risk tiers) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research call #2 (LLM-provider integration checklist +
  flow-engine extra-care rules) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Read harness config (full) from disk for exact tier patterns,
  requiredChecks, mergePolicy, evidenceConfig.
  Did NOT read CLAUDE.md or docs/* (covered by the digest).

snapshot_id-en er reell — en anmeldere kan verifisere nøyaktig hvilken versjon av reglene agenten arbeidet fra.

Tre hypoteser

Eksperimentet ble utformet for å løse tre testbare spådommer, skrevet ned på forhånd:

H1 — En digest er billigere enn å lese på nytt. Les inn prosa-dokumentene en gang, server hver agent en kompakt syntetisert digest, i stedet for at hver agent leser hvert dokument på hver oppgave. Hvis sann: meningsfullt lavere kostnad per anmeldelse, med like dommer.

H2 — Parafrase ødelegger policy. En digest kan formidle “Tier 3 krever menneskelig gjennomgang” uten tap. Den kan ikke formidle "requireReviewAgent": true uten tap — de eksakte, sitérbare spesifikasjonene en anmeldere trenger for å hevde et brudd dør i oppsummering. Hvis sann: digest-bare agenter bør systematisk misse port-brudd som agenter som holder den bokstavelige policyfilen fanger.

H3 — Leanere kontekst leser dypere. Kontekst betales for to ganger — en gang i dollar, en gang i oppmerksomhet: hvert redundant dokument i vinduet konkurrerer med koden under anmeldelse. Hvis sann: lesing av alt (digest + alle dokumenter) bør ikke vinne; den leaneste tilstrekkelige konteksten bør.

Hvordan vi testet det

Tjueto agenter anmeldte den samme Tier-3 pull request i vårt produksjonsdepot (en LLM-leverandør-integrasjon: 44 filer, +2.111 linjer, virkelige innsatser — faktureringstabell, flow-engine-ruting). Fem armer, som bare avviker i kontekstlastingstrinn:

ArmKontekstlastingn
meaninggridkontekstmotor-digest bare (2× context_research)5
diskleser 7+ dokumenter fra disk — ingen kontekstmotor5
hybriddigest + leser ALLE dokumentene5
opt-hybriddigest + leser EN fil: harness-konfigurasjonen5
coldingen konvensjonskontext i det hele tatt (grunnlinje)2

Grunnregler: en festnet commit, en prompt-tekst, en modell — Claude Opus 4.8 — alle armer sammenvevd i en enkelt samtidig batch. Agenter ble utelukket fra PR-kommentartråden, slik at tidligere eksperimentrunder ikke kunne lekke inn. Hvert tall kommer fra de råe agent-transkripsjonene, med tokenbruk deduplisert per API-forespørsel og priset til listepriser. Kvalitet scores mot 13 uavhengig verifiserte, virkelige defekter i PR-en, mønster-matchet i hver anmeldelse og manuelt revidert for falske positiver. Dommeavtale på tvers av alle armer: 21/22 sa REQUEST CHANGES.

Så hva: den billigste konfigurasjonen vant også på kvalitet

Scatter chart of cost per review versus verified findings: opt-hybrid is cheapest and most thorough, read-everything hybrid scores worst
ArmKostnad / anmeldelseFunn (av 13)Port-funn (av 3)Veggklokke
meaninggrid$1,777,80,25:34
disk$2,308,60,84:35
hybrid$1,837,40,85:40
opt-hybrid ★$1,569,61,44:55
cold$1,648,00,54:13

★ = konfigurasjonen vi nå sender som depoets standard ferdighet. Veggklokke inkluderer delt konkurranse fra å kjøre 22 agenter samtidig.

H1 — bekreftet

Digest-bare armen anmeldte for $1,77 mot $2,30 for å lese dokumentene (−23%), og den vinnende digest-pluss-en-fil-armen for $1,56 (−32%) — med like dommer. Sparingen sammensatt: digestet erstatter en stabel med dokumenter som ellers ville kjørt gjennom hver påfølgende API-kalls kontekst.

H2 — bekreftet, avgjørende

Den hoppede over review-agent-sjekken — et genuint sammenslåingspolicy-brudd i denne PR-en — ble fanget av 5 av 5 agenter som holdt den bokstavelige policyfilen, og av 1 av 5 digest-bare agenter. Mekanismen er nøyaktig det H2 forutsa: for å skrive det funnet, må en agent matche eksakte CI-sjekknavn mot eksakte konfigfelt — en parafrase er ikke sitérbar bevis, så digest-bare agenter sikrer seg og dropper det. En direkte lesing gjenoppretter det.

Side by side: the harness policy requiring the review-agent check, and the CI run where that check was skipped while everything else passed

H3 — bekreftet

Hybrid-armen som leste alt bar mest kontekst av noen arm og scoret dårligst (7,4/13), mens den leaneste tilstrekkelige armen scoret best (9,6/13) — og var best av alle armer på det eneste dypeste funnet, en dead-code-feil som krever sporing av en kallsti på tvers av tre filer. Redundant prosa la ikke til informasjon; den konkurrerte med koden om oppmerksomhet.

Time anatomy of a digest agent versus a docs-reading agent: the context engine wait is visible, doc reads are fast slivers, model time dominates both

En ærlig fotnote: cold-grunnlinjen (8,0/13 på $1,64) viser at de fleste av de 13 defektene er vanlige kodebugger en sterk modell finner uten noen konvensjonskontext i det hele tatt. Hva cold ikke kan gjøre er policy-halvdelen av jobben — porter, nivåer, sammenslåingsregler — som er nettopp der armene skiller seg.

Kurer prosaen inn i en digest. Les policyfilen rå. Ikke les noe to ganger.

Full avsløring

  • Modell: hver API-kall av hver agent kjørte på claude-opus-4-8 (Claude Opus 4.8) — verifisert fra model-feltet i hver transkripsjonslinje, ikke antatt. Resultatene kan avvike på andre modeller; mindre modeller er sannsynligvis avhengig mer av kuratert kontekst, ikke mindre.
  • Priser: kostnader bruker Anthropic-listepriser på skrivingstidspunktet; faktisk fakturering kan avvike. Relative sammenligninger er upåvirket.
  • Utvalgsstørrelse: n=5 per arm (n=2 for cold), en PR, ett depot, en oppgavetype. Port-effekten (5/5 vs 1/5) er skarp; per-funn-satser andre steder er ±1 agent. Behandle dette som en sterk pilot, ikke en benchmark.
  • Kvalitetsmål: mønsterdeteksjon over anmeldelsestekst (sitater ekskludert), manuelt revidert for falske positiver. Den teller omtaler av verifiserte defekter, ikke samlet anmeldelse-veltalenhet.
  • Timing: alle 22 agenter delte en maskin og en API-kvote; veggklokke-tall inkluderer den konkurransen.
  • Vi korrigerte oss selv to ganger: initiale token-tellinger var oppblåst 2–3× (per-linje-bruksduplicering i transkripsjonene; fikset av forespørsel-ID dedup), og en tidligere tidslinje-visuell underkjente veggtid (fikset av full intervall-attribusjon). Begge korreksjonene er bakt inn i hvert tall her.
FlowHunt Logo

Klar til å vokse bedriften din?

Start din gratis prøveperiode i dag og se resultater i løpet av få dager.

Nå hva: stjel løkken

Hva vi sendte

Den vinnende armen er nå depoets standard check-context-first-ferdighet: trekk kontekstmotor-digestet (to kall), så les nøyaktig en fil fra disk — harness-konfigurasjonen — og send ut en bekreftelsesblokk som siterer øyeblikksbildet og de eksakte portene. En målt svakhet, en en-linje policyretting, re-validert samme dag. Den løkken — måle, fikse kontekstpolicyen, re-validere — er delen vi ville oppmuntre deg til å stjele, uansett hvilken kontekstmotor du bruker.

Hva du kan gjøre på mandag

  1. Del agentkontext din i to: prosa (konvensjoner, arkitektur, testing) vs maskinlesbar policy (CI-porter, risikonivåer, sammenslåingsregler).
  2. Digest prosaen; digest aldri policyen. Server prosaen gjennom en kontekstmotor — meaninggrid er vår — og gjør policyfilen en obligatorisk ordrett lesing i din kontekstport.
  3. Gjør kontekst revisjonsbar. Versjon den innlesne konteksten; krev at agenter siterer snapshot-id-en i en bekreftelsesblokk anmeldere faktisk kan sjekke.
  4. Måle før du tror — inkludert oss. En håndful agenter per arm på ditt eget depot er nok til å se mønsteret. Score anmeldelsene mot verifiserte funn, ikke vibes.

En åpen invitasjon

Hvis du kjører dette eksperimentet på ditt eget depot — samme armer, din modell, din harness — ville vi genuint likt å se tallene dine, spesielt hvis de motbeviser våre. Og hvis laget ditt vil ha hjelp med å sette opp en kontekstport som denne, eller vil snakke om meaninggrid og harnext-stacken, ta kontakt med FlowHunt-teamet eller finn open-source-harness-en på harnext.dev . Replikasjoner, spørsmål og korreksjoner er alle velkomne.

Vanlige spørsmål

Štefan er en AI- og programvaringeniør som bygger FlowHunt. Utover selve produktet designer han agentic software-engineering-arbeidsflyter for utviklere som reduserer utviklingskostnader samtidig som de øker kodekvaliteten.

Štefan Moravík
Štefan Moravík
AI- og programvaringeniør

Bygg Agent Workflows som betaler for seg selv

FlowHunt hjelper ingeniørteam med å utforme agentic workflows, kontekstporter og MCP-integrasjoner som reduserer utviklingskostnader samtidig som de øker kodekvaliteten.