Tool Calling hoạt động như thế nào? #23

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Tool calling là cơ chế để model đề xuất một công cụ cùng các tham số có cấu trúc. Model không tự chạy công cụ. Ứng dụng nhận đề xuất, kiểm tên tool, dữ liệu và quyền, thực thi bằng code, rồi gửi kết quả về để model trả lời hoặc đề xuất bước tiếp theo.

Đọc xong, bạn sẽ hiểu:

• Model làm phần nào và ứng dụng làm phần nào trong một tool call.
• Sáu chặng từ yêu cầu tới câu trả lời cuối.
• Cách kiểm một tool read-only trước khi cho agent dùng.

1. Tool Calling là gì? Model không tự bấm nút

Trong bài trước về kiến trúc một AI agent #22, model chỉ là một khối trong hệ. Khi agent cần tra đơn, xem thời tiết hay đọc file, model không tự mở database hoặc chạm vào máy chủ. Model tạo một đề xuất có cấu trúc để phần mềm xung quanh xử lý.

Hãy hình dung quầy kho. Nhân viên tiếp nhận viết phiếu: “Lấy hồ sơ A-102”. Tờ phiếu ghi đúng tên việc và mã hồ sơ, nhưng tờ phiếu không tự mở cửa kho. Thủ kho còn phải kiểm người gửi có quyền hay không, mã có hợp lệ không, rồi mới lấy hồ sơ và ghi biên nhận.

Model viết “phiếu gọi tool”; ứng dụng đóng vai thủ kho. Ranh giới này quan trọng vì model có thể chọn nhầm tool hoặc điền sai dữ liệu.

a. Tool không nhất thiết là một API trên mạng

Tool có thể là hàm tính toán, lệnh đọc file, truy vấn database, dịch vụ thời tiết hoặc API gửi email. Điểm chung là tool cung cấp một khả năng nằm ngoài việc model sinh chữ.

Ví dụ, get_weather lấy thời tiết mới, read_order_demo đọc đơn giả, còn send_email tạo tác động. Ba tool không nên có cùng mức quyền.

b. Function Calling là một loại Tool Calling

Function calling thường chỉ tool được mô tả như một hàm với input có cấu trúc. Tool calling rộng hơn, có thể gồm tìm web, chạy code hoặc kết nối MCP — một chuẩn nối ứng dụng với tool bên ngoài.

Bài này tập trung vào flow chung. Bài #24 sẽ đi sâu cách định nghĩa function. Ở đây chỉ cần nhớ: model tạo đề xuất; code mới là phần thực thi.

2. Một vòng Tool Calling đi qua sáu chặng

Một vòng gọi công cụ đi qua sáu chặng:

1. Ứng dụng gửi yêu cầu và danh sách công cụ cho AI.
2. AI đề xuất công cụ cần gọi cùng các tham số.
3. Ứng dụng kiểm tên công cụ, tham số và quyền.
4. Bộ thực thi chạy công cụ.
5. Ứng dụng gắn kết quả với mã lần gọi, tức mã nối đúng yêu cầu với đúng kết quả.
6. AI dùng kết quả để trả lời hoặc đề xuất vòng mới.

Sáu chặng này nối tiếp nhau; AI không tự chạy công cụ nếu ứng dụng chưa kiểm và thực thi. OpenAI Function Calling

Hình 1 — Tool calling là vòng bàn giao giữa model và ứng dụng; phiếu gọi tool không tự thực thi.

a. Chặng 1-2: mô tả tool rồi gửi yêu cầu

Tool definition là bản mô tả tên tool, mục đích và input. Ví dụ, read_order_demo nhận một trường order_id. Mô tả phải nói tool chỉ đọc dữ liệu demo và không hoàn tiền.

JSON Schema là bộ quy tắc mô tả hình dạng dữ liệu. Schema có thể yêu cầu order_id là chuỗi và không cho phép trường lạ. Schema giống mẫu phiếu có ô bắt buộc: người điền vẫn có thể ghi sai mã, nhưng không thể tùy tiện thêm ô “xóa đơn”.

Ứng dụng gửi yêu cầu cùng những tool model được phép cân nhắc. Danh sách càng rộng, model càng khó chọn và phạm vi rủi ro càng lớn.

b. Chặng 3: model tạo tool call

Model có thể trả lời bằng văn bản hoặc tạo một tool call. Argument là giá trị cụ thể model điền vào input. Với câu “Tra đơn A-102”, đề xuất có thể gồm tool read_order_demo và argument order_id: A-102.

Một call còn có call ID, tức mã nối yêu cầu gọi tool với đúng kết quả của nó. Nếu model gọi hai tool, call ID giúp ứng dụng không gắn kết quả thời tiết vào call tra đơn.

c. Chặng 4-6: kiểm, chạy và trả kết quả

Executor là code phía ứng dụng nhận call. Executor kiểm tên tool có trong allowlist — danh sách được phép — cùng argument, quyền và bước xác nhận. Chỉ sau đó executor mới chạy tool.

Tool result là dữ liệu hoặc lỗi được gửi lại model. Anthropic cũng tách rõ client tool chạy trong ứng dụng: model trả tool_use, code chạy thao tác rồi gửi tool_result. Anthropic Tool Use

Model đọc result để trả lời hoặc đề xuất call tiếp. Harness phải giới hạn số vòng; gọi tới khi may ra đúng không phải cách xử lý lỗi.

3. Case tra đơn hàng giả: từ câu hỏi đến kết quả

Người dùng viết: “Đơn A-102 đến đâu rồi?” Ứng dụng chỉ cung cấp tool read-only read_order_demo. Model tạo call giả:

{
  "call_id": "call_demo_01",
  "name": "read_order_demo",
  "arguments": { "order_id": "A-102" }
}

Đây mới là phiếu đề xuất. Executor kiểm name, định dạng A-102 và quyền read-only. Nếu pass, tool demo trả:

{
  "call_id": "call_demo_01",
  "status": "packed",
  "updated_at": "2026-07-22T09:00:00Z"
}

Hình 2 — Call ID nối đúng đề xuất với đúng result, còn executor giữ quyền chạy tool.

Model có thể nói: “Dữ liệu demo cho thấy đơn A-102 đã đóng gói lúc 09:00.” Result không có ngày giao, nên model không được thêm “chắc chắn giao chiều nay”.

Dữ liệu demo cho thấy đơn A-102 được cập nhật trạng thái “đã đóng gói” lúc 09:00 UTC ngày 22/07/2026.

a. Thiếu mã thì hỏi, không đoán

Nếu người dùng chỉ hỏi “Đơn của tôi đâu rồi?”, model nên hỏi mã đơn. Tạo order_id ngẫu nhiên rồi gọi tool làm result có vẻ thật nhưng thuộc đơn khác.

Hỏi lại không phải thất bại. Đó là nhánh đúng khi argument bắt buộc còn thiếu. Một form ngoài đời cũng không xử lý được phiếu giao hàng nếu thiếu địa chỉ.

b. Tool gây tác động cần thêm cổng

Giả sử người dùng viết “Hoàn tiền đơn A-102”. Model có thể nhận ra ý định, nhưng không nên được tự gọi tool hoàn tiền. Ứng dụng có thể chỉ cho xem trước số tiền, sau đó yêu cầu người có quyền xác nhận.

Tool gửi email, xóa file hay chuyển tiền cần phạm vi hẹp, preview, xác nhận và log. Việc khó đảo ngược phải qua người duyệt.

4. Tool call có cấu trúc vẫn có thể sai

JSON đúng cú pháp chưa chứng minh hành động đúng. Model có thể chọn nhầm tool, điền mã sai hoặc lặp call sau timeout. Executor phải xem cả call lẫn result là dữ liệu chưa tin cậy.

Hình 3 — Schema giữ đúng hình dạng; quyền, chống gọi trùng và xác nhận mới giữ flow trong ranh giới.

a. Schema chỉ chặn một lớp lỗi

Strict mode giúp call bám schema; OpenAI yêu cầu object không nhận thuộc tính ngoài và các field theo quy tắc required/nullable. OpenAI Function Calling

Nhưng order_id: A-999 vẫn có thể đúng kiểu chuỗi dù mã không tồn tại. Sau kiểm schema còn cần kiểm nghiệp vụ: mã có trong kho demo không và user có được xem đơn đó không.

b. Timeout không cho phép gọi vô hạn

Ứng dụng tạo một idempotency key cho hành động ban đầu và dùng lại đúng key khi retry. Server lưu trạng thái/kết quả của key; nếu nhận lại cùng key, nó trả kết quả cũ thay vì thực hiện tác động lần hai.

Tool có thể timeout, tức quá thời gian chờ, sau khi đã chạy nhưng trước khi trả result. Gọi lại tool gửi email có thể tạo hai thư. Idempotency giúp cùng yêu cầu chạy lặp không tạo tác động trùng.

Tool ghi dữ liệu cần idempotency key, giới hạn retry và trạng thái rõ. Không biết call trước đã chạy chưa thì dừng để kiểm tra.

c. Khi nào không nên dùng Tool Calling?

Nếu flow cố định và input đã có cấu trúc, code thường tốt hơn. Tính tổng hóa đơn hay đổi định dạng ngày không cần model chọn tool.

Tool calling có ích khi ngôn ngữ người dùng đa dạng và model cần chọn giữa vài khả năng rõ. Đừng dùng model để thay một câu if/else đã đủ chính xác.

5. Bài tập 15 phút: lần theo một tool call read-only

Mở giấy, Markdown hoặc JSON Formatter local. Không dùng API key hay dữ liệu thật. Chép call_demo_01 và kiểm từng dòng trước executor.

a. Mẫu đối chiếu đã điền

b. Checklist trước khi bật tool

1. Tool có tên và mô tả đủ rõ để người mới chọn đúng không?
2. Schema có chặn field lạ và kiểm đủ argument bắt buộc không?
3. Executor có allowlist và quyền tối thiểu không?
4. Tool gây tác động có preview, xác nhận và idempotency không?
5. Lỗi có điểm dừng, retry giới hạn và log không chứa secret không?

Đổi order_id thành rỗng. Kết luận phải là “hỏi lại”, không phải “chạy tool”. Sau đó đổi tool thành refund_order; kết luận phải là “không có trong allowlist” hoặc “chờ người duyệt”. Nếu bảng vẫn cho chạy tự động, cổng kiểm đang quá rộng.

6. Tổng kết: cho model đề xuất, cho code kiểm và chạy

Tool calling biến yêu cầu tự nhiên thành một đề xuất có cấu trúc, nhưng quyền thực thi vẫn thuộc ứng dụng. Flow đáng tin không dừng ở JSON đẹp; nó cần schema, business validation, quyền tối thiểu, call/result đúng cặp và điểm dừng rõ.

a. Năm ý chính

• Tool calling để model đề xuất tool và argument, không để model tự chạy code.
• Tool definition cùng JSON Schema giúp model tạo call đúng hình dạng hơn.
• Executor phải kiểm allowlist, dữ liệu và quyền trước khi chạy tool.
• Tool result cần gắn đúng call ID và vẫn được xem là dữ liệu chưa tin cậy.
• Tool gây tác động cần xác nhận, chống chạy trùng và điểm dừng rõ.

b. Câu hỏi tự kiểm tra

• Model và executor khác nhau ở trách nhiệm nào?
• JSON Schema có đảm bảo order_id tồn tại không?
• Vì sao call ID cần đi cùng tool result?
• Khi nào nên dùng hàm thường thay vì tool calling?

c. Gợi ý đáp án

Xem gợi ý câu 1

Model đề xuất tool call; executor kiểm quyền, dữ liệu và chạy code. → xem mục 2.

Xem gợi ý câu 2

Không. Schema chỉ kiểm hình dạng; business validation mới kiểm mã có thật và được phép truy cập. → xem mục 4.

Xem gợi ý câu 3

Call ID nối đúng kết quả với đúng đề xuất, nhất là khi có nhiều call. → xem mục 2 và 3.

Xem gợi ý câu 4

Dùng hàm thường khi flow cố định, input có cấu trúc và không cần model định tuyến. → xem mục 4.

d. Thuật ngữ cần nhớ

e. Nguồn tham khảo

• OpenAI Function Calling
• Anthropic Tool Use
• MCP Architecture

Xem lại Kiến trúc một AI Agent #22 để đặt tool calling vào đúng khối. Bài tiếp theo: Function Calling #24.

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi hệ thống có tool đều cần kiểm quyền và dữ liệu trước khi thực thi.