Loop Engineering thực chiến: Giao việc cho agent, giữ lại phán đoán

Lập trình viên làm việc với agent (agentic coding) giờ không còn ngồi gõ prompt từng lượt. Quy trình lập trình đang chuyển dịch sang loop engineering — bước thay đổi hạ tầng từ việc gửi prompt thủ công sang thiết kế các vòng lặp điều khiển tự động và đệ quy. Hệ thống vòng lặp sẽ thay bạn gửi prompt, điều phối các agent chạy liên tục cho đến khi chạm các điều kiện dừng định trước.

Thay vì trực tiếp cầm tay chỉ việc và phản hồi từng bước, kỹ sư giờ dựng các hệ thống biết tự phát hiện đầu việc, chia nhỏ nhiệm vụ, chạy các bước kiểm tra xác định (deterministic checks) và cập nhật trạng thái thẳng vào tệp trên đĩa cục bộ.

Kỹ thuật này đẩy lập trình viên lên một tầng kiến trúc mới: từ người nhập lệnh trực tiếp thành người thiết kế các vòng lặp tự vận hành.

Từ prompt đơn lẻ đến vòng lặp: Vì sao kỹ sư chuyển dịch sang loop engineering?

Trong hai năm qua, thói quen phổ biến khi làm việc với coding agent vẫn là trau chuốt một prompt thật tỉ mỉ, nhồi toàn bộ bối cảnh vào một cửa sổ ngữ cảnh (context window) đơn lẻ rồi tương tác thủ công từng lượt. Kỹ sư phải ngồi canh màn hình, đọc kết quả trả về rồi gõ tiếp lệnh mới. Mô hình vòng lặp xóa bỏ sự can thiệp vụn vặt này bằng cách thiết lập các chu kỳ phản hồi tự sửa lỗi (self-correcting feedback cycles), nơi agent liên tục thực thi, kiểm tra kết quả và tự điều chỉnh hướng đi cho đến khi hoàn thành mục tiêu.

Cách làm này không phải lý thuyết suông mà đang là thực tế vận hành tại các đội ngũ xây dựng công cụ hàng đầu. Boris Cherny, Trưởng bộ phận Claude Code tại Anthropic, nói thẳng: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." Cùng góc nhìn đó, Peter Steinberger cũng khẳng định: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Về mặt kiến trúc, loop engineering nằm ở tầng trên của agent harness engineering (môi trường bao quanh một agent đơn lẻ) và mô hình nhà máy (factory model). Vòng lặp vận hành theo bộ hẹn giờ hoặc lịch trình cố định, tự động kích hoạt các sub-agent trợ lý và nạp lại ngữ cảnh mới cho hệ thống.

Sự phát triển này bắt nguồn từ các đoạn mã bash tự dựng như vòng lặp Ralph của Geoff Huntley (while :; do cat PROMPT.md | claude-code ; done), liên tục chuyển lệnh từ tệp prompt vào CLI. Hiện nay, kiến trúc vòng lặp đã đạt được sự đồng nhất và chuẩn hóa nguyên ngữ (primitive parity) giữa các công cụ thương mại hàng đầu như Claude Code và OpenAI Codex:

Automations: Cơ chế lập lịch phát hiện và phân loại (triage) công việc (tab Automations trên Codex tương đương với /schedule và lifecycle hooks trên Claude Code).
Worktrees: Môi trường git tách biệt để các agent vận hành song song không gây xung đột ghi tệp (tính năng thread worktree tích hợp trên Codex tương đương với command git worktree và cờ --worktree trên Claude Code).
Skills: Định dạng đóng gói tri thức dự án chuẩn hóa (SKILL.md) giúp agent không phải đoán định quy chuẩn.
Connectors và Plugins: Tích hợp công cụ ngoại vi thông qua giao thức mở MCP (Model Context Protocol).
Sub-agents: Phân tách vai trò giữa agent thực thi ("maker") và agent kiểm tra ("checker") (cấu hình TOML trong .codex/agents/ tương đương với cấu hình tệp markdown trong .claude/agents/).

Bên cạnh 5 nguyên ngữ này, vùng lưu trữ trạng thái trên đĩa cục bộ (các tệp markdown như AGENTS.md hoặc bảng việc Linear) chính là xương sống của toàn bộ kiến trúc. Agent sẽ xóa sạch bộ nhớ sau mỗi phiên làm việc, nhưng repository lưu trên đĩa cứng thì giữ lại trọn vẹn tiến trình.

Hai nguyên ngữ cốt lõi: Phân biệt rõ ranh giới giữa Goal và Loop

Trong các công cụ như Claude Code hay Codex, quy trình vận hành xoay quanh hai nguyên ngữ thực thi cốt lõi: Goal (/goal) và Loop (/loop).

Nguyên ngữ Goal (/goal) điều khiển một tác vụ có ranh giới rõ ràng, chạy đệ quy cho đến khi đạt được điều kiện dừng mang tính xác định và kiểm chứng được. Cơ chế của Goal dựa vào một mô hình đánh giá (evaluator model) độc lập: sau mỗi lượt thực thi của agent làm việc, mô hình đánh giá sẽ rà soát toàn bộ nhật ký phiên (transcript) và kết quả đầu ra để đối chiếu với điều kiện dừng. Thiết kế này ngăn chặn triệt để tình trạng agent tự chấm điểm bài làm của mình hoặc tự ý dừng sớm khi chưa đạt chuẩn kỹ thuật. Ví dụ về lệnh CLI cụ thể: /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries. Kỹ sư thường dùng /goal để sửa lỗi đệ quy hoặc tối ưu hóa hiệu năng cho đến khi toàn bộ bài kiểm thử chuyển sang màu xanh.

Trong khi đó, nguyên ngữ Loop (/loop / /schedule) hoạt động như một bộ lập lịch cron theo thời gian để kích hoạt lại prompt theo các khoảng cố định. Cú pháp điển hình có dạng: /loop 5m check my PR, address review comments, and fix failing CI. Điểm khác biệt nằm ở bề mặt thực thi và chu kỳ sống: lệnh /loop cục bộ chạy trực tiếp ngay trong phiên CLI hiện tại, tự động hết hạn sau 7 ngày hoặc dừng ngay khi bạn đóng cửa sổ terminal. Còn nếu muốn duy trì chu kỳ chạy ngầm trên đám mây ngay cả khi đã gập máy tính, lệnh /schedule sẽ đẩy quy trình thực thi lên các cloud routine.

Tên nguyên ngữ	Cơ chế kích hoạt	Điều kiện dừng	Trường hợp sử dụng tối ưu
Goal (`/goal`)	Kích hoạt theo yêu cầu công việc đơn lẻ	Điều kiện xác định bằng số liệu/kiểm thử đạt hoặc chạm ngưỡng số lượt quy định	Tối ưu hóa hiệu năng, sửa lỗi đến khi vượt qua kiểm thử (pass test), hoàn thành tác vụ có tiêu chuẩn đầu ra rõ ràng
Loop (`/loop` / `/schedule`)	Kích hoạt theo khoảng thời gian cố định (Interval/Cron) hoặc sự kiện	Hết hạn phiên (7 ngày với `/loop` cục bộ) hoặc hủy lịch thủ công (`/schedule`)	Giám sát CI, tổng hợp lỗi/issue hàng ngày, kiểm tra PR định kỳ, tự động phân loại (triage) công việc

Bài toán phối hợp: Khi Loop làm nhiệm vụ triage và kích hoạt Goal

Sức mạnh thực sự của loop engineering bộc lộ rõ nhất khi bạn ghép nguyên ngữ Loop (chuyên phát hiện và phân loại việc) với nguyên ngữ Goal (chuyên thực thi chi tiết). Mô hình bảng điều khiển hàng ngày (daily control panel pattern) thiết lập một vòng lặp chạy định kỳ mỗi 12 đến 24 giờ để quét các issue mới trên GitHub, các bản ghi CI báo lỗi hoặc những pull request đang chờ xử lý.

Quy trình phối hợp diễn ra theo các bước tuần tự:

Vòng lặp Loop chạy theo lịch trình định kỳ để kiểm tra các thay đổi trên hệ thống.
Hệ thống gọi một kỹ năng phân loại (triage skill) để đọc dữ liệu, phân tích độ ưu tiên và lọc bỏ các yêu cầu không phù hợp.
Kết quả phân loại được ghi cấu trúc vào tệp trạng thái trên đĩa cục bộ (AGENTS.md, các tệp tiến độ) hoặc cập nhật lên Linear thông qua kết nối MCP.
Với các sự cố cần xử lý, hệ thống kích hoạt một /goal bên trong một git worktree độc lập để viết mã, chạy kiểm thử và đưa ra bản sửa lỗi.

Cấu hình mẫu cho command phối hợp: /loop every 24h "Check GitHub for issues labeled 'bug'. If one exists, use /goal to implement a fix until all local tests pass and push the branch."

Duy trì tệp trạng thái trên đĩa là yêu cầu sống còn trong kiến trúc này. Cửa sổ ngữ cảnh của các mô hình LLM sẽ bị xóa sạch khi bắt đầu một phiên làm việc mới. Mọi thiết kế hệ thống đều phải tuân theo một nguyên lý cốt lõi: Mô hình xóa sạch bộ nhớ sau mỗi phiên, nhưng repository thì giữ lại ký ức. Việc ghi nhận lịch sử xử lý, danh sách tồn đọng và kết quả kiểm thử vào tệp AGENTS.md trên repository giúp chu kỳ chạy tiếp theo tiếp quản đúng trạng thái dang dở mà không giẫm lại các vết xe đổ trước đó.

Điều phối song song: Kiến trúc vận hành nhiều agent mà không xung đột

Khi thả đồng thời từ 5 đến 10 agent chạy song song, nếu để chúng cùng thao tác trên một thư mục làm việc thì xung đột ghi tệp là điều chắc chắn xảy ra. Giải pháp hạ tầng bắt buộc ở đây là Git worktree (--worktree hoặc cơ chế cách ly luồng tích hợp). Mỗi sub-agent làm việc trong một thư mục tách biệt hoàn toàn với nhánh git riêng nhưng vẫn dùng chung lịch sử repository, dập tắt nguy cơ các agent ghi đè mã nguồn của nhau.

Trong kiến trúc song song, tách bạch vai trò giữa agent thực thi ("maker") và agent kiểm tra ("checker") là nguyên tắc then chốt. Mô hình sinh mã luôn có xu hướng tự chấm điểm bài làm của mình quá dễ dãi. Bạn cần cấu hình các sub-agent riêng biệt (lưu tại .claude/agents/ dưới dạng markdown hoặc .codex/agents/ dưới dạng TOML) với system prompt và tầng mô hình khác nhau. Sub-agent làm nhiệm vụ thăm dò hay đọc log có thể dùng mô hình nhỏ, tốc độ cao; trong khi sub-agent thẩm định an ninh hay kiểm tra logic nghiệp vụ bắt buộc phải dùng mô hình mạnh nhất với khả năng suy luận sâu.

Chiến lược phân bổ cửa sổ ngữ cảnh cũng phải tính đến trần hiệu dụng thực tế (khoảng 170K token) và hiện tượng suy giảm chất lượng suy luận (autoregressive degradation) khi ngữ cảnh bị nhồi nhét quá mức. Phiên làm việc chính chỉ nên đóng vai trò là một bộ điều phối (scheduler) thật gọn nhẹ. Hệ thống sẽ khởi tạo các sub-agent ngắn hạn để nhận những việc ngốn token như rà soát codebase hay mổ xẻ trace thực thi, rồi chỉ gom kết quả đã cô đọng về phiên chính.

Trọng tài tối cao quyết định tính đúng đắn của mã nguồn luôn là áp lực ngược (backpressure) bằng chương trình. Các công cụ kiểm tra xác định như trình biên dịch (compiler), trình kiểm tra kiểu (type checker), dialyzer, pytest, hay Rust borrow checker dựng nên những rào cản kỹ thuật không thể thỏa hiệp. Mã do agent viết ra bắt buộc phải vượt qua toàn bộ các bài kiểm tra này trước khi được chấp nhận, loại bỏ hoàn toàn thói quen sửa lỗi qua loa trên bề mặt hoặc tạo ra thứ mã thậm chí không biên dịch nổi.

Nghệ thuật ủy thác: Những gì nên giao phó và những gì bắt buộc phải giám sát

Mức độ an toàn khi ủy thác việc cho các vòng lặp phụ thuộc vào hai yếu tố: tính xác định của bài toán và bộ công cụ kiểm thử đi kèm.

Những tác vụ an toàn để bạn buông tay ủy thác hoàn toàn bao gồm: viết bổ sung unit test cho đủ độ phủ, dọn sạch lỗi linter trên toàn dự án, nâng cấp phiên bản thư viện phụ thuộc, tự động phân loại PR hàng ngày dựa trên bộ quy tắc đóng góp cứng (chẳng hạn tự động đóng các PR dịch thuật nếu quy trình dự án không nhận) và tái hiện các lỗi đơn giản. Đây đều là những việc có tiêu chuẩn đầu ra rành mạch và đo đếm được bằng máy.

Ngược lại, những khu vực bắt buộc bạn phải mắt thấy tai nghe bao gồm: vùng mã nguồn nhạy cảm (xác thực người dùng, thuật toán bảo mật, luồng tiền tài chính, migration cơ sở dữ liệu cốt lõi, các hệ thống cũ (brownfield) chằng chịt nợ kỹ thuật), các quyết định mở về mặt kiến trúc và mọi thay đổi chạm vào public API. Với những chỗ này, kỹ sư phải đích thân soi từng dòng diff chứ không thể phó mặc cho agent.

Riêng với giao diện người dùng (Frontend & UX), nguyên tắc bất di bất dịch là không bao giờ nghiệm thu chỉ vì agent báo đã sửa tệp thành công. Bạn cần một quy trình xác minh đa bước thực thụ thông qua kỹ năng kiểm thử frontend.

Dưới đây là cấu hình tham chiếu cho kỹ năng xác minh giao diện (verify-frontend-change):

markdown

---
name: verify-frontend-change
description: Verify any UI change end-to-end before declaring it done.
---
 
**Xác minh các thay đổi giao diện (Verifying frontend changes):**
Never report a UI change as complete based on a successful edit alone.
Verify it the way a human reviewer would:
 
1. Start the dev server and open the edited page in the browser.
2. Interact with the change directly. For a new control (button, input,
   toggle): click it, confirm the expected state change, and screenshot
   before/after.
3. Check the browser console: zero new errors or warnings.
4. Use the Chrome DevTools MCP, run a performance trace and audit
   Core Web Vitals.
 
If any step fails, fix the issue and rerun from step 1 - do not hand
back partially verified work.

Vòng lặp không thể mua được điều gì: Phán đoán vẫn phải là của kỹ sư

Vòng lặp tự động giúp bạn nhân rộng quy mô và tốc độ gõ phím cơ học, nhưng tuyệt đối không mua được gu thẩm mỹ kỹ thuật, phán đoán kiến trúc hay trách nhiệm giải trình của con người. Vận hành loop engineering mà buông lỏng kiểm soát sẽ đẩy dự án vào ba rủi ro mang tính hệ thống: "nợ hiểu biết" (comprehension debt: mã nguồn biến đổi nhanh hơn khả năng thấu hiểu của kỹ sư), "sự đầu hàng về nhận thức" (cognitive surrender: gật đầu thụ động trước mọi kiến trúc do agent vẽ ra), và lãng phí tài nguyên do vòng lặp bị kẹt (ở đây bắt buộc phải cài cầu dao ngắt mạch, chẳng hạn dừng ngay lập tức nếu một lệnh thất bại 3 lần liên tiếp mà không tạo ra thay đổi trạng thái nào).

Tôi dựng vòng lặp là để giải phóng đôi tay khỏi những thao tác cơ học lặp đi lặp lại, chứ không phải để trốn tránh việc đọc hiểu hệ thống. Hãy để agent cày ải đêm ngày, nhưng quyền bấm nút và trách nhiệm giải trình khi hệ thống gặp sự cố vẫn phải nằm trọn trong tay bạn.