Tool calling cho tác tử: hợp đồng công cụ và quyền thực thi

Đăng ngày 27/10/2026

Gọi đúng hàm mới là một phần của công việc

Tool calling cho tác tử là cơ chế để mô hình đề xuất một công cụ cùng tham số, còn hệ thống thực thi kiểm và xử lý lời gọi ấy. Trong công việc, một lời gọi hợp lệ vẫn có thể sai: đúng định dạng nhưng nhầm hồ sơ, đúng hồ sơ nhưng vượt quyền, hoặc đúng mọi trường mà lại gửi yêu cầu thật trong khi người dùng chỉ muốn bản nháp. Vì vậy, hợp đồng công cụ cần mô tả cả ý nghĩa và tác dụng nghiệp vụ.

Trong Writing effective tools for agents, Anthropic đề xuất chọn công cụ có mục đích rõ, đặt tên phân biệt, trả ngữ cảnh hữu ích và kiểm bằng những tác vụ thực tế của ứng dụng [1]. Đây là hướng dẫn của một nhà cung cấp có lợi ích thương mại trong lĩnh vực tác tử. Giá trị có thể dùng ở đây là coi mô tả công cụ như tài liệu giao việc cần được thử, không xem một danh sách hàm dài là dấu hiệu hệ thống có năng lực hơn.

Bài viết đề xuất hai công cụ thiết kế: hợp đồng sáu câu cho mỗi thao tác, và ba lớp kiểm gồm cấu trúc, đối tượng cùng quyền, rồi ý định nghiệp vụ. Tình huống là trợ lý tạo dự thảo yêu cầu hỗ trợ nội bộ tại một công ty Việt Nam. Các ví dụ, phép thử và điểm dừng là giả định biên tập; không có triển khai, tỷ lệ hiệu quả hoặc nhà cung cấp dịch vụ cụ thể nào được xác nhận.

Schema mô tả hình dạng, nghiệp vụ quyết định ý nghĩa

Đặc tả Tools của MCP phiên bản 2025-11-25 mô tả tên, mô tả, lược đồ đầu vào và lược đồ đầu ra tùy chọn cho công cụ [2]. Đây là một ví dụ giao thức cụ thể, không phải hình thức bắt buộc của mọi hệ thống gọi hàm. Lược đồ giúp các thành phần biết dữ liệu cần trông thế nào, nhưng không tự trả lời một yêu cầu hỗ trợ có được phép tạo, thuộc đơn vị nào hoặc có đúng người nhận không.

JSON Schema Draft 2020-12 có các ràng buộc về kiểu, giá trị và trường bắt buộc, trong đó trường bắt buộc được kiểm theo sự hiện diện của tên thuộc tính [3]. Việc có một trường không chứng minh giá trị của trường ấy đã được xác minh. Một mã nhân viên là chuỗi đúng kiểu vẫn có thể chỉ người khác. Một tiêu đề có độ dài hợp lệ vẫn có thể chứa thông tin không được gửi vào hệ thống hỗ trợ.

Nghĩa nghiệp vụ cần được viết ngay cạnh tham số. Mã hồ sơ là mã lấy từ kết quả tra cứu đã kiểm, không phải tên hiển thị do mô hình tự đoán. Mức ưu tiên là lựa chọn theo quy tắc nội bộ, không phải cảm xúc trong câu người dùng. Trường người nhận có thể được suy ra ở máy chủ từ danh tính và nhóm xử lý được phép, thay vì cho tác tử tự nhập tùy ý một địa chỉ hoặc một mã bộ phận.

Tham số thiếu phải có nghĩa rõ. Chưa biết người phụ trách không được biến thành mã mặc định của quản trị viên; chưa có thời điểm xảy ra không được tự điền giờ hiện tại như thể đó là dữ kiện thật. Công cụ có thể nhận trạng thái chưa biết nếu quy trình cho phép, hoặc từ chối và yêu cầu làm rõ. Đội thiết kế phải chọn một cách có chủ đích để khoảng trống không âm thầm trở thành thông tin bịa trong yêu cầu hỗ trợ.

Công cụ một: hợp đồng sáu câu

Trước khi thêm một công cụ, trả lời sáu câu: nó phục vụ việc gì; dùng khi nào và không dùng khi nào; đối tượng được xác định từ đâu; ai có quyền làm; nó tạo tác dụng gì; kết quả nào xác nhận đã làm đúng. Đây là khung biên tập được đề xuất cho đội nghiệp vụ và kỹ thuật cùng đọc. Nếu không thể trả lời rõ, việc tối ưu lời mô tả cho mô hình chưa giải quyết được thiếu sót của giao diện nghiệp vụ.

Với công cụ tạo dự thảo, mục đích là lưu nội dung để người dùng xem lại; tác dụng phải giới hạn ở nơi giữ bản nháp, không tự gửi thông báo hay mở việc cho đội xử lý. Hợp đồng cần nói bản nháp chứa những trường nào, ai xem được và làm sao nhận lại đúng bản vừa tạo. Nếu một hệ thống bên dưới tự phát thông báo khi lưu, đội không được gọi lớp bọc ấy là tạo nháp mà bỏ qua tác dụng thực tế.

Công cụ gửi yêu cầu thật cần một hợp đồng khác vì có thể tạo việc, thông báo và nghĩa vụ phản hồi nội bộ. Không nên giấu hai hành vi trong một tùy chọn khó thấy nếu chúng có quyền và hậu quả khác nhau. Mô tả cần chỉ rõ điều kiện xác nhận, nội dung cuối được gửi và trạng thái trả về. Việc người dùng từng đồng ý cho tạo nháp không mặc nhiên mở quyền gửi mọi phiên bản sửa tiếp theo.

Tách đọc, tạo nháp và ghi thật

Ba thao tác có thể dùng cùng một nguồn dữ liệu nhưng cần quyền khác nhau. Đọc danh mục loại lỗi giúp người dùng chọn đúng nhóm; tạo nháp giúp gom thông tin; gửi yêu cầu thật mới bắt đầu quy trình xử lý. Tác tử chỉ nên được thấy và gọi những thao tác phù hợp phạm vi đã giao. Việc ẩn nút trên giao diện không đủ nếu phía thực thi vẫn chấp nhận lời gọi trực tiếp tới công cụ có quyền cao hơn.

Tên công cụ nên thể hiện tác dụng một cách nhất quán. Một tên chung như xử lý yêu cầu dễ khiến người thiết kế lẫn cả tra cứu, sửa, gửi và đóng việc vào cùng cửa. Khi tách công cụ, đừng làm mất quan hệ giữa các đối tượng: bản nháp cần mã riêng, phiên bản rõ và liên kết đúng người tạo. Bước gửi phải biết nó đang gửi phiên bản nào, tránh việc người dùng duyệt một bản nhưng tác tử gửi bản đã sửa sau đó.

Công cụ hai: ba lớp kiểm trước khi thực thi

OWASP API1:2023 nhấn mạnh kiểm quyền ở cấp đối tượng cho các thao tác nhận định danh từ phía gọi; truy cập được một chức năng không có nghĩa được thao tác trên mọi bản ghi [4]. Với tác tử, máy chủ phải kiểm danh tính, hành động và đối tượng theo chính sách. Không lấy mã người dùng do mô hình gửi làm bằng chứng rằng đó là danh tính thật của phiên làm việc hoặc rằng hồ sơ ấy thuộc phạm vi được phép.

Lớp cấu trúc kiểm kiểu, trường bắt buộc, giới hạn và các giá trị được chấp nhận. Lớp đối tượng cùng quyền kiểm bản ghi có thể truy cập theo hành động được yêu cầu và trạng thái hiện hành hay không. Lớp ý định kiểm tác dụng này có khớp việc người dùng đã giao và điều kiện nghiệp vụ không. Ba lớp cần phối hợp; một bộ kiểm dữ liệu đầu vào tốt không thể thay toàn bộ kiểm quyền hoặc xác nhận ý định cho thao tác có ảnh hưởng.

Ví dụ, một lời gọi tạo nháp có tiêu đề và mô tả đúng cấu trúc nhưng mang mã bộ phận khác cần bị chặn hoặc điều chỉnh theo nguồn được phép, không chỉ cảnh báo bằng văn bản rồi vẫn ghi. Một lời gọi gửi yêu cầu trên đúng hồ sơ của người dùng vẫn có thể sai ý định nếu họ chỉ yêu cầu soạn thử. Kiểm trường hợp này cần thông tin giao việc đáng tin và ranh giới thực thi, không dựa riêng vào cách mô hình tự diễn giải lời nói trước khi gọi.

Khi điều kiện thay đổi giữa lúc chuẩn bị và lúc chạy, kiểm lại ở thời điểm thực thi. Một bản nháp vừa bị người khác sửa hoặc một quyền vừa thu hồi không nên bị bỏ qua vì tham số ban đầu đã hợp lệ. Giao diện có thể yêu cầu đối chiếu phiên bản trước khi ghi để phát hiện xung đột. Nếu không hỗ trợ, quy trình phải nêu cách phát hiện và bàn giao khi chưa bảo đảm đang thao tác trên đúng bản được duyệt.

Thử lại phải hiểu tác dụng của lời gọi

RFC 9110 phân biệt phương thức HTTP an toàn với phương thức có tính lặp lại giữ nguyên tác dụng dự định; tài liệu cũng đặt điều kiện cho việc tự động thử lại một yêu cầu không có tính chất ấy [5]. Hai khái niệm không đồng nghĩa: lặp không làm thêm thay đổi dự định không có nghĩa thao tác ban đầu vô hại. Công cụ tác tử cần mô tả tác dụng ở cấp ứng dụng, không chỉ dựa vào tên phương thức HTTP bên dưới.

Khi tạo yêu cầu hỗ trợ bị hết thời gian chờ, tác tử chưa biết máy chủ đã tạo hồ sơ hay chưa. Gửi lại cùng nội dung có thể tạo hai việc. Thiết kế có thể dùng định danh cho một thao tác và cơ chế chống lặp được máy chủ thực hiện, hoặc một đường tra trạng thái đủ tin cậy. Cơ chế cụ thể phải được xác minh với hệ thống dùng thật; không thể chỉ thêm một trường mã yêu cầu rồi mặc định đã có bảo đảm chống trùng.

Kết quả cần phân biệt chưa gửi, đã chấp nhận xử lý, đã tạo thành công và chưa xác định được trạng thái, nếu hệ thống có các giai đoạn ấy. Một phản hồi đã nhận yêu cầu không nhất thiết có nghĩa đội hỗ trợ đã nhận việc hoặc thông báo đã tới người nhận. Tác tử nên báo đúng giai đoạn được xác minh. Khi không có đường kiểm, bàn giao phần chưa rõ cho người vận hành có ích hơn việc lặp cho tới khi nhận một câu thành công.

Kết quả và lỗi cần đủ nghĩa để quyết định bước sau

RFC 9457 định nghĩa cách chuyển thông tin lỗi HTTP thành dữ liệu máy có thể đọc và lưu ý không để chi tiết lỗi lộ thông tin nội bộ hoặc dữ liệu người dùng [6]. Đây là định dạng cho giao diện HTTP, không phải yêu cầu mọi công cụ tác tử đều phải dùng y hệt. Nguyên tắc hữu ích là lỗi phải giúp chọn hành động tiếp theo, trong khi phần thông tin trả về vẫn được giới hạn theo người nhận và mục đích.

Trong đặc tả MCP đã nêu, lỗi thực thi công cụ được phân biệt với lỗi giao thức và có cơ chế thể hiện lỗi trong kết quả [2]. Ứng dụng cần hiểu sự phân biệt ấy thay vì chỉ thấy lời gọi đã có phản hồi là thành công. Nếu lớp kết nối nhận thông báo lỗi nhưng lớp tổng hợp vẫn nói đã tạo bản nháp, hợp đồng đầu ra đã bị mất ở giữa. Bộ kiểm phải đi qua toàn đường từ máy chủ tới câu báo cho người dùng.

Một lỗi thiếu trường có thể cho phép bổ sung tham số; lỗi không đủ quyền cần dừng thao tác ấy; xung đột phiên bản cần đọc lại theo quyền và xác nhận cách giải quyết. Thông báo không nên tiết lộ một hồ sơ tồn tại ở bộ phận khác nếu người gọi không được biết. Mã điều tra có thể giúp người vận hành tìm nhật ký cần thiết, còn nội dung hiện cho tác tử chỉ giữ chi tiết được phép và đủ để tránh lặp lại sai cách.

Kết quả thành công cũng cần có nghĩa rõ: định danh đối tượng đã tạo, loại trạng thái, phiên bản nếu có và đường kiểm theo quyền. Trả lại toàn bộ hồ sơ khách hoặc nhân viên không làm biên nhận tốt hơn nếu nhiệm vụ chỉ cần xác nhận bản nháp đã lưu. Khi công cụ phân trang hoặc cắt bớt kết quả, phải báo điều đó để tác tử không coi phần đã đọc là toàn bộ. Thiếu thông tin cần được nêu thành giới hạn thay vì giấu sau một đầu ra ngắn.

Đo đúng hàm và đúng mục đích bằng hai phép nhìn

BFCL là benchmark nghiên cứu về gọi hàm, có các dạng gọi nối tiếp, song song, lựa chọn không gọi và bối cảnh nhiều bước theo phạm vi công bố [7]. Nó giúp thấy năng lực gọi công cụ cần nhiều dạng thử, nhưng điểm benchmark không xác nhận quyền hay mục tiêu của một ứng dụng doanh nghiệp. Trong bài này, nguồn được đọc là trang công bố gốc và tóm tắt của nghiên cứu; không dùng thứ hạng hiện hành để đề xuất mô hình.

τ-bench bổ sung cách kiểm trạng thái dữ liệu cuối trong tương tác với người dùng mô phỏng và quy tắc ngành; tác giả cũng nêu rằng trạng thái cuối đúng có thể chưa đủ nếu thiếu bước tuân thủ trong đường đi [8]. Vì vậy, phép nhìn thứ nhất ở đây là lời gọi có đúng công cụ, tham số và kết quả. Phép nhìn thứ hai là tác dụng đã tạo có đúng ý định, phạm vi quyền và trình tự phải tuân theo hay không.

Trong bộ thử hỗ trợ, hãy đặt cạnh nhau ba yêu cầu gần giống: giải thích cách báo lỗi, tạo một bản nháp và gửi bản nháp đã được xác nhận. Đầu vào có thể cùng nhắc tên thiết bị nhưng kỳ vọng gọi công cụ khác nhau. Nếu hệ thống luôn tạo việc thật vì mọi câu đều nói đến hỗ trợ, nó thất bại về ý định dù các tham số đều hợp lệ. Đây là lỗi cần được đếm riêng để tìm đúng chỗ sửa.

Tình huống giả định: soạn yêu cầu hỗ trợ nội bộ

Giả sử nhân viên của một công ty dịch vụ tại Việt Nam muốn mô tả lỗi thiết bị để nhờ đồng nghiệp xem trước. Trợ lý được phép đọc danh mục thiết bị thuộc nhân viên và tạo nháp ở không gian của họ. Nhóm kỹ thuật chưa cho phép trợ lý gửi việc thật hoặc đính kèm toàn bộ nhật ký hệ thống. Đây là phạm vi giả định để thiết kế công cụ, không phải quy trình đã được xác minh của một công ty đang hoạt động.

Tác tử tìm được hai thiết bị có tên gần giống. Thay vì đoán mã, nó đưa phần thông tin phân biệt được phép cho người dùng chọn hoặc hỏi một chi tiết cần thiết. Sau khi đối tượng đã rõ, công cụ tạo nháp chỉ nhận các trường phù hợp và máy chủ xác định chủ hồ sơ từ phiên đã xác thực. Biên nhận cho biết nháp đã lưu; tác tử mở lại theo quyền để kiểm thiết bị, mô tả và trạng thái chưa gửi.

Nếu người dùng muốn thêm ảnh màn hình, cần kiểm ảnh có chứa thông tin không cần thiết trước khi đưa vào đường xử lý đã được phép. Việc có quyền xem ảnh trong hội thoại không tự mở quyền tải ảnh sang một dịch vụ khác. Nháp có thể ghi đang chờ bổ sung tệp phù hợp, nếu quy trình cho phép. Không bịa rằng nhật ký đã đính kèm khi công cụ chỉ lưu một dòng mô tả nhắc tới nhật ký.

Ở bước sau, giả sử người dùng muốn gửi nháp. Hệ thống phải xác định bản đang được xác nhận và quyền gửi hiện hành, không dùng lại suy đoán từ lần tạo nháp. Nếu công cụ gửi chưa được cấp, trợ lý bàn giao đường gửi do người dùng thực hiện theo quy trình. Kết quả đúng là nói rõ bản đã chuẩn bị và giới hạn hành động. Cố tìm một công cụ sửa trạng thái gần giống để lách qua thiếu quyền sẽ làm hỏng mục tiêu của thiết kế.

Chọn phạm vi triển khai và chỉ số cần nhìn

Đội nhỏ có thể chỉ cần vài công cụ hẹp: tra danh mục trong phạm vi, lưu nháp và đọc lại nháp. Mỗi công cụ có một người nghiệp vụ giữ nghĩa và một người kỹ thuật giữ điều kiện thực thi. Khi không có đủ người duy trì, nên giới hạn số loại yêu cầu hơn là mở nhiều hàm chung khó kiểm. Thêm công cụ chỉ có ích khi có một công việc cụ thể chưa được giải quyết và có thể viết phép thử chấp nhận.

Theo dõi tỷ lệ chọn đúng thao tác, tham số bị từ chối, lỗi nhầm đối tượng, hành động sai ý định và việc tạo trùng theo nguyên nhân. Mẫu số phải gắn với nhóm tác vụ đã thử, cùng phần chưa thể kết luận. Tính cả thời gian người dùng sửa bản nháp và người vận hành điều tra. Một hệ thống ít lỗi cú pháp nhưng hay mở nhầm việc có thể tốn công hơn hệ thống biết hỏi lại đúng chỗ và giữ thao tác ở trạng thái dự thảo.

Phép thử và điểm dừng trước khi mở quyền

Trước khi dùng công cụ có tác dụng thật, tạo môi trường thử tách biệt và chốt các điều kiện chấp nhận. Bộ ca cần có mã hợp lệ nhưng sai chủ hồ sơ, quyền bị thu hồi, nội dung quá dài, thiếu dữ kiện và yêu cầu chỉ muốn hướng dẫn. Kiểm rằng máy chủ từ chối đúng, tác tử hiểu đúng lỗi và câu trả lời cuối không biến từ chối thành thành công. Chỉ thử mô hình chọn hàm trên giấy sẽ bỏ qua hai phần sau.

Thử thêm kết quả hết thời gian chờ sau khi máy chủ đã ghi, phản hồi bị cắt và xung đột phiên bản giữa duyệt với gửi. Mỗi ca phải có trạng thái cuối mong đợi và hành động không được xảy ra, như tạo trùng hoặc gửi phiên bản chưa được xác nhận. Khi kết quả chưa rõ, kiểm khả năng bàn giao cùng mã tra cứu. Những ca này là thiết kế thử cần thực hiện, không phải bằng chứng bài viết đã chạy trên một hệ thống thật.

Dừng mở rộng quyền khi phát hiện truy cập ngoài phạm vi, gửi thật từ yêu cầu tạo nháp hoặc không truy được tác dụng sau lỗi. Sửa ở tầng thích hợp: hợp đồng, kiểm quyền, giao diện hay cách chấm, rồi chạy lại ca lỗi cùng những ca cần bảo toàn. Không chỉ đổi mô tả để tác tử né một ví dụ mà bỏ nguyên lỗ hổng máy chủ. Điều kiện cho phép dùng rộng hơn phải gắn với bằng chứng toàn đường và người chịu trách nhiệm chấp nhận.

Hỏi đáp về tool calling cho tác tử

Có schema chặt thì còn cần người nghiệp vụ không? Có. Schema kiểm được hình dạng và một số ràng buộc, còn ý nghĩa của mức ưu tiên, bản nháp hay điều kiện gửi cần người có trách nhiệm xác định. Nếu chưa thống nhất một trường mang nghĩa gì, mô hình có thể điền rất nhất quán mà vẫn sai. Hãy chốt nghĩa và ví dụ chấp nhận trước khi mở rộng số công cụ hoặc tối ưu cách gọi.

Có nên gộp đọc và ghi cho tiện không? Chỉ nên gộp khi tác dụng, quyền và cách kiểm vẫn rõ, phù hợp công việc đã giao. Trong ca tạo nháp rồi gửi, tách thao tác thường tạo một điểm xem xét hữu ích vì hai bước có hậu quả khác nhau. Quyết định cần dựa vào hành vi thực tế của hệ thống dưới, không chỉ tên hàm hoặc việc giao diện có ít nút hơn.

Mô hình gọi một hàm không có trong danh mục thì sao? Lớp thực thi cần từ chối theo hợp đồng, không tự tìm một hàm tên gần giống rồi chạy thay. Tác tử có thể xem lại danh mục được phép hoặc nêu việc chưa làm được trong phạm vi. Tự sửa tên chỉ chấp nhận khi việc ánh xạ đã được thiết kế, kiểm và không làm đổi tác dụng. Không dùng suy đoán để mở một thao tác ngoài danh mục quyền.

Công cụ trả thành công có đủ để báo xong không? Cần xem thành công nghĩa là đã tiếp nhận, đã lưu nháp hay đã hoàn tất tác dụng dự định. Kiểm thêm theo đường được phép khi hậu quả và hợp đồng yêu cầu. Nếu biên nhận chỉ xác nhận lưu, hãy báo đã lưu. Nếu trạng thái còn chưa rõ, nêu giới hạn và cách tiếp nhận; lời báo xong phải khớp bằng chứng thay vì khớp mong muốn kết thúc hội thoại.

Nguồn, phương pháp và giới hạn suy luận

Bài có hỗ trợ AI, dựa trên tám nguồn gốc đã đọc ngày 27/10/2026: đặc tả, tiêu chuẩn, hướng dẫn an ninh, nghiên cứu và tài liệu nhà cung cấp. Phạm vi đọc BFCL chỉ gồm trang công bố và tóm tắt; không dùng số benchmark để dự báo hiệu quả. Hợp đồng sáu câu, ba lớp kiểm và ca hỗ trợ là tổng hợp biên tập giả định, chưa thử thực địa hoặc thẩm định chuyên gia/pháp lý. Hướng dẫn thương mại được ghi nguồn và không coi là kiểm chứng độc lập.