40+ Built-in Tools: Khi nào dùng tool nào?
Khám phá cách 40+ built-in tools biến LLM thành agent thực chiến. Không phải để trang trí — đây là tư duy chọn primitive và thiết kế composition để tránh con...
Agent hiện đại không còn là "cái đầu" đơn độc nữa. Chúng được trang bị 40+ công cụ built-in — từ Python interpreter, bash terminal, đến browser automation và vector DB — biến LLM từ "bộ não" thành "cơ thể" có thể hành động trên thế giới thực. Nhưng đây không phải là bài viết liệt kê catalog: chúng ta sẽ nói về tư duy chọn lọc primitive và cách thiết kế composition để tránh "drowning in capabilities", cùng với việc áp dụng progressive disclosure để giữ context window sạch sẽ.
Vấn đề
LLM là "bộ nhớ mất mát" (lossy compression algorithm) — terabytes văn bản được nén thành gigabytes weights. Khi bạn hỏi "234×567 bằng bao nhiêu?", model có thể đã nhớ câu trả lời trong weights, nhưng artifact của nén dữ liệu gây ra lỗi. Hoặc tệ hơn, model tự tin tính nhẩm rồi đưa ra kết quả sai thay vì dùng calculator.
Vấn đề còn nghiêm trọng hơn với file I/O và dữ liệu thời gian thực. Pre-training không thể bao hồm mọi kịch bản tool chain (tổ hợp công cụ) — đó là bài toán bùng nổ tổ hợp (combinatorial explosion). Cách tiếp cận cũ — viết prompt dài dòng "nhớ dùng tool khi cần" — thất bại vì hiện tượng tool blindness: model bỏ qua tool có sẵn để tự giải quyết việc tưởng chừng đơn giản (ví dụ: tự tính toán thay vì gọi calculator).
Thêm vào đó, việc nạp 40 tool descriptions vào system prompt ngốn ~8.000 tokens, chỉ còn lại 24k cho dữ liệu người dùng trong cửa sổ 32k. Context bloat không chỉ tốn tiền — nó làm loãng attention mechanism, khiến model "quên" mục tiêu ban đầu giữa rừng function signatures.
Ý tưởng cốt lõi
Bản chất của built-in tools là type-safe reality check — như compiler ngăn bạn cộng string với integer, tool schema ngăn LLM hallucinate API parameters. 40 tool không phải để dùng riêng lẻ, mà là 40 primitive để tổ hợp thành ~2^40 workflow (nguyên lý universal constructor).
Progressive Disclosure: SKILL.md cho Tool System
Thay vì dump toàn bộ 40 tool vào prompt mỗi lần inference, áp dụng pattern tương tự SKILL.md:
- Tier 1 (Metadata): Chỉ load
name+description(≤200 chars) của tất cả tools — như "mục lục" để model biết có những gì. Ví dụ:"python_exec: Run Python code in sandbox for data analysis". - Tier 2 (Trigger): Khi model match intent với keyword (ví dụ: "phân tích CSV"), mới inject chi tiết parameter schema của
python_execvàread_file. - Tier 3 (Execution): Chỉ khi tool được gọi, mới nạp environment variables và connection strings (ví dụ: DB credentials qua MCP).
Ví dụ thực chiến với data analysis:
# data_analysis_skill.md
---
name: "Data Analysis Agent"
description: "Use this when user asks about statistics, CSV processing, or pandas operations"
tools: ["python_exec", "read_file", "write_file"]
## Workflow
1. Always use `read_file` to verify schema before pandas operations
2. Use `python_exec` with pandas, numpy, matplotlib
3. Save results via `write_file` to /outputs/Composition Logic: ReAct vs DAG
Cách tổ hợp tools quyết định hiệu quả:
- ReAct Loop (Reason → Act → Observe): Phù hợp exploratory tasks. Agent lý luận → chọn tool → quan sát output → lý luận tiếp. Phù hợp khi không biết trước sequence (ví dụ: debug lỗi production).
- DAG Planner (Directed Acyclic Graph): Phù hợp ETL hoặc data pipeline biết trước. Ví dụ:
read_filesong song vớiweb_search(2 node độc lập) → cả 2 đổ vàopython_exec(merge node) →write_file.
Ví dụ pipeline phân tích cạnh tranh:
read_file(./competitors.csv) ─┐
├─► python_exec(analysis.py) ─► write_file(report.md)
web_search("Q3 2024 trends") ─┘Thiết kế Tool: Naming và Description
Từ kinh nghiệm production trong tool design guide:
- Naming: Dùng verb+noun mô tả business task (
reconcile_invoice_payments) thay vì CRUD kỹ thuật (POST /invoices). Điều này tạo "conceptual magnets" — vector embeddings của tên tool nằm gần intent vector của người dùng. - Description: Phải chứa when to use (khi nào dùng), input schema, return format. Ví dụ:
"Use ONLY when user asks about past transactions; requires customer_id in UUID format; returns empty list if none found". - Error Contracts: Trả về structured error thay vì
"Error 400". Ví dụ:{"error": "MISSING_FIELD", "field": "date_range", "expected_format": "ISO 8601"}để LLM self-correct ở turn tiếp theo.
Tại sao nó hoạt động
Cơ chế hoạt động dựa trên separation of concerns kiến trúc:
- Semantic Layer (LLM): Quyết định "muốn làm gì" — chọn tool dựa trên pattern matching giữa intent và description.
- Syntactic Layer (Tool System): Thực thi "làm như thế nào" — parse JSON arguments, validate schema, gọi API.
- Policy Layer (Hooks): Kiểm soát "được phép làm gì" — pre-action hooks chặn shell injection, post-action hooks log và audit.
Sandbox execution (E2B, Docker) là critical: mỗi tool call spawn container với 10-30s timeout, stdout/stderr captured làm "observation tokens" cho LLM ở turn sau. Điều này tách biệt reasoning (probabilistic) khỏi execution (deterministic), tránh lỗi hallucinate trên arithmetic hay file I/O.
Benchmark từ SWE-bench cho thấy: agent có code interpreter đạt 43% solve rate, trong khi raw Chain-of-Thought chỉ đạt 12.8%. Đó là sự khác biệt giữa "bộ não" và "tay chân".
Ý nghĩa thực tế
Bản đồ chọn tool theo tình huống
| Tình huống | Tool phù hợp | Nguyên tắc |
|---|---|---|
| Tính toán số học phức tạp (>3 phép tính) | python_exec | Không tin vào "mental math" của LLM |
| Đọc file CSV >100 dòng | read_file + python_exec | Tránh copy-paste nội dung file vào context |
| Dữ liệu real-time (giá cổ phiếu, thời tiết) | web_search hoặc browser | Knowledge cutoff mitigation |
| Truy vấn database nội bộ | MCP database/query | Qua MCP server, không hardcode SQL trong prompt |
| Tạo hình ảnh | image_generation | Non-parametric output (không sinh ảnh bằng text description) |
| Thao tác hệ thống (rm, curl) | bash với strict allowlist | Luôn kết hợp 5-layer security |
Anti-patterns cần tránh
- Tool Blindness: Model tự tính "234×567" thay vì dùng calculator. Fix: Prompt engineering negative constraint — "You MUST use calculator for all arithmetic".
- Cascading Errors: Một lệnh bash sai xóa nhầm workspace. Fix: Quality gates bắt buộc dry-run trước khi thực thi.
- Context Pollution: Load tất cả 40 tools cho task chỉ cần 2 cái. Fix: SKILL.md routing để lazy-load.
Giới hạn
- Latency Tax: Mỗi tool call thêm 2-5s roundtrip. Pipeline 7 bước (WebArena benchmark) có thể mất 30s+.
- Decision Fatigue: 40 tools available làm model "phân vân" — generation time tăng khi phải chọn giữa nhiều options tương đồng semantic.
- Sandbox Escape: Nếu không configure SSRF protection, tool
web_searchcó thể pivot thành vector tấn công nội bộ (169.254.169.254).
Đào sâu hơn
Tài liệu chính thức:
- MCP Specification — Protocol chuẩn để expose tools cho agents
- SWE-bench — Benchmark evaluation cho code-agent với tool use
Bài liên quan TroiSinh:
Cùng cụm (Skills & Tools):
Skill System: Từ SKILL.md đến progressive disclosure
Hiểu sâu hơn về cách tổ chức tool qua 3-tier architecture để giảm context bloat
Tạo Custom Skill: Package kiến thức thành markdown
Hướng dẫn tạo SKILL.md cho data analysis riêng của bạn
MCP cho Agent: Kết nối tools theo chuẩn mở
Kết nối database và external APIs qua Model Context Protocol
Thiết kế Tool cho Agent: Naming, description, error handling
Best practices đặt tên và mô tả tool để tránh tool blindness
Đọc tiếp:
Hooks & Quality Control: Kết hợp tool với validation
Kiến trúc 25+ lifecycle events để chặn hành động nguy hiểm trước khi chạy
Memory & Context: Quản lý trạng thái cross-session
Khi tool cần nhớ kết quả từ lần chạy trước
MCP cho Agent: Kết nối tools theo chuẩn mở — Giải pháp cho bài toán N×M
MCP (Model Context Protocol) chuẩn hóa kết nối AI agent với tools qua JSON-RPC, giải quyết bài toán N×M integrations và tiết kiệm 98% context tokens qua acti...
Thiết kế Tool cho Agent: Naming, description, error handling — Khi 'tay chân' AI hiểu sai ý
Tại sao agent gọi nhầm tool liên tục? Cách đặt tên, mô tả và xử lý lỗi để agent chọn đúng 'tay chân' mỗi lần, giảm 30% lỗi selection.