Paano gawing maaasahan ang AI agent: hakbang-hakbang na plano mula sa pagsukat hanggang autonomous na trabaho

Bakit hindi maaasahan ang agent kahit malakas ang modelo

Ang pagiging maaasahan ng agent ay katangian ng buong sistema, hindi lang ng modelo. Ang mahabang gawain ay binubuo ng dose-dosenang hakbang, at nag-iipon ang mga pagkakamali: kung tama ang 95% ng bawat hakbang, humigit-kumulang 60% lang ng mga takbo na may sampung hakbang ang walang anumang pagkakamali (0.95^10 ≈ 0.60), at mas mababa sa 10% ang may limampung hakbang. Hindi mo mapapabuti ang katumpakan ng modelo, pero kaya mong mahuli ang pagkakamali sa mismong hakbang nito at gawin itong mura. Ito ang trabaho ng harness: ang mga tagubilin, kasangkapan, kapaligiran, estado, at feedback na nakapalibot sa modelo.

Narito ang mapa mula sa pagtatrabaho «ayon sa pakiramdam» tungo sa maaasahang pagiging maaasahan na masusukat, at pagkatapos ay tungo sa autonomous na trabaho. Nakaayos ang mga hakbang ayon sa epekto: bawat susunod ay nakasandig sa nauna.

Hakbang 1. Itigil ang pagsusuri batay sa pakiramdam

Naniniwala ang isang inhinyero na nabago ng bagong prompt ang lahat, ang isa naman ay walang nakikitang pagkakaiba, at walang sumukat ng anuman. Magsimula sa failure log: sa bawat pagkakataong natigil ang agent, nasira ang isang bagay, o nag-ulat ng sirang feature, magsulat ng isang linya.

| petsa | gawain             | nangyari                       | subsystem    |
|-------|--------------------|--------------------------------|--------------|
| 10/10 | discount sa cart   | «tapos na», hindi pinatakbo e2e | feedback    |
| 10/10 | payment webhook    | hindi mabuksan ang DB          | kapaligiran  |
| 11/10 | refactor ng API    | inulit ang tinanggihang solusyon | estado     |

Ang kolum na «subsystem» ang pinakamahalaga. Pagkatapos ng isang linggo, makikita mo kung nasaan ang bottleneck, at iyon ang aayusin mo sa halip na lahat. Mali ang pagsukat ng pagiging maaasahan sa pamamagitan ng bilang ng matagumpay na takbo, dahil ang log ng pagkakatigil lang ang nagsasabi kung saan bumabagsak ang agent.

Hakbang 2. Gamitin ang dalawang sukatan: MTBF at MTTR

Dalawang numero ang bumubuo sa pagiging maaasahan. Ang MTBF (mean time between failures) para sa agent ay kung ilang hakbang ang kaya nitong tapusin bago tumigil. Ang MTTR (mean time to recovery) ay ang oras na kailangan para maibalik ang agent sa gumaganang kalagayan pagkatapos ng pagkabigo. Lumalaki ang availability sa pagtaas ng una at pagbaba ng ikalawa.

Walang katapusan ang habulan ng agent na hindi nagkakamali. Kadalasang kayang bawasan ang MTTR sa loob ng isang araw, kaya simulan sa ikalawang numero.

Hakbang 3. Gawing mura ang pagkakamali

Katanggap-tanggap ang autonomous na trabaho kapag bumaba na sa halos zero ang halaga ng pagkakamali, hindi kapag tumigil na sa pagkakamali ang agent. Kailangan dito ang tatlong bagay:

• Maliit at malinis na commit — maibabalik ang anumang pagbabago sa isang command.
• Isolation — gumagana ang agent sa hiwalay na branch o working copy, halimbawa sa pamamagitan ng git worktree, at sa sandbox na walang access sa production.
• Reset script para sa kapaligiran — ang database, dependency, at serbisyo ay bumabalik sa paunang kalagayan sa isang command.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # gumawa ulit ng DB, ilapat ang migration, mag-load ng fixtures

Sukatin gamit ang stopwatch kung gaano katagal ang buong pagbabalik sa gumaganang kalagayan. Iyon ang iyong MTTR. Limitahan din ang radius ng pinsala: magtakda ng limitasyon sa laki ng diff bawat gawain at ipagbawal ang pagbabago ng mga file sa labas ng saklaw nito.

Hakbang 4. Isara ang feedback loop

Kung walang verification, ang agent ang sarili nitong nag-iisang hukom, at taos-puso nitong iisipin na tapos na ang trabaho. Bigyan ito ng mga command para suriin ang sarili at gawing sapilitan ang mga ito.

• Fail-fast: huminto ang verification sa unang pagkakamali na may malinaw na mensahe, sa halip na maglabas ng isang daang linya ng ingay.
• Mabilis na pagsusuri pagkatapos ng bawat pagbabago: linter at type check sa pamamagitan ng hook ng agent.
• Redundancy: ikalawang independiyenteng pagsusuri para sa parehong katangian — isang E2E na senaryo sa ibabaw ng unit tests. Ang berdeng unit test ay hindi nagpapatunay na gumagana ang feature para sa user.

Isulat ang pamantayan ng «tapos na» bilang kondisyong masusuri: «pumapasa ang E2E na senaryo ng checkout na may promo code», hindi «naipatupad na ang discount».

Hakbang 5. Ilipat ang memorya sa mga file

Hindi naaalala ng agent ang nakaraang session. Ang lahat ng kailangan para ipagpatuloy ang trabaho ay dapat nasa repository: layunin, mga nagawa at kung paano sinuri, mga desisyon kasama ang dahilan, mga dead end, at ang susunod na hakbang. Magandang senyales kapag ang bagong session, na may repository lang at salitang «ituloy mo», ay agad na nagsisimula ng kapaki-pakinabang na gawain.

Lumilikha ng pakiramdam ng pagpapatuloy ang mahabang nakabuod na kasaysayan ng usapan, pero nawawala rito ang pinakamahalaga: ang dahilan ng mga opsyong tinanggihan. Kadalasang mas mura ang sinasadyang pag-reset ng session na may kumpletong nakasulat na estado.

Hakbang 6. Isang gawain sa isang pagkakataon

Batas ni Little: ang bilang ng gawaing ginagawa ay katumbas ng rate ng pagdating ng gawain na minultiply sa oras na nananatili ang bawat gawain sa sistema. Kapag nakapirmi ang kapasidad, hindi pinabibilis ng sabay-sabay na gawain ang trabaho, pinapahaba lang nito ang bawat isa. Mas mahigpit pa ito para sa agent: ang tatlong feature ay tatlong magkakaibang domain model sa iisang context window.

• Panatilihin ang WIP=1: isang feature hanggang sa may na-verify na resulta.
• Hatiin ang gawain sa maliliit na piraso: isang kakayahan ng user na masusuri, 1–3 file, at verification na mas mabilis sa isang minuto.
• Gumawa ng BACKLOG.md bilang labasan ng mga «habang nandiyan». Kung may nakitang kalapit na depekto, isang linya lang sa backlog, hindi basta pag-aayos.

Hakbang 7. Paghiwalayin ang gumagawa at ang tagasuri

Mahinang preno ang self-assessment ng agent: ang parehong session na sumulat ng code ay madalas maniwalang tama ito. Hayaang ang hiwalay na subagent o session ang magsuri ng resulta, na tumatanggap lang ng requirement, diff, at resulta ng verification, nang walang pangangatwiran ng gumagawa. Ang hatol ng tagasuri ay dapat nakabatay sa machine checks, hindi sa «mukhang ayos naman».

Hakbang 8. Ilabas ang agent sa autonomous loop

Ginagawang maaasahan ng harness ang isang takbo, at ginagawang autonomous ng loop ang sunod-sunod na takbo. Ang loop na nakapatong sa mahinang harness ay nagpaparami lang ng pagkakamali nang mas mabilis, kaya huli ang hakbang na ito. Ang pinakasimpleng loop ay maipapaliwanag sa tatlong linya:

Layunin:     pumasa ang e2e na senaryo ng bayad na may promo code
Verification: make lint && make test && make e2e
Huminto:     naabot ang layunin O 15 pagsubok O 2 oras → tawagin ang tao

Piliin ang uri ng loop ayon sa gawain. Kung may malinaw na dulo ang trabaho, kailangan ng goal-based loop na may memorya ng progreso, independiyenteng tagasuri, at badyet ng hakbang. Kung walang dulo (halimbawa, pang-umagang pagsusuri ng CI o pag-analisa ng bagong error), gumamit ng schedule-based loop. Karaniwang pagkakamali ang pag-iskedyul ng gawaing may dulo: nagsisimula itong muli sa zero sa bawat takbo.

Mga tuntunin para sa ligtas na autonomy

• Tanging machine-verifiable na kondisyon ng paghinto, kasama ang limitasyon sa pagsubok at badyet.
• Escalation: maglista nang maaga ng mga bagay na hindi dapat pagkatiwalaan ng loop (production migration, pera, pagbura ng datos).
• Kung nakatigil ang gawain at hindi na talaga umuusad ang progreso, senyales ito na ibigay sa tao, hindi ituloy ang pag-ikot.
• Basahin ang mga diff. Hindi dapat lampasan ng bilis ng loop ang bilis ng iyong pagbabasa, dahil mawawalan ka ng pag-unawa sa sarili mong codebase.

Mga karaniwang pagkakamali sa daan

Pagsisimula sa pagsulat muli ng mga tagubilin

Ang pinakakaraniwang tugon sa pagkabigo ng agent ay magdagdag ng panuntunan sa AGENTS.md. Ilang buwan ang lilipas, lalaki ang file sa daan-daang linya at malulunod ang mahahalagang panuntunan. Kung nagpapakita ang failure log na hindi nagpapatakbo ng verification ang agent, ayusin ang feedback: ilagay ang command sa verification at ang hook, huwag magdagdag ng isa pang talata ng teksto.

Pag-aayos ng lahat nang sabay

Gustong pagbutihin ang limang subsystem ng harness nang sabay. Pero pagkatapos, hindi malalaman kung ano ang talagang nakatulong. Bigyan ng marka ang bawat subsystem mula 1 hanggang 5, gugulin ang kalahating oras sa pinakamahina, at patakbuhin ang parehong limang tipikal na gawain bago at pagkatapos. Ipapakita ng pagkakaiba sa failure log kung may epekto.

Pagkalito sa «berde ang test» at «gumagana ang feature»

Maaaring sumulat ang agent ng test na sumusuri sa sarili nitong implementasyon, hindi sa requirement. Laging berde ang ganitong test. Ang proteksyon ay verification sa antas ng user (E2E na senaryo), na isinulat bago ang implementasyon o ng independiyenteng tagasuri, kasama ang panuntunang hindi binabago ng agent ang test para lang pumasa.

Pag-disable ng verification para sa bilis

Ang mabagal na verification ay nag-uudyok na laktawan ito ng «sa pagkakataong ito lang». Mas mabuting hatiin ito: mabilis na linter at type check pagkatapos ng bawat pagbabago, buong test suite at E2E bago sabihing «tapos na». Sa ganitong paraan, nananatiling maikli ang feedback loop at hindi nakakaabala sa trabaho.

Pagturing sa ablation bilang unang hakbang

Maaari mong i-disable ang bawat subsystem ng harness nang paisa-isa at tingnan kung gaano bumababa ang kalidad. Kapaki-pakinabang ito pero mahal at hindi dapat unang gawin: unahin ang failure log na magtuturo ng bottleneck, at kukumpirmahin lang ng ablation ang hinala. Ang hindi pagbaba ng kalidad kapag na-disable ang isang bahagi ay hindi nangangahulugang walang silbi ito; baka hindi lang ito ginagamit ng napiling set ng gawain.

Hagdan ng pagkahinog

Buod

Paano gawing maaasahan ang AI agent: sukatin, hanapin ang mahinang subsystem sa pamamagitan ng failure log, gawing mura ang pagkakamali, isara ang feedback loop, ilipat ang memorya sa mga file, panatilihin ang isang gawain sa isang pagkakataon, at paghiwalayin ang gumagawa sa tagasuri. Pagkatapos nito lang magiging ligtas ang autonomous loop na may machine-verifiable na kondisyon ng paghinto. Ang bawat hakbang sa planong ito ay tinatalakay nang praktikal sa kursong harness engineering.