Bắt đầu với loop

• Thay vì chỉ đạo coding agent bằng từng prompt một, đang chuyển sang mô hình vận hành agent lặp lại chu trình công việc cho đến khi đáp ứng điều kiện dừng
• Đội ngũ Claude Code phân loại loop theo 4 tiêu chí: cách kích hoạt, cách dừng, primitive được dùng, loại công việc phù hợp
• Các loại loop chính gồm 4 nhóm: Turn-based, Goal-based, Time-based, Proactive
• Không phải mọi công việc đều cần loop phức tạp; hãy bắt đầu từ lời giải đơn giản nhất rồi áp dụng mẫu một cách chọn lọc
• Chất lượng đầu ra của loop phụ thuộc vào hệ thống xung quanh, nên duy trì chất lượng mã và quản lý mức dùng token là then chốt

---

Định nghĩa loop và tiêu chí phân loại

• Đội ngũ Claude Code định nghĩa loop là một agent lặp lại chu trình công việc cho đến khi điều kiện dừng được thỏa mãn
• Đưa ra 4 tiêu chí để phân loại loop
  • Được kích hoạt như thế nào
  • Dừng lại như thế nào
  • Dùng primitive nào của Claude Code
  • Phù hợp nhất với loại công việc nào
• Không phải lúc nào cũng cần loop phức tạp; ưu tiên lời giải đơn giản rồi mới dùng mẫu một cách có chọn lọc

Loop Turn-based

• Được kích hoạt bằng prompt của người dùng, và dừng khi Claude đánh giá công việc đã hoàn tất hoặc cần thêm ngữ cảnh
• Phù hợp với các tác vụ ngắn không thuộc quy trình định kỳ hay lịch trình
• Cách quản lý là viết prompt cụ thể và cải thiện kiểm chứng bằng skills để giảm số turn
• Mọi prompt đều khởi động một loop thủ công nơi người dùng chỉ đạo từng turn; điều này được gọi là agentic loop
  • Claude thu thập ngữ cảnh → thực hiện hành động → xác nhận công việc → lặp lại nếu cần → phản hồi
  • Ví dụ: khi được yêu cầu tạo nút like, Claude sẽ đọc mã, chỉnh sửa, chạy test rồi trả kết quả; sau đó người dùng tự kiểm tra thủ công và viết prompt tiếp theo
• Bước kiểm chứng có thể mở rộng phạm vi tự xác nhận của Claude bằng cách mã hóa quy trình thủ công vào SKILL.md
  • Cần bao gồm công cụ hoặc connector để đo lường hay tương tác với kết quả
  • Việc kiểm chứng càng định lượng thì càng dễ tự kiểm chứng

• Ví dụ SKILL.md (verify-frontend-change)

  • Quy tắc kiểm chứng end-to-end thay đổi UI trước khi tuyên bố hoàn tất
  • Không được báo hoàn thành chỉ vì sửa mã thành công; hãy kiểm chứng như một reviewer con người
    • Khởi động dev server rồi mở trang đã chỉnh sửa bằng trình duyệt
    • Tự thao tác với phần tử đã thay đổi (nhấp nút, ô nhập, công tắc), xác nhận thay đổi trạng thái, chụp ảnh màn hình trước và sau
    • Xác nhận có đúng zero lỗi hoặc cảnh báo mới trong console của trình duyệt
    • Chạy performance trace bằng Chrome Devtools MCP và kiểm tra Core Web Vitals
  • Nếu một bước thất bại thì sửa rồi chạy lại từ bước 1, không được trả về trong trạng thái kiểm chứng dở dang

Loop Goal-based (/goal)

• Được kích hoạt bằng prompt thủ công theo thời gian thực, và dừng khi đạt mục tiêu hoặc chạm số turn tối đa
• Phù hợp với các công việc có tiêu chí kết thúc có thể kiểm chứng
• Cách quản lý là đặt tiêu chí hoàn thành cụ thể và giới hạn turn rõ ràng, ví dụ "dừng sau 5 lần thử"
• Với các tác vụ phức tạp mà một turn là không đủ, agent sẽ hoạt động tốt hơn khi lặp lại (iterate)
• Khi định nghĩa trạng thái hoàn tất bằng /goal, Claude sẽ không tự phán đoán "đã đủ tốt chưa" để dừng sớm
  • Mỗi khi Claude cố dừng, evaluator model sẽ kiểm tra điều kiện và buộc làm lại cho đến khi đạt mục tiêu hoặc tới số turn đã chỉ định
  • Các tiêu chí mang tính xác định như số lượng test vượt qua hay ngưỡng điểm cụ thể đặc biệt hiệu quả
• Ví dụ
  • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Loop Time-based (/loop và /schedule)

• Được kích hoạt theo khoảng thời gian chỉ định, và dừng khi người dùng hủy hoặc công việc hoàn tất (PR được merge, hàng đợi trống)
• Phù hợp với công việc lặp lại hoặc giao tiếp với môi trường, hệ thống bên ngoài
• Cách quản lý là đặt khoảng cách dài hơn hoặc phản ứng dựa trên sự kiện thay vì dựa trên thời gian
• Một số tác vụ agentic có tính lặp lại: công việc giống nhau nhưng đầu vào thay đổi, ví dụ tóm tắt tin nhắn Slack mỗi sáng
• Với công việc phụ thuộc hệ thống bên ngoài, có thể giao tiếp bằng cách kiểm tra ở mỗi chu kỳ rồi phản ứng khi có thay đổi, ví dụ PR phát sinh review code hoặc CI lỗi
• /loop sẽ chạy lại prompt theo từng khoảng thời gian
  • /loop 5m check my PR, address review comments, and fix failing CI
• /loop chạy trên máy tính của người dùng nên sẽ dừng khi phiên làm việc kết thúc; có thể chuyển thành routine trên cloud bằng /schedule

Loop Proactive

• Được kích hoạt bằng sự kiện hoặc lịch trình mà không cần con người can thiệp theo thời gian thực
• Mỗi tác vụ sẽ kết thúc khi đạt mục tiêu, còn bản thân routine tiếp tục chạy cho đến khi người dùng tắt đi
• Phù hợp với luồng công việc lặp lại, được định nghĩa rõ như báo lỗi, phân loại issue, migration, nâng cấp dependency
• Cách quản lý là định tuyến routine sang các model nhỏ hơn, nhanh hơn và chỉ dùng model mạnh nhất ở phần cần phán đoán
• Có thể kết hợp các primitive ở trên với auto mode, dynamic workflows (research preview) để tạo loop chạy dài hạn

• Ví dụ cấu hình xử lý phản hồi

  • Dùng /schedule (research preview) để chạy routine kiểm tra báo cáo mới
  • Dùng /goal để định nghĩa hoàn tất, và dùng skills để tài liệu hóa cách kiểm chứng
  • Dùng Dynamic workflows để điều phối các agent phân loại, sửa lỗi và rà soát cho từng báo cáo
  • Dùng Auto mode để chạy routine mà không cần xác nhận quyền
  • Ví dụ prompt tích hợp: /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

Duy trì chất lượng mã

• Chất lượng đầu ra của loop phụ thuộc vào hệ thống xung quanh, nên thiết kế hệ thống là rất quan trọng
• Giữ codebase sạch: Claude sẽ làm theo các mẫu và quy ước sẵn có trong codebase hiện tại
• Cung cấp phương tiện tự kiểm chứng: dùng skills để mã hóa trạng thái "tốt" theo tiêu chuẩn của nhóm
• Tạo điều kiện tiếp cận tài liệu: tài liệu framework và thư viện chứa các best practice mới nhất
• Dùng second agent cho code review: reviewer với ngữ cảnh mới sẽ ít thiên lệch hơn và không bị ảnh hưởng bởi suy luận của agent chính; có thể dùng skill /code-review tích hợp sẵn hoặc Code Review cho Github
• Khi kết quả riêng lẻ không đạt chuẩn, đừng chỉ sửa từng issue mà hãy mã hóa để cải thiện chính hệ thống

Quản lý mức dùng token

• Loop cần có ranh giới rõ ràng và áp dụng các nguyên tắc sau
• Chọn primitive và model phù hợp: việc nhỏ không cần multi-agent hay loop, một số tác vụ có thể dùng model rẻ và nhanh hơn
• Định nghĩa tiêu chí thành công và dừng rõ ràng: mô tả cụ thể trạng thái hoàn tất để không đạt mốc quá sớm
• Thử nghiệm trước khi chạy quy mô lớn: dynamic workflows có thể tạo ra hàng trăm agent, hãy đo mức sử dụng trên phạm vi nhỏ trước
• Dùng script cho tác vụ mang tính xác định: chạy script rẻ hơn việc để model suy luận từng bước; ví dụ skill PDF có thể cung cấp script điền form thay vì tạo lại mã mỗi lần
• Không chạy routine quá mức cần thiết: đặt khoảng thời gian phù hợp với tần suất thay đổi của đối tượng theo dõi
• Xem lại mức sử dụng: /usage phân tích mức dùng theo skills, subagents và MCPs; /goal không kèm tham số sẽ hiển thị số turn hiện tại và lượng token đã dùng; /workflows hiển thị mức dùng token của từng agent và có thể dừng bất cứ lúc nào

Bắt đầu

• Tóm tắt theo từng loại loop
  • Turn-based: ủy quyền việc kiểm chứng (check), dùng khi cần khám phá hoặc ra quyết định, tận dụng skills kiểm chứng tùy chỉnh
  • Goal-based: ủy quyền điều kiện dừng, dùng khi biết rõ trạng thái hoàn tất, tận dụng /goal
  • Time-based: ủy quyền việc kích hoạt, dùng khi công việc phát sinh theo lịch từ bên ngoài dự án, tận dụng /loop và /schedule
  • Proactive: ủy quyền cả prompt, dùng cho công việc lặp lại và được định nghĩa rõ, tận dụng tất cả các phần trên cùng dynamic workflows
• Cách bắt đầu là xem lại các công việc bạn vốn đang làm, chọn một công việc mà bạn chính là nút thắt cổ chai rồi đánh giá phần nào có thể ủy quyền
  • Có thể viết checklist kiểm chứng không
  • Mục tiêu có đủ rõ ràng không
  • Công việc có đến theo lịch không
• Khi có ý tưởng, hãy chạy loop, quan sát nơi nó bị kẹt hoặc chạy quá mức, và đừng ngại cải tiến lặp đi lặp lại