Jinsi ya kufanya wakala wa AI kuwa wa kuaminika: mpango wa hatua kwa hatua kutoka kupima hadi kazi ya kujiendesha

Kwa nini wakala hana uaminifu hata modeli ikiwa na nguvu

Uaminifu wa wakala ni sifa ya mfumo mzima, si ya modeli peke yake. Kazi ndefu ina hatua kadhaa, na makosa hujilimbikiza: kwa hatua 95% sahihi, mnyororo wa hatua kumi usio na kosa hata moja hufika katika takriban 60% ya majaribio (0.95^10 ≈ 0.60), na kwa hatua hamsini chini ya 10%. Usahihi wa modeli hauko mikononi mwako, lakini unaweza kukamata kosa katika hatua ile ile na kulifanya liwe la gharama nafuu. Hapo ndipo harness inapofanya kazi: maelekezo, zana, mazingira, hali na maoni vinavyozunguka modeli.

Hapa chini kuna mpango unaokupeleka kutoka «hisia» hadi uaminifu unaopimika, na kutoka hapo hadi kazi ya kujiendesha. Hatua zimepangwa kwa mpangilio wa athari: kila hatua inayofuata inategemea iliyotangulia.

Hatua 1. Acha kutathmini kwa «hisia»

Mhandisi mmoja ana uhakika kwamba prompt mpya ndiyo iliyobadilisha kila kitu, mwingine haoni tofauti, na hakuna aliyehesabu vipimo. Anza na kumbukumbu ya kushindwa: kila wakala anapokwama, kuvunja kitu, au kuripoti kipengele kisichofanya kazi, andika mstari mmoja.

| tarehe | kazi                 | kilichotokea                       | kipengele      |
|--------|----------------------|------------------------------------|----------------|
| 10/10  | punguzo kwenye kikapu| «imekamilika», e2e haikuendeshwa   | maoni          |
| 10/10  | webhook ya malipo    | haikuweza kuwasha hifadhidata      | mazingira      |
| 11/10  | urekebishaji wa API  | alirudia suluhisho lililokataliwa  | hali           |

Safu ya «kipengele» ndiyo muhimu zaidi. Baada ya wiki moja utaona kizuizi kiko wapi, na utarekebisha sehemu hiyo badala ya kila kitu kwa wakati mmoja. Kuhesabu uaminifu kwa uwiano wa majaribio yaliyofaulu ni kosa: kumbukumbu ya vikwazo ndiyo inayoonyesha wakala anaanguka wapi.

Hatua 2. Pima vipimo viwili: MTBF na MTTR

Uaminifu una namba mbili. MTBF (wastani wa muda kati ya kushindwa) kwa wakala ni hatua ngapi anapita kabla ya kukwama. MTTR (wastani wa muda wa kurejea) ni muda unaochukua kurudi katika hali ya kufanya kazi baada ya kushindwa. Upatikanaji huongezeka ama namba ya kwanza ikiongezeka au ya pili ikipungua.

Kufukuzia wakala ambaye haskosei kabisa ni mbio zisizo na mwisho. MTTR kwa kawaida inaweza kupunguzwa ndani ya siku moja. Kwa hiyo anza na namba ya pili.

Hatua 3. Fanya kosa liwe la gharama nafuu

Kujiendesha kunakubalika si wakala anapoacha kukosea, bali gharama ya kosa inaposhuka karibu na sifuri. Kwa hilo unahitaji mambo matatu:

• Commit ndogo na safi — kila mabadiliko yanaweza kurudishwa kwa amri moja.
• Kutengwa — wakala anafanya kazi kwenye tawi au nakala tofauti ya kazi, kwa mfano kwa git worktree, na kwenye sandbox isiyo na ufikiaji wa uzalishaji.
• Skripti ya kuweka upya mazingira — hifadhidata, utegemezi na huduma zinarudi katika hali ya awali kwa amri moja.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # tengeneza upya DB, tumia migrations, pakia fixtures

Pima kwa saa ya kusimamisha muda wa urejeo kamili kwenye hali ya kazi. Hiyo ndiyo MTTR yako. Wakati huo huo punguza eneo la madhara: weka kikomo cha ukubwa wa diff kwa kazi moja na katazo la kubadilisha faili nje ya eneo la kazi hiyo.

Hatua 4. Funga mzunguko wa maoni

Bila uthibitishaji, wakala ndiye hakimu pekee wa kazi yake, na anaamini kwa dhati kwamba kazi imekamilika. Mpe amri anazoweza kuzitumia kujikagua, na zifanye za lazima.

• Fail-fast: ukaguzi unasimama kwenye kosa la kwanza kwa ujumbe wazi, badala ya kutoa mistari mia ya kelele.
• Ukaguzi wa haraka baada ya kila mabadiliko: linter na ukaguzi wa aina kupitia hook ya wakala.
• Urudufu: ukaguzi wa pili huru wa jambo lilelile — jaribio la E2E juu ya majaribio ya kitengo. Majaribio ya kitengo yenye kijani hayathibitishi kwamba kipengele kinafanya kazi kwa mtumiaji.

Andika kigezo cha «imekamilika» kama sharti linaloweza kuthibitishwa: «mchakato wa E2E wa checkout wenye msimbo wa promo unapita», si «punguzo limetekelezwa».

Hatua 5. Hamisha kumbukumbu kwenye faili

Wakala hakumbuki kikao kilichopita. Kila kinachohitajika ili kuendelea kazi lazima kiwe kwenye hazina: lengo, yaliyofanyika na jinsi yalivyothibitishwa, maamuzi pamoja na sababu zake, njia zisizofaa, na hatua inayofuata. Ishara nzuri: kikao kipya kikipata hazina na neno «endelea» tu, kinaanza kazi yenye manufaa mara moja.

Historia ya mazungumzo iliyofupishwa inatoa hisia ya mwendelezo, lakini inapoteza jambo lenye thamani zaidi — sababu za chaguzi zilizokataliwa. Kumaliza kikao kwa makusudi kwa hali iliyoandikwa kikamilifu kwa kawaida ni nafuu zaidi.

Hatua 6. Kazi moja kwa wakati

Sheria ya Little: idadi ya kazi zinazoendelea ni sawa na kiwango cha kuwasili kikizidishwa na muda wa kazi moja kwenye mfumo. Kwa uwezo ulio thabiti, kazi sambamba hazifanyi kazi kwa kasi zaidi, zinarefusha kila kazi tu. Kwa wakala hili ni kali zaidi: vipengele vitatu ni modeli tatu za vikoa ndani ya dirisha moja la muktadha.

• Weka WIP=1: kipengele kimoja hadi matokeo yaliyothibitishwa.
• Kata kazi kwa ukubwa unaofaa: uwezo mmoja wa mtumiaji unaoweza kuthibitishwa, faili 1–3, ukaguzi chini ya dakika moja.
• Tengeneza BACKLOG.md kama mahali pa mambo «ya ziada». Wakala akiona kasoro karibu, ni mstari mmoja kwenye backlog, si mabadiliko ya kujitegemea.

Hatua 7. Tenganisha mtekelezaji na mkaguzi

Tathmini ya wakala mwenyewe ni breki dhaifu: kikao kile kile kilichoandika msimbo huelekea kuuona kuwa sahihi. Acha matokeo yatathminiwe na subagent au kikao tofauti kinachopokea mahitaji, diff na matokeo ya ukaguzi tu, bila hoja za mtekelezaji. Hukumu ya mkaguzi itegemee ukaguzi wa mashine, si «inaonekana sawa».

Hatua 8. Mwachie wakala mzunguko wa kujiendesha

Harness inafanya mbio moja iwe ya kuaminika, mzunguko unafanya mfululizo wa mbio uwe wa kujiendesha. Mzunguko juu ya harness dhaifu unaongeza kasi ya makosa tu, ndiyo maana hatua hii ni ya mwisho. Mzunguko rahisi zaidi unaweza kuandikwa kwa mistari mitatu:

Lengo:       mchakato wa E2E wa malipo wenye msimbo wa promo unapita
Uthibitishaji: make lint && make test && make e2e
Kusimama:    lengo limefikiwa AU majaribio 15 AU saa 2 → mwite binadamu

Chagua aina ya mzunguko kulingana na kazi. Kazi yenye mstari wa mwisho inahitaji mzunguko wa lengo: kumbukumbu ya maendeleo, mkaguzi huru na bajeti ya hatua. Kazi isiyo na mwisho (ukaguzi wa CI wa asubuhi, kupanga makosa mapya) inahitaji mzunguko ulioratibiwa. Kosa la kawaida ni kuratibu kazi yenye mwisho: kila mbio inaianza upya.

Kanuni za kujiendesha kwa usalama

• Sharti la kusimama liwe linaloweza kuthibitishwa na mashine tu, pamoja na kikomo cha majaribio na bajeti.
• Upandishaji: andika mapema vitu ambavyo mzunguko hauaminiwi navyo (migration za uzalishaji, fedha, kufuta data).
• Kazi ikikwama na maendeleo halisi yakikoma, hiyo ni ishara ya kumkabidhi binadamu, si kuendelea kuzunguka.
• Soma diffs. Kasi ya mzunguko isizidi kasi yako ya kusoma, vinginevyo unapoteza uelewa wa msimbo wako mwenyewe.

Makosa ya kawaida njiani

Kuanza kwa kuandika upya maelekezo

Jibu maarufu zaidi kwa kushindwa kwa wakala ni kuongeza kanuni kwenye AGENTS.md. Baada ya miezi kadhaa faili linavimba hadi mistari mamia, na kanuni muhimu zinapotea ndani yake. Ikiwa kumbukumbu ya kushindwa inaonyesha wakala hakuendesha ukaguzi, kinachopaswa kurekebishwa ni maoni: amri ya uthibitishaji na hook, si aya nyingine ya maandishi.

Kurekebisha kila kitu kwa wakati mmoja

Kuna hamu ya kuboresha vipengele vitano vya harness pamoja. Matokeo yake haijulikani kipi kilisaidia. Pima kila kipengele kwa kipimo cha 1 hadi 5, tumia nusu saa kwenye dhaifu zaidi, na endesha kazi tano zile zile za kawaida kabla na baada. Tofauti katika kumbukumbu ya kushindwa itaonyesha kama kulikuwa na athari.

Kuchukulia «majaribio ya kijani» kama «kipengele kinafanya kazi»

Wakala anaweza kuandika jaribio linalokagua utekelezaji wake mwenyewe, si mahitaji. Jaribio la aina hiyo huwa la kijani kila wakati. Kinga yake ni ukaguzi wa kiwango cha mtumiaji (hali ya E2E) unaoandikwa kabla ya utekelezaji au na mkaguzi huru, pamoja na kanuni kwamba wakala haruhusiwi kubadilisha jaribio ili lipite.

Kuzima ukaguzi kwa ajili ya kasi

Ukaguzi wa polepole unajaribu kuruka «mara hii tu». Ni bora kuugawa: linter na ukaguzi wa aina wa haraka baada ya kila mabadiliko, na seti kamili ya majaribio na E2E kabla ya neno «imekamilika». Hivyo mzunguko wa maoni unabaki mfupi na hauzuii kazi.

Kuchukulia ablation kama hatua ya kwanza

Unaweza kuzima vipengele vya harness kimoja kimoja ukaone ubora unashuka kiasi gani. Hili ni la manufaa, lakini ni la gharama na si hatua ya kwanza: kwanza kumbukumbu ya kushindwa inaonyesha kizuizi kiko wapi, na ablation inathibitisha dhana tu. Kushuka kwa sifuri kitu kinapozimwa hakumaanishi kwamba hakihitajiki — labda seti ya kazi iliyochaguliwa haikukitumia.

Ngazi ya ukomavu

Hitimisho

Jinsi ya kufanya wakala wa AI kuaminika: pima, tafuta kipengele dhaifu kutoka kumbukumbu ya kushindwa, fanya kosa liwe la gharama nafuu, funga mzunguko wa maoni, weka kumbukumbu kwenye faili, weka kazi moja kwa wakati, na tenganisha mtekelezaji na mkaguzi. Baada ya hapo tu mzunguko wa kujiendesha wenye sharti la kusimama linaloweza kuthibitishwa na mashine unakuwa salama. Kila hatua ya mpango huu inafundishwa kwa vitendo katika kozi ya harness engineering.