Anthropic Engineering

Giới thiệu tính năng sử dụng công cụ nâng cao trên Nền tảng dành cho nhà phát triển Claude

🕐 20/07/2026 12:08 📰 Anthropic Engineering ✅ Đã dịch sang tiếng Việt

Tương lai của các tác nhân AI là nơi các mô hình hoạt động liền mạch trên hàng trăm hoặc hàng nghìn công cụ. Một trợ lý IDE tích hợp các thao tác git, xử lý tệp, trình quản lý gói, framework kiểm thử và pipeline triển khai. Một điều phối viên vận hành kết nối đồng thời Slack, GitHub, Google Drive, Jira, cơ sở dữ liệu công ty và hàng chục máy chủ MCP.

Để xây dựng các tác nhân hiệu quả, chúng cần làm việc với thư viện công cụ không giới hạn mà không cần nhồi nhét mọi định nghĩa vào ngữ cảnh ngay từ đầu. Bài viết blog của chúng tôi về việc sử dụng thực thi mã với MCP đã thảo luận về cách kết quả và định nghĩa công cụ đôi khi tiêu tốn hơn 50.000 token trước khi tác nhân đọc một yêu cầu. Các tác nhân nên khám phá và tải công cụ theo nhu cầu, chỉ giữ lại những gì liên quan đến tác vụ hiện tại.

Các tác nhân cũng cần khả năng gọi công cụ từ mã. Khi sử dụng gọi công cụ bằng ngôn ngữ tự nhiên, mỗi lần gọi yêu cầu một lượt suy luận đầy đủ và kết quả trung gian chất đống trong ngữ cảnh dù có hữu ích hay không. Mã là lựa chọn tự nhiên cho logic điều phối, chẳng hạn như vòng lặp, câu lệnh điều kiện và biến đổi dữ liệu. Các tác nhân cần sự linh hoạt để chọn giữa thực thi mã và suy luận dựa trên tác vụ cụ thể.

Các tác nhân cũng cần học cách sử dụng công cụ chính xác từ các ví dụ, không chỉ từ định nghĩa schema. Schema JSON xác định những gì hợp lệ về mặt cấu trúc, nhưng không thể diễn tả các mẫu sử dụng: khi nào bao gồm tham số tùy chọn, tổ hợp nào có ý nghĩa, hoặc quy ước nào API của bạn mong đợi.

Hôm nay, chúng tôi phát hành ba tính năng giúp điều này khả thi:

Trong thử nghiệm nội bộ, chúng tôi nhận thấy các tính năng này đã giúp chúng tôi xây dựng những thứ không thể thực hiện được với các mẫu sử dụng công cụ thông thường. Ví dụ, Claude for Excel sử dụng Gọi Công cụ Lập trình để đọc và sửa đổi bảng tính với hàng nghìn hàng mà không làm quá tải cửa sổ ngữ cảnh của mô hình.

Dựa trên kinh nghiệm của chúng tôi, chúng tôi tin rằng các tính năng này mở ra những khả năng mới cho những gì bạn có thể xây dựng với Claude.

Định nghĩa công cụ MCP cung cấp ngữ cảnh quan trọng, nhưng khi nhiều máy chủ kết nối hơn, các token đó có thể tích lũy. Hãy xem xét thiết lập năm máy chủ:

Đó là 58 công cụ tiêu tốn khoảng 55K token trước khi cuộc trò chuyện bắt đầu. Thêm nhiều máy chủ hơn như Jira (riêng nó đã sử dụng ~17K token) và bạn sẽ nhanh chóng đạt đến chi phí chung 100K+ token. Tại Anthropic, chúng tôi đã thấy định nghĩa công cụ tiêu tốn 134K token trước khi tối ưu hóa.

Nhưng chi phí token không phải là vấn đề duy nhất. Các lỗi phổ biến nhất là chọn sai công cụ và tham số không chính xác, đặc biệt khi các công cụ có tên tương tự như `notification-send-user` so với `notification-send-channel`.

Thay vì tải tất cả định nghĩa công cụ ngay từ đầu, Công cụ Tìm kiếm Công cụ khám phá các công cụ theo nhu cầu. Claude chỉ thấy những công cụ thực sự cần cho tác vụ hiện tại.

Điều này thể hiện mức giảm 85% trong việc sử dụng token trong khi vẫn duy trì quyền truy cập vào toàn bộ thư viện công cụ của bạn. Thử nghiệm nội bộ cho thấy cải thiện đáng kể về độ chính xác trong các đánh giá MCP khi làm việc với thư viện công cụ lớn. Opus 4 cải thiện từ 49% lên 74%, và Opus 4

.5 từ 79.5% lên 88.1% khi bật Tool Search Tool.

Tool Search Tool cho phép Claude khám phá công cụ một cách linh hoạt thay vì tải tất cả định nghĩa ngay từ đầu. Bạn cung cấp tất cả định nghĩa công cụ cho API, nhưng đánh dấu các công cụ với `defer_loading: true` để chúng có thể được khám phá theo nhu cầu. Các công cụ bị trì hoãn không được tải vào ngữ cảnh của Claude ban đầu. Claude chỉ thấy Tool Search Tool cùng với các công cụ có `defer_loading: false` (những công cụ quan trọng nhất, thường dùng nhất của bạn).

Khi Claude cần các khả năng cụ thể, nó tìm kiếm các công cụ liên quan. Tool Search Tool trả về tham chiếu đến các công cụ phù hợp, sau đó được mở rộng thành định nghĩa đầy đủ trong ngữ cảnh của Claude.

Ví dụ: nếu Claude cần tương tác với GitHub, nó tìm kiếm "github" và chỉ `github.createPullRequest` cùng `github.listIssues` được tải—chứ không phải hơn 50 công cụ khác của bạn từ Slack, Jira và Google Drive.

Bằng cách này, Claude có quyền truy cập vào toàn bộ thư viện công cụ của bạn trong khi chỉ trả chi phí token cho các công cụ nó thực sự cần.

Lưu ý về bộ nhớ đệm prompt: Tool Search Tool không phá vỡ bộ nhớ đệm prompt vì các công cụ bị trì hoãn hoàn toàn bị loại khỏi prompt ban đầu. Chúng chỉ được thêm vào ngữ cảnh sau khi Claude tìm kiếm chúng, vì vậy prompt hệ thống và định nghĩa công cụ cốt lõi của bạn vẫn có thể được lưu vào bộ nhớ đệm.

Đối với máy chủ MCP, bạn có thể trì hoãn việc tải toàn bộ máy chủ trong khi vẫn giữ các công cụ sử dụng cao cụ thể được tải:

Nền tảng Claude Developer cung cấp các công cụ tìm kiếm dựa trên regex và BM25 ngay lập tức, nhưng bạn cũng có thể triển khai các công cụ tìm kiếm tùy chỉnh bằng cách sử dụng embeddings hoặc các chiến lược khác.

Giống như bất kỳ quyết định kiến trúc nào, việc bật Tool Search Tool đều có sự đánh đổi. Tính năng này thêm một bước tìm kiếm trước khi gọi công cụ, vì vậy nó mang lại ROI tốt nhất khi tiết kiệm ngữ cảnh và cải thiện độ chính xác vượt trội hơn độ trễ bổ sung.

Gọi công cụ truyền thống tạo ra hai vấn đề cơ bản khi quy trình làm việc trở nên phức tạp hơn:

Programmatic Tool Calling cho phép Claude điều phối các công cụ thông qua mã thay vì thông qua các vòng lặp API riêng lẻ. Thay vì Claude yêu cầu công cụ từng cái một với mỗi kết quả được trả về ngữ cảnh của nó, Claude viết mã gọi nhiều công cụ, xử lý đầu ra của chúng và kiểm soát thông tin nào thực sự đi vào cửa sổ ngữ cảnh của nó.

Claude xuất sắc trong việc viết mã và bằng cách để nó thể hiện logic điều phối bằng Python thay vì thông qua các lệnh gọi công cụ bằng ngôn ngữ tự nhiên, bạn có được luồng điều khiển đáng tin cậy và chính xác hơn. Vòng lặp, điều kiện, biến đổi dữ liệu và xử lý lỗi đều rõ ràng trong mã thay vì ẩn trong suy luận của Claude.

Hãy xem xét một tác vụ kinh doanh phổ biến: "Thành viên nhóm nào vượt quá ngân sách du lịch quý 3 của họ?"

Bạn có ba công cụ có sẵn:

Với Programmatic Tool Calling:

Thay vì mỗi kết quả công cụ trả về cho Claude, Claude viết một script Python điều phối toàn bộ quy trình làm việc. Script chạy trong Code Execution tool (một môi trường sandbox), tạm dừng khi cần kết quả từ các công cụ của bạn. Khi bạn trả về kết quả công cụ qua API,

Chúng được xử lý bởi script thay vì được tiêu thụ bởi mô hình. Script tiếp tục thực thi và Claude chỉ thấy kết quả đầu ra cuối cùng.

Đây là mã điều phối của Claude cho tác vụ kiểm tra tuân thủ ngân sách:

Ngữ cảnh của Claude chỉ nhận được kết quả cuối cùng: hai đến ba người đã vượt quá ngân sách của họ. 2.000+ mục dòng, các tổng trung gian và tra cứu ngân sách không ảnh hưởng đến ngữ cảnh của Claude, giảm mức tiêu thụ từ 200KB dữ liệu chi phí thô xuống chỉ còn 1KB kết quả.

Lợi ích về hiệu suất là rất đáng kể:

Quy trình sản xuất liên quan đến dữ liệu lộn xộn, logic điều kiện và các thao tác cần mở rộng quy mô. Programmatic Tool Calling cho phép Claude xử lý sự phức tạp đó một cách lập trình trong khi vẫn tập trung vào các kết quả có thể hành động thay vì xử lý dữ liệu thô.

Thêm code_execution vào tools và đặt allowed_callers để chọn các công cụ tham gia thực thi lập trình:

API chuyển đổi các định nghĩa công cụ này thành các hàm Python mà Claude có thể gọi.

Thay vì yêu cầu các công cụ từng cái một, Claude tạo mã Python:

Khi mã gọi get_expenses(), bạn nhận được một yêu cầu công cụ với trường caller:

Bạn cung cấp kết quả, được xử lý trong môi trường Code Execution thay vì ngữ cảnh của Claude. Vòng lặp yêu cầu-phản hồi này lặp lại cho mỗi lần gọi công cụ trong mã.

Khi mã chạy xong, chỉ kết quả của mã được trả về cho Claude:

Đây là tất cả những gì Claude thấy, không phải 2000+ mục dòng chi phí được xử lý trên đường đi.

Programmatic Tool Calling thêm một bước thực thi mã vào quy trình làm việc của bạn. Chi phí bổ sung này được đền đáp khi tiết kiệm token, cải thiện độ trễ và tăng độ chính xác là đáng kể.

JSON Schema xuất sắc trong việc định nghĩa cấu trúc – kiểu dữ liệu, trường bắt buộc, enum được phép – nhưng nó không thể diễn đạt các mẫu sử dụng: khi nào nên bao gồm tham số tùy chọn, tổ hợp nào có ý nghĩa, hoặc quy ước nào API của bạn mong đợi.

Schema định nghĩa những gì hợp lệ, nhưng để lại các câu hỏi quan trọng chưa được trả lời:

Những sự mơ hồ này có thể dẫn đến các yêu cầu sai định dạng.

📎 Nguồn gốc: Anthropic Engineering Xem bài gốc →