Harness dhidi ya context engineering: tofauti kati ya harness, prompt na context engineering

Kwa ufupi: ngazi tatu za kazi moja

Prompt engineering inajibu «unawezaje kuomba», context engineering inajibu «modeli inahitaji kujua nini sasa hivi», na harness engineering inajibu «wakala anafanya kazi katika mazingira gani na anajuaje kwamba amekosea». Hizi si mbinu zinazoshindana, bali ngazi zinazokaa ndani ya nyingine: prompt nzuri ni sehemu ya context nzuri, na context iliyopangwa vizuri ni mojawapo ya vipengele vya harness.

Mkanganyiko unatokea kwa sababu zote tatu hubadilisha tabia ya modeli. Lakini vishikio vyake ni tofauti. Ikiwa wakala hawezi kuendesha majaribio, hakuna maneno ya prompt yatakayorekebisha hilo. Ikiwa wakala anasahau maamuzi ya jana, tatizo si maneno ya ombi, bali mahali hali inapohifadhiwa. Kuelewa tofauti ya harness dhidi ya context engineering kunaokoa wiki: unaacha kuandika upya maelekezo mahali ambapo mazingira yamevunjika.

Prompt engineering: maneno ya ombi moja

Prompt engineering ni kazi na maandishi ya ombi: nafasi, kazi, muundo wa jibu, mifano (few-shot), mipaka na mpangilio wa hatua. Kitengo chake cha kazi ni wito mmoja wa modeli. Matokeo hupimwa kwa jibu: je ni sahihi, je muundo unafaa, je modeli imepotea njia.

Mbinu za kawaida ni:

• kueleza muundo wa matokeo waziwazi (schema ya JSON, jedwali, orodha);
• kutoa mifano 2–3 ya «ingizo → matokeo sahihi»;
• kuomba hoja hatua kwa hatua kabla ya jibu;
• kutenganisha maelekezo na data kwa vitenganishi wazi;
• kuorodhesha ambacho hakipaswi kufanywa.

Prompt engineering inafanya kazi vizuri kwa kazi za «ingizo moja — jibu moja»: kuainisha, kutoa data, kutafsiri, kuandika maandishi kwa kiolezo. Mipaka yake huonekana modeli inapoanza kutenda: kuita zana, kubadilisha faili, kufanya hatua kadhaa mfululizo. Hapo ubora hautegemei sentensi moja tena, bali kila kinachozunguka modeli.

Context engineering: kinachoingia kwenye dirisha la modeli

Context engineering ni usimamizi wa yaliyomo kwenye dirisha la muktadha katika kila hatua. Dirisha lina ukomo, na wakala katika kikao kirefu hukusanya matokeo ya amri, yaliyomo ya faili na historia ya mazungumzo. Lengo: wakati wowote, dirishani kuna kinachohitajika tu, na hakuna ziada.

Inajumuisha:

• uteuzi: faili, nyaraka na vipande vya msimbo vipi vipakiwe kwa kazi (utafutaji, RAG, kusoma inapohitajika);
• ufupishaji: muhtasari wa historia ndefu, kukata matokeo ya amri, kubana kikao;
• muundo: faili la maelekezo kama faharasa, na maelezo ya kina katika nyaraka tofauti ambazo wakala hufungua inapozihitaji;
• kutenga: kuhamisha kazi ndogo kwa subagent yenye muktadha wake safi, ili mtiririko mkuu usichafuke.

Kipimo cha context engineering ni kama wakala alipata kanuni au taarifa sahihi kwa wakati unaofaa, na kama hakuzama katika kelele. Dalili yake ya kawaida: kanuni imeandikwa kwenye CLAUDE.md, lakini wakala anaikiuka, kwa sababu faili lina kurasa tano na kanuni imepotea kati ya sauti ya maandishi na mitindo anayoipenda kiongozi wa timu.

Harness engineering: kila kinachozunguka modeli

Harness («kamba ya kuongoza») ni mazingira ambamo wakala anafanya kazi. Ndani yake modeli ni sehemu moja, inayoingia kwenye mzunguko mara moja. Kila kingine — maelekezo, zana, mazingira, hali na maoni — kinabuniwa na mhandisi. Harness engineering inahakikisha wakala hawezi tu kuandika msimbo, bali pia kuuendesha, kuukagua, kujua makosa yake, na kuendelea kazi kwenye kikao kijacho pale pale alipoishia.

Harness inaweza kugawanywa kwa urahisi katika vipengele vitano:

Katika mpangilio huu, context engineering inaishi ndani ya vipengele viwili vya kwanza: inaamua jinsi maelekezo na matokeo ya zana yanavyoingia dirishani. Harness inaongeza kile ambacho hakiwezi kuwekwa kwenye muktadha: amri ya uthibitishaji inayofanya kazi, mazingira yanayoweza kuzalishwa upya, na faili la hali linaloishi hata baada ya kuanzishwa upya.

Jedwali la ulinganisho

Kwa nini prompt na context pekee hazitoshi

Hadithi ya kawaida: timu inaona wakala anakosea mara nyingi na inatumia wiki nzima kuandika AGENTS.md ya kurasa tano. Wakala bado hakimbii linter kabla ya commit. Sababu si maandishi: wakala hana ufikiaji wa shell wenye ruhusa zinazohitajika, na linter haijawekwa kwenye image. Hili ni tatizo la zana na mazingira, lakini lilirekebishwa kwa maelekezo.

Hadithi ya pili: wakala anarekebisha hitilafu ile ile kwa mara ya tatu, kwa sababu baada ya kuanzishwa upya hakumbuki alichojaribu. Context engineering ndani ya kikao haisaidii hapa: dirisha linafutwa. Kinachohitajika ni kipengele cha hali — faili ambamo wakala anaandika majaribio na maamuzi, na kanuni ya kulisoma mwanzoni mwa kazi.

Hadithi ya tatu ndiyo ghali zaidi: wakala anaandika «imekamilika», majaribio ya kitengo ni ya kijani, lakini kipengele hakifanyi kazi. Hakuna prompt ya «kagua kwa makini» wala hati za ziada kwenye muktadha zitakazompa wakala ukaguzi huru. Ukaguzi huo unatoka tu kwa maoni ya mashine: jaribio la mwisho-hadi-mwisho, skripti ya uthibitishaji, au mkaguzi tofauti asiyefikia hoja za mtekelezaji.

Hitimisho la jumla: prompt na context vinaathiri kile modeli inachofikiri. Harness inaathiri kile modeli inachoweza kufanya na kinachojua baada ya kutenda.

Kwa nini kubadilisha modeli hakusaidii

Mwitikio wa kawaida kwa wakala asiye imara ni kuchukua modeli yenye nguvu zaidi. Kwa kawaida hii haitatui tatizo: modeli ile ile katika hazina iliyopangwa vizuri hufanya kazi kama mkubwa anayejiamini, lakini katika hazina isiyo na amri za uthibitishaji na maelezo ya stack inachanganyikiwa. Modeli yenye nguvu zaidi haitakisia makubaliano ya timu yako, haitapata ufikiaji wa hifadhidata ambayo haipo, na haitajua migration imevunjika ikiwa hakuna aliyeiendesha.

Harness pia haipitwi na wakati kwa kutoka kwa modeli mpya. Maelekezo, mazingira yanayoweza kuzalishwa upya na uthibitishaji vinahitajika na modeli yoyote. Kinachobadilika ni kiasi cha usimamizi wa mkono unaoweza kuondolewa: modeli yenye nguvu inahitaji invariants tu («data inathibitishwa kwenye mpaka wa kikoa»), si maelekezo ya hatua kwa hatua.

Jinsi ya kujua ngazi gani irekebishwe

Utambuzi kwa dalili ni wa haraka zaidi kuliko majaribio yoyote:

Anza harness wapi

Ukijenga kuanzia mwanzo, mpangilio wa vitendo ni: maoni → maelekezo → hali → mazingira → zana. Maoni kwanza, kwa sababu bila hayo athari za mabadiliko mengine hazipimiki. Hadi kuwe na amri inayojibu kwa uaminifu «inafanya kazi au haifanyi», kila uboreshaji wa maelekezo unapimwa kwa hisia.

Mwanzo wa chini kabisa unaonekana hivi:

# AGENTS.md (sehemu)
## Jinsi ya kukagua
- make check   # lint, aina, majaribio ya kitengo
- make e2e     # hali za mwisho-hadi-mwisho
Kipengele kiko tayari tu amri zote mbili zikimaliza kwa msimbo 0.

## Kanuni
- MUST: maswali yote ya SQL yana vigezo
- MUST: kabla ya commit endesha make check
- Maelezo ya malipo: docs/payments.md (soma kazi inapogusa malipo)

Angalia mstari wa mwisho: huo ndio context engineering ndani ya harness. Faili la kuingilia ni ramani, si kitabu cha kiada; maelezo yanapakiwa kwa sharti la «lini».

Jinsi ya kupima mchango wa kila sehemu

Harness ina kipimo ambacho prompt haina: sehemu ya kazi ambazo wakala ameziita «zimekamilika» lakini ukaguzi huru haujathibitisha. Kipimo hicho huitwa verification gap. Chukua kazi 10 mfululizo, na kwa kila moja rekodi kama wakala alisema «imekamilika» na kama ukaguzi ulipita — utapata namba ya kulinganisha baada ya kila mabadiliko.

Ili kujua sehemu ipi ina athari, hutumika ablation: modeli na seti ya kazi zinabaki zilezile, kisha sehemu moja ya harness inazimwa na kushuka kwa ubora kunaangaliwa. Mambo mawili ya kukumbuka. Usianze na ablation, anza na kumbukumbu ya kushindwa: kuweka alama katika tabaka gani kitu kilivunjika kunaonyesha kizuizi haraka. Na kushuka kwa sifuri hakuthibitishi kwamba sehemu haina maana: huenda seti hii ya kazi haikuitumia kamwe.

Makosa ya kawaida

• Kuchukulia harness kama faili la prompt. Maelekezo ni sehemu moja kati ya tano. Rafu ya mapishi haifanyi jikoni.
• Kurekebisha ukosefu wa zana kwa maandishi. «Endesha majaribio kila mara» haina maana ikiwa majaribio hayawezi kuendeshwa katika mazingira ya wakala.
• Kupanua maelekezo kupita kiasi. Faili la kuingilia likiwa refu zaidi, ndivyo uwezekano wa kanuni muhimu kutosomwa unavyoongezeka. Geuza kanuni muhimu kuwa ukaguzi unaoweza kuendeshwa.
• Kuamini ripoti ya wakala mwenyewe. Modeli inayotathmini kazi yake yenyewe huelekea kuipandisha thamani. Ukaguzi ufanywe na skripti au wakala tofauti mwenye muktadha safi.
• Kusanidi harness mara moja na kuiacha. Kama msimbo, harness nayo inapitwa na wakati: kanuni zinatoka kwenye uhalisia, amri zinabadilika. Inahitaji kukaguliwa mara kwa mara.

Hitimisho

Prompt engineering huboresha maneno, context engineering huchagua taarifa dirishani, na harness engineering hujenga mazingira yote ya wakala, yakiwemo zana, mazingira, hali na ukaguzi. Wakala anapofanya kazi kwa muda mrefu na kubadilisha msimbo wake mwenyewe, harness ndiyo inayoamua: inageuza «wakala amesema imekamilika» kuwa «mfumo umethibitisha kwamba inafanya kazi». Kwa hiyo katika mjadala wa harness dhidi ya context engineering, hakuna chaguo la «au–au»: context ni sehemu ya harness, na sehemu ya kurekebisha inaonyeshwa na dalili. Mada hii inafundishwa kwa vitendo katika kozi ya harness engineering kupitia mradi kamili wa backend ya malipo.