Tool Calling là gì? Cách AI Agent sử dụng công cụ

Tool Calling là chủ đề trọng tâm của bài viết này. Một LLM có thể giải thích SQL nhưng không tự truy vấn Database. Nó có thể đề xuất gửi email nhưng không tự gửi nếu ứng dụng không cung cấp công cụ. Tool Calling là cơ chế nối khả năng hiểu ngôn ngữ và reasoning của Model với các hàm được thực thi trong hệ thống phần mềm.

Đây là kỹ năng cốt lõi của Agentic AI Engineer. Khi Tool Calling được thiết kế tốt, Agent có thể dùng dữ liệu thật và thực hiện công việc trong phạm vi cho phép. Khi thiết kế kém, Agent có thể chọn nhầm Tool, tạo tham số sai, lặp hành động hoặc truy cập vượt quyền.

Mục lục

Tool Calling là gì?
Model không trực tiếp chạy hàm
Vòng đời một Tool Call
Thiết kế Tool Schema
Đặt tên và viết Description
Validation nhiều lớp
Authorization và Identity
Read Tool và Write Tool
Tool Result có cấu trúc
Error Handling và Retry
Idempotency
Parallel và Sequential Tool Calls
Dynamic Tool Selection
Ví dụ Agent truy vấn doanh thu
Evaluation Tool Calling
Checklist production
Kết luận
Tài liệu tham khảo

Tool Calling là gì?

Tool Calling, đôi khi được gọi là Function Calling, cho phép Model tạo yêu cầu có cấu trúc để ứng dụng gọi một hàm. Tool có thể là hàm Python, REST API, truy vấn Database, Search Service, Workflow hoặc một Adapter tới SaaS.

Model được cung cấp danh sách Tool cùng schema. Khi nhận nhiệm vụ, nó có thể trả câu trả lời trực tiếp hoặc đề nghị gọi Tool. Application kiểm tra yêu cầu, thực thi hàm rồi gửi Tool Result trở lại Model. Model dùng kết quả để trả lời hoặc chọn bước tiếp theo.

Model không trực tiếp chạy hàm

Điểm quan trọng nhất là Model chỉ tạo dữ liệu thể hiện ý định. Nếu Model sinh tên get_order và tham số {"order_id":"A102"}, chưa có Database nào được truy cập. Runtime quyết định có cho phép lời gọi đó hay không.

Sự phân tách này tạo ranh giới an toàn. Model xử lý ngôn ngữ và lựa chọn. Runtime xử lý Authentication, Authorization, Validation, Timeout, Retry và Audit. Không nên viết một hàm chung nhận bất kỳ SQL hoặc URL nào từ Model rồi thực thi trực tiếp.

Vòng đời một Tool Call

Ứng dụng nhận User Request và xác thực danh tính.
Orchestrator chọn Tools phù hợp rồi gửi schema cùng Context cho Model.
Model chọn Tool và tạo Arguments.
Runtime parse và kiểm tra schema.
Policy Layer kiểm tra quyền và quy tắc nghiệp vụ.
Tool Executor gọi hệ thống thật.
Kết quả được chuẩn hóa và ghi Trace.
Tool Result được đưa lại cho Model.
Model trả Final Answer hoặc tạo Tool Call mới.

Mỗi bước có Failure Mode riêng. Parse có thể lỗi định dạng. Validation có thể phát hiện ngày sai. Authorization có thể từ chối dữ liệu. API bên ngoài có thể timeout. Model có thể hiểu sai Tool Result. Trace phải giúp xác định lỗi xảy ra ở đâu.

Thiết kế Tool Schema

Schema mô tả dữ liệu Model phải tạo. Một schema tốt dùng kiểu cụ thể, Enum khi có tập lựa chọn giới hạn, trường Required hợp lý và Description giải thích ý nghĩa nghiệp vụ.

{
  "name": "get_revenue",
  "description": "Lấy doanh thu đã ghi nhận trong khoảng ngày, theo múi giờ Việt Nam",
  "parameters": {
    "type": "object",
    "properties": {
      "start_date": {
        "type": "string",
        "format": "date",
        "description": "Ngày bắt đầu, định dạng YYYY-MM-DD"
      },
      "end_date": {
        "type": "string",
        "format": "date"
      },
      "group_by": {
        "type": "string",
        "enum": ["day", "branch", "category"]
      }
    },
    "required": ["start_date", "end_date", "group_by"],
    "additionalProperties": false
  }
}

Không nên tạo tham số tên data hoặc options nếu Model phải đoán nội dung. Cũng không nên đưa quá nhiều tham số tùy chọn vào một Tool. Nếu hai chức năng có mục đích và quyền khác nhau, tách thành hai Tools thường rõ hơn.

Đặt tên và viết Description

Tên Tool nên bắt đầu bằng động từ và mô tả một hành động rõ ràng, chẳng hạn search_contracts, get_customer_profile hoặc create_support_ticket. Những tên chung như process khiến Model khó lựa chọn.

Description cần nói Tool làm gì, khi nào nên dùng, khi nào không nên dùng, dữ liệu trả về và giới hạn quan trọng. Nếu có hai Tools gần giống, Description phải giải thích sự khác biệt. Ví dụ, search_orders tìm nhiều đơn theo điều kiện, còn get_order_by_id lấy một đơn chính xác.

Tool Description là một phần của Context nên cũng tạo Token Cost. Mục tiêu là đầy đủ nhưng không dài dòng. Các ví dụ nên tập trung vào tình huống dễ nhầm thay vì lặp lại schema.

Validation và phân quyền khi gọi công cụ

Validation nhiều lớp

Lớp đầu kiểm tra cú pháp và kiểu dữ liệu theo JSON Schema. Lớp thứ hai kiểm tra quy tắc nghiệp vụ, chẳng hạn ngày bắt đầu không được sau ngày kết thúc và khoảng truy vấn không vượt 90 ngày. Lớp thứ ba kiểm tra quyền. Lớp cuối có thể áp dụng Policy về rủi ro và Approval.

def validate_revenue_request(args, user):
    validate_json_schema(args)

    if args["start_date"] > args["end_date"]:
        raise ValidationError("start_date must not exceed end_date")

    if days_between(args) > 90:
        raise PolicyError("date range exceeds 90 days")

    if not user.can_read_sales:
        raise PermissionError("sales access denied")

Thông báo lỗi trả về cho Model nên có cấu trúc và không làm lộ dữ liệu nhạy cảm. Lỗi có thể sửa, như ngày không hợp lệ, cho phép Model tạo Arguments mới. Lỗi Permission không nên được retry bằng biến thể khác.

Authorization và Identity

Agent cần hành động thay mặt một Principal cụ thể, thường là người dùng hoặc Service Account có phạm vi hẹp. Tool Layer phải nhận Identity đã được xác thực từ Application, không nhận user_id do Model tự tạo.

Nếu Sales chỉ được xem khu vực phía Nam, Data Tool phải tự áp dụng Filter tương ứng. Không nên trả toàn bộ dữ liệu rồi yêu cầu Model chỉ hiển thị phần được phép. Dữ liệu không có quyền không được đi vào Context.

Quyền cũng cần xét theo hành động. Người dùng có thể đọc hóa đơn nhưng không được sửa. Có thể tạo Draft email nhưng không được gửi. Tool Catalog nên chỉ cung cấp Tools mà Principal hiện tại có thể sử dụng.

Read Tool và Write Tool

Read Tool quan sát trạng thái mà không thay đổi hệ thống, ví dụ lấy báo cáo hoặc tìm tài liệu. Write Tool tạo tác động như cập nhật đơn hàng, gửi tin nhắn hoặc xóa bản ghi. Phân loại này giúp xác định Approval, Logging và Idempotency.

Write Tool nên có tên thể hiện rõ hành động. Không nên để manage_customer vừa đọc vừa cập nhật. Với hành động quan trọng, Agent nên tạo Proposal trước. Người dùng xem Target, dữ liệu thay đổi, lý do và tác động rồi mới phê duyệt.

Tool Result có cấu trúc

Tool Result cần phục vụ cả Model và hệ thống quan sát. Một cấu trúc tốt có status, data, metadata và error. Metadata có thể chứa Source, Freshness, Unit, Pagination và Request ID.

{
  "status": "success",
  "data": {"revenue": 520000000},
  "metadata": {
    "currency": "VND",
    "timezone": "Asia/Ho_Chi_Minh",
    "freshness": "2026-09-15T08:00:00+07:00",
    "request_id": "req_82931"
  },
  "error": null
}

Kết quả quá lớn nên được tổng hợp, phân trang hoặc lưu ở Object Storage rồi trả Reference. Không đưa hàng nghìn dòng vào Context nếu Model chỉ cần ba chỉ số. Tool nên trả đủ bằng chứng để kết luận nhưng không làm Context trở thành Data Warehouse.

Error Handling và Retry

Lỗi cần được phân loại. Validation Error yêu cầu sửa Arguments. Permission Error phải dừng. Rate Limit có thể đợi và retry. Timeout có thể ở trạng thái không chắc chắn, đặc biệt với Write Tool. Business Error như "đơn hàng đã hủy" cần được trả về để Model giải thích.

Retry nên có giới hạn, Exponential Backoff và Jitter. Không để Model tự gọi lại vô hạn. Circuit Breaker giúp ngừng gọi một dịch vụ đang lỗi hàng loạt. Timeout phải khác nhau theo Tool thay vì một giá trị chung.

Idempotency

Idempotency bảo đảm cùng một yêu cầu được gửi lại không tạo tác động trùng. Đây là yêu cầu quan trọng với thanh toán, tạo Ticket, gửi thông báo và cập nhật bản ghi.

Application tạo Idempotency Key từ Task ID và Action ID rồi truyền cho Tool. Service lưu kết quả lần đầu. Nếu nhận lại cùng Key, Service trả kết quả cũ thay vì thực hiện lại. Không nên yêu cầu Model tự phát minh Key.

Parallel và Sequential Tool Calls

Hai Tool Calls độc lập có thể chạy song song để giảm latency, chẳng hạn lấy doanh thu và tồn kho cho cùng khoảng ngày. Nếu kết quả bước trước quyết định tham số bước sau, chúng phải chạy tuần tự.

Parallel Execution cần kiểm soát Rate Limit, số Worker và cách tổng hợp lỗi. Nếu một trong ba Tools thất bại, Orchestrator phải biết nhiệm vụ có thể tiếp tục với dữ liệu một phần hay cần dừng.

Dynamic Tool Selection

Khi hệ thống có hàng trăm Tools, đưa toàn bộ schema vào Context làm tăng Token và khiến Model khó chọn. Dynamic Tool Selection dùng Intent, Role và Metadata để lấy một tập Tools nhỏ phù hợp với nhiệm vụ.

Tool Registry có thể lưu Domain, Risk Level, Required Permission, Input Schema và Version. Trước mỗi Model Call, Orchestrator lọc theo quyền rồi chọn Tools liên quan. Tool Retrieval cũng cần Evaluation để tránh bỏ sót công cụ cần thiết.

Ví dụ Agent truy vấn doanh thu

Người dùng hỏi "Doanh thu tuần trước giảm ở đâu?". Orchestrator xác định User có quyền xem ba chi nhánh. Model gọi get_revenue với khoảng ngày đã chuẩn hóa và group_by là branch. Tool Layer tự thêm danh sách Branch được phép.

Kết quả cho thấy Q7 giảm mạnh. Model gọi tiếp Tool theo Category nhưng chỉ cho Q7. Sau đó Model trả ba Finding, mỗi Finding liên kết với Request ID và thời gian dữ liệu. Nếu người dùng yêu cầu tạo Ticket, hệ thống chuyển sang Approval vì đây là Write Action.

Evaluation Tool Calling

Evaluation cần đo nhiều tầng: Tool Selection Accuracy, Argument Accuracy, Permission Compliance, Execution Success, Task Completion, số Tool Calls, latency và cost. Exact Match không luôn phù hợp vì nhiều chuỗi Tool Calls khác nhau có thể cùng đúng.

Test Set nên có câu rõ ràng, câu mơ hồ, ngày tương đối, yêu cầu vượt quyền, API lỗi, dữ liệu rỗng và Prompt Injection nằm trong Tool Result. Sau mỗi thay đổi Tool Description hoặc Model, chạy Regression Test để phát hiện hành vi mới.

Checklist production

Tool có một mục đích rõ và tên dễ phân biệt.
Schema hạn chế trường tự do và dùng Enum khi phù hợp.
Business Validation được thực thi ngoài Model.
Identity đến từ phiên đăng nhập, không từ Arguments.
Data Filter được áp dụng trước khi dữ liệu vào Context.
Write Tool có Approval, Idempotency và Audit Log.
Error được phân loại thành retryable và non-retryable.
Tool Result có Source, Freshness và Request ID.
Max Tool Calls, Timeout và Budget đã được đặt.
Evaluation bao phủ Tool Selection, Arguments và Outcome.

Kết luận

Tool Calling tạo cầu nối giữa ngôn ngữ và hành động, nhưng Model chỉ nên đề xuất. Application vẫn phải chịu trách nhiệm về quyền, kiểm tra dữ liệu, thực thi và ghi vết. Một Tool tốt là một API có hợp đồng rõ, phạm vi nhỏ, kết quả có cấu trúc và Failure Mode được dự đoán.

Khi xây Agent đầu tiên, hãy bắt đầu với một hoặc hai Read Tools. Đánh giá khả năng chọn Tool và tạo Arguments trước. Chỉ thêm Write Tools sau khi hệ thống có Identity, Permission, Approval, Idempotency và Observability.

Tài liệu tham khảo

OpenAI Documentation. Function calling. Vòng đời Tool Calling, schema và cách xử lý kết quả.
OpenAI Documentation. Structured Outputs. Cách ràng buộc Output theo JSON Schema.
Anthropic. Writing Effective Tools for AI Agents. Thiết kế Tool Description, response và evaluation.
Model Context Protocol. Architecture overview. Kiến trúc cung cấp Tools và Resources cho ứng dụng AI.
OWASP Top 10 for LLM Applications. Các rủi ro như Excessive Agency và Insecure Output Handling.
Google Cloud Architecture Center. Agentic AI design patterns. Pattern thiết kế hệ thống Agent.

TechData.AI - Leading The Future.

Hoàng Minh.