Ngày xuất bản: 19 tháng 5 năm 2026, Cập nhật lần cuối: 28 tháng 5 năm 2026
| Video giải thích | Web | Phần mở rộng | Trạng thái của Chrome | Mục đích |
|---|---|---|---|---|
| GitHub |  Bản dùng thử theo nguyên gốc |
Xem | Ý định thử nghiệm |
WebMCP hỗ trợ các tác nhân sử dụng mô hình trí tuệ nhân tạo tạo sinh. Để kiểm tra bất kỳ hệ thống nào sử dụng trí tuệ nhân tạo tạo sinh, các bài kiểm tra của bạn cần hỗ trợ các kết quả có tính xác suất: một đầu vào có thể dẫn đến hàng ngàn câu trả lời với độ chính xác khác nhau. Kỹ thuật kiểm thử này được gọi là đánh giá hoặc evals.
Trước khi đưa các công cụ vào sản xuất, bạn phải xác nhận rằng các tác nhân hiểu khi nào cần gọi công cụ, cách thực thi nó và những câu trả lời nào được chấp nhận. Hãy giải quyết những nguy cơ thất bại trước khi chúng xảy ra.
Viết các bài đánh giá để kiểm tra các điểm tiếp xúc của hệ thống với mô hình ngôn ngữ lớn (LLM):
- Hãy kiểm tra xem mô hình có hiểu mục đích của công cụ của bạn hay không, dựa trên mô tả và lược đồ của nó.
- Xác minh rằng mô hình chọn đúng công cụ với các tham số chính xác để hỗ trợ ý định của người dùng.
- Xác nhận rằng mô hình đang hoạt động dựa trên thông tin đã nhận được, ví dụ như sử dụng thông tin đó để gọi một công cụ khác.
- Xác minh hành trình thành công của người dùng. Dựa trên ý định của người dùng, liệu một tác nhân có thể hoàn tất hành trình của người dùng trên trang web của tôi bằng các công cụ được cung cấp hay không?
Bạn nên tiếp tục viết các kiểm thử xác định cổ điển cho mọi hoạt động tương tác hệ thống không giao tiếp với mô hình.
Chế độ lỗi
Nhà phát triển nên kiểm thử hệ thống để ngăn chặn lỗi trước khi chúng xảy ra. Để làm như vậy, bạn cần hiểu rõ thời điểm hệ thống có thể gặp lỗi, cả khi hoạt động độc lập và khi tương tác với các yếu tố bên ngoài. Đối với WebMCP, bản thân công cụ này có thể gặp lỗi và các nhân viên có thể không sử dụng được công cụ như mong đợi.
Các công cụ WebMCP có thể gặp lỗi và khi đó, tác nhân có thể gặp lỗi với các công cụ WebMCP. Ví dụ: giả sử người dùng muốn thêm một chiếc áo thun vào giỏ hàng.
| Lỗi | Ví dụ | Khắc phục sự cố |
|---|---|---|
| Nhân viên không chọn đúng công cụ hoặc gọi trực tiếp công cụ không chính xác. |
Tác nhân bỏ qua 
|
|
| Nhân viên hỗ trợ gọi các công cụ theo thứ tự không chính xác |
Tác nhân gọi 
|
|
| Trợ lý gọi công cụ bằng các đối số không chính xác |
Trợ lý gọi 
|
|
Nếu người dùng muốn kiểm tra xem trong giỏ hàng của họ có những gì thì sao?
| Lỗi | Ví dụ | Khắc phục sự cố |
|---|---|---|
| Kết quả đầu ra của công cụ không chính xác hoặc công cụ bỏ sót một số thao tác. | Người dùng yêu cầu 
|
|
Cuối cùng, một công cụ có thể giải quyết mọi vấn đề mà JavaScript gặp phải. Để khắc phục sự cố, hãy kiểm tra những điều sau:
- Mã nguồn của công cụ có xử lý đúng cách tất cả các lỗi và ngoại lệ tiềm ẩn trong quá trình thực thi hay không?
- Lỗi có được báo cáo lại cho tác nhân và mô hình một cách khéo léo không?
- Các API hoặc dịch vụ bên ngoài mà công cụ này dựa vào có hoạt động ổn định không?
- Liệu cấu trúc lỗi có đủ rõ ràng để mô hình có thể phân biệt giữa sự cố tạm thời (thử lại) và lỗi nghiêm trọng không?
Kiểm thử các công cụ một cách riêng biệt
Nếu một nhân viên hỗ trợ không thể tìm ra công cụ nào cần gọi cho một yêu cầu đơn giản như "Tôi muốn một chiếc bánh pizza nhỏ", thì họ sẽ không có cơ hội thành công trong một quy trình xử lý đơn hàng phức tạp của người dùng.
Bằng cách kiểm tra các công cụ một cách riêng biệt, bạn có thể tối ưu hóa lược đồ và mô tả của mình trước khi chạy mô phỏng trình duyệt.
Đo độ chính xác của cuộc gọi
Hãy xem bản demo của chúng tôi, WebMCP zaMaker.
Khi người dùng yêu cầu, "Tôi muốn một chiếc bánh pizza nhỏ," bạn có thể mong đợi một phản hồi mẫu cho biết ý định thực hiện lệnh gọi set_pizza_size với đối số "size":"Small".
Hàm expectedCall định nghĩa hàm và đối số dự kiến. Cách tiếp cận này xác nhận rằng tác nhân sẽ chọn công cụ phù hợp để hỗ trợ ý định của người dùng, dựa trên lược đồ được cung cấp.
{
"messages": [
{
"role": "user",
"content": "I'd like a small pizza."
}
],
"expectedCall": [
{
"functionName": "set_pizza_size",
"arguments": { "size": "Small" }
}
]
}
expectedCall được sử dụng để thực hiện một bài kiểm tra xác định dựa trên quy tắc:
Bạn có thể liên kết các công cụ WebMCP của mình với vòng đời của một thành phần, điều này có nghĩa là bạn phải kiểm tra xem trạng thái ứng dụng của bạn có khớp với những gì WebMCP mong đợi hay không. Để quản lý việc này, hãy cung cấp danh sách đầy đủ các công cụ có liên quan đến trạng thái mà bạn muốn đánh giá. Ví dụ, người dùng đang duyệt web cùng với người đại diện của họ và mở WebMCP zaMaker.
Trạng thái ứng dụng
[
...
{
"name": "add_topping",
"description": "Add one or more toppings to the pizza",
...
},
{
"name": "set_pizza_size",
"description": "Set the pizza size directly.",
"inputSchema": {
"type": "object",
"properties": {
"size": {
"type": "string",
"enum": [
"Small",
"Medium",
"Large",
"Extra Large"
],
"description": "The specific size name."
},
}
}
},
{
"name": "set_pizza_style",
"description": "Set the style of the pizza (colors/theme)",
...
},
...
]
Cuộc gọi dự kiến
...
"expectedCall": [
{
"functionName": "set_pizza_size",
"arguments": { "size": "Small" }
}
]
...
Khi mở, WebMCP sẽ hiển thị các công cụ add_topping, set_pizza_size và set_pizza_style. Để kiểm tra chính xác bất kỳ công cụ riêng lẻ nào, bạn nên kết hợp tất cả các công cụ để tạo ra một trạng thái mô phỏng hoàn chỉnh.
LƯU Ý: Nhân viên môi giới có thể có thêm các công cụ khác, nhưng điều tốt nhất bạn có thể làm là đánh giá các công cụ mà bạn cung cấp.
Giờ bạn đã biết rằng tác nhân sẽ gọi đúng công cụ khi cần, bạn có thể kiểm tra xem lệnh gọi công cụ có các tham số chính xác hay không và kết quả có đúng như mong đợi hay không. Có hai bước: kiểm tra xác định và kiểm tra xác suất.
Tiến hành các bài kiểm tra xác định
Vì các công cụ WebMCP được xây dựng bằng JavaScript hoặc dưới dạng chú thích HTML, bạn có thể viết các bài kiểm tra xác định để thực hiện các tác vụ sau:
- Kiểm tra logic của công cụ.
- Xác nhận các hàm phụ thuộc đã được gọi đúng cách.
- Xác nhận giao diện người dùng đã được cập nhật như mong đợi, cùng với bất kỳ tác dụng phụ nào khác không mong muốn.
- Kiểm tra xem thông tin trả về có khớp với giá trị mong đợi hay không.
- Xác thực các thông số kiểm thử.
Ví dụ, nếu công cụ của bạn sử dụng một hàm SearchComponent, bạn có thể kiểm tra bằng cách truyền một đối tượng giả lập của SearchComponent. Hãy nhớ mô phỏng môi trường mà công cụ đang hoạt động để có được kết quả tốt nhất. Đây là kỹ thuật tương tự mà bạn sẽ sử dụng khi viết các bài kiểm thử tích hợp ứng dụng khác.
Tiến hành các bài kiểm tra xác suất
Nếu bạn cần đầu ra của mô hình để gọi đúng các công cụ tiếp theo, bạn cần viết các hàm eval.
Người dùng có thể đưa ra các truy vấn trực tiếp cho mô hình để hỏi cụ thể công cụ đó làm gì, hoặc một truy vấn mơ hồ ngụ ý rằng nên sử dụng một công cụ nào đó. Ví dụ, "Thêm xúc xích pepperoni vào bánh pizza của tôi" là một truy vấn trực tiếp. Câu "Tôi muốn tất cả thịt trên bánh pizza của mình" mơ hồ hơn và đòi hỏi mô hình phải hiểu rằng nó cần công cụ add_topping và xác định loại topping nào có thể được định nghĩa là thịt.
Khi tạo tập dữ liệu cho các bài đánh giá của bạn, hãy bao gồm cả các truy vấn trực tiếp kiểm tra hiệu năng cơ bản của công cụ và các truy vấn mở kiểm tra khả năng suy luận của mô hình và logic lựa chọn công cụ.
Nếu bạn điều hành một quán cà phê, bạn có thể hỗ trợ khách hàng yêu cầu nhân viên của họ đặt lại loại cà phê giống hệt loại họ đã đặt tháng trước. Viết một công cụ để tìm kiếm các đơn hàng trước đó, OrderHistoryService, và một công cụ khác để đặt cà phê. Để kiểm tra dịch vụ lịch sử đơn hàng, bạn có thể gửi một yêu cầu giả lập trả về ID sản phẩm cà phê.
Trong ví dụ này, bạn đánh giá xem mô hình có hiểu ý định của truy vấn, chọn đúng công cụ và liệu công cụ đó có cung cấp thông tin chính xác để thực hiện hành động hay không.
Nếu mô hình không gọi get_order_history, nó sẽ không biết phải sử dụng item_id nào cho order_product.
Kiểm thử từ đầu đến cuối
Hãy viết các bài kiểm tra từ đầu đến cuối để bạn tự tin rằng người dùng và các đại lý của họ có thể hoàn thành hành trình của mình một cách thành công. Ngoài việc kiểm tra từng công cụ riêng lẻ, bạn cũng đang kiểm tra xem các thao tác nhiều bước có được thực hiện theo đúng trình tự hay không.
Ví dụ, bạn điều hành một cửa hàng quần áo trực tuyến. Một người dùng hỏi người đại lý của họ: "Tôi muốn mua một chiếc áo khoác đen và một chiếc quần jeans. Bạn có thể cung cấp bảng phân tích chi tiết các vật liệu đã sử dụng không?
Một hành trình thành công của người đại diện có thể diễn ra như sau:
- Truy cập vào danh mục quần áo.
- Hãy tìm một trong những món đồ quần áo được yêu cầu (thứ tự không quan trọng).
- Tìm mục cụ thể (
search_clothes). - Lấy thông tin chi tiết sản phẩm bao gồm danh sách vật liệu (
get_product_details). - Lặp lại bước 2-4 cho mỗi mặt hàng được yêu cầu.
Khi tác nhân đến bước 2, nó có thể tìm kiếm màu đen trước hoặc quần jean trước, thứ tự không quan trọng. Tuy nhiên, các bước còn lại phải được thực hiện theo trình tự.
Viết một chương trình đánh giá từ đầu đến cuối để xác minh rằng tác nhân gọi các công cụ theo đúng thứ tự mong đợi:
{
"messages": [
{
"role": "user",
"content": "I am looking to buy a black jacket and a pair of jeans.
Could you provide a breakdown of the materials used ?"
}
],
"expectedCall": [
{
"functionName": "navigate_to_category",
"arguments": { "category": "clothes" }
},
{
"unordered": [
{
"ordered": [
{
"functionName": "search_clothes",
"arguments": { "query": "black jacket" }
},
{
"functionName": "get_product_details",
"arguments": { "productId": "JACKET002" }
}
]
},
{
"ordered": [
{
"functionName": "search_clothes",
"arguments": { "query": "jeans" }
},
{
"functionName": "get_product_details",
"arguments": { "productId": "JEANS001" }
}
]
}
]
}
]
}
Đánh giá các sự cố trong chuỗi cung ứng
start_pizza_creator, set_pizza_style, set_pizza_size, start_checkout, add_discount_coupon và complete_checkout. Lỗi add_discount_coupon xảy ra, nhưng quy trình vẫn hoàn tất, nghĩa là người dùng không nhận được giảm giá.Có thể sẽ có những lúc nhân viên phải gọi nhiều công cụ khác nhau theo trình tự. Điều gì sẽ xảy ra nếu một công cụ gặp sự cố giữa chừng trong quá trình này? Ví dụ, một người dùng muốn đặt pizza bằng mã giảm giá của họ:
"Tôi muốn một chiếc pizza Pesto cỡ nhỏ." Hãy sử dụng mã khuyến mãi của tôi, FreePizza."
Có khả năng nhân viên sẽ gặp lỗi ở bước add_discount_coupon và tiếp tục thanh toán cho một chiếc bánh pizza với giá đầy đủ. Để kiểm tra công cụ add_discount_coupon, bạn có thể tự thực hiện chuỗi lệnh gọi công cụ này mà không cần tương tác với mô hình để mô phỏng tình huống này. Hãy đưa ứng dụng của bạn đến tiểu bang mà bạn dự đoán công cụ sẽ gặp sự cố. Trong trường hợp này, đó là sau công cụ start_checkout. Sau đó, bạn có thể đánh giá add_discount_coupon một cách riêng biệt.
Thử nghiệm với WebMCP
Hãy bắt đầu thử nghiệm việc đánh giá các công cụ một cách độc lập và tự đánh giá các trang web hỗ trợ WebMCP của bạn với bất kỳ tác nhân nào tương thích với WebMCP:
- Tải xuống ứng dụng của chúng tôicông cụ đánh giá thử nghiệm trên GitHub.
- Xem lại khóa học của chúng tôi, Tạo đánh giá AI.