Mga tanong sa interview tungkol sa harness engineering: 22 tanong na may sagot para sa AI engineer

Paano maghanda

Ang mga tanong sa interview tungkol sa harness engineering ay karaniwang nagsisimula sa pangkalahatan at lumalalim: ano ang harness, ano ang binubuo nito, paano mo sinusuri ang problema, paano mo sinusukat ang epekto. Hinahanap ng interviewer ang inhenyong pag-iisip: ang kakayahang ihiwalay ang problema ng modelo sa problema ng kapaligiran at magmungkahi ng solusyong masusuri. Narito ang 22 tanong na may sagot, nakapangkat ayon sa paksa.

Mga pangunahing kaalaman

1. Ano ang harness ng agent?

Ang harness ay ang buong kapaligirang ginagalawan ng AI agent, bukod sa mismong modelo: mga tagubilin, kasangkapan, kapaligiran ng pagpapatakbo, pag-iimbak ng estado, at feedback loop. Nagpapasya ang modelo, at tinutukoy ng harness kung ano ang alam nito, kung ano ang kaya nitong gawin, at paano nito malalaman ang resulta. Iisang modelo sa iba't ibang harness ay nagbibigay ng magkakaibang kalidad.

2. Paano naiiba ang harness engineering sa prompt engineering at context engineering?

Ang prompt engineering ay tungkol sa pagsulat ng isang request, ang context engineering ay tungkol sa kung ano ang pumapasok sa window ng modelo sa bawat hakbang. Sakop ng harness engineering ang dalawa at dinadagdagan ang mga bagay na hindi malulutas ng teksto: access sa kasangkapan, mauulit na kapaligiran, estado sa pagitan ng mga session, at automated na pagsusuri ng resulta.

3. Pangalanan ang limang subsystem ng harness.

Mga tagubilin (AGENTS.md, CLAUDE.md, skills, dokumento), kasangkapan (shell, test, linter, browser, MCP), kapaligiran (dependency, runtime, Docker, worktree), estado (PROGRESS.md, listahan ng feature, mga desisyon), at feedback (make check, E2E, hook, tagasuri). Hindi lang «medyo mas mahina» ang kinalalabasan kapag may nawawalang subsystem, kundi isang sistematikong uri ng pagkabigo.

4. Bakit madalas hindi nakakatulong ang pagpapalit ng mas malakas na modelo?

Dahil marami sa mga pagkabigo ay hindi tungkol sa talino ng modelo. Hindi makakakuha ng access sa kasangkapang hindi ibinigay ang malakas na modelo, hindi maaalala ang sesyon kahapon kung walang state file, at hindi malalaman na sira ang migration kung walang nagpatakbo nito. Hindi rin mahuhulaan ng modelo ang mga partikular na kaugalian ng team.

Diagnostics

5. Nilalabag ng agent ang panuntunang nakasulat sa CLAUDE.md. Ano ang gagawin mo?

Una, tingnan kung nakikita ng agent ang panuntunan: ang mahabang file na may dose-dosenang punto ay nagpapalabo sa mahalaga. Paikliin ang entry file bilang talaan ng nilalaman, at ilipat ang mga detalye sa dokumentong ikinakarga ayon sa kondisyon. Kung kritikal ang panuntunan, gawing masusuring pagsusuri na maaaring patakbuhin, gaya ng linter, test, grep guard, o hook. Kapag ganoon, mahuhuli ng makina ang paglabag, at hindi na nakasalalay sa atensyon ng modelo.

6. Paano mo tutukuyin mula sa sintomas kung aling subsystem ang sira?

Ang paglabag sa mga kilalang kaugalian ay problema ng mga tagubilin. Ang agent na «gustong gawin pero hindi kaya» ay problema ng mga kasangkapan. Ang bawat session na nagsisimula sa pag-aayos ng kapaligiran ay problema ng kapaligiran. Ang bagong session na hindi alam kung saan natigil ay problema ng estado. Ang «tapos na» na hindi tugma sa realidad ay problema ng feedback.

7. Saan dapat magsimula sa pagbuo ng harness, at bakit?

Sa feedback. Kung walang command na makinang sumasagot ng «gumagana ba o hindi», hindi masusukat ang epekto ng anumang iba pang pagbabago. Karaniwang kasunod ang mga tagubilin, estado, kapaligiran, at kasangkapan, pero empirikal ang pagkakasunod-sunod at nakadepende sa kung ano ang pinakamalalang sira.

8. Paano mo susukatin ang kontribusyon ng isang bahagi ng harness?

Sa pamamagitan ng ablation: panatilihing pareho ang modelo at set ng gawain, i-disable ang isang subsystem nang paisa-isa, at tingnan ang pagbaba. Pero mas mainam magsimula sa failure log na may label kung aling layer ang pinagmulan, dahil mas mabilis nitong matutukoy ang bottleneck. Ang hindi pagbaba ay hindi nangangahulugang walang silbi ang bahagi: maaaring hindi ito ginagamit ng mga gawaing iyon, o redundant ito.

Mga tagubilin at context

9. Paano dapat istruktura ang isang mahusay na AGENTS.md?

Parang router, hindi textbook: ano ang proyekto, paano ito patakbuhin, paano ito suriin, ang Definition of Done, at maikling listahan ng mga mandatoryong limitasyon. Nasa hiwalay na dokumento ang mga detalye, na may mga link tulad ng «basahin kapag gawain ay tungkol sa pagbabayad». Itinatakda ng file ang mga invariant («na-validate ang data sa hangganan»), hindi nagdidikta ng implementasyon o mga library linya-por-linya.

10. Para saan ang subagent?

Para sa paghihiwalay ng context. Isinasagawa ang subsidiary na gawain, gaya ng paghahanap sa codebase, review, o pagsusuri, sa sarili nitong context at ibinabalik lang ang output. Hindi nadudumihan ang pangunahing thread, at ang subagent ng pagsusuri ay hindi nagmamana ng pangangatwiran ng gumagawa, na mahalaga para sa patas na pagtatasa.

11. Ano ang «harness debt»?

Ang naipong agwat sa pagitan ng harness at ng realidad: mga lumang panuntunan, mga command na hindi na gumagana, mga dokumento tungkol sa mga module na wala na. Kumikilos ito na parang technical debt: nag-iipon nang tahimik at nababayaran ng mga pagkabigo ng agent. Kailangang regular na suriin ang harness, hindi lang i-configure nang minsan.

Estado at mga session

12. Paano labanan ang «amnesia» ng agent sa pagitan ng mga session?

Itago ang estado sa repository: PROGRESS.md (kalagayan, mga nagawa, mga hadlang, susunod na hakbang), DECISIONS.md (desisyon, dahilan, mga opsyong tinanggihan), listahan ng mga feature na may status, at madalas na mga commit. Sa mga tagubilin, itakda ang pagkakasunod ng pagsisimula: basahin ang progreso, patakbuhin ang script ng pagsusuri ng kapaligiran, at kunin ang active na feature.

13. Para saan ang panuntunang WIP=1?

Kapag sabay-sabay na sinimulan ng agent ang maraming feature, nagkakalat ang estado: walang feature ang natatapos, magkakahalo ang mga pagbabago, at mahirap i-rollback. Ang iisang active na feature ay nagbibigay ng malinaw na punto ng pagsusuri, malinis na commit, at simpleng pagbawi pagkatapos ng pagkabigo.

14. Ano ang cold start test?

Pagsusuri kung ang bagong session ay makasasagot sa mga pangunahing tanong nang walang tulong ng tao: anong proyekto ito, saan natigil, aling feature ang active, paano masusuri na maayos ang lahat. Kung sumasagot ang agent batay sa mga file nang hindi nanghuhula, gumagana ang subsystem ng estado.

Verification

15. Bakit hindi nagpapatunay na gumagana ang feature ang berdeng unit test?

Hiwalay na sinusuri ng unit test ang module at naka-mock ang mga dependency, kaya hindi nito nakikita ang mga punto ng koneksyon: hindi tugmang interface, pagkalat ng estado (nagbago ang schema pero luma ang cache), pagtagas ng resource, at mga problema sa configuration at kapaligiran. Ang mga bug na nahuhuli ng unit test ay bahagi lang ng mga nahuhuli ng integration test, at ang mga iyon naman ay bahagi lang ng mga nahuhuli ng E2E.

16. Ano ang verification gap at paano ito sinusukat?

Ang proporsyon ng mga gawaing idineklara ng agent na tapos na pero hindi kinumpirma ng independiyenteng pagsusuri. Kumuha ng 10 gawaing magkakasunod at itala ang dalawang katotohanan para sa bawat isa. Nagbibigay ang sukatang ito ng baseline: pagkatapos ng pagbabago sa harness, kalkulahin ulit sa katulad na set ng gawain.

17. Paano isusulat ang Definition of Done para sa agent?

Sa AGENTS.md, bilang listahan ng masusuring punto: natapos ang mga verification command nang may code 0, may E2E na sumasaklaw sa senaryo, naa-apply ang migration, at na-update ang progreso. Makabubuting tahasang ilista rin kung ano ang hindi itinuturing na tapos: «mukhang tama», «pumapasa ang unit test», «gumagana sa lokal ko».

18. Bakit hindi dapat ang agent mismo ang maglagay ng status na «tapos na»?

Madalas labis na tinatasa ng mga modelo ang sarili nilang gawa, at ang self-assessment ay nangyayari sa parehong context kung saan ginawa ang desisyon. Dapat ilagay ng verification script ang status na passing batay sa resulta ng pagtakbo, at itala ang hash ng commit bilang patunay.

19. Paano magtatakda ng independiyenteng tagasuri?

Isang hiwalay na agent o session na nakikita lang ang requirement, diff, at resulta ng pagtakbo, pero hindi ang pangangatwiran ng gumagawa. Sinusuri nito ayon sa rubric (katumpakan, arkitektura, test, paghawak ng error), at bawat pagtatasa ay tumutukoy sa file, linya, o log. Makabubuting gumamit ng ibang modelo para hindi magkapareho ang mga blind spot.

20. Paano gagawing masusuring pagsusuri ang panuntunan sa arkitektura?

Tatlong antas: grep guard (mabilis, batay sa pattern), panuntunan ng linter na nakauunawa sa import graph (import-linter, dependency-cruiser), at architecture test sa CI. Lahat ay isinasama sa make check, nabibigo na may code na hindi 0, at nagpi-print ng WHY at FIX para maayos ng agent ang paglabag mismo. Ang trigger para sa bagong pagsusuri ay ang pangalawang beses na lumitaw ang parehong komento sa review.

Autonomous na trabaho

21. Ano ang kailangan para mapatakbo ang agent nang ilang oras?

Malinaw na layunin, monotonikong sukatan ng progreso (halimbawa, bilang ng feature na passing), badyet ng oras at pagsubok bawat feature, awtomatikong rollback kapag may regression, at listahan ng mga gawaing nangangailangan ng tao: migration, imprastraktura, pera. Kasama rin ang isolation: sandbox o hiwalay na git worktree, para hindi maapektuhan ng pagkakamali ang working environment.

22. Kailan hindi sapat ang iisang agent loop, at paano magdisenyo ng graph ng mga tungkulin?

Kapag nagsimulang suriin ng gumagawa ang sarili at natigil. Hinahati noon ang gawain sa mga tungkulin: implementasyon, review, test, merge. Ang reviewer ay tumatanggap ng malinis na context at rubric, at isinasagawa ng code ang merge kapag review == pass. Kapag pumalya ang review, bumabalik ang feature sa implementasyon, at pagkatapos ng ilang sunod-sunod na kabiguan, nire-restart ito na may malinis na context. Ibig sabihin nito na nasa pag-unawa sa gawain ang problema, hindi sa code.

Buod

Sa interview tungkol sa harness engineering, pinakamalakas ang sagot ng nagsasalita tungkol sa mga bagay na masusuri: anong file, anong command, anong sukatan. Tandaan ang limang subsystem, ang verification gap, at ang panuntunang «ang script ang nagtatakda ng status ng pagiging handa». Ang lahat ng paksang ito ay pinagsasama sa iisang harness sa isang totoong proyekto sa kursong harness engineering.