Harness inžinerija: kas tai yra ir kaip ji veikia
Paprasta kalba parašytas vadovas apie tai, kas yra DI harness ir kaip harness inžinerija lemia, ką gali nuveikti DI agentai.

Ką reiškia harness inžinerija
Harness inžinerija – tai DI įrankio harness, t. y. visų įrankio dalių, išskyrus patį DI modelį, kūrimo darbas.
Modelis – tai DI sistema, apmokyta naudojant didelius teksto kiekius, kad galėtų skaityti ir rašyti tekstą. DI modelių pavyzdžiai – OpenAI kuriamas GPT, Anthropic kuriamas Claude ar Google kuriamas Gemini.
Pats savaime modelis gali tik priimti tekstą (kartais ir vaizdus ar garsą) ir atsakyti tekstu. Jis negali prisiminti ankstesnių pokalbių, ieškoti naujausios informacijos ar paleisti kodo. Todėl jam reikalingas harness, kuris valdo, kokią informaciją modelis gauna, kokias programas jis gali naudoti, ką jam leidžiama daryti ir kaip tikrinamas jo darbas.
Net paprastam pokalbių asistentui reikalingas harness. Modelis pamiršta kiekvieną apsikeitimą žinutėmis vos tik atsako, todėl harness saugo pokalbio įrašą. Jei kas nors paklausia apie Paryžių, o tada patikslina: „Koks jo gyventojų skaičius?“, harness abu klausimus modeliui siunčia kartu. Taip modelis supranta, kad „jo“ reiškia Paryžių.
Harness inžinerija – viena iš priežasčių, kodėl du tuo pačiu modeliu paremti įrankiai gali veikti taip skirtingai. Pavyzdžiui, viename nepriklausomame bandyme tyrėjai paliko tą patį modelį (GPT5) ir pakeitė tik harness, o modelio rezultatas programavimo teste pakito net iki 11 %.
DI modelių kūrėjai, tokie kaip Anthropic ir OpenAI, kuria harness savo DI produktams, pavyzdžiui, Claude Code ir Codex. O DI produktus kuriančios bendrovės projektuoja harness pasirinktiems baziniams modeliams. Dalį harness formuoja ir DI įrankių naudotojai. Daugelis įrankių leidžia pridėti nuolatinių instrukcijų, prijungti programas ir pasirinkti, kuriems veiksmams reikia jų patvirtinimo, prieš įrankiui juos atliekant.
Harness inžinerija DI agentams
Kiekvienas DI įrankis turi harness, tačiau harness inžinerija tampa ypač svarbi dirbant su DI agentais. Agentai savarankiškai atlieka kelių žingsnių užduotis, pavyzdžiui, tiria konkurentus ir surašo rezultatus į skaičiuoklę, o harness vykdo kiekvieną žingsnį. Todėl, jei harness suklysta, pavyzdžiui, paima praėjusių metų kainas, tai paveiks ir visus tolesnius žingsnius.
Dauguma agentų harness turi šešias pagrindines dalis:
1. Agento ciklas
Agento ciklas – tai harness kodas, kuris žingsnis po žingsnio stumia užduotį į priekį.
DI modelis nusprendžia, koks kitas žingsnis reikalingas užduočiai atlikti, ir parašo įrankio iškvietimą – trumpą užklausą, kurioje nurodomas harness įrankis, pavyzdžiui, interneto paieška, ir ką tas įrankis turėtų padaryti.
Harness pastebi užklausą, atlieka paiešką ir prideda rezultatus prie to, ką modelis mato. Modelis juos perskaito ir nusprendžia, ką daryti toliau.
2. Konteksto valdymas
Modelis bendrųjų žinių įgyja mokymo metu, tačiau šios žinios apsiriboja laikotarpiu iki mokymo pabaigos. Jose nėra nieko, kas būtų susiję su konkrečia užduotimi, pavyzdžiui, įmonės failų, šiandienos naujienų ar to, kas buvo pasakyta anksčiau pokalbyje.
Visa tai modelis gauna iš savo konteksto lango – teksto, kurį harness jam pateikia prieš kiekvieną atsakymą, pavyzdžiui, instrukcijų, užklausos, iki šiol vykusio pokalbio ir paieškos rezultatų.
Į langą telpa tik ribotas teksto kiekis. Be to, net dar langui neprisipildžius, modeliai kartais praleidžia informaciją, paslėptą ilgų įvesčių viduryje.
Todėl konteksto valdymu rūpinasi harness, atrinkdamas tik tą informaciją, kurios reikia kiekvienam žingsniui. Pavyzdžiui, jei užduotis – palyginti penkių konkurentų kainodarą, harness gali pateikti kiekvienos įmonės kainų puslapį, o ne visą jos svetainę. Atliekant ilgas užduotis, harness taip pat gali pakeisti išsamų ankstesnių žingsnių įrašą trumpa santrauka, kad modelis žinotų, ką jau padarė, o ta istorija neužpildytų lango.
3. Įrankiai
Įrankiai – tai kodas, atliekantis veiksmus, kurių prašo modelis. Kiekvienas įrankis atlieka vienos rūšies veiksmą, pavyzdžiui, ieško internete, atidaro ir skaito tinklalapį, paleidžia kodą ar redaguoja failą. Kai modelis parašo įrankio iškvietimą, harness perduoda jį tinkamam įrankiui ir grąžina rezultatą.
Daugelyje harness taip pat yra jungčių – įrankių, kurie, naudodami žmogaus suteiktą prieigą, susieja agentą su konkrečia programa, tokia kaip el. paštas, kalendorius ar bendrinamas diskas. Pavyzdžiui, naudodamas kalendoriaus jungtį, agentas gali patikrinti, ar žmogus laisvas, prieš pasiūlydamas susitikimo laiką.
4. Atmintis
Atmintis – tai saugoma informacija, perkeliama iš vienos sesijos į kitą. Sesijos metu harness išsaugo trumpas pastabas, pavyzdžiui, apie žmogaus pageidavimus ar projekto būklę. Kitos sesijos pradžioje harness prideda šias pastabas prie konteksto lango, todėl modelis jas perskaito prieš skaitydamas naują užklausą. Taip agentas, pavyzdžiui, gali tęsti savaitinę ataskaitą nuo ten, kur baigė, užuot vėl pradėjęs nuo pradžių.
5. Leidimai
Leidimai – tai taisyklės, nustatančios, ką agentas gali pasiekti ir daryti. Prieigos taisyklės nustato, kokius failus, programas ar svetaines jis gali atidaryti. Patvirtinimo taisyklės nustato, kuriems veiksmams reikia palaukti žmogaus pritarimo, pavyzdžiui, žinutės siuntimui ar pirkimui.
Kai kurias iš šių taisyklių harness kode nustato agentą kurianti bendrovė. Tada organizacijos administratoriai gali pridėti savų, o atskiri naudotojai – pasirinkti, pavyzdžiui, kurias paskyras prijungti.
6. Tikrinimas
Tikrinimas – tai kodas, kuris patikrina agento darbą, kol šis dar nepasiekė žmogaus. Naudojami dviejų rūšių patikrinimai:
- Fiksuotos taisyklės – konkretūs testai, kurie kaskart lygiai taip pat išlaikomi arba neišlaikomi, pavyzdžiui, patikrinimas, ar kiekvienas ataskaitos skaičius yra dokumente, kurį agentas iš tikrųjų perskaitė.
- Kito DI modelio peržiūra – šis modelis perskaito darbą ir jį įvertina. Taip galima pastebėti problemų, kurias sunku paversti taisykle, pavyzdžiui, santrauką, kurioje praleistas svarbus punktas.
Nė vienas patikrinimas nepagauna visko, todėl harness paprastai derina abi rūšis. Kai patikrinimas aptinka problemą, harness prideda jos aprašymą prie modelio konteksto lango ir grąžina užduotį atgal į agento ciklą. Modelis ištaiso problemą ir bando dar kartą, todėl daug klaidų ištaisoma dar prieš naudotojui pamatant rezultatą.
Harness inžinerijos pavyzdžiai
Pasiruošimas susitikimui su klientu
Užduotis: Klientų vadybininkas paprašo agento parengti rytojaus susitikimo su klientu suvestinę, apimančią neišspręstus klausimus ir darbotvarkės projektą.
Ką daro harness:
- Per el. pašto jungtį agentas vadybininko pašto dėžutėje ieško susirašinėjimo su klientu.
- Leidimai jam leidžia skaityti el. laiškus, bet neleidžia jų siųsti.
- Konteksto valdymas modeliui perduoda tik paskutinių trijų mėnesių susirašinėjimą su tuo klientu, o ne visą pašto dėžutę.
- Agento ciklas atlieka kelis paieškos ir skaitymo etapus, o modelis tai, ką randa, sugrupuoja į neišspręstus klausimus.
- Tada tikrinimo metu patikrinama, ar kiekvienas suvestinėje nurodytas klausimas susietas su tikru el. laišku.
Galimas rezultatas: Vadybininkas gauna vieno puslapio suvestinę, kurioje kiekvieną punktą galima atsekti iki šaltinio el. laiško.
Mėnesinės pardavimų ataskaitos atnaujinimas
Užduotis: Operacijų vadovas paprašo agento atnaujinti mėnesinę pardavimų ataskaitą šio mėnesio skaičiais.
Ką daro harness:
- Atmintis įkelia praėjusio mėnesio sesijos pastabas, įskaitant ataskaitos formatą ir vadovo prašymą skaičius apvalinti iki artimiausio tūkstančio.
- Failų įrankis atidaro pardavimų skaičiuoklę komandos bendrinamame diske.
- Leidimai agentui leidžia redaguoti ataskaitos juodraštį, bet neleidžia keisti šaltinio skaičiuoklės, todėl pradiniai skaičiai negali būti netyčia pakeisti.
- Tikrinimo metu patikrinama, ar ataskaitos sumos sutampa su skaičiuoklės duomenimis.
Galimas rezultatas: Ataskaita pateikiama tokiu pačiu formatu kaip ir praėjusį mėnesį, o naudotojui nereikia jo iš naujo aiškinti.
Bendrinamos pašto dėžutės rūšiavimas
Užduotis: Pagalbos komanda paprašo agento surūšiuoti rytą gautus prašymus pagal temas ir parengti atsakymų į dažniausius iš jų juodraščius.
Ką daro harness:
- Agento ciklas peržiūri pašto dėžutę po vieną laišką.
- Kiekvienam laiškui modelis parenka temos žymą, o harness ją pritaiko per el. pašto jungtį.
- Užduoties pradžioje harness prideda komandos patvirtintus atsakymų šablonus prie konteksto lango kaip gaires, kad modelis kiekvieną juodraštį rengtų pagal šabloną.
- Patvirtinimo taisyklė kiekvieną atsakymą palieka juodraščiu, kol kas nors iš komandos jį peržiūri ir išsiunčia.
Galimas rezultatas: Komanda pradeda dieną su surūšiuotais prašymais ir peržiūros laukiančiais atsakymais.
Svetainės klaidos taisymas
Užduotis: Programuotojas paprašo programavimo agento ištaisyti klaidą, dėl kurios neveikia atsiskaitymo mygtukas.
Ką daro harness:
- Agentas dirba sandbox aplinkoje – izoliuotoje kodo kopijoje, kurioje jo pakeitimai negali paveikti veikiančios svetainės.
- Kodo įrankis leidžia modeliui skaityti ir redaguoti failus.
- Po kiekvieno pakeitimo tikrinimas paleidžia automatinius projekto testus.
- Visi nesėkmingų testų rezultatai grąžinami modeliui kaip nauja informacija.
Galimas rezultatas: Agentas vis koreguoja pataisą, kol testai sėkmingai praeina. Tada, prieš paskelbiant pakeitimą, programuotojas jį peržiūri.
Harness inžinerija, užklausų inžinerija ir konteksto inžinerija: kuo jos skiriasi
Užklausų inžinerija – tai vienos užklausos kūrimas ir optimizavimas. Konteksto inžinerija – tai viso to, ką mato modelis, valdymas. Harness inžinerija – tai visos sistemos, kurioje veikia modelis, projektavimo ir tobulinimo procesas.
Terminas | Kas paprastai tai daro | Pavyzdys iš konkurentų tyrimo užduoties |
Užklausų inžinerija | Bet kas, rašantis užklausą | Prašymas „po vieną eilutę kiekvienam konkurentui, po vieną stulpelį kiekvienam kainų lygiui“ |
Konteksto inžinerija | Harness kūrėjai, taip pat naudotojai, pridedantys failus ar šablonus | Kiekvieno konkurento kainų puslapio ir komandos skaičiuoklės šablono pateikimas modeliui |
Harness inžinerija | DI produktus kuriančios bendrovės, taip pat komandos ir naudotojai, kurie pasirenka nustatymus bei pageidavimus ir įkelia informaciją | Sprendimas, kokius įrankius agentas gali naudoti, kuriems veiksmams reikia patvirtinimo ir kaip tikrinamas jo darbas |
Kaip naudotojai gali paveikti DI harness
Didžiąją agento harness dalį sukuria agentą kurianti bendrovė, tačiau daugelis DI produktų leidžia naudotojams koreguoti dalį jo per nustatymus, tokius kaip pasirinktinės instrukcijos, prijungtos programos ir patvirtinimai.
Naudotojai gali formuoti agento harness ir pagerinti agento rezultatus keturiais būdais:
1. Nuolatinės instrukcijos
Nuolatinės instrukcijos – tai pastabos, kurias žmogus parašo vieną kartą, kad harness galėtų jas pridėti prie konteksto lango kiekvienos užduoties pradžioje. Jas verta nustatyti viskam, ką žmogus kitu atveju kartotų kiekvienoje užklausoje: kas jis yra ir kuo užsiima, kokio rašymo stiliaus pageidauja arba kokios taisyklės taikomos pasikartojančiam darbui, pavyzdžiui, kliento mėnesinei ataskaitai.
Daugelis DI produktų siūlo dviejų lygių nuolatines instrukcijas. Visai paskyrai taikomos instrukcijos tinka tam, kas galioja visam darbui, pavyzdžiui, rašybos pageidavimams. Projekto instrukcijos tinka vienam klientui ar darbo eigai, todėl vienam skirti nurodymai nepersikelia į kitą.
Nuolatinės instrukcijos pokalbių asistentuose ir agentuose veikia vienodai, tačiau agentai nuo jų priklauso labiau. Pokalbyje žmogus gali pataisyti DI po kiekvieno atsakymo. Agentas gali atlikti daug žingsnių, kol kas nors pamatys jo darbą, todėl iš anksto pateiktos instrukcijos yra vienas iš nedaugelio būdų jį nukreipti viso darbo metu.
Kaip parašyti veiksmingas nuolatines instrukcijas
- Pradėkite nuo trumpos instrukcijos, pavyzdžiui: „Esu programinės įrangos įmonės rinkodaros vadovas. Rašyk paprasta anglų kalba, santraukas rašyk trumpesnes nei 200 žodžių ir naudok JAV rašybą.“
- Papildykite jas, kai DI suklysta. Jei DI vis apvalina skaičius, kurių komandai reikia tikslių, pridėkite tai nurodančią eilutę.
- Instrukcijos turi būti konkrečios: „Pateik tikslius skaičius, niekada neapvalintus“ yra geriau nei „Būk tikslus“.
- Sąrašą laikykite trumpą ir pašalinkite eilutes, kai jos tampa nebenaudingos, nes kiekviena eilutė užima vietos konteksto lange.
2. Prijungtos programos
Prijungtos programos susieja DI produktą su įrankiais, kuriuos žmogus jau naudoja, pavyzdžiui, el. paštu, kalendoriumi ar bendrinamu disku. Prijungus programą, DI gali dirbti su paties žmogaus informacija, o ne tik su tuo, kas įklijuota į pokalbį.
Prijungimus verta nustatyti, kai užduotis priklauso nuo tose programose esančios informacijos, pavyzdžiui, rengiant susitikimo suvestinę iš el. laiškų gijų ar apibendrinant bendrinamame diske esančius dokumentus.
Kaip saugiai prijungti programas
- Prijunkite tik tas programas, kurių reikia užduočiai, nes kiekvienas prijungimas – tai dar viena galimybė atsirasti klaidoms.
- Kai įmanoma, rinkitės tik skaitymo prieigą. Pavyzdžiui, susitikimų suvestines rengiančiam agentui reikia el. laiškus skaityti, o ne juos siųsti.
- Kai produktas leidžia, nustatykite prijungimus pagal projektą. Pavyzdžiui, Perplexity platformoje žmonės gali pasirinkti, kurias jungtis naudoja kiekvienas projektas.
- Nepamirškite atjungti nebenaudojamų programų.
3. Patvirtinimo nustatymai
Patvirtinimo nustatymai lemia, kuriems veiksmams reikia palaukti žmogaus pritarimo, prieš DI juos atliekant. Kai kurie patvirtinimai yra integruoti į produktą, o kai kurie produktai leidžia žmonėms pasirinkti, kuriems kitiems veiksmams jo reikia.
Kaip nustatyti patvirtinimo taisykles
- Reikalaukite patvirtinimo veiksmams, kurių negalima atšaukti, pavyzdžiui, žinutės išsiuntimui, pirkimui ar failo ištrynimui.
- Patvirtinimų sąrašas turi būti trumpas. Jei agentas prašo pritarimo kiekvienam smulkiam žingsniui, žmonės ima tvirtinti neskaitę.
4. Standartai ir patikros
Daugumoje DI produktų jau yra įdiegti tam tikri standartai. Pavyzdžiui, Perplexity prie savo atsakymų pateikia nuorodas į šaltinius, kad kiekvieną teiginį būtų galima patikrinti. Naudotojo nustatyti standartai papildo tai, ko produktas pats negali žinoti, pavyzdžiui, komandos pageidaujamą ataskaitų formatą.
Kaip nustatyti DI darbo standartus
- Pasikartojančiam darbui pateikite šabloną, kad DI turėtų nustatytą struktūrą, kurią reikia užpildyti.
- Pasidalykite komandai patikusio ankstesnio darbo pavyzdžiu, kad DI galėtų perimti jo toną ir detalumo lygį.
- Prašykite prie kiekvieno skaičiaus pateikti nuorodą į šaltinį.
- Atidžiai peržiūrėkite pirmuosius rezultatus, o pasikartojančias spragas paverskite nauja nuolatine instrukcija.
Kaip Perplexity žiūri į agentų harness
Perplexity Computer pagrindą sudaro nuo modelio nepriklausomas harness, kuris sujungia daugiau nei 20 pažangių modelių į vieną sistemą. Jis kiekvieną užduotį suskaido į dalines užduotis, perduoda jas subagentams (atskiriems agentams, kurių kiekvienas atlieka vieną dalį) ir kiekvieną darbo dalį nukreipia jai tinkamam modeliui.
Kaip nustatyti instrukcijas, failus ir jungtis, sužinokite Perplexity projektų vadove.
DUK
Kas yra harness inžinierius?
Harness inžinierius kuria ir prižiūri sistemą, leidžiančią DI modeliui patikimai atlikti darbą. Pavyzdžiui, tai gali būti naujo įrankio pridėjimas agentui, aiškinimasis, kodėl agentas vis daro tą pačią klaidą, arba patikrų, kurias jis atlieka prieš baigdamas užduotį, griežtinimas. Tai nėra standartinis pareigų pavadinimas, nors ateityje tai gali pasikeisti. Šį darbą paprastai atlieka programinės įrangos inžinieriai DI įmonėse arba agentus kuriančiose komandose. Gamybos srityje tuo pačiu angliškuoju pavadinimu vadinamas specialistas, projektuojantis laidų pynes – automobiliuose ir mašinose naudojamus sujungtų kabelių ryšulius.
Kas yra agento harness?
Agento harness paprastai vadinama viskas, kas sudaro DI agentą, išskyrus patį modelį. Tai apima kodą, kuris vykdo agento ciklą, valdo kontekstą, atlieka įrankių iškvietimus, saugo atmintį, užtikrina leidimų laikymąsi ir patikrina agento darbą prieš pateikiant jį žmogui.
Ar kiekvienas DI įrankis turi harness?
Taip. Net paprastam pokalbių asistentui reikia harness, kad būtų galima sekti pokalbį, nes modelis pats neprisimena ankstesnių žinučių.
Kūrėjai taip pat gali naudoti modelį, siųsdami jam užklausas iš savo programinės įrangos per API (ryšį, leidžiantį vienai programai siųsti užklausas kitai). Tokiu atveju harness funkciją atlieka paties kūrėjo kodas.
Ar geresni modeliai padarys harness nebereikalingus?
Geresniems modeliams gali prireikti mažiau nurodymų žingsnis po žingsnio, todėl dalis to, ką harness atlieka šiandien, gali sumažėti. Tačiau pats modelis tik paverčia tekstą kitu tekstu. Jis neturi interneto ryšio ir prieigos prie kitų programų. Prieiga prie failų, veiksmų atlikimas ir patvirtinimo taisyklių užtikrinimas vyksta modelį supančioje programinėje įrangoje, todėl tikėtina, kad šis darbas ir toliau liks harness užduotis, kad ir kokie pajėgūs taptų modeliai.