Loop engineering là gì? Định nghĩa dễ hiểu

Loop engineering là gì

Loop engineering là việc thiết kế chu kỳ lặp mà một AI agent chạy qua: điều gì đánh thức agent, agent được phép truy cập gì, đầu ra được kiểm tra như thế nào và điều gì sẽ dừng agent. Prompt engineering định hình một message gửi cho model. Loop engineering định hình quy trình gửi hàng nghìn message khi bạn đang ngủ. Đơn vị công việc chuyển từ prompt sang loop.

Tóm lại: bạn không còn chỉ viết hướng dẫn mà bắt đầu viết một control system. Agent vẫn cần hướng dẫn tốt, nhưng hướng dẫn chỉ là một thành phần trong chu kỳ chạy theo lịch, làm việc trên một bản sao biệt lập của code, tự chứng minh kết quả bằng test và dừng khi hết budget.

Vì sao thuật ngữ này xuất hiện vào năm 2026

Tên gọi này đang được định hình công khai ngay lúc này. Repository GitHub cobusgreyling/loop-engineering đã vượt 9,600 stars trong vòng hai tháng kể từ lần đầu xuất hiện (tính đến tháng 7 năm 2026), với khẩu hiệu "Stop prompting. Design the loop. Get a score." Nó khái quát sự chuyển dịch thành sáu khối xây dựng: lập lịch, worktree, skill, plugin và connector, sub-agent, cùng bộ nhớ bền vững được lưu bên ngoài cuộc trò chuyện.

Repository này trích lời Boris Cherny, người phụ trách Claude Code tại Anthropic:

Tôi không còn prompt cho Claude nữa. Tôi có các loop đang chạy để prompt Claude.

Một repository thứ hai, AI-Builder-Club/skills, có gần 1,100 stars (tính đến tháng 7 năm 2026) và nêu trực tiếp hai vai trò: "codebase harness" giúp repository an toàn để agent chạy test và thực hiện deploy, cùng "loop engineer", người xây dựng workflow thức dậy khi có trigger, thực hiện công việc và ghi những gì đã học vào một file dùng chung để loop tiếp theo có thể đọc.

Không repository nào trong số này phát minh ra phương pháp đó. Bất kỳ ai từng chạy nightly build, linter trong continuous integration hoặc cron job mở ticket đều đã biết mô hình này. Điểm mới là worker bên trong loop hiện không còn mang tính tất định, nên các thành phần xung quanh phải thực hiện những việc khác trước.

Bốn phần của một loop

Mọi loop hoạt động được đều có bốn phần này. Một loop bỏ qua bất kỳ phần nào sẽ có thể đánh thức bạn lúc 3am.

• Trigger. Sự kiện bắt đầu một lần chạy: timer, webhook, pull request mới hoặc alert.
• Boundary. Các file, credential và network mà agent có thể truy cập trong lần chạy đó.
• Verification. Một kiểm tra có exit code để quyết định có giữ hay loại bỏ output của lần chạy.
• Budget. Giới hạn token, thời gian và chi phí. Giới hạn này kết thúc lần chạy dù lần chạy có thành công hay không.

Đọc lại bốn phần trên dưới dạng câu hỏi, bạn sẽ có một buổi design review cho bất kỳ agent nào bạn định để chạy liên tục.

Trigger: nội dung đánh thức agent

Timer là trigger đơn giản nhất. Trên Linux server, systemd timer phù hợp hơn cron vì nó ghi log, retry theo cấu hình của bạn và không khởi chạy bản sao thứ hai của unit khi bản hiện tại vẫn đang chạy. Tính chất cuối cùng này loại bỏ lỗi chồng lấp phổ biến nhất trong các vòng lặp của agent: 2 lần chạy cùng chỉnh sửa một branch.

Tạo unit tại /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

Và tạo timer tại /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 phải hiển thị cột NEXT với thời gian trong tương lai và cột LEFT đếm ngược. Kết quả trống có nghĩa là timer chưa được enable, vì enable không có --now chỉ lập lịch cho lần boot tiếp theo. TimeoutStartSec=1800 quan trọng hơn bạn nghĩ: nếu agent bị treo khi chờ input, unit sẽ giữ trạng thái active vô thời hạn và timer sẽ không chạy lại. Đọc một lần chạy bằng journalctl -u agent-loop.service -n 50.

Nếu chạy vòng lặp từ cron, hãy tự thêm cơ chế ngăn chạy chồng lấp, vì cron sẽ tự do khởi chạy bản sao thứ hai:

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

flock -n thoát ngay với status 1 khi lock đang được giữ. Vì vậy, lần chạy thứ hai sẽ âm thầm kết thúc thay vì chạy đua với lần đầu. Cùng cấu hình systemd service và timer này có thể áp dụng cho mọi job chạy dài trên máy, dù là agent hay không.

Ranh giới: cấp bản sao riêng cho mỗi lần chạy

Một agent chỉnh sửa working tree của bạn có thể làm mất các thay đổi chưa commit. Git worktree giải quyết việc này với chi phí thấp: mỗi lần chạy có thư mục riêng và branch riêng, nhưng dùng chung một object store.

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

git worktree list in một dòng cho mỗi tree, gồm đường dẫn, commit và branch của tree đó. Khi lần chạy kết thúc, git worktree remove /srv/agent/work/triage-01 xóa thư mục, còn git worktree prune xóa các entry có thư mục đã biến mất. Từ đây, các vòng lặp chạy song song trở nên an toàn vì hai agent trên hai branch trong hai thư mục khác nhau không thể ghi đè lên nhau.

Ranh giới này cũng áp dụng cho credential. Một vòng lặp chạy unattended chứa các token có thời hạn dài, và mỗi lần chạy đều có thể làm lộ token vào log, commit hoặc context của model. Giới hạn token chỉ cho repository mà vòng lặp truy cập, và nếu có thể, không đưa token vào environment mà shell của agent có thể thấy. Đọc cách giữ secret ngoài các AI agent trước khi cấp quyền production cho vòng lặp. Để tạo ranh giới chặt hơn, chạy toàn bộ vòng lặp trên VM tạm thời có thể hủy sau mỗi lần chạy.

Xác minh: cổng kiểm soát giúp vòng lặp an toàn

Đây là phần phân biệt một vòng lặp với một cron job chỉ biết nhập lệnh. Đầu ra của agent là một đề xuất. Cổng kiểm soát sẽ quyết định.

#!/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 thực hiện công việc thực sự trong script đó. Nếu thiếu -e, một git fetch bị lỗi sẽ bị bỏ qua và lần chạy tiếp tục sử dụng origin/main đã cũ. Nếu thiếu -u, lỗi gõ tên biến sẽ được mở rộng thành chuỗi rỗng. Sau đó thao tác dọn dẹp sẽ chạy trên sai đường dẫn thay vì báo lỗi ngay.

Khối if ! npm test thể hiện toàn bộ ý tưởng. Mã thoát của một bước kiểm tra mà bạn đã tin cậy, như test suite hoặc type checker, sẽ quyết định branch được push hay bị hủy. Vòng lặp không có cổng kiểm soát sẽ tạo ra nhiều công việc mà không ai có thời gian review. Điều đó còn tệ hơn việc không làm gì. Vòng lặp có cổng kiểm soát sẽ tạo ra một branch đã đạt cùng tiêu chuẩn mà branch của một contributor phải đạt.

Hãy chọn một cổng kiểm soát báo lỗi một cách trung thực. Một test suite vẫn pass khi diff rỗng sẽ khiến vòng lặp cho rằng không làm gì cũng là thành công. Repository có test yếu sẽ tạo ra vòng lặp yếu. Vì vậy, các repository đang được quan tâm đặt việc “làm cho codebase sẵn sàng cho agent” trước việc “viết vòng lặp”.

Ngân sách: điều gì dừng một lần chạy

Một agent retry vô hạn sẽ tạo ra hóa đơn không có giới hạn. Hãy đặt giới hạn thời gian thực trên đồng hồ cho mọi loop và thực thi giới hạn đó bằng TimeoutStartSec ở phía trên; đặt giới hạn số lần retry trong script; và đặt giới hạn chi tiêu trong tài khoản của provider. Sau đó, hãy ghi log chi phí của từng lần chạy để phát hiện loop tăng chi phí trước khi hóa đơn thể hiện điều đó. Kiểm soát chi phí cho VPS chạy agent liên tục trình bày phần hạch toán, còn quản lý context mà agent giữ lại giữa các lượt trình bày đòn bẩy lớn nhất để giảm chi phí mỗi lần chạy, vì một loop đọc lại cùng repository mỗi 30 phút sẽ tính phí cho việc đó mỗi 30 phút.

Chi phí là lý do các loop thường hiệu quả hơn một session dài. Một lần chạy bắt đầu mới, thực hiện một tác vụ hẹp rồi thoát sẽ giữ context nhỏ. Một session mở trong tám giờ sẽ giữ mọi lỗi trước đó trong lịch sử và tính phí cho toàn bộ transcript ở mỗi lượt.

Các mẫu hình được các repository thịnh hành hệ thống hóa

Repository loop-engineering liệt kê 7 mẫu hình dùng trong production. Bạn nên đọc chúng như một danh sách lựa chọn thay vì một tuyên ngôn. Phân loại công việc hằng ngày. Theo dõi pull request và xử lý các comment review. Dọn các bản build lỗi trong continuous integration. Dọn dependency. Soạn changelog. Dọn dẹp sau khi merge. Phân loại issue.

Điểm chung của chúng là một công việc hẹp với điều kiện kiểm tra rõ ràng. “Sửa bản build bị lỗi” có điều kiện đạt mà máy có thể đọc. “Cải thiện codebase” thì không. Vì vậy, nó không bao giờ trở thành một loop. Nó trở thành một mớ hỗn độn chạy theo lịch.

Chúng cũng có một bản ghi bằng văn bản. Cả 2 repository đều đưa state ra khỏi cuộc hội thoại và ghi vào các file trong repository: đã chạy gì, đã tìm thấy gì, đã quyết định gì. File đó là bộ nhớ của loop. Nhờ đó, loop thứ 2 có thể tiếp tục công việc của loop thứ nhất thay vì tìm lại từ đầu. Đây cũng là cách audit agent sau khi chạy, vì context của model biến mất ngay khi run kết thúc.

Vòng lặp thất bại ở đâu

Các lỗi này không có gì đặc biệt và lặp lại ở nhiều nhóm.

• Không có bước kiểm soát. Output cứ tích lũy, không ai review, mức độ tin cậy sụp đổ và vòng lặp bị tắt.
• Chồng lấn. Có 2 lần chạy trên cùng một branch hoặc 2 agent trong cùng một working tree, tạo ra các conflict mà agent sau đó cố gắng tự giải quyết.
• Trôi âm thầm. Vòng lặp vẫn liên tục pass vì check quá yếu nên không thể fail.
• Phạm vi không giới hạn. Một trigger chạy sau mỗi commit trong repository có hoạt động cao sẽ trở thành vấn đề chi phí chỉ sau 1 ngày.

Mỗi lỗi đều có cùng một cách khắc phục: thu hẹp job, làm check chặt chẽ hơn và ghi log lần chạy. Nếu bạn không thể mô tả điều kiện pass trong 1 câu, job đó chưa sẵn sàng để tự động hóa.

Bắt đầu mà không cần thuật ngữ

Bạn không cần một framework. Một máy chủ Linux nhỏ luôn bật, một git repository có test suite bị lỗi đúng lúc cần lỗi, một systemd timer và một shell script chứa if là đủ tạo thành một vòng lặp hoàn chỉnh. Đây thực sự là điểm bắt đầu phù hợp với hầu hết mọi người, vì bạn sẽ trả lời các câu hỏi về thiết kế bằng cách chạy hệ thống thay vì chọn công cụ. Khi một vòng lặp đã ổn định, việc chạy vòng lặp thứ hai chủ yếu chỉ cần thêm một timer và một worktree. Xem cách chạy coding AI agent trên VPS để thiết lập cơ bản, và các tùy chọn AI agent tự host hiện nay nếu bạn muốn chạy chính agent trên phần cứng do mình kiểm soát.

FAQ

Kỹ thuật loop có khác với kỹ thuật prompt không?

Kỹ thuật prompt tối ưu một message: cách diễn đạt, ví dụ và định dạng output. Kỹ thuật loop tối ưu chu kỳ bao quanh message: trigger khởi chạy một lần chạy, sandbox nơi lần chạy đó thực thi, bước kiểm tra để chấp nhận hoặc từ chối output, và budget để kết thúc loop. Bạn vẫn cần một prompt tốt bên trong loop. Tuy nhiên, prompt không còn là yếu tố bạn phải tinh chỉnh hằng ngày, vì gate và trigger ảnh hưởng đến kết quả nhiều hơn.

Tôi có cần framework để xây dựng agent loop không?

Không. Một systemd timer, một git worktree cho mỗi lần chạy, một shell script kết thúc bằng lệnh test và giới hạn chi phí trên tài khoản provider là đủ để đáp ứng mọi phần trong định nghĩa này. Framework bổ sung interface lập lịch, định dạng shared memory và cơ chế định tuyến multi-agent. Những tính năng này hữu ích khi bạn chạy nhiều loop. Chúng không phải điều kiện bắt buộc để bắt đầu loop đầu tiên.

Codebase harness là gì?

Đó là tập hợp các thành phần cho phép agent làm việc trong repository mà không cần con người có mặt: thiết lập bằng một lệnh, các test chạy non-interactive và báo lỗi rõ ràng, một linter, cùng cách deploy hoặc preview thay đổi. Thuật ngữ này xuất hiện trong cùng làn sóng repository năm 2026 với kỹ thuật loop. Cách kiểm tra rất đơn giản: nếu một contributor mới không thể đi từ clone đến test xanh chỉ bằng một lệnh, agent cũng không thể làm được.

Làm cách nào để ngăn agent loop tạo ra hóa đơn lớn?

Hãy giới hạn ở 3 nơi. Đặt TimeoutStartSec trên systemd unit để kill một lần chạy bị treo. Giới hạn số lần retry trong script thay vì lặp cho đến khi thành công. Đặt hard spend limit trên API account, vì đó là giới hạn duy nhất agent không thể thuyết phục để vượt qua. Sau đó ghi log chi phí của từng lần chạy, vì một loop có chi phí tăng gấp đôi thường là loop đã âm thầm mở rộng phạm vi.

Những job nào đáng chuyển thành loop trước?

Hãy chọn một job có điều kiện pass mà máy có thể đọc được và có blast radius nhỏ. Sửa một build bị lỗi, cập nhật dependency và tạo lại changelog đều phù hợp, vì test suite hoặc diff có thể chứng minh kết quả. Các công việc mở như refactor hoặc design chưa phù hợp, vì chưa có gì để gate kiểm tra; loop không có gate là cách tốn kém để tạo thêm review debt.