Every agent system faces the same uncomfortable trade off. You want a deep, well organized knowledge base that survives

Kila mfumo wa wakala unakabiliwa na mabadilishano magumu yaleyale. Unataka msingi wa maarifa uliopangwa vizuri na wenye kina ambao utadumu wakati wa mapitio ya kodi na historia ya git. Lakini pia unahitaji wakati wa utendaji (runtime) uwe na kasi na uwe na umakini. Mahitaji haya mawili yanapingana. Kadiri unavyohifadhi maelekezo mengi, ndivyo inavyokuwa rahisi kuyatupa yote kwenye prompt na kutegemea matokeo bora. Tumaini hilo lina gharama kubwa.

Katika mfumo wa ikolojia wa Agent Project Context, mvutano huu umegawanyika wazi katika tabaka mbili. APC inashughulikia udumu. APX inashughulikia kasi. Kuelewa jinsi zinavyoingiliana—na kwa nini APX inakataa kupakia kila ufafanuzi wa ujuzi mapema—kufichua mengi kuhusu uhandisi wa prompt kuliko miongozo mingi ya uboreshaji inavyoweza kukuambia.

Kumbukumbu na Injini

Kazi ya APC ni kudumu. Inahifadhi faili za ujuzi zinazoweza kutumika tena chini ya .apc/skills/ kama nyaraka za Markdown za kawaida. Kwa sababu faili hizi zipo ndani ya ghala lako (repository), zinaambatana na udhibiti wa toleo (version control). Unaweza kufungua pull request inayobadilisha utaratibu wa utekelezaji. Unaweza kufanya diff ya kurudisha sera ya usalama ya wiki sita zilizopita. Unaweza kukagua kwa usahihi kile ambacho wakala alipaswa kujua na lini. Ukaguzi huo ni muhimu wakati utekelezaji mbaya unapofanya kazi au mkaguzi wa uzingatiaji anapoanza kuuliza maswali.

APX, kwa upande mwingine, huishi katika wakati uliopo. Inasimamia mazungumzo halisi kati yako na modeli. Lengo lake si kuhifadhi maarifa bali kuyatumia kwa usahihi. Wakati APX inapoichukulia ujuzi kama mzigo wa kudumu, mfumo mzima hupunguza kasi. Dirisha la muktadha (context window) hujaa. Gharama za tokeni huongezeka. Mbaya zaidi, uangalifu wa modeli unatawanyika kwenye maelekezo ambayo hayahusiani na ombi la sasa.

Hii ndiyo sababu maudhui ya ujuzi hupakiwa kulingana na mahitaji.

Gharama Halisi ya Prompt Iliyovimba

Timu nyingi zinaelewa kuwa tokeni zina gharama. Timu chache zinatambua kuwa tokeni zisizohusika hupunguza usahihi.

Wakati APX inapoweka kila ujuzi unaopatikana kwenye kila awamu ya mazungumzo, prompt inakuwa na kelele nyingi. Modeli inapokea runbook ya utekelezaji, mwongozo wa usalama, marejeleo ya mtindo wa API, orodha ya ukaguzi wa majaribio, na FAQ ya kujiunga yote kwa wakati mmoja. Hata ukiwa na dirisha kubwa la muktadha, ubora wa uwezo wa kufikiri hupungua wakati modeli inapaswa kwanza kupitia kelele ili kupata taarifa muhimu. Inaweza kushikilia hitaji la usalama lililokusudiwa kwa utekelezaji wa uzalishaji (production) wakati ikijibu swali kuhusu mpangilio wa majaribio ya ndani. Inaweza kuleta mawazo ya uongo (hallucinate) ya hatua kutoka kwenye orodha ya ukaguzi wa toleo kwenye marekebisho rahisi ya hitilafu. Kila aya ya ziada ya maandishi yasiyohusika ni kizuizi kinachosubiri kutokea.

Hesabu ni rahisi. Awamu nyingi za mazungumzo hazihitaji ujuzi mwingi. Ikiwa unauliza marekebisho ya haraka ya logi ya makosa, hauhitaji maandishi kamili ya runbook ya utekelezaji au mwongozo wa kuimarisha usalama. Unahitaji modeli ionee kosa, ielewe kanuni za mradi wako, na ifanye marekebisho kwenye faili sahihi. Kupakia maudhui ya ujuzi yasiyohusika hakusaidii modeli kufanya hili. Inailazimisha modeli kuchuja data zisizo na faida kabla hata haijaanza kufanya kazi kwenye tatizo lako halisi.

Jinsi Upakiaji wa Kulingana na Mahitaji Unavyofanya Kazi

Utaratibu huu ni rahisi lakini uliokusudiwa. APC inaendelea kushikilia ukweli wa msingi. Fafanuzi zako za ujuzi zinabaki pale zinapostahili: katika .apc/skills/<name>.md.

APX hainakili faili hizo kwenye kumbukumbu hai. Badala yake, inatengeneza daftari fupi la majina ya ujuzi. Modeli huona orodha hii na kuelewa kuwa kuna katalogi iliyopo. Ikiwa inahitaji kupitia au kuthibitisha ni uwezo gani yaliyopo, inaweza kuitisha wito wa list_skills. Hii inampa uoni bila kuongeza wingi wa data.

Wakati kazi inahitaji sintaksi kamili, hatua za kina, au vikwazo maalum vilivyomo kwenye faili ya ujuzi, modeli huita load_skill. Katika hatua hiyo, na hatua hiyo tu, APX inachukua maudhui kamili ya Markdown kutoka APC na kuingiza kwenye muktadha. Maelekezo yanakuja tayari kutumika, yanatumika mara moja kwa madhumuni yake, na mfumo unajiepusha na kuyabeba kama mzigo usio na faida.

Fikiria tofauti kati ya kuingiza maktaba (importing a library) na kubandika kila ufafanuzi wa kazi (function definition) kwenye faili yako kuu. Njia moja huifanya kodi yako iweze kupitika kwa urahisi. Njia nyingine inatengeneza vurugu ambayo inafanya kazi kwa bahati mbaya tu.

Nani Anayeshinda Ujuzi Unapogongana

APX pia hudhibiti utaratibu wa kipaumbele ulio wazi inapopakia ujuzi. Si kila mazingira ni sawa, na ushauri wa jumla haupaswi kamwe kupuuza maarifa ya ndani.

Project skills una kipaumbele cha juu zaidi. Faili hizi zipo kwenye repozitari yako ya sasa chini ya .apc/skills/. Zinahifadhi kanuni maalum za timu yako, viunganishi (wrappers) vyako vya kipekee, viwango vya majina vya zamani, na mfululizo wa zana (toolchain) zako maalum. Ikiwa mradi wako unafafanua njia yake ya kushughulikia uhamiaji wa hifadhidata (database migrations), ufafanuzi huo ndio utakaoshinda.

Ujuzi wa kimataifa (Global skills) unakuja baada ya hapo. Haya yanahusu mifumo inayotumika katika shirika zima ambayo inatumika wakati mradi wenyewe haujatoa maelekezo. Yanafanya kazi kama maktaba ya kawaida (standard library).

Ujuzi wa ndani wa wakati wa utendaji (Built-in runtime skills) uko chini kabisa kama chaguo la mwisho (fallback). Yanashughulikia uwezo wa jumla ambao kila wakala (agent) anapaswa kuelewa lakini hakuna mradi maalum uliopata kujisumbua kuufafanua upya.

Mtazamo huu wa tabaka unamaanisha kuwa repozitari yako inadhibiti tabia yake yenyewe. Ujuzi wa kimataifa au wa ndani hauwezi kuchukua udhibiti kwa bahati mbaya wa mchakato wa kazi (workflow) ambao timu yako imebadilisha kwa makusudi.

Jinsi Hii Inavyoonekana Kiutendaji

Wazia kazi ya kawaida ya matengenezo. Mwanachama wa timu anabandika logi ya hitilafu (error log) kwenye mazungumzo. Traceback inaonyesha rejea moja ya null kwenye moduli ya huduma (utility module). Suluhisho huenda likawa mistari miwili ya uandishi wa kuzuia makosa (defensive coding).

Katika mfumo usio na upakiaji wa mahitaji (on-demand loading), APX ingejaza muktadha (context) kwa kila ujuzi unaoujua. Sasa modeli ina kurasa arobaini za maandishi za kuzingatia kabla ya kugusa mistari hiyo miwili. Inaona orodha ya ukaguzi wa toleo (release checklist) na kujiuliza ikiwa inapaswa kuongeza toleo. Inaona mwongozo wa usalama na kufikiria uhakiki wa pembejeo (input validation) kwenye kazi (function) inayohitaji tu ukaguzi wa null. Inaona mwongozo wa utekelezaji (deployment runbook) na kuanza kufikiria mazingira ya majaribio (staging environments). Modeli inapoteza mwelekeo. Jibu linachukua muda mrefu zaidi. Kipimo cha tokeni kinazunguka kwa kasi.

Kwa usanidi wa APX wa mahitaji (on-demand design), modeli inaona majina tu. Inajua kuwa [release-checklist], [security-guide], [deployment-runbook], na [error-handling] zipo. Inapuuza tatu za kwanza. Inaweza kupakia [error-handling] ikiwa kanuni za mradi wako kwa usalama wa null ni maalum. Inarekebisha hitilafu hiyo. Ujuzi usiohusika haukuwahi kuingia kwenye dirisha la muktadha (context window). Modeli ilibaki imejikita kwa sababu prompt ilibaki safi.

Mantiki hiyo hiyo inafanya kazi wakati kazi yenyewe inapokuwa tata. Ikiwa baadaye utamwomba wakala kuandaa utekelezaji wa uzalishaji (production deployment), inaweza kupakia mwongozo wa utekelezaji, kushauriana na mwongozo wa usalama, na kufuata orodha ya ukaguzi wa toleo wakati tu hatua hizo zinapohitajika. Maarifa yalikuwepo wakati wote. Yalikuwa yanasubiri tu wakati sahihi.

Nidhamu ya Prompt kama Usanifu

Utengano kati ya APC na APX si jambo la kiufundi tu la utekelezaji. Ni falsafa ya nidhamu ya prompt. APC huhifadhi maarifa milele, na kuyafanya yaweze kupitiwa, kuwa na matoleo, na kuwa salama. APX huamua ni kiasi gani cha maarifa hayo kinastahili kupata nafasi katika muktadha hai sasa hivi.

Katalogi tajiri ya ujuzi ni rasilimali. Prompt iliyovimba ni mzigo. Lengo ni kuweka muktadha wako unaoweza kuhamishika bila kuufanya uwe hai wakati wote. Repozitari yako inapaswa kuwa na kila maelekezo ambayo timu yako imewahi kuandika, lakini wakala anapaswa kusoma tu yale yanayosaidia katika kazi ya sasa.

Ikiwa mfumo wako unailazimisha modeli kubeba kila sehemu ya ujuzi katika kila awamu, haujatengeneza msaidizi mwenye akili. Unatengeneza mkutubi anayevuta kumbukumbu nzima hadi kwenye kila swali la meza ya marejeo. Hifadhi kila kitu. Pakia kile kinachojali. Hivyo ndivyo unavyowafanya mawakala kuwa na kasi, muktadha uwe safi, na uwezo wa kufikiri uwe mkali.