Uhandisi wa mzunguko (loop engineering) ni nini?

Maana ya uhandisi wa mzunguko (loop engineering)

Uhandisi wa mzunguko ni mbinu ya kubuni mzunguko wa mara kwa mara ambao wakala wa AI huufuata: nini kinachomwamsha, nini anachoweza kugusa, jinsi matokeo yake yanavyokaguliwa, na nini kinachomsimamisha. Uhandisi wa prompt (prompt engineering) huunda ujumbe mmoja kwa ajili ya modeli. Uhandisi wa mzunguko huunda mchakato unaotuma maelfu ya ujumbe wakati umelala. Kitengo cha kazi huhama kutoka kwenye prompt na kwenda kwenye mzunguko.

Kwa ufupi: unaacha kuandika maelekezo na kuanza kuandika mfumo wa udhibiti. Wakala bado anahitaji maelekezo mazuri, lakini yanakuwa sehemu moja ndani ya mzunguko unaoendeshwa kwa ratiba, unaofanya kazi kwenye nakala iliyotengwa ya msimbo wako, unaothibitisha matokeo yake kwa jaribio, na unaoacha kazi wakati bajeti inapoisha.

Kwa nini neno hili liliibuka mwaka 2026

Jina hili linawekwa rasmi hadharani hivi sasa. Hazina ya GitHub cobusgreyling/loop-engineering ilivuka nyota 9,600 ndani ya miezi miwili tangu kuonekana kwake kwa mara ya kwanza (kufikia Julai 2026), chini ya mstari "Acha kuandika prompt. Sanifu mzunguko. Pata alama." Inakusanya mabadiliko hayo katika vizuizi sita vya ujenzi: ratiba, worktrees, ujuzi, plugins na viunganishi, mawakala wadogo (sub-agents), na kumbukumbu ya kudumu inayohifadhiwa nje ya mazungumzo.

Inamnukuu Boris Cherny, anayeongoza Claude Code katika Anthropic:

Siandiki tena prompt kwa Claude. Nina mizunguko inayoendeshwa ambayo humwandikia Claude prompt.

Hazina ya pili, AI-Builder-Club/skills, inakaribia nyota 1,100 (kufikia Julai 2026) na inataja majukumu hayo mawili moja kwa moja: "codebase harness" inayofanya hazina kuwa salama kwa wakala kuendesha majaribio na deployments ndani yake, na "loop engineer" anayejenga mitiririko ya kazi (workflows) inayozinduka kwa kichocheo (trigger), kufanya kazi, na kuandika yale waliyojifunza kwenye faili iliyoshirikiwa ili mzunguko unaofuata uweze kuisoma.

Hakuna hazina kati ya hizo iliyobuni mbinu hiyo. Mtu yeyote ambaye amewahi kuendesha nightly build, linter katika continuous integration, au cron job inayofungua tiketi tayari anajua muundo wake. Kinachobadilika ni kwamba mfanyakazi aliye ndani ya mzunguko sasa si wa kideterministi (non-deterministic), jambo ambalo hubadilisha kile ambacho mashine inayozunguka inapaswa kufanya.

Sehemu nne za loop

Kila loop inayofanya kazi ina sehemu hizi nne, na loop inayokosa mojawapo ndiyo inayokufanya uamke saa 9 usiku.

• Trigger. Tukio linaloanzisha mchakato: timer, webhook, pull request mpya, au alert.
• Boundary. Mafaili, credentials, na mtandao ambao agent anaweza kufikia wakati wa mchakato huo.
• Verification. Uhakiki wenye exit code unaoamua kama matokeo ya mchakato huo yahifadhiwe au yatupwe.
• Budget. Kikomo cha token, muda, na fedha kinachomaliza mchakato bila kujali kama umefanikiwa au la.

Soma sehemu hizo nne kama maswali na utakuwa na tathmini ya usanifu kwa ajili ya agent yeyote unayekaribia kumwacha akiendelea kufanya kazi.

Kichochezi: kinachokiwezesha wakala

Timer ndiyo kichochezi rahisi zaidi, na kwenye seva ya Linux, systemd timer ni bora kuliko cron kwa sababu inatunza kumbukumbu (logs), inajaribu tena kulingana na masharti yako, na haitaanzisha nakala ya pili ya unit ambayo bado inaendelea kufanya kazi. Sifa hiyo ya mwisho huondoa hitilafu ya kawaida ya mwingiliano katika loops za wakala: mbio mbili zinazohariri tawi moja.

Andika unit kwenye /etc/systemd/system/agent-loop.service:

[Unit]
Description=Agent loop: triage open issues
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent
WorkingDirectory=/srv/agent/repo
ExecStart=/srv/agent/bin/loop.sh
TimeoutStartSec=1800

Na timer kwenye /etc/systemd/system/agent-loop.timer:

[Unit]
Description=Run the triage loop every 30 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=30min
Unit=agent-loop.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now agent-loop.timer
systemctl list-timers agent-loop.timer

systemctl list-timers inapaswa kuonyesha safu ya NEXT yenye muda ujao na safu ya LEFT inayohesabu kuelekea chini. Matokeo matupu yanamaanisha kuwa timer haijawezeshwa, kwa sababu enable bila --now hupanga ratiba hiyo kwa ajili ya boot inayofuata pekee. TimeoutStartSec=1800 ni muhimu zaidi kuliko inavyoonekana: wakala anayekwama akisubiri ingizo atashikilia unit ikiwa hai milele, na timer haitawaka tena. Soma utekelezaji kwa journalctl -u agent-loop.service -n 50.

Ikiwa unaendesha loop kutoka kwa cron badala yake, ongeza ulinzi wako wa mwingiliano, kwa sababu cron itaanza nakala ya pili bila kusita:

*/30 * * * * /usr/bin/flock -n /tmp/agent-loop.lock /srv/agent/bin/loop.sh

flock -n hutoka mara moja ikiwa na status 1 wakati lock imeshikiliwa, kwa hivyo utekelezaji wa pili hupotea kimya kimya badala ya kushindana na wa kwanza. Setup ile ile ya systemd service na timer inatumika kwa kazi yoyote ya muda mrefu kwenye seva, iwe ni wakala au la.

Upeo: kila mchakato uwe na nakala yake

Wakala anayebadilisha working tree yako ni wakala anayeweza kupoteza kazi yako ambayo haijafanyiwa commit. Git worktrees hutatua hili kwa gharama nafuu: kila mchakato hupata saraka yake na branch yake, huku zikishiriki hifadhi moja ya object.

cd /srv/agent/repo
git worktree add -b loop/triage-01 /srv/agent/work/triage-01 origin/main
git worktree list

git worktree list huchapisha mstari mmoja kwa kila tree ikiwa na njia yake, commit, na branch. Mchakato unapomalizika, git worktree remove /srv/agent/work/triage-01 hufuta saraka hiyo, na git worktree prune husafisha entries ambazo saraka zake zimetoweka. Loop zinazofanya kazi sambamba huwa salama katika hatua hii, kwa sababu mawakala wawili kwenye branch mbili katika saraka mbili hawawezi kuandikiana juu ya kazi ya mwenzake.

Upeo pia unahusu vitambulisho (credentials). Loop inayofanya kazi bila kusimamiwa hushikilia token za muda mrefu, na kila mchakato ni fursa ya kuvujisha token kwenye log, commit, au muktadha wa model. Punguza upeo wa token kwenye repository moja tu inayotumiwa na loop hiyo, iweke nje ya mazingira yanayoonekana na shell ya wakala pale inapowezekana, na usome jinsi ya kuzuia siri zisivuje kwenye AI agents kabla ya kuipa loop ufikiaji wa production. Kwa ulinzi mkali zaidi, weka loop nzima kwenye VM ya muda unayoweza kuifuta baada ya kila mchakato. Chombo unachotumia pia huweka sehemu ya upeo kabla hujaandika chochote, kwa hivyo inafaa kusoma jinsi sandbox inayodhibitiwa ya Cowork inavyolinganishwa na Claude Code kwenye mashine yako kabla ya kuamua ni kiasi gani cha utengano unachohitaji kujijengea.

Uthibitishaji: lango linalofanya mzunguko kuwa salama

Hii ndiyo sehemu inayotofautisha mzunguko (loop) na kazi ya cron inayochapa maandishi tu. Matokeo ya wakala (agent) ni pendekezo. Lango ndilo linaloamua.

#!/usr/bin/env bash
set -euo pipefail

repo=/srv/agent/repo
branch="loop/$(date -u +%Y%m%dT%H%M%SZ)"
tree="/srv/agent/work/$(basename "$branch")"

cd "$repo"
git fetch --quiet origin
git worktree add -b "$branch" "$tree" origin/main
cd "$tree"

# the agent's own command runs here, in non-interactive mode

if ! npm test; then
  echo "gate failed: discarding $branch" >&2
  cd "$repo"
  git worktree remove --force "$tree"
  exit 1
fi

git push origin "$branch"
cd "$repo"
git worktree remove "$tree"

set -euo pipefail inafanya kazi ya kweli katika hati hiyo. Bila -e, git fetch iliyofeli hupuuzwa na mchakato unaendelea kutumia origin/main iliyopitwa na wakati. Bila -u, kosa la uchapaji katika jina la variable hupanuka na kuwa string tupu, na usafishaji (cleanup) kisha unafanyika kwenye path isiyo sahihi badala ya kufeli kwa uwazi.

Kizuizi cha if ! npm test ndiyo wazo zima. Exit code ya ukaguzi unaouamini tayari, kama vile suite yako ya majaribio au type checker, ndiyo inayoamua kama branch itatumwa (pushed) au kuharibiwa. Mzunguko usio na lango huzalisha kazi ambayo hakuna mtu aliye na muda wa kuikagua, jambo ambalo ni mbaya zaidi kuliko kutokuwa na kazi yoyote. Mzunguko wenye lango huzalisha branch ambayo tayari imepita kigezo kilekile ambacho branch ya binadamu lazima ipite. Lango la kijani (green gate) halisemi chochote kuhusu kiasi cha code ambacho wakala amegusa ili kufika hapo, kwa hivyo ni vyema kuoanisha ukaguzi huo na maelekezo ya kudumu kama kanuni inayomfanya wakala achukue mabadiliko madogo zaidi yanayofanya kazi, ambayo huweka diff kuwa ndogo kiasi kwamba kuikagua bado ni rahisi.

Chagua lango linalofeli kwa uaminifu. Suite ya majaribio inayofaulu kwenye diff tupu humfundisha wakala kuwa kutofanya chochote ni mafanikio. Repositories zenye majaribio dhaifu hupata mizunguko dhaifu, ndiyo maana repositories zinazovuma huweka "kuifanya codebase iwe tayari kwa wakala" kabla ya "kuandika mzunguko". Ikiwa unataka kujua kama suite yako ingegundua regression badala ya kutekeleza mistari tu, mutation testing ndiyo ukaguzi unaojibu hilo, na wakala anayerejesha ripoti ya ushahidi inayoweza kuendeshwa tena badala ya kukuomba usome diff yake hugeuza jibu hilo kuwa kitu unachoweza kukithibitisha mwenyewe.

Bajeti: nini kinazuia mzunguko wa gharama

Wakala anayejaribu tena bila kikomo ni wakala anayesababisha bili isiyo na ukomo. Kila mzunguko lazima uwe na ukomo wa muda wa saa, unaotekelezwa na TimeoutStartSec hapo juu; idadi ya majaribio ndani ya script yako; na ukomo wa matumizi unaotekelezwa na akaunti ya mtoa huduma. Kisha, weka kumbukumbu ya gharama ya kila mzunguko, ili uweze kuona mzunguko ukipoteza ufanisi kabla ya ankara kufika. Udhibiti wa gharama kwa wakala wa VPS anayefanya kazi muda wote inashughulikia upande wa uhasibu, na kusimamia muktadha anaobeba wakala kati ya zamu inashughulikia kigezo kikubwa zaidi cha gharama kwa kila mzunguko, kwa sababu mzunguko unaosoma tena repository ileile kila dakika 30 hulipia gharama hiyo kila dakika 30.

Gharama ndiyo sababu inayofanya mizunguko mifupi mara nyingi kuwa bora kuliko kikao kimoja kirefu. Mzunguko unaoanza upya, unaofanya kazi moja mahususi na kisha kuzima, huweka muktadha wake ukiwa mdogo. Kikao kilichoachwa wazi kwa saa nane hubeba kila kosa la awali katika historia yake, na hulipia nakala nzima ya mazungumzo hayo katika kila zamu.

Mifumo inayofafanuliwa na hazina zinazovuma

Hazina ya loop-engineering inaorodhesha mifumo saba ya uzalishaji, na inafaa kusomwa kama orodha ya chaguzi badala ya ilani. Uainishaji wa kila siku (Daily triage). Msimamizi wa pull-request anayefuatilia maoni ya uhakiki na kuyajibu. Kisafishaji cha continuous-integration kinachochukua build zilizofeli. Kisafishaji cha dependency. Mtayarishaji wa changelog. Usafishaji baada ya merge. Uainishaji wa issue.

Kitu wanachoshiriki ni kazi finyu yenye kigezo dhahiri cha kufaulu. "Rekebisha build inayofeli" ina sharti la kufaulu ambalo mashine inaweza kulisoma. "Boresha codebase" haina sharti hilo, kwa hivyo haiwezi kuwa loop. Inageuka kuwa fujo yenye ratiba.

Pia zinashiriki rekodi iliyoandikwa. Hazina zote mbili huondoa hali ya sasa kutoka kwenye mazungumzo na kuiweka kwenye faili ndani ya hazina: nini kiliendeshwa, nini kilipatikana, na nini kiliamuliwa. Faili hiyo ndiyo kumbukumbu ya loop, na ndiyo sababu loop ya pili inaweza kujenga juu ya kazi ya ile ya kwanza badala ya kuigundua upya. Pia ndiyo njia unayotumia kukagua wakala baada ya tukio, kwa sababu muktadha wa model hupotea mara tu run inapoisha. Uratibu wa moja kwa moja ni njia tofauti, na kikao kimoja cha Claude Code kinaweza kukabidhi kazi kwa kingine kwenye mashine hiyo hiyo wakati vyote vikiwa bado vinafanya kazi, lakini hakuna chochote katika mabadilishano hayo kinachodumu zaidi ya kikao chochote, kwa hivyo faili inabaki kuwa sehemu unayoisoma baadaye.

Mahali ambapo loops hushindwa

Kushindwa huku ni kwa kawaida, na hujirudia katika timu mbalimbali.

• Hakuna kizuizi. Matokeo hujilimbikiza, hakuna anayeyakagua, imani hupotea, na loop huzimwa.
• Mwingiliano. Runs mbili kwenye branch moja, au agents wawili kwenye working tree moja, husababisha migogoro ambayo agent hujaribu kuitatua.
• Silent drift. Loop inaendelea kupita kwa sababu ukaguzi ni dhaifu mno kushindwa.
• Upeo usio na kikomo. Trigger inayofanya kazi kila commit katika repository yenye shughuli nyingi hugeuka kuwa tatizo la gharama ndani ya siku moja.

Kila moja ina suluhisho sawa: punguza ukubwa wa job, kaza ukaguzi, na weka log ya run hiyo. Ikiwa huwezi kuelezea sharti la kupita (pass condition) katika sentensi moja, job hiyo haijawa tayari kwa ajili ya otomatiki.

Kuanza bila msamiati maalum

Hauhitaji mfumo wa ziada (framework). Seva ndogo ya Linux inayowaka muda wote, hazina ya git (git repository) ambayo suite yake ya majaribio inashindwa inapopaswa, timer moja ya systemd, na hati ya shell (shell script) yenye if ndani yake vinatosha kuunda mzunguko kamili. Hapo ndipo watu wengi wanapaswa kuanzia, kwa sababu maswali ya usanifu yanajibiwa kwa kuendesha kitu chenyewe badala ya kuchagua zana. Mzunguko mmoja ukiwa thabiti, kuendesha wa pili ni suala la kuongeza timer nyingine na worktree nyingine. Tazama jinsi ya kuendesha wakala wa AI wa kuandika msimbo kwenye VPS kwa usanidi wa msingi, na chaguzi za sasa za wakala wa AI wa kujihostia ikiwa unataka wakala huyo aendeshe kwenye vifaa unavyovimiliki.

FAQ

Je, loop engineering ni tofauti na prompt engineering?

Prompt engineering huboresha ujumbe mmoja: mpangilio wa maneno, mifano, na umbizo la matokeo. Loop engineering huboresha mzunguko unaozunguka ujumbe huo: kichocheo kinachoanzisha mchakato, mazingira ya sandbox inapoendeshwa, ukaguzi unaokubali au kukataa matokeo, na bajeti inayomaliza mchakato huo. Bado unahitaji prompt nzuri ndani ya loop. Prompt huacha kuwa kitu unachokirekebisha kila siku, kwa sababu lango la ukaguzi na kichocheo huwa na athari kubwa zaidi kwenye matokeo.

Je, ninahitaji framework ili kujenga agent loop?

Hapana. systemd timer, git worktree kwa kila mchakato, shell script inayomalizia na amri ya majaribio, na kikomo cha matumizi kwenye akaunti ya mtoa huduma hufunika kila sehemu ya ufafanuzi huu. Framework huongeza violesura vya kuratibu, miundo ya kumbukumbu iliyoshirikiwa, na uelekezaji wa mawakala wengi, ambavyo ni muhimu unapoendesha loop kadhaa. Sio gharama ya lazima kwa loop ya kwanza.

codebase harness ni nini?

Ni seti ya vitu vinavyomruhusu wakala kufanya kazi kwenye repository bila binadamu kuwepo: usanidi wa amri moja, majaribio yanayoendeshwa bila mwingiliano na kutoa taarifa za makosa kwa uwazi, linter, na njia ya kupeleka au kuhakiki mabadiliko. Neno hili linatokana na wimbi lilelile la repository za mwaka 2026 kama loop engineering. Jaribio la kivitendo ni rahisi: kama mchangiaji mpya wa kibinadamu hawezi kufika hatua ya kupata majaribio yaliyofaulu (green tests) kwa amri moja baada ya kufanya clone, basi hata wakala hawezi.

Ninawezaje kuzuia agent loop isisababishe bili kubwa?

Iwekee kikomo katika sehemu tatu. Weka TimeoutStartSec kwenye systemd unit ili mchakato uliokwama uweze kusitishwa. Punguza idadi ya majaribio ya kurudia (retries) ndani ya script badala ya kuendelea kurudia hadi kufanikiwa. Weka kikomo cha matumizi ya pesa kwenye akaunti ya API, kwa sababu hicho ndicho kizuizi pekee ambacho wakala hawezi kukikwepa. Kisha rekodi gharama kwa kila mchakato, kwa sababu loop inayoongeza gharama mara mbili kwa kawaida ni loop ambayo wigo wake umeongezeka kimyakimya.

Ni kazi zipi zinafaa kugeuzwa kuwa loop kwanza?

Chagua kazi yenye sharti la kufaulu linaloweza kusomwa na mashine na yenye athari ndogo ikikosewa. Kurekebisha build iliyofeli, kusasisha dependency, na kutengeneza upya changelog vyote vinafaa, kwa sababu test suite au diff inaweza kuthibitisha matokeo. Kazi zisizo na mwisho kama refactoring au usanifu hazifai bado, kwa sababu hakuna kitu cha kukaguliwa na lango, na loop isiyo na lango ni njia ya gharama kubwa ya kuzalisha deni la ukaguzi.