Kỹ thuật thiết kế loop là gì? Định nghĩa dễ hiểu

Kỹ thuật thiết kế loop là gì

Kỹ thuật thiết kế loop là việc thiết kế chu kỳ lặp mà một AI agent thực hiện: điều gì đánh thức agent, agent được phép tác động vào đâu, output được kiểm tra như thế nào và điều gì khiến agent dừng lại. Prompt engineering định hình một message gửi cho model. Kỹ thuật thiết kế loop định hình quy trình gửi hàng nghìn message trong khi bạn đang ngủ. Đơn vị công việc chuyển từ prompt sang loop.

Tóm lại: bạn ngừng viết instruction và bắt đầu viết một control system. Agent vẫn cần instruction tốt, nhưng instruction chỉ còn là một thành phần trong chu kỳ chạy theo lịch, làm việc trong một bản sao cô lập của code, tự chứng minh kết quả bằng test và dừng lại 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 đạt 9,600 star 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à có khoảng 11,600 star vào 2026-10-27, với dòng "Stop prompting. Design the loop. Get a score." Trong tháng 7 năm 2026, README của repository này nhóm sự thay đổi thành sáu khối xây dựng: scheduling, worktree, skill, plugin và connector, sub-agent, cùng memory bền vững được lưu bên ngoài conversation. README hiện tại không còn danh sách đó (kiểm tra ngày 2026-10-27), nhưng vẫn lưu state của loop trong một file bên ngoài conversation.

Repository ghi nhận Boris Cherny, người lãnh đạo Claude Code tại Anthropic, là một trong những nguồn cảm hứng. Câu nói được trích dẫn rộng rãi của ông là:

Tôi không còn prompt 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,300 star (tính đến 2026-10-27) và gọi trực tiếp tên hai vai trò: "codebase harness", tức cơ chế giúp một repository an toàn để agent chạy test và deploy, và "loop engineer", tức người xây dựng workflow thức dậy khi có trigger, thực hiện công việc rồi ghi những gì đã học được vào một file dùng chung để loop tiếp theo có thể đọc.

Không repository nào trong hai repository này phát minh ra cách làm đó. 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 deterministic, nên các thành phần xung quanh phải thực hiện công việc khác trước.

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

Mọi loop hoạt động đúng đều có bốn thành phần này. Nếu thiếu một thành phần, loop đó có thể đánh thức bạn lúc 3 giờ sáng.

• 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 phép truy cập trong lần chạy đó.
• Verification. Kiểm tra có exit code để quyết định giữ lại hay loại bỏ output của lần chạy.
• Budget. Giới hạn token, thời gian và chi phí để kết thúc lần chạy, bất kể lần chạy có thành công hay không.

Đặt lại bốn thành phần này dưới dạng câu hỏi, bạn sẽ có một design review cho mọi agent mà bạn chuẩn bị để chạy liên tục.

Trigger: thứ đá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ách bạn đặt và không khởi động bản sao thứ hai của một unit đang chạy. Tính chất cuối cùng loại bỏ lỗi overlap phổ biến nhất trong các vòng lặp agent: 2 lần chạy cùng chỉnh sửa một branch.

Trước tiên, tạo user riêng cho agent. User này là một phần của ranh giới bảo mật, nên chỉ sở hữu /srv/agent và không sở hữu gì khác:

sudo useradd --system --home-dir /srv/agent --shell /usr/sbin/nologin agent
sudo chown -R agent:agent /srv/agent

Sau đó 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 có thời gian trong tương lai và cột LEFT đang đếm ngược. Kết quả trống nghĩa là timer chưa được enable, vì enable mà 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ĩ. Một service Type=oneshot được xem là đang khởi động cho đến khi script kết thúc. systemd mặc định tắt start timeout cho oneshot unit. Vì vậy, nếu thiếu dòng này, agent bị treo khi chờ input sẽ khiến unit mắc kẹt vĩnh viễn ở trạng thái activating. Mỗi lần timer tick sau đó đều thấy unit vẫn đang chạy và không khởi động gì. Khi có dòng này, systemd sẽ terminate lần chạy sau 30 phút và đánh dấu lần chạy đó là failed. Nếu bạn đổi unit sang Type=simple mặc định, TimeoutStartSec không còn áp dụng cho chính lần chạy đó, và RuntimeMaxSec= là setting giới hạn thời gian. Dùng journalctl -u agent-loop.service -n 50 để đọc thông tin của một lần chạy.

Nếu thay vào đó bạn chạy vòng lặp bằng cron, hãy tự thêm cơ chế chặn overlap, vì cron sẽ không ngần ngại khởi động 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 bị giữ. Vì vậy, lần chạy thứ hai âm thầm kết thúc thay vì race với lần chạy đầu tiên. Cách cấu hình systemd service và timer tương tự áp dụng cho mọi job chạy lâu trên máy, dù có phải agent hay không.

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

Một agent chỉnh sửa working tree của bạn có thể làm mất phần việc 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 và branch riêng, đồng thời 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 path, 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 worktree, nhưng chỉ xóa worktree sạch. Nếu tree có file chưa được track, file đã được track nhưng bị sửa, hoặc chứa submodule, git sẽ từ chối cho đến khi bạn thêm --force. Vì vậy, gate script bên dưới chỉ ép xóa trên path dùng để loại bỏ lần chạy đó. git worktree prune dọn 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 và trong hai thư mục khác nhau không thể ghi đè lên nhau.

Ranh giới này cũng bao gồm credential. Một vòng lặp chạy không cần giám sát sẽ giữ 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 model context. Giới hạn token cho đúng repository mà vòng lặp truy cập. Khi có thể, không để token trong environment mà shell của agent nhìn thấy. Hãy đọc cách giữ secret ngoài các AI agent trước khi cấp quyền production cho một vòng lặp. Nếu cần ranh giới chặt hơn, hãy đặt toàn bộ vòng lặp trên một VM tạm thời có thể hủy sau mỗi lần chạy. Công cụ bạn chọn cũng xác định một phần ranh giới trước khi bạn viết bất kỳ thứ gì. Vì vậy, nên đọc Cowork managed sandbox khác Claude Code trên máy của bạn như thế nào trước khi quyết định mức isolation cần tự xây dựng.

Verification: lớp 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 gõ lệnh. Output của agent chỉ là đề xuất. Lớp kiểm soát mới là thành phần 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 thực sự có tác dụng 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 trên 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, rồi thao tác cleanup chạy trên path sai thay vì dừng ngay và báo lỗi rõ ràng. Dòng cuối không có --force là có chủ ý: nếu lần chạy để lại file chưa được track hoặc chưa commit trong tree, git sẽ từ chối xóa tree đó, còn -e sẽ kết thúc lần chạy với lỗi sau khi push thay vì âm thầm xóa phần việc chưa có ai commit.

Khối if ! npm test là toàn bộ ý tưởng. Exit code của một check mà bạn đã tin cậy, chẳng hạn test suite hoặc type checker, quyết định branch được push hay bị xóa. Vòng lặp không có lớp kiểm soát sẽ tạo ra phần việc mà không ai có thời gian review, còn tệ hơn là không làm gì. Vòng lặp có lớp kiểm soát sẽ tạo ra một branch đã vượt qua cùng tiêu chuẩn mà branch của một contributor phải vượt qua. Gate xanh không cho biết agent đã chỉnh bao nhiêu code để đạt kết quả đó. Vì vậy, nên kết hợp check này với một chỉ dẫn cố định như quy tắc buộc agent thực hiện thay đổi nhỏ nhất có hiệu quả, để diff đủ nhỏ và việc review vẫn nhanh.

Hãy chọn một gate báo lỗi trung thực. Một test suite vẫn pass khi diff rỗng sẽ dạy cho vòng lặp 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 phổ biến đặt việc “làm cho codebase sẵn sàng cho agent” trước việc “viết vòng lặp”. Nếu muốn biết test suite có thực sự phát hiện regression thay vì chỉ chạy qua các dòng code hay không, mutation testing là check trả lời câu hỏi đó. Một agent trả về evidence report có thể chạy lại thay vì yêu cầu bạn tự đọc diff sẽ biến kết quả đó thành thứ bạn có thể tự xác nhận.

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 chi phí không giới hạn. Hãy đặt giới hạn thời gian thực cho mỗi loop, được thực thi bằng TimeoutStartSec ở 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 đó ghi log chi phí của từng lần chạy để phát hiện loop bị lệch trước khi hóa đơn phản ánh đ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 mang theo 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. Một loop đọc lại cùng một repository mỗi 30 phút sẽ phát sinh chi 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 với context 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 8 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 pattern được những repository đang thịnh hành hệ thống hóa

Repository về loop engineering liệt kê tám pattern production (tính đến 2026-10-27). Nên đọc chúng như một thực đơn, không phải một tuyên ngôn. Triage hằng ngày. Một loop mỏng chạy dưới dạng GitHub Action và không lưu file state. Một pull-request babysitter theo dõi review comment và trả lời chúng. Một continuous-integration sweeper xử lý các build bị lỗi. Một dependency sweeper. Một changelog drafter. Dọn dẹp sau merge. Triage issue.

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

Chúng cũng có một bản ghi bằng văn bản. Cả hai repository đều đưa state ra khỏi conversation và lưu vào các file trong repository: đã chạy gì, tìm thấy gì và quyết định gì. File đó là memory của loop. Nhờ đó, loop thứ hai 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 xong, vì context của model biến mất ngay khi run kết thúc. Live coordination là một channel riêng. một session Claude Code có thể chuyển công việc cho session khác trên cùng máy trong khi cả hai vẫn đang chạy, nhưng không có dữ liệu nào trong trao đổi đó tồn tại sau khi một trong hai session kết thúc. Vì vậy, file vẫn là phần bạn đọc lại sau đó.

Các vòng lặp thất bại ở đâu

Các lỗi này thường rất đơn giản và lặp lại ở nhiều team.

• Không có cổng 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 chéo. Hai lần chạy trên cùng một branch hoặc hai agent trong cùng một working tree tạo ra conflict, sau đó agent lại cố tự resolve.
• 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. Trigger chạy sau mọi commit trong một repository có hoạt động cao sẽ trở thành vấn đề chi phí chỉ sau một ngày.

Tất cả đều có cùng một cách xử lý: thu nhỏ job, làm check chặt hơn và ghi log lần chạy. Nếu không thể mô tả điều kiện pass trong một 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 framework. Một Linux server nhỏ luôn bật, một git repository có test suite fail khi cần fail, 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ì các câu hỏi về thiết kế được giải đáp bằng cách chạy hệ thống thay vì chọn tool. Khi một vòng lặp đã ổn định, 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 nền tảng, và các lựa chọn AI agent self-host hiện nay nếu bạn muốn agent chạy trên phần cứng do mình kiểm soát.

FAQ

Kỹ thuật xây dựng vòng lặp có khác kỹ thuật xây dựng prompt không?

Kỹ thuật xây dựng prompt tối ưu một message: cách diễn đạt, ví dụ và format output. Kỹ thuật xây dựng vòng lặp tối ưu chu kỳ bao quanh message: trigger khởi động lần chạy, sandbox nơi lần chạy hoạt động, bước kiểm tra chấp nhận hoặc từ chối output và budget kết thúc vòng lặp. Bạn vẫn cần prompt tốt bên trong vòng lặp. Tuy nhiên, prompt không còn là thứ 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 vòng lặp agent 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à spend cap trên tài khoản provider đã bao phủ mọi phần trong định nghĩa này. Framework bổ sung interface lập lịch, format shared memory và định tuyến multi-agent. Những tính năng này hữu ích khi bạn chạy nhiều vòng lặp. Chúng không phải điều kiện bắt buộc để bắt đầu vòng lặp đầ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: setup bằng một lệnh, các test chạy non-interactive và báo lỗi rõ ràng, linter, cùng cách deploy hoặc preview một 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 xây dựng vòng lặp. Cách kiểm tra thực tế rất đơn giản: nếu một contributor mới không thể đi từ clone đến green test chỉ bằng một lệnh, agent cũng không thể làm được.

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

Hãy giới hạn ở 3 nơi. Đặt TimeoutStartSec trên một systemd unit Type=oneshot như unit ở trên để kill một lần chạy bị treo. Với service Type=simple, thiết lập tương đương là RuntimeMaxSec. Giới hạn số lần retry bên 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ể dùng lời lẽ để vượt qua. Sau đó ghi log chi phí theo từng lần chạy, vì một vòng lặp có chi phí tăng gấp đôi thường là vòng lặp đã âm thầm mở rộng scope.

Những job nào đáng được chuyển thành vòng lặp trước?

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