1.1 Agentic Loops

Những gì cần nắm

Agentic loop là vòng thực thi lõi nằm sau mọi agent chạy trên Claude. Nó là control flow tất định, viết bằng code. Không phải mẹo prompt, không phải retry loop, cũng không phải một lượt chat. Nắm đúng vòng đời này thì phần lớn Domain 1 tự sáng ra; nắm sai thì agent của bạn đứng giữa chừng tác vụ ngay trên production.

Vòng đời của agentic loop

Vòng lặp gồm bốn bước, lặp lại tới khi xong:

Gửi request tới Claude qua Messages API. Request này mang theo toàn bộ lịch sử hội thoại (system prompt, các message trước, và mọi tool result từ vòng lặp trước).
Đọc trường stop_reason trong response. Đây là tín hiệu có thẩm quyền quyết định bước kế tiếp. Với một agentic loop cơ bản, nó có hai giá trị đáng quan tâm:
- "tool_use" — Claude muốn gọi một hoặc nhiều tool. Vòng lặp tiếp tục.
- "end_turn" — Claude đã làm xong. Vòng lặp dừng.
Nếu stop_reason là "tool_use": chạy (các) tool được yêu cầu, append tool result vào lịch sử hội thoại dưới dạng message mới, rồi gửi lại hội thoại đã cập nhật cho Claude.
Nếu stop_reason là "end_turn": agent đã xong việc. Trả response cuối cùng cho user.

Bước 3 chính là chỗ loop hay vỡ. Tool result bắt buộc phải được append vào lịch sử hội thoại. Bỏ sót bước đó, Claude không thể suy luận trên thông tin mới ở vòng kế — model không bao giờ thấy tool trả về gì, nên cũng chẳng có gì mới để hành động.

Quyết định do model dẫn dắt

Trong một agentic loop, Claude tự chọn tool cần gọi dựa trên context hiện tại. Đó là model-driven decision-making — model đọc tác vụ, cân nhắc các tool đang có, rồi chọn một cái. So sánh với pre-configured decision tree hay fixed tool sequence, nơi developer hard-code sẵn tool nào chạy lúc nào.

Đề thi thiên về hướng model-driven vì nó linh hoạt. Claude thích ứng được với tình huống developer chưa từng vẽ ra, xử lý được edge case, và xâu chuỗi tool theo thứ tự không ai lên kế hoạch trước. Có đúng một ngoại lệ đáng thuộc lòng: khi business logic đòi tuân thủ tất định — thao tác tài chính, kiểm tra bảo mật, yêu cầu pháp lý — thì cưỡng chế bằng code thắng sự linh hoạt đó. Task Statement 1.4 nói kỹ phần này.

Ba anti-pattern

Có ba anti-pattern về cách dừng loop xuất hiện đi xuất hiện lại. Học cách nhận ra cả ba.

Anti-pattern 1: parse tín hiệu bằng ngôn ngữ tự nhiên. Kiểm tra xem Claude có nói “I’m done” hay “task complete” để quyết định dừng loop. Sai, vì ngôn ngữ tự nhiên bản chất là mơ hồ. Claude có thể nói “tôi đã phân tích xong file đầu tiên” trong khi vẫn định làm tiếp các file còn lại. Trường stop_reason sinh ra chính là để triệt tiêu sự mơ hồ này.

Anti-pattern 2: lấy cap số vòng lặp làm cơ chế dừng chính. Đặt “dừng sau 10 vòng” làm cách chính để kết thúc agent. Sai, vì nó hoặc cắt ngang công việc còn dở (nếu tác vụ thật sự cần 12 vòng), hoặc chạy thừa vòng (nếu tác vụ xong trong 3 vòng). Model đã báo hoàn tất qua stop_reason — dùng tín hiệu đó. Cap số vòng chấp nhận được ở vai trò lưới an toàn (chặn trên để agent không chạy hoang), nhưng không bao giờ là cơ chế điều khiển chính.

Anti-pattern 3: coi việc có text trong response là dấu hiệu hoàn tất. Dùng response.content[0].type == "text" để kết luận loop đã xong. Sai, vì Claude có thể trả text nằm chung với các block tool_use. Một response có thể chứa đoạn giải thích (“Tôi sẽ tra lịch sử đơn hàng của khách”) rồi ngay sau đó là một tool call. Sự hiện diện của text không nói lên agent đã xong hay chưa.

Ví dụ thực tế: bug dừng sớm

Một developer build agent hỗ trợ khách hàng. Nó chạy ổn với câu hỏi đơn giản nhưng thỉnh thoảng đứng giữa chừng với yêu cầu phức tạp. Code đang kiểm tra if response.content[0].type == "text" để xác định đã xong.

Bug: Claude trả về một đoạn text giải thích (“Để tôi tra đơn hàng của bạn”) nằm chung với một block tool_use yêu cầu tool lookup_order. Code thấy text ở vị trí [0], kết luận agent đã xong, rồi trả response dở dang cho user.

Cách sửa: thay kiểm tra content type bằng kiểm tra stop_reason. Tiếp tục loop khi stop_reason == "tool_use", dừng khi stop_reason == "end_turn". Cách này đúng bất kể response chứa những content type nào.

Bẫy thi

Tình huống luyện tập

Agent của một developer thỉnh thoảng dừng sớm khi Claude trả text nằm chung với một tool call. Loop của họ kiểm tra response.content[0].type == ‘text’ để xác định agent đã xong. User báo nhận được response dở dang với các câu hỏi phức tạp. Developer nên đổi gì?

A. Thêm cap 15 vòng lặp để agent chạy đủ lâu cho các câu hỏi phức tạp
B. Đặt tool_choice thành any để Claude luôn gọi tool thay vì trả text
C. Parse text của assistant tìm các cụm báo hoàn tất như “I have finished” trước khi dừng loop
D. Kiểm tra trường stop_reason thay vì content type — tiếp tục khi stop_reason là tool_use, dừng khi end_turn

Đáp án & giải thích

Đúng: D

A — Cap tùy tiện không chạm tới nguyên nhân gốc. Agent thoát vì nhận diện sai loại response, không phải vì lặp chưa đủ. Cap 15 vẫn dừng sớm như thường nếu bug text-check kích hoạt ở vòng thứ 2.
B — Cách này ép gọi tool ngay cả khi agent thật sự đã xong, tạo vòng lặp vô hạn. Vấn đề không nằm ở việc Claude trả text — vấn đề là code hiểu nhầm sự hiện diện của text thành tín hiệu hoàn tất.
C — Parse ngôn ngữ tự nhiên vừa mơ hồ vừa không đáng tin. Claude có thể nói đã xong một bước trong khi vẫn định làm bước kế. Trường stop_reason đã cho sẵn tín hiệu rõ ràng.
D — Trường stop_reason là tín hiệu tất định, có thẩm quyền để điều khiển loop. Nó phân biệt đúng giữa response mà Claude còn muốn gọi thêm tool (tool_use) và response mà Claude đã xong (end_turn), bất kể có text đi kèm tool call hay không.

Nguồn

Claude Agent SDK Overview — Anthropic
Messages API Reference — Anthropic
Building with Claude API (Skilljar) — Anthropic

Exam Simulator

Năm câu trắc nghiệm theo format đề thi về Agentic Loops. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

Agent của một developer thỉnh thoảng dừng sớm khi Claude trả text nằm chung với một tool call. Loop của họ kiểm tra response.content[0].type == "text" để xác định agent đã xong. User báo nhận được response dở dang với các câu hỏi phức tạp. Developer nên đổi gì?

A. Thêm cap 15 vòng lặp để agent chạy đủ lâu cho các câu hỏi phức tạp
B. Parse text của assistant tìm các cụm báo hoàn tất như “I have finished” trước khi dừng loop
C. Kiểm tra trường stop_reason thay vì content type — tiếp tục khi stop_reason là “tool_use”, dừng khi “end_turn”
D. Đặt tool_choice thành “any” để Claude luôn gọi tool thay vì trả text, và coi một reply chỉ có text là dấu hiệu kết thúc

Đáp án & giải thích

Đúng: C

C đúng vì stop_reason là tín hiệu tất định, có thẩm quyền để điều khiển loop. Nó phân biệt đúng giữa response mà Claude còn muốn gọi thêm tool (tool_use) và response mà Claude đã xong (end_turn), bất kể có text đi kèm tool call hay không.
A sai vì cap tùy tiện không chạm tới nguyên nhân gốc. Agent thoát vì nhận diện sai loại response, không phải vì lặp chưa đủ. Cap 15 vẫn dừng sớm nếu bug text-check kích hoạt ở vòng thứ 2.
B sai vì parse ngôn ngữ tự nhiên mơ hồ và không đáng tin. Claude có thể nói đã xong một bước trong khi vẫn định làm bước kế. Trường stop_reason đã cho sẵn tín hiệu rõ ràng.
D sai vì cách này ép gọi tool ngay cả khi agent thật sự đã xong, tạo vòng lặp vô hạn. Vấn đề không nằm ở việc Claude trả text — vấn đề là code hiểu nhầm sự hiện diện của text thành tín hiệu hoàn tất.

Câu 2

Mô tả nào đúng về vòng đời của agentic loop?

A. Gửi request, đọc stop_reason, nếu “tool_use” thì chạy tool và append kết quả vào history, nếu “end_turn” thì kết thúc
B. Gửi request, xem response có text không, parse text lấy hướng dẫn, chạy mọi tool được nhắc trong text
C. Gửi request, chạy tuần tự tất cả tool đang có, xem có tool nào lỗi không, retry các tool lỗi
D. Gửi request, đếm token trong response, nếu vượt ngưỡng thì cần dùng tool, ngược lại thì kết thúc

Đáp án & giải thích

Đúng: A

A đúng vì vòng đời agentic loop đi theo bốn bước tất định: gửi request qua Messages API, đọc stop_reason, chạy tool và append kết quả nếu là tool_use, dừng nếu là end_turn.
B sai vì nó dựa vào việc parse ngôn ngữ tự nhiên để lấy hướng dẫn, vốn mơ hồ. Trường stop_reason mới quyết định bước kế tiếp, không phải nội dung text.
C sai vì agentic loop không chạy tuần tự mọi tool. Claude chọn tool nào cần gọi dựa trên context (model-driven decision-making). Tool cũng không tự động được retry.
D sai vì số token không liên quan gì tới việc điều khiển loop. Trường stop_reason là tín hiệu có thẩm quyền duy nhất để quyết định tiếp tục hay dừng.

Câu 3

Một agent làm đúng các tác vụ đơn giản nhưng rơi vào vòng lặp vô hạn với câu hỏi phức tạp. Developer sửa bằng cách thêm cap 10 vòng lặp. Cách này sai ở đâu?

A. Cap đặt quá thấp — với câu hỏi phức tạp phải để ít nhất 50
B. Cap số vòng chỉ chạy được với API đồng bộ, không dùng được với streaming response
C. Agent cần thêm tool để xử câu hỏi phức tạp, không phải cần cap số vòng
D. Cap chỉ là lưới an toàn; bug thật nằm ở chỗ stop_reason không được kiểm tra

Đáp án & giải thích

Đúng: D

D đúng vì vòng lặp vô hạn cho thấy stop_reason không được dùng đúng vai trò cơ chế điều khiển chính. Cap số vòng che bug chứ không sửa bug. Cap chỉ chấp nhận được như lưới an toàn (chặn trên) để agent không chạy hoang, không phải cơ chế điều khiển loop chính.
A sai vì nâng cap không sửa nguyên nhân gốc. Nếu loop vô hạn do stop_reason không được kiểm tra thì không giá trị cap nào giải quyết được vấn đề — nó chỉ làm chậm thời điểm dừng.
B sai vì cap số vòng áp dụng được cho mọi chế độ thực thi. Vấn đề là dùng nó làm cơ chế điều khiển chính thay vì kiểm tra stop_reason.
C sai vì số lượng tool không liên quan tới hành vi lặp vô hạn. Loop tiếp tục hay dừng là do stop_reason, không do có sẵn đúng tool hay không.

Câu 4

Vì sao tool result bắt buộc phải được append vào lịch sử hội thoại trước khi gửi request kế tiếp cho Claude?

A. Để giảm chi phí API bằng cách cache các response trước đó
B. Để Claude suy luận được trên thứ tool vừa trả về trước khi quyết định bước kế
C. Để stream được kết quả từng phần ra giao diện người dùng
D. Vì Messages API từ chối request không kèm lịch sử hội thoại đầy đủ

Đáp án & giải thích

Đúng: B

B đúng vì model cần thấy tool trả về gì để quyết định hành động kế tiếp. Không có tool result trong lịch sử hội thoại, Claude không đưa được output của tool vào chuỗi suy luận, nên cũng không quyết định nổi là gọi tiếp tool khác hay kết thúc.
A sai vì việc append tool result là để giữ mạch suy luận, không phải để giảm chi phí. Model cần dữ liệu để nghĩ, không phải để tiết kiệm tiền.
C sai vì append tool result liên quan tới chuỗi suy luận của model, không liên quan tới việc stream kết quả từng phần cho user. Đó là hai chuyện khác nhau.
D sai vì API không từ chối lịch sử thiếu như một ràng buộc kỹ thuật. Vấn đề là thiếu tool result thì model thiếu thông tin để suy luận đúng.

Câu 5

Một agent hỗ trợ khách hàng dùng model-driven decision-making để chọn tool. Trong trường hợp nào nên đè cách này bằng cưỡng chế bằng code?

A. Khi tác vụ đòi tuân thủ tất định cho thao tác tài chính, bảo mật hoặc pháp lý
B. Khi agent đang xử lý hơn 3 hội thoại đồng thời, vì chạy song song làm việc chọn tool của model kém tin cậy
C. Khi user gọi đích danh tên một tool trong message
D. Khi agent có hơn 5 tool, vì bề mặt tool rộng khiến lựa chọn của model khó đoán hơn

Đáp án & giải thích

Đúng: A

A đúng vì model-driven decision-making mang bản chất xác suất. Với thao tác mà một lần sai gây thiệt hại tài chính, lộ bảo mật hoặc vi phạm quy định, cưỡng chế bằng code cho đảm bảo tất định, và nó đè lên sự linh hoạt của model.
B sai vì số hội thoại đồng thời không quyết định chọn hướng model-driven hay cưỡng chế bằng code. Kiểu cưỡng chế được quyết định bởi mức độ rủi ro của thao tác.
C sai vì yêu cầu của user không đè lên quyết định kiến trúc giữa model-driven và cưỡng chế bằng code. Mức rủi ro của thao tác mới quyết định.
D sai vì số tool đang có không liên quan tới quyết định cưỡng chế. Agent có 2 tool hay 20 tool thì thao tác rủi ro cao vẫn cần cưỡng chế bằng code.