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 cộng đồng xác lập ngay lúc này. Repository GitHub cobusgreyling/loop-engineering đã vượt 9,600 star trong vòng hai tháng kể từ khi xuất hiện lần đầu (tính đến tháng 7 năm 2026), với khẩu hiệu "Đừng viết prompt nữa. Hãy thiết kế loop. Hãy lấy điểm." Nó tóm tắt sự thay đổi này thành 6 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 cuộc hội thoại.

Tài liệu này trích dẫn Boris Cherny, người phụ trách Claude Code tại Anthropic:

Tôi không còn viết prompt cho Claude nữa. Tôi chạy các loop để chúng viết prompt cho Claude.

Một repository thứ hai, AI-Builder-Club/skills, có gần 1,100 star (tính đến tháng 7 năm 2026) và gọi trực tiếp tên 2 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 lại 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ố đó phát minh ra cách làm này. Bất kỳ ai từng chạy nightly build, linter trong continuous integration hoặc cron job tạo 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 deterministic, nên các thành phần xung quanh phải đảm nhiệm nhiều việc khác hơn.

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: cách đá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 cấu hình và không khởi chạy bản sao thứ hai của một unit vẫn đang chạy. Đặc tính cuối cùng này loại bỏ lỗi overlap phổ biến nhất trong các vòng lặp của agent: hai 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ị một cột NEXT với thời gian trong tương lai và một 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ên lịch cho lần boot tiếp theo. TimeoutStartSec=1800 quan trọng hơn bạn nghĩ: nếu agent bị treo vì chờ input, unit sẽ tiếp tục active vô thời hạn và timer sẽ không chạy lại. Đọc log của một lần chạy bằng journalctl -u agent-loop.service -n 50.

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

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

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 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 đường dẫn, commit và branch. 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 liên quan đến credential. Một vòng lặp chạy unattended 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 phạm vi của token ở đúng repository mà vòng lặp truy cập. Khi có thể, không đưa token vào environment mà shell của chính agent nhìn thấy. Hãy đọc cách giữ secret ngoài 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 chạy toàn bộ vòng lặp trên một disposable VM 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 này trước khi bạn viết bất kỳ thứ gì. Vì vậy, nên đọc Cowork managed sandbox so với Claude Code trên máy của bạn trước khi quyết định mức độ isolation cần tự xây dựng.

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. Output của agent là một đề xuất. Cổng kiểm soát đưa ra 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 không có -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 không có -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ì báo lỗi rõ ràng.

Khối if ! npm test là toàn bộ ý tưởng. Exit code của một check mà bạn đã tin cậy, như test suite hoặc type checker, 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 công 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ó cổng 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. Cổng màu xanh không cho biết agent đã sửa bao nhiêu code để đạt được kết quả đó. Vì vậy, nên kết hợp check 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 nhưng có tác dụng, để diff đủ nhỏ và việc review vẫn nhanh.

Hãy chọn một cổng kiểm soát có thể báo lỗi trung thực. Một test suite vẫn pass với 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 đ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”. Nếu muốn biết test suite có thực sự phát hiện regression hay chỉ chạy qua các dòng code, mutation testing là check trả lời câu hỏi đó. Một agent trả lại report bằng chứng 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 thịnh hành chuẩn hóa

Repository loop-engineering liệt kê 7 pattern dùng trong production. Bạn nên đọc chúng như một danh sách lựa chọn, không phải một tuyên ngôn. Triage hằng ngày. Một pull-request babysitter theo dõi các review comment và trả lời chúng. Một continuous-integration sweeper xử lý các build bị đỏ. Một dependency sweeper. Một changelog drafter. Dọn dẹp sau merge. Triage issue.

Điểm chung của chúng là một nhiệm vụ hẹp với điều kiện chặn rõ ràng. “Sửa build đang fail” có điều kiện đạt mà máy có thể đọc đượ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ớ công việc 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 trạng thái ra khỏi cuộc trò chuyện và ghi vào các file trong repository: đã chạy gì, tìm thấy gì và đã quyết định gì. File đó là bộ nhớ của loop. Đây là lý do loop thứ 2 có thể tiếp tục công việc của loop thứ nhất thay vì phát hiện lại từ đầu. File đó cũng cho phép bạn audit agent sau khi chạy xong, vì context của model biến mất ngay khi run kết thúc. Việc phối hợp trực tiếp là một channel riêng, và 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ả 2 vẫn đang chạy. Tuy nhiên, không có gì trong trao đổi đó tồn tại sau khi một trong 2 session kết thúc, nên file vẫn là phần bạn đọc lại sau này.

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 loop có khác prompt engineering không?

Prompt engineering 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ỳ xoay quanh message: trigger bắt đầu một lần chạy, sandbox nơi nó chạy, bước kiểm tra chấp nhận hoặc từ chối output, và budget kết thúc lần chạy. Bạn vẫn cần một prompt tốt bên trong loop. Nhưng 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 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à 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, định dạng shared memory và cơ chế định tuyến multi-agent. Những thứ 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 một repository mà không cần con người trực tiếp hỗ trợ: quy trình setup 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 một thay đổi. Thuật ngữ này xuất hiện cùng làn sóng repository năm 2026 với kỹ thuật loop. 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 test xanh chỉ bằng một lệnh, agent cũng không thể làm được.

Làm sao để ngăn agent loop làm phát sinh hóa đơn lớn?

Hãy giới hạn ở 3 nơi. Đặt TimeoutStartSec trên systemd unit để tiến trình bị treo sẽ bị dừng. Giới hạn số lần retry trong script thay vì loop cho đến khi thành công. Đặt hard spend limit trên API account, vì đó là giới hạn duy nhất mà agent không thể tìm cách vượt qua bằng lời. Sau đó ghi log chi phí theo 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 scope.

Trước tiên nên chuyển những job nào thành loop?

Hãy chọn job có điều kiện pass ở dạng machine-readable và blast radius nhỏ. Sửa một build bị đỏ, 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ả. Những công việc mở như refactor hoặc thiết kế chưa phù hợp, vì chưa có gì để gate kiểm tra. Một loop không có gate là cách tốn kém để tạo thêm review debt.