# Loop engineering là gì: xây AI agent tốt hơn quanh một vòng lặp

[Martin Keen](https://homus.dev/speakers/martin-keen) · [IBM Technology](https://homus.dev/orgs/ibm-technology)

> Loop engineering: vòng goal, action, observe, adjust cùng trigger, context, skill, spine, tool, sub-agent, và bốn pitfall cần con người trong vòng lặp.

Topics: Agents, Context Engineering, Coding Agents, Workflow

Canonical: https://homus.dev/talks/what-is-loop-engineering-building-better-ai-agents

## 1. Từ prompt engineering đến loop engineering

Martin Keen, Master Inventor ở IBM, mở đầu bài giảng lightboard bằng một định nghĩa: loop engineering là một thuật ngữ gắn với việc làm việc cùng AI agent, và nó giống như một phiên bản mới hơn, "ngầu" hơn của prompt engineering.

![Martin Keen đứng trước tấm lightboard đen, phía trên ghi LOOP ENGINEERING](https://homus.dev/photos/DQBqh6gcx7U-0003.jpg)

Martin Keen (Master Inventor, IBM) trước tấm lightboard trống, chỉ mới có tiêu đề "Loop Engineering" ở trên cùng.

Anh nhắc lại prompt engineering là gì. Với prompt engineering, mọi thứ xoay quanh chuyện viết: bạn viết ra một prompt hoàn hảo, tối thượng, rồi gửi prompt đó tới một LLM. Model trả về một response, và bạn lại phải viết tiếp prompt hoàn hảo kế tiếp, rồi cứ thế. Ở góc dưới bên trái tấm bảng, anh vẽ đúng hình ảnh này: một ô PROMPT, một ô LLM, mũi tên đi qua đi lại giữa hai ô, với nhãn "Prompt Engineering".

Loop engineering thì khác: đó là việc thiết kế một hệ thống làm toàn bộ phần việc viết prompt đó thay cho bạn. Loop engineering lấy một prompt và gửi nó tới một AI agent. Sau đó loop engineering kiểm tra kết quả agent làm ra và prompt nó lần nữa. Cứ qua lại, qua lại như thế, lặp cho tới khi xong. Ở góc trên bên trái, anh vẽ ô PROMPT nối với ô AI AGENT bằng hai mũi tên lên xuống.

![Lightboard với hai sơ đồ: Prompt nối AI Agent ở trên, Prompt nối LLM dưới nhãn Prompt Engineering ở dưới](https://homus.dev/photos/DQBqh6gcx7U-0105.jpg)

Hai sơ đồ đặt cạnh nhau: ở dưới là prompt engineering (người viết prompt gửi LLM rồi nhận lại), ở trên là loop engineering (prompt và AI agent đi qua đi lại trong một vòng tự động).

Điểm khác biệt nằm ở chỗ: chúng ta không phải tự tay "engineer" từng prompt. Đó là việc của loop engineering. Sự can thiệp của con người là tối thiểu (minimal). Martin nói thêm rằng anh sẽ quay lại chữ "minimal" này một chút sau.

## 2. Giao việc cho agent: làm cho unit test của checkout hết đỏ

Để có ví dụ cụ thể, Martin giao cho agent một việc. Giả sử có một checkout service (dịch vụ thanh toán giỏ hàng) với cả đống unit test đang fail, và nhiệm vụ là làm cho những unit test đang fail đó hết fail. Anh vẽ một chiếc xe đẩy hàng ở góc trên bên phải bảng để đại diện cho checkout service này.

Để làm việc đó, chúng ta sẽ dùng một loop. Và loop bắt đầu bằng một goal. Trong trường hợp này, goal là: làm cho các unit test của checkout pass. Anh vẽ một vòng tròn màu tím ghi chữ GOAL ngay dưới chiếc xe đẩy.

![Lightboard: chiếc xe đẩy hàng ở góc phải trên, bên dưới là vòng tròn tím ghi GOAL](https://homus.dev/photos/DQBqh6gcx7U-0136.jpg)

Ví dụ checkout service được vẽ thành chiếc xe đẩy hàng, và chặng đầu của vòng lặp là GOAL: làm cho unit test của checkout pass.

## 3. Bốn chặng của vòng lặp: goal, action, observe, adjust

Từ vòng GOAL, Martin vẽ tiếp từng chặng theo chiều kim đồng hồ.

**Action.** AI agent thực hiện một hành động. Đó là chặng kế tiếp của vòng lặp, và với một coding agent thì hành động có thể là mở một file hay sửa một đoạn code.

**Observe.** Chặng kế tiếp là agent quan sát output, tức là xem điều gì xảy ra sau hành động vừa rồi.

**Adjust.** Điểm dừng cuối cùng trên vòng là điều chỉnh dựa trên những gì quan sát được. Nếu test chuyển sang xanh, "yay", test đó xong, agent chuyển sang test đang fail kế tiếp. Còn nếu test vẫn đỏ, agent sẽ thử một cách sửa khác.

Rồi vòng lặp quay về goal: xong chưa? Chưa. Được, chạy tiếp. Và cứ thế chúng ta đi vòng quanh loop.

Bốn chặng Martin vẽ thành vòng tròn: goal, action, observe, adjust, rồi quay về goal để hỏi "đã xong chưa".

## 4. Một goal tốt phải kiểm chứng được

Vì vậy, việc đặt ra một goal tốt khá quan trọng. Goal sẽ được đánh giá lại mỗi lần agent đi hết một vòng, và chính nó quyết định agent có chạy tiếp hay không.

Martin đưa một ví dụ goal tồi: "make the checkout faster" (làm cho checkout nhanh hơn). Nó tồi theo đúng kiểu "be happier" (sống vui hơn) là một quyết tâm năm mới tồi. Cả hai đều không có phép thử nào đo được. Hệ quả là agent có thể chạy vòng vòng mãi mãi, hoặc có thể dừng ngay sau một lượt rồi tuyên bố thắng lợi.

Ngược lại, goal "stop when every unit test in the checkout suite passes" (dừng khi mọi unit test trong bộ test checkout đều pass) là kiểm chứng được, nên agent sẽ biết chắc chắn khi nào goal đã đạt. Martin viết nguyên câu này lên bảng, trong ngoặc kép, ngay trên vòng GOAL.

```
Stop when every unit test in the checkout suite passes
```

![Vòng lặp Goal, Action, Observe, Adjust, phía trên là câu Stop when every unit test in the checkout suite passes](https://homus.dev/photos/DQBqh6gcx7U-0303.jpg)

Vòng lặp bốn chặng đã vẽ xong, và phía trên là goal kiểm chứng được mà Martin chọn: dừng khi mọi unit test trong bộ test checkout đều pass.

Tóm lại, một goal tốt thì cụ thể và có điều kiện kết thúc, tức một stopping condition. Vậy đó là loop. Về cơ bản chỉ là bốn chặng này.

## 5. Vì sao cần cả một "engineering": thứ gì kích hoạt vòng lặp

Martin tự trêu: chẳng có gì nhiều nhỉ? Có vẻ đâu cần cả một ngành engineering đặt tên theo nó. Vậy tại sao lại cần? Câu trả lời của anh: loop engineering thực chất là những gì được xây quanh vòng lặp này. Và anh bắt đầu vẽ thêm các thành phần xung quanh.

Trước hết, phải có thứ gì đó khởi động vòng lặp. Một thứ có thể khởi động nó là một **schedule** (lịch chạy), một thứ khác có thể khởi động nó gọi là **hook**. Trên bảng, anh vẽ biểu tượng tờ lịch ghi SCHEDULE và một dấu tick ghi HOOK, cả hai có mũi tên chỉ vào vòng GOAL.

- **Schedule** là thứ đơn giản, kiểu "chạy checkout loop mỗi đêm". Nhiều team làm việc này chỉ bằng một cron job bình thường.

- **Hook** thì event-driven (chạy theo sự kiện), nghĩa là hook được gọi khi một điều cụ thể xảy ra, ví dụ một file thay đổi hay một pull request được mở. Developer chủ yếu dùng hook cho security và chất lượng, chẳng hạn để bắt buộc tuân theo các policy.

![Lightboard: Schedule và Hook chỉ vào Goal, ô Context ở góc trái dưới](https://homus.dev/photos/DQBqh6gcx7U-0436.jpg)

Hai cách kích hoạt vòng lặp được vẽ phía trên GOAL: SCHEDULE (tờ lịch) và HOOK (dấu tick). Ở góc trái dưới bắt đầu xuất hiện ô CONTEXT cho phần kế tiếp.

## 6. Context engineering: compact và skill

Mỗi lần đi một vòng qua agentic loop, hệ thống sẽ sinh ra một thứ gì đó. Nó sinh ra context. Output của test là context, nội dung file cũng là context. Và context có thể chất đống rất nhanh, khiến agent khó tập trung sự chú ý vào những thứ quan trọng. Martin vẽ một ô lớn ghi CONTEXT ở góc trái dưới bảng.

Vì vậy có thêm một ngành engineering nữa: **context engineering**, tức là chọn những phần nào thực sự được vòng lặp nhìn thấy. Điều đó có thể nghĩa là ta cần làm một số thao tác trên context này:

- **Compact** (nén context): một việc ta có thể làm.

- Hoặc dùng **progressive disclosure** (hé lộ dần) của agent **skill**. Skill chứa hướng dẫn cách làm một việc gì đó, cách một việc lặp đi lặp lại cụ thể diễn ra.

![Lightboard: chữ Context Engineering, hai mũi tên Compact và Skill chỉ vào ô Context, giữa vòng lặp có một ký hiệu đường thẳng đứng nhiều gạch ngang](https://homus.dev/photos/DQBqh6gcx7U-0523.jpg)

Nhãn "Context Engineering" với hai mũi tên COMPACT và SKILL chỉ vào ô CONTEXT. Ở giữa vòng lặp đã có thêm một ký hiệu như xương sống: phần spine của mục kế tiếp.

Cơ chế progressive disclosure của Agent Skills được Anthropic mô tả trong [tài liệu Agent Skills](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview): agent chỉ nạp phần mô tả ngắn của skill trước, rồi mới nạp hướng dẫn đầy đủ khi cần.

## 7. Spine: trạng thái bền vững ở giữa vòng lặp

Bên trong vòng lặp, Martin vẽ một thứ mà anh gọi là **spine** (xương sống): một đường thẳng đứng với các gạch ngang, đặt ngay giữa bốn chặng. Đây thực chất là persistent state (trạng thái bền vững). Có thể đó là một vài file markdown, nơi agent ghi lại nó đã làm gì và việc đó có hiệu quả không.

Thông tin lưu trong spine có thể chỉ dẫn cho những lần lặp sau của vòng: nên làm gì, cái gì đã hiệu quả cho tới lúc đó, và có thể cả cái gì chưa hiệu quả.

Spine giữ lại ký ức giữa các vòng: mỗi lượt ghi lại việc đã làm và kết quả, lượt sau đọc để biết nên đi tiếp thế nào.

## 8. Tool cho chặng action: MCP và API

Ở chặng action, agent có thể cần gọi ra các tài nguyên bên ngoài. Nó làm việc đó thông qua **tool access** (quyền dùng tool). Martin vẽ biểu tượng cờ lê ghi TOOL cạnh vòng ACTION, với hai nhánh MCP và APIs.

Việc này có thể dùng các chuẩn như MCP, tức [Model Context Protocol](https://modelcontextprotocol.io/introduction), hoặc agent có thể gọi tool trực tiếp qua API (tool calling). Agent dùng tool để chạy code, để truy cập file system, để chạy lệnh trong terminal, để query database, đủ thứ kiểu như vậy. Đó là action.

![Lightboard: biểu tượng cờ lê ghi Tool cạnh vòng Action, hai nhánh MCP và APIs](https://homus.dev/photos/DQBqh6gcx7U-0608.jpg)

TOOL được gắn vào chặng ACTION, tách thành hai nhánh: MCP và APIs.

## 9. Sub-agent ở chặng observe, và toàn cảnh hệ thống

Ở chặng observe, thay vì để chính agent đã viết code tự kiểm code đó, một loop engineering tốt sẽ mang vào một agent thứ hai. Ta có thể coi agent thứ hai này là một **sub-agent**. Nó vừa đóng vai một người kiểm tra (checker), vừa là một đồng nghiệp để giao bớt việc.

Sub-agent có instruction riêng và context riêng của nó, và có thể chạy bằng một AI model khác với AI agent chính, trước khi gửi kết quả của nó trở lại. Trên bảng, Martin vẽ một ô SUBAGENT dưới vòng OBSERVE, với hai mũi tên đi xuống và quay lên.

![Toàn bộ sơ đồ loop engineering: Schedule, Hook, Goal, Action, Tool với MCP và APIs, Observe với Subagent, Adjust, spine ở giữa, Context Engineering với Compact và Skill](https://homus.dev/photos/DQBqh6gcx7U-0713.jpg)

Trigger (schedule, hook) ở trên, context engineering (compact, skill) ở trái, tool (MCP, APIs) ở phải, sub-agent ở dưới chặng observe, và spine ở giữa vòng lặp.

Martin tổng kết lại toàn cảnh. Vậy đó là loop:

- Có một **trigger** để khởi động vòng lặp.

- Có **context và skill** để nạp thông tin cho nó.

- Có một **spine** để nhớ những gì đã xảy ra.

- Có **tool** để nó hành động trên các task.

- Và có **sub-agent** để kiểm chứng kết quả.

Còn lại một câu hỏi: con người làm gì trong lúc toàn bộ hệ thống này cứ lặp đi lặp lại?

## 10. Quay lại chữ "minimal": con người vẫn phải ở trong vòng lặp

Martin chuyển sang một bảng mới và viết lên góc trái "MINIMAL HUMAN INVOLVEMENT". Anh nhắc lại: anh đã nói loop engineering cần sự tham gia tối thiểu của con người so với prompt engineering, vì agent tự viết prompt cho chính nó thay vì để một người gửi từng prompt bằng tay.

Nhưng kể cả một vòng lặp được xây tốt, có checker, có sub-agent, có spine và đủ mọi thứ còn lại, nó vẫn cần con người tham gia. Cách tiếp cận human in the loop (có con người trong vòng lặp) giúp tránh những cái bẫy nguy hiểm nhất có thể xảy ra với việc sinh code tự động.

Những cái bẫy nào? Martin đưa ra bốn cái, và viết tiêu đề PITFALLS ở bên phải bảng.

## 11. Pitfall 1 và 2: unverified code và comprehension debt

**Unverified code (code chưa được kiểm chứng).** Cái bẫy thứ nhất bắt đầu từ một sự thật đơn giản: một sub-agent làm checker thì vẫn chỉ là một agent. Developer là con người mới là người chịu trách nhiệm sau cùng cho toàn bộ code được ship. Và điều đó có nghĩa là một người thật phải đọc và kiểm chứng code đó.

![Lightboard: Minimal Human Involvement bên trái, Pitfalls bên phải với Unverified Code và Comprehension Debt](https://homus.dev/photos/DQBqh6gcx7U-0843.jpg)

Hai pitfall đầu được viết dưới tiêu đề PITFALLS: UNVERIFIED CODE (biểu tượng thẻ code) và COMPREHENSION DEBT (biểu tượng bộ não).

**Comprehension debt (nợ hiểu biết).** Khoảng cách giữa tổng lượng code trong một hệ thống và mức độ con người hiểu được nó được gọi là comprehension debt. Khi agent viết nhiều code hơn và con người kiểm ít đi, comprehension debt sẽ cứ tăng lên. Và nó có thể tích tụ khá nhanh, vì agent viết rất nhiều code.

Nếu không được xử lý, comprehension debt có thể thành một vấn đề lớn khi developer phải xử lý một sự cố production khẩn cấp, hoặc khi con người cần thiết kế kiến trúc cho một đợt migration.

Comprehension debt theo định nghĩa của Martin: khoảng cách giữa tổng lượng code và mức con người hiểu nó, nới rộng nhanh khi agent viết nhiều hơn.

## 12. Pitfall 3: intent debt và chuyện mã giảm giá

Martin nói còn một loại nợ khác cũng đặt dưới mục pitfall: **intent debt** (nợ ý định). Một agent có thể đọc được hệ thống làm gì, nhưng hiểu ra vì sao hệ thống làm như vậy thì khó hơn một chút, trừ khi điều đó đã được viết ra ở đâu đó, chẳng hạn trong một file [AGENTS.md](https://agents.md/).

Không có nó, agent có thể tạo ra một thay đổi đúng về mặt kỹ thuật nhưng lại đi ngược với mục tiêu của project.

Anh quay lại ví dụ checkout loop. Giả sử agent sửa một test đang fail bằng cách nới lỏng phần validation cho mã giảm giá (discount code). Đó là một cách sửa hoàn toàn ổn nếu chỉ xét theo các test, nhưng là một cách sửa hoàn toàn tệ nếu xét theo lợi nhuận của doanh nghiệp.

Ví dụ intent debt trong checkout loop: một bản sửa làm test pass nhưng đi ngược lợi ích kinh doanh, vì "tại sao" chưa được viết ra cho agent đọc.

Vì vậy, việc của con người ở đây là viết ý định (intent) ra, giữ nó luôn cập nhật, và giữ nó ở chỗ AI agent nhìn thấy được.

## 13. Pitfall 4: cognitive surrender

Cái bẫy thứ tư Martin muốn nhắc tới có cái tên nghe khá nặng nề: **cognitive surrender** (đầu hàng về nhận thức). "Yeah, chúng ta chắc chắn không muốn điều đó", anh nói, nhưng nó lại rất dễ xảy ra.

Việc giao bớt công việc cho máy có thể dẫn tới cognitive surrender, khi một người cứ thế chấp nhận mù quáng bất cứ thứ gì đi ra từ vòng lặp. Kiểu: "AI làm thì chắc là đúng rồi."

![Lightboard: danh sách bốn pitfall Unverified Code, Comprehension Debt, Intent Debt, Cognitive Surrender](https://homus.dev/photos/DQBqh6gcx7U-0952.jpg)

Đủ bốn pitfall: UNVERIFIED CODE, COMPREHENSION DEBT, INTENT DEBT (biểu tượng bóng đèn) và COGNITIVE SURRENDER (biểu tượng lá cờ trắng đầu hàng).

Khi điều đó xảy ra, comprehension debt cũng sẽ tăng lên, vì lúc đó chẳng còn ai thậm chí cố gắng hiểu output do AI sinh ra nữa.

## 14. Ba việc của con người trong loop engineering

Vậy hoá ra "sự can thiệp tối thiểu của con người" lại là một lượng can thiệp khá cụ thể. Martin vẽ một khuôn mặt đeo kính ở góc trái dưới bảng, với các mũi tên chỉ ra các việc con người phải làm:

- **Viết goal** kèm theo stopping condition (điều kiện dừng).

- **Viết intent** ra, ở chỗ agent có thể tìm thấy.

- **Đọc output** mà agent tạo ra.

![Lightboard: khuôn mặt người đeo kính với mũi tên Writes the Goal và Writes Intent, bên phải là danh sách bốn pitfall](https://homus.dev/photos/DQBqh6gcx7U-1023.jpg)

Martin đang vẽ các việc của con người dưới khuôn mặt đeo kính: WRITES THE GOAL và WRITES INTENT đã có trên bảng, mũi tên thứ ba dành cho việc đọc output của agent.

Kết luận của Martin: loop engineering hoạt động tốt nhất khi có một con người ở trong vòng lặp đó. Anh hỏi người xem có đang tự xây agentic loop trong công việc của mình không, và mời mọi người chia sẻ ở phần bình luận.

## Nguồn và liên kết

- Tên gốc: What Is Loop Engineering? Building Better AI Agents
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=DQBqh6gcx7U](https://www.youtube.com/watch?v=DQBqh6gcx7U)

- Kênh YouTube IBM Technology (Martin Keen): [youtube.com/channel/UCKWaEZ-_VweaEx1j62do_vQ](https://www.youtube.com/channel/UCKWaEZ-_VweaEx1j62do_vQ)

- Bài giải thích "What Is Loop Engineering?" của IBM, được dẫn trong phần mô tả video: [ibm.com/think/topics/loop-engineering](https://www.ibm.com/think/topics/loop-engineering)

- Model Context Protocol (MCP), chuẩn mở để agent kết nối tool và nguồn dữ liệu: [modelcontextprotocol.io](https://modelcontextprotocol.io/introduction)

- AGENTS.md, định dạng file hướng dẫn cho coding agent trong một repo: [agents.md](https://agents.md/)

- Tài liệu Agent Skills của Anthropic, phần progressive disclosure: [platform.claude.com/docs/en/agents-and-tools/agent-skills/overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview)

Nguồn: https://homus.dev/talks/what-is-loop-engineering-building-better-ai-agents · cập nhật 2026-10-19