Best Practices Gọi Tool Cho Agent: Vì Sao Agent Chọn Sai Tool
Best practices gọi tool cho agent là thứ nằm giữa một bản demo chạy được và một agent lặng lẽ gọi sai tool trong production. Đội engineering của Anthropic đã đo được một description viết lại duy nhất cắt một kết quả tool từ 206 token xuống 72, và Claude Code giờ chặn cứng mọi phản hồi tool ở 25.000 token vì sự lãng phí này là có thật. Agent của bạn hỏng theo bốn cách: sai tool, sai tham số, vòng lặp mất kiểm soát, chảy máu token, và mỗi cách đều có một bản sửa bạn có thể ship ngay tuần này.
Điểm chính:
- Tool calling của agent hỏng theo đúng bốn cách: sai tool, sai tham số, vòng lặp mất kiểm soát và chảy máu token.
- Description của tool là chỉ dẫn duy nhất model nhìn thấy lúc chọn, nên chúng sửa được phần lớn các lệnh gọi sai tool.
- Schema phẳng, đúng hình dạng task, kèm đầu vào được validate, loại bỏ hầu hết lỗi sai tham số.
- Phản hồi tool gọn và một vòng eval chạy sau mọi thay đổi giữ chi phí token và regression đo được.
Vì sao agent gọi tool thất bại trong production?
Tool calling của agent hỏng theo bốn cách: model chọn sai tool, viết sai tham số, quay cuồng trong một vòng lặp mất kiểm soát, hoặc chảy máu token qua những phản hồi phình to. Mỗi lỗi đánh vào một bước khác nhau của vòng lặp gọi, nên thứ tự sửa rất quan trọng. Hãy bắt đầu từ khâu chọn, vì một lựa chọn sai tool sẽ đầu độc mọi bước sau đó.
| Chế độ lỗi | Nó xảy ra ở đâu trong vòng lặp | Thực hành sửa lỗi | Nỗ lực |
|---|---|---|---|
| Sai tool | Model chọn từ danh sách tool | 1 (description) + 4 (namespace, lọc) | Thấp |
| Sai tham số | Model viết JSON tool_call | 2 (schema phẳng) + 6 (validation) | Thấp-TB |
| Vòng lặp mất kiểm soát | tool_result quay vòng về model | 3 (tool nguyên tử) + 7 (cổng con người) | TB |
| Chảy máu token | tool_result trả về cửa sổ ngữ cảnh | 5 (kết quả gọn) + 8 (vòng eval) | Thấp-TB |
Toàn bộ phác đồ, nhìn lướt:
| Thực hành | Lỗi nó sửa | Nỗ lực |
|---|---|---|
| 1. Viết description mà model hành động được | Sai tool | Thấp |
| 2. Giữ schema phẳng và đúng hình dạng task | Sai tham số | Thấp |
| 3. Gói chuỗi nhiều bước thành tool nguyên tử | Vòng lặp mất kiểm soát | TB |
| 4. Namespace, cắt tỉa và lọc tool động | Sai tool | TB |
| 5. Trả về kết quả gọn, tín hiệu cao | Chảy máu token | Thấp |
| 6. Validate mọi lệnh gọi và để lỗi dạy model | Sai tham số | TB |
| 7. Chặn hành động phá hủy sau một con người | Vòng lặp, an toàn | TB |
| 8. Chạy vòng eval sau mọi thay đổi tool | Cả bốn, dưới dạng regression | TB |
Hãy làm theo đúng thứ tự này. Thực hành 1 và 2 mất một buổi chiều và dẹp được phần lớn lỗi sai tool, sai tham số bạn thấy hôm nay. Description của tool không phải tài liệu hướng dẫn. Nó là chỉ dẫn duy nhất model nhận được vào lúc chọn.
Giai đoạn 1: Thiết kế tool mà model thực sự dùng được
Những cải thiện độ tin cậy rẻ nhất trong gọi tool cho agent nằm ở định nghĩa tool, không phải ở prompt hay ở việc chọn model. Model không bao giờ đọc API docs hay README của bạn. Nó nhìn thấy một cái tên, một chuỗi description và một JSON schema, rồi quyết định chỉ từ ba thứ đó. Làm đúng ba thứ ấy và độ chính xác chọn sẽ nhích lên trước cả khi bạn đụng vào bất kỳ thứ gì khác.
Thực hành 1: Viết description mà model hành động được
Viết description của tool như chỉ dẫn gửi cho model, không phải như tài liệu API. Một description làm hài lòng lập trình viên ("REST wrapper cho users endpoint") chẳng cho model chút căn cứ nào để quyết định. Hướng dẫn engineering của Anthropic về viết tool và best practices định nghĩa tool của họ cùng thúc đẩy một khuôn mẫu: nói rõ khi nào dùng tool, nó trả về gì, và khi nào KHÔNG dùng.
{
"name": "get_user",
"description": "Fetches a user profile. Use ONLY when you already have a user_id. Do NOT use to search or list users; call search_users instead. Returns name, email, plan. Errors if user_id is not a valid UUID."
}so với phiên bản mà hầu hết các team đang ship:
{
"name": "get_user",
"description": "Gets a user."
}Hai quy tắc làm hộ phần lớn việc ở đây. Thứ nhất, đặt tên tham số sao cho nghĩa của chúng không thể hiểu nhầm: user_id, không bao giờ user hay id, vì user sẽ mời model truyền một cái tên hoặc email vào chỗ đáng ra là UUID. Thứ hai, nêu rõ các loại trừ. "Do NOT use to search users" ngăn được nhiều lệnh gọi sai tool hơn bất kỳ lượng mô tả tích cực nào, vì model nhầm lẫn các tool chồng lấn thường xuyên hơn nhiều so với hiểu nhầm một tool đơn lẻ, có ranh giới rõ. Về cơ chế ở cấp provider, cách những định nghĩa này đến được API của OpenAI, Anthropic và Google, xem hướng dẫn function calling đa provider của chúng tôi.
Thực hành 2: Giữ schema phẳng và đúng hình dạng task
Giữ schema đầu vào phẳng, với mọi field mà task thực sự cần và không field nào nó không cần. Object lồng nhau với các nhánh tùy chọn là nơi lỗi sai tham số sinh sôi: model phải suy luận một cấu trúc mà nó chưa từng thấy ví dụ. Hướng dẫn function calling của OpenAI chấp nhận JSON Schema tùy ý, nhưng dễ dãi không đồng nghĩa với đáng tin.
{
"name": "create_ticket",
"parameters": {
"type": "object",
"properties": {
"ticket": {
"type": "object",
"properties": {
"details": {
"type": "object",
"properties": {
"title": { "type": "string" },
"meta": { "type": "object" }
}
}
}
}
}
}
}Làm phẳng nó về đúng task:
{
"name": "create_ticket",
"parameters": {
"type": "object",
"properties": {
"title": { "type": "string" },
"priority": { "type": "string", "enum": ["low", "medium", "high"] },
"assignee_id": { "type": "string" }
},
"required": ["title", "priority"]
}
}Enum ăn đứt văn bản tự do với mọi field có một tập giá trị giới hạn. Mảng required ăn đứt mọi thứ tùy chọn. Nếu model gần như luôn cần một field, hãy biến nó thành required trong schema của tool, kể cả khi API của bạn gọi nó là optional. Bạn không đang soi gương API của mình. Bạn đang thiết kế một bề mặt mà một model cụ thể có thể điền đúng.
Giai đoạn 2: Quản lý cả bộ tool, không chỉ từng tool
Chất lượng của từng tool không còn đủ một khi agent mang nhiều hơn một nắm tool, vì lỗi chọn tăng theo kích thước danh sách mà model đọc.
Thực hành 3: Gói chuỗi API nhiều bước thành một tool nguyên tử
Gộp mọi chuỗi lệnh gọi API cố định vào một tool nguyên tử. Bài engineering của Anthropic dùng schedule_event và get_customer_context làm mẫu: một lệnh gọi làm trọn cả việc ăn đứt ba lệnh gọi mà agent phải xâu chuỗi đúng mỗi lần. Mỗi mắt xích trong chuỗi là thêm một lượt mà model có thể khựng lại, thử lại sai, hoặc lặp vòng.
# What the agent does WITHOUT an atomic tool: 3 calls, 3 chances to fail
calendar = call_tool("list_calendars", {})
free = call_tool("find_free_slot", {"calendar_id": calendar["items"][0]["id"], "duration": 30})
call_tool("create_event", {"calendar_id": calendar["items"][0]["id"], "start": free["start"]})
# One atomic tool: the sequence lives in your code, not the model's head
call_tool("schedule_event", {"duration": 30, "attendees": ["[email protected]"]})Quy tắc kinh nghiệm: nếu model luôn phải gọi B sau A, thì A và B là một tool mặc hai bộ đồ.
Thực hành 4: Namespace, cắt tỉa và lọc tool động
Đặt namespace cho mọi tên tool và chỉ cho mỗi agent thấy tập con mà task hiện tại của nó cần. Tên chung chung va chạm ngay khoảnh khắc bạn nối hai integration. Hãy tưởng tượng một agent nối vào hai MCP server, cả hai cùng phơi một tool tên search: hai động từ giống hệt nhau, không cách nào phân biệt. Anthropic ghi nhận mức tăng eval đo được từ namespace bằng tiền tố:
| Trước | Sau (tiền tố) | Sau (hậu tố) |
|---|---|---|
search | asana_projects_search | search_asana_projects |
create | asana_tasks_create | create_asana_tasks |
search (server thứ hai) | github_repos_search | search_github_repos |
Cắt tỉa quan trọng ngang đặt tên. Một agent hỗ trợ không cần nạp sẵn bộ tool billing trong khi nó trả lời câu hỏi về mật khẩu. Mô hình planner-worker, trong đó một planner định tuyến task tới một worker chỉ nạp các tool liên quan, là bản sửa chuẩn; hướng dẫn nạp tool động của LangGraph chỉ dẫn cách triển khai. Bao nhiêu tool là quá nhiều? Hãy coi 5-10 tool mỗi agent là khoảng làm việc, không phải luật: độ chính xác giảm khi danh sách dài ra, và thuốc chữa là lọc, không phải model to hơn. Nếu bạn đang chọn chính lớp định tuyến và lọc, hãy so các lựa chọn trong bài tổng hợp của chúng tôi về các thư viện function calling tốt nhất.
Giai đoạn 3: Kiểm soát dữ liệu trả về và dữ liệu gửi đi
Vòng lặp chạy theo cả hai chiều, và hầu hết các team chỉ thiết kế nửa đi ra. Thứ tool của bạn trả về quyết định bao nhiêu phần cửa sổ ngữ cảnh sống sót tới lượt kế tiếp, và thứ validation của bạn từ chối quyết định model học từ lỗi của nó hay lặp lại chúng.
Thực hành 5: Trả về kết quả gọn, tín hiệu cao
Trả về kết quả nhỏ nhất mà model có thể hành động, với định danh đọc được thay vì ID thô. Bài engineering của Anthropic ghi nhận một tool có kết quả mặc định dài 206 token; một cài đặt response_format gọn cắt cùng kết quả đó xuống 72 token, xấp xỉ một phần ba. Nhân con số đó với vài chục lệnh gọi mỗi task và nó quyết định agent của bạn có hoàn tất nổi việc hay không.
// Before: 206 tokens (shape per Anthropic's documented example)
{
"status": "success",
"data": {
"id": "8f14e45f-ceea-3f9c-a2f3-90c1b5e0a7d2",
"object": "task", "created_at": "2026-07-02T09:14:00Z",
"updated_at": "2026-07-11T16:40:12Z", "completed_at": null,
"assignee": {"id": "c9a1...f2", "object": "user"},
"projects": [{"id": "b7d3...91", "object": "project"}],
"permalink": "https://app.asana.com/0/.../f"
}
}
// After: 72 tokens
{ "task": "Fix login redirect", "assignee": "Dana Kim", "project": "Web App", "due": "2026-07-20" }Thêm hai chi tiết từ cùng nguồn: Anthropic hỗ trợ một enum response_format (detailed với concise) trên định nghĩa tool, để bạn khai báo hình dạng mình muốn thay vì ngồi phân tích cả vòi rồng. Và Claude Code chặn phản hồi tool ở 25.000 token, một trần cứng dù sao cũng cắt bớt kết quả phình to. Anthropic cũng báo cáo, như phát hiện của riêng họ, rằng việc resolve UUID thành tên ngữ nghĩa giảm đo được ảo giác truy xuất, đó là vì sao payload "sau" ở trên ghi "Dana Kim" chứ không phải c9a1...f2. Phản hồi phình to còn là bài toán chi phí; xem hướng dẫn giảm chi phí API LLM của chúng tôi để thấy bức tranh đầy đủ.
Thực hành 6: Validate mọi lệnh gọi và để lỗi dạy model
Validate mọi lệnh gọi tool ở phía server và trả về lỗi chứa sẵn cách sửa. Bài viết của Martin Fowler về function calling nói thẳng: đừng bao giờ tin output của model. Nó sẽ truyền string vào chỗ đáng ra là enum và bịa ra những ID không tồn tại.
def create_ticket(args):
if args.get("priority") not in {"low", "medium", "high"}:
return {"error": f"priority must be one of: low, medium, high. Got '{args.get('priority')}'. Pass priority='medium' for normal issues."}
if not is_valid_uuid(args.get("assignee_id")):
return {"error": "assignee_id must be a UUID. Call list_team_members to get valid IDs, then retry."}
return db.create_ticket(**args)Chuỗi lỗi mới là cả cuộc chơi. So sánh:
# Unhelpful: the model retries the same bad call
{"error": "invalid input"}
# Helpful: the model knows exactly what to change
{"error": "priority must be one of: low, medium, high. Got 'urgent'. Use 'high'."}Mỗi lỗi validation mà tool của bạn trả về là một prompt bạn đang viết cho lần thử kế tiếp của model. Lỗi nêu tên ràng buộc và chỉ vào tool sửa lỗi sẽ biến một vòng lặp thử lại thành một lần phục hồi duy nhất. Đây cũng là tuyến phòng thủ bảo mật đầu tiên của bạn; hướng dẫn guardrails cho LLM của chúng tôi đi sâu vào đó.
Giai đoạn 4: Làm sao để an toàn, rồi đo được?
An toàn và đo lường là cùng một giai đoạn, vì một hành động phá hủy không cổng chặn và một regression không được đo đều lộ diện dưới dạng sự cố mà bạn không thấy trước. Chặn những hành động không thể hoàn tác, rồi gắn công cụ đo cho mọi thứ để lần thay đổi tool kế tiếp là một quyết định có bằng chứng đứng sau, không phải một hy vọng.
Thực hành 7: Chặn hành động phá hủy sau một con người
Tách tool đọc khỏi tool ghi và đặt một cổng xác nhận của con người lên bất cứ thứ gì mang tính phá hủy. Tool annotations trong đặc tả MCP tồn tại đúng cho việc này: destructiveHint đánh dấu tool thực hiện cập nhật phá hủy, còn openWorldHint gắn cờ tool chạm vào hệ thống bên ngoài, để client có thể hỏi trước khi thi hành. Hãy dùng chúng.
Chế độ lỗi này không phải giả thuyết. Laurent Kubaski đã ghi nhận một ca, trong bài tổng hợp tool-calling tháng 7/2025 của ông kèm liên kết báo cáo gốc, nơi một người dùng yêu cầu Copilot trong Excel tác động lên hàng 4 và agent lại tác động lên hàng 8. Không có cổng xác nhận nào đứng giữa hàng sai và lệnh ghi. Bản sửa chính là khuôn mẫu AWS tài liệu hóa cho Bedrock Agents: agent chuẩn bị hành động, trả nó về để phê duyệt, và chỉ thi hành sau khi một con người xác nhận. Cursor làm y vậy với sửa file. Khoanh vùng credential ở mức chỉ đọc khi việc đọc là tất cả những gì task cần, và coi các cổng xác nhận như một phần bề mặt injection của bạn, chủ đề trong hướng dẫn phòng chống prompt injection của chúng tôi.
Thực hành 8: Chạy vòng eval sau mọi thay đổi tool
Chạy một bộ eval nhỏ trước và sau mọi thay đổi tool, và đọc metric theo một thứ tự cố định. Hướng dẫn tối ưu của Paragon đề xuất một khung bốn metric đáng để áp:
| Metric (theo Paragon) | Nó bắt được gì | Đo bằng cách nào |
|---|---|---|
| Độ đúng tool | Lệnh gọi sai tool | Agent có gọi đúng tool cho task không? |
| Độ đúng đầu vào | Sai tham số | Tham số có hợp lệ và đầy đủ không? |
| Hoàn tất task | Lỗi đầu-cuối | Mục tiêu của người dùng có đạt không? |
| Hiệu suất task | Chảy máu token, vòng lặp | Số lệnh gọi và số token? |
Cookbook đánh giá tool của Anthropic, xây trên eval MCP thật của Slack và Asana, cho thấy task eval tốt và tệ trông ra sao:
# Weak: vague, many valid paths, impossible to score
"Use the Asana tools to organize some work."
# Strong: one correct tool, checkable arguments, binary outcome
"Create a task titled 'Renew TLS cert' in project 'Infra' assigned to [email protected], due 2026-08-15. Expect exactly one create_task call with those four fields."Cách diễn giải của chúng tôi, được gắn nhãn đúng như vậy: những con số công bố cho bạn thứ tự để làm. Kiểm tra độ đúng tool trước tiên, vì chính phép đo của Anthropic cho thấy thay đổi description và cách đặt tên tác động trực tiếp lên nó (bản viết lại 206-xuống-72 token, phát hiện ảo giác UUID-sang-tên), và để hiệu suất task lại sau cùng, vì nó chủ yếu phản ánh những lỗi mà ba metric đầu đã bắt được. Với bộ khởi đầu, hãy thiết kế 15-30 task, hai hoặc ba task mỗi tool, mỗi task có một lệnh gọi kỳ vọng duy nhất và một điều kiện đạt nhị phân. Kích thước đó đủ để bắt regression từ một bản viết lại description mà không mất cả tuần dán nhãn, và chúng tôi đọc cách thiết lập Slack và Asana của cookbook như bằng chứng rằng một bộ nhỏ cỡ này là điểm khởi đầu đúng như dự kiến, không phải đường tắt. Cơ chế sâu hơn nằm trong hướng dẫn đánh giá AI agent trong production của chúng tôi, và nếu kết quả eval nói rằng bản thân các tool thì ổn nhưng lớp điều phối thì không, đó là lúc xem lại lựa chọn framework của bạn trước các framework AI agent tốt nhất.
Gọi tool cho agent và MCP: khác nhau ở đâu?
MCP là một chuẩn vận chuyển và đăng ký, không phải một lớp tin cậy, nên cùng tám thực hành ấy áp dụng bất kể tool của bạn đến qua MCP hay được định nghĩa inline. Tool calling native là hợp đồng của model-provider: cách model phát ra một tool_call và đọc một tool_result. MCP chuẩn hóa cách tool đến được model; nó không làm gì cho việc model có chọn đúng hay không.
| Tool calling native xử lý | MCP bổ sung | Cả hai đều không xử lý |
|---|---|---|
| Định dạng message tool_call / tool_result | Một giao thức chung để mọi client tới được mọi server | Chất lượng description |
| Schema riêng từng provider | Khám phá và đăng ký tool | Thiết kế schema, validation |
| Đàm phán lệnh gọi song song | Annotation như destructiveHint | Cổng con người, eval, vệ sinh phản hồi |
Một MCP server phơi một tool tên search với description "searches things" sẽ thất bại y hệt một hàm inline được định nghĩa cùng cách. Sửa định nghĩa trước, rồi hãy lo về vận chuyển. Hướng dẫn Model Context Protocol của chúng tôi phủ trọn phần giao thức từ đầu đến cuối.
Cách Techsy áp dụng tám best practices này
Trong mọi bản dựng agent cho khách hàng, chúng tôi ép ba thực hành này trước bất cứ thứ gì khác được ship: description viết như chỉ dẫn (Thực hành 1), cổng validation trên mọi tool ghi (Thực hành 6), và một bộ eval chạy trước deploy, không phải sau một sự cố (Thực hành 8). Ba thứ đó phủ các lệnh gọi sai tool, sai tham số, và những regression tái sinh cả hai, đó là nơi mọi sự cố agent production mà chúng tôi từng gỡ lỗi đã bắt đầu. Năm thực hành còn lại theo sau khi agent lớn lên. Nếu agent của bạn đã qua giai đoạn demo và vẫn chọn sai tool, hãy nhận tư vấn miễn phí và chúng tôi sẽ nói bạn nên sửa thực hành nào trong tám cái trước tiên.
Về tác giả
Mert Batur là Co-Founder của Techsy.io, nơi team ship các AI agent, hệ thống automation và pipeline voice/SDR cho khách hàng B2B. Anh viết về stack công cụ LLM mà team Techsy thực sự dùng trong production. Kết nối trên LinkedIn.
Câu hỏi thường gặp
Gọi tool cho agent là gì?
Gọi tool cho agent là cơ chế trong đó một LLM quyết định gọi một hàm bên ngoài, phát ra một tool_call có cấu trúc, và chờ code của bạn trả về một tool_result để nó suy luận tiếp. Đó là thứ biến một model chat thành một agent có thể truy vấn database, gọi API và hành động: model chọn tool và tham số, executor của bạn chạy chúng.
Vòng lặp gọi tool cho agent hoạt động thế nào?
Vòng lặp có năm bước: yêu cầu của người dùng đến model, model chọn một tool và viết một tool_call, executor của bạn chạy nó, một tool_result trả về model, và model hoặc trả lời hoặc phát ra một lệnh gọi khác. Chu kỳ đó lặp lại cho tới khi task xong. Bốn chế độ lỗi trong hướng dẫn này, mỗi cái sống ở một bước cụ thể của vòng lặp đó.
Vì sao agent của tôi chọn sai tool?
Thường vì hai tool chồng lấn và description của chúng không nói rõ cái nào là cái nào. Model chỉ chọn từ tên và description, nên "gets a user" với "finds users" đọc như thay thế được nhau. Sửa bằng các dòng loại trừ ("do NOT use to search"), tên có namespace, và ít tool hơn trong ngữ cảnh. Thử nghiệm bốn model của Kubaski cho thấy ngay cả model mạnh cũng định tuyến sai trên danh sách mơ hồ.
Làm sao ép agent cấu trúc output của nó?
Ràng buộc schema, không phải prompt. Dùng enum cho field có tập giá trị giới hạn, mảng required cho bất cứ thứ gì task cần, và object phẳng thay vì lồng. Với câu trả lời cuối cùng thay vì lệnh gọi tool, các tính năng của provider như structured outputs của OpenAI và các chế độ tool-choice của Anthropic ép một hình dạng cụ thể. Hướng dẫn structured outputs của chúng tôi phủ cả hai đường, kèm code.
Gọi tool native và MCP khác nhau thế nào?
Tool calling native là hợp đồng giữa code của bạn và một model provider: định dạng message tool_call và tool_result. MCP là một lớp giao thức chuẩn hóa cách tool được khám phá và chuyển tới bất kỳ client tương thích nào. MCP đổi đường ống, không đổi độ tin cậy. Một tool mô tả tệ sẽ thất bại cùng cách trên cả hai đường, như hướng dẫn Model Context Protocol của chúng tôi giải thích.
Bao nhiêu tool là quá nhiều với một LLM agent?
Coi 5-10 tool mỗi agent là khoảng làm việc, không phải luật. Độ chính xác chọn giảm khi danh sách nhìn thấy dài ra, nhất là khi tên hoặc description chồng lấn. Thuốc chữa không phải model to hơn mà là lọc: chỉ nạp tập con mà task hiện tại cần, dùng chia tách planner-worker. Đặt namespace cho mọi thứ để hai integration không bao giờ cùng phơi một search trần.
Model nào tốt nhất cho tool calling?
Không có câu trả lời duy nhất, và benchmark công bố già đi rất nhanh trong lĩnh vực này. Các model tiên phong từ OpenAI, Anthropic và Google đều vượt qua các task tool-use cơ bản, trong khi các model nhỏ hơn ghép với tool thiết kế tốt thường hoàn tất task gần bằng với một phần nhỏ chi phí token. Hãy xây bộ eval 15-30 task từ Thực hành 8 và kiểm các ứng viên trên chính bộ tool của bạn.
Làm sao giảm chi phí token từ tool calling?
Cắt thứ trả về. Trả kết quả gọn, tín hiệu cao thay vì payload API thô: Anthropic ghi nhận mức cắt 206-xuống-72 token từ một thay đổi response_format. Resolve UUID thành tên, bỏ các field model không bao giờ dùng, và nhớ rằng mọi kết quả tool tái nhập cửa sổ ngữ cảnh ở mọi lượt sau đó. Ít lệnh gọi hơn, qua tool nguyên tử, gỡ trọn cả kết quả khỏi hóa đơn.
Làm sao đánh giá chất lượng tool calling?
Chấm bốn metric theo thứ tự: độ đúng tool (đúng tool?), độ đúng đầu vào (tham số hợp lệ?), hoàn tất task (đạt mục tiêu?), và hiệu suất task (số token và lệnh gọi?). Viết 15-30 task, mỗi task kỳ vọng một lệnh gọi cụ thể với tham số kiểm được và điều kiện đạt nhị phân. Chạy bộ này trước và sau mọi thay đổi tool để một bản viết lại description không bao giờ được ship mà chưa đo.
Kết luận
Chẩn đoán trước khi tối ưu. Agent của bạn chọn sai tool vì một trong bốn lý do, và ba trong tám thực hành ở trên, description, schema phẳng và lọc, sửa các thất bại chọn đứng sau phần lớn sự cố production. Bắt đầu ở đó, vì chúng chỉ tốn một buổi chiều và chúng là lý do bài toán này sửa được ngay từ đầu. Giữ lỗi validation giàu thông tin, chặn mọi thứ mang tính phá hủy sau một con người, và chạy vòng eval sau mọi thay đổi để bạn đo trước khi đổi model. Vấn đề sai tool không phải vấn đề của model. Nó là vấn đề thiết kế tool, và bạn sở hữu thiết kế đó.