Phân bổ công cụ & Lựa chọn công cụ
Những điều bạn cần biết
Số lượng tool bạn cấp cho một agent ảnh hưởng trực tiếp đến độ tin cậy khi agent đó chọn đúng tool cần dùng. Đây không phải là một chi tiết triển khai nhỏ nhặt — đây là một quyết định kiến trúc cốt lõi, quyết định hệ thống multi-agent của bạn có vận hành được trong production hay không.
Vấn đề quá tải tool
Cấp cho một agent duy nhất 18 tool sẽ làm giảm độ tin cậy khi chọn tool. Model phải đối mặt với độ phức tạp quyết định tăng dần theo từng tool được thêm vào, và tỷ lệ lỗi tăng lên khi bộ công cụ ngày càng lớn. Khoảng tối ưu là 4-5 tool cho mỗi agent, được giới hạn đúng theo vai trò cụ thể của agent đó.
Đây không chỉ là vấn đề số lượng — mà còn là vấn đề mức độ liên quan. Một agent tổng hợp (synthesis) KHÔNG nên có tool tìm kiếm web. Một agent tìm kiếm web KHÔNG nên có tool phân tích tài liệu. Khi agent sở hữu những tool nằm ngoài chuyên môn của nó, chúng có xu hướng dùng sai. Một agent tổng hợp có quyền truy cập web_search có thể tự ý chạy tìm kiếm riêng thay vì dùng kết quả tìm kiếm đã được cung cấp sẵn, gây trùng lặp công việc và lãng phí context.
Nguyên tắc: mỗi agent chỉ nhận đúng những tool cần thiết cho vai trò đã định của nó. Không hơn.
Cấu hình tool_choice
Tham số tool_choice kiểm soát cách model tương tác với các tool sẵn có. Có ba chế độ, mỗi chế độ phục vụ một mục đích riêng.
"auto" (mặc định) Model tự quyết định gọi tool hay trả về văn bản. Dùng chế độ này cho hoạt động thông thường, khi model cần sự linh hoạt để trả lời theo kiểu hội thoại nếu không có tool nào phù hợp.
jsonCopy
{
"tool_choice": { "type": "auto" }
}"any" Model BẮT BUỘC phải gọi một tool nhưng được tự chọn tool nào. Dùng chế độ này khi bạn cần đầu ra có cấu trúc được đảm bảo từ một trong nhiều schema — model sẽ luôn tạo ra một lệnh gọi tool, không bao giờ trả về văn bản thuần.
jsonCopy
{
"tool_choice": { "type": "any" }
}Điều này đặc biệt hữu ích trong các pipeline trích xuất dữ liệu. Nếu bạn có nhiều schema trích xuất (một cho hóa đơn, một cho biên lai, một cho hợp đồng) và loại tài liệu chưa xác định, "any" đảm bảo model sẽ chọn một schema và tạo ra đầu ra có cấu trúc thay vì trả lời theo kiểu hội thoại.
Buộc chọn tool cụ thể (Forced selection) Model BẮT BUỘC phải gọi một tool cụ thể được chỉ định tên. Dùng chế độ này để ép các bước bắt buộc đầu tiên — model không thể bỏ qua hay đổi thứ tự thao tác bắt buộc đó.
jsonCopy
{
"tool_choice": { "type": "tool", "name": "extract_metadata" }
}Đây là công cụ để ép buộc thứ tự quy trình. Nếu việc trích xuất metadata phải diễn ra trước khi bất kỳ tool làm giàu dữ liệu (enrichment) nào chạy, forced selection sẽ đảm bảo điều đó. Model không thể tự ý bỏ qua extract_metadata để nhảy thẳng đến bước làm giàu dữ liệu. Sau khi lệnh gọi bắt buộc hoàn tất, các lượt tiếp theo có thể dùng "auto" cho các bước còn lại.
Tool xuyên vai trò được giới hạn phạm vi
Đôi khi một agent cần quyền truy cập không thường xuyên vào một năng lực thuộc về vai trò khác. Cách tiếp cận ngây thơ là định tuyến mọi yêu cầu như vậy qua coordinator. Vấn đề: điều này thêm 2-3 lượt round trip cho mỗi yêu cầu và có thể làm tăng độ trễ lên 40% hoặc hơn.
Giải pháp là một tool xuyên vai trò được giới hạn phạm vi (scoped cross-role tool): một phiên bản bị ràng buộc của năng lực đó, được cấp trực tiếp cho agent cần dùng nó.
Hãy xét một agent tổng hợp thường xuyên cần xác minh những sự thật đơn giản trong quá trình tạo báo cáo. Thiết kế ngây thơ định tuyến mọi yêu cầu xác minh trở lại coordinator, coordinator ủy quyền cho agent tìm kiếm, chờ kết quả, rồi trả về. Với 85% các trường hợp xác minh — những tra cứu đơn giản chỉ mất vài mili giây — chi phí round-trip này là lãng phí.
Cách khắc phục: cấp cho agent tổng hợp một tool verify_fact được giới hạn phạm vi, xử lý trực tiếp các tra cứu đơn giản. Những xác minh phức tạp (cần nhiều nguồn, đối chiếu chéo, hoặc phán đoán tinh tế) vẫn định tuyến qua coordinator. 85% trường hợp đơn giản được xử lý tại chỗ; 15% trường hợp phức tạp dùng pipeline đầy đủ.
Mẫu hình này được kiểm tra trực tiếp trong đề thi (Câu 9). Hãy nắm chắc nó.
Thay thế tool tổng quát bằng phương án bị ràng buộc
Thay vì cấp cho một subagent fetch_url (có thể tải bất cứ thứ gì từ bất cứ đâu), hãy cấp load_document chỉ xác thực URL tài liệu. Tool bị ràng buộc:
- Ngăn chặn việc dùng sai (agent không thể tải bất kỳ URL tùy ý nào)
- Làm rõ mục đích của tool (mô tả cụ thể, không chung chung)
- Giảm rủi ro gây tác dụng phụ ngoài ý muốn (không tải các tài nguyên không phải tài liệu)
Đây là nguyên tắc đặc quyền tối thiểu áp dụng vào thiết kế tool. Mỗi tool nên làm đúng những gì agent cần và không hơn.
Giới hạn tool theo vai trò trong thực tế
Đây là cách phân bổ tool trông như thế nào trong một hệ thống nghiên cứu multi-agent được thiết kế tốt:
| Agent | Tool (4-5 mỗi loại) |
|---|---|
| Tìm kiếm web | search_web, fetch_page, extract_links, save_snippet |
| Phân tích tài liệu | extract_metadata, extract_data_points, summarize_content, verify_claim |
| Tổng hợp | compile_report, verify_fact (giới hạn phạm vi), format_citation, assess_coverage |
| Coordinator | Agent (trước đây là Task, dùng để tạo subagent), review_output, request_revision |
Mỗi agent có đúng những tool nó cần. Agent tổng hợp có một verify_fact được giới hạn phạm vi cho các tra cứu đơn giản. Coordinator kiểm soát quy trình mà không cần truy cập vào các tool chuyên biệt theo lĩnh vực.
Khái niệm chính
Khoảng tối ưu là 4-5 tool cho mỗi agent, được giới hạn theo vai trò của nó. Với các thao tác đơn giản tần suất cao, hãy thêm một tool xuyên vai trò được giới hạn phạm vi trực tiếp vào agent cần dùng nó — điều này tránh được độ trễ round-trip qua coordinator cho trường hợp phổ biến.
Bẫy thi
Bẫy thi: Định tuyến mọi yêu cầu xác minh đơn giản qua coordinator trong khi 85% là các tra cứu đơn giản
Các round-trip qua coordinator thêm 2-3 chặng cho mỗi yêu cầu. Một tool verify_fact được giới hạn phạm vi trên agent tổng hợp xử lý trực tiếp 85% trường hợp đơn giản, cắt giảm độ trễ tới 40%.
Bẫy thi: Dùng tool_choice 'auto' khi cần đầu ra có cấu trúc bắt buộc
Với 'auto', model có thể trả về văn bản hội thoại thay vì gọi tool. Dùng 'any' để đảm bảo có lệnh gọi tool, hoặc forced selection để đảm bảo gọi đúng một tool cụ thể.
Bẫy thi: Cấp cho một agent 18 tool và kỳ vọng nó chọn tool đáng tin cậy
Độ tin cậy khi chọn tool giảm dần khi số lượng tool tăng lên. Khoảng tối ưu là 4-5 tool cho mỗi agent. Càng nhiều tool thì độ phức tạp quyết định và tỷ lệ lỗi chọn sai càng tăng.
Bẫy thi: Cấp cho subagent một tool fetch_url tổng quát trong khi load_document bị ràng buộc là đủ
Các tool tổng quát tạo điều kiện cho việc dùng sai. Phương án bị ràng buộc (load_document chỉ xác thực URL tài liệu) áp dụng nguyên tắc đặc quyền tối thiểu và làm rõ mục đích của tool hơn.
Tình huống luyện tập
Không tìm thấy câu hỏi luyện tập "q-2-3-001".
Bài tập thực hành
Cấu hình phân bổ tool trong một hệ thống multi-agent
Bạn sẽ học được gì
- Giới hạn tool theo vai trò agent bằng quy tắc 4-5 tool cho mỗi agent
- Triển khai tool xuyên vai trò được giới hạn phạm vi để tránh độ trễ round-trip qua coordinator
- Cấu hình các chế độ tool_choice (auto, any, forced) cho các yêu cầu quy trình khác nhau
- Áp dụng thiết kế tool theo nguyên tắc đặc quyền tối thiểu bằng cách thay thế tool tổng quát bằng phương án bị ràng buộc
- Xác minh rằng việc phân bổ tool ngăn chặn tình trạng dùng sai tool xuyên vai trò trong hệ thống multi-agent
Các bước
Vì sao: Quá tải tool làm giảm độ tin cậy khi chọn tool. Đề thi kiểm tra nguyên tắc mỗi agent nên có 4-5 tool được giới hạn theo vai trò cụ thể của nó. Cấp cho một agent duy nhất 18 tool là một anti-pattern đã biết, gây ra định tuyến sai.
Bạn sẽ thấy: Một object cấu hình hoặc bảng liệt kê ba agent, mỗi agent có đúng 4-5 tool. Không tool nào xuất hiện ở nhiều hơn một vai trò agent (trừ các tool xuyên vai trò được giới hạn phạm vi thêm vào sau). Tên tool thể hiện rõ mục đích và phạm vi của chúng.
Vì sao: Định tuyến mọi yêu cầu xác minh sự thật qua coordinator thêm 2-3 lượt round trip và tới 40% độ trễ. Đề thi kiểm tra mẫu hình tool xuyên vai trò được giới hạn phạm vi — cấp cho agent một phiên bản bị ràng buộc của năng lực đó cho 85% trường hợp đơn giản, chỉ định tuyến các trường hợp phức tạp qua coordinator.
Bạn sẽ thấy: Một tool verify_fact được thêm vào bộ tool của agent tổng hợp với mô tả giới hạn rõ ràng nó chỉ dùng cho các tra cứu đơn nguồn đơn giản và nêu rằng các xác minh đa nguồn phức tạp cần leo thang lên coordinator.
Vì sao: Forced selection ép buộc thứ tự quy trình. Đề thi kiểm tra kiến thức của bạn về cả ba chế độ tool_choice: auto cho phép model tự do lựa chọn, any đảm bảo có lệnh gọi tool, và forced selection đảm bảo gọi đúng một tool cụ thể. Điều này ngăn model bỏ qua các bước bắt buộc.
Bạn sẽ thấy: Một cấu hình agent phân tích tài liệu trong đó lệnh gọi API đầu tiên dùng tool_choice với type: tool và name: extract_metadata, các lệnh gọi tiếp theo chuyển sang tool_choice: auto cho các bước phân tích còn lại.
Vì sao: Điều này áp dụng nguyên tắc đặc quyền tối thiểu vào thiết kế tool. Một tool fetch_url tổng quát có thể tải bất cứ thứ gì từ bất cứ đâu, tạo điều kiện cho việc dùng sai. Một load_document bị ràng buộc xác thực URL sẽ ngăn agent tải các tài nguyên tùy ý. Đề thi kiểm tra trực tiếp mẫu hình này.
Bạn sẽ thấy: Một định nghĩa tool load_document bao gồm logic xác thực URL (kiểm tra phần mở rộng file tài liệu hoặc domain đáng tin cậy) và từ chối các URL không phải tài liệu với thông báo lỗi rõ ràng.
Vì sao: Kiểm thử đầu-cuối xác thực rằng việc phân bổ tool của bạn hoạt động đúng trong thực tế. Dùng sai tool xuyên vai trò — chẳng hạn như agent tổng hợp tự chạy tìm kiếm web riêng thay vì dùng kết quả đã được cung cấp — là một lỗi phổ biến mà đề thi kỳ vọng bạn ngăn chặn thông qua việc giới hạn phạm vi đúng cách.
Bạn sẽ thấy: Một log chạy thử cho thấy: agent tìm kiếm web chỉ dùng tool của nó, agent phân tích tài liệu bắt đầu bằng extract_metadata (bị ép buộc), và agent tổng hợp dùng compile_report cộng với verify_fact cho các kiểm tra đơn giản. Không agent nào gọi tool nằm ngoài bộ tool được gán cho nó.