Ukaguzi mpya wa "ujuzi" (skills) 2,465 wa AI-agent yaliyoorodheshwa hadharani ulibaini kuwa zaidi ya nusu yanakiuka maelezo yaliyochapishwa, na asilimia 7.8 hata haziwezi kuchaguliwa na agent kwa sababu zinakosa metadata inayohitajika. Kasoro hizi zinatishia uaminifu wa mfumo wowote unaogundua na kupakia ujuzi huu kiotomatiki.

Kwa nini ukaguzi huu ni muhimu

Daftari za ujuzi za agent (Agent-skill registries) huwaruhusu watengenezaji kuchapisha uwezo unaoweza kutumika tena—vifurushi vya kodi ambavyo agent huria (autonomous agent) inaweza kuvitumia inapohitajika. Agent hukagua daftari, husoma YAML frontmatter ya kila ujuzi (kipande kidogo cha maandishi yaliyopangwa ambayo lazima yawe na angalau jina na maelezo), na kuamua ikiwa ujuzi huo unaendana na malengo yake. Ikiwa frontmatter imepotea au imeandikwa vibaya, ujuzi huo hutoweka kwenye menyu ya agent. Katika ulimwengu ambapo agent huria hupanga mikutano, kutatua matatizo ya seva, na mengineyo, ujuzi uliovunjika unaharibu mtiririko wa kazi.

Namba zinachofunua

  • 57.8 % ya ujuzi una angalau ukiukaji mmoja wa maelezo (spec violation).
  • 29.2 % zinataja jina ambalo halilingani na slug ya daftari (kitambulisho cha URL).
  • 18.1 % zina njia za kifurushi zilizovunjika au viungo vilivyokufa.
  • 7.8 % (ujuzi 192) hazina YAML frontmatter kabisa, jambo linalozifanya zisijulikane jina wala kuelezewa.
  • 3.8 % zina njia kamili za faili (absolute file paths) ambazo zipo kwenye mashine ya mwandishi pekee.
  • 2.4 % zinatumia vibaya uwanja wa allowed-tools, na kuufanya usiweze kusomwa na agent.
  • 2.1 % zinafunua funguo za API kupitia environment variables, jambo ambalo ni ishara ya hatari ya kiusalama.
  • 1.3 % zinaita zana za command-line za nje bila kuzitaja, jambo linalokiuka sheria ya uwezo wa kutumika popote (portability rule).

Uwezo wa kutumika popote (portability) unaonekana mara nyingi zaidi. Njia kamili (absolute path) kama /home/USER/.local/bin/tool hufanya kazi kwa mtengenezaji aliyeandika ujuzi huo lakini inafeli kwa mtumiaji mwingine yeyote, na kusababisha makosa ya wakati wa utendaji (runtime errors) ambayo ukaguzi wa kudumu (static checks) hauwezi kuyagundua.

Uchambuzi wa kina: kesi ya openclaw

Ukaguzi huo pia ulichunguza ujuzi 46 uliowekwa kwenye ghala (repository) la openclaw. Baada ya kuboresha skripti ya upimaji ili kuzuia tahadhari zisizo za kweli, mkaguzi aligundua kasoro 59 za kweli—ikikumbusha kuwa zana za ukaguzi (linters) zenye ukali uliopitiliza zinaweza kuleta matokeo hasi. Zana inapobainisha matatizo mengi yasiyo na madhara, watengenezaji huacha kuitumia, na matatizo ya kweli hupita bila kugunduliwa.

Kasoro mbili za openclaw zilionyesha faili ambazo hazipo tena kwenye ghala. Msimamizi (maintainer) aliunganisha marekebisho (fix) ambayo yanarejesha marejeleo yaliyopotea, akionyesha jinsi ombi moja la pull request linavyoweza kusafisha mnyororo wa utegemezi (dependency chain) uliovunjika.

Miitikio ya watengenezaji

Mkaguzi alifungua masuala (issues) kwenye ghala za asili za ujuzi huo. Ripoti moja ilikataliwa; msimamizi alidai kuwa neno "imevunjika" linapaswa kuhukumiwa kwa tabia halisi wakati wa utendaji, na si kwa ukaguzi wa faili wa kudumu. Mkaguzi alikubali kuwa tafsiri kali ya kuvunjika lazima iendane na jinsi ujuzi unavyofanya kazi kwa vitendo. Suala lingine lilikubaliwa, na marekebisho yake sasa yanapatikana.

Nani anayefaidika—au anayepoteza

  • Agent na watumiaji wa mwisho wanapata tabia inayotabirika na inayofanya kazi vizuri zaidi wakati daftari linapokuwa na ujuzi unaozingatia sheria na unaoweza kutumika popote.
  • Waandishi wa ujuzi wanapata sheria za uhakiki zilizo wazi zaidi zinazozuia makosa kabla ya kuchapishwa, na kupunguza mchakato mrefu wa kutatua masuala.
  • Waendeshaji wa daftari lazima wajenge au waunganishe mifumo ya uhakiki iliyo kali zaidi; bila hivyo, mfumo huo unahatarisha kupoteza uaminifu.

Uhakiki hafifu unahimiza uwasilishaji wa "haraka na holela" ambao unaweza kuharibu agent wakati wa utendaji (production), jambo linaloweza kusababisha muda wa kutofanya kazi wenye gharama kubwa au hatari za kiusalama.

Hoja kinyume: je, ukiukaji wote ni wa hatari?

Baadhi wanahoji kuwa "makosa" fulani hayana madhara. Jina lisilolingana linaweza lisiathiri agent inayochagua ujuzi kwa slug badala ya jina linaloonekana. Kusoma funguo za API kutoka kwenye environment inaweza kuwa uamuzi wa makusudi wa usanifu kwa ajili ya maendeleo ya ndani (local development). Hata hivyo, asilimia za ukaguzi huu zinachukulia ukiukaji wowote wa maelezo kama ukiukaji, jambo ambalo linaweza kutia chumvi athari za vitendo za baadhi ya masuala.

Nini cha kufuatilia baadaye

  • Linters zilizoboreshwa zinazotofautisha hitilafu za kweli za uwezo wa kutumika popote na mambo madogo yasiyo na madhara.
  • Viunganishi vya uhakiki upande wa daftari (registry-side validation hooks) vinavyokataliwa uwasilishaji usio na frontmatter inayohitajika au wenye njia kamili (absolute paths).
  • Ukaguzi unaoendeshwa na jamii unaofichua kasoro zilizojificha kabla hazijafikia agent wa utendaji (production agents).
  • Mapitio ya maelezo yanayoweza kutokea yanayofafanua uwanja usio na uwazi kama allowed-tools na

Idadi kubwa ya ujuzi wa wakala wa AI uliorodheshwa hadharani unashindwa ukaguzi wa msingi wa uzingatiaji, na sehemu kubwa ya ujuzi huo haiwezi kuchaguliwa kabisa. Matokeo haya yanasisitiza hitaji la wazi la uhakiki mkali zaidi, zana bora za linting, na utamaduni wa jamii unaochukulia uzingatiaji wa maelezo ya kiufundi (spec) kama hitaji la lazima la kuchapisha. Mpaka hatua hizo za kinga ziwekwe, mawakala wataendelea kukwama kwenye ujuzi dhaifu na usiohamishika.

Chanzo: https://dev.to/hyuga611/i-audited-2465-published-agent-skills-192-of-them-cannot-be-selected-the-way-the-spec-says-4k70