- Claude Developer Platform được bổ sung 3 tính năng mới, cung cấp kiến trúc sử dụng công cụ nâng cao để mô hình có thể tìm kiếm, gọi và học cách dùng hàng nghìn công cụ bên ngoài một cách hiệu quả
- Tool Search Tool chỉ tải định nghĩa công cụ vào đúng thời điểm cần thiết, giúp giảm tới 85% lượng token sử dụng và cải thiện độ chính xác lên mức 74~88% trong môi trường MCP quy mô lớn
- Programmatic Tool Calling gọi công cụ song song trong môi trường thực thi mã để đạt được tiết kiệm token (37%), giảm độ trễ và cải thiện độ chính xác
- Tool Use Examples giúp mô hình học được mẫu sử dụng công cụ và quan hệ giữa các tham số mà JSON Schema không thể biểu đạt, thông qua các ví dụ gọi thực tế
- Ba tính năng này cung cấp nền tảng điều phối hiệu quả cho các AI agent quy mô lớn và là thành phần cốt lõi của tự động hóa workflow phức tạp
Mở rộng khả năng sử dụng công cụ của AI agent
- Các AI agent trong tương lai sẽ cần tận dụng tích hợp hàng trăm đến hàng nghìn công cụ
- Ví dụ gồm công cụ hỗ trợ IDE, điều phối vận hành, và tích hợp với Slack, GitHub, Jira, Google Drive
- Cách làm trước đây phải tải trước toàn bộ định nghĩa công cụ, nên nhanh chóng tiêu tốn context window
- Cách tiếp cận mới là tìm kiếm và tải công cụ vào đúng lúc cần, đồng thời đảm bảo hiệu quả bằng gọi dựa trên mã và học từ ví dụ
Tool Search Tool
- Trong môi trường MCP hiện có, khi kết nối nhiều server thì riêng phần định nghĩa công cụ có thể chiếm hơn 100.000 token
- Ví dụ: GitHub(26K), Slack(21K), Jira(17K), khi cộng dồn có trường hợp vượt 134K token
- Tool Search Tool tìm kiếm và tải công cụ theo nhu cầu
- Ở lần tải đầu chỉ dùng khoảng 500 token, sau đó chỉ tải thêm các công cụ cần thiết
- Tổng lượng token sử dụng giảm xuống khoảng 8.7K, tiết kiệm 95% ngữ cảnh
- Kết quả thử nghiệm nội bộ cho thấy độ chính xác đánh giá MCP được cải thiện: Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1%
- Có thể tải công cụ trì hoãn thông qua thiết lập
defer_loading: true
- Chỉ luôn tải các công cụ dùng thường xuyên, còn lại sẽ được gọi khi cần tìm kiếm
- Mặc định cung cấp công cụ tìm kiếm dựa trên regex và BM25, đồng thời cũng hỗ trợ tìm kiếm tùy chỉnh dựa trên embedding
- Điều kiện nên áp dụng: có từ 10 công cụ trở lên, định nghĩa vượt 10K token, hoặc thường xuyên xảy ra lỗi chọn nhầm công cụ
Programmatic Tool Calling
- Cách gọi dựa trên ngôn ngữ tự nhiên trước đây kém hiệu quả do tích lũy kết quả trung gian và nhiều lượt suy luận
- Ví dụ: khi phân tích log 10MB, toàn bộ dữ liệu bị đưa vào ngữ cảnh gây lãng phí token
- Programmatic Tool Calling (PTC) gọi công cụ song song trong môi trường thực thi mã
- Claude dùng mã Python để thực hiện vòng lặp, câu lệnh điều kiện và chuyển đổi dữ liệu
- Kết quả trung gian không được đưa vào ngữ cảnh của mô hình, và chỉ kết quả cuối cùng mới được trả về
- Ví dụ: trong tác vụ tìm người vượt ngân sách theo quý, thay vì 2.000 mục thì chỉ có 1KB kết quả được đưa vào ngữ cảnh
- Hiệu quả
- Lượng token sử dụng từ 43,588→27,297 (giảm 37%)
- Giảm độ trễ (loại bỏ 19 lượt suy luận khi cần 20 lần gọi)
- Cải thiện độ chính xác: tìm kiếm nội bộ 25.6→28.5%, benchmark GIA 46.5→51.2%
- Điều kiện nên áp dụng
- Tóm tắt dữ liệu quy mô lớn, các lời gọi phụ thuộc từ 3 bước trở lên, hoặc tác vụ cần chạy song song
- Không hiệu quả với một lần gọi đơn lẻ hoặc phản hồi nhỏ
Tool Use Examples
- JSON Schema chỉ định nghĩa cấu trúc, chứ không thể biểu đạt mẫu sử dụng, quy tắc định dạng, hay quan hệ giữa các tham số
- Ví dụ: định dạng ngày, quy tắc ID, hoặc thời điểm dùng đối tượng lồng nhau có thể không rõ ràng
- Tool Use Examples thêm ví dụ đầu vào thực tế (
input_examples) vào định nghĩa công cụ
- Qua ví dụ, Claude học được định dạng ngày (YYYY-MM-DD), quy tắc ID (USR-XXXXX), và các tổ hợp tham số tùy chọn
- Trong thử nghiệm nội bộ, độ chính xác xử lý tham số phức tạp tăng từ 72% lên 90%
- Điều kiện nên áp dụng
- Công cụ có nhiều cấu trúc lồng nhau hoặc tham số tùy chọn
- API có quy tắc theo từng domain nhưng không thể biểu diễn bằng Schema
- Trường hợp cần phân biệt giữa các công cụ tương tự nhau
Cách kết hợp ba tính năng và best practice
- Ba tính năng hoạt động bổ trợ lẫn nhau
- Tool Search Tool → tìm công cụ cần dùng
- Programmatic Tool Calling → thực thi hiệu quả
- Tool Use Examples → gọi chính xác
- Thứ tự ưu tiên áp dụng
- Vượt ngữ cảnh → Tool Search Tool
- Quá nhiều kết quả trung gian → Programmatic Tool Calling
- Lỗi tham số → Tool Use Examples
- Mẹo cấu hình
- Viết rõ ràng tên và mô tả công cụ để tăng độ chính xác khi tìm kiếm
- Luôn tải 3~5 công cụ dùng thường xuyên, còn lại dùng tải trì hoãn
- Ghi rõ định dạng trả về cho công cụ thực thi mã
- Dữ liệu ví dụ nên thực tế và ngắn gọn (1~5 ví dụ)
Bắt đầu
- Ba tính năng này được cung cấp ở phiên bản beta
- Có thể sử dụng sau khi thêm header
betas=["advanced-tool-use-2025-11-20"]
- Công cụ đi kèm gồm
tool_search_tool_regex_20251119, code_execution_20250825 v.v.
- Tài liệu chính thức và GitHub cookbook cung cấp ví dụ API và hướng dẫn triển khai
- Các tính năng này được giới thiệu là nền tảng công nghệ giúp vượt qua gọi hàm đơn thuần để tiến tới điều phối thông minh
- Chúng được nhấn mạnh là thành phần cốt lõi giúp hiện thực hóa khám phá động, thực thi hiệu quả và gọi chính xác trong workflow phức tạp và môi trường dữ liệu quy mô lớn
5 bình luận
Ý kiến trên Hacker News
Đang tìm cách giảm mức sử dụng context khi stream nhiều tool call
Một phần xử lý được offload sang chính tool để trả về cấu trúc tóm tắt từ một file markdown 200k token, nhưng ngay cả cách này đôi khi cũng làm đầy context của model chính rất nhanh
Tôi nghĩ Programmatic Tool Calling là bước tiếp theo tự nhiên
Vì LLM đang đi theo hướng xử lý code như một ngôn ngữ, nên định nghĩa của ngôn ngữ đó rất quan trọng
Nhưng tôi cho rằng việc tìm kiếm tool là overhead không cần thiết. Đưa sẵn các tool cần thiết vào context sẽ hiệu quả hơn
Cuối cùng, cần một tool definition language ngắn gọn như định nghĩa hàm, và tôi muốn đưa object vào context để model nhận biết type cùng các method có thể gọi được
.d.tslà đượcBảo trì hay test cũng dễ, và nếu cần thì có thể import kiểu
export * as Foo from '@foo/foo'Vì LLM cũng viết code tốt, nếu cho quyền ghi thì nó có thể tự tạo hoặc import tool
Về sau, có lẽ một nền tảng cộng tác AI↔con người mang tính tương tác như Jupyter/Pluto/Mathematica sẽ phù hợp hơn
Nếu gắn thêm nhập liệu bằng giọng nói và cho phép cộng tác giữa các phiên, thì gần như sẽ thành một hệ thống ở cấp độ Skynet
Agent tôi làm chỉ với một phần tính năng của Python SDK và vài hàm tùy chỉnh là đã hoạt động đủ tốt
Cấu trúc pseudo-RPC kiểu này cho cảm giác như một nghi thức thừa thãi
Smolagents tận dụng điều này để xử lý đầu ra của tool dưới dạng object (dict)
Tôi tò mò liệu cách tiếp cận này có giống với hướng tôi đang nói tới không
Chi tiết có trong bài blog của Hugging Face
Tôi tò mò liệu MCP server có đưa ví dụ sử dụng vào định nghĩa tool hay không
Nếu có, họ cũng có thể đưa cả ví dụ code để bỏ qua bước sinh code, nhưng có lẽ họ chặn điều đó vì vấn đề bảo mật
Thực thi code do bên thứ ba cung cấp là nguy hiểm, nên tôi hiểu cách thiết kế này
Hơi tiếc vì họ dùng Python làm wrapper
Nếu dùng Bash thì tính tương thích giữa các ngôn ngữ sẽ cao hơn và cũng phù hợp với các workflow không dùng Python hơn
Khả năng chạy tool bên ngoài của nó cũng không kém Bash
Hướng đi “một tương lai nơi model xử lý mượt mà hàng trăm đến hàng nghìn tool” có vẻ là sai lầm
Tôi nghĩ hướng đúng hơn là ít tool hơn + khả năng tận dụng tốt hơn
Cực đoan mà nói, chỉ một ShellTool thôi cũng có thể là đủ
Lý tưởng nhất là model tự tạo và test tool để học cách khiến chúng trở nên đáng tin cậy
Hệ sinh thái connector thì dễ hiểu và dễ marketing, nhưng về căn bản có vẻ là một paradigm sai
Tôi nghĩ sẽ rất hay nếu có một model orchestrator cục bộ nhỏ
Trong nhiều trường hợp, điều phối toàn bộ workflow theo cách lập trình là rất kém hiệu quả
Để giảm ô nhiễm context và tăng tốc độ, cấu trúc lý tưởng là programmatic > tiny local LLM > frontier LLM
Model nhỏ có thể reset context thường xuyên và chỉ chuyển những kết quả cần thiết cho model lớn
Khi dùng AI assistant, có những mẫu lặp đi lặp lại
Nếu tự mình cải tiến một cách làm kém hiệu quả, thì vài tháng sau lại có tool mới ra đời khiến công sức đó trở nên vô nghĩa
Tôi nghĩ đó là cái giá của việc chạy theo công nghệ mới nhất
Có lẽ một ngày nào đó toàn bộ web sẽ được cấu thành từ hàng tỷ tool
Google sẽ index chúng, và Gemini sẽ chọn động để hành động trên thế giới
Thật ra tôi đã kỳ vọng điều này ở Gemini 3
Tính năng #2 được nhắc ở đây là một cách hiện thực hóa khái niệm gần đây đang được bàn tán: “không gọi tool trực tiếp mà viết code để gọi”
Nó chạy trong Python sandbox, có thể truy cập qua API, và phơi bày việc gọi tool giống như gọi API thông thường
Batch tool calling đã giúp tăng đáng kể tốc độ AI assistant trong sản phẩm của chúng tôi, và tính năng lần này trông như một phiên bản tiến hóa của điều đó
Agentic builder của chúng tôi chỉ dùng đúng một tool — đó là GraphQL
Agent viết và chạy query, rồi lấy thông tin cần thiết qua introspection
Có thể tiết kiệm token vì chỉ nhận về lượng dữ liệu tối thiểu
Không cần load hơn 50 tool, và cũng giải quyết được vấn đề N+1 của REST API
Nhờ GraphQL typed schema, agent viết code tốt hơn
Trước đây tôi không thích GraphQL, nhưng nhìn vào trạng thái hiện tại của MCP thì tôi nghĩ đây là một trong những công nghệ phù hợp nhất cho AI agent
Chi tiết được tổng hợp trong bài này
Agent của tôi chỉ thực hiện một truy vấn SPARQL, và state chỉ nằm trong graph DB
Phần lớn ontology đều công khai, nên gần như không cần schema introspection
Nhờ đầu ra có cấu trúc, có thể ràng buộc để nó chỉ tạo RDF hợp lệ
Có lẽ GraphQL cũng có thể làm theo cách tương tự
Tôi phải làm nhiều việc như web search, gọi local API, tích hợp Slack, nên chỉ GraphQL thôi là không đủ
Có các vấn đề về quyền hạn, caching, mutation, nhưng chúng không ảnh hưởng nhiều đến việc nạp context có chọn lọc
LLM viết truy vấn GraphQL theo schema khá tốt
Ngay cả khi mắc lỗi, nếu trả về thông báo lỗi rõ ràng thì nó sửa lại rất nhanh
Phần reasoning liên quan có trong bài blog này
Nhưng đến giờ thì có vẻ vẫn là nhờ sức mạnh của model. Vì đây là những model do Claude cung cấp nên nó mới hoạt động tốt như vậy, còn các model khác thì quả thật là... cũng đáng nghi ngờ nhỉ.
Trong số các công ty như Anthropic, Google và OpenAI, tôi có cảm giác Anthropic là bên gần với Agentic AI nhất.
Mình cũng đã nghĩ sonnet 4.5 khá là tốt rồi
nhưng có vẻ opus 4.5 còn tốt hơn nữa. Wow.
Vậy à? Cụ thể chủ yếu là ở những điểm nào vậy?