Một AI Agent nên có bao nhiêu tool? Nhiều tool có làm lựa chọn kém chính xác hơn?

Model chọn tool từ tín hiệu trong yêu cầu, tên tool, mô tả và schema tham số. Anthropic cũng nêu rõ model dựa vào yêu cầu của người dùng và phần mô tả tool để quyết định. Khi candidate set tăng, một số dạng nhiễu xuất hiện:

1. Semantic overlap: search_customer, find_contact, lookup_account đều có vẻ phù hợp với cùng một câu hỏi.
2. Granularity mismatch: một tool rộng như manage_order cạnh nhiều tool nhỏ như order.cancel và order.update_address khiến boundary không rõ.
3. Description collision: các mô tả chỉ nói “dùng để quản lý dữ liệu” mà không nêu khi nào dùng, khi nào không dùng.
4. Schema ambiguity: tham số tự do như action, payload hoặc query khiến nhiều ý định cùng ánh xạ vào một contract.
5. Irrelevant exposure: tool tài chính, HR và deployment xuất hiện trong tác vụ hỗ trợ khách hàng dù không liên quan.
6. No-tool confusion: agent gọi một tool gần đúng ngay cả khi nên trả lời trực tiếp, hỏi lại hoặc từ chối.

Vì vậy, “ít tool hơn” chỉ hữu ích nếu tập rút gọn vẫn chứa tool đúng và không làm mất khả năng hoàn thành tác vụ.

Có thể dùng bốn câu hỏi để thiết kế active set:

• Một bước có bao nhiêu intent hợp lệ? Nếu bước chỉ đọc thông tin đơn hàng, không cần expose tool ghi dữ liệu.
• Các tool khác nhau rõ đến mức nào? Năm tool đồng nghĩa có thể khó hơn mười lăm tool thuộc các domain tách biệt.
• Sai lựa chọn gây hậu quả gì? Với read-only, có thể chấp nhận candidate set rộng hơn. Với thanh toán, quyền truy cập hoặc production deployment, cần allowlist rất hẹp và policy độc lập.
• Agent có thể định tuyến trước không? Nếu có domain router hoặc workflow state rõ ràng, chỉ load namespace phù hợp sau khi xác định domain.

Heuristic 5–15 active tools mỗi bước phù hợp để bắt đầu test vì đủ nhỏ để quan sát lỗi và đủ rộng cho nhiều use case. Nếu cần nhiều hơn, không nên tự động kết luận thiết kế sai. Hãy đo kết quả theo từng nhóm tool. Ngược lại, agent chỉ có ba tool nhưng cả ba đều quá rộng vẫn có thể tạo ra tool call nguy hiểm hoặc khó kiểm soát.

Một kiến trúc production có thể đi theo luồng: request → intent/domain router → policy filter → tool retrieval → active candidate set → model selection → argument validation → authorization → executor.

Router trước tiên xác định domain như support, billing hay infrastructure. Policy filter loại tool agent hoặc người dùng không được phép dùng. Tool retrieval xếp hạng các tool còn lại theo mô tả, metadata, workflow state và dữ liệu cần truy cập. Chỉ top candidates được materialize vào context; tool khác vẫn nằm trong catalog và có thể được load ở bước sau. OpenAI Agents SDK hỗ trợ deferred loading, tool search, namespace và dynamic filtering cho MCP; các cơ chế này phù hợp với cách tiếp cận progressive disclosure.

Cần tách rõ hai quyết định: retrieval chọn tool nào đáng để model cân nhắc, còn authorization quyết định tool call đã chọn có được phép thực thi hay không. Router hay vector search có thể bỏ sót hoặc xếp hạng sai; vì vậy executor vẫn phải deny-by-default, kiểm tra tenant, action, resource, giới hạn và approval.

Mỗi tool nên có một mục đích rõ, tên theo domain và động từ như order.get, shipment.track, refund.create_draft. Mô tả cần trả lời bốn câu: tool làm gì, dùng khi nào, không dùng khi nào, và yêu cầu/precondition nào phải có. Với tool dễ nhầm, hãy nêu negative guidance, ví dụ: “không dùng để thực thi hoàn tiền; chỉ tạo bản nháp”.

Schema nên dùng kiểu dữ liệu cụ thể, enum, required fields, giới hạn độ dài/số lượng và additionalProperties: false khi phù hợp. Tránh nhận cả câu lệnh tự do hoặc object payload không có cấu trúc. OpenAI Agents SDK khuyến nghị strict JSON Schema cho function tools; Anthropic nhấn mạnh mô tả chi tiết và cho phép thêm ví dụ đầu vào cho tool có tham số phức tạp.

Khi hai tool khác nhau chủ yếu vì backend provider nhưng cùng một ý định nghiệp vụ, cân nhắc đặt một façade tool ổn định và để backend chọn provider. Khi hai action có rủi ro khác nhau, ví dụ draft và execute, nên tách tool để policy và audit rõ ràng. Gộp hay tách phải dựa vào semantic boundary và quyền, không chỉ để đạt một target count đẹp.

Berkeley Function Calling Leaderboard đánh giá nhiều tình huống như nhiều function candidates, parallel calls, relevance/irrelevance và missing functions. Điều này cho thấy function calling không chỉ là chọn một tên tool; còn có quyết định không gọi, chọn đủ tập tool và truyền đúng tham số. Tuy nhiên, benchmark công khai không thay thế eval theo schema và traffic riêng của doanh nghiệp.

Hãy tạo một bộ golden test gồm request phổ biến, câu hỏi mơ hồ, no-tool cases, tool không có trong candidate set, tool gần nghĩa, prompt injection và multi-step tasks. Với mỗi request, gắn expected outcome: no_tool, ask_clarification, một tool cụ thể hoặc một tập tool được phép. Sau đó so sánh ít nhất ba cấu hình: full catalog; routing theo domain; retrieval top-k động.

Các chỉ số nên gồm:

• Tool selection accuracy: đúng tool hoặc đúng tập tool.
• No-tool precision/recall: không gọi tool khi không cần và không bỏ tool khi cần.
• Argument validity/correctness: schema hợp lệ và giá trị đúng resource.
• Unauthorized-call rate: tool call bị policy chặn; mục tiêu production cho side effect trái phép phải là zero execution.
• Clarification rate: hỏi lại đúng lúc thay vì đoán.
• Task success, latency, token và cost: tối ưu selection nhưng không làm workflow chậm hoặc đắt quá mức.

Cách tìm ngưỡng phù hợp bằng thử nghiệm

Giữ cố định model, prompt, temperature, tool definitions và eval set; chỉ thay đổi candidate strategy. Chạy nhiều lần nếu model có tính ngẫu nhiên và lưu toàn bộ trace. Bắt đầu với active set nhỏ, sau đó tăng theo nhóm domain hoặc top-k: 5, 10, 15, 25 chẳng hạn. Đây là các mốc thử nghiệm, không phải giới hạn khuyến nghị chung.

Phân tích confusion matrix theo từng cặp tool. Nếu customer.search thường bị nhầm với contact.search, sửa boundary hoặc routing trước khi đổi model. Nếu tool đúng thường không được retrieval đưa vào candidate set, lỗi nằm ở router/retriever chứ không phải selector. Nếu model chọn đúng nhưng arguments sai, tập trung vào schema, examples và bước resolve entity. Nếu tool call đúng nhưng không được phép, policy filter trước model và authorization sau model đang không đồng bộ.

Chỉ mở rộng active set khi task success tăng mà selection error, no-tool false positive, latency và cost vẫn nằm trong SLO. Canary theo use case hoặc tenant; không thay toàn bộ catalog cùng lúc.

Khi nào nên gộp, tách hoặc chuyển sang nhiều agent?

Gộp tool khi nhiều tool cùng thể hiện một capability nghiệp vụ, có cùng quyền và cùng hậu quả, chỉ khác chi tiết provider mà backend có thể tự xử lý. Tách tool khi action có precondition, scope hoặc risk tier khác nhau; đặc biệt nên tách read, draft, execute và delete. Dùng router/namespace khi catalog lớn nhưng domain có ranh giới rõ. Tách agent chuyên trách khi các domain cần instruction, dữ liệu, owner, credential và eval khác nhau — không chỉ vì số tool tăng.

Các tín hiệu cảnh báo gồm: tool descriptions phải liên tục bổ sung ngoại lệ; cùng một request thường gọi luân phiên nhiều tool gần nghĩa; model chọn tool “bao trùm” thay vì action cụ thể; active schema chiếm nhiều context; tool nhạy cảm xuất hiện trong bước không liên quan; hoặc thay đổi một tool làm regression ở domain khác.

Không nên dùng multi-agent chỉ để che một catalog thiết kế kém. Mỗi specialist vẫn cần candidate set rõ, authorization độc lập, observability và contract test. Handoff giữa agent cũng là một quyết định phải benchmark và bảo vệ.

Checklist trước production

1. Lập inventory tool theo domain, action, owner, dữ liệu, side effect và risk tier.
2. Xác định tool catalog, authorized set và active set riêng biệt.
3. Loại tool trùng nghĩa; chuẩn hóa naming, description, negative guidance và strict schema.
4. Đặt domain/workflow router trước tool selection; lọc quyền trước khi materialize candidates.
5. Giữ authorization và business policy ở backend sau khi model tạo tool call.
6. Xây golden eval có no-tool, ambiguous, missing-tool, similar-tool, multi-step và adversarial cases.
7. Benchmark full catalog với routed set và retrieval top-k trên cùng dữ liệu.
8. Theo dõi selection, arguments, task success, deny, clarification, latency, token và cost theo tool pair.
9. Rollout theo shadow/canary; có kill switch cho tool, namespace, agent và tenant.
10. Review tool không còn dùng, description drift, schema version và confusion matrix định kỳ.

Kết luận thực tế: agent không cần “càng nhiều tool càng mạnh”. Một agent tốt cần đúng tool, đúng thời điểm, đúng quyền và một candidate set đã được kiểm chứng bằng eval.