Vài tuần trước mình có viết về vì sao tech lead nên ngừng viết prompt, bắt đầu viết loop — khung ra quyết định cho việc khi nào nên tự động hóa thói quen prompt thủ công. Cái bài đó chưa nói tới phần thực sự hay bể trong production: bạn chọn kiến trúc loop nào, và chuyện gì xảy ra khi chọn sai. Một bài deep-dive gần đây từ Data Science Dojo lần theo hành trình tiến hóa này rất chi tiết, và đáng để tech lead dành thời gian đọc — vì phần lớn team vẫn đang mắc lỗi của Generation 1 trong khi dùng tooling của Generation 4.
Loop, Rút Gọn Về Hai Thứ
Bỏ hết tooling ra, một agentic loop chỉ cần đúng hai thành phần: một trigger — theo sự kiện, theo lịch, hoặc do người khởi tạo — và một goal kiểm chứng được. Agent sau đó xoay vòng qua 5 bước cho đến khi đạt goal:
- Perceive — nạp input: goal của user, kết quả từ tool, response từ API
- Reason — hiểu input nghĩa là gì và có những lựa chọn nào
- Plan — chọn hành động tiếp theo
- Act — thực thi: gọi tool, viết code, query database
- Observe — nhận kết quả và cập nhật lại hiểu biết
Chu trình đó là toàn bộ engine. Mọi thứ nói tiếp trong bài này chỉ là các tinh chỉnh gắn thêm vào một trong năm bước đó, để fix một kiểu bể cụ thể đã xảy ra trong thực tế.
Bốn Thế Hệ, Mỗi Thế Hệ Fix Lỗi Của Thế Hệ Trước
| Thế hệ | Thời điểm | Thêm vào cái gì | Fix vấn đề gì |
|---|---|---|---|
| 1 — Proof of concept | 3/2023 | AutoGPT: chia goal thành sub-task, gắn tool web + file | Chứng minh có nhu cầu — nhưng lập tức dính infinite loop và hóa đơn API bung nóc |
| 2 — Academic framework | 2022–2023 | ReAct (reasoning trace đi kèm action, +34% trên ALFWorld), Reflexion (tự phê bình trước khi retry), Plan-and-Execute (tách planning khỏi execution, nhanh 3.6x theo nghiên cứu LangChain) | Cho loop khả năng suy luận về hành động của chính nó, thay vì chỉ nối chuỗi hành động |
| 3 — Architectural pattern | 2024 | OODA loop (thêm bước “Orient” tường minh), inner/outer dual loop của Microsoft Magentic-One, multi-agent supervisor orchestration | Ngăn agent bị kẹt retry lại đúng chiến lược đã fail — đổi lại multi-agent tốn ~15x token |
| 4 — Practitioner tooling | 2025–2026 | Ralph Loop (reset context mỗi vòng, dùng file system làm memory), /goal native trong Claude Code và Codex với evaluator model riêng, pattern parallel-workflow của Boris Cherny (5+ session Claude chạy song song, share state qua CLAUDE.md) | Giải quyết context overflow và premature exit — hai failure mode khiến loop chạy dài không đáng tin cậy |
Điểm chung xuyên suốt bốn thế hệ: ai đó gặp một lỗi cụ thể, gọi tên được, và thế hệ tiếp theo là một fix nhắm thẳng vào đúng lỗi đó — không phải một cải tiến chung chung. Điều này hữu ích để biết, vì nó có nghĩa là bạn nên chọn kiến trúc dựa trên failure mode mà mình thực sự đang gặp, chứ không phải mặc định chọn cái gì mới nhất.
Memory Là Phần Ai Cũng Làm Sai Đầu Tiên
Loop trong production cần memory, và có bốn loại khác nhau đang cùng tồn tại — gộp chung chúng lại là lý do phần lớn lần thử đầu tiên đi sai hướng:
- Episodic — bản ghi những gì agent đã thử và kết quả ra sao
- Semantic — domain knowledge có cấu trúc: architecture decision, API docs, những thứ một senior engineer “vốn đã biết”
- Vector — retrieval dựa trên similarity, kéo vào những đoạn liên quan theo ngữ cảnh
- File-based — state sống trên disk, sống sót qua một lần reset context (đây chính là chiêu của Ralph Loop)
Pattern CLAUDE.md của Boris Cherny là semantic memory làm đúng cách: một file tồn tại xuyên suốt mọi session, mọi lần reset context, để agent không phải học lại convention của codebase mỗi lần chạy. Nếu loop của team bạn cứ mắc lại đúng một dạng lỗi qua các session, vấn đề là thiếu semantic memory, không phải cần model thông minh hơn.
Guardrail Không Phải Tùy Chọn — Đó Là Sản Phẩm
Đây là phần phân biệt một loop engineering practice thật với một demo. Mọi loop chạy production, tối thiểu cần:
- Giới hạn cứng số vòng lặp — một loop không có trần là một bug chờ ngày phát nổ
- Ngân sách token và cost — enforce ở tầng loop, không phải phát hiện ra trên hóa đơn
- Phát hiện không tiến triển — nếu state không đổi đáng kể sau N vòng, dừng và escalate
- Circuit breaker cho tool call — có case production ghi nhận một tool bị gọi 400 lần trong 5 phút
- Điều kiện dừng kiểm chứng được — “nhìn có vẻ xong” không phải điều kiện dừng; test suite pass mới là điều kiện dừng
- Human checkpoint trước hành động không đảo ngược được — bất cứ gì đụng production data, payment, deploy đều cần một cổng chặn, không ngoại lệ
Bỏ qua mấy cái này và bạn sẽ dính đúng những failure mode xuất hiện trong mọi postmortem của loop chạy hỏng: infinite loop vì goal không kiểm chứng được, goal drift vì spec mơ hồ, context overflow làm suy giảm chất lượng reasoning qua một session dài, và silent failure — output nghe rất tự tin nhưng không hề có tiến triển thật.
Hóa Đơn Token Là Một Quyết Định Kiến Trúc, Không Phải Tai Nạn
| Setup | Hệ số token so với một chat session thường |
|---|---|
| Single agent, loop kiểu ReAct | ~4x |
| Multi-agent supervisor orchestration | ~15x |
Có case ghi nhận chi phí token lên tới $1.3 triệu/tháng. Đó không phải câu chuyện cảnh báo “AI đắt” — mà là câu chuyện cảnh báo về việc triển khai multi-agent orchestration cho một bài toán mà một loop ReAct đơn giản đã giải được với 1/4 chi phí. Hệ số nhân token nên là một dòng trong quyết định kiến trúc của bạn, không phải thứ finance phát hiện ra ở Q3.
Chọn Pattern Nào Cho Đúng
Hướng dẫn lựa chọn này khớp với những gì team đang report trong production:
- Bắt đầu với ReAct. Nó là mặc định vì lý do chính đáng — phần lớn task không cần kiến trúc phức tạp hơn “reason, rồi act, rồi observe.”
- Thêm Reflexion khi failure mode là chất lượng, không phải phạm vi — agent hoàn thành task nhưng sai chi tiết ở lần chạy đầu. Tự phê bình trước khi retry fix đúng loại lỗi này.
- Dùng Ralph Loop khi task nặng về context — migration chạy dài, refactor lớn, bất cứ gì mà bottleneck là chính context window chứ không phải reasoning.
- Chỉ đi multi-agent khi đã đo được một cải thiện cụ thể xứng đáng với 15x chi phí. “Có vẻ như nó sẽ giúp” không phải một phép đo.
Việc Tech Lead Nên Làm Tuần Này
Audit các loop hiện có của team — hoặc thói quen re-prompt thủ công đang là ứng viên cho loop — theo checklist này, chứ không phải theo kiến trúc nào đang trend trên X tuần này:
- Nó có điều kiện dừng kiểm chứng được không, hay dừng khi “nhìn có vẻ xong”?
- Nó có giới hạn cứng số vòng lặp và ngân sách cost được enforce trong code, không phải trong một Slack reminder?
- Chiến lược memory có khớp với failure thực tế bạn đang gặp không — semantic memory cho convention lặp lại, file-based cho context overflow, vector cho retrieval?
- Một mình ReAct có giải được bài toán này không, hay bạn chọn multi-agent vì nó là kiến trúc thú vị hơn là kiến trúc cần thiết?
Loop engineering không phải một kỹ năng bạn có hoặc không có. Nó là một chồng fix cụ thể cho những lỗi cụ thể, và công việc của tech lead là biết mình đang thực sự fix lỗi nào trước khi chồng thêm một lớp kiến trúc nữa lên trên.