Harness vs context engineering: paano naiiba ang harness engineering sa prompt at context engineering

Maikling buod: tatlong antas ng iisang problema

Sinasagot ng prompt engineering ang tanong na «paano hihingin», sinasagot ng context engineering ang «ano ang kailangang malaman ng modelo ngayon», at sinasagot ng harness engineering ang «sa anong kapaligiran nagtatrabaho ang agent at paano nito nalalamang nagkamali ito». Hindi sila magkakalaban na pamamaraan kundi magkakasunod na antas: ang magandang prompt ay bahagi ng magandang context, at ang maingat na dinisenyong context ay isa sa mga subsystem ng harness.

Nagkakalito dahil pare-pareho ang tatlo sa pagbabago ng kilos ng modelo, pero magkakaiba ang kanilang pingga. Kung hindi makapagpatakbo ng test ang agent, walang pagbabago sa pagkakasulat ng prompt na makakaayos nito. Kung nakakalimutan ng agent ang mga desisyon kahapon, hindi ang mga salita ng kahilingan ang problema kundi kung saan nakaimbak ang estado. Ang pag-unawa sa pagkakaiba ng harness vs context engineering ay nakakatipid ng ilang linggo, dahil titigil ka sa muling pagsusulat ng mga tagubilin kung saan sira ang kapaligiran.

Prompt engineering: paano isusulat ang iisang request

Ang prompt engineering ay gawain sa teksto ng request: papel, gawain, format ng sagot, halimbawa (few-shot), mga limitasyon, at pagkakasunod-sunod ng mga hakbang. Ang yunit ng trabaho ay iisang tawag sa modelo. Sinusuri ang resulta batay sa sagot: tama ba ito, nasa tamang format ba, at hindi ba lumihis ang modelo.

Mga karaniwang pamamaraan:

• ilarawan nang tahasan ang format ng output (JSON schema, talahanayan, listahan);
• magbigay ng 2–3 halimbawang «input → tamang output»;
• hilinging mangatwiran nang hakbang-hakbang bago sumagot;
• paghiwalayin ang tagubilin at datos gamit ang malinaw na delimiter;
• ilista ang mga bagay na hindi dapat gawin.

Maayos ang prompt engineering para sa gawaing «isang input, isang output»: klasipikasyon, pagkuha ng datos, pagsasalin, pagbuo ng teksto ayon sa template. Nakikita ang limitasyon nito kapag nagsimulang kumilos ang modelo: tumawag ng kasangkapan, magbago ng mga file, magtrabaho nang dose-dosenang hakbang nang sunud-sunod. Doon, hindi na nakadepende ang kalidad sa iisang pangungusap, kundi sa lahat ng nakapalibot sa modelo.

Context engineering: anong impormasyon ang pumapasok sa window ng modelo

Ang context engineering ay pamamahala ng nilalaman ng context window sa bawat hakbang. Limitado ang window, at ang agent sa mahabang session ay nag-iipon ng output ng command, nilalaman ng file, at kasaysayan ng usapan. Ang layunin ay magkaroon ng tamang impormasyon sa bawat sandali at walang sobra.

Kabilang dito ang:

• pagpili: aling mga file, dokumento, at code snippet ang ilo-load para sa gawain (search, RAG, pagbasa kapag kailangan);
• pag-compress: pagbubuod ng mahabang kasaysayan, pagputol ng mahabang output ng command, pag-compact ng session;
• istruktura: ang file ng tagubilin ang nagsisilbing talaan ng nilalaman, habang nasa hiwalay na dokumento ang detalye na binubuksan ng agent kapag kailangan;
• isolation: paglilipat ng subtask sa subagent na may sariling malinis na context para hindi madumihan ang pangunahing daloy.

Ang sukatan ng context engineering ay kung nakita ba ng agent ang tamang tuntunin o impormasyon sa tamang sandali, at kung hindi ba ito nalunod sa ingay. Karaniwang sintomas ng problemang ito ang tuntuning nakasulat sa CLAUDE.md pero nilalabag pa rin ng agent, dahil limang pahina ang file at nawala ang tuntunin sa gitna ng tono ng pananalita at mga gawi ng team lead.

Harness engineering: lahat ng nakapalibot sa modelo

Ang harness («pang-gabay na kagamitan») ang kapaligiran kung saan nagtatrabaho ang agent. Isa lang ang modelo sa loob nito, na pumapasok sa loop nang isang beses. Lahat ng iba, ang mga tagubilin, kasangkapan, kapaligiran, estado, at feedback, ay dinisenyo ng inhinyero. Tinitiyak ng harness engineering na hindi lang nakakasulat ng code ang agent kundi nakakapagpatakbo rin nito, nakakapag-verify, nalalaman ang pagkakamali, at nakapagpapatuloy sa susunod na session mula sa parehong punto.

Maaaring hatiin ang harness sa limang subsystem:

Sa ganitong pagkakaayos, nasa loob ng unang dalawang subsystem ang context engineering: ito ang nagpapasya kung paano pumapasok sa window ang mga tagubilin at output ng kasangkapan. Dinadagdagan naman ng harness ang hindi maisisiksik sa context: gumaganang command sa verification, mauulit na kapaligiran, at file ng estado na nakaliligtas sa mga restart.

Talaan ng paghahambing

Bakit hindi sapat ang prompt at context lang

Klasikong kuwento: nakita ng team na nagkakamali ang agent kaya gumugol ito ng isang linggo sa pagsulat ng limang-pahinang AGENTS.md. Hindi pa rin nagpapatakbo ng linter ang agent bago mag-commit. Hindi nakasalalay ang sanhi sa teksto: walang shell ang agent na may kinakailangang pahintulot, at hindi naka-install ang linter sa image. Problema ito ng mga kasangkapan at kapaligiran, pero tinangkang ayusin sa pamamagitan ng mga tagubilin.

Ikalawang kuwento: sinubukan ng agent na ayusin ang iisang bug sa tatlong magkakasunod na session, dahil pagkatapos ng restart ay hindi nito naalala ang nasubukan na. Hindi makakatulong ang context engineering sa loob ng session, dahil nabura na ang window. Kailangan ng subsystem ng estado: isang file kung saan isinusulat ng agent ang mga pagsubok at desisyon, at ang tuntunin na basahin ito sa simula ng trabaho.

Ikatlong kuwento, ang pinakamahal: sinabi ng agent na «tapos na», berde ang lahat ng unit test, pero hindi gumagana ang feature. Walang prompt na «suriing mabuti» at walang karagdagang dokumento sa context na makapagbibigay sa agent ng independiyenteng verification. Tanging feedback mula sa makina ang makakagawa nito: end-to-end test, verification script, o hiwalay na tagasuri na walang access sa pangangatwiran ng gumagawa.

Ang kabuuang konklusyon: nakakaapekto ang prompt at context sa iniisip ng modelo. Nakakaapekto ang harness sa kung ano ang kaya nitong gawin at kung ano ang nalalaman nito pagkatapos kumilos.

Bakit hindi nalulutas ng pagpapalit ng modelo

Karaniwang reaksyon sa hindi matatag na agent ang kumuha ng mas malakas na modelo. Kadalasan hindi ito nakakaayos ng problema: ang parehong modelo sa maayos na repository ay kumikilos na parang tiwalang senior, pero sa repository na walang command sa verification at walang deskripsyon ng stack, nalilito ito. Hindi huhulaan ng mas malakas na modelo ang mga kaugalian ng iyong team, hindi ito bibigyan ng access sa database na hindi ibinigay, at hindi nito malalaman na sira ang migration kung walang nagpatakbo nito.

Hindi rin nagiging luma ang harness sa paglabas ng bagong modelo. Kailangan pa rin ng mga tagubilin, mauulit na kapaligiran, at verification ng bawat modelo. Ang nagbabago lang ay kung gaano karaming micromanagement ang maaaring alisin: sapat na sa malakas na modelo ang mga invariant («ang data ay bina-validate sa hangganan ng domain»), hindi kailangan ang hakbang-hakbang na tagubilin.

Paano malalaman kung aling antas ang aayusin

Mas mabilis ang diagnosis mula sa sintomas kaysa sa anumang eksperimento:

Saan magsisimula sa harness

Kung bubuo mula sa simula, praktikal ang ganitong pagkakasunod: feedback → mga tagubilin → estado → kapaligiran → mga kasangkapan. Nauuna ang feedback dahil kung wala ito, hindi masusukat ang epekto ng iba pang pagbabago. Kapag walang command na tapat na nagsasabi kung «gumagana ba o hindi», sa pakiramdam lang susuriin ang bawat pagpapabuti ng mga tagubilin.

Ganito ang pinakamaliit na panimula:

# AGENTS.md (bahagi)
## Paano mag-verify
- make check   # lint, type, unit tests
- make e2e     # mga end-to-end na senaryo
Tapos lang ang feature kapag parehong nagtapos ang command nang may code 0.

## Mga tuntunin
- MUST: lahat ng SQL query ay parameterized
- MUST: bago mag-commit, patakbuhin ang make check
- Detalye sa pagbabayad: docs/payments.md (basahin kapag may kinalaman sa pagbabayad ang gawain)

Pansinin ang huling linya: ito ang context engineering sa loob ng harness. Mapa ang entry file, hindi textbook; ikinakarga ang mga detalye ayon sa kondisyong «kailan».

Paano sukatin ang ambag ng bawat bahagi

May sukatan ang harness na wala sa prompt: ang proporsyon ng mga gawaing idineklara ng agent na tapos na pero hindi kinumpirma ng independiyenteng pagsusuri. Tinatawag itong verification gap. Kumuha ng 10 gawaing magkakasunod, at pagkatapos ng bawat isa, itala kung sinabi ng agent na «tapos na» at kung pumasa ang verification. Makakakuha ka ng numerong maihahambing sa mga pagbabago.

Para malaman kung aling subsystem ang nagbibigay ng epekto, ginagamit ang ablation: pirmihan ang modelo at set ng gawain, pagkatapos ay i-disable ang isang bahagi ng harness nang paisa-isa at tingnan ang pagbaba. Dalawang bagay ang dapat tandaan. Huwag magsimula sa ablation kundi sa failure log: ang pag-label kung aling layer ang bumagsak ay mas mabilis magturo ng bottleneck. At ang hindi pagbaba ay hindi nagpapatunay na walang silbi ang bahagi: maaaring hindi ito ginagamit ng napiling set ng gawain.

Mga karaniwang pagkakamali

• Pag-aakalang harness ang file ng prompt. Isa lang sa limang subsystem ang mga tagubilin. Ang istanteng may resipe ay hindi pa kusina.
• Pag-aayos ng kakulangan sa kasangkapan gamit ang teksto. Walang saysay ang «laging patakbuhin ang test» kung hindi tumatakbo ang test sa kapaligiran ng agent.
• Pamamaga ng mga tagubilin. Mas mataas ang tsansang hindi mabasa ang mahalagang tuntunin kapag mas mahaba ang entry file. Mas mainam gawing executable na pagsusuri ang mahahalagang tuntunin.
• Pagtitiwala sa sariling ulat ng agent. Madalas lumaki ang pagtatasa ng modelo sa sarili nitong gawa. Ang tagasuri ay dapat script o hiwalay na agent na may malinis na context.
• Pag-setup ng harness nang isang beses lang. Tumatanda ito tulad ng code: lumalayo ang mga tuntunin sa realidad at nagbabago ang mga command. Kailangang regular itong suriin.

Buod

Pinapabuti ng prompt engineering ang pagkakasulat, pinipili ng context engineering ang impormasyong pumapasok sa window ng modelo, at binubuo ng harness engineering ang buong kapaligiran ng agent, kabilang ang mga kasangkapan, kapaligiran, estado, at verification. Kapag mahaba ang gawain ng agent at ito mismo ang nagbabago ng code, ang harness ang nagiging mapagpasya: ginagawa nitong «sinabi ng agent na tapos na» ang «na-verify ng sistema na gumagana». Kaya sa usapin ng harness vs context engineering, hindi ito pagpili ng isa: bahagi ng harness ang context, at ang subsystem na itinuturo ng sintomas ang dapat ayusin. Tinatalakay nang praktikal ang paksang ito sa kursong harness engineering sa isang totoong proyekto ng payment backend.