2.3 Tool Distribution & Tool Choice

Những gì cần nắm

Số lượng tool bạn giao cho một agent ảnh hưởng trực tiếp tới việc nó chọn đúng tool ổn định tới đâu. Nghe như chi tiết implementation. Không phải — đó là quyết định kiến trúc, quyết định luôn chuyện hệ multi-agent của bạn chạy nổi trên production hay không.

Vấn đề quá tải tool

Giao cho một agent 18 tool thì độ tin cậy khi chọn tụt xuống. Mỗi tool thêm vào là thêm độ phức tạp cho quyết định, và tỉ lệ lỗi tăng theo kích thước bộ tool. Khoảng tối ưu là 4-5 tool mỗi agent, giới hạn theo đúng vai trò của agent đó.

Nhưng số lượng không phải toàn bộ câu chuyện — mức liên quan cũng nặng ký ngang vậy. Một synthesis agent KHÔNG nên có tool web search. Một web search agent KHÔNG nên có tool phân tích tài liệu. Cho agent những tool nằm ngoài chuyên môn của nó thì nó sẽ có xu hướng dùng sai: một synthesis agent có web_search có thể tự đi tìm kiếm thay vì dùng kết quả đã được đưa tận tay, vừa làm trùng việc vừa phí context.

Nguyên tắc: mỗi agent chỉ nhận đúng những tool cần cho vai trò đã định. Không hơn.

Gộp các tool gần trùng nhau

Tách theo vai trò là câu trả lời hiển nhiên cho quá tải tool. Nó là câu trả lời sai khi các tool đều làm cùng một loại việc.

Lấy ví dụ một data platform server có 22 tool: ba tool query, mỗi nguồn dữ liệu một cái, và 19 phép biến đổi — pivot_table, calculate_percentile, normalise_currency, cứ thế xuống. Tách theo vai trò thì bạn giao cho một transformation agent 19 tool, tức là dời đúng vấn đề cũ xuống thấp một tầng. Agent vẫn không chọn nổi cho ổn định.

19 tool đó nên gộp lại, vì chúng chung một hình dạng. Dữ liệu vào, một phép toán, dữ liệu ra:

{
  "name": "transform_data",
  "description": "Apply a transformation to a dataset. Use transform_type to select the operation.",
  "input_schema": {
    "type": "object",
    "properties": {
      "dataset": { "type": "string" },
      "transform_type": {
        "type": "string",
        "enum": ["pivot", "percentile", "normalise_currency", "..."]
      },
      "options": { "type": "object" }
    },
    "required": ["dataset", "transform_type"]
  }
}

Hai mươi hai tool còn bốn. Không mất gì cả: mọi phép biến đổi vẫn gọi được, giờ dưới dạng một giá trị enum model chọn ngay trong một lệnh gọi, thay vì một tool phải mò ra giữa mười chín description gần y hệt nhau. Độ chính xác khi chọn tăng vì lựa chọn khó đã nhỏ lại, không phải vì năng lực nhỏ lại.

Vậy ca nào dùng cách nào?

Bộ tool đang ở tình trạng…	Cách sửa
Số lượng còn kham được, nhưng hai cái đọc lên na ná nhau	Mài lại description (Task Statement 2.1)
Các việc khác nhau (query, transform, export)	Tách theo vai trò, mỗi agent 4-5 tool
Các biến thể của cùng một việc, chung một hình dạng	Gộp thành một tool có tham số
Làm được nhiều hơn mức agent nên được phép	Siết lại (mục kế tiếp)

Dòng đầu tiên là chỗ thí sinh hay vấp. Task Statement 2.1 dạy description là cách sửa misrouting, và nó đúng khi bộ tool còn đủ nhỏ để suy luận. Một agent chọn get_customer thay vì lookup_order trong bộ năm tool là vấn đề description. Cùng triệu chứng đó trong bộ 22 tool thì không: agent đã vượt qua điểm mà chất lượng description nào cứu nổi, và viết lại cả 22 description để nguyên độ phức tạp của quyết định ở chỗ cũ. Cùng triệu chứng, khác bệnh. Đếm số tool trước khi chọn thuốc.

Để ý dòng thứ ba: nó kéo ngược hướng, và đề thi thích đúng cái mâu thuẫn này. Gộp làm giảm số tool mà agent phải chọn giữa. Siết làm giảm phạm vi mà một tool với tới được. Gộp 19 phép biến đổi vào transform_data không trao cho agent quyền năng mới, nên nó không phá vỡ least privilege. Thay fetch_url bằng load_document làm việc ngược lại, và cả hai đều có thể đúng trong cùng một hệ.

Một cách sửa không phải cách sửa: dời bớt tool sang một MCP server thứ hai. Ranh giới server là vô hình với model. Client đưa cho nó mọi tool từ mọi server đã kết nối dưới dạng một danh sách phẳng, nên vấn đề 22 tool chia sang hai server vẫn là vấn đề 22 tool.

Cấu hình tool_choice

Tham số tool_choice điều khiển cách model tương tác với các tool sẵn có. Ba thiết lập, ba nhiệm vụ khác nhau.

"auto" (mặc định) Model tự quyết gọi tool hay trả text. Dùng cho vận hành chung, khi model cần linh hoạt để trả lời theo kiểu hội thoại lúc không lệnh gọi tool nào phù hợp.

{
  "tool_choice": { "type": "auto" }
}

"any" Model BẮT BUỘC gọi một tool nhưng tự chọn cái nào. Dùng khi bạn cần đảm bảo có structured output 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ả text thuần.

{
  "tool_choice": { "type": "any" }
}

Pipeline trích xuất là chỗ thiết lập này phát huy. 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à chưa biết loại tài liệu, "any" đảm bảo model chọn lấy một cái và cho ra structured output thay vì trả lời kiểu hội thoại.

Forced selection Model BẮT BUỘC gọi một tool cụ thể đã chỉ tên. Dùng để cưỡng chế bước bắt buộc đầu tiên — model không thể bỏ qua hay đảo thứ tự thao tác bắt buộc đó.

{
  "tool_choice": { "type": "tool", "name": "extract_metadata" }
}

Đây là công cụ để cưỡng chế thứ tự workflow. Nếu bước trích xuất metadata phải chạy trước mọi tool enrichment, forced selection đảm bảo điều đó. Model không thể quyết định bỏ qua extract_metadata để nhảy thẳng sang enrichment. Sau khi lệnh gọi bị ép hoàn tất, các lượt sau dùng "auto" cho phần còn lại.

Scoped cross-role tool

Đôi khi một agent thỉnh thoảng cần một năng lực vốn thuộc vai trò khác. Cách làm ngây thơ là đẩy mọi yêu cầu kiểu đó qua coordinator. Vấn đề: cách này thêm 2-3 vòng round trip mỗi yêu cầu và có thể làm độ trễ tăng 40% trở lên.

Giải pháp là một scoped cross-role tool: một phiên bản bị siết của năng lực đó, giao thẳng cho agent cần nó.

Giả sử một synthesis agent liên tục phải xác minh những sự kiện đơn giản trong lúc sinh báo cáo. Thiết kế ngây thơ đẩy mọi lượt xác minh về coordinator, coordinator ủy thác cho search agent, chờ kết quả rồi trả lại. Với 85% lượt xác minh — những tra cứu đơn giản chạy trong mili-giây — vòng round trip đó là phí toàn tập.

Cách sửa: cho synthesis agent một tool verify_fact bị giới hạn, xử lý thẳng các tra cứu đơn giản. Những lượt xác minh phức tạp (cần nhiều nguồn, đối chiếu chéo, hoặc phải phán đoán thật) vẫn đi qua coordinator. 85% ca đơn giản xử tại chỗ; 15% ca phức tạp dùng pipeline đầy đủ.

Câu hỏi mẫu số 9 trong exam guide hỏi thẳng mô hình này.

Thay tool chung chung bằng phương án bị siết

Thay vì cho subagent fetch_url (lấy được bất cứ thứ gì từ bất cứ đâu), hãy cho nó load_document chỉ nhận URL tài liệu đã qua kiểm tra. Tool bị siết sẽ:

Ngăn dùng sai (agent không fetch được URL tùy ý)
Làm mục đích của tool rõ hơn (description cụ thể, không chung chung)
Giảm rủi ro tác dụng phụ ngoài ý muốn (không fetch những tài nguyên không phải tài liệu)

Đây là least privilege áp cho thiết kế tool. Mỗi tool làm đúng thứ agent cần và không gì hơn.

Phân bổ tool theo vai trò trong thực tế

Đây là hình dung về phân bổ tool trong một hệ multi-agent nghiên cứu được thiết kế tốt:

Agent	Tool (4-5 mỗi agent)
Web Search	`search_web`, `fetch_page`, `extract_links`, `save_snippet`
Document Analysis	`extract_metadata`, `extract_data_points`, `summarize_content`, `verify_claim`
Synthesis	`compile_report`, `verify_fact` (bị siết), `format_citation`, `assess_coverage`
Coordinator	`Agent` (trước đây là `Task`, dùng để spawn subagent), `review_output`, `request_revision`

Mỗi agent có đúng những tool nó cần. Synthesis agent có verify_fact bị siết cho các tra cứu đơn giản. Coordinator điều hành workflow mà bản thân không giữ tool chuyên môn nào.

Bẫy thi

Tình huống luyện tập

Một synthesis agent thường xuyên trả quyền về coordinator chỉ để xác minh sự kiện đơn giản, thêm 2-3 vòng round trip mỗi tác vụ và 40% độ trễ. Phân tích cho thấy 85% lượt xác minh là tra cứu đơn giản. Giải pháp hiệu quả nhất là gì?

A. Cho synthesis agent một tool verify_fact bị siết dành cho tra cứu đơn giản, chỉ đẩy các lượt xác minh phức tạp qua coordinator
B. Tăng mức song song của coordinator để các yêu cầu xác minh được xử lý đồng thời và độ trễ xếp hàng biến mất hoàn toàn
C. Cache mọi kết quả xác minh ở tầng coordinator để các lượt tra cứu lặp lại trả về tức thì, không phải đi thêm vòng nào tới subagent
D. Bỏ hẳn bước xác minh sự kiện khỏi workflow synthesis để không tác vụ nào phải chịu độ trễ round trip

Đáp án & giải thích

Đúng: A

A — Một scoped cross-role tool xử lý thẳng 85% ca đơn giản, triệt tiêu độ trễ round trip. Ca phức tạp vẫn đi qua coordinator để được xử lý đúng cách.
B — Xử lý nhanh hơn không loại bỏ được những vòng round trip thừa. Độ trễ đến từ chính phần định tuyến, không phải từ tốc độ coordinator.
C — Cache giúp cho các lượt tra cứu lặp lại nhưng không chạm tới chi phí round trip của lần xác minh đầu tiên, mà lần đầu mới là đa số.
D — Bỏ xác minh là đánh đổi chất lượng output. Mục tiêu là làm xác minh nhanh hơn cho ca phổ biến, không phải bỏ luôn.

Nguồn

Claude Certified Architect Foundations Exam Guide — Domain 2, Task Statement 2.3 — Anthropic
Tool use — Anthropic API Documentation — Anthropic
Claude Agent SDK — Tool Configuration — Anthropic

Exam Simulator

Năm câu trắc nghiệm theo format đề thi về Tool Distribution & Tool Choice. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

A. Tăng mức song song của coordinator để xử lý các lượt xác minh nhanh hơn
B. Cache kết quả xác minh ở coordinator để các lượt tra cứu lặp lại trả về tức thì
C. Cho synthesis agent một tool verify_fact bị siết của riêng nó, chỉ đẩy các lượt kiểm tra phức tạp về coordinator
D. Bỏ hẳn bước xác minh sự kiện khỏi workflow synthesis, thế là hết round trip và hết độ trễ do nó gây ra

Đáp án & giải thích

Đúng: C

C đúng vì một scoped cross-role tool xử lý 85% ca đơn giản ngay tại chỗ, mà đó chính là nơi độ trễ round trip đang đổ vào. Phần phức tạp còn lại vẫn đi qua coordinator, nên không mất gì.
A sai vì coordinator nhanh hơn không gỡ được những vòng round trip thừa. Độ trễ đến từ chính việc định tuyến, không phải từ tốc độ coordinator làm việc.
B sai vì cache chỉ giúp từ lần thứ hai một sự kiện được kiểm tra. Ở đây lần xác minh đầu tiên mới là đa số, và chúng vẫn trả đủ giá round trip.
D sai vì bỏ xác minh là đổi chất lượng lấy tốc độ. Mục tiêu là làm ca phổ biến nhanh lên, không phải ngừng kiểm tra.

Câu 2

Một pipeline phân tích tài liệu luôn phải trích xuất metadata trước khi chạy bất kỳ tool enrichment nào. Cấu hình tool_choice nào cưỡng chế được điều đó?

A. tool_choice: { type: “tool”, name: “extract_metadata” } cho lệnh gọi đầu tiên, rồi { type: “auto” } sau đó
B. tool_choice: { type: “auto” }, vì đằng nào model cũng trích xuất metadata trước
C. tool_choice: { type: “any” }, vì model buộc phải gọi tool và sẽ chọn extract_metadata
D. Đặt extract_metadata đầu tiên trong mảng tools, vì model ưu tiên cái nào đứng trước

Đáp án & giải thích

Đúng: A

A đúng vì forced selection đảm bảo extract_metadata chạy trước: model không bỏ qua cũng không đảo thứ tự được. Chuyển sang “auto” sau đó để các tool enrichment được chọn theo đúng năng lực của chúng.
B sai vì “auto” để model tự quyết có gọi tool hay không. Nó có thể nhảy thẳng sang enrichment hoặc trả lời bằng văn xuôi.
C sai vì “any” đảm bảo có một lệnh gọi tool nhưng không đảm bảo là tool nào. Một tool enrichment cũng thỏa mãn điều kiện đó y như extract_metadata.
D sai vì vị trí trong mảng không đảm bảo thứ tự nào cả. Việc chọn tool dựa trên description và ngữ cảnh, không dựa trên chỗ đứng trong danh sách.

Câu 3

Một agent có 18 tool và liên tục chọn sai tool cho query của người dùng. Nguyên nhân gốc nhiều khả năng là gì?

A. Tool description cần chi tiết hơn hẳn mức hiện tại để model phân biệt được
B. Model cần few-shot examples để học cách chọn đúng từ các ví dụ giải sẵn trong prompt
C. Nên đặt tool_choice là “any” để luôn ép được một lệnh gọi tool
D. Agent có quá nhiều tool, khiến độ tin cậy khi chọn tụt xuống, và khoảng hợp lý là 4-5 tool giới hạn theo vai trò

Đáp án & giải thích

Đúng: D

D đúng vì độ tin cậy khi chọn rơi dần theo số lượng tool, và 18 lựa chọn đã vượt xa mức mà description còn gánh nổi quyết định. Giới hạn agent xuống 4-5 tool khớp vai trò của nó mới là cách sửa.
A sai vì description tốt hơn có giúp nhưng không gỡ nổi chính số lượng lựa chọn. Dù viết hoàn hảo, 18 tool vẫn là quá nhiều để chọn cho ổn định.
B sai vì few-shot examples thêm token overhead vào mọi request mà không giảm số lựa chọn model phải cân nhắc.
C sai vì “any” ép gọi tool nhưng không giúp model chọn đúng trong 18 cái. Nó còn bỏ luôn lựa chọn trả lời bằng text, làm mọi thứ tệ hơn.

Câu 4

Một subagent hiện có quyền dùng fetch_url, tool lấy được mọi URL từ mọi domain. Cải thiện đúng theo least privilege là gì?

A. Thêm phần kiểm tra URL vào system prompt để giới hạn thứ agent được fetch
B. Thay fetch_url bằng load_document, tool kiểm tra URL tài liệu và từ chối phần còn lại
C. Giữ nguyên fetch_url và thêm log request để team giám sát mọi thứ agent fetch
D. Bỏ hẳn fetch_url và đẩy mọi lượt fetch qua coordinator, để coordinator sở hữu toàn bộ request đi ra

Đáp án & giải thích

Đúng: B

B đúng vì đổi một tool chung chung lấy một tool bị siết là đưa least privilege vào chính interface. load_document nhận URL tài liệu, từ chối phần còn lại, và nhờ vậy đọc lên cũng hết mập mờ.
A sai vì chỉ dẫn trong system prompt chỉ mang tính khuyến nghị. Model vẫn gọi fetch_url với URL nào nó thích, nên ràng buộc phải nằm trong tool.
C sai vì log chỉ bắt được việc dùng sai sau khi nó đã xảy ra. Ngăn ngay trong tool tốt hơn phát hiện trên dashboard.
D sai vì đẩy mọi lượt fetch qua coordinator là thêm một vòng round trip cho một thao tác phổ biến. Một tool cục bộ bị siết cho cùng mức an toàn mà không kèm độ trễ.

Câu 5

Một pipeline trích xuất xử lý hóa đơn, biên lai và hợp đồng. Loại tài liệu chưa biết ở đầu vào. Bạn cần đảm bảo có structured output từ đúng schema. Nên dùng tool_choice nào?

A. tool_choice: { type: “auto” }, vì model sẽ nhận ra loại tài liệu mà không cần bị ép
B. tool_choice: { type: “tool”, name: “extract_invoice” }, ép schema hóa đơn cho mọi tài liệu
C. tool_choice: { type: “any” }, đảm bảo có lệnh gọi tool trong khi model tự chọn schema
D. Cho mọi tài liệu chạy lần lượt qua cả ba tool trích xuất, rồi giữ kết quả nào trông đầy đủ nhất

Đáp án & giải thích

Đúng: C

C đúng vì “any” đảm bảo có một lệnh gọi tool, và chính điều đó làm output có cấu trúc, trong khi vẫn để model chọn schema. Tổ hợp đó đúng là lý do “any” tồn tại.
A sai vì “auto” cho phép trả lời kiểu hội thoại thay vì gọi tool. Khi bắt buộc phải có structured output thì đó không phải là đảm bảo.
B sai vì ép một tool cụ thể là giả định trước loại tài liệu, mà loại tài liệu theo định nghĩa là chưa biết. Một bộ trích xuất hóa đơn không xử lý đúng biên lai hay hợp đồng.
D sai vì chạy cả ba đốt API call và context cho hai kết quả rồi bỏ đi. Một lệnh gọi với “any” là xong.