TROISINH
Phát triển AgentSkills & Tools nâng cao

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_execread_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_file song song với web_search (2 node độc lập) → cả 2 đổ vào python_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:

  1. 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.
  2. Syntactic Layer (Tool System): Thực thi "làm như thế nào" — parse JSON arguments, validate schema, gọi API.
  3. 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ốngTool phù hợpNguyên tắc
Tính toán số học phức tạp (>3 phép tính)python_execKhông tin vào "mental math" của LLM
Đọc file CSV >100 dòngread_file + python_execTrá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 browserKnowledge cutoff mitigation
Truy vấn database nội bộMCP database/queryQua MCP server, không hardcode SQL trong prompt
Tạo hình ảnhimage_generationNon-parametric output (không sinh ảnh bằng text description)
Thao tác hệ thống (rm, curl)bash với strict allowlistLuô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_search có 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

On this page