Thiết kế tool có mô tả rõ ràng và ranh giới tách bạch

Khi bạn đưa cho Claude nhiều tool, Claude phải tự chọn dùng tool nào cho từng yêu cầu. Nó chọn dựa vào đâu? Chủ yếu dựa vào tên và phần mô tả (description) bạn viết cho mỗi tool.

Bài này giúp bạn trả lời: vì sao agent hay chọn nhầm tool, và sửa bằng cách nào cho đúng gốc?

Ví dụ xuyên suốt: trợ lý tra cứu nội bộ của công ty logistics

Một công ty logistics dựng trợ lý giúp nhân viên tra cứu tài liệu. Bản đầu có ba tool:

Và system prompt có câu: "Khi nhân viên nhắc tới hợp đồng, luôn dùng search_docs."

Sau một tuần, nhóm thấy ba vấn đề:

1. Hỏi "quy trình xin nghỉ phép thế nào?", trợ lý lúc dùng search_docs, lúc dùng search_wiki, kết quả không ổn định.
2. Đưa một file PDF bảng giá, có người muốn trích bảng số liệu, có người muốn tóm tắt, nhưng process_file làm gì thì không ai đoán trước được.
3. Hỏi "hợp đồng lao động thời vụ nghỉ phép mấy ngày?" (thông tin nằm trong wiki nhân sự), trợ lý vẫn đi tìm trong search_docs vì thấy chữ "hợp đồng".

Mô tả tool là thứ Claude dựa vào để chọn

Tài liệu của Anthropic viết rằng mô tả thật chi tiết là yếu tố quan trọng nhất quyết định tool hoạt động tốt hay không, và khuyên mỗi mô tả nên có ít nhất 3–4 câu, nhiều hơn nếu tool phức tạp.

"Tìm tài liệu" và "Tìm thông tin" gần như cùng nghĩa. Claude không có cách nào biết tool nào hợp với câu hỏi về nghỉ phép, nên chọn kiểu may rủi. Đây là vấn đề đầu tiên trong ví dụ.

Một mô tả tốt trả lời được các câu sau:

• Tool làm gì, trả về gì.
• Đầu vào có định dạng thế nào.
• Khi nào nên dùng, và khi nào không nên dùng, nhất là so với tool nghe giống nó.
• Ví dụ vài câu hỏi hợp với tool này.
• Giới hạn và trường hợp biên: không tìm được gì, tài liệu quá cũ, v.v.

Viết lại search_docs:

search_docs: Tìm trong kho hợp đồng và văn bản pháp lý đã ký với khách hàng
và đối tác (file PDF đã scan). Đầu vào là từ khoá hoặc mã hợp đồng dạng HD-2026-0123.
Dùng khi cần điều khoản, giá, thời hạn trong một hợp đồng cụ thể.
Không dùng cho quy trình, chính sách nội bộ hay câu hỏi nhân sự:
những thứ đó nằm trong search_wiki.
Ví dụ: "phí phạt giao trễ trong hợp đồng với kho Bình Dương".

Đổi tên để hết chồng chéo

Đôi khi mô tả viết kỹ rồi mà tên vẫn gây nhầm. search_docs và search_wiki nghe như cùng một việc. Đổi tên cho nói đúng phạm vi:

Tài liệu của Anthropic cũng khuyên đặt tên có tiền tố theo dịch vụ hoặc theo loại dữ liệu, ví dụ github_list_prs, slack_send_message, để các tool không lẫn vào nhau.

Tách tool đa năng thành tool có việc rõ ràng

process_file là kiểu tool đa năng: một tên, nhiều việc, mỗi lần làm một kiểu. Claude không biết gọi nó sẽ được gì, người viết code gọi nó cũng không biết sẽ nhận kết quả dạng nào.

Cách sửa là tách thành nhiều tool, mỗi tool có đầu vào và đầu ra rõ ràng:

Đề thi gọi đây là tách tool chung chung thành tool theo mục đích, có hợp đồng đầu vào, đầu ra rõ ràng (purpose-specific tools with defined input/output contracts).

System prompt cũng ảnh hưởng tới việc chọn tool

Vấn đề thứ ba trong ví dụ không nằm ở tool, mà ở câu "khi nhân viên nhắc tới hợp đồng, luôn dùng search_docs". Câu này gắn một từ khoá với một tool. Hễ thấy chữ "hợp đồng", Claude bị kéo về search_docs, kể cả khi mô tả các tool đã viết rất rõ.

Đề thi gọi đây là chỉ dẫn nhạy với từ khoá (keyword-sensitive instructions). Cách sửa là bỏ kiểu dặn theo từ khoá, để mô tả tool làm việc của nó, hoặc viết lại theo ý nghĩa: "Câu hỏi về điều khoản trong một hợp đồng cụ thể đã ký thì dùng search_signed_contracts."