Các phương pháp hay nhất về WebMCP

Alexandra Klepper
Alexandra Klepper
GitHub Bluesky

Xuất bản: Ngày 18 tháng 5 năm 2026

Khai báo công cụ WebMCP phải rõ ràng, không cần nhà phát triển hoặc tác nhân xem xét đầu ra và thử lại. Cho dù bạn sử dụng Imperative API hay Declarative API, hãy làm theo các phương pháp hay nhất sau đây:

  • Trước khi xây dựng, hãy tạo một chiến lược về công cụ.
  • Sử dụng ngôn từ rõ ràng và HTML ngữ nghĩa.
  • Thiết kế giản đồ và xử lý dữ liệu đầu vào.
  • Xây dựng các công cụ đáng tin cậy.
  • Kiểm thử và gỡ lỗi.

Tạo chiến lược về công cụ

Giống như khi bạn làm cho bất kỳ ứng dụng phần mềm nào, bước đầu tiên bạn nên làm là lập kế hoạch cho chiến lược công cụ của mình:

  • Mỗi công cụ phải bao gồm một hàm duy nhất. Ví dụ: một công cụ có thể hướng người dùng đến một loại biểu mẫu cụ thể, trong khi một công cụ khác sẽ so khớp các trường nhập dữ liệu với thông tin người dùng. Hãy cẩn thận để không tạo ra các công cụ trùng lặp, vì tác nhân có thể nhầm lẫn về việc nên sử dụng công cụ nào. Hãy tự hỏi: tôi có thể thực hiện nhiều việc bằng cùng một hàm không?
  • Quản lý việc đăng ký công cụ. Đăng ký các công cụ khi chúng hữu ích trong một trạng thái trang nhất định, sau đó huỷ đăng ký khi công cụ không còn sử dụng được nữa.
    • API mệnh lệnh: Bạn có thể quản lý việc đăng ký một cách linh hoạt bằng registerTool và unregisterTool.
    • API khai báo: Bạn có thể quản lý việc đăng ký một cách linh hoạt bằng cách thêm hoặc xoá các thuộc tính công cụ trên biểu mẫu, bằng toolName và toolDescription.
  • Giảm độ phức tạp: Đối với hầu hết các ứng dụng, đăng ký tĩnh nên là phương pháp mặc định.
  • Tin tưởng để tác nhân hoàn thành việc cần làm*. Thay vì viết các chỉ dẫn cứng nhắc hoặc tiêu cực, hãy giả định rằng tác nhân phần mềm có thể hiểu những gì cần thiết để hoàn thành nhiệm vụ, thay vì mong đợi tác nhân phần mềm quản lý chính xác một quy trình gồm nhiều bước.

Mặc dù không có giới hạn về số lượng công cụ được phép, nhưng mỗi công cụ sẽ chiếm một phần của cửa sổ ngữ cảnh và làm tăng thời gian hoàn thành. Bạn cung cấp càng nhiều công cụ và các công cụ càng trùng lặp thì trợ lý càng khó chọn đúng. Thử nghiệm để xác định lựa chọn phù hợp cho ứng dụng của bạn.

Điều này giúp bạn tạo các công cụ riêng lẻ mà không bị trùng lặp mục đích và quản lý thời điểm các công cụ này có sẵn.

Sử dụng ngôn từ rõ ràng và mã ngữ nghĩa

Sử dụng ngôn từ rõ ràng và trực tiếp để đặt tên cho các công cụ cũng như mô tả cách sử dụng chúng. Điều này giúp các tác nhân tìm thấy những gì họ cần, hiểu những gì họ tìm thấy và sử dụng thông tin đó như nhà phát triển mong đợi.

Khi viết tên công cụ, hãy phân biệt quá trình thực thi với quá trình khởi tạo và sử dụng các động từ mô tả chính xác những gì xảy ra. Ví dụ: create-event là một công cụ để tạo sự kiện ngay lập tức, nhưng start-event-creation-process là một công cụ chuyển hướng người dùng đến một biểu mẫu để tạo sự kiện.

Thông tin mô tả rõ ràng phải cho biết chức năng của công cụ và thời điểm sử dụng công cụ đó. Dựa vào ngôn ngữ và lựa chọn ưu tiên tích cực thay vì ngôn ngữ tiêu cực, chẳng hạn như các hạn chế.

Không nên

"Không dùng công cụ này để xem thời tiết."

Các hạn chế phải được ngầm hiểu trong nội dung mô tả rõ ràng.
Nên

"Công cụ này có thể tạo một sự kiện trên lịch, được lên lịch vào một ngày và giờ cụ thể."

Giảm thiểu điện toán nhận thức

Giống như việc bạn nên giảm tải nhận thức cho con người khi hoàn thành các nhiệm vụ phức tạp, bạn cũng nên giảm tải điện toán nhận thức cho mô hình:

  • Chấp nhận thông tin đầu vào thô của người dùng. Tránh yêu cầu tác nhân thực hiện các phép toán hoặc chuyển đổi chuỗi đầu vào. Ví dụ: nếu người dùng nói "11:00 đến 15:00", thì công cụ sẽ chấp nhận đây là một chuỗi. Tránh yêu cầu mô hình tính toán số phút giữa các thời điểm này.
  • Khai báo các loại cụ thể cho tham số, chẳng hạn như chuỗi, số hoặc enum.
  • Giải thích lý do bạn đưa ra những lựa chọn nhất định. Lựa chọn của bạn phải tự giải thích được. Lý do giúp nhân viên đưa ra lựa chọn phù hợp hơn. Ví dụ: nếu bạn điều hành một cửa hàng thương mại điện tử, hãy khai báo loại phí vận chuyển bằng ngôn ngữ tự nhiên thay vì sử dụng một mã nhận dạng không rõ ràng: shipping="Express" thay vì shipping_id=1.

Ưu tiên độ tin cậy

Các tác nhân và con người đều được hưởng lợi từ những công cụ hoạt động như mong đợi:

  • Đặt cơ chế thất bại duyên dáng cho giới hạn về tốc độ. Các công cụ phải cho phép lặp lại một cách hợp lý, chẳng hạn như để so sánh giá. Nếu một công cụ bị giới hạn tốc độ, hãy trả về một lỗi có ý nghĩa hoặc khuyên người dùng tự thực hiện tác vụ.
  • Cập nhật trạng thái giao diện sau khi hoàn tất các hàm. Các tác nhân có thể dựa vào giao diện để lên kế hoạch cho các bước tiếp theo, trong khi các hàm có thể mất nhiều thời gian hơn để hoàn thành so với quá trình tải giao diện. Nhân viên hỗ trợ nên xác nhận rằng chức năng đã hoàn tất sau khi giao diện được cập nhật hoặc yêu cầu cập nhật lại.
  • Xác thực nghiêm ngặt trong mã, xác thực lỏng lẻo trong giản đồ. Bạn nên dùng các ràng buộc và kiểm thử cho những hàm và mã có logic nhị phân. Mặc dù các ràng buộc về giản đồ có thể hữu ích, nhưng không được đảm bảo. Thêm các lỗi mô tả vào mã hàm để cho phép mô hình tự sửa và thử lại bằng các tham số mới, hợp lệ.

Kiểm thử và gỡ lỗi Eval

Tạo các kiểm thử đánh giá và cung cấp các công cụ của bạn để gỡ lỗi. Không giống như các kiểm thử đơn vị xác định, bạn không thể mã hoá cứng các quy trình đánh giá vì đầu ra có thể có những dạng thức không lường trước được.

  • Xác định vấn đề. Bạn có thể trình bày vấn đề của mình như một hợp đồng API, bao gồm loại đầu vào, định dạng đầu ra và mọi ràng buộc bổ sung.
  • Xác định kết quả cơ bản và kết quả lý tưởng. Đặc biệt là với dữ liệu đầu vào dạng văn bản, bạn cần hiểu rõ những loại kết quả nào có thể mang lại cho bạn đầu ra như mong đợi.
  • Xác định cách đánh giá kết quả. Bạn có thể xác định và đo lường kết quả định tính, mang tính chủ quan dựa trên chất lượng thông tin đầu vào, mức độ hữu ích và khả năng hoàn thành nhiệm vụ tiếp theo. Bạn có thể sử dụng một số kỹ thuật để đánh giá kết quả đầu ra, bao gồm cả các bước kiểm tra dựa trên mã cho kết quả đầu ra dựa trên quy tắc (giới hạn ký tự) và LLM-as-a-judge (LLM đóng vai trò là người đánh giá).

Tránh thêm các quy tắc hẹp để vá các vấn đề với một mô hình cụ thể. Ví dụ: nếu bạn thêm một trường chọn cho danh xưng, mô hình có thể đưa ra lựa chọn sai. Thay vì thêm các quy tắc hẹp để vá vấn đề này, hãy trừu tượng hoá và điều chỉnh công cụ của bạn. Bạn nên đặt trường này là không bắt buộc. Sau đó, yêu cầu trợ lý hỏi người dùng xem lựa chọn nào phù hợp để đảm bảo người dùng hài lòng với kết quả.

Tương tác và chia sẻ ý kiến phản hồi

WebMCP đang được thảo luận tích cực và có thể thay đổi trong tương lai. Nếu bạn dùng thử các API này và có ý kiến phản hồi, chúng tôi rất mong được lắng nghe.