Uhandisi wa mzunguko ni nini? Maana yake

Maana ya uhandisi wa mzunguko

Uhandisi wa mzunguko ni zoezi la kubuni mzunguko unaorudiwa ambao wakala wa AI huendesha: ni nini kinachouamsha, ni vitu gani unavyoweza kutumia, jinsi matokeo yake yanavyokaguliwa, na ni nini kinachoukomesha. Uhandisi wa vidokezo huunda ujumbe mmoja kwa ajili ya modeli. Uhandisi wa mzunguko huunda mchakato unaotuma maelfu ya ujumbe unapolala. Kitengo cha kazi huhama kutoka kwenye kidokezo hadi kwenye mzunguko.

Kwa ufupi: unaacha kuandika maagizo na kuanza kuandika mfumo wa udhibiti. Wakala bado anahitaji maagizo mazuri, lakini maagizo hayo huwa sehemu moja ya mzunguko unaoendeshwa kwa ratiba, unaofanya kazi katika nakala iliyotengwa ya msimbo wako, unaothibitisha matokeo yake kwa jaribio, na unaokoma bajeti inapoisha.

Kwa nini istilahi hiyo ilionekana mwaka 2026

Jina hilo linawekwa rasmi hadharani sasa. Hifadhi ya GitHub cobusgreyling/loop-engineering ilifikisha nyota 9,600 ndani ya miezi miwili tangu ilipoonekana kwa mara ya kwanza (kufikia Julai 2026), ikiwa na kauli: "Usiandike maelekezo ya kila mara. Buni mzunguko. Pata alama." Inakusanya mabadiliko hayo katika vipengele sita vya msingi: upangaji wa ratiba, worktrees, ujuzi, plugins na viunganishi, mawakala wasaidizi, na kumbukumbu ya kudumu inayohifadhiwa nje ya mazungumzo.

Inamnukuu Boris Cherny, anayeongoza Claude Code katika Anthropic:

Sitoi tena maelekezo kwa Claude. Nina mizunguko inayoendelea ambayo inampa Claude maelekezo.

Hifadhi ya pili, AI-Builder-Club/skills, ina karibu nyota 1,100 (kufikia Julai 2026) na inataja majukumu hayo mawili moja kwa moja: "codebase harness" inayofanya hifadhi iwe salama kwa wakala kuendesha majaribio na deployments ndani yake, na "loop engineer" anayejenga mtiririko wa kazi unaoamka baada ya kichochezi, kutekeleza kazi, na kuandika ulichojifunza kwenye faili ya pamoja ili mzunguko unaofuata uweze kukisoma.

Hakuna hifadhi kati ya hizo iliyobuni utaratibu huu. Mtu yeyote aliyeendesha build ya kila usiku, linter katika continuous integration, au cron job inayofungua tiketi tayari anaelewa muundo wake. Jambo jipya ni kwamba worker aliye ndani ya mzunguko sasa hafanyi kazi kwa utabirika wa kudumu, jambo linalobadilisha kile ambacho mifumo inayouzunguka inapaswa kufanya.

Sehemu nne za mzunguko

Kila mzunguko unaofanya kazi una sehemu hizi nne. Mzunguko unaoruka sehemu yoyote kati ya hizo unaweza kuendelea bila kudhibitiwa.

• Kichocheo. Tukio linaloanzisha utekelezaji: kipima muda, webhook, pull request mpya au tahadhari.
• Mipaka. Faili, vitambulisho vya ufikiaji na mtandao ambao agent anaweza kufikia wakati wa utekelezaji huo.
• Uthibitishaji. Ukaguzi wenye exit code unaoamua ikiwa matokeo ya utekelezaji yatahifadhiwa au kutupiliwa mbali.
• Bajeti. Kikomo cha tokeni, muda na fedha kinachomaliza utekelezaji, bila kujali kama umefanikiwa.

Soma sehemu hizo nne tena kama maswali, nawe utakuwa na ukaguzi wa muundo wa agent yoyote unayokaribia kuiacha ikiendelea kufanya kazi.

Kichochezi: kinachomwamsha wakala

Kichochezi cha timer ndicho rahisi zaidi, na kwenye seva ya Linux timer ya systemd ni bora kuliko cron kwa sababu huandika kumbukumbu, hujaribu tena kulingana na masharti yako, na haitaanzisha nakala ya pili ya unit ambayo bado inaendelea. Sifa hiyo huondoa hitilafu ya kawaida zaidi ya mwingiliano katika mizunguko ya wakala: uendeshaji miwili kuhariri tawi lilelile.

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 iliyo na muda wa baadaye na safu ya LEFT inayohesabu muda uliosalia. Matokeo matupu yanamaanisha kuwa timer haijawezeshwa, kwa sababu enable bila --now huiweka ratiba ya kuwashwa upya kunakofuata pekee. TimeoutStartSec=1800 ni muhimu zaidi kuliko inavyoonekana: wakala anayekwama akingoja ingizo ataifanya unit ibaki hai bila kikomo, na timer haitawaka tena. Soma uendeshaji kwa journalctl -u agent-loop.service -n 50.

Ukiendesha mzunguko kutoka cron badala yake, ongeza ulinzi wako wa mwingiliano, kwa sababu cron itaanzisha kwa urahisi nakala ya pili:

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

flock -n hutoka mara moja ikiwa na hali ya 1 wakati lock imeshikiliwa, kwa hiyo uendeshaji wa pili hutoweka kimya badala ya kushindana na wa kwanza. Usanidi huohuo wa service na timer ya systemd unatumika kwa kazi yoyote inayoendelea kwa muda mrefu kwenye mashine, iwe ni wakala au la.

Mpaka: panga kila utekelezaji upate nakala yake

Wakala anayehariri working tree yako anaweza kupoteza kazi ambayo bado haijawekwa kwenye commit. Git worktrees hutatua hili kwa gharama ndogo: kila utekelezaji hupata saraka yake na branch yake, huku ikishiriki object store moja.

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 ukiwa na njia yake, commit na branch. Utekelezaji unapoisha, git worktree remove /srv/agent/work/triage-01 hufuta saraka hiyo, na git worktree prune huondoa maingizo ambayo saraka yake imetoweka. Loops zinazotekelezwa kwa pamoja huwa salama hapa, kwa sababu mawakala wawili walio kwenye branches mbili na saraka mbili hawawezi kuandikiana juu ya kazi ya mwingine.

Mpaka huu unahusu pia credentials. Loop inayoendeshwa bila uangalizi hushikilia tokeni za muda mrefu, na kila utekelezaji unaweza kuvuja tokeni hiyo kwenye log, commit au muktadha wa modeli. Weka upeo wa tokeni hiyo kwenye repository moja tu ambayo loop inafikia, na ikiwezekana usiiweke kwenye environment ambayo shell ya wakala yenyewe inaweza kuona. Soma jinsi ya kuzuia siri zisionekane kwa mawakala wa AI kabla hujaipa loop uwezo wa kufikia production. Kwa kizuizi kikali zaidi, weka loop yote kwenye VM ya muda unayoweza kuiharibu baada ya kila utekelezaji.

Uthibitishaji: lango linalofanya mzunguko uwe salama

Hii ndiyo sehemu inayotofautisha mzunguko na cron job inayochapa amri. 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 halisi katika script hiyo. Bila -e, git fetch iliyoshindwa hupuuzwa na utekelezaji huendelea kutumia origin/main iliyopitwa na wakati. Bila -u, kosa la kuandika jina la kigeu husababisha jina hilo kupanuka kuwa mfuatano tupu, kisha usafishaji huendeshwa kwenye path isiyo sahihi badala ya kushindwa kwa uwazi.

Bloku ya if ! npm test ndiyo wazo lote. Msimbo wa kutoka wa ukaguzi unaouamini tayari, kama test suite au type checker yako, huamua kama branch itatumwa au itafutwa. Mzunguko usio na lango huzalisha kazi ambayo hakuna mtu aliye na muda wa kuikagua, na hali hiyo ni mbaya kuliko kutokuwa na kazi. Mzunguko wenye lango huzalisha branch ambayo tayari imepita kiwango kilekile ambacho branch ya mchangiaji wa kibinadamu inapaswa kupita.

Chagua lango linaloshindwa kwa uaminifu. Test suite inayofaulu kwenye diff tupu huufundisha mzunguko kwamba kutofanya chochote ni mafanikio. Repositories zenye test dhaifu hupata mizunguko dhaifu. Ndiyo maana repositories zinazoongoza huweka “fanya codebase iwe tayari kwa mawakala” kabla ya “andika mzunguko”.

Bajeti: kinachozuia utekelezaji

Wakala anayojaribu tena bila kikomo ni wakala mwenye bili isiyo na kikomo. Weka kikomo cha muda wa saa kwenye kila kitanzi, kikitekelezwa na TimeoutStartSec hapo juu; weka idadi ya majaribio tena ndani ya script yako; na weka kikomo cha matumizi kinachotekelezwa na akaunti ya mtoa huduma. Kisha andika gharama ya kila utekelezaji kwenye logi, ili uweze kuona kitanzi kikianza kupotoka kabla ankara haijaonyesha hivyo. Udhibiti wa gharama kwa VPS ya wakala inayofanya kazi kila wakati inaeleza upande wa uhasibu, na kusimamia muktadha ambao wakala hubeba kati ya zamu inaeleza njia kuu zaidi ya kupunguza gharama kwa kila utekelezaji, kwa sababu kitanzi kinachosoma tena repository ileile kila baada ya dakika 30 hulipia usomaji huo kila baada ya dakika 30.

Gharama ndiyo sababu vitanzi kwa kawaida huwa bora kuliko session moja ndefu. Utekelezaji unaoanza upya, kufanya kazi moja finyu na kutoka huweka muktadha wake kuwa mdogo. Session iliyoachwa wazi kwa saa 8 hubeba kila kosa la awali katika historia yake, na hulipia nakala nzima ya mazungumzo katika kila zamu.

Miundo ambayo hazina zinazoongoza huweka katika kanuni

Hazina ya loop-engineering inaorodhesha miundo saba ya uzalishaji, na inafaa kuisoma kama orodha ya chaguo badala ya ilani. Ukaguzi wa kila siku. Msaidizi wa pull request anayefuatilia maoni ya ukaguzi na kuyajibu. Kichujaji cha continuous integration kinachochukua builds zenye hitilafu. Kichujaji cha dependencies. Mtayarishaji wa rasimu ya changelog. Usafishaji baada ya merge. Upangaji wa issues.

Kile wanachoshirikiana ni kazi finyu yenye kigezo cha wazi cha kupita. "Rekebisha build yenye hitilafu" ina sharti la kupita ambalo mashine inaweza kusoma. "Boresha codebase" haina sharti hilo, kwa hiyo haiwi loop kamwe. Inakuwa mkanganyiko wenye ratiba.

Pia wanashirikiana kuwa na rekodi iliyoandikwa. Hazina zote mbili huondoa hali kutoka kwenye mazungumzo na kuiweka katika faili zilizo kwenye hazina: kilichoendeshwa, kilichopatikana, na kilichoamuliwa. Faili hiyo ni kumbukumbu ya loop, na ndiyo sababu loop ya pili inaweza kuendeleza kazi ya kwanza badala ya kuigundua upya. Pia ndiyo njia ya kukagua agent baada ya tukio, kwa sababu muktadha wa model hupotea mara tu uendeshaji unapomalizika.

Mahali mizunguko inaposhindwa

Hitilafu hizi si za kuvutia, na hujirudia katika timu mbalimbali.

• Hakuna kizuizi. Matokeo huongezeka, hakuna anayeyakagua, imani hupotea, na mzunguko huzimwa.
• Kuingiliana. Uendeshaji miwili hufanyika kwenye branch moja, au mawakala wawili hufanya kazi katika working tree moja na kusababisha migongano ambayo wakala hujaribu kuisuluhisha.
• Mkengeuko usioonekana. Mzunguko huendelea kufaulu kwa sababu ukaguzi ni dhaifu kiasi kwamba hauwezi kusababisha kushindwa.
• Wigo usio na kikomo. Trigger inayotekelezwa kwenye kila commit katika repository yenye shughuli nyingi hugeuka kuwa tatizo la gharama ndani ya siku moja.

Kila tatizo lina suluhisho lilelile: punguza kazi, boresha ukaguzi, na andika kumbukumbu ya uendeshaji. Ikiwa huwezi kueleza sharti la kufaulu kwa sentensi moja, kazi hiyo haijawa tayari kuendeshwa kiotomatiki.

Kuanza bila msamiati

Huhitaji mfumo maalum wa uundaji. Seva ndogo ya Linux inayofanya kazi muda wote, hazina ya git ambayo mkusanyiko wake wa majaribio hushindwa inapopaswa, kipima muda kimoja cha systemd na hati moja ya shell yenye if ndani yake vinatosha kuunda mzunguko kamili. Hapo ndipo watu wengi wanapaswa kuanzia, kwa sababu maswali ya usanifu hujibiwa kwa kuendesha mfumo huo badala ya kuchagua zana. Mzunguko mmoja unapokuwa thabiti, kuendesha wa pili huhitaji hasa kipima muda kingine na worktree nyingine. Angalia jinsi ya kuendesha wakala wa AI wa uandishi wa programu kwenye VPS kwa usanidi wa msingi, na chaguo za sasa za mawakala wa AI zinazojihudumia ikiwa unataka wakala mwenyewe aendeshe kwenye maunzi unayoyadhibiti.

FAQ

Je, uhandisi wa mzunguko unatofautiana na uhandisi wa vidokezo?

Uhandisi wa vidokezo huboresha ujumbe mmoja: uteuzi wa maneno, mifano na muundo wa matokeo. Uhandisi wa mzunguko huboresha mchakato unaouzunguka ujumbe: kichochezi kinachoanzisha utekelezaji, sandbox unamotekelezwa, ukaguzi unaokubali au kukataa matokeo yake, na bajeti inayoukomesha. Bado unahitaji kidokezo kizuri ndani ya mzunguko. Kidokezo si kitu cha kwanza tena kuboresha kila siku, kwa sababu lango na kichochezi vina athari kubwa zaidi kwenye matokeo.

Je, ninahitaji mfumo wa kuunda mzunguko wa agent?

Hapana. Kipima muda cha systemd, git worktree kwa kila utekelezaji, hati ya shell inayoishia kwa amri ya test, na kikomo cha matumizi kwenye akaunti ya mtoa huduma vinatosheleza kila sehemu ya ufafanuzi huo. Mifumo huongeza violesura vya kuratibu, miundo ya kumbukumbu inayoshirikiwa na uelekezaji wa mawakala wengi. Hivi huwa muhimu unapoendesha mizunguko kadhaa. Si sharti la kuanza mzunguko wa kwanza.

Harness ya codebase ni nini?

Ni seti ya vitu vinavyomwezesha agent kufanya kazi kwenye repository bila kuwepo kwa binadamu: usanidi wa amri moja, test zinazoendeshwa bila mwingiliano na kushindwa kwa uwazi, linter, na njia ya kusambaza au kuhakiki awali mabadiliko. Istilahi hii ilitokana na wimbi lilelile la 2026 la repository kama uhandisi wa mzunguko. Jaribio la vitendo ni rahisi: ikiwa mchangiaji mpya wa kibinadamu hawezi kutoka kwenye clone hadi test zinazofaulu kwa amri moja, agent pia hawezi.

Ninawezaje kuzuia mzunguko wa agent usizalishe bili kubwa?

Weka kikomo katika maeneo matatu. Weka TimeoutStartSec kwenye unit ya systemd ili utekelezaji ulioganda ukomeshwe. Weka kikomo cha majaribio tena ndani ya hati badala ya kuendelea kujaribu hadi mafanikio yapatikane. Weka kikomo thabiti cha matumizi kwenye akaunti ya API, kwa sababu hicho ndicho kikomo pekee ambacho agent hawezi kukishawishi kivukiwe. Kisha weka kumbukumbu ya gharama ya kila utekelezaji, kwa sababu mzunguko ambao gharama yake inaongezeka mara mbili kwa kawaida ni mzunguko ambao wigo wake umeongezeka kimyakimya.

Ni kazi zipi zinafaa kwanza kubadilishwa kuwa mzunguko?

Chagua kazi yenye sharti la kufaulu linaloweza kusomeka na mashine na yenye athari ndogo iwapo itashindwa. Kurekebisha build iliyoshindikana, kusasisha utegemezi na kuzalisha upya changelog zote zinafaa, kwa sababu test suite au diff inaweza kuthibitisha matokeo. Kazi zisizo na mwisho maalum, kama vile refactoring au usanifu, bado hazifai, kwa sababu hakuna kitu ambacho lango linaweza kukagua. Mzunguko usio na lango ni njia ghali ya kuzalisha deni la ukaguzi.