Die afgelope twee jaar was loopbaanadvies rondom KI-agente meestal daarop gerig om te leer hoe om hulle goed te prompt. Dit is nie meer die skaars vaardigheid nie. Die skaars vaardigheid is om die raamwerk te bou waarbinne 'n agent funksioneer — die ding wat toenemend 'n harness genoem word — en dit is spesifiek genoeg, en moeilik genoeg, dat dit sy eie posbeskrywing word eerder as 'n newe-verantwoordelikheid van "die KI-persoon" in 'n span.
Die duidelikste openbare deurloop van wat dit werklik behels, kom van Lenny's Newsletter, wat dokumenteer hoe die produkbestuurnutsmiddel ChatPRD 'n harness gebou het om Sentry-foute outomaties op te spoor. Die stuk is die moeite werd om in geheel te lees as jy oorweeg om hierin te spesialiseer, want dit maak 'n punt wat maklik miskyk kan word: die model was nooit die bottelnek nie. Die span het die Claude Agent SDK as grondslag gebruik, en het toe die grootste deel van hul ingenieurswerk bestee aan 'n pasgemaakte terminaal-koppelvlak en 'n stel aanpassers wat die agent aan Sentry, Linear, GitHub en Vercel koppel. Dit is die werk, in die kleine. Vier stelsels, vier verskillende outentifiseringskemas, vier verskillende datavorms, en 'n koppelvlak wat 'n mens toelaat om dop te hou en in te gryp sonder om elke stap dop te hou.
Waaruit 'n "harness" eintlik bestaan
As jy probeer uitwerk of dit 'n vaardigheidstel is wat die moeite werd is om te ontwikkel, help dit om dit op te breek in dele waarvoor afsonderlik aangestel word, of ten minste afsonderlik in 'n onderhoud geëvalueer word:
- Toestemmingsontwerp. Om te besluit wat 'n agent onbeheerd mag doen (lees 'n kaartjie, stel 'n PR op) teenoor wat 'n mens in die lus vereis (saamvoeg, ontplooi, verwyder, geld bestee) — en dit as werklike beleid in kode te kodifiseer, nie as 'n promptinstruksie wat die model onder druk kan ignoreer nie. Dit is nader aan toegangsbeheer-ingenieurswese as aan promptskryf.
- Nutsmiddel-aanpassers. Dun, deeglik getoetste omhulsels om elke eksterne stelsel (Sentry, Linear, GitHub, Vercel, of watter stapel jou maatskappy ook al gebruik) wat die agent se bedoeling omskep in 'n veilige, gevalideerde API-oproep en die antwoord terugvertaal na iets waaroor die model kan redeneer. Dit is gewone sagteware-ingenieurswese — foutafhandeling, herprobeerpogings, skemavalidering — toegepas op 'n nuwe verbruiker.
- Terminaal- of konsolekoppelvlak. 'n Manier waarop 'n mens kan sien wat die agent doen, aksies kan goedkeur of afkeur, en kan ingryp wanneer dit vasval. ChatPRD het 'n pasgemaakte een gebou; baie spanne sal eerder kant-en-klaar agentkonsoles gebruik, maar iemand moet steeds besluit wat gewys word, wat weggesteek word, en wat 'n klik vereis voordat dit gebeur.
- Nutsmiddelkeuse op skaal. 'n Artikel van Machine Learning Mastery wys op iets wat die moeite werd is om te weet as jy enigiets buite 'n demo bou: 'n agent se akkuraatheid met nutsmiddel-oproepe neig om te verswak sodra die nutsmiddelkatalogus verby sowat 'n dosyn opsies gaan — die model begin nutsmiddels verkeerd oproep, parameters hallusineer, of vashaak by slegte oproepe. Die versagtingsmaatreëls wat dit lys (om te beheer watter nutsmiddels selfs sigbaar is in 'n gegewe konteks, herwinning-gebaseerde nutsmiddelsoektogte, roetering na gespesialiseerde sub-agente, eksplisiete beplanningstappe, terugvallogika, en maatstaf-harnesse om terugslae op te spoor) is self 'n kontrolelys van dinge wat 'n harness-ingenieur moet weet hoe om te implementeer, nie net van te weet nie.
- Konteks- en geheue-ingenieurswese. Dieselfde bron trek 'n onderskeid wat die moeite werd is om te internaliseer: konteksingenieurswese (wat in 'n enkele afleidingsoproep ingaan, en waar) en geheue-ingenieurswese (wat oor sessies heen behoue bly, hoe dit gestoor word, hoe dit onttrek word) is verskillende dissiplines met verskillende faalwyses. Die bewering is dat die meeste ineenstortings in langlopende, multi-sessie-agente daarop terugvoer dat die twee saamgevoeg word — om sessiegeheue te behandel asof dit net nog konteks is, of andersom — veral op die punt waar die stelsel besluit wat onttrek moet word.
Die bewyse dat dit 'n werklike, befondsbare rol is — nie net 'n hobbyis-nis nie
Skeptici sal redelikerwys vra of 'n "harness-ingenieur" 'n werk is, of net 'n taak binne iemand anders se werk. Twee datapunte uit die oorsig dui daarop dat dit na eersgenoemde beweeg. Eerstens het Microsoft se Aspire-span — 'n groep van 10 mense — GitHub se Agentic Workflows gebruik om dokumentasie-PR's oor verskeie bewaarplekke heen te outomatiseer, en oor twee vrystellings heen 82 PR's saamgevoeg teen 'n mediaan van 44.8 uur ná die ooreenstemmende produk-PR uitgereik is, sonder enige nuwe personeel en sonder prosesheropleiding. Dit is 'n klein span wat buitengewone hefboomwerking kry, spesifiek omdat iemand in die raamwerk belê het (die werkvloei-definisies, die hersieningsroetering, die aktiveerlogika) eerder as om ingenieurs die dokumentasie-PR's met die hand te laat skryf. Tweedens behandel Microsoft Research se SkillOpt-projek agent-"skill"-lêers — die instruksies en beperkings wat vorm gee aan hoe 'n agent binne sy harness optree — as iets wat stelselmatig geoptimeer moet word eerder as met die hand geredigeer, en rapporteer dat dit die beste of gelykop-beste was oor al 52 selle van 'n maatstafrooster (ses maatstawwe, sewe modelle, drie uitvoeringsmodusse), met die geoptimeerde skills wat oordraagbaar was oor verskillende modelle en verskillende harnesse heen. Of daardie spesifieke nutsmiddel al dan nie die standaard word nie, dit dui daarop dat die bedryf begin om harness-konfigurasie te behandel as 'n ingenieursartefak met sy eie nutsmiddels en maatstawwe — dieselfde trajek wat "DevOps" van 'n stel ad hoc-skrifte in 'n dissipline omskep het.
Daar word nou ook infrastruktuur spesifiek vir hierdie laag gebou. Google se nuut aangekondigde "Managed Agents"-vermoëns in die Gemini-API — agtergrond- en asinchrone uitvoering, integrasie met afgeleë MCP-bedieners, pasgemaakte funksie-oproepe, geloofsbriefverfrissing oor interaksies heen — is in wese vooraf-gebou loodgieterswerk vir presies die probleme wat die ChatPRD-span met die hand opgelos het. Dit is 'n normale patroon: wat een span vanjaar pasgemaak bou, produkteer 'n platformverskaffer volgende jaar. Dit skakel nie die harness-ingenieursrol uit nie; dit lig die vloer en verskuif die werk na die integrasie en konfigurasie van bestuurde boustene eerder as om elke aanpasser van voor af te skryf, soortgelyk aan hoe wolkinfrastruktuur nie ops-ingenieurs uitgeskakel het nie, maar wel verander het waaraan hulle hul tyd bestee.
Wat dit beteken as jy hierdie rol wil bereik
'n Paar konkrete, verifieerbare dinge om op 'n portefeulje of CV te sit as jy geloofwaardig vir hierdie werk wil wees: bou een aanpasser van begin tot einde teen 'n werklike API waaroor jy geen beheer het nie (met outentifisering, foutafhandeling en tempobeperkings ingesluit, nie 'n gelukkige-pad-demo nie); ontwerp en dokumenteer 'n toestemmingsmodel vir 'n agent wat onderskei tussen lees-/voorstel-/handelingsaksies, en wys waarom elke grens is waar dit is; en bou of konfigureer 'n hersieningskoppelvlak waar 'n mens agent-aksies goedkeur voordat dit uitgevoer word, aangesien dit die onderdeel is waarop die meeste maatskappye sal aandring voordat hulle 'n agent aan produksie laat raak. As jy 'n harness-ingenieurspos oorweeg of jou eie verantwoordelikhede aftaken, vra spesifiek wie die toestemmingsmodel besit, wie die aanpassers besit, en wie die mens-hersieningsoppervlak besit — in baie spanne het hierdie drie dinge tans geen duidelike eienaar nie, wat presies die gaping is wat hierdie rol besig is om te vul.
Een voorbehoud wat die moeite werd is om reguit te stel: geen van bogenoemde bronne bevestig 'n aanstellingsmark-syfer vir hierdie spesifieke titel nie, en "harness-ingenieur" is nog nie 'n posbenaming wat jy op advertensies sal sien nie — dit verskyn eerder binne titels soos "KI-infrastruktuuringenieur," "agentplatform-ingenieur," of bloot "senior back-end-ingenieur, KI-stelsels." Behandel dit as 'n vaardigheidstel om te ontwikkel en akkuraat te beskryf, nie 'n titel om op LinkedIn na te soek nie.