Từ Prompting Agents đến Loop Engineering

Một quan điểm đang lan truyền trong giới lập trình AI: hãy ngừng việc tự tay nhắc lệnh cho các coding agent của bạn và bắt đầu thiết kế các vòng lặp để chúng làm việc đó thay bạn. Cũng như mọi thứ mới mẻ, điều này thường được nhắc lại nhiều nhưng ít khi được giải thích. Đây là phiên bản thực tế: vòng lặp agent là gì, tại sao nó quan trọng, và nó trông như thế nào trong môi trường sản xuất.

Bên dưới là một số suy nghĩ của tôi (được viết với sự hỗ trợ của Claude) từ các thí nghiệm, nghiên cứu và cuộc trò chuyện với một số học viên, nhà sáng lập kỹ thuật, kỹ sư AI và startup của chúng tôi.

Bạn cũng có thể xem buổi trực tiếp gần đây của chúng tôi về "Autonomous Long-Running Coding Agents" như một điểm khởi đầu tốt cho tất cả những điều này.

Nguồn gốc của quan điểm

"Bạn không nên tự tay nhắc lệnh cho coding agent nữa. Bạn nên thiết kế các vòng lặp để nhắc lệnh cho agent."Peter Steinberger (

@steipete ), ngày 7 tháng 6 năm 2026. 2,2 triệu lượt xem.

Tweet gốc

Boris Cherny, người tạo ra Claude Code, cũng đưa ra quan điểm tương tự từ một góc nhìn khác.

"Tôi không còn nhắc lệnh cho Claude nữa. Tôi có các vòng lặp đang chạy. Chính chúng là những thứ đang nhắc lệnh cho Claude và tìm ra việc cần làm. Công việc của tôi là viết các vòng lặp."Boris Cherny (

@bcherny ).

Tweet gốc

Vấn đề không phải là kỹ thuật prompt engineering đã chết. Với loop engineering, công việc được nâng lên một tầm cao mới, từ viết mã sang viết hệ thống có thể tự viết mã. Các nhà phát triển đi xa nhất trên con đường này báo cáo về những tháng mà họ đã gửi hàng trăm PR mà không cần mở IDE, với mọi dòng lệnh đều do agent viết.

Vòng lặp thực sự là gì

Một vòng lặp là một chương trình nhỏ bạn viết để thực hiện bốn việc:

• nhắc lệnh cho coding agent thay bạn,
• đọc những gì nó tạo ra,
• quyết định xem nó đã hoàn thành chưa,
• và nếu chưa, nhắc lại lệnh với lỗi hoặc bước tiếp theo.

Bạn không còn ngồi trong vòng lặp để gõ lệnh nữa; bạn viết vòng lặp, và mô hình trở thành một chương trình con mà nó gọi đến.

Hình thức luôn giống nhau: đặt mục tiêu, hành động, kiểm tra, phản hồi lỗi, và lặp lại cho đến khi kiểm tra đạt hoặc vòng lặp tự dừng lại.

"Vòng lặp" có nghĩa là ít nhất năm thứ

Phần lớn sự bất đồng đến từ việc mọi người dùng một từ để chỉ năm ý tưởng khác nhau. Đây là sự phát triển, từ cũ nhất đến mới nhất.

• ReAct (2022). Mô hình nghiên cứu ban đầu: suy luận, hành động, quan sát, lặp lại.
• AutoGPT (2023). Một vòng lặp mục tiêu tự nhắc lệnh, nổi tiếng vì không biết khi nào nên dừng.
• ralph loop. Một thiết lập lại ngữ cảnh có chủ đích giữa các lần lặp để agent không bị ngập trong lịch sử của chính nó.
• /loop và /goal. Nhịp độ và điều kiện hoàn thành được tích hợp sẵn trong agent, mang trạng thái qua các lượt.
• orchestration. Một tác giả phân nhánh nhiều agent để đọc GitHub, Slack và chat của bạn, và quyết định xây dựng gì tiếp theo.

Các phần bạn thực sự lắp ráp

Sự phát triển này giải thích những gì mọi người muốn nói khi nói về vòng lặp; còn đây là những gì một vòng lặp được xây dựng từ. Sáu phần tương tự luôn xuất hiện và hầu hết hiện nay đã được tích hợp sẵn trong các công cụ lập trình thay vì các tập lệnh tùy chỉnh mà bạn tự bảo trì.

• Một trình kích hoạt. Thứ gì đó khởi động vòng lặp mà bạn không cần nhấn nút: một lịch trình, một webhook, một thay đổi file, hoặc một label được gắn vào PR. Đây là điều phân biệt một vòng lặp thực sự với một lần chạy đơn lẻ mà bạn lặp lại bằng tay.
• Sự cô lập. Một bản sao riêng tư cho mỗi agent, thường là một git worktree, để hai agent chạy cùng lúc không thể ghi đè file của nhau. Khi bạn chạy nhiều hơn một, điều này không còn là tùy chọn.
• Ngữ cảnh được ghi lại. Các quy ước, bước build và quy tắc cụ thể của dự án được lưu ở nơi agent có thể đọc được trong mỗi lần chạy. Bỏ qua bước này, vòng lặp sẽ tự suy diễn lại dự án của bạn từ đầu mỗi lần và đoán mò những chỗ thiếu sót.
• Kết nối với công cụ của bạn. Các bộ kết nối đến trình theo dõi issue, CI, cơ sở dữ liệu và chat, để vòng lặp có thể mở PR, liên kết ticket và đăng kết quả thay vì in ra một bản vá và chờ bạn tự xử lý phần còn lại.
• Một agent thứ hai kiểm tra. Một worker riêng biệt đánh giá đầu ra, tách biệt với agent đã tạo ra nó, bởi vì một model tự đánh giá công việc của chính nó thường bỏ qua hầu hết mọi thứ.
• Trạng thái trên đĩa. Một file markdown, một bảng hoặc một hàng đợi: bất cứ thứ gì nằm ngoài cuộc hội thoại ghi lại những gì đã hoàn thành và những gì cần làm tiếp theo. Model quên giữa các lần chạy; file thì không.

Lắp ráp sáu phần đó, bạn đã có một điểm khởi đầu tốt cho loop engineering. Trước đây bạn phải tự xây dựng mọi thứ; giờ đây hầu hết đã có sẵn như các tính năng tích hợp, đó là lý do tại sao mô hình này đã chuyển từ một kỹ thuật ngoại vi thành một phương pháp phổ biến.

Một vòng lặp cụ thể: người giám sát PR

Một ví dụ cụ thể bạn có thể xây dựng ngay hôm nay:

• Kích hoạt. Mỗi 15 phút một lần.
• Phạm vi. Các PR đang mở có label agent-watch.
• Hành động. Nếu CI báo đỏ vì một lý do có thể xác định, hãy thực hiện một lần sửa. Nếu nhánh chính đã thay đổi, rebase một lần.
• Ngân sách. Một lần sửa mỗi PR, tối đa năm phút, tối đa mười file thay đổi.
• Điều kiện dừng. CI chuyển xanh hoặc hết ngân sách, sau đó dừng và thông báo cho người dùng.

Bạn sẽ thấy các PR được merge thay vì một đống backlog các bản build bị hỏng. Hình thức tương tự áp dụng cho hầu hết công việc vận hành:

• Sức khỏe CI. Mỗi 30 phút, lấy các lần chạy thất bại và nhóm chúng theo dấu hiệu, để mười PR đỏ có cùng một nguyên nhân gốc trở thành một thứ cần xem xét.
• Xác minh triển khai. Sau khi push, truy cập các endpoint của bạn, xác nhận mã 200 và nội dung dự kiến, đồng thời gắn cờ các lỗi hồi quy trước khi người dùng phát hiện ra.
• Phân cụm phản hồi. Mỗi 30 phút, lấy bình luận từ các kênh của bạn, nhóm chúng thành các chủ đề và ánh xạ mỗi cụm đến file hoặc tài liệu sở hữu nó.

Một vòng lặp Claude Code cụ thể với /goal

Người giám sát là một vòng lặp bạn tự kết nối; cũng hữu ích khi thấy một vòng lặp được tích hợp sẵn trong agent. Trong Claude Code, vòng lặp hoàn chỉnh nhỏ nhất là /goal: bạn đưa ra một trạng thái cuối có thể kiểm chứng và nó tiếp tục thực hiện các lượt cho đến khi trạng thái đó đạt được.

Đây là một ví dụ về /goal được sử dụng như một lệnh trong phiên làm việc của Claude Code. Bạn khởi chạy phiên, sau đó đặt mục tiêu bên trong nó:

1$ claude  # khởi chạy Claude Code
2$ /goal tests in test/auth pass   # đặt mục tiêu trong phiên làm việc

Đó là cùng một hình thức hành động-kiểm tra-lặp lại như trước, với trình xác minh được tích hợp sẵn.

Tại thời điểm này, rõ ràng là một /goal tốt trông giống một hợp đồng hơn là một lời nhắc lệnh. Một /goal tốt chỉ định bốn điều: trạng thái cuối bạn muốn, bằng chứng chứng minh bạn đã đạt được nó, các ràng buộc mà agent không được vi phạm để đạt được nó, và ngân sách công việc mà nó được phép sử dụng. Để bất kỳ điều nào trong số đó mơ hồ, model sẽ lấp đầy khoảng trống bằng cách đọc theo hướng dễ nhất: nó dừng sớm, đi đường tắt hoặc định nghĩa lại thành công để bảng điểm trông có vẻ hoàn thành trong khi hệ thống thực sự vẫn bị hỏng.

• Đặt điều kiện. Gõ /goal và một trạng thái cuối có thể kiểm tra, ví dụ: /goal tests in test/auth pass. Lượt đầu tiên bắt đầu ngay lập tức.
• Agent thực hiện một lượt. Nó chỉnh sửa, chạy các bài kiểm tra và hiển thị kết quả trong phiên làm việc.
• Trình đánh giá kiểm tra. Một model nhanh đọc bảng điểm và quyết định xem nó đã đạt hay chưa, để agent không tự đánh giá công việc của chính mình.
• Lặp lại hoặc kết thúc. Chưa đạt nghĩa là một lượt khác với hướng dẫn; đạt nghĩa là mục tiêu tự xóa và quá trình chạy dừng lại.

Trạng thái được duy trì qua các lượt, do đó nó không bỏ cuộc sớm hoặc bỏ rơi ràng buộc giữa chừng. Một số biện pháp kiểm soát giúp nó đáng tin cậy:

• Làm cho việc kiểm tra có thể đo lường được. Một kết quả kiểm thử, một mã thoát, một số lượng file hoặc một hàng đợi trống. "npm test exits 0" là một mục tiêu; "làm cho nó tốt hơn" thì không.
• Giới hạn quá trình chạy. Thêm nội dung như "hoặc dừng sau 20 lượt" để một vòng lặp bị kẹt sẽ tự dừng thay vì đốt cháy các lượt.
• Kết hợp với chế độ tự động để các lượt chạy không cần giám sát và sử dụng /goal clear để hủy bỏ nó sớm.

Bước đánh giá ẩn chứa một điểm tinh tế hữu ích: trình kiểm tra không nhất thiết phải là cùng một model với người lập trình. Khi vòng lặp có các vai trò riêng biệt (người lập kế hoạch, người thực thi, người đánh giá, người xem xét trực quan), mỗi vai trò có thể chạy trên một model khác nhau và việc chọn model nào đảm nhận vai trò nào trở thành một quyết định kiến trúc thay vì đặt cược duy nhất vào một coding agent "tốt nhất". Một số model lập kế hoạch tốt hơn, một số thực thi rẻ hơn, một số đánh giá ảnh chụp màn hình chính xác hơn và một người điều phối tốt cho phép bạn hoán đổi chúng theo vai trò thay vì chờ một nhà cung cấp duy nhất chiến thắng trong mọi hạng mục.

Nó hoạt động tốt cho việc di chuyển API (di chuyển mọi vị trí gọi cho đến khi nó biên dịch và các bài kiểm tra vượt qua), tái cấu trúc (chia nhỏ một file cho đến khi mỗi module nằm trong ngân sách), làm việc với backlog issue (xử lý một hàng đợi đã được gắn nhãn cho đến khi nó trống) và các vòng lặp đánh giá (tinh chỉnh một prompt cho đến khi điểm số vượt qua một ngưỡng). /loop là đối tác cho công việc không có một vạch đích duy nhất: thay vì một điều kiện hoàn thành, nó nhắc lại lệnh theo lịch trình, đó là cách một vòng lặp như người giám sát PR tiếp tục chạy.

Chạy nhiều vòng lặp không cần giám sát

Một vòng lặp /goal đơn lẻ là một agent làm việc hướng tới một vạch đích. Chạy nhiều quy trình không cần giám sát sẽ làm tăng rủi ro, bởi vì một vòng lặp chỉ đáng tin cậy khi nó có khả năng tự kiểm tra công việc của mình. Thiết lập của Cherny để chạy Opus một cách tự động trong nhiều giờ bao gồm năm bước:

1. Tự động phê duyệt quyền để agent không dừng lại để hỏi trên mỗi lần gọi công cụ.
2. Sử dụng quy trình làm việc động (thêm Ultracode vào prompt) để phân nhánh ra nhiều agent thay vì một luồng tuần tự duy nhất.
3. Sử dụng /goal hoặc /loop để duy trì hoạt động. /goal đặt một điều kiện hoàn thành, /loop nhắc lại lệnh theo lịch trình và cả hai đều duy trì trạng thái, do đó nó không dừng sớm.
4. Chạy nó trên đám mây (ứng dụng desktop hoặc mobile) để phiên làm việc vẫn tồn tại khi bạn đóng laptop.
5. Cung cấp cho nó một cách để tự xác minh từ đầu đến cuối. Claude trong Chrome cho web, một MCP mô phỏng cho mobile và một máy chủ trực tiếp cho backend. Đây là bước làm cho bốn bước kia trở nên an toàn.

Trình tự đầy đủ:

1claude --permission-mode auto                          # 1 · không có lời nhắc phê duyệt
2ultracode  orchestrate sub-agents to ship the feature  # 2 · phân nhánh
3/goal all tests pass and the demo loads clean          # 3 · tiếp tục
4→ cloud / desktop app                                  # 4 · đóng laptop
5→ chrome ext · sim MCP · live server                   # 5 · tự xác minh, sau đó dừng

crabfleet: điều phối như một sản phẩm

Việc điều phối sẽ dễ hình dung hơn với một công cụ cụ thể. crabfleet của Peter Steinberger, một dự án OpenClaw được mô tả là "trung tâm điều khiển cho các lần chạy agent", là một vòng lặp được đóng gói như một sản phẩm và hình thức của nó tương ứng với mọi thứ ở trên.

• Công việc dưới dạng thẻ trên bảng. Các nhiệm vụ được nhập dưới dạng thẻ được xây dựng từ một prompt, một issue trên GitHub hoặc một PR, sau đó di chuyển qua các trạng thái cần làm, đang chạy, xem xét bởi con người và đã hoàn thành. Bảng đó là hàng đợi của vòng lặp và bước dừng và báo cáo của nó, được hiển thị trực quan.
• Các lần chạy bền bỉ, không phải dạng chạy rồi quên. Mỗi lần chạy là một lần thử được theo dõi với các tín hiệu heartbeat, để nó tiếp tục hoạt động khi bạn rời mắt và tồn tại khi bạn đóng laptop. Bạn chỉ tiếp quản khi runtime quảng cáo rằng nó hỗ trợ bàn giao.
• Agent có thể sinh ra agent khác. Một lần chạy có thể bắt đầu các phiên con, gửi tin nhắn, đọc bảng điểm và cập nhật bản tóm tắt của chính nó từ bên trong một sandbox: bộ nhớ trên đĩa và khả năng phân nhánh ở cùng một nơi, một tác giả và nhiều agent.

Nó chạy trên các sandbox đám mây dùng một lần với thiết bị đầu cuối dựa trên trình duyệt, đó là điều làm cho việc rời khỏi một lần chạy không cần giám sát trở nên an toàn. Vấn đề không phải là công cụ cụ thể mà là vòng lặp đã được củng cố thành hạ tầng cơ sở: một hàng đợi, thực thi bền bỉ, phân nhánh và một cổng kiểm tra của con người giờ đây là những thứ bạn cấu hình thay vì phải tự viết kịch bản mỗi lần.

Chi phí bây giờ đi về đâu

Trong hai năm, câu hỏi về chi phí trong lập trình AI rất đơn giản: model nào và bao nhiêu token. Bên trong một vòng lặp, bản năng đó lại chỉ vào lớp sai. Chi phí không còn là một lần gọi duy nhất mà là số lần vòng lặp quay vòng, do đó một vòng lặp thử lại sáu lần trước khi hội tụ sẽ tốn kém gấp sáu lần so với một vòng lặp đạt được ngay trong lần đầu tiên, trên cùng một model.

Điều đó thay đổi những gì đáng để tối ưu hóa:

• Số lần lặp là hạng mục ngân sách, không phải token. Một model rẻ hơn nhưng lặp lại thường xuyên gấp đôi thì không hề rẻ hơn, vì vậy hãy theo dõi chi phí cho mỗi tác vụ đã hoàn thành, không phải chi phí cho mỗi lần gọi.
• Một bộ xác minh yếu là lỗi đắt giá nhất bạn có thể phát hành. Nếu việc kiểm tra quyết định "hoàn thành" còn lỏng lẻo, vòng lặp sẽ dừng sớm trên công việc bị hỏng hoặc tiếp tục cày trên công việc đã ổn, và cả hai đều lãng phí toàn bộ các lần lặp. Hãy thắt chặt điều này trước bất cứ thứ gì khác.
• Thất bại nhanh là một biện pháp kiểm soát chi phí. Một vòng lặp không có giới hạn về số lần thất bại liên tiếp cuối cùng sẽ không thành công; nó cuối cùng sẽ cạn kiệt tài khoản, do đó điều kiện dừng bảo vệ hóa đơn cũng như cơ sở mã.

Trước đây bạn tinh chỉnh prompt; bây giờ bạn tinh chỉnh vòng lặp, bởi vì đó là nơi chi phí tích lũy.

Khi nào không nên dùng vòng lặp

Vòng lặp mang lại hiệu quả khi một tác vụ lặp đi lặp lại và máy móc có thể biết khi nào nó hoàn thành. Ngoài ra, vòng lặp chỉ tự động hóa sự xáo trộn. Bỏ qua nó trong những trường hợp sau:

• Chỉnh sửa một lần. Nếu bạn có thể hoàn thành nó trong một lần duy nhất, vòng lặp hoàn toàn là chi phí phụ.
• Công việc không có phạm vi hoặc mang tính khám phá. "Tìm hiểu tại sao người dùng bỏ đi" không có điều kiện vượt qua, do đó vòng lặp không bao giờ hội tụ.
• Bất cứ thứ gì không có kiểm tra tự động rẻ. Nếu người xác minh duy nhất là chính mắt bạn, bạn vẫn đang ở bên trong vòng lặp. Hãy xây dựng bước kiểm tra trước hoặc tự mình thực hiện tác vụ đó.

Những điều có thể sai

Một vòng lặp chạy trong khi bạn ngủ cũng mắc lỗi trong khi bạn ngủ và các dạng thất bại có thể dự đoán trước.

• Gánh nặng xác minh vẫn là con người. Vòng lặp viết nhanh hơn bạn có thể xem xét, vì vậy nếu bạn ngừng đọc các bản diff, bạn không hề loại bỏ công việc mà chỉ trì hoãn nó.
• Khoảng cách về hiểu biết ngày càng rộng. Gửi mã mà bạn không viết, nhanh hơn khả năng bạn tiếp thu, làm xói mòn mô hình của chính hệ thống của bạn và khoản nợ đó sẽ đến hạn trong lần xử lý sự cố tiếp theo.
• Trôi dạt thầm lặng trên một bước kiểm tra lỏng lẻo. Một bộ xác minh yếu cho phép công việc sai nhưng vượt qua lọt vào mọi lần lặp, do đó vòng lặp trông có vẻ hiệu quả trong khi nó đang đào một cái hố.

Không có điều nào trong số này là lý lẽ chống lại vòng lặp; đó là lý do tại sao kỹ sư thiết kế vòng lặp lại càng quan trọng hơn, chứ không phải ít hơn.

Cách xây dựng vòng lặp của riêng bạn

1. Chọn một tác vụ có thể lặp lại. Giám sát PR, sửa CI, xác minh triển khai: hãy bắt đầu với công việc thường nhật.
2. Giới hạn phạm vi chặt chẽ. "Sửa xác thực webhook thanh toán, chỉ chạm vào app/api/billing và lib/billing" tốt hơn "sửa lỗi". Một vòng lặp lỏng lẻo sẽ lang thang.
3. Cung cấp cho nó một ngân sách và một điều kiện dừng. Số lần thử tối đa, thời gian chạy tối đa, số file tối đa, chi tiêu tối đa, số lần thất bại liên tiếp tối đa. Một vòng lặp chạy không cần giám sát cũng là một vòng lặp đang mắc lỗi không cần giám sát.
4. Thêm một bộ xác minh độc lập. Một sub-agent riêng biệt đánh giá công việc, bởi vì agent đã viết mã là người đánh giá tồi nhất về việc liệu nó đã hoàn thành hay chưa.
5. Chạy nó theo một nhịp độ. /loop cho một khoảng thời gian, cron cho một lịch trình, hooks tại các điểm trong vòng đời hoặc GitHub Actions để nó tồn tại khi bạn đóng laptop.
6. Giữ bộ nhớ trên đĩa. Model quên giữa các lần chạy, do đó trạng thái sống trong markdown hoặc một bảng, không phải trong cửa sổ ngữ cảnh.

Kết luận: vòng lặp, không phải model, giờ đây là phần đắt đỏ và dễ hỏng hóc. Hãy xây dựng nó như một người có ý định vẫn là kỹ sư chịu trách nhiệm về đầu ra, chứ không chỉ là người khởi động quá trình chạy.

Nếu bạn thấy bất kỳ lỗi nào hoặc điều gì cần làm rõ hơn, đừng ngần ngại liên hệ.

Các tài liệu tham khảo hữu ích khác

• Addy Osmani (@addyosmani), về các vòng lặp lập trình có sự hỗ trợ của AI
• Matt Van Horn (@mvanhorn), "WTF Là Một Vòng Lặp?"
• Peter Steinberger (@steipete), về thiết kế vòng lặp
• Boris Cherny (@bcherny), về chạy agent một cách tự động