Tool Calling

Level: L7 — MCP, API & Connectors (Bài 5/11 theo thứ tự sản xuất — · Đối tượng: Người đã học bài 65-66 (cơ chế API/Webhook giữa 2 hệ

1. Mục tiêu học tập

Sau bài này, bạn có thể:

Giải thích vì sao 1 mô hình ngôn ngữ (LLM) không thể tự thực hiện 1 hành động thật (gửi email, đọc database) — nó chỉ có thể sinh ra văn bản, và cần 1 cơ chế cầu nối.
Mô tả đúng vòng lặp 5 bước của tool calling: định nghĩa tool → model quyết định gọi → model xuất ra lời gọi có cấu trúc → ứng dụng thực thi → kết quả trả về cho model.
Phân biệt: model quyết định gọi gì, nhưng ứng dụng của bạn mới là bên thực sự thực thi hành động — model không bao giờ tự chạy code.
Nhận diện đây là mẫu hình chung qua nhiều nhà cung cấp LLM khác nhau, không phải phát minh riêng của 1 hãng.

2. Khái niệm cốt lõi

Bước 1 — Concept (vấn đề cần giải quyết, trước khi nói tới bất kỳ cơ chế cụ thể nào): 1 LLM về bản chất chỉ làm 1 việc — nhận văn bản đầu vào, sinh ra văn bản đầu ra. Nó không có tay để tự gửi 1 email, tự đọc 1 database, hay tự gọi 1 API (bài 65). Vậy làm sao AI “làm được việc” thay vì chỉ “nói về việc”? Đây chính là bài toán Tool Calling giải quyết.

Bước 2 — Open standard/mẫu hình chung (không gắn 1 hãng — đối chiếu 2 vendor lớn để xác nhận đây là mẫu hình phổ quát, không phải đặc thù 1 công ty): cả Anthropic lẫn OpenAI đều mô tả cùng 1 hình dạng vòng lặp, chỉ khác thuật ngữ cụ thể:

Bước	Anthropic gọi	OpenAI gọi	Bản chất chung
1	Gửi `tools` + tin nhắn	Định nghĩa và gửi `tools`	Mô tả cho model những “hàm” nào nó có thể gọi, và hình dạng tham số của từng hàm
2	`stop_reason: "tool_use"` + khối `tool_use`	Model tạo “tool call” (kèm call ID, tên, tham số JSON)	Model quyết định cần gọi hàm nào, xuất ra 1 lời gọi có cấu trúc (không phải văn xuôi)
3	Ứng dụng thực thi, tạo `tool_result`	Ứng dụng thực thi cục bộ	Model KHÔNG tự chạy code — ứng dụng của bạn (hoặc hạ tầng nhà cung cấp, với 1 số tool đặc biệt) mới là bên thực thi
4	Gửi lại `tool_result` trong request mới	Gửi lại tin nhắn “tool” kèm kết quả	Kết quả thực thi được đưa trở lại vào ngữ cảnh hội thoại của model
5	Lặp lại nếu vẫn `"tool_use"`	Model trả lời cuối hoặc gọi thêm tool	Model tiếp tục dựa trên kết quả vừa nhận — có thể gọi thêm tool khác, hoặc trả lời cuối cùng

Nguyên tắc quan trọng nhất bài này, trích gần nguyên văn Anthropic: “Tool use is a contract between your application and the model… The model never executes anything on its own. It emits a structured request, your code… runs the operation, and the result flows back into the conversation” [S105]. Đây là ranh giới trách nhiệm cốt lõi: model quyết định (“nên gọi gì”), ứng dụng thực thi (“thực sự làm gì”) — không bao giờ lẫn lộn 2 vai trò này.

3. Tại sao nội dung này quan trọng

Đây là mảnh ghép còn thiếu để hiểu MCP (bài 68-69) có ý nghĩa gì — MCP không phát minh ra cơ chế tool calling, nó chuẩn hóa cách khai báo tool giữa nhiều hệ thống khác nhau, dựa trên đúng cơ chế bạn học ở đây. Không hiểu tool calling trần trụi trước, MCP sẽ chỉ là 1 mớ thuật ngữ trừu tượng khó neo vào đâu.

4. Cơ chế hoạt động

Bước 3 — Architecture (cấu trúc 1 lời gọi tool, vẫn ở mức khái niệm phổ quát):

Định nghĩa tool (schema): tên, mô tả (để model hiểu khi nào nên dùng), và cấu trúc tham số đầu vào (giống 1 hợp đồng: “hàm này tên gì, cần đưa vào những gì”).
Lời gọi (call): khi model quyết định dùng 1 tool, nó xuất ra 1 khối dữ liệu có cấu trúc (không phải câu văn tự nhiên) — gồm tên tool và giá trị cụ thể cho từng tham số.
Kết quả (result): sau khi ứng dụng thực thi xong, kết quả được gửi lại cho model dưới dạng dữ liệu có cấu trúc hoặc văn bản, gắn với đúng lời gọi ban đầu (qua ID).

Bước 4 — Real implementation (vòng lặp đầy đủ, tổng hợp từ cả 2 nguồn, diễn đạt trung lập):

Ứng dụng gửi cho model: danh sách tool khả dụng (schema) + yêu cầu người dùng.
Model đọc yêu cầu, đối chiếu với mô tả từng tool, quyết định có cần gọi tool không (và gọi cái nào).
Nếu cần, model xuất ra 1 lời gọi có cấu trúc (không tự thực thi).
Ứng dụng nhận lời gọi, trích tham số, thực thi thật (gọi API thật — bài 65, đọc database thật, v.v.).
Ứng dụng gửi kết quả trở lại cho model.
Model đọc kết quả, quyết định: trả lời cuối cùng, hay cần gọi thêm 1 tool khác — quay lại bước 2.

Khi nào model quyết định gọi tool (không phải lúc nào cũng gọi) [S105]: model gọi tool khi yêu cầu khớp với năng lực đã mô tả và câu trả lời chưa có sẵn trong ngữ cảnh; trả lời trực tiếp cho kiến thức ổn định, tác vụ sáng tạo, hội thoại thông thường. Hành vi này điều chỉnh được qua hướng dẫn (ví dụ: yêu cầu rõ “luôn tra cứu trước khi trả lời” tăng xu hướng gọi tool).

5. Mental model

Tiếp nối ẩn dụ mạng lưới nhà cung cấp: nếu bài 65 dạy “tờ đơn đặt hàng” và bài 66 dạy “nhà cung cấp chủ động gọi lại,” bài này dạy ai là người viết tờ đơn và ai là người thực sự giao hàng. Model giống 1 trợ lý văn phòng rất giỏi đọc yêu cầu — nó biết khi nào cần điền 1 tờ đơn đặt hàng và điền đúng thông tin gì, nhưng chính nó không có chân để đi giao hàng — nó đưa tờ đơn đã điền cho bạn (ứng dụng), bạn là người thực sự đi thực hiện, rồi báo lại kết quả để trợ lý viết tiếp phần còn lại của công việc.

6. Hướng dẫn từng bước

Checklist “đọc hiểu 1 vòng lặp tool calling” (tổng hợp của người viết, áp dụng cho bất kỳ vendor LLM nào):

Tool nào đang được khai báo cho model, mô tả (description) có đủ rõ để model hiểu khi nào nên dùng không?
Phản hồi của model có phải “lời gọi có cấu trúc” hay chỉ là văn bản thường? (Nếu model chỉ nói nó sẽ làm gì mà không xuất ra lời gọi đúng định dạng, ứng dụng sẽ không thực thi được gì.)
Ai chịu trách nhiệm thực thi lời gọi đó — code của bạn, hay hạ tầng nhà cung cấp?
Kết quả thực thi có được đưa đúng trở lại vào ngữ cảnh hội thoại không, để model “biết” điều vừa xảy ra?

7. Ví dụ thực tế

Bước 5 — Vendor example (đặt sau khi cơ chế chung đã vững, đúng thứ tự đã khóa):

Anthropic [S105]: khi Claude quyết định gọi 1 tool do bạn định nghĩa, response chứa stop_reason: "tool_use" và 1 khối tool_use gồm tên tool

tham số dạng JSON. Ứng dụng thực thi, gửi lại 1 khối tool_result trong request tiếp theo.

OpenAI [S106]: khi model quyết định gọi 1 function, nó xuất ra 1 “tool call” kèm call ID, tên function, và tham số mã hóa JSON. Ứng dụng thực thi, gửi lại 1 tin nhắn “tool” chứa call ID và kết quả.

Điểm chung quan trọng nhất: cả 2 đều dùng JSON để mô tả tham số lời gọi và kết quả — không phải trùng hợp, mà vì cấu trúc dữ liệu rõ ràng, máy phân tích được là điều kiện bắt buộc để ứng dụng có thể tự động thực thi mà không cần “đoán ý” model qua văn xuôi.

8. Prompt/template/workflow

Khung mô tả 1 tool cho model (tái sử dụng, dạng khái niệm — không phải code cụ thể):

Tên tool: [tên ngắn gọn, rõ chức năng]
Mô tả: [khi nào model nên dùng tool này — càng cụ thể càng giúp model
quyết định đúng]
Tham số cần: [tên tham số] — [kiểu dữ liệu] — [tham số này dùng để làm gì]

9. Visual hoặc diagram cần thiết

Hình 7.3 — Tool Calling: vòng lặp 6 bước, ranh giới trách nhiệm Model vs Ứng dụng.

10. Bài tập thực hành

Chọn 1 tác vụ cụ thể cho dự án Notes App (dự án tích lũy) mà AI cần “làm được việc” thay vì chỉ trả lời văn bản (ví dụ: “tạo 1 ghi chú mới với nội dung X”).
Viết ra khung mô tả tool (mục 8) cho tác vụ đó.
Vẽ lại vòng lặp 6 bước (mục 4) áp dụng cho đúng ví dụ của bạn — model quyết định gì, ứng dụng thực thi gì, kết quả trả về ra sao.
Giải thích: nếu model “nói” nó đã tạo ghi chú nhưng không xuất ra lời gọi có cấu trúc đúng, điều gì thực sự xảy ra? (Gợi ý: không có gì cả — đây là lỗi phổ biến, xem mục 12.)

11. Checklist

Giải thích được vì sao LLM cần 1 cơ chế cầu nối để "làm được việc."
Mô tả đúng vòng lặp: định nghĩa tool → model quyết định → lời gọi có cấu trúc → ứng dụng thực thi → kết quả trả về → model tiếp tục.
Phân biệt rõ: model quyết định, ứng dụng thực thi — không lẫn lộn.
Nhận diện đây là mẫu hình chung (đối chiếu Anthropic/OpenAI), không đặc thù 1 hãng.
Không nhầm bài này với MCP (bài 68) hay kiến trúc agent (Level 8).

12. Lỗi thường gặp

(Suy luận từ nguyên tắc [S105, S106], không phải quan sát độc lập.)

Tin rằng model “tự làm” hành động — model chỉ quyết định và mô tả hành động; luôn có 1 lớp thực thi (ứng dụng của bạn, hoặc hạ tầng nhà cung cấp) đứng giữa.
Mô tả tool mơ hồ — model khó quyết định đúng khi nào nên gọi tool nào nếu description không đủ rõ (nguyên tắc thiết kế tool chất lượng cao đã học sâu ở L8 Ch03).
Không đưa kết quả trở lại đúng vòng lặp — model sẽ “quên” đã gọi tool, có thể gọi lại hoặc trả lời sai vì thiếu ngữ cảnh.
Nhầm tool calling với MCP — tool calling là cơ chế; MCP là 1 chuẩn đóng gói cách khai báo cơ chế đó giữa nhiều hệ thống (đào sâu bài 68).

13. Giới hạn & khi nào KHÔNG nên áp dụng

Bài này không dạy MCP — nếu bạn cần biết cách chuẩn hóa việc khai báo tool giữa nhiều hệ thống/nhà cung cấp, đó là bài 68-69.
Bài này không dạy thiết kế tool chất lượng cao (mô tả rõ ràng, ví dụ edge case, nguyên tắc poka-yoke) — đã học đầy đủ ở Level 8 (Ch03, Agent-Computer Interface).
Bài này không dạy cách agent tự điều phối nhiều tool/nhiều bước — đó là phạm vi Level 8 (Ch01-02, orchestration pattern).
Không phải mọi tác vụ cần tool — theo nguyên tắc chính thức [S105]: không cần tool cho kiến thức ổn định, tác vụ sáng tạo, hoặc khi độ trễ gọi tool lớn hơn nhiều giá trị nhận lại.

14. An toàn & quản trị (Safety/Governance)

Nguyên tắc “model quyết định, ứng dụng thực thi” (mục 2) chính là ranh giới an toàn quan trọng nhất của cơ chế này: vì model không tự chạy code, ứng dụng của bạn luôn có 1 điểm kiểm soát trước khi bất kỳ hành động thật nào xảy ra (ví dụ: kiểm tra tham số hợp lệ trước khi thực thi, từ chối thực thi nếu tham số bất thường). Đây là lý do thiết kế tool tốt (L8 Ch03) và giới hạn quyền tool được phép làm (đào sâu bài 74-75) đều quan trọng — lỗ hổng không nằm ở việc model “muốn” làm gì, mà ở việc ứng dụng có kiểm tra trước khi thực thi hay không.

15. Best practices

Viết mô tả tool đủ rõ để model quyết định đúng khi nào nên dùng — không rõ ràng thì model dễ gọi sai hoặc không gọi khi cần.
Luôn kiểm tra tham số model gửi lên trước khi thực thi thật — không tin tưởng mù quáng lời gọi chỉ vì nó đến từ model.
Đảm bảo kết quả thực thi luôn được đưa trở lại đúng vòng lặp, gắn đúng ID lời gọi ban đầu.
Với tác vụ có tác dụng phụ thật (ghi dữ liệu, gửi email), cân nhắc thêm 1 bước xác nhận con người trước khi thực thi (đào sâu ở Level 8).

16. Nội dung nâng cao (không bắt buộc)

Một số hệ thống LLM hỗ trợ gọi nhiều tool song song trong cùng 1 lượt (model xuất ra nhiều lời gọi cùng lúc thay vì tuần tự) — cả Anthropic (“một hoặc nhiều khối tool_use”) và OpenAI (“không, một, hoặc nhiều tool call”) đều hỗ trợ điều này. Đây là tối ưu hiệu năng (giảm số vòng lặp cần thiết), không đổi bản chất cơ chế đã học ở bài này — chỉ là nhiều lời gọi được xử lý trong cùng 1 vòng thay vì 1.

17. Nguồn tham khảo

[S105] Tool Use / How Tool Use Works, Anthropic — platform.claude.com/docs — vòng lặp 5 bước, ranh giới trách nhiệm model/ứng dụng, khi nào nên/không nên dùng tool.
[S106] Function Calling, OpenAI — developers.openai.com/api/docs — vòng lặp 5 bước (thuật ngữ khác, cùng bản chất), thành phần schema.
Dẫn chiếu (không trích dẫn mới): bài 65 (API, ví dụ hành động thực thi); bài 68 (MCP, chuẩn hóa cách khai báo tool); L8 Ch03 (thiết kế tool chất lượng cao, ACI).

18. Ngày kiểm chứng

Nội dung kiểm chứng qua nguồn Tier 1 (S105, S106) ngày 2026-07-13. Cơ chế vòng lặp (mục 2, 4) là mẫu hình nền tảng ổn định qua nhiều vendor; chi tiết định dạng cụ thể (tên trường JSON, tên tham số API) có thể đổi theo phiên bản API — bài này cố ý không đi sâu chi tiết implementation để giữ nội dung bền theo thời gian.