Loop engineering ni nini? Ufafanuzi rahisi

Maana ya loop engineering

Loop engineering ni mbinu ya kubuni mzunguko wa mara kwa mara ambao AI agent huufuata: nini kinachoiwasha, nini inaweza kugusa, jinsi matokeo yake yanavyokaguliwa, na nini kinachoisimamisha. Prompt engineering hutengeneza ujumbe mmoja kwa ajili ya model. Loop engineering hutengeneza mchakato unaotuma maelfu ya ujumbe wakati umelala. Kitengo cha kazi huhama kutoka kwenye prompt na kwenda kwenye loop.

Kwa ufupi: unaacha kuandika maelekezo na kuanza kuandika mfumo wa udhibiti. Agent bado anahitaji maelekezo mazuri, lakini yanakuwa sehemu moja ndani ya mzunguko unaoendeshwa kwa ratiba, unaofanya kazi katika nakala iliyotengwa ya code yako, unaothibitisha matokeo yake kwa kutumia test, na unaoacha kazi wakati bajeti inapoisha.

Kwa nini neno hili liliibuka mwaka 2026

Jina hili linaanza kutumika 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 kauli mbiu: "Acha kuandika maelekezo (prompting). Sanifu mzunguko (loop). Pata matokeo." Inakusanya mabadiliko haya katika vizuizi sita vya msingi: upangaji (scheduling), worktrees, ujuzi (skills), plugins na viunganishi (connectors), mawakala wadogo (sub-agents), na kumbukumbu ya kudumu inayohifadhiwa nje ya mazungumzo.

Inamnukuu Boris Cherny, anayeongoza Claude Code katika Anthropic:

Siandiki tena maelekezo kwa Claude. Nina mizunguko (loops) inayoendesha maelekezo kwa Claude.

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) inayowaka kwa kichocheo (trigger), kufanya kazi, na kuandika yale waliyojifunza kwenye faili la pamoja ili mzunguko unaofuata uweze kuyasoma.

Hakuna hazina kati ya hizi iliyobuni mbinu hii. Mtu yeyote aliyewahi kuendesha nightly build, linter katika continuous integration, au cron job inayofungua tiketi tayari anajua mfumo huu. Kinachobadilika ni kwamba mfanyakazi aliye ndani ya mzunguko sasa si wa kideterministi (non-deterministic), jambo linalobadilisha kile ambacho mashine inayozunguka mfumo huo inapaswa kufanya.

Sehemu nne za loop

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

• Trigger. Tukio linaloanzisha mzunguko: timer, webhook, pull request mpya, au alert.
• Boundary. Mafaili, credentials na mtandao ambao agent anaweza kufikia wakati wa mzunguko huo.
• Verification. Uhakiki wenye exit code unaoamua kama matokeo ya mzunguko yatahifadhiwa au yatafutwa.
• Budget. Kikomo cha token, muda na gharama kinachomaliza mzunguko 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.

Trigger: kile kinachochochea wakala

Timer ndiyo kichocheo cha kawaida zaidi, na kwenye seva ya Linux, systemd timer ni bora kuliko cron kwa sababu inatunza kumbukumbu (logs), inajaribu tena kulingana na masharti yako, na haitazindua nakala ya pili ya unit ambayo bado inaendelea kufanya kazi. Sifa hiyo ya mwisho huondoa hitilafu ya kawaida ya mwingiliano katika loops za wakala: nakala 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 wa baadaye na safu ya LEFT inayohesabu kuelekea chini. Matokeo matupu yanamaanisha kuwa timer haijawashwa, kwa sababu enable bila --now hupanga ratiba hiyo kwa ajili ya boot inayofuata pekee. TimeoutStartSec=1800 ni muhimu zaidi kuliko inavyoonekana: wakala anayekwama akisubiri maelekezo atashikilia unit hiyo kuwa hai milele, na timer haitawaka tena. Soma utekelezaji (run) kwa kutumia journalctl -u agent-loop.service -n 50.

Ikiwa unaendesha loop kutoka kwa cron badala yake, ongeza ulinzi wako mwenyewe dhidi ya mwingiliano, kwa sababu cron itazindua 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 imeshikiliwa, hivyo utekelezaji wa pili hupotea kimya kimya badala ya kushindana na ule 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 unapoisha, git worktree remove /srv/agent/work/triage-01 hufuta saraka hiyo, na git worktree prune husafisha entries ambazo saraka zake zimetoweka. Loops 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 kwa repository moja tu ambayo loop inagusia, iweke nje ya mazingira yanayoonekana na shell ya wakala pale inapowezekana, na usome jinsi ya kuweka siri nje ya AI agents kabla ya kuipa loop ufikiaji wa uzalishaji (production). Kwa ulinzi mkali zaidi, weka loop nzima kwenye VM ya muda unayoweza kuifuta baada ya kila mchakato. Zana unayotumia pia huweka sehemu ya upeo kabla hujaandika chochote, kwa hivyo inafaa kusoma jinsi Cowork's managed sandbox 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 kazi ya cron inayochapa maandishi tu. Matokeo ya wakala 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 mzunguko unaendelea kutumia origin/main iliyopitwa na wakati. Bila -u, kosa la kuandika jina la kigezo (variable) litapanuka na kuwa kamba tupu (empty string), na usafishaji utafanyika kwenye njia (path) isiyo sahihi badala ya kufeli kwa uwazi.

Kizuizi cha if ! npm test ndiyo kiini cha wazo zima. Msimbo wa kutoka (exit code) wa ukaguzi unaouamini tayari, kama vile suite yako ya majaribio au kikagua aina (type checker), ndicho kinachoamua kama tawi (branch) litasukumwa (push) au litafutwa. Mzunguko usio na lango huzalisha kazi ambayo hakuna mtu aliye na muda wa kuikagua, jambo ambalo ni baya zaidi kuliko kutofanya kazi yoyote. Mzunguko wenye lango huzalisha tawi ambalo tayari limepita kizingiti kilekile ambacho tawi la mchangiaji wa kibinadamu lazima lipite. Lango la kijani halisemi chochote kuhusu kiasi cha msimbo 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 tofauti (diff) kuwa ndogo kiasi kwamba kuikagua bado ni rahisi.

Chagua lango linalofeli kwa uaminifu. Suite ya majaribio inayofaulu kwenye tofauti tupu (empty diff) inaufundisha mzunguko kuwa kutofanya chochote ni mafanikio. Hazina (repositories) zenye majaribio dhaifu hupata mizunguko dhaifu, ndiyo maana hazina zinazovuma huweka "kuifanya codebase kuwa 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 tofauti zake hubadilisha jibu hilo kuwa kitu unachoweza kukithibitisha mwenyewe.

Bajeti: nini kinazuia utekelezaji

Wakala anayejaribu tena bila kikomo ni wakala anayesababisha gharama zisizo na ukomo. Kila kitanzi lazima kiwe na ukomo wa muda wa saa, unaotekelezwa na TimeoutStartSec hapo juu; idadi ya majaribio ndani ya hati yako; na ukomo wa matumizi unaotekelezwa na akaunti ya mtoa huduma. Kisha, weka kumbukumbu ya gharama ya kila utekelezaji, ili uweze kuona kitanzi kikipoteza ufanisi kabla ya ankara kufika. Udhibiti wa gharama kwa VPS ya wakala anayefanya kazi kila wakati inashughulikia upande wa uhasibu, na kusimamia muktadha anaobeba wakala kati ya zamu inashughulikia kigezo kikubwa zaidi cha gharama kwa kila utekelezaji, kwa sababu kitanzi kinachosoma tena hazina ileile kila dakika 30 hulipia gharama hiyo kila dakika 30.

Gharama ndiyo sababu vitanzi mara nyingi huwa bora kuliko kipindi kimoja kirefu cha kazi. Utekelezaji unaoanza upya, unaofanya kazi moja ndogo na kumaliza, huweka muktadha wake ukiwa mdogo. Kipindi 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 menyu badala ya ilani. Uainishaji wa kila siku. Msimamizi wa pull-request anayefuatilia maoni ya uhakiki na kuyajibu. Kifagio cha continuous-integration kinachochukua build zilizofeli. Kifagio cha dependency. Mtunzi wa changelog. Usafishaji baada ya merge. Uainishaji wa issue.

Kinachozifanya zifanane ni kazi finyu yenye kigezo cha wazi cha kupita. "Rekebisha build inayofeli" ina sharti la kufaulu ambalo mashine inaweza kulisoma. "Boresha codebase" haina sharti hilo, kwa hivyo haiwezi kuwa loop. Inakuwa fujo yenye ratiba.

Pia zinafanana kwa kuwa na rekodi iliyoandikwa. Hazina zote mbili huhamisha hali 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 kugundua upya. Hii pia ndiyo njia unayotumia kukagua wakala baada ya tukio, kwa sababu muktadha wa modeli hupotea mara tu utekelezaji unapokoma. 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 kile, kwa hivyo faili inabaki kuwa sehemu unayoisoma baadaye.

Mahali ambapo loops hushindwa

Hitilafu hizi ni za kawaida na hujirudia katika timu mbalimbali.

• Hakuna kizuizi. Matokeo hujilimbikiza, hakuna anayeyakagua, imani hupotea, na loop huzimwa.
• Mwingiliano. Uendeshaji mbili kwenye branch moja, au mawakala wawili kwenye working tree moja, husababisha migogoro ambayo wakala hujaribu kuitatua.
• Drift ya kimya. Loop inaendelea kufaulu kwa sababu ukaguzi ni dhaifu mno kushindwa.
• Upeo usio na mipaka. Kichochezi kinachofanya 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 kazi, boresha ukaguzi, na weka kumbukumbu ya uendeshaji. Ikiwa huwezi kuelezea sharti la kufaulu katika sentensi moja, kazi hiyo haijawa tayari kwa ajili ya otomatiki.

Kuanza bila msamiati maalum

Hauhitaji mfumo (framework). Seva ndogo ya Linux inayowaka muda wote, hazina ya git ambayo suite yake ya majaribio inafeli inapopaswa, timer moja ya systemd, na hati ya shell 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 aendeshwe kwenye maunzi unayoyadhibiti mwenyewe.

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, umbizo la kumbukumbu ya pamoja, na uelekezaji wa mawakala wengi, ambavyo ni muhimu pindi unapoendesha loops 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 yanayotoa taarifa za makosa kwa uwazi, linter, na njia ya kupeleka au kuhakiki mabadiliko. Neno hili lilitokana na wimbi lilelile la repositories la mwaka 2026 kama loop engineering. Jaribio la kivitendo ni rahisi: kama mchangiaji mpya wa kibinadamu hawezi kufanya clone na kupata majaribio ya kijani (green tests) kwa amri moja, basi hata wakala hawezi.

Ninawezaje kuzuia agent loop isisababishe bili kubwa?

Weka vikomo katika sehemu tatu. Weka TimeoutStartSec kwenye systemd unit ili mchakato uliokwama uweze kusitishwa. Weka kikomo cha majaribio ya kurudia (retries) ndani ya script badala ya kuendelea kurudia 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 ambayo gharama zake huongezeka mara mbili kwa kawaida ni loop ambayo wigo wake umeongezeka kimyakimya.

Ni kazi zipi zinafaa kugeuzwa kuwa loop kwanza?

Chagua kazi yenye sharti la kupita linaloweza kusomwa na mashine na yenye athari ndogo ikikosea. Kurekebisha build iliyofeli, kusasisha dependency, na kutengeneza upya changelog zote zinafaa, 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.