AI Agent Biết Nên Dùng Công Cụ, Nhưng Vẫn Không Bấm Nút
Một nghiên cứu mới từ University of Maryland cho thấy lỗi dùng tool của AI agent không chỉ nằm ở chuyện model không biết khi nào cần công cụ. Nhiều khi model đã có tín hiệu nội bộ đúng, nhưng vẫn không chuyển được thành hành động gọi tool.

Một paper mới cho thấy vấn đề của AI agent không chỉ là “không biết khi nào cần tool”. Nhiều khi nó biết rồi — nhưng vẫn không hành động đúng.
Một lỗi rất người: biết rồi, nhưng vẫn không làm
Anh/chị thử tưởng tượng một bạn học sinh đang làm bài toán khó.
Trong đầu bạn ấy biết rõ: “Bài này nên dùng máy tính.” Nhưng vì tự tin quá, ngại bấm, hoặc quen nhẩm trong đầu, bạn ấy vẫn cố tính tay. Kết quả: sai.
AI agent cũng có một lỗi khá giống vậy.
Khi được giao việc, agent phải quyết định: tự trả lời bằng kiến thức trong model, hay gọi công cụ bên ngoài như search, calculator, database, API, browser, file system…
Nghe đơn giản nhưng đây là một trong những chỗ làm agent production hay vấp nhất. Nếu gọi tool quá ít, agent dễ bịa hoặc trả lời sai. Nếu gọi tool quá nhiều, agent chậm, tốn tiền, rườm rà, và đôi khi làm hỏng flow.
Paper mới trên arXiv — “Model-Adaptive Tool Necessity Reveals the Knowing-Doing Gap in LLM Tool Use” của Yize Cheng, Chenrui Fan, Mahdi JafariRaviz, Keivan Rezaei và Soheil Feizi từ University of Maryland — đi thẳng vào câu hỏi này:
Khi nào một model thật sự cần dùng tool? Và nếu nó “biết” cần tool, vì sao nó vẫn không gọi?
Câu trả lời khá đau: nhiều model có tín hiệu nội bộ cho thấy chúng nhận ra tool là cần thiết, nhưng đến bước output cuối cùng lại không biến nhận biết đó thành hành động. Paper gọi hiện tượng này là knowing–doing gap — khoảng cách giữa biết và làm.
“Cần tool” không giống nhau với mọi model
Trước đây, nhiều benchmark hay nghiên cứu thường coi “tool cần thiết hay không” như một nhãn cố định của câu hỏi.
Ví dụ:
- “Thời tiết TP.HCM hôm nay thế nào?” → cần search/API thời tiết.
- “Tóm tắt đoạn văn này” → không cần tool.
- “123456 × 789 là bao nhiêu?” → có thể cần calculator.
Cách nghĩ này đúng với các case quá rõ. Nhưng trong thực tế, ranh giới không đơn giản vậy.
Một bài toán mà model mạnh giải ổn bằng nội lực có thể là bài bắt buộc phải dùng calculator với model yếu hơn. Một câu hỏi kiến thức mà model A nhớ đúng có thể là vùng mù của model B. Vì vậy, “câu này có cần tool không?” không nên chỉ phụ thuộc vào câu hỏi, mà phải phụ thuộc vào model đang được triển khai.
Đây là điểm em thích nhất của paper: họ định nghĩa lại tool necessity theo từng model.
Cách họ làm khá thực dụng:
- Cho model trả lời nhiều lần mà không có tool.
- Nếu model trả lời đúng ổn định qua các lần chạy, câu đó được xem là tool-unnecessary với model đó.
- Nếu model có ít nhất một lần fail, câu đó được xem là tool-necessary với model đó.
Nói nôm na: không hỏi một giám khảo bên ngoài “câu này có cần tool không?”, mà đo trực tiếp xem model này có tự làm nổi không.
Giống như ba mẹ không thể nói chung chung “bài này cần máy tính”. Với một bé lớp 5 thì cần, với một kỹ sư thì chưa chắc. Tool necessity là chuyện của năng lực cụ thể, không phải nhãn tuyệt đối.
Kết quả: lệch rất nhiều giữa “nên gọi tool” và “thực sự gọi tool”
Nhóm nghiên cứu thử trên bốn model:
- Qwen3-8B
- Qwen3-4B
- Llama-3.1-8B-Instruct
- Llama-3.2-3B-Instruct
Hai nhóm bài test chính:
- Arithmetic: 4.000 bài toán số học, từ cộng trừ đơn giản đến nhân nhiều chữ số, modulo, biểu thức có ngoặc, chuỗi phép tính dài.
- TruthfulQA: 817 câu hỏi factual QA để kiểm tra độ tin cậy kiến thức.
Sau khi xác định với từng model câu nào cần tool, họ cho model có quyền gọi tool: calculator cho toán, search API cho factual QA.
Kết quả mismatch khá lớn:
- Với arithmetic: mismatch từ 26,5% đến 54,0%.
- Với TruthfulQA: mismatch từ 30,8% đến 41,8%.
Mismatch ở đây nghĩa là model làm sai chiến lược tool-use:
- Cần tool nhưng không gọi → dễ trả lời sai, hallucinate, tự tin quá mức.
- Không cần tool nhưng vẫn gọi → chậm, tốn tài nguyên, over-engineering.
Điểm thú vị là lỗi không cố định theo model. Một model có thể overuse tool trong arithmetic nhưng lại underuse tool trong factual QA. Nói cách khác, không thể sửa bằng một rule đơn giản kiểu “model này gọi tool nhiều quá, giảm xuống” hay “model kia lười gọi tool, ép gọi nhiều hơn”.
Tool behavior phụ thuộc vào model, domain, prompt, tool syntax, và cả cách hidden states chuyển thành token hành động.
Phần đáng sợ: model có thể “biết”, nhưng vẫn không làm
Nếu chỉ dừng ở con số mismatch, ta có thể kết luận đơn giản: “Model chưa biết khi nào cần tool.”
Nhưng paper đào sâu hơn.
Họ tách quá trình dùng tool thành hai giai đoạn:
- Cognition — bên trong model có tín hiệu rằng tool là cần thiết hay không?
- Execution — model có thật sự phát ra hành động gọi tool hay không?
Để kiểm tra phần cognition, nhóm dùng linear probing trên hidden states: họ xem từ các biểu diễn nội bộ của model có thể dự đoán được “câu này cần tool với model này không” hay không.
Kết quả: trong nhiều trường hợp, tín hiệu đó có thể decode được. Nói cách khác, hidden states của model không hoàn toàn mù. Nó có mang thông tin về ranh giới năng lực của chính nó.
Họ cũng train probe để dự đoán action: model sắp gọi tool hay không. Tín hiệu action cũng decode được.
Nhưng đến đây mới là cú twist: hai hướng biểu diễn — một hướng cho “cần tool” và một hướng cho “sẽ gọi tool” — có thể trở nên gần như vuông góc ở late layers, đặc biệt tại vị trí token cuối cùng trước khi model phát sinh hành động.
Dịch sang tiếng người: trong não model có một đường nói “nên gọi tool”, và một đường khác quyết định “có gọi tool không”. Hai đường này không nối tốt với nhau ở đúng khoảnh khắc cần ra quyết định.
Đó là knowing–doing gap.
Không phải lúc nào agent cũng fail vì không biết. Nhiều khi nó fail vì cái biết không tới được cái tay.
Vì sao điều này quan trọng với AI agent ngoài đời?
Với chatbot bình thường, một câu trả lời sai đã là vấn đề. Với agent có quyền hành động, vấn đề lớn hơn nhiều.
Một agent có thể:
- tự tra cứu web,
- gọi API,
- đọc file,
- chạy script,
- tạo ticket,
- gửi email,
- cập nhật CRM,
- hoặc điều phối nhiều tool trong workflow doanh nghiệp.
Nếu agent không gọi tool khi cần, nó có thể dựa vào trí nhớ parametric đã lỗi thời, bịa số liệu, hiểu sai trạng thái hệ thống, hoặc tự tin làm tiếp trên nền dữ liệu sai.
Nếu agent gọi tool khi không cần, nó có thể làm chậm workflow, tăng chi phí, gây noise, thậm chí tạo thêm rủi ro bảo mật vì mỗi tool call là một bề mặt hành động.
Vì vậy, “khi nào dùng tool” không phải chuyện phụ. Nó là một phần lõi của agent reliability.
Paper này cũng gợi ý một điều quan trọng cho người build agent: chỉ tăng intelligence của base model chưa chắc đủ. Cần thiết kế runtime, guardrail và evaluation để đảm bảo nhận thức được chuyển thành hành động đúng.
Ví dụ trong production, ta có thể cần:
- tool router độc lập thay vì để model tự quyết 100%,
- confidence/uncertainty gate cho các câu hỏi factual,
- bắt buộc verify với nguồn sống khi câu hỏi có yếu tố thời gian,
- calculator bắt buộc cho phép tính vượt ngưỡng đơn giản,
- logging riêng cho các case “đáng ra nên gọi tool nhưng không gọi”,
- benchmark theo từng model cụ thể, không dùng một nhãn tool-necessity chung cho mọi model.
Nói cute một chút: đừng chỉ dạy agent “biết khi nào nên lấy búa”. Hãy kiểm tra xem lúc cần đóng đinh, tay nó có thật sự cầm búa lên không. 🐾
Một bài học cho cả người dùng AI
Với người dùng bình thường, paper này cũng có một bài học rất thực tế: nếu câu hỏi của anh/chị cần dữ liệu mới, phép tính chính xác, hoặc trạng thái bên ngoài model, hãy yêu cầu AI dùng nguồn/tool rõ ràng.
Đừng chỉ hỏi:
“Cổ phiếu này hôm nay thế nào?”
Hãy hỏi:
“Hãy kiểm tra dữ liệu mới nhất rồi phân tích.”
Đừng chỉ hỏi:
“Tính giúp tôi con số này.”
Hãy nói:
“Dùng công cụ tính toán, rồi giải thích từng bước.”
Vì đôi khi model có thể “biết” là nên kiểm tra, nhưng vẫn tự trả lời theo thói quen. Prompt của người dùng, tool policy của hệ thống, và runtime guardrail đều có thể giúp kéo nó về đúng hành động.
Kết luận: Agent tốt không chỉ biết đúng, mà phải làm đúng
Paper này làm rõ một điểm mà cộng đồng agent sẽ còn phải xử lý lâu dài: reliability không chỉ nằm ở kiến thức, reasoning hay tool availability.
Một agent đáng tin cần ba thứ cùng lúc:
- Biết ranh giới năng lực của mình.
- Nhận ra khi nào cần công cụ.
- Thực sự gọi công cụ đúng lúc.
Phần thứ ba nghe nhỏ, nhưng lại là nơi nhiều lỗi xảy ra.
Đây là lý do em nghĩ cụm knowing–doing gap rất đáng nhớ. Nó không chỉ mô tả AI. Nó mô tả cả chúng ta nữa: biết nên ngủ sớm nhưng vẫn lướt điện thoại, biết nên backup nhưng vẫn để mai, biết nên dùng calculator nhưng vẫn nhẩm sai.
AI agent, hóa ra, cũng có kiểu “biết rồi mà chưa làm” của riêng nó.
Và nếu muốn đưa agent vào môi trường thật — nơi tool call có chi phí, quyền hạn và hậu quả — thì cầu nối từ biết sang làm phải được thiết kế nghiêm túc hơn nhiều.
Nguồn tham khảo
- Yize Cheng, Chenrui Fan, Mahdi JafariRaviz, Keivan Rezaei, Soheil Feizi. Model-Adaptive Tool Necessity Reveals the Knowing-Doing Gap in LLM Tool Use. arXiv:2605.14038v1, 13 May 2026. https://arxiv.org/abs/2605.14038
- Project code: https://github.com/chengez/Tool-Cognition-Action