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) na ilionyesha takriban 11,600 mnamo 2026-10-27, chini ya mstari "Acha ku-prompt. Sanifu loop. Pata alama." Mnamo Julai 2026, README yake iligawanya mabadiliko hayo katika vizuizi sita vya ujenzi: scheduling, worktrees, skills, plugins na connectors, sub-agents, na durable memory inayohifadhiwa nje ya mazungumzo. README ya sasa haina tena orodha hiyo (iliyokaguliwa 2026-10-27), lakini bado inahifadhi hali ya loop kwenye faili nje ya mazungumzo.

Hazina hiyo inamtaja Boris Cherny, anayeongoza Claude Code katika Anthropic, kama mmoja wa watu waliotoa msukumo. Mstari wake ulioripotiwa sana ni:

Sifanyi prompt kwa Claude tena. Nina loop zinazoendeshwa ambazo hufanya prompt kwa Claude.

Hazina ya pili, AI-Builder-Club/skills, iko karibu na nyota 1,300 (kufikia 2026-10-27) na inataja majukumu hayo mawili moja kwa moja: "codebase harness" inayofanya hazina kuwa salama kwa wakala kuendesha majaribio na deployments, na "loop engineer" anayejenga workflows zinazoamka kwa trigger, kufanya kazi, na kuandika kile walichojifunza kwenye faili ya pamoja ili loop inayofuata iweze kukisoma.

Hakuna hazina iliyobuni mazoezi haya. Mtu yeyote ambaye amewahi kuendesha nightly build, linter katika continuous integration, au cron job inayofungua ticket tayari anajua muundo wake. Kinachopya ni kwamba mfanyakazi aliye ndani ya loop sasa si wa kideterministi (non-deterministic), jambo linalobadilisha kile 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 (agent)

Timer ndicho 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.

Kwanza, mpe wakala mtumiaji wake mwenyewe. Mtumiaji huyo ni sehemu ya mpaka wa usalama, kwa hivyo anamiliki /srv/agent pekee na si kingine chochote:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Kisha 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 wa baadaye na safu ya LEFT inayohesabu kuelekea chini. Matokeo matupu yanamaanisha kuwa timer haijawashwa, kwa sababu enable bila --now huipanga kwa ajili ya boot inayofuata pekee. TimeoutStartSec=1800 ni muhimu zaidi kuliko inavyoonekana. Huduma ya Type=oneshot huhesabiwa kuwa inaanza hadi script yake itakapomaliza, na systemd huzima muda wa kusubiri (timeout) kwa unit za oneshot kwa chaguo-msingi, kwa hivyo bila mstari huu, wakala anayekwama akisubiri maingizo ataiacha unit ikiwa imekwama katika hali ya kuwasha (activating) milele, na kila tick ya timer inayofuata itaikuta bado inaendelea na haitaanzisha chochote. Mstari huu ukiwa umewekwa, systemd husitisha uendeshaji baada ya dakika 30 na kuutia alama ya kufeli. Ikiwa utabadilisha unit kuwa Type=simple ya kawaida, TimeoutStartSec haitashughulikia tena uendeshaji wenyewe, na RuntimeMaxSec= ndiyo mipangilio inayoweka kikomo hicho. Soma uendeshaji kwa kutumia journalctl -u agent-loop.service -n 50.

Ikiwa unaendesha loop kutoka 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 na hali ya 1 wakati lock inashikiliwa, kwa hivyo uendeshaji wa pili hupotea kimya kimya badala ya kushindana na wa kwanza. usanidi wa systemd service na timer uleule hutumika kwa kazi yoyote ya muda mrefu kwenye seva, iwe ni wakala au la.

Boundary: mpe kila mchakato nakala yake binafsi

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 unapoisha, git worktree remove /srv/agent/work/triage-01 huondoa worktree, lakini ile iliyo safi pekee. Ikiwa tree ina faili ambazo hazijafuatiliwa (untracked) au faili zilizobadilishwa, au ina submodules, git itakataa hadi uongeze --force, ndiyo maana hati ya lango (gate script) hapa chini hulazimisha uondoaji kwenye njia inayofuta mchakato huo pekee. git worktree prune husafisha entries ambazo saraka zake zimetoweka. Loop zinazofanya kazi sambamba (parallel loops) huwa salama katika hatua hii, kwa sababu mawakala wawili kwenye branch mbili katika saraka mbili hawawezi kuandikiana juu ya kazi za mwenzake.

Boundary pia inahusu vitambulisho (credentials). Loop inayofanya kazi bila kusimamiwa hubeba token za muda mrefu, na kila mchakato ni fursa ya kuvujisha token kwenye log, commit, au muktadha wa model. Punguza wigo wa token kwa repository moja ambayo loop inagusana nayo, iweke nje ya mazingira (environment) ambayo shell ya wakala huiona pale inapowezekana, na usome jinsi ya kuweka siri nje ya mawakala wa AI kabla ya kuipa loop ufikiaji wa production. Kwa ulinzi mkali zaidi, weka loop nzima kwenye VM ya muda unayoweza kuifuta baada ya kila mchakato. Zana unayotumia pia huweka sehemu ya boundary 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 (isolation) unachohitaji kujijengea mwenyewe.

Uthibitishaji: lango linalofanya mzunguko kuwa salama

Hii ndiyo sehemu inayotofautisha mzunguko (loop) na cron job inayochapa 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 script hiyo. Bila -e, git fetch iliyofeli hupuuzwa na mzunguko unaendelea dhidi ya origin/main iliyopitwa na wakati. Bila -u, kosa la kuandika (typo) katika jina la variable hupanuka na kuwa string tupu, na usafishaji (cleanup) kisha unafanyika kwenye njia (path) isiyo sahihi badala ya kufeli kwa uwazi. Mstari wa mwisho hauna --force kwa makusudi: kama mzunguko uliacha faili ambazo hazijafuatiliwa au hazijakubaliwa (uncommitted) kwenye tree, git inakataa kuiondoa, na -e inamaliza mzunguko kwa hitilafu baada ya push badala ya kufuta kimya kimya kazi ambayo hakuna aliyeikubali.

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

Chagua lango linalofeli kwa uaminifu. Test suite inayofaulu kwenye diff tupu inafundisha mzunguko 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 ingekamata 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 inageuza jibu hilo kuwa kitu unachoweza kujithibitishia 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.

Mitindo ambayo hazina zinazovuma zinaiweka rasmi

Hazina ya loop-engineering inaorodhesha mitindo minane ya uzalishaji (kufikia 2026-10-27), na inafaa kusomwa kama menyu badala ya manifesto. Daily triage. Loop nyembamba inayoendeshwa kama GitHub Action na isiyohifadhi faili ya hali. Mlezi wa pull-request anayefuatilia maoni ya mapitio na kuyajibu. Kifagio cha continuous-integration kinachochukua builds zilizofeli (red builds). Kifagio cha dependency. Mtunzi wa changelog. Usafishaji baada ya merge. Triage ya issue.

Wanachoshiriki ni kazi finyu yenye lango dhahiri. "Rekebisha build inayofeli" ina sharti la kufaulu ambalo mashine inaweza kulisoma. "Boresha codebase" haina, kwa hivyo haijawahi kuwa loop. Inakuwa vurugu yenye ratiba.

Pia wanashiriki rekodi iliyoandikwa. Hazina zote mbili husukuma hali nje ya mazungumzo na kuingia kwenye faili ndani ya hazina: kile kilichoendeshwa, kile kilichopatikana, kile kilichoamuliwa. Faili hiyo ndiyo kumbukumbu ya loop, na ndiyo sababu loop ya pili inaweza kujenga juu ya kazi ya ile ya kwanza badala ya kugundua upya. Pia ndiyo njia unayotumia kukagua wakala baada ya tukio, kwa kuwa muktadha wa modeli hupotea wakati 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 vinaendelea, 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 muundo wa matokeo. Loop engineering huboresha mzunguko unaozunguka ujumbe huo: kichocheo kinachoanzisha mchakato, mazingira ya sandbox yanayotumika, 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 test, na kikomo cha matumizi kwenye akaunti ya mtoa huduma hufunika kila sehemu ya ufafanuzi huu. Framework huongeza violesura vya kuratibu, miundo ya kumbukumbu ya pamoja, na uelekezaji wa mawakala wengi (multi-agent routing), ambavyo ni muhimu pindi unapoendesha loop nyingi. Sio gharama ya lazima kwa ajili ya loop ya kwanza.

codebase harness ni nini?

Ni seti ya vitu vinavyoruhusu wakala (agent) kufanya kazi kwenye repository bila binadamu kuwepo: usanidi wa amri moja, majaribio (tests) yanayoendeshwa bila mwingiliano wa kibinadamu na yanayotoa taarifa wazi yakifeli, linter, na njia ya ku-deploy au kuhakiki mabadiliko. Neno hili linatokana na wimbi lilelile la 2026 la repository kama ilivyo kwa loop engineering. Jaribio la kivitendo ni rahisi: kama mchangiaji mpya wa kibinadamu hawezi kufika hatua ya kupata tests za kijani (green tests) kutoka kwenye clone kwa amri moja, basi hata wakala hawezi.

Ninawezaje kuzuia agent loop isiniletee bili kubwa?

Weka vikomo katika sehemu tatu. Weka TimeoutStartSec kwenye Type=oneshot systemd unit kama ile iliyo hapo juu ili mchakato uliokwama usitishwe (kwenye Type=simple service, kitu kinacholingana na hicho ni RuntimeMaxSec). Weka kikomo cha majaribio ya kurudia (retries) ndani ya script badala ya kuendelea kuzunguka hadi kufanikiwa. Weka kikomo cha matumizi ya fedha kwenye akaunti ya API, kwa sababu hicho ndicho kikomo 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 (small blast radius). Kurekebisha build iliyofeli (red build), kusasisha dependency, na kutengeneza upya changelog vyote vinafaa, kwa sababu test suite au diff inaweza kuthibitisha matokeo. Kazi zisizo na mwisho maalum kama refactoring au usanifu hazifai bado, kwa sababu hakuna kitu cha kukaguliwa na lango (gate), na loop isiyo na lango ni njia ya gharama kubwa ya kuzalisha deni la ukaguzi (review debt).