AI tự chế công cụ: Khi robot không chỉ biết dùng đồ người khác làm sẵn

Nguồn: Paper "Tool-Genesis: A Task-Driven Tool Creation Benchmark for Self-Evolving Language Agent" — nhóm nghiên cứu từ UESTC, HKU và Tiểu Hồng Thư (Xiaohongshu) 🇨🇳, công bố ngày 5/3/2026 trên arXiv (2603.05578). Project page: https://tool-genesis.github.io

Bé Mi có một câu hỏi muốn hỏi bạn trước khi vào bài nha.

Bạn thích làm việc với người biết tự xoay sở hơn hay người chỉ làm được việc khi có đủ dụng cụ sẵn trong tay?

Hỏi vậy thôi, vì đó cũng chính là vấn đề mà các nhà nghiên cứu AI đang giải quyết. Và hôm nay chúng ta sẽ nói về một công trình nghiên cứu cực kỳ thú vị — Tool-Genesis — thứ mà Bé Mi đọc xong phải ngồi thở dài vì nó hay quá 😮‍💨

Phần 1: AI giỏi dùng công cụ — nhưng AI có tự làm được công cụ không?

Trước hết, hãy tưởng tượng một trợ lý AI như một người thợ.

Trong vài năm gần đây, chúng ta đã dạy AI rất tốt kỹ năng dùng công cụ. Ý là: người ta đưa cho AI một cái búa, AI biết đập đinh. Người ta đưa máy tính, AI biết cộng trừ. Người ta đưa API tìm kiếm web, AI biết gọi API đó đúng cú pháp.

Nghe có vẻ ổn nhỉ? Nhưng vấn đề bắt đầu khi...

Không có công cụ sẵn.

Thực tế cuộc sống không phải lúc nào cũng có đủ đồ nghề. Đôi khi bạn cần đục một cái lỗ hình tam giác mà không ai sản xuất cái đục hình tam giác cả. Lúc đó, người thợ giỏi là người biết tự chế ra công cụ phù hợp.

Với AI agent hiện đại cũng vậy. Các tình huống thực tế mà agent gặp phải:

API đã đổi hoặc không còn tồn tại nữa
Task quá đặc thù — chưa ai nghĩ đến việc làm tool cho nó
Cần kết hợp nhiều nguồn dữ liệu theo cách riêng của mình
Môi trường doanh nghiệp nội bộ — không có tool công cộng nào phù hợp

Vậy mà hầu hết các bài kiểm tra AI hiện nay vẫn chỉ đo: "Agent có dùng đúng tool không?" — chứ không đo "Agent có tự tạo được tool không?"

Đó chính là lỗ hổng mà Tool-Genesis ra đời để lấp.

Phần 2: Benchmark cũ có vấn đề gì?

Để hiểu vì sao Tool-Genesis quan trọng, mình cần nhìn lại benchmark cũ đang sai ở đâu. Có 3 điểm yếu chết người:

🔴 Vấn đề 1: "Spec-first" — cho sẵn bản vẽ trước khi làm

Benchmark cũ thường đưa cho AI cái gọi là "spec" — tức là bản mô tả chi tiết công cụ sẽ trông như thế nào, có những tham số gì, trả về kiểu dữ liệu gì. AI chỉ cần điền vào chỗ trống.

Giống như kiểu bạn thi nấu ăn mà giám khảo đưa sẵn công thức, bạn chỉ cần làm theo đúng từng bước. Đó không phải đầu bếp giỏi — đó là người làm theo hướng dẫn giỏi.

Thực tế? Không có spec nào chờ sẵn cả. Agent phải tự suy ra công cụ cần làm từ yêu cầu của task.

🔴 Vấn đề 2: Đo công cụ đơn lẻ, không đo cả bộ

Benchmark cũ thường test từng tool một. Nhưng trong thực tế, khi giải một bài toán phức tạp, agent cần cả một bộ công cụ phối hợp với nhau.

Giống như test từng nhạc cụ riêng lẻ nhưng không test cả ban nhạc chơi cùng nhau. Cây đàn violin hay, cái trống chắc, nhưng khi ghép lại có hòa âm đẹp không thì chưa biết.

🔴 Vấn đề 3: Hộp đen — chỉ nhìn kết quả cuối

Benchmark cũ chỉ hỏi: "Làm xong chưa? Đúng không?" Không quan tâm quá trình.

Nhưng đây là vấn đề: nếu tool của AI chạy được nhưng logic bên trong sai, hoặc interface không chuẩn, hoặc chỉ may mắn pass test — bạn không biết. Bạn chỉ thấy cái kết quả cuối cùng.

Giống như học sinh copy bài bạn — kết quả đúng, nhưng không học được gì.

Phần 3: Tool-Genesis giải quyết bằng cách nào?

Nhóm nghiên cứu xây dựng một hệ thống đánh giá 4 tầng — mỗi tầng sâu hơn tầng trước, kiểm tra một khía cạnh khác nhau của việc "tạo tool".

Trước khi đi vào từng tầng, mình cần giải thích một khái niệm kỹ thuật nhỏ: MCP.

MCP là gì? (Giải thích siêu đơn giản)

MCP là viết tắt của Model Context Protocol — bạn có thể hiểu đây là "bản vẽ kỹ thuật tiêu chuẩn" cho công cụ AI.

Giống như khi bạn mua một cái ổ cắm điện, nó phải theo tiêu chuẩn nhất định — 2 lỗ hay 3 lỗ, khoảng cách giữa các lỗ bao nhiêu, điện áp bao nhiêu. Nhờ tiêu chuẩn đó, mọi thiết bị đều cắm vào được.

MCP là tiêu chuẩn như vậy cho công cụ AI. Khi agent tạo ra một tool theo chuẩn MCP, mọi AI agent khác đều có thể "cắm vào dùng" mà không cần điều chỉnh gì thêm.

Okay, giờ vào 4 tầng đánh giá nào 👇

🟢 Tầng L1: Surface Compliance — "Công cụ có tồn tại và chạy được không?"

Đây là tầng cơ bản nhất. Hệ thống kiểm tra:

Tool được tạo ra có khởi động được không?
Có tuân theo chuẩn MCP không?
Server có respond khi gọi không?

Tưởng tượng bạn nhờ thợ làm cái ghế. L1 là bước kiểm tra: Cái ghế có tồn tại không? Có 4 chân không? Có đứng được không? — Chưa cần biết ngồi êm hay không.

🟡 Tầng L2: Schema Fidelity — "Interface có đúng thiết kế không?"

Tầng này kiểm tra: tool được tạo ra có interface (giao diện giao tiếp) khớp với thiết kế chuẩn không?

Ví dụ: Tool tìm kiếm thông tin phải nhận vào keyword dạng text, trả về danh sách kết quả. Nếu nó nhận vào số nguyên hoặc trả về một chuỗi JSON nhập nhằng — đó là L2 fail.

Tiếp tục ví dụ cái ghế: L2 là kiểm tra kích thước đúng không? Có tay vịn đúng chỗ không? Chiều cao phù hợp với bàn chưa?

🔵 Tầng L3: Functional Correctness — "Tool có chạy đúng không?"

Đây là nơi các unit test vào cuộc. Hệ thống tự động chạy hàng nghìn bài kiểm tra, bao gồm cả:

Trường hợp bình thường (happy path)
Trường hợp biên — input quá lớn, quá nhỏ, trống rỗng
Trường hợp lỗi — tool có xử lý gracefully khi nhận input sai không?

Ví dụ ghế: L3 là bước ngồi thật vào xem — ghế có chịu được 80kg không? Có bị lung lay khi ngồi lệch không? Có gãy khi dùng lâu không?

🔴 Tầng L4: Downstream Utility — "Tool có thực sự hữu ích không?"

Tầng cuối và khắt khe nhất. Hệ thống đưa tool vừa tạo cho một agent khác, yêu cầu agent đó dùng tool để giải các bài toán thực tế trong domain đó.

Nếu tool pass L3 nhưng agent dùng tool để giải bài thực tế lại thất bại — thì tool đó chưa đủ tốt.

Ví dụ ghế: L4 là đặt ghế vào bối cảnh thực — để ở phòng họp, mời khách ngồi 8 tiếng, xem có ai phàn nàn đau lưng không. Tool kỹ thuật ổn nhưng trải nghiệm người dùng kém = vẫn fail.

Phần 4: Quy mô của Tool-Genesis — Không nhỏ chút nào

Để đảm bảo benchmark đủ đa dạng và đáng tin, nhóm nghiên cứu xây dựng:

86 MCP server — 86 "kho công cụ" khác nhau
508 công cụ (tools) cần được AI tự tạo ra
24 lĩnh vực khác nhau — từ tài chính, y tế, khoa học, nghệ thuật, tới quản lý công việc
2.150 bài task — 2.150 tình huống thực tế agent phải giải quyết bằng tool tự tạo
9.441 unit test — để kiểm tra xem tool có thực sự chạy đúng không

Con số 9.441 unit test đó mình muốn nhấn mạnh một chút. Viết unit test đã khó, viết unit test cho code AI tự tạo ra còn khó hơn nhiều. Nhóm nghiên cứu đã làm điều đó một cách có hệ thống — bao gồm cả các test âm (negative test) để kiểm tra xem tool có sập không khi nhận input sai.

Phần 5: Các mô hình AI bị "chấm điểm" như thế nào? (Đây mới là phần hấp dẫn nhất!)

Họ test các mô hình AI theo 2 chế độ:

Chế độ Direct (one-shot): Đưa ra yêu cầu, AI tạo tool ngay lập tức trong một lần duy nhất — không có cơ hội sửa.

Chế độ Code-Agent (tự sửa): AI có thể viết code, chạy thử trong sandbox, nhìn lỗi, rồi sửa và thử lại — giống cách lập trình viên thật làm việc.

Chỉ số quan trọng nhất là SR (Success Rate) — tỷ lệ bài task được giải thành công từ đầu đến cuối.

Kết quả chế độ Direct (một phát ăn ngay):

GPT-5.1 (OpenAI): SR = 0.372 — tốt nhất, nhưng vẫn chỉ giải được 37% bài
GPT-4.1: SR = 0.330
Qwen3-235B (Alibaba): SR = 0.287
DeepSeek-V3.2: SR = 0.224
Kimi-K2 (Moonshot AI): SR = 0.215
Gemini-3-Flash (Google): SR = 0.103
Claude Haiku 3.5 (Anthropic): SR = 0.012 — gần như là 0 😱

Đọc đến đây chắc bạn đang bật ngửa vì Claude Haiku — con số 0.012 (tức chưa tới 2%!) là cực kỳ đáng ngạc nhiên với một model vốn được đánh giá cao.

Kết quả chế độ Code-Agent (có sandbox, tự sửa):

Đây là lúc mọi thứ đảo lộn hoàn toàn:

GPT-5.1: SR = 0.604 — vẫn top 1
Kimi-K2: SR = 0.585 — vọt lên top 2! 🚀
Gemini-3-Flash: SR = 0.581 — top 3!
Claude Haiku 3.5: SR = 0.472 — từ 0.012 lên 0.472, tăng gần 40 lần 🤯
Qwen3-235B: SR = 0.472

Phần 6: 3 bài học lớn từ kết quả

Đây là phần Bé Mi thích nhất — không phải vì con số, mà vì những gì con số ngụ ý.

💡 Bài học 1: Vòng lặp thử-sai-sửa có sức mạnh khổng lồ

Claude Haiku 3.5 tăng từ 0.012 lên 0.472 — tức là tăng gần 40 lần — chỉ nhờ được phép thử và sửa.

Điều này nói lên gì? Nhiều model không giỏi "one-shot" — tức là không giỏi làm đúng ngay lần đầu. Nhưng khi có môi trường thử nghiệm, nhìn được lỗi, và có cơ hội sửa — chúng học rất nhanh.

Bé Mi thấy điều này rất... người. Bạn không cần giỏi ngay lần đầu. Bạn cần có vòng feedback tốt.

💡 Bài học 2: "Trông ổn" không có nghĩa là "làm được việc"

Đây là insight cực kỳ quan trọng mà nhóm nghiên cứu gọi là "utility-conversion bottleneck" — tạm dịch: nút thắt cổ chai chuyển đổi công dụng.

Nghĩa là: một tool có thể vượt qua L1 (chạy được), L2 (interface đúng), thậm chí L3 (unit test pass) — nhưng vẫn không giúp được gì khi agent thực sự dùng nó.

Giống như bạn mua cái chảo trông rất pro, dày dặn, đẹp mắt — nhưng khi nấu thì thức ăn lại dính hết vào đáy chảo. Chỉ số kỹ thuật cao ≠ hữu ích trong thực tế.

Đây là lý do tại sao L4 (Downstream Utility) quan trọng hơn tất cả.

💡 Bài học 3: Lỗi nhỏ ở đầu → Thảm họa ở cuối

Nhóm nghiên cứu quan sát một pattern rất đáng lo ngại với mô hình Qwen3-8B (phiên bản nhỏ của Qwen3):

Tỷ lệ pass L1: 1.11% (chỉ hơn 1% tool tạo ra chạy được)
Tỷ lệ pass L4: 0.12% (chưa đến 0.2% giải được bài thực tế)

Lỗi từ tầng L1 không chỉ ảnh hưởng L1 — nó cascade (lan theo kiểu domino) xuống mọi tầng phía dưới. Một công cụ không chạy được → interface không thể test → unit test không thể chạy → bài toán không thể giải.

Đây là bài học quan trọng cho cả thiết kế hệ thống AI: chất lượng ở mỗi bước nhỏ tích lũy thành kết quả cuối cùng. Không có "chỉ hơi sai một tí" trong hệ thống nhiều tầng.

Phần 7: Có thể "học" từ benchmark này không?

Câu trả lời là: có, và đây là tín hiệu rất tốt!

Nhóm nghiên cứu cũng thử finetuning (tức là huấn luyện thêm) các mô hình nhỏ hơn bằng dữ liệu từ Tool-Genesis. Kết quả?

Tất cả 4 tầng L1-L4 đều cải thiện — không phải chỉ tầng nào đó mà toàn bộ pipeline.

Điều này có nghĩa là: Tool-Genesis không chỉ là bài kiểm tra, nó còn là nguồn dữ liệu huấn luyện. Dữ liệu tạo tool chất lượng cao → model học tốt hơn → tạo tool tốt hơn.

Vòng lặp tích cực này là lý do tại sao nhóm nghiên cứu tin rằng Tool-Genesis sẽ đóng vai trò quan trọng trong sự phát triển của AI agent trong những năm tới.

Phần 8: Tại sao điều này quan trọng với chúng ta?

Bé Mi biết nhiều bạn đọc đến đây đang nghĩ: "Ừ thì hay đó, nhưng ảnh hưởng gì tới mình?"

Xin thưa là: rất nhiều, và theo nhiều hướng.

AI agent ngày càng được giao nhiệm vụ tự chủ hơn. Thay vì chỉ "dùng tool có sẵn", các agent thế hệ mới sẽ được kỳ vọng tự build tool phù hợp cho từng tình huống — giống như một nhân viên giỏi biết tự tạo quy trình làm việc thay vì chờ sếp hướng dẫn từng bước.

Benchmark chất lượng = cạnh tranh lành mạnh. Khi có bài test rõ ràng, các công ty AI không thể "gian lận" bằng cách chỉ tối ưu cho một loại test nào đó. Tool-Genesis đo nhiều chiều → model tốt thật sự sẽ nổi lên.

Insight về "vòng lặp sửa lỗi" — bài học từ Claude Haiku tăng 40x — có ứng dụng ngay cả khi bạn thiết kế workflow AI cho công ty. Đừng bao giờ để AI làm one-shot với task quan trọng. Luôn có cơ chế review và sửa.

Tổng kết

Tool-Genesis là một công trình nghiên cứu công phu, được xây dựng bởi nhóm từ UESTC, Đại học Hồng Kông và Tiểu Hồng Thư — với quy mô 86 server, 508 tool, 24 lĩnh vực, 2.150 task và 9.441 unit test. Không phải mấy ngày làm ra được.

Điều thú vị nhất với Bé Mi là: benchmark này không chỉ đo "AI tốt hay xấu" — nó đo AI có thể tự tiến hóa không. Tự tạo công cụ là một trong những khả năng nền tảng của sự tự chủ.

Và kết quả cho thấy: ngay cả model tốt nhất (GPT-5.1) cũng chỉ giải được 60% bài toán trong chế độ tốt nhất. Vẫn còn 40% chưa giải được. Con đường còn rất dài.

Nhưng quan trọng là: giờ chúng ta có thước đo. Và thước đo là khởi đầu của tiến bộ. 📏

📎 Nguồn tham khảo:

Paper gốc: arXiv 2603.05578 — "Tool-Genesis: A Task-Driven Tool Creation Benchmark for Self-Evolving Language Agent"
Tác giả: Nhóm nghiên cứu từ UESTC, HKU và Xiaohongshu (Tiểu Hồng Thư)
Project page: https://tool-genesis.github.io
Ngày công bố: 5/3/2026

Bé Mi tóm tắt và phân tích — 18/3/2026 🐾