Loop Engineering: Ngừng ra lệnh cho AI, hãy thiết kế vòng lặp

Thay vì "cầm tay chỉ việc" cho AI qua từng lượt phản hồi thủ công, kỹ sư dựng một hệ thống tự vận hành để gỡ độ trễ do con người phải liên tục để mắt (human attention latency) ra khỏi quy trình phát triển phần mềm.

Loop Engineering là gì? (Từ prompt → context → harness → loop)

Lịch sử tương tác giữa kỹ sư và AI đang tiến hóa qua bốn giai đoạn kỹ thuật:

1. Prompting: gõ lệnh thủ công từng lượt, phản hồi dựa trên một kết quả đầu ra đơn lẻ.
2. Context: cung cấp dữ liệu nền (codebase, tài liệu) để agent hiểu sâu hệ thống.
3. Harness: thiết lập môi trường thực thi (sandbox, terminal, file system) cho một agent đơn lẻ.
4. Loop: hệ thống nằm trên harness, tự gọi agent, tự kiểm tra kết quả và lặp lại cho đến khi đạt mục tiêu.

Boris Cherny (trưởng dự án Claude Code tại Anthropic) và Peter Steinberger cùng chỉ ra rằng công việc của kỹ sư hiện nay không phải là trực tiếp gõ prompt cho agent, mà là thiết kế các "vòng lặp". Ở đây, kỹ sư đặt ra các mục tiêu đệ quy — những mục tiêu mà từ đó hệ thống tự suy ra các bước con dựa trên "vibe" hoặc yêu cầu kỹ thuật, tự làm rồi tự điều chỉnh cho đến khi thỏa điều kiện dừng. Dù là một vòng lặp đơn agent tự tinh chỉnh bản nháp của chính nó, hay một "đội" (fleet) gồm nhiều sub-agent chuyên biệt, triết lý cốt lõi vẫn vậy: thay con người ở vai trò người ra lệnh bằng một hệ thống tự quản lý các agent.

Vì sao Loop Engineering nổi lên lúc này?

Điểm nghẽn lớn nhất trong quy trình phát triển AI-native hiện nay là chính con người. Khi bạn ra lệnh cho AI từng bước một, cả hệ thống chỉ chạy nhanh bằng đúng tốc độ phản ứng của bạn. Các kỹ sư hàng đầu ở Anthropic và OpenAI không còn ngồi gõ lệnh nữa; họ thiết kế sẵn các routine để hệ thống tự vận hành 24/7, và đã có người quản lý cùng lúc 10–15 agent chạy song song.

Sự trỗi dậy của Loop Engineering còn đến từ sự hội tụ của các công cụ đủ mạnh. Trước đây, muốn dựng một vòng lặp tự động bạn phải tự bảo trì một "đống script bash" mong manh; giờ hạ tầng lập lịch, cô lập và lưu trạng thái đã được đóng gói sẵn trong sản phẩm:

• Claude Code: tích hợp sẵn các khối dựng cơ bản (primitive) như /loop và /goal cho vòng lặp.
• Codex: cho phép thiết lập mục tiêu và quy trình tự động hóa mà không cần viết quá nhiều script tùy chỉnh.

"Hình dạng" của một vòng lặp đang dần độc lập với công cụ: dù bạn dùng Claude Code, Codex hay Grok, các yêu cầu kiến trúc để vòng lặp chạy được vẫn giống nhau.

Vòng lặp mở/đóng và vòng lặp trong/ngoài

Một tác vụ có hợp với loop hay không tùy vào ba điều kiện: nó lặp lại thường xuyên, có định nghĩa "Done" mà máy tự kiểm tra được, và chi phí thử sai thấp.

• Open-loop (vòng lặp mở): tính khám phá cao, có thể bật ra những giải pháp ngoài dự kiến. Tuy nhiên nó ngốn từ 50k đến 2M token mỗi lần chạy và dễ tạo ra "slop" (code rác) nếu thiếu tiêu chí chặt chẽ.
• Closed-loop (vòng lặp đóng): bị ràng buộc bởi mục tiêu xác định. Đây là mô hình tối ưu cho công việc thực tế nhờ kiểm soát được ngân sách và càng chạy càng chính xác hơn qua từng lượt.
• Inner loop (vòng lặp trong): dùng context window (bộ nhớ tạm). Agent tự kiểm tra kết quả ngay trong phiên làm việc, ví dụ chạy test trước khi báo "Done".
• Outer loop (vòng lặp ngoài): dùng bộ nhớ lưu trên đĩa (disk-based memory). Hệ thống học hỏi xuyên suốt nhiều phiên, giúp agent không lặp lại lỗi cũ của ngày hôm trước.

Giải phẫu một vòng lặp: 5 thành phần cốt lõi + bộ nhớ

Dựa trên khung lý thuyết của Addy Osmani, một vòng lặp hoàn chỉnh gồm năm thành phần:

1. Automations: nhịp đập (heartbeat) của hệ thống — cron job, GitHub Actions, hook.
2. Worktrees: dùng git worktree để cô lập môi trường. Nhiều agent chạy song song trên các nhánh khác nhau mà không giẫm lên file của nhau.
3. Skills: tri thức dự án được ghi xuống file SKILL.md (quy chuẩn code, lệnh build) thay vì bắt agent đoán mò mỗi lượt.
4. Plugins/Connectors: khả năng tương tác với thế giới thực qua MCP (Model Context Protocol), GitHub, Slack, Jira.
5. Sub-agents: chia tách vai trò Maker (người làm) và Checker (người kiểm tra).

Thành phần "cộng một" là bộ nhớ (memory/state). File STATE.md hay progress.txt chính là chỗ dựa giúp loop không bị "mất trí nhớ" giữa các phiên:

• SKILL.md chứa kiến trúc và metadata dự án.
• RULES.md chứa "bài học kinh nghiệm" (learning memory). Mỗi khi agent mắc lỗi, kỹ sư cập nhật một quy tắc vào đây để các lần chạy sau không lặp lại sai lầm đó.

Một file SKILL.md đơn giản có thể trông như sau:

# Project Skills: Auth Module
- Framework: Vitest
- Convention: File naming must be *.test.ts
- Requirement: Always mock Redis during tests using MSW.

Một vòng lặp chạy như thế nào trong thực tế

Hệ thống thường vận hành dựa trên hai cơ chế nền tảng:

• ReAct (Reason + Act): suy nghĩ → hành động → quan sát kết quả → lặp lại. Mỗi hành động đều bám vào phản hồi của lượt trước.
• Reflexion: phân tích thất bại bằng ngôn ngữ tự nhiên để tự điều chỉnh chiến thuật cho lần thử sau, thay vì mù quáng thử lại y hệt.

Lấy ví dụ một "Analytics Watcher": hệ thống theo dõi log lỗi. Khi thấy lỗi tăng vọt đột biến (spike), bước đầu tiên của loop là tái hiện lỗi đó thành một bài integration test cố tình cho thất bại. Sau đó Maker agent sửa code cho đến khi bài test này chạy đậu, rồi mới mở Pull Request. Chính cái test đỏ đó là điều kiện dừng khách quan nhất — agent có thể "lý sự" với con người, nhưng không thể cãi một bài test đang đỏ.

Quality gate, maker/checker và bộ nhớ

Để chặn việc tạo ra code kém chất lượng, một vòng lặp cần hai trụ:

• Quality gate: phải là những rào cản khách quan, tất định (deterministic) như trình biên dịch, linter hoặc bộ test suite. Agent có thể biện minh bằng lời, nhưng không thể tranh luận với một red test hay một bản build hỏng. Loop phải lặp tiếp cho đến khi cổng chuyển xanh.
• Maker/Checker split: agent viết code không được phép tự phê duyệt sản phẩm của chính mình. Phải dùng một model riêng biệt (thường mạnh hơn) đóng vai Checker, tạo ra một quy trình review mang tính đối kháng để bạn yên tâm rời tay khỏi vòng lặp.

Một vòng lặp "biết học" sẽ ghi mỗi lần vướng quality gate thành một ràng buộc vĩnh viễn trong RULES.md. Ví dụ, nếu loop fail vì dùng cú pháp JSON path đã lỗi thời, điều đó trở thành một quy tắc trên đĩa. Thay vì học lại kiến trúc dự án mỗi sáng, agent đọc quy tắc và tránh được bug của ngày hôm qua.

Giới hạn của vòng lặp và trách nhiệm của kỹ sư

• Chi phí token: một vòng lặp có thể tiêu tốn hàng nghìn USD nếu thiếu điều kiện dừng hoặc hard cap (giới hạn cứng, ví dụ dừng sau 8 lượt thử). Càng nhiều sub-agent và nhịp chạy (cadence) càng dày thì chi phí càng nhân lên nhanh.
• Nợ thấu hiểu (comprehension debt): khi loop đẩy code đi nhanh hơn tốc độ bạn đọc, khoảng cách giữa codebase và mức độ bạn thực sự hiểu nó cứ rộng dần. Đẩy đi thứ code bạn chưa đọc nghĩa là bạn không còn là kỹ sư, chỉ là hành khách.
• Buông xuôi nhận thức (cognitive surrender): cái nguy hiểm khi phó mặc hoàn toàn phán đoán cho hệ thống. Loop là một đòn bẩy; nếu bạn dùng nó để khỏi phải suy nghĩ, nó chỉ giúp bạn đào hố sâu hơn, nhanh hơn.

Tóm lại, loop chỉ là đòn bẩy hiệu suất. Kỹ sư vẫn là người chịu trách nhiệm cuối cùng cho chất lượng của từng dòng code đưa ra sản phẩm.

Bắt đầu xây vòng lặp với Claude Code / Codex

Hãy bắt đầu từ các lệnh có sẵn:

• Claude Code:
  • Dùng /loop cho các tác vụ lặp lại theo nhịp định kỳ.
  • Dùng /goal (hỗ trợ từ v2.1.139) để đặt mục tiêu kèm điều kiện dừng kiểm tra được.
  • Dùng Dynamic Workflows (từ v2.1.154) với từ khóa ultracode để AI tự chia tách tác vụ cho hàng trăm sub-agent.
• Codex: thiết lập trong tab Automations và theo dõi kết quả qua Triage inbox.

Một đoạn shell script minh họa cách tự động xử lý khi CI báo lỗi (CI failure):

#!/bin/bash
# daily_loop.sh - Kiểm tra và sửa lỗi CI định kỳ
while true; do
  echo "Checking CI status..."
  # Tool kiểm tra log CI, nếu phát hiện lỗi sẽ kích hoạt agent
  claude --print "Phân tích log CI, tái hiện lỗi bằng test case và sửa cho đến khi pass."
 
  # Kiểm tra chuỗi "DONE" trong log để thoát vòng lặp
  if grep -q "DONE" .loop/run.log; then
    break
  fi
  sleep 300 # Chạy lại sau 5 phút
done

Các câu hỏi thường gặp

Loop có tốn kém không? Có. Một vòng lặp có thể đốt hàng triệu token. Hãy ưu tiên closed-loop và luôn đặt hard cap (tối đa 5–8 lượt chạy) để bảo vệ ngân sách.

Tại sao cần mô hình Maker/Checker? Để đảm bảo tính khách quan. Agent thực thi thường "tự mãn" với kết quả mình vừa làm; một Checker độc lập sẽ phát hiện các lỗ hổng logic tốt hơn nhiều.

Làm sao để loop không chạy vô tận? Dùng điều kiện dừng dựa trên chỉ số khách quan (như test pass 100%) kết hợp với giới hạn cứng về số lượt chạy (hard cap) hoặc thời gian chạy.

Tài liệu tham khảo

• Loop Engineering — Addy Osmani
• Loop Engineering 101 — Daniel Moka
• Loop Engineering — Cobus Greyling
• How To Build a Claude Loop: Better Than 99% of People — Gao Dalie
• Finally. Agent Loops Clearly Explained.
• I guess we're writing loops now?