# Loop Engineering là gì? Cách hệ thống AI tự cải thiện kết quả

> Kỹ thuật Loop Engineering giúp chuyển đổi từ việc viết prompt thủ công sang thiết kế các hệ thống AI tự động đánh giá và cải thiện kết quả.

Nguồn: https://camnangai.com/ky-thuat/loop-engineering-la-gi  
Xuất bản: 2026-10-24

**Loop Engineering** là phương pháp thay thế việc viết prompt thủ công bằng cách thiết kế một hệ
  thống tự động, đệ quy: giao việc cho agent, truyền ngữ cảnh, đánh giá đầu ra, cập nhật trạng thái
  và liên tục lặp lại cho đến khi đạt mục tiêu.


Khi bạn còn ngồi gõ prompt và điều khiển agent thủ công từng lượt, chính con người sẽ trở thành điểm nghẽn về cả năng lực nhận thức lẫn băng thông kiểm duyệt (review bandwidth). Ở quy mô 10 yêu cầu, bạn có thể đọc và đánh giá cẩn thận từng dòng mã hay câu trả lời. Nhưng khi quy mô tăng lên 50 hay 200 yêu cầu, mô hình vẫn duy trì tốc độ tạo văn bản trong khi khả năng kiểm soát chất lượng của bạn bị suy giảm do mệt mỏi. Loop Engineering giải quyết triệt để rào cản này bằng cách đưa toàn bộ quy trình đánh giá, ghi nhớ và ra quyết định dừng ra khỏi đầu kỹ sư, đóng gói thành một kiến trúc phần mềm vận hành tự động.


  Bằng cách thiết lập cơ chế tự kiểm tra xác thực dựa trên dữ liệu lưu trên đĩa, vòng lặp AI có thể
  liên tục cải thiện kết quả đầu ra mà không yêu cầu sự giám sát trực tiếp từ bạn ở từng bước thực
  thi.


![Chuyển dịch từ việc viết prompt thủ công sang kiến trúc vòng lặp Loop Engineering tự động lặp lại và tự sửa lỗi](https://camnangai.com/articles/loop-engineering-la-gi/01-infographic-vn.webp)

## Từ prompt thủ công đến Loop Engineering: Vì sao kỹ sư cần chuyển dịch tư duy?

Trong mô hình tương tác AI truyền thống, quy trình của bạn diễn ra theo một vòng lặp thủ công: gõ prompt, đọc kết quả trả về, tự phát hiện lỗi, điều chỉnh bối cảnh và gửi lại prompt mới. Con người khi đó là động cơ duy nhất kéo vòng lặp chạy. Khi bạn áp dụng vào công việc thực tế với khối lượng lớn, sự suy giảm chú ý sẽ khiến chất lượng kiểm soát bị trôi lệch (quality control drift). Mô hình sinh ra kết quả ở chu kỳ thứ 200 với cùng tốc độ như chu kỳ đầu tiên, nhưng bạn lúc đó không còn đủ tỉnh táo để phát hiện các lỗi sai tinh vi nữa.

Sự phụ thuộc quá mức vào kiểm duyệt thủ công dẫn đến ba gánh nặng kỹ thuật lớn mà Addy Osmani đã định nghĩa: "nợ hiểu biết" (comprehension debt) gia tăng khi mã nguồn do AI tạo ra vượt quá khả năng đọc hiểu của bạn; "đầu hàng nhận thức" (cognitive surrender) khi bạn mệt mỏi và chấp nhận mọi đầu ra mà không buồn kiểm chứng; và "gánh nặng điều phối" (orchestration tax) khi thời gian bạn quản lý agent còn tốn kém hơn tự tay viết mã. Loop Engineering xuất hiện để loại bỏ các điểm nghẽn này bằng cách chuyển giao công việc đánh giá và duy trì ngữ cảnh cho một hệ thống phần mềm chuyên biệt.

Về mặt cơ chế vận hành, bạn cần phân biệt rõ giữa Agent Harness và Loop. Agent Harness chỉ quản lý môi trường thực thi và ngữ cảnh trò chuyện của một phiên chạy đơn lẻ. Trong khi đó, Loop nằm ở tầng kiến trúc ngay phía trên harness: nó vận hành dựa trên bộ định thời (timers) hoặc lịch trình (cron/hooks), tự khởi tạo các nhánh công việc (worktree) và sub-agent, đánh giá kết quả đầu ra dựa trên trạng thái lưu trữ cứng trên đĩa (như tệp `AGENTS.md` hoặc bảng Linear), và liên tục thúc đẩy agent qua nhiều phiên chạy mà không cần bạn phải ngồi kích hoạt từng lệnh.

Để hình dung rõ vị trí của Loop Engineering trong hệ thống, bạn có thể tham khảo 4 cấp độ thực thi công việc dưới đây:

| Cấp độ kiến trúc | Cơ chế vận hành chính                                                                            | Khả năng tự chủ và điều phối                                                                     |
| :--------------- | :----------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------- |
| **Prompt**       | Một cuộc gọi API đơn lẻ, phụ thuộc hoàn toàn vào đánh giá tức thì của con người.                 | Không có tự chủ; con người thực hiện toàn bộ việc đánh giá và lặp lại.                           |
| **Workflow**     | Các luồng mã được định sẵn, điều phối các bước xử lý nối tiếp hoặc phân nhánh.                   | Tự do trong phạm vi luồng cố định; xử lý các tác vụ có cấu trúc rõ ràng.                         |
| **Agent**        | Lựa chọn công cụ linh hoạt và tự lập kế hoạch trong phạm vi một lượt tương tác (turn).           | Tự chủ trong từng lượt; sử dụng phản hồi từ môi trường để điều chỉnh hành động.                  |
| **Loop**         | Chu kỳ liên tục: _Act -> Observe -> Evaluate -> Update State -> Decide -> Repeat/Stop/Escalate_. | Tự chủ liên tục; được điều khiển bởi trạng thái lưu trên đĩa và tiêu chuẩn đánh giá nghiêm ngặt. |

Sự chuyển dịch sang Loop Engineering đòi hỏi bạn phải đổi vai trò từ người trực tiếp gõ lệnh sang người thiết kế hệ thống kiểm soát. Việc này giúp hệ thống của bạn duy trì được năng lực tự kiểm định và tự sửa lỗi ngay cả khi không có con người can thiệp trực tiếp.

## 9 thành phần cấu trúc của một vòng lặp AI tin cậy

![9 thành phần kiến trúc cốt lõi của một vòng lặp AI tin cậy trong môi trường sản xuất](https://camnangai.com/articles/loop-engineering-la-gi/02-vn.webp)

Để xây dựng một vòng lặp AI vận hành ổn định trong môi trường sản xuất, bạn cần thiết lập đầy đủ 9 thành phần cấu trúc cốt lõi. Nhóm thành phần định hướng đầu tiên gồm có:

- **1. Mục tiêu (Goal)**: Định nghĩa dưới dạng trạng thái đo lường được thay vì một đầu việc mơ hồ. Chẳng hạn, thay vì giao nhiệm vụ "review PR này", bạn cần yêu cầu cụ thể: "kiểm tra mọi tệp bị thay đổi, chạy test suite, gán lỗi vào bằng chứng cụ thể và đưa ra khuyến nghị approve, request changes hoặc escalate".
- **2. Bối cảnh (Context)**: Cung cấp các quy tắc kiến trúc và hướng dẫn hiện hành thay vì nạp toàn bộ lịch sử trò chuyện nhiều năm vào cửa sổ ngữ cảnh (context window). Vòng lặp hiệu quả thường bắt đầu bằng bộ quy tắc chung của kho mã nguồn, sau đó chỉ truy xuất thêm tài liệu chuyên biệt khi thật sự cần.
- **3. Hành động (Actions)**: Chia nhỏ thành các bước di chuyển có thể truy vết (như đọc diff để so sánh mã cũ - mới, tìm kiếm trong kho mã nguồn, chạy bộ kiểm thử), tránh giao các lệnh thực thi quá rộng khiến bạn không thể debug khi xảy ra sự cố.

Nhóm thành phần thực thi và đánh giá bao gồm:

- **4. Công cụ (Tools)**: Cung cấp giao diện lập trình được khóa chặt phạm vi (như giao diện Agent-Computer Interfaces hoặc các máy chủ MCP - Model Context Protocol). Quyền hạn của công cụ phải khớp đúng với tác vụ: một loop chỉ review PR thì dứt khoát không được cấp quyền merge code.
- **5. Bộ đánh giá (Evals)**: Kết hợp giữa kiểm tra mã định tính (deterministic code checks), đối chiếu dữ liệu gốc và đánh giá bằng mô hình cho các tiêu chí phức tạp. Quy tắc ở đây là dùng mã máy tính cho các phép kiểm tra số học và định dạng, dùng dữ liệu gốc để kiểm tra tính thực tế, và chỉ dùng LLM cho các tiêu chí cần sự diễn giải.
- **6. Bộ nhớ / Trạng thái (Memory / State)**: Lưu trữ trạng thái cấu trúc trên ổ đĩa nằm ngoài context window của mô hình (như tệp `AGENTS.md`, bảng Linear hay các tệp JSON/YAML) để né hiện tượng trôi ngữ cảnh (context drift). Khi phiên làm việc bị xóa, bộ nhớ trên đĩa giúp loop tiếp tục công việc ở chu kỳ sau mà không bị mất dữ liệu.

Một cấu trúc tệp trạng thái bộ nhớ chuẩn trên đĩa có dạng:

```text
Pull request: #1842
Files changed: 7
Files inspected: 6
Missing inspection: auth/session.py
Tests run: unit, integration
Failed checks: 1
Risk level: high
Required next action: inspect permission changes
```

Nhóm thành phần an toàn và kiểm soát vận hành gồm có:

- **7. Rào chắn (Guardrails)**: Thiết lập ranh giới kiến trúc và phân quyền nghiêm ngặt, chẳng hạn như quyền truy cập chỉ đọc, chạy trong môi trường sandbox cô lập và cấm tuyệt đối việc sửa đổi hạ tầng sản xuất.
- **8. Leo thang (Escalation)**: Định nghĩa cơ chế bàn giao cho con người khi xuất hiện mâu thuẫn dữ liệu hoặc rủi ro cao. Loop phải gom đầy đủ thông tin xung đột, bằng chứng thu thập được và phương án quyết định cụ thể trước khi nhờ bạn phê duyệt.
- **9. Điều kiện dừng (Stopping Conditions)**: Quy định rõ ràng các điểm thoát cho hệ thống: khi hoàn thành mục tiêu, khi cạn kiệt ngân sách (token, chi phí hoặc thời gian), khi tiến trình bị đình trệ (stalled), khi công cụ gặp sự cố hoặc khi cần con người ra quyết định.

Mô hình ngôn ngữ suy cho cùng chỉ đảm nhận vai trò tạo văn bản và suy luận; chính hệ thống cấu trúc 9 thành phần xung quanh mới cung cấp bộ điều khiển hoàn chỉnh. Thiếu hụt bất kỳ mắt xích nào trong số này, vòng lặp của bạn sẽ rất dễ trượt sang trạng thái vận hành không kiểm soát.

## Cơ chế tự cải thiện: Mô hình Champion-Challenger và Eval-Driven Development

Cơ chế tự cải thiện trong Loop Engineering dựa trên quy trình thử nghiệm kiểm soát mang tên **Self-Improving Champion Loop**. Phiên bản prompt hoặc phần mẫu hiện tại đóng vai trò là Champion (nhà vô địch). Mỗi thay đổi bạn đề xuất sẽ tạo ra một Challenger (kẻ thách thức). Challenger chỉ được nâng cấp thành Champion mới nếu nó chứng minh được kết quả tốt hơn hẳn trên một tập dữ liệu kiểm thử nghiêm ngặt. Quy tắc tối quan trọng của quy trình này là _chỉ thay đổi một yếu tố mỗi vòng_ nhằm bảo toàn mối quan hệ nguyên nhân - kết quả.

![Quy trình tự cải thiện theo mô hình Champion-Challenger và phân tách tập dữ liệu Holdout](https://camnangai.com/articles/loop-engineering-la-gi/03-vn.webp)

Để bạn vận hành mô hình này mà không dính bẫy học vẹt (overfitting), tập dữ liệu phải được phân tách làm ba nhóm riêng biệt: _Improvement set_ (khoảng 25 trường hợp) dùng để phát hiện lỗi và đề xuất thay đổi; _Holdout set_ (khoảng 15 trường hợp) dùng để kiểm tra năng lực tổng quát hóa; và _Audit set_ (tập dữ liệu độc lập thứ ba) được giữ nguyên tuyệt đối trong môi trường sản xuất để nhận diện nguy cơ rò rỉ thông tin khi loop lặp lại nhiều lần trên Holdout set.

```text
Propose -> Test -> Compare -> Promote/Reject -> Log -> Repeat
```

Một bài học thực tế từ Ruben Dominguez và Shubham Saboo đã chứng minh tầm quan trọng của việc phân tách dữ liệu: Khi bắt đầu với prompt gốc (Champion) trên 15 trường hợp thuộc Holdout set, điểm số trung bình chỉ đạt 3,4/5 và có tới 10/15 câu trả lời vi phạm quy tắc vì tự ý hứa hẹn tính năng chưa cam kết. Ở vòng 2, việc bổ sung 3 ví dụ vào prompt đã giúp tăng điểm đánh giá trên Improvement set thêm 0,5 điểm. Tuy nhiên, khi đưa Challenger này ra kiểm tra trên Holdout set, điểm số lại tụt từ 3,8 xuống 3,6 do prompt bị học vẹt theo các trường hợp luyện tập. Challenger bị loại bỏ ngay lập tức. Đến vòng 4, loop thêm quy tắc trực tiếp: _"Nếu tính năng chưa nằm trên roadmap cam kết, chỉ ghi nhận nhu cầu và không đưa ra ngày phát hành dự kiến"_, giúp điểm Holdout tăng vọt từ 4,0 lên 4,4. Đến vòng 7, hệ thống đạt điểm 4,6 (vượt mục tiêu 4,5) và tự động dừng lại. Toàn bộ quá trình chạy hoàn toàn tự động trong 40 phút, ngốn đúng $2 tiền token, tạo ra phiên bản prompt khác 30% so với ban đầu nhưng có bằng chứng thực nghiệm rõ ràng.

Song song với việc phân tách dữ liệu, bạn cần ứng dụng các kỹ thuật đánh giá chuyên biệt. Theo Eugene Yan, đối với các tác vụ phân loại hoặc trích xuất, bạn nên áp dụng các chỉ số Precision, Recall, ROC-AUC, PR-AUC và độ phân kỳ Jensen-Shannon (JSD) để đo lường khả năng phân tách phân phối giữa các lớp. Với tác vụ tóm tắt hoặc kiểm tra tính thực tế, việc tinh chỉnh (fine-tune) mô hình suy luận ngôn ngữ tự nhiên (Natural Language Inference - NLI) cho kết quả tin cậy hơn nhiều. Cơ chế toán học của NLI eval diễn ra như sau: xem văn bản gốc là tiền đề (premise) và văn bản do AI tạo ra là giả thuyết (hypothesis). Mô hình NLI trả về logits cho 3 chiều `[contradiction, neutral, entailment]`. Để tính xác suất mâu thuẫn hoặc sai lệch thông tin (factual inconsistency), bạn bỏ qua chiều `neutral` (chỉ số 1), áp dụng hàm Softmax trên hai chiều `entailment` và `contradiction`, rồi lấy giá trị xác suất của `contradiction`:

```text
P(contradiction) = e^(z_contradiction) / (e^(z_contradiction) + e^(z_entailment))
```

Ngoài ra, việc áp dụng cơ chế học tăng cường bằng lời và tự phản hồi (Verbal Reinforcement Learning / Self-Feedback) như trong nghiên cứu _Reflexion_ (lưu trữ phản hồi bằng lời vào bộ nhớ ngắn hạn (episodic memory) mà không cần cập nhật trọng số mô hình) và _Self-Refine_ (mô hình đóng vai trò khởi tạo, phản hồi và tinh chỉnh) cho phép agent liên tục hoàn thiện kết quả đầu ra qua từng vòng lặp.

## Ba kiến trúc loop thực chiến: Builder-Critic, Saturation và Evaluator-Optimizer

Kiến trúc đầu tiên là **Builder-Critic** (mô hình phân tách Maker-Checker). Kiến trúc này tách biệt hoàn toàn giữa hai vai trò: một mô hình hoặc agent đóng vai trò tạo dựng (soạn thảo mã nguồn hoặc viết PRD, tức tài liệu đặc tả yêu cầu sản phẩm), trong khi Critic là một agent riêng biệt, sử dụng prompt khác hoặc mô hình có năng lực suy luận cao hơn để đóng vai trò tấn công, tìm kiếm lỗ hổng bảo mật, giả định sai và các trường hợp biên. Việc tách biệt người làm và người kiểm tra giúp bạn loại bỏ triệt để thiên vị tự chấm điểm (self-grading bias). Mọi phản biện từ Critic phải được Builder giải quyết dưới dạng _Fixed_ (đã sửa trong tài liệu hoặc mã nguồn) hoặc _Accepted Risk_ (chấp nhận rủi ro và ghi lại lý do). Trong các công cụ hiện đại, bạn có thể triển khai mô hình này qua các sub-agent định nghĩa trong thư mục `.codex/agents/` hoặc `.claude/agents/`.

![Ba kiến trúc vòng lặp AI thực chiến: Builder-Critic, Vòng lặp bão hòa và Evaluator-Optimizer](https://camnangai.com/articles/loop-engineering-la-gi/04-vn.webp)

Kiến trúc thứ hai là **Saturation** (vòng lặp bão hòa tri thức), chuyên dùng để bạn xử lý dữ liệu phi cấu trúc khối lượng lớn như văn bản phỏng vấn, tệp hỗ trợ khách hàng hay kết quả khảo sát. Dữ liệu được đưa vào theo từng đợt (chẳng hạn đợt 20 tệp). Sau mỗi đợt, hệ thống trích xuất thông tin, gom cụm (clustering) và đánh giá tiêu chí dừng gọi là bão hòa nghiên cứu (Research Saturation). Vòng lặp sẽ tự động dừng lại khi hai đợt xử lý liên tiếp không tạo ra thêm cụm tri thức mới hoặc không làm thay đổi đáng kể cấu trúc thông tin hiện có, với giới hạn chặn cứng thường là 10 đợt. Trạng thái bộ nhớ trên đĩa duy trì bản đồ các cụm tri thức, trích dẫn gốc và danh sách tệp đã xử lý.

Kiến trúc thứ ba là **Evaluator-Optimizer**, một mô hình do Anthropic tổng kết dựa trên quy trình phản hồi vòng kín. Trong cấu trúc này, mô hình đánh giá (Evaluator) chấm điểm và đưa ra phản hồi có cấu trúc về bản thảo do mô hình khởi tạo (Generator) tạo ra, giúp Generator sửa đổi bài viết ở chu kỳ tiếp theo.

```text
[Generator] -> (Draft) -> [Evaluator] -> (Feedback) -> [Generator]
```

Mô hình Evaluator-Optimizer đặc biệt hiệu quả khi tiêu chuẩn đánh giá của bạn khách quan và rõ ràng, đồng thời quá trình tinh chỉnh nhiều bước mang lại giá trị có thể đo lường được. Các kịch bản ứng dụng tiêu chuẩn bao gồm: dịch thuật văn học (nơi Evaluator bắt các sắc thái tinh vi mà bước dịch đầu tiên bỏ sót), các tác vụ tìm kiếm đa bước phức tạp (Evaluator quyết định xem thông tin đã đủ chưa hay cần tìm kiếm thêm), hoặc lập trình tự động dựa trên các bộ unit test định sẵn (vòng lặp chỉ nghỉ khi toàn bộ test suite chuyển sang màu xanh).

## 5 cái bẫy thất bại khi vận hành loop và giải pháp kiểm soát

Khi vận hành hệ thống loop thực tế, bạn sẽ đối mặt với 5 cái bẫy thất bại phổ biến. Nắm rõ nguyên nhân và giải pháp kiểm soát sẽ giúp bạn bảo vệ hệ thống khỏi các sự cố tốn kém:

- **Trôi lệch mục tiêu (Drift)**: Hiện tượng này xảy ra khi loop tối ưu hóa một chỉ số thay thế (proxy metric) thay vì kết quả thực tế. Điển hình là việc vòng lặp liên tục rút ngắn câu trả lời để vượt qua kiểm tra độ dài khiến kết quả trở nên vô dụng. _Giải pháp_: Bạn phải tái khẳng định mục tiêu cốt lõi ở mỗi vòng lặp, sử dụng bộ quy chuẩn đa chiều (multidimensional rubric) và trực tiếp kiểm tra hướng hành vi của mô hình thay vì chỉ nhìn vào điểm số.
- **Bộ đánh giá yếu (Weak Evals)**: Xuất hiện khi bộ đánh giá dễ bị đánh lừa hơn chính tác vụ cần thực hiện. Nếu bộ chấm điểm hời hợt, loop sẽ học cách "nịnh" bộ chấm điểm thay vì làm đúng việc. _Giải pháp_: Sử dụng các kiểm tra định tính bằng mã máy tính, yêu cầu mô hình trích dẫn bằng chứng cụ thể từ nguồn, kiểm thử bộ eval trên các trường hợp đúng/sai đã biết, và thực hiện kiểm tra mẫu thủ công định kỳ.
- **Chi phí bùng nổ (Runaway Cost)**: Sự nhân bản của các chu kỳ lặp, lượt đánh giá và các phiên bản Challenger bị từ chối có thể làm cạn kiệt ngân sách token của bạn trong thời gian ngắn. _Giải pháp_: Thiết lập giới hạn cứng về số vòng tối đa, thời gian chạy, số lượng token và chi phí trước khi kích hoạt; đồng thời sử dụng các mô hình nhỏ hơn hoặc mã máy tính cho các bước kiểm tra đơn giản.
- **Độ trễ cao (Latency)**: Các vòng lặp kéo dài từ 40 phút đến nhiều giờ sẽ làm gián đoạn luồng làm việc nếu bạn ngồi chờ kết quả. _Giải pháp_: Vận hành vòng lặp bất đồng bộ (asynchronously), ghi lại checkpoint có cấu trúc lên đĩa để có thể tiếp tục mạch chạy (resumable runs), và chỉ gửi thông báo cho bạn qua Slack hoặc Email khi hoàn thành, thất bại hoặc cần leo thang.
- **Lặp lại vô tận (Endless Retries)**: Xảy ra khi bạn thiết lập điều kiện dừng dạng "tiếp tục cho đến khi đạt kết quả hoàn hảo", trong khi sự hoàn hảo là điều không thể đạt được trên thực tế khi gặp các ca khó.

```text
Lỗi: "Tiếp tục cho đến khi đạt điểm 10/10" -> Lặp vô tận khi gặp ca khó
Khắc phục: "Đạt điểm 8/10 OR tối đa 3 vòng không cải thiện -> Xuất kết quả tốt nhất + Báo cáo lỗi"
```

_Giải pháp cho Endless Retries_: Bắt buộc bạn phải ghép nối mọi mục tiêu chất lượng với quy tắc đình trệ (stall rules), chẳng hạn dừng lại nếu sau 3 vòng liên tiếp điểm số không tăng, kèm theo giới hạn ngân sách rõ ràng. Khi dừng do đình trệ, vòng lặp phải xuất ra ứng viên tốt nhất hiện tại kèm theo giải thích chi tiết về các lỗi chưa thể khắc phục để bạn can thiệp.

## Thang đo tự chủ: Cách một hệ thống loop từng bước giành quyền tự quyết

Để bạn đưa một vòng lặp AI vào vận hành sản xuất an toàn, hệ thống phải tiến triển qua 4 cấp độ tự chủ (The Autonomy Ladder):

![Thang đo 4 cấp độ tự chủ: Chạy ngầm, Đề xuất, Phê duyệt và Tự chủ có ranh giới](https://camnangai.com/articles/loop-engineering-la-gi/05-vn.webp)

- **Cấp độ 1: Chạy ngầm (Shadow)**. Vòng lặp vận hành trên dữ liệu thực tế nhưng không thực thi bất kỳ hành động bên ngoài nào. Mọi đầu ra được ghi log và so sánh trực tiếp với quyết định thực tế của con người để đánh giá độ chính xác.
- **Cấp độ 2: Đề xuất (Suggest)**. Vòng lặp tạo ra các khuyến nghị cho bạn. Hệ thống tự động theo dõi và ghi nhận tỷ lệ bạn chấp nhận, chỉnh sửa hoặc từ chối các đề xuất đó.
- **Cấp độ 3: Phê duyệt (Approve)**. Vòng lặp chuẩn bị sẵn các hành động thực tế (như mở Pull Request, viết bản thảo phản hồi khách hàng), nhưng quá trình thực thi đòi hỏi bạn phải kiểm tra bằng chứng và bấm nút phê duyệt.
- **Cấp độ 4: Tự chủ có ranh giới (Bounded Autonomy)**. Vòng lặp tự động thực thi hành động độc lập trong một phạm vi ranh giới được tài liệu hóa nghiêm ngặt (chẳng hạn: tự động phản hồi 6 loại yêu cầu rủi ro thấp, sử dụng nguồn dữ liệu đã duyệt, thỏa mãn toàn bộ 7 bước kiểm tra, nằm trong giới hạn chi phí và khối lượng yêu cầu hàng ngày).

Nguyên tắc cốt lõi khi bạn cấp quyền tự chủ cho loop là phải dựa trên bằng chứng có thể quan sát được (observable evidence) chứ không dựa vào độ tự tin do mô hình tự báo cáo. Bằng chứng này bao gồm: các bộ unit test đã vượt qua, tài liệu nguồn được truy xuất chính xác, các bản ghi nội bộ khớp hoàn toàn, và tác vụ thuộc đúng danh mục đã được cấp phép.

Ngay cả khi hệ thống của bạn đã đạt Cấp độ 4, tôi khuyên bạn vẫn phải duy trì việc kiểm tra và lấy mẫu ngẫu nhiên (sampling/auditing). Những thay đổi về chính sách nội bộ, định dạng dữ liệu đầu vào hoặc sự trôi lệch nhẹ của prompt theo thời gian có thể làm suy giảm chất lượng hệ thống mà các bộ chỉ số dashboard không phản ánh kịp thời.

## Khung thiết kế loop: Khi nào nên (và không nên) biến tác vụ thành vòng lặp?

Trước khi bắt tay vào viết mã để biến một tác vụ thành vòng lặp tự động, bạn cần trả lời 3 câu hỏi kiểm định bắt buộc:

- **Có thể kiểm tra kết quả khách quan không?** Vòng lặp mã nguồn có unit test, vòng lặp nghiên cứu có kiểm tra bão hòa tri thức. Nếu bạn không thể giải thích thuật toán hoặc tiêu chí khách quan để đánh giá chất lượng công việc, tuyệt đối không tự động hóa nó thành loop.
- **Hậu quả ra sao nếu hệ thống làm sai?** Các tác vụ ảnh hưởng đến tài chính, cam kết pháp lý, hoàn tiền cho khách hàng hoặc di chuyển cơ sở dữ liệu hạ tầng đòi hỏi rào chắn phê duyệt của con người (human gate) cực kỳ nghiêm ngặt.
- **Có thể xác định điều kiện dừng trước khi chạy không?** Bạn phải định nghĩa rõ ngưỡng thành công, ngân sách token, giới hạn đình trệ và điều kiện thất bại trước khi kích hoạt tiến trình.

Để chuẩn hóa quy trình triển khai, bạn phải hoàn thành đặc tả đầy đủ 12 trường dữ liệu trên một trang giấy (The One-Page Loop Spec) trước khi viết mã:

```text
TASK: Tác vụ lặp lại cụ thể cần thực hiện
TRIGGER: Sự kiện hoặc lịch trình kích hoạt loop (Cron, Hook, Webhook)
GOAL: Trạng thái đo lường được xác định là thành công
CONTEXT: Tài liệu, quy tắc, hướng dẫn và lịch sử cần thiết
ACTIONS: Các bước di chuyển nhỏ hệ thống được phép thực hiện
TOOLS: Hệ thống và API được truy cập (kèm phạm vi phân quyền)
EVALUATOR: Cơ chế chấm điểm (Code, So sánh nguồn, LLM, hay Con người)
MEMORY: Cấu trúc dữ liệu lưu trạng thái giữa các vòng lặp
GUARDRAILS: Các hành động tuyệt đối cấm thực hiện
ESCALATION: Điều kiện phải chuyển giao cho con người và bằng chứng đi kèm
STOPPING CONDITIONS: Giới hạn cụ thể cho Success / Budget / Stall / Escalation / Failure
LOG: Dữ liệu đầu vào, hành động, bằng chứng, điểm số, chi phí và quyết định cần ghi lại
LAUNCH STAGE: [ ] Shadow  [ ] Suggest  [ ] Approve  [ ] Bounded Autonomy
```

Xây dựng các vòng lặp tự động giúp bạn tăng tối đa điểm tựa đòn bẩy (leverage) khi làm việc với AI. Tuy nhiên, bạn cần tránh bẫy "đầu hàng nhận thức", tức là dựng loop cốt để trốn tránh việc đọc hiểu hệ thống hoặc không nắm vững bản chất vấn đề mã nguồn. Việc tự động hóa chỉ phát huy hiệu quả khi dựa trên năng lực chuyên môn sâu sắc của người thiết kế.

Đừng dựng loop chỉ để trốn việc đọc mã nguồn hay để nhắm mắt làm ngơ trước những vấn đề kiến trúc mà bạn chưa hiểu rõ. Hãy thiết kế các vòng lặp tự động để mở rộng quy mô công việc, nhưng bạn phải luôn duy trì quyền kiểm soát kỹ thuật và quy trình đánh giá mã nguồn nghiêm ngặt để giữ vững chất lượng hệ thống dài hạn.

## Tài liệu tham khảo

- [Loop Engineering: Build AI Systems That Improve Their Work — Addy Osmani](https://www.the-ai-corner.com/p/loop-engineering-masterclass-self-improving-ai-systems-2026)
- [Loop Engineering: The Next Frontier in AI Coding Agents — Addy Osmani](https://addyosmani.com/blog/loop-engineering/)
- [Building Effective Agents — Anthropic Research](https://www.anthropic.com/research/building-effective-agents)
- [Reflection Agents — LangChain](https://blog.langchain.dev/reflection-agents/)
- [Reflexion: Language Agents with Verbal Reinforcement Learning — Shinn et al.](https://arxiv.org/abs/2303.11366)
- [Self-Refine: Iterative Refinement with Self-Feedback — Madaan et al.](https://arxiv.org/abs/2303.17651)
- [Task-Specific LLM Evals that Do & Don't Work — Eugene Yan](https://eugeneyan.com/writing/evals/)