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

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.

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.

Đ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.

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.

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

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.

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.

Cơ chế progressive disclosure của Agent Skills được Anthropic mô tả trong tài liệu Agent Skills: 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ả.

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, 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.

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.

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 đó.

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.

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.

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ì 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."

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:

1. Viết goal kèm theo stopping condition (điều kiện dừng).
2. Viết intent ra, ở chỗ agent có thể tìm thấy.
3. Đọc output mà agent tạo ra.

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.