Ano ang loop engineering? Simpleng depinisyon

Ano ang ibig sabihin ng 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 nagpapatigil dito. 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. Ang unit of work ay lumilipat mula sa prompt papunta sa loop.

Sa maikling paliwanag: humihinto ka sa pagsusulat lamang ng mga instruction at nagsisimula kang magsulat ng isang control system. Kailangan pa rin ng agent ng mahuhusay na instruction, pero nagiging isang component lamang ang mga ito sa loob ng cycle na tumatakbo ayon sa schedule, gumagana sa isang isolated copy ng iyong code, nagpapatunay sa sarili nitong resulta gamit ang test, at sumusuko kapag naubos ang budget.

Bakit lumitaw ang termino noong 2026

Itinatakda pa lamang ngayon sa publiko ang pangalan. Umabot sa 9,600 stars ang GitHub repository na cobusgreyling/loop-engineering sa loob ng dalawang buwan mula nang unang lumitaw ito (noong Hulyo 2026), gamit ang linyang “Huwag nang mag-prompt. Idisenyo ang loop. Kumuha ng score.” Inilalarawan nito ang pagbabagong ito sa anim na building block: scheduling, worktrees, skills, plugins at connectors, sub-agents, at matibay na memory na iniimbak sa labas ng conversation.

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

Hindi na ako nagpo-prompt kay Claude. May mga loop akong tumatakbo na nagpo-prompt kay Claude.

Ang ikalawang repository, AI-Builder-Club/skills, ay may halos 1,100 stars (noong Hulyo 2026) at direktang tinutukoy ang dalawang role: isang “codebase harness” na ginagawang ligtas ang repository para magpatakbo ang isang agent ng tests at deploys, at isang “loop engineer” na bumubuo ng mga workflow na nagigising kapag may trigger, nagsasagawa ng trabaho, at nagsusulat ng mga natutuhan nila sa isang shared file upang mabasa ito ng susunod na loop.

Wala sa dalawang repository ang nag-imbento ng gawaing ito. 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.

Ang apat na bahagi ng loop

May apat na bahaging taglay ang bawat gumaganang loop. Kapag may isang bahaging nilaktawan, maaaring magising ka nang 3am.

• Trigger. Ang event na nagsisimula ng 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 itatago 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 itinakdang tuntunin, at hindi ito nagsisimula 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 column na NEXT na may oras sa hinaharap, at column na LEFT na nagbibilang pababa. Walang laman ang resulta kapag hindi naka-enable ang timer, dahil ang enable nang walang --now ay nag-iiskedyul lamang nito para sa susunod na boot. Mas mahalaga kaysa sa inaakala ang TimeoutStartSec=1800: kung naghihintay ang agent ng input, mananatiling active ang unit nang walang hanggan, at hindi na muling magti-trigger 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 kusang 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 una. Nalalapat din ang parehong setup ng systemd service at timer sa anumang matagal na job sa server, agent man o hindi.

Hangganan: bigyan ang bawat run ng sariling kopya

Ang agent na nag-e-edit ng iyong working tree ay maaaring makawala sa iyong mga hindi pa naka-commit na pagbabago. Murang paraan para malutas ito ang Git worktrees: binibigyan ng sariling directory at sariling branch ang bawat run, habang nagbabahagi ang mga ito 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 ngayon ang mga parallel loop, dahil hindi maaaring ma-overwrite ng dalawang agent sa dalawang branch at dalawang directory ang isa't isa.

Tungkol din sa credentials ang hangganang ito. Ang loop na tumatakbo nang hindi binabantayan ay may hawak na mga token na matagal ang bisa, at bawat run ay maaaring maging sanhi ng paglabas ng token sa log, commit, o context ng model. Limitahan ang token sa iisang repository na ginagamit ng loop, at kung maaari ay huwag itong ilagay sa environment na nakikita ng sariling shell ng agent. Basahin ang kung paano ilayo ang mga secret sa AI agents bago bigyan ng production access ang loop. Para sa mas mahigpit na paghihiwalay, ilagay ang buong loop sa isang disposable VM na maaari mong sirain pagkatapos ng bawat run.

Pagpapatunay: ang gate na nagpapaligtas sa loop

Ito ang naghihiwalay sa isang loop mula sa isang cron job na nagta-type. 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"

May aktuwal na ginagawang mahalagang trabaho ang set -euo pipefail sa script na iyon. Kung wala ang -e, binabalewala ang nabigong git fetch at nagpapatuloy ang run gamit ang lipas na origin/main. Kung wala ang -u, nag-e-expand ang typo sa pangalan ng variable bilang empty string, at tumatakbo ang cleanup sa maling path sa halip na malinaw na mabigo.

Ang if ! npm test block ang buong konsepto. Ang exit code ng check na pinagkakatiwalaan mo na, gaya ng test suite o type checker, ang nagpapasya kung ipu-push o buburahin ang branch. Ang loop na walang gate ay gumagawa ng work na walang oras ang sinuman na i-review, at mas masahol ito kaysa sa walang work. Ang loop na may gate ay gumagawa ng branch na nakapasa na sa parehong pamantayang kailangang lampasan ng branch ng isang human contributor.

Pumili ng gate na tapat na nagfa-fail. Itinuturo ng test suite na pumapasa sa empty diff na tagumpay ang walang ginagawa. Ang mga repository na mahihina ang tests ay nagkakaroon ng mahihinang loop. Kaya inuuna ng mga trending repository ang "gawing handa ang codebase para sa agent" bago ang "isulat ang loop".

Badyet: ano ang pumipigil sa isang run

Ang agent na walang tigil sa pag-retry ay agent na may walang limitasyong gastos. Bigyan ang bawat loop ng wall-clock ceiling na ipinapatupad ng TimeoutStartSec sa itaas; magtakda ng retry count sa loob ng iyong script; at magtakda ng spend cap na ipinapatupad ng provider account. Pagkatapos, i-log kung magkano ang gastos ng bawat run para makita mo ang paglihis ng loop bago pa ito makita sa invoice. Sinasaklaw ng Pagkontrol sa gastos para sa isang agent VPS na laging naka-on ang bahagi ng accounting, at sinasaklaw ng pamamahala sa context na dala ng agent sa pagitan ng mga turn ang pinakamalaking salik sa gastos ng bawat run, dahil kapag muling binabasa ng isang loop ang parehong repository bawat 30 minutes, binabayaran mo ito bawat 30 minutes.

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

Ang mga pattern na itinatakda ng mga trending repository

Inililista ng loop-engineering repository ang pitong production pattern, at mas mainam basahin ang mga ito bilang menu kaysa manifesto. Daily triage. Isang pull-request babysitter na nagmo-monitor ng mga review comment at sumasagot sa mga ito. Isang continuous-integration sweeper na kumukuha ng mga red build. Isang dependency sweeper. Isang gumagawa ng draft ng changelog. Cleanup pagkatapos ng merge. Issue triage.

Ang pagkakapareho ng mga ito ay isang tiyak na gawain na may malinaw na gate. Ang “Ayusin ang failing build” ay may pass condition na mababasa ng machine. Walang ganito ang “Pagandahin ang codebase,” kaya hindi ito nagiging loop. Nagiging magulong gawain ito na may schedule.

Mayroon din silang nakasulat na record. Inilalabas ng parehong repository ang state mula sa conversation at inilalagay ito sa mga file sa repository: kung ano ang nag-run, kung ano ang nakita, at kung ano ang napagpasyahan. Ang file na iyon ang memory ng loop, at ito ang dahilan kung bakit makapagpapatuloy ang pangalawang loop sa ginawa ng una sa halip na tuklasin itong muli. Ito rin ang paraan para ma-audit ang isang agent pagkatapos ng run, dahil nawawala ang context ng model sa sandaling matapos ang run.

Kung saan pumapalya ang mga loop

Paulit-ulit ang mga failure na ito sa iba’t ibang team.

• Walang gate. Naiipon ang output, walang nagre-review nito, nawawala ang tiwala, at isinasara ang loop.
• Nag-o-overlap. May dalawang run sa isang branch, o dalawang agent sa isang working tree, kaya nagkakaroon ng mga conflict na sinusubukan namang i-resolve ng agent.
• Tahimik na paglihis. Patuloy na pumapasa ang loop dahil masyadong mahina ang check para mag-fail.
• Walang limitasyong saklaw. Ang trigger na tumatakbo sa bawat commit sa isang busy na repository ay nagiging problema sa gastos sa loob ng isang araw.

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

Pagsisimula nang walang bokabularyo

Hindi mo kailangan ng framework. Sapat na ang isang maliit na Linux server na palaging 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 dapat magsimula ang karamihan, dahil nasasagot ang mga tanong tungkol sa disenyo sa aktuwal na pagpapatakbo ng system, hindi sa pagpili ng tool. Kapag stable na ang isang loop, ang pagpapatakbo ng pangalawang loop ay karaniwang nangangailangan lang ng isa pang timer at isa pang worktree. Tingnan ang kung paano magpatakbo ng coding AI agent sa VPS para sa pangunahing setup, at ang kasalukuyang mga opsyon para sa self-hosted AI agent kung gusto mong patakbuhin mismo ang agent sa hardware na kontrolado mo.

FAQ

Magkaiba ba ang loop engineering sa prompt engineering?

Ino-optimize ng prompt engineering ang isang mensahe: pagpili ng salita, mga halimbawa, at format ng output. Ino-optimize naman ng loop engineering ang 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 sa run. Kailangan mo pa rin ng mahusay na prompt sa loob ng loop. Hindi na ang prompt ang pangunahing inaayos 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 para sa bawat bahagi ng definition ang isang systemd timer, isang git worktree sa bawat run, isang shell script na nagtatapos sa isang test command, at isang spend cap sa provider account. Nagdaragdag ang mga framework ng scheduling interface, shared memory format, at multi-agent routing. Kapaki-pakinabang ang mga ito kapag nagpapatakbo ka na ng ilang loop. Hindi kailangan ang mga ito para makapagsimula sa unang loop.

Ano ang codebase harness?

Ito ang set ng mga bagay na nagbibigay-daan sa isang agent na magtrabaho sa isang repository nang walang taong naroroon: isang one-command setup, mga test na tumatakbo nang non-interactively at malinaw na nagfa-fail, isang 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 pagsubok: kung hindi makakarating ang isang bagong human contributor mula clone hanggang green tests gamit ang isang command, hindi rin ito magagawa ng isang agent.

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

Lagyan ito ng limitasyon 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 ito ang tanging ceiling na hindi malalampasan ng agent sa pamamagitan ng pakikipag-usap. Pagkatapos, i-log ang gastos sa bawat run, dahil ang loop na dumodoble ang gastos ay karaniwang loop na tahimik na lumawak ang scope.

Aling mga trabaho ang unang sulit gawing loop?

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