Ano ang loop engineering? Simpleng depinisyon

Ano ang loop engineering

Ang loop engineering ay ang pagdidisenyo ng paulit-ulit na cycle na pinapatakbo ng isang AI agent: kung ano ang gumigising dito, kung ano ang maaari nitong galawin, kung paano sinusuri ang output nito, at kung ano ang nagpapahinto rito. Hinuhubog ng prompt engineering ang isang mensahe para sa isang model. Hinuhubog naman ng loop engineering ang prosesong nagpapadala ng libo-libong mensahe habang natutulog ka. Mula sa prompt, lumilipat sa loop ang unit of work.

Sa madaling sabi: hindi ka na lang sumusulat ng mga instruction; nagsusulat ka na ng control system. Kailangan pa rin ng agent ng mahuhusay na instruction, pero nagiging isang component ang mga ito sa loob ng cycle na tumatakbo ayon sa schedule, gumagana sa isolated copy ng iyong code, nagpapatunay sa sarili nitong resulta gamit ang test, at humihinto kapag naubos na ang budget.

Bakit lumitaw ang termino noong 2026

Kasalukuyang binibigyang-kahulugan ang pangalan sa publiko. Ang GitHub repository na cobusgreyling/loop-engineering ay umabot sa 9,600 stars sa loob ng dalawang buwan mula nang unang lumitaw ito (hanggang Hulyo 2026), sa ilalim ng linyang “Huwag nang mag-prompt. Idisenyo ang loop. Kumuha ng score.” Pinagsasama nito ang pagbabagong ito sa anim na building block: scheduling, worktrees, skills, plugins at connectors, sub-agents, at durable memory na pinananatili sa labas ng conversation.

Sinipi nito si Boris Cherny, na namumuno sa Claude Code sa Anthropic:

Hindi na ako nagse-send ng prompt kay Claude. May mga loop akong tumatakbo na nagse-send ng prompt kay Claude.

Ang ikalawang repository, AI-Builder-Club/skills, ay nasa humigit-kumulang 1,100 stars (hanggang Hulyo 2026) at tuwirang pinapangalanan ang dalawang role: isang “codebase harness” na ginagawang ligtas ang repository para magpatakbo rito ang isang agent ng mga test at deployment, at isang “loop engineer” na bumubuo ng mga workflow na nagigising kapag may trigger, gumagawa ng trabaho, at nagsusulat ng mga natutuhan nito sa isang shared file para mabasa ito ng susunod na loop.

Wala sa alinmang repository ang nag-imbento ng praktika. Alam na ng sinumang nagpatakbo ng nightly build, linter sa continuous integration, o cron job na nagbubukas ng ticket ang ganitong anyo. Ang bago ay non-deterministic na ngayon ang worker sa loob ng loop. Dahil dito, nagbabago ang mga kailangang gawin ng nakapaligid na machinery.

A loop na may apat na bahagi

May apat na bahaging ito ang bawat gumaganang loop. Kapag may isang bahaging nawawala, maaari kang magising ng loop nang 3am.

• Trigger. Ang event na nagsisimula ng isang run: isang timer, webhook, bagong pull request, o alert.
• Boundary. Ang mga file, credential, at network na maaaring ma-access ng agent sa run na iyon.
• Verification. Isang check na may exit code. Tinutukoy nito kung pananatilihin o itatapon ang output ng run.
• Budget. Ang limitasyon sa token, oras, at gastos na nagtatapos sa run, nagtagumpay man ito o hindi.

Basahin muli ang apat na ito bilang mga tanong. Magagamit mo ang mga ito bilang design review para sa anumang agent na iiwan mong tumatakbo.

Trigger: kung ano ang gumigising sa agent

Ang timer ang pinakasimpleng trigger. Sa Linux server, mas mainam ang systemd timer kaysa cron dahil nagla-log ito, nagre-retry ayon sa itinakda mo, at hindi ito magsisimula ng pangalawang kopya ng unit na tumatakbo pa. Inaalis ng huling katangiang ito ang pinakakaraniwang overlap bug sa mga loop ng agent: dalawang run ang nag-e-edit sa iisang branch.

Isulat ang unit sa /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

At ang timer sa /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

Dapat magpakita ang systemctl list-timers ng NEXT column na may oras sa hinaharap at LEFT column na nagbibilang pababa. Ang walang laman na resulta ay nangangahulugang hindi naka-enable ang timer, dahil ang enable nang walang --now ay nagse-schedule nito para sa susunod na boot lamang. Mas mahalaga ang TimeoutStartSec=1800 kaysa sa inaakala: kung ma-stuck ang agent habang naghihintay ng input, mananatiling active ang unit magpakailanman, at hindi na muling gagana ang timer. Basahin ang isang run gamit ang journalctl -u agent-loop.service -n 50.

Kung cron ang gagamitin mo para patakbuhin ang loop, magdagdag ng sarili mong overlap guard dahil basta na lamang magsisimula ang cron ng pangalawang kopya:

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

Agad na lumalabas ang flock -n na may status 1 kapag hawak ang lock. Dahil dito, tahimik na nawawala ang pangalawang run sa halip na makipag-unahan sa naunang run. Nalalapat din ang parehong systemd service at timer setup sa anumang matagal na job sa server, agent man o hindi.

Boundary: bigyan ng sariling kopya ang bawat run

Ang agent na nag-e-edit ng working tree ay maaaring makabura o makapagpabago sa iyong mga uncommitted na gawain. Murang solusyon dito ang Git worktrees: bawat run ay may sariling directory at sariling branch, habang nagbabahagi ng iisang object store.

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

Ang git worktree list ay nagpi-print ng isang linya para sa bawat tree, kasama ang path, commit, at branch nito. Kapag natapos ang run, binubura ng git worktree remove /srv/agent/work/triage-01 ang directory, at nililinis ng git worktree prune ang mga entry na wala na ang directory. Ligtas na ang mga parallel loop sa puntong ito dahil hindi maaaring ma-overwrite ng dalawang agent sa magkaibang branch at magkaibang directory ang gawain ng isa’t isa.

Tungkol din sa credentials ang boundary. Ang loop na tumatakbo nang hindi binabantayan ay may hawak na mga token na matagal ang bisa, at bawat run ay maaaring maging daan para mailabas ang isa sa log, commit, o model context. Limitahan ang token sa iisang repository na ginagamit ng loop. Kung maaari, huwag itong ilagay sa environment na nakikita ng sariling shell ng agent. Basahin ang kung paano ilayo ang secrets sa AI agents bago bigyan ng production access ang isang loop. Para sa mas mahigpit na isolation, ilagay ang buong loop sa isang disposable VM na maaari mong i-destroy pagkatapos ng bawat run. Nakaaapekto rin sa boundary ang tool na ginagamit mo bago mo pa ito i-configure. Kaya mainam na basahin ang kung paano ikinukumpara ang managed sandbox ng Cowork sa Claude Code sa sarili mong machine bago magpasya kung gaano karaming isolation ang kailangan mong ikaw mismo ang magpatupad.

Pag-verify: ang gate na nagpapanatiling ligtas sa loop

Ito ang bahaging naghihiwalay sa isang loop mula sa isang cron job na nagta-type lang. Proposal ang output ng agent. Ang gate ang nagpapasya.

#!/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 ang gumagawa ng aktuwal na trabaho sa script na iyon. Kung wala ang -e, binabalewala ang nabigong git fetch at nagpapatuloy ang run gamit ang lumang origin/main. Kung wala ang -u, nagiging empty string ang typo sa pangalan ng variable, at tumatakbo ang cleanup sa maling path sa halip na malinaw na mabigo.

Ang buong ideya ay nasa block na if ! npm test. Ang exit code ng isang check na pinagkakatiwalaan mo na, gaya ng test suite o type checker, ang nagpapasya kung ipu-push o sisirain ang branch. Ang loop na walang gate ay gumagawa ng trabahong walang oras ang sinuman para i-review, kaya mas masama ito kaysa sa walang trabaho. Ang loop na may gate ay gumagawa ng branch na nakapasa na sa parehong pamantayang kailangang mapasa ng branch ng human contributor. Walang sinasabi ang green gate tungkol sa dami ng code na ginalaw ng agent para makarating doon. Kaya mainam na ipares ang check sa isang standing instruction gaya ng rule na nagpapagawa sa agent ng pinakamaliit na gumaganang pagbabago, upang manatiling maliit ang diff at mura pa ring i-review.

Pumili ng gate na tapat na nagfa-fail. Ang test suite na pumapasa sa empty diff ay nagtuturo sa loop na tagumpay ang walang gawin. Nagkakaroon ng mahihinang loop ang mga repository na mahihina ang test. Kaya inuuna ng mga trending repository ang “gawing handa sa agent ang codebase” bago ang “isulat ang loop”. Kung gusto mong malaman kung talagang makakahuli ng regression ang suite mo at hindi lang mae-execute ang mga linya, mutation testing ang check na makasasagot dito. Ang agent na nagbabalik ng rerunnable evidence report sa halip na hilingin sa iyong basahin ang diff nito ang nagiging paraan para makumpirma mo mismo ang sagot na iyon.

Badyet: ano ang pumipigil sa isang run

Ang agent na walang katapusang nagre-retry ay agent na walang limitasyon ang gastos. Lagyan ang bawat loop ng wall-clock ceiling na ipinapatupad ng TimeoutStartSec sa itaas; magtakda ng retry count sa loob ng script; at magpatupad ng spend cap sa provider account. I-log din kung magkano ang gastos ng bawat run para makita mo ang unti-unting pagtaas ng gastos ng loop bago pa ito lumitaw sa invoice. Sinasaklaw ng Pagkontrol ng gastos para sa always-on agent VPS ang accounting side, at ng pamamahala sa context na dala ng agent sa bawat turn ang pinakamalaking salik sa per-run cost, dahil ang loop na muling nagbabasa ng parehong repository bawat 30 minuto ay nagbabayad para rito bawat 30 minuto.

Dahil sa gastos, kadalasang mas mainam ang mga loop kaysa sa isang mahabang session. Ang run na nagsisimula nang bago, gumagawa ng isang tiyak na gawain, at pagkatapos ay lumalabas ay nagpapanatiling maliit ng context nito. Ang session na bukas nang walong oras ay dala sa history nito ang bawat naunang pagkakamali at nagbabayad para sa buong transcript sa bawat turn.

Mga pattern na isinasabuhay ng mga repository na trending

Naglilista ang loop-engineering repository ng pitong production pattern, at mas kapaki-pakinabang basahin ang mga ito bilang isang menu kaysa bilang manifesto. Daily triage. Isang pull-request babysitter na sumusubaybay sa mga review comment at sumasagot sa mga ito. Isang continuous-integration sweeper na kumukuha ng mga red build. Isang dependency sweeper. Isang changelog drafter. Post-merge cleanup. Issue triage.

Pareho silang may makitid na gawain at malinaw na gate. May condition para pumasa ang “Ayusin ang failing build” na kayang basahin ng machine. Wala nito ang “Pagandahin ang codebase,” kaya hindi ito nagiging loop. Nagiging magulong gawain ito na may schedule.

Pareho rin silang may nakasulat na record. Inililipat ng dalawang repository ang state palabas ng conversation at papunta sa mga file sa repository: ano ang tumakbo, ano ang nakita nito, at ano ang napagpasyahan nito. Ang file na iyon ang memory ng loop. Dahil dito, maaaring ipagpatuloy ng ikalawang loop ang ginawa ng una sa halip na tuklasin itong muli. Ito rin ang paraan upang ma-audit ang isang agent pagkatapos ng run, dahil nawawala ang context ng model sa sandaling matapos ang run. Hiwalay na channel ang live coordination, at maaaring magpasa ng gawain ang isang Claude Code session sa isa pa sa parehong box habang tumatakbo pa silang pareho. Ngunit walang anumang bahagi ng palitang iyon ang mananatili kapag natapos ang alinman sa dalawang session, kaya ang file pa rin ang babalikan mo kalaunan.

Kapag pumapalya ang mga loop

Nakababagot ang mga failure, at paulit-ulit itong nangyayari sa iba’t ibang team.

• Walang gate. Naiipon ang output, walang nagre-review nito, nawawala ang tiwala, at pinapatay ang loop.
• Nagkakapatong. May dalawang run sa isang branch, o dalawang agent sa iisang working tree, kaya nagkakaroon ng conflict na sinusubukang ayusin ng agent.
• Tahimik na paglihis. Patuloy na pumapasa ang loop dahil masyadong mahina ang check para magdulot ng failure.
• Walang limitasyon ang saklaw. Ang trigger na tumatakbo sa bawat commit sa isang abalang repository ay nagiging problema sa gastos sa loob lamang ng isang araw.

Iisa ang solusyon sa lahat ng ito: paliitin ang trabaho, gawing mas tiyak ang check, at i-log ang run. Kung hindi mo mailalarawan sa isang pangungusap ang kondisyon para pumasa, hindi pa handang i-automate ang trabaho.

Pagsisimula nang hindi muna kailangang alamin ang mga termino

Hindi mo kailangan ng framework. Sapat na ang isang maliit na Linux server na laging naka-on, isang git repository na nagfa-fail ang test suite kapag dapat itong mag-fail, isang systemd timer, at isang shell script na may if para makabuo ng kumpletong loop. Dito talaga dapat magsimula ang karamihan, dahil nasasagot ang mga tanong sa disenyo sa aktuwal na pagpapatakbo ng system, hindi sa pagpili ng tool. Kapag stable na ang isang loop, ang pagpapatakbo ng ikalawa ay karaniwang nangangailangan lamang ng isa pang timer at isa pang worktree. Tingnan ang kung paano magpatakbo ng coding AI agent sa isang VPS para sa pangunahing setup, at ang kasalukuyang mga opsyon para sa self-hosted AI agent kung gusto mong tumakbo mismo ang agent sa hardware na kontrolado mo.

FAQ

Magkaiba ba ang loop engineering sa prompt engineering?

Ang prompt engineering ay nag-o-optimize ng isang mensahe: wording, mga halimbawa, at output format. Ang loop engineering ay nag-o-optimize ng cycle sa paligid ng mensahe: ang trigger na nagsisimula ng run, ang sandbox kung saan ito tumatakbo, ang check na tumatanggap o tumatanggi sa output nito, at ang budget na nagtatapos dito. Kailangan mo pa rin ng magandang prompt sa loob ng loop. Hindi na prompt ang pangunahing tina-tune araw-araw, dahil mas malaki ang epekto ng gate at trigger sa resulta.

Kailangan ko ba ng framework para bumuo ng agent loop?

Hindi. Sapat na ang systemd timer, isang git worktree para sa bawat run, isang shell script na nagtatapos sa isang test command, at spend cap sa provider account para masaklaw ang bawat bahagi ng depinisyon. Nagdaragdag ang frameworks ng scheduling interface, shared memory format, at multi-agent routing. Kapaki-pakinabang ang mga ito kapag nagpapatakbo ka na ng ilang loop. Hindi kinakailangan ang mga ito para makapagsimula sa unang loop.

Ano ang codebase harness?

Ito ang pangkat ng mga bagay na nagbibigay-daan sa agent na magtrabaho sa isang repository nang walang taong nagbabantay: one-command setup, mga test na tumatakbo nang non-interactive at malinaw na nagfa-fail, linter, at paraan para mag-deploy o mag-preview ng pagbabago. Nagmula ang termino sa parehong 2026 wave ng mga repository kung saan lumitaw ang loop engineering. Simple ang praktikal na test: kung hindi makakarating ang bagong human contributor mula clone hanggang green tests gamit ang isang command, hindi rin iyon magagawa ng agent.

Paano ko mapipigilan ang agent loop na magkaroon ng malaking bill?

Maglagay ng limit sa tatlong lugar. Itakda ang TimeoutStartSec sa systemd unit para mapatay ang run kapag nag-hang ito. Limitahan ang retries sa loob ng script sa halip na mag-loop hanggang magtagumpay. Magtakda ng hard spend limit sa API account, dahil iyon lang ang ceiling na hindi kayang lampasan ng agent sa pamamagitan ng pangangatwiran. Pagkatapos, i-log ang cost ng bawat run, dahil ang loop na dumodoble ang cost ay karaniwang loop na unti-unting lumawak ang scope nang hindi napapansin.

Aling mga job ang unang sulit gawing loop?

Pumili ng job na may machine-readable pass condition at maliit na blast radius. Kabilang dito ang pag-aayos ng red build, pag-update ng dependency, at pag-regenerate ng changelog, dahil mapapatunayan ng test suite o diff ang resulta. Hindi pa angkop ang open-ended na trabaho gaya ng refactoring o design, dahil wala pang mache-check ang gate. Ang loop na walang gate ay magastos na paraan para lumikha ng review debt.