Tool Use là gì và cách dùng tool an toàn
TL;DR: Tool use là khi AI không chỉ trả lời bằng chữ mà còn gọi công cụ: đọc file, chạy test, fetch Lark Doc, query Base, mở browser, tạo image, hoặc gọi API. Tool làm AI hữu ích hơn, nhưng cũng làm rủi ro cao hơn nếu quyền ghi/xóa không được kiểm soát.
Cập nhật 31/07/2026: Với agent hiện đại, thiết kế tool interface và permission quan trọng hơn việc nhồi nhiều ví dụ lệnh. Tool nên có tên rõ, schema rõ, trạng thái rõ và cách verify rõ.
Tool Use là gì?
Tool use là khả năng model chọn và gọi một công cụ bên ngoài để hoàn thành task. Công cụ có thể là local CLI, MCP server, connector, browser, database, Lark CLI hoặc API nội bộ.
Không có tool, AI chỉ tư vấn. Có tool, AI có thể tạo artifact thật.
Các loại tool trong workflow Diginno
| Loại tool | Ví dụ | Rủi ro chính |
|---|---|---|
| Local shell | rg, npm run build, git diff |
Xóa/sửa file sai nếu command nguy hiểm |
| File edit | sửa MDX, code, config | Ghi đè thay đổi của người khác |
| Browser/devtools | kiểm tra UI, console, network | Nhìn nhầm environment hoặc session |
| Lark CLI | Docs, Wiki, Base, Drive | Ghi nhầm node/doc, sai identity user/bot |
| MCP/connectors | DB, GitHub, Notion, Sheets | Quyền đọc/ghi rộng, dữ liệu nhạy cảm |
| API/webhook | n8n, backend, third-party | Gọi production ngoài ý muốn |
Tool use khác gì prompt thường?
Prompt thường tạo text. Tool use tạo hành động. Vì vậy task có tool cần thêm governance:
- AI đang chạy bằng identity nào?
- Tool có quyền read-only hay write?
- Có dry-run hoặc preview không?
- Output có chứa secret/dữ liệu khách không?
- Sau khi tool chạy, verify bằng gì?
Quy tắc an toàn khi dùng tool
- Read trước write. Đọc file/doc/node/schema trước khi sửa.
- Scope nhỏ. Chỉ sửa đúng file/doc/task được yêu cầu.
- Không chạy lệnh destructive. Tránh
rm, reset, checkout, delete nếu chưa có xác nhận rõ. - Dry-run khi có thể. Đặc biệt với Lark move/delete, deploy, database write.
- Verify surface thật. Lark thì fetch/node-list; web thì build/browser; API thì response/log.
- Ghi lại artifact. Link Wiki, file path, commit, test result hoặc URL.
Tool description nên viết thế nào?
Theo hướng context engineering mới, đừng chỉ đưa nhiều ví dụ. Hãy thiết kế description/schema để agent hiểu cách dùng:
- Tên tool nói đúng hành động.
- Tham số có kiểu và enum rõ.
- Output có trạng thái
success/failed/pendingrõ. - Rủi ro write/delete được đánh dấu.
- Tool tự nói khi cần confirmation hoặc next command.
CLI evidence loop là gì?
Đây là vòng lặp tối thiểu khi AI có quyền sửa repo:
1. Search: rg để tìm đúng file/pattern.
2. Read: mở file liên quan, không đoán API.
3. Edit: sửa scope nhỏ.
4. Verify: build/lint/test hoặc fetch live surface.
5. Report: nói rõ đã làm gì, chưa làm gì, rủi ro còn lại.
Ví dụ: publish Lark Wiki đúng cách
Một task Lark không xong khi file local đã sửa. Xong nghĩa là:
- Tạo/update Lark Doc bằng
--as userđúng quyền. - Move vào đúng Wiki space/node.
- Fetch outline hoặc node-list để verify.
- Lưu lại URL trong artifact local nếu cần.
Bài học cần nhớ
Tool biến AI từ người viết nháp thành người vận hành. Vì vậy càng nhiều tool, càng phải rõ quyền, scope, dry-run và verification. Diginno dùng AI nhanh, nhưng không bỏ qua bằng chứng hoàn thành.
Bài viết hữu ích?
Chia sẻ để nhiều người biết đến!
>_ LLM-Friendly Copy
Copy as Markdown to use with ChatGPT, Claude, or other AI tools
