2026-07-22 · Bijgewerkt 2026-07-22

[!NOTE] Automatische vertaling Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.

Harness engineering voor AI agents: het ontwerpen van de lus rondom de model

Deel 6 van de serie ‘Engineering the Agentic Stack’

De reasoning loop van een agent kiest de volgende actie. Zijn harness levert context, valideert en autoriseert de voorgestelde tool calls, stuurt geaccepteerde oproepen door naar de runtime, registreert de resultaten en beslist of de taak voltooid is.

Models stelt wijzigingen voor en kan taken als afgerond markeren, terwijl de harness toezicht houdt op de rechten en de acceptatiecontroles interpreteert die bepalen of de lus kan worden gestopt. Deel 5 Er wordt aandacht besteed aan de runtime die ervoor zorgt dat het proces actief blijft. Dit artikel richt zich op de controlecode die zich binnen die runtime bevindt: hoe men kan bepalen of elke toevoeging nuttig is en hoe men de resulterende controles behouden kan zodat deze nog steeds te lokaliseren zijn wanneer de harness verandert.

Naast de eerste expliciete acceptatiecontrole vormt elke extra poging tot herstart, overdracht of evaluator een hypothese met betrekking tot een waargenomen fout. Zulke aanpassingen krijgen pas hun plaats wanneer een gecontroleerde vergelijking aantoont dat ze daadwerkelijk helpen.

Om die controleweg concreet te maken, zal ik een klein, fictief winkelrepository gebruiken. De coderingsopdracht is om de drempel voor een automatische korting van 10% te verlagen van $100 naar $75. src/checkout.py. De repository bevat twee vereiste controles:

• pytest tests/test_checkout.py controleert de berekening van de korting. pnpm playwright test tests/checkout_discount.spec.ts Voegt een artikel ter waarde van $80 toe in een lokale testwinkel en controleert of de afrekenpagina een korting van $8 toont.

Het voorbeeld is een educatief hulpmiddel en geen echte toepassing of benchmark. Elke poging begint vanuit dezelfde commit en met dezelfde initiële testgegevens. De harness kan de wijziging alleen accepteren wanneer beide commando’s slagen en de trace deze resultaten koppelt aan de geteste commit.

In de latere secties worden bewust twee andere voorbeelden gebruikt. Een volgvolgorde API legt uit waarom oproepen die de staat veranderen bescherming tegen heruitvoering nodig hebben, terwijl een migratie van een betalingsadapter laat zien wat een nieuwe model session moet doen om onafgemaakte taken voort te zetten. Het bijbehorende laboratorium aan het einde is opnieuw apart: het is uitvoerbaar, maar bevat algemene gesimuleerde taken in plaats van dit repository voor winkels.

TL;DR: Begin met één model, een paar gespecialiseerde hulpmiddelen en een expliciete acceptatiecontrole. Voeg herproberingen toe wanneer traces tijdelijke fouten bij aanroepen aangeeft. Zorg voor een doorgeefprocedure van de voortgang wanneer sessions het werk opnieuw uitvoert. Tijdens het testen van eventuele wijzigingen moet de model-versie, de taken, de beoordelingsmethode en het totale budget onveranderd blijven. Verwijder de betreffende component zodra deze geen verbetering oplevert in de gemeten resultaten.

Het diagram laat de verandering in discount zien van het voorstel tot het bewijsmateriaal. De harness levert de taak en bestanden, en controleert het voorgestelde edit_file De argumenten en rechten worden gecontroleerd, waarna de geaccepteerde oproep wordt verwerkt. Nadat runtime de wijziging heeft toegepast, voert harness de genoemde eenheidstests en browseracceptantietests uit. Een mislukte opdracht wordt teruggestuurd naar model als bewijs voor een volgende poging; twee geslaagde opdrachten maken de wijziging geschikt voor acceptatie.

Wat harness bezit

OpenAI’s Walkthrough van de Codex loop Dit beschrijft de basiscyclus. De harness assembleert een prompt, vraagt aan de model om de volgende actie, stuurt een geaccepteerde tool call naar de runtime, voegt het resultaat toe en stelt opnieuw de vraag totdat de harness het resultaat accepteert of de controle teruggeeft aan de gebruiker.

Implementaties kunnen meerdere verantwoordelijkheden samenvoegen tot één proces. De foutgrenzen blijven echter verschillend:

Wanneer er een fout optreedt, dien je de grens te diagnosticeren die zou moeten reageren. Een slecht plan kan betere instructies of model reasoning nodig hebben. Als edit_file richt zich op een pad daarbuiten src/De harness moet dit afwijzen, terwijl een sandbox-proces dat sterft voordat de wijziging wordt uitgevoerd tot de runtime behoort; dit proces moet ofwel de worker opnieuw starten of de crash melden.

de eigen van OpenAI harness – ingenieurscasestudy Het beschrijft een opstartbare applicatie‑instans voor elk worktree. Het team heeft bovendien browserautomatisering geïntegreerd in de agent omgeving en heeft logs, metrics en traces beschikbaar gesteld.

Een taak als “geen span in deze vier kritieke gebruikersjourneys mag langer duren dan twee seconden” kon worden getest omdat de agent de applicatie kon uitvoeren en dezelfde signalen kon opvragen die een ingenieur zou controleren. Het casestudy is productspecifiek. Wat wordt overgedragen, is de voorwaarde achter het resultaat: de applicatie en de bijbehorende prestatiesignalen moesten beschikbaar zijn binnen het agent-omgeving.

Lopopolo, de auteur van die casestudy, houdt een Handleiding voor harness ingenieurswerk Dit artikel benoemt de twee belangrijkste strategieën die worden gehanteerd: het behandelen van model en codering agent als een zwarte doos, zonder ze verder te analyseren, en het ontwerpen van de omgeving en hulpmiddelen rondom deze elementen. Zijn benadering verklaart tevens waarom een groot deel van de harness uiteindelijk neerkomt op gewone code.

De kwaliteitsnormen, procedures, geschiedenis van uitzonderingen en autoriteitssverhoudingen van een organisatie blijven onder het zichtvlak van wat een algemene model kan waarnemen. De harness brengt deze elementen naar voren als instructies voor het repository, toestemmingsregels en acceptatiecontroles. Elke goedgekeurde uitvoering kan de daaruit verkregen kennis weer terug invoeren in deze artefacten, in plaats van af te gaan op de volgende session om ze opnieuw te ontdekken.

Houd de prijsverlaging bij van het voorstel tot de acceptatie

Voor de hierboven gedefinieerde kortingsopdracht stelt model voor om te veranderen calculate_discount in src/checkout.py. Er gebeuren verschillende zaken voordat dat optreedt Het bewerken wordt beschouwd als vooruitgang:

1. De contextbouwer levert de taak, instructies voor het repository, relevante bestanden, eerdere tool results-gegevens, en het huidige plan.
2. De model stelt een voorstel voor. edit_file roepen met een pad en vervangingstekst.
3. De toolgrens (de harness-code tussen voorstel en uitvoering) valideert de argumenten, controleert het pad tegen de toegestane reikwijdte en vraagt om goedkeuring indien de operatie deze nodig heeft.
4. De runtime past de wijziging in de sandbox aan en geeft een gestructureerd resultaat terug.
5. De harness wordt uitgevoerd pytest tests/test_checkout.py, gevolgd door pnpm playwright test tests/checkout_discount.spec.ts, en leest beide exitcodes. De browsertest controleert de zichtbare korting van $8 op de vooraf ingestelde winkelwagen ter waarde van $80.
6. De harness bepaalt wat de resultaten betekenen. Een mislukte controle vormt een nieuwe context voor de volgende model ronde, terwijl een geslaagde uitvoering de taak tot kandidaat voor voltooiing maakt.
7. Een geslaagd resultaat wordt pas bewijs van voltooiing nadat de harness het commando, de exitcode en de versie van het geteste artefact in de trace heeft opgenomen.

In stap 2 is er geen enkel bestand veranderd. De harness kan dit afwijzen. ../../secrets.envEen destructieve opdracht vereist toestemming, of er moet een uitvoering worden gestopt wanneer het budget is uitgeput. Nadat de tests zijn uitgevoerd, leest de harness zelf de exitcodes ervan. De model kan zijn eigen wijziging niet als geslaagd markeren.

De trace moet de voorgestelde route en vervangende tekst weergeven, de beslissing met betrekking tot rechten, de bestanden die zijn veranderd, de geteste commit en beide resultaten van de commando’s. Een definitieve versie done Een bericht zonder die records bewijst niet dat deze wijziging de vereiste controles heeft doorstaan.

Bepaal waar elke regel wordt toegepast

Plaats tests/checkout_discount.spec.ts Binnen de normale programma-logica stuurt de harness het Playwright-commando naar de runtime, leest de uitvoercode ervan en weigert de uitvoering te beëindigen zolang deze mislukt. Een prompt kan de model eraan herinneren de test uit te voeren. Het kan de model echter niet tegenhouden om zonder bewijs succes te verklaren.

Andere regels zijn van toepassing op andere lagen:

Toolcontracten scheiden het voorstel van de toestemming af

De taak voor het aanbrengen van kortingen vereist alleen bestandswijzigingen en testcommando’s. Een API die een toestandsverandering ondergaat, heeft een andere manier van falen, dus gebruik voor deze sectie andere voorbeelden. Stel dat de agent kan oproepen create_test_order tegen een staging-orderdienst tijdens het opzetten van testgegevens. Dit hulpmiddel maakt deel uit van de acceptatiecontroles voor de discount-task niet. Het is hier nuttig omdat een timeout kan verhullen of de dienst inderdaad een bestelling heeft aangemaakt.

De grenzen van het hulpmiddel vereisen meer dan alleen een beschrijving in natuurlijke taal. Voor create_test_order, de harness heeft een contract nodig met:

• Gevalideerde argumenten, zodat ongeldige invoer vóór uitvoering wordt afgewezen
• Een gestructureerd resultaat zoals { "order_id": "123", "created": true }, zodat latere controles geen vrijvormige tekst hoeven te parseren
• een effectencategorie die aangeeft of de oproep alleen informatie ophaalt of een bestand, een database-record of een externe dienst wijzigt. Het registreert ook of het herhalen van de oproep veilig is. Deze label vertelt de harness of een automatische herprobeeractie werk kan dupliceren: het kan opnieuw proberen get_order_status wanneer de dienst deze zoekopdracht als alleen-lezen definieert, mag deze echter niet blindelings opnieuw proberen create_test_order omdat de eerste oproep mogelijk al een bestelling heeft aangemaakt
• een tijdslimiet- en herprobeerbeleid, zodat een verloren reactie geen oneindige reeks oproepen veroorzaakt
• een toestemmingsschijf die aangeeft welke goedkeuring vereist is. Het lezen van de status van de bestelling kan automatisch plaatsvinden, terwijl het aanmaken van een bestelling bevestiging kan vereisen

De beschrijving in natuurlijke taal is de tekst die wordt weergegeven aan de model. Hierin kan staan bijvoorbeeld: “Maak een testbestelling aan voor verificatie bij de afrekening.” Die zin helpt de model om te beslissen wanneer hij een voorstel moet doen. create_test_order. Het autoriseert de oproep niet. In dit voorbeeld valideert de MCP-client van de harness de argumenten, past zijn eigen regels toe en controleert hij de betrouwbaarheid van de server, de vereisten voor goedkeuring en de veiligheid bij herproberingen voordat er iets wordt verstuurd.

Een MCP-server publiceert beschrijvingen van hulpmiddelen en optionele annotaties over het gedrag naar de client. Een defecte of kwaadaardige server zou een hulpmiddel dat een toestandsverandering teweegbrengt kunnen beschrijven als onschadelijk. Als de client die bewering automatisch accepteert, kan dit ertoe leiden dat het hulpmiddel wordt uitgevoerd of opnieuw wordt geprobeerd. create_test_order zonder toestemming een duplicaat aanmaken, waardoor de MCPspecificatie vereist dat klanten dit behandelen Toonnotaties als onbetrouwbaar tenzij de server zelf betrouwbaar is.

De specificaties voorschrijven geen enkele universele instelling voor vertrouwen. Daarom heeft de client een expliciete vertrouwenspolitiek nodig voor zijn deployment; een server kan zijn eigen annotaties niet automatisch betrouwbaar maken. Deze politiek bepaalt welk metadata invloed mag uitoefenen op beslissingen met betrekking tot toestemmingen of herproberingen, en welke annotaties enkel adviserend van aard blijven.

Het opnieuw uitvoeren van een state-veranderende oproep vereist replay-protection

Een ernstiger probleem met herproberingen doet zich voor wanneer create_test_order Er wordt een bestelling aangemaakt, maar de bijbehorende HTTP-respons gaat verloren. De harness detecteert een tijdslimiet en kan niet bepalen of de server de aanvraag heeft afgerond. Het herhalen van de oproep kan leiden tot het maken van een tweede bestelling.

Een statusopvraag kan opnieuw worden geprobeerd wanneer de service deze als alleen-lezen definieert. Een creatieaanroep vereist bescherming, bijvoorbeeld via een idempotentie-sleutel: de client voegt een unieke verzoekidentificator toe, en de service retourneert het eerste resultaat in plaats van opnieuw een bestelling te creëren wanneer deze identificator opnieuw wordt gezien. Zonder deze bescherming moet de harness controleren of de bestelling al bestaat of om een menselijke beslissing vragen voordat er opnieuw wordt geprobeerd. AWS documenteert dit patroon in haar Gids voor idempotente API acties.

Voor acceptatie zijn onafhankelijke bewijzen noodzakelijk

Een succesvolle create_test_order De respons geeft slechts aan dat het hulpmiddel gegevens heeft teruggestuurd. Het bewijst echter niet dat een coderingsopdracht de tests heeft doorstaan. Mocht een latere browsertest afhankelijk zijn van de volgorde waarin de stappen worden uitgevoerd, dan moet harness het responsschema valideren en die test nog steeds uitvoeren voordat de codeverandering wordt geaccepteerd.

Sommige criteria kunnen niet worden teruggebracht tot een exitcode. Voor een aparte taak op het gebied van visueel ontwerp kan een nieuwe evaluator een weergegeven pagina of diagram vergelijken met een schriftelijke rubriek. Teams moeten controleren of evaluator overeenkomt met menselijke beoordelingen voordat ze dit gebruiken als afsluitingscontrolepunt.

Er is hulp nodig bij de migratie van een betalingsadapter

Wissel opnieuw van taak, maar blijf binnen het fictieve winkelrepository. De agent Nu moet de afrekeningsfunctie worden gemigreerd van de payment adapter versie 1 naar versie 2. Dit is het werk dat moet worden uitgevoerd. spans de checkout-handler, de betalingsclient, de configuratie en de tests, zodat deze langer meegaan dan één versie. model session.

Voor de eerste session zijn contextlimiet is bereikt, heeft deze al meerdere bestanden gewijzigd, een lokale betaling sandbox gestart en is vertrokken tests/payment_migration.spec.ts Er treedt een fout op. Die browseracceptatietest voert één betaling uit via adapter v2 en controleert de opgeslagen provider-ID. Een samenvatting van het gesprek kan de volgende model session informeren, maar het kan de sandbox niet opnieuw starten noch aantonen welke bestanden momenteel zijn gewijzigd.

De volgende session moet drie zaken herstellen:

Compacting vervangt oudere berichten door een kortere samenvatting zodat de huidige session kan doorgaan. Een voortgangsoverdracht noteert wat de volgende session nodig heeft: de huidige branch, gewijzigde bestanden, de laatste testopdracht en het resultaat, evenals de volgende onopgeloste stap. Als de oude conversatie verouderde aannames bevat, kan de harness een nieuwe model session starten op basis van die overdracht en de huidige werkruimte. Het vervangen van een gestopte worker en het herstellen van diens processen vormt een aparte runtime hersteloperatie.

Een kleine aanpassing in de documentatie heeft mogelijk geen van deze mechanismen nodig. Bij de migratie van betalingen is een overdracht noodzakelijk zodra het werk de grens van sessions overschrijdt, omdat de volgende model session zowel de werkomgeving als de status van de taak opnieuw moet opbouwen.

De experimenten van Anthropic met langdurige codering agents er werd tussen sessions gebruikgemaakt van de git-historie en een voortgangsbestand, terwijl later harness-ontwerprapport het scheidt de compressie van de overdracht in een nieuw context en rapporteert het extra orchestration, token gebruik en de benodigde wall time voor dergelijke overdrachten.

Gebruik traces om drie verschillende fouten van elkaar te onderscheiden

De volgende drie rijen zijn illustratieve trace schetsen, en geen gemeten uitvoeringsresultaten of output uit het bijbehorende laboratorium. Elke rij toont een andere fout, waardoor er ook een verschillende harness reactie optreedt.

Dit onderscheid is belangrijk omdat een 503 Dit zorgt er niet voor dat elke oproep veilig kan worden herhaald. De eerste rij is een alleen-lezen lookup. De tweede rij is een verzoek dat de staat wijzigt, waardoor de idempotentie-sleutel en de status aan de server bepalen of een nieuwe creatiepoging is toegestaan. De derde rij is helemaal geen fout van het hulpprogramma; de harness heeft nog geen bewijs verzameld dat nodig is om de prijsverlaging te accepteren.

Een chattranscript legt vast wat de model heeft waargenomen. Het kan niet aantonen of de bestelingsdienst een verzoek heeft verwerkt voordat het antwoord verdween. De trace moet worden gecombineerd met de clientcall, de goedkeuringsbeslissing, de idempotentiekey, het serverresultaat of de statusopvraag, de geteste commit en het resultaat van de acceptatietest. Deze velden geven de harness aan op welke van de drie mogelijke paden hij zich bevindt.

Voordat u een component toevoegt, geeft u de herhaalde fout die deze moet verminderen en het getal dat u gaat bijhouden een naam. Verwijder de component indien een gecontroleerde vergelijking dit getal niet voldoende verandert om de kosten ervan te dekken.

Meet één verandering tegelijk

Een ablatie meet of een harness-component de gewenste werking veroorzaakt, door die component te wijzigen of te verwijderen terwijl de rest van het experiment onveranderd blijft. Bijvoorbeeld: helpt linting door een editor bij deze model in dit takenpakket?

Gebruik het volgende protocol:

1. Vries de model-versie, de taakinstanzen, de omgeving, de grader en prompts buiten het te testen component in.
2. Geef beide varianten dezelfde totale token, tijd- en budgetlimieten.
3. Kies het aantal pogingen of de stopregel voordat je de vergelijking uitvoert.
4. Voer dezelfde taakinstanzen uit in beide varianten. Omdat de uitvoer van model varieert, moet elke taak meerdere keren worden herhaald.
5. Rapporteer de gemiddelde waarde samen met de spreiding of het betrouwbaarheidsinterval.
6. Tel elk gestart experiment, inclusief tijdsverloop, stoppen vanwege beleid, harness-crashes en evaluator-falen.

Alleen de succesratio kan een dure component verhullen. Houd op zijn minst bij welke gebroken taken als voltooid worden geregistreerd, de kosten en de tijd die per voltooide taak nodig is, fouten in de tools, dubbele bestellingen, de tijd die nodig is voor reviews, en handmatige wijzigingen van toestemmingen. Kies de metric die de werkelijke kosten voor het product weergeeft. Een stijging van twee punten in het aantal voltooide taken is een slechte ruil als dit resulteert in een verdubbeling van de wachtrij voor reviews.

Een gepaard experiment voor betalingsmigratie maakt het mogelijk om de voortgangsoverdracht te meten. Elk paar bestaande uit een controlegroep en een behandeling begint bij dezelfde repository-commit en wordt geïnitialiseerd met checkpoint, dezelfde model, taak, beoordelaar en totale budget. De overdracht vormt de enige schakel. De belangrijkste metriek telt dubbele toolacties na het hervatten van de uitvoering: een actie wordt als duplicaat beschouwd wanneer de uitvoering en het resultaat overeenkomen met een stap die de vorige session al had voltooid.

De SWE-artikel over agent Het verbetert de prestaties van GPT-4 Turbo op de 300-taakset van de SWE-bench Lite en rapporteert een oplossingspercentage van 18,0% wanneer de volledige interface wordt gebruikt, vergeleken met 11,0% bij gebruik alleen van de shell agent. In het artikel zijn ook afzonderlijke functies van de interface aangepast:

Deze cijfers hebben betrekking op die model, benchmark, en het limiet van $4 per taak. without linting, full file, en full history De rijen vertegenwoordigen de nuttige één-eigenschaps-tests: bij elk test werd één specifieke interface-eigenschap gewijzigd, terwijl de model en de evaluatie-instellingen onveranderd bleven.

LangChain heeft een uitgebreidere versie gepubliceerd vaste model-vergelijking voor deepagents-cli. Het rapporteert een stijging volgens Terminal-Bench 2.0 van 52,8% naar 66,5%. gpt-5.2-codex De fout is verholpen nadat het team de system prompt, de hulpmiddelen en het middleware heeft aangepast. De publicatie bevat meerdere wijzigingen tegelijk en mist een betrouwbaarheidsinterval, een vergelijking van het totale budget na correctie, evenals een tabel met de effecten van elke afzonderlijke wijziging. Hierdoor kan niet worden vastgesteld welke wijziging daadwerkelijk nuttig is.

Anthropic’s Rapport over een langlopende applicatie Het betreft een kwalitatieve, productspecifieke casestudy in plaats van een gecontroleerd benchmark experiment. Tijdens Sprint 3 werden er 27 criteria voor level-editing geverifieerd met behulp van de evaluator. Het team rapporteert dat evaluator-aanroepen overhead vormden voor taken die Opus 4.6 zelfstandig en betrouwbaar kon uitvoeren, maar toch nog van nut waren bij het benaderen van de grenzen van de model. Daarom werden na de model-upgrade de harness-componenten één voor één verwijderd. Dit voorbeeld dient als reden om oude infrastructuur opnieuw te evalueren wanneer er model-veranderingen optreden; het geeft echter geen indicatie van de algemene effectgrootte.

Zorg ervoor dat de harness blijvend bewerkbaar is nadat deze zijn plek heeft gevonden

Ablatie behoudt een harness klein, maar de bijbehorende code kan desondanks langer meegaan dan model het was afgestemd op. Een verzoek zoals “verberg geheime gegevens in elke capture-path” geeft een gedrag aan, niet een bestand. In een productieomgeving harness, dat gedrag kan span Uitvoering fasen en gedeelde toestand. Een mens of codering agent Het is noodzakelijk om alle implementaties van de site te vinden voordat deze veilig gewijzigd kan worden.

Een preprint uit 2026 van Wang et al., de Harness Handleiding, Deze stap wordt behavior localization genoemd. Het handboek maakt een op gedrag gerichte kaart aan op basis van de harness codebase. Door statische analyse wordt een programma-grafiek verkregen zonder model aanroepen, waarna een LLM de verschillende onderdelen hiervan organiseert in uitvoeringsfasen.

De onderhouder of programmeur die agent uitvoert, begint met een overzicht van het systeem, opent de desbetreffende uitvoerfase en gaat vervolgens verder naar brongebonden gegevens voor een functie of bestand. Een registerweergave noteert waar gedeelde toestanden tussen de verschillende fasen worden geschreven en gelezen. Deze hiërarchie zorgt ervoor dat het overzicht compact blijft, terwijl er toch een pad naar de bron wordt behouden.

Frisheid is een aparte regel. Elke locator moet worden gevalideerd tegen de live repository. Het handboek sluit verouderde entries uit in plaats van te gissen, en elke niet-lege diff synchroniseert opnieuw de entries die worden beïnvloed.

Het diagram vereenvoudigt de modificatieronde: een verzoek dat enkel betrekking heeft op het gedrag daalt de verschillende niveaus van het handboek af; elke mogelijke locatie wordt gecontroleerd tegenover de actuele repository voordat het plan wordt opgesteld, en iedere toegepaste diff zorgt voor her-synchroonstelling van de kaart.

De Evaluatie van het handleiding houdt zich aan het protocol dat in dit artikel wordt verdedigd. Op twee open-source frameworks (Terminus-2, zes Python-bestanden en het Codex monorepo met 2.267 Rust-bestanden) onderzocht een alleen-lezen planner, aangedreven door DeepSeek-V4-Pro, ofwel de repository rechtstreeks of via het handleidingssysteem. De verzoeken, repository-toegangsrechten, hulpprogramma-permissies en de decodificeringsprocedure waren in beide gevallen identiek. Drie judges-modellen (GPT-5.5, Opus 4.8, DeepSeek-V4-Pro) beoordeelden elk editieplan op basis van localisatie, scopebeheer en reasoning:

Het door een handleiding ondersteunde planner leverde vaker succes op en maakte minder gebruik van planner tokens in beide repositories. De voorwaarden blijven van toepassing op dit resultaat: drie LLM judges gecorrigeerde editplannen die zijn gegenereerd door één planner model op twee harnesses. De studie beoordeelde de plannen, maar niet de daadwerkelijk uitgevoerde verschillen of de percentages productiefouten.

De eerdere secties maken gebruik van traces om uit te leggen waarom een component bestaat. Deze kaart beantwoordt de volgende vraag: waar bevindt zich die component wanneer deze moet worden aangepast?

Probeer de methode in het bijbehorende laboratorium uit

De harness – demo-project bij de commit 517353f3 het is een klein, deterministisch oefening met 12 generieke synthetische taken die codeveranderingen zoals fix-parser-edge-case, split-large-module, en wire-browser-test. Het implementeert het fictieve store-repository niet.

Elk taakfixuur specificeert een moeilijkheidsgraad plus vier booleaanse voorwaarden: een onbetrouwbare tool, verloren voortgang, een gemiste implementatiekloof en een vage voltooiingsstatus. De simulator leidt voor moeilijke taken die ook een voortgangsbestand vereisen, een vijfde voorwaarde af: zonder context_resetCompressie behoudt verouderde aannames. Een deterministische beoordelaar markeert een taak als voltooid alleen wanneer de geselecteerde configuratie elke van toepassing zijnde voorwaarde kan verwerken. Er wordt geen model of externe dienst uitgevoerd.

De commando’s beantwoorden verschillende vragen:

• make check Voert Ruff en zeven eenheidstests uit, inclusief de validator die elke ablatie‑pair weigert die meer dan één component wijzigt. make run Het genereert een cumulatieve onderwijzmatrix, gevolgd door vijf geldige vergelijkingen waarbij één component wordt weggelaten. make failures geeft de onverwerkte oorzaak aan voor elke mislukte taak. De volledige harness moet eindigen met all synthetic tasks pass.

make check
make run
make failures

Het causale gedeelte van make run Ziet er zo uit:

component                 control  treatment  delta
retry_policy              8/12     12/12       +4
progress_handoff          7/12     12/12       +5
evaluator                 8/12     12/12       +4
fail_closed_acceptance    7/12     12/12       +5
context_reset            10/12     12/12       +2

Voor elke rij staat de controlegroep voor de volledige configuratie waarbij één component is verwijderd; de behandeling herstelt alleen die ene component. De eerdere cumulatieve matrix is nuttig voor oriëntatie, maar sommige aangrenzende rijen voegen meerdere componenten tegelijk toe, waardoor er geen oorzaak kan worden vastgesteld.

Het laboratorium valideert elk gedeclareerd paar voordat het wordt uitgevoerd. De regressietests omvatten daarnaast ook opzettelijk een ongeldig paar dat zowel de herprobeerbeleid als evaluator tegelijkertijd wijzigt; de validator wijst dit af.

Het configuratieschema van het laboratorium controleert alle vijf de componentenvelden. Dit uitvoerbare fragment toont dezelfde beveiligingscontrole voor een geldig paar voor het overdragen van voortgang:

from dataclasses import dataclass, fields


@dataclass(frozen=True)
class Config:
    progress_handoff: bool = False
    evaluator: bool = False
    retry_policy: bool = False
    fail_closed_acceptance: bool = False
    context_reset: bool = False


def changed_components(control: Config, treatment: Config) -> tuple[str, ...]:
    return tuple(
        field.name
        for field in fields(control)
        if getattr(control, field.name) != getattr(treatment, field.name)
    )


control = Config(progress_handoff=False, evaluator=True, retry_policy=True)
treatment = Config(progress_handoff=True, evaluator=True, retry_policy=True)
assert changed_components(control, treatment) == ("progress_handoff",)

Begin met één lus en één acceptatiecontrole

Ik zou een coderingsproject agent harness starten met één capabele model-repository, instructies, enkele gespecialiseerde hulpmiddelen, een sandbox, en één expliciete acceptatietest. Ik zou de tool calls-resultaten, kosten en die finale test opslaan in één trace, zodat de eerste bruikbare fouten direct zichtbaar zijn, zonder dat deze opnieuw moeten worden gereconstrueerd uit terminallogs en chattranscripten. Dit is een voorgesteld basisniveau, geen bewijs afkomstig uit een geïmplementeerd systeem.

Voeg vanaf daar alleen toe wat een trace rechtvaardigt. Noteer wie elke component onderhoudt, hoeveel tokens of seconden deze toevoegt, en welke regressietest het mogelijk maakt om hem na een model-upgrade te verwijderen.

Zes maanden later, iemand die het ziet progress_handoff=True Het moet in staat zijn om het mislukte traces te vinden dat de oorzaak vormde, evenals de regressiecases die dit nog steeds in stand houden. De traces leggen uit waarom het component bestaat; een actuele gedragskaart geeft aan waar er aan gewerkt moet worden.

Referenties

• OpenAI, Het ontvouwen van de Codex agent loop.
• OpenAI, Harness engineering: het benutten van Codex in een agent-georiënteerde omgeving.
• Lopopolo, Harness engineering: antologie, veldgids en agent-contextbundel.
• Anthropic Engineering, Doeltreffende hulpmiddelen voor langlopende agents.
• Anthropic Engineering, Harness ontwerp voor de ontwikkeling van langlopende applicaties.
• LangChain, Het verbeteren van Deep Agents met harness engineering.
• Yang et al., SWE-agent: Agent – Computerinterfaces maken geautomatiseerde softwareontwikkeling mogelijk.
• Wang et al., Harness Handleiding: Het maken van evoluerende Agent harnesses die leesbaar, navigeerbaar en bewerkbaar zijn, arXiv:2607.13285, 2026.
• AWS, Herproberingen veilig maken met idempotente acties APIs.
• Model Contextprotocol, Specificaties voor de tools.

Reeks: Het ontwerpen van de Agentic-stack

• Deel 1: AI Agent Reasoning Lussen in 2026: ReAct, ReWOO en Plan-en-Execute Deel 2: AI Agent Memory Architectuur in 2026: checkpoints, vector stores, en documentatiegeheugen Deel 3: AI Agent Tool Use in 2026: MCP, CLI, vaardigheden, uitvoering van code en ACI
• Deel 4: AI Agent Beveiliging in 2026: guardrails, rechten, sandboxes, HITL, en MCP scopebepaling Deel 5: Langdurig draaiende AI Agent Runtime in 2026: sessions, sandboxes, checkpoints, hulpmiddelen en deployment vormen
• Deel 6: Harness Engineering voor AI Agents (dit artikel)