Series Claude Opus 4.7 #2: Cấp quyền "Thượng phương bảo kiếm" – Tool Use và Kỹ năng điều khiển Terminal
Ở Bài 1, chúng ta đã nhắc đến việc một AI Agentic (như khái niệm Opus 4.7 mà chúng ta đang giả lập) không chỉ biết "chat" mà còn biết "hành động". Nhưng bản thân một mô hình ngôn ngữ lớn (LLM) thực chất chỉ là một khối toán học khổng lồ nằm trên server, nó không hề có "tay chân" để gõ phím.
Vậy làm thế nào để nó có thể tự chui vào server Linux, đọc file log và restart lại service Golang của hệ thống AFC? Bí mật nằm ở một tính năng mang tính cách mạng: Tool Use (Sử dụng công cụ).
1. Bản chất của Tool Use (Function Calling)
Hãy tưởng tượng bạn đang là một Giám đốc (AI Agent) bị mù và bị trói tay, nhưng bù lại bạn có một bộ não thiên tài. Để làm việc, bạn thuê một cậu Thư ký (chính là đoạn code kết nối API do bạn viết).
- Bước 1: Bạn (AI) nói với Thư ký: "Tôi cần biết CPU của server đang là bao nhiêu".
- Bước 2: Thư ký nhận lệnh, tự động gõ lệnh top -bn1 trên Terminal.
- Bước 3: Thư ký lấy kết quả Terminal trả về (chuỗi text) và đọc lại cho bạn (AI) nghe.
- Bước 4: Bạn (AI) nghe xong, phân tích: "CPU đang 99%, nguyên nhân do tiến trình ID 1234. Hãy gõ lệnh kill -9 1234 cho tôi!".
Đó chính xác là cách Tool Use hoạt động. Bạn định nghĩa sẵn một tập hợp các "công cụ" (chạy lệnh bash, truy vấn SQL, gọi API bên thứ 3) và cấp cho AI quyền gọi các công cụ đó khi nó thấy cần thiết.
2. Dạy AI cách dùng Tool (Định nghĩa JSON Schema)
Để AI biết nó có những vũ khí gì trong tay, bạn phải đưa cho nó một quyển "Hướng dẫn sử dụng" viết bằng định dạng JSON.
{
"name": "execute_bash_command",
"description": "Thực thi một lệnh bash an toàn trên server Linux. Chỉ dùng khi cần đọc log, kiểm tra trạng thái tiến trình hoặc file system.",
"input_schema": {
"type": "object",
"properties": {
"command": {
"type": "string",
"description": "Lệnh bash cần chạy. Ví dụ: 'tail -n 100 /var/log/afc.log'"
}
},
"required": ["command"]
}
}
Khi AI đọc được JSON này, nó hiểu: "À, mình có một phép thuật tên là execute_bash_command. Bất cứ khi nào cần bới móc hệ thống, mình chỉ cần trả về một chuỗi JSON yêu cầu chạy lệnh, hệ thống bên ngoài sẽ chạy giùm mình."
3. Thực chiến: Agent tự động Debug sự cố nghẽn Kafka
Hãy đặt AI vào một kịch bản DevOps thực tế. Nửa đêm, hệ thống giám sát CloudWatch báo động đỏ: Độ trễ đồng bộ vé offline đang tăng đột biến.
Thay vì bạn phải lọ mọ mở laptop, bạn kích hoạt Agent. Dưới đây là cuộc hội thoại nội tâm (System 2 Thinking) và chuỗi hành động của nó:
- Suy luận 1: "Độ trễ tăng. Cần kiểm tra xem service Consumer Kafka có đang sống không. Mình sẽ dùng công cụ execute_bash_command."
- Hành động 1: Gọi Tool ➔ docker ps | grep afc-kafka-consumer
- Kết quả trả về: Container vẫn đang trạng thái Up.
- Suy luận 2: "Container vẫn sống nhưng tại sao lại nghẽn? Khả năng cao là bị kẹt logic hoặc văng lỗi Panic trong Golang. Cần đọc 50 dòng log cuối cùng."
- Hành động 2: Gọi Tool ➔ docker logs --tail 50 afc-kafka-consumer
- Kết quả trả về: ERROR: Dialing Vitess database timeout. Connection refused.
- Suy luận 3: "Lỗi rồi! Không phải do Kafka, mà do service này mất kết nối tới Database Vitess. Cần kiểm tra xem có ai đổi cấu hình mạng không, hoặc mạng nội bộ đang đứt."
- Hành động 3: Gọi Tool ➔ ping -c 3 vitess-master.local
- Kết quả trả về: 100% packet loss.
Kết luận cuối cùng gửi cho bạn: > "Hệ thống Kafka consumer không lỗi, nhưng nó đang bị timeout do không kết nối được tới Vitess (vitess-master.local). Tôi vừa ping thử và thấy rớt mạng hoàn toàn. Đề nghị bạn kiểm tra lại Security Group hoặc VPC kết nối giữa 2 cụm này ngay lập tức."
Chỉ trong vài giây, AI đã tự động chẩn đoán xong một quy trình mà một Kỹ sư DevOps con người phải mất ít nhất 10-15 phút gõ lệnh thủ công.
4. Rào chắn sinh tử (Human-in-the-loop)
Khi bạn cấp cho AI quyền gọi API và gõ lệnh Terminal, sức mạnh của nó là vô song. Nhưng rủi ro cũng tỷ lệ thuận.
Sẽ ra sao nếu AI phân tích sai và tự động sinh ra quyết định: "Ổ cứng đầy rồi, để tôi chạy lệnh rm -rf / để dọn dẹp"? Hoặc nguy hiểm hơn là gọi lệnh xóa bảng trong Database Production?
Quy tắc vàng trong thiết kế Agentic Workflow là: Không bao giờ cho Agent quyền Auto-Approve (Tự động phê duyệt) ở những tác vụ phá hủy (Destructive Actions).
Kiến trúc thực tế bắt buộc phải có cơ chế Human-in-the-loop (Con người can thiệp):
- Với các lệnh đọc (Read-only) như cat, tail, docker ps, ping: Cho phép AI tự động chạy 100%.
- Với các lệnh ghi/sửa/xóa (Write/Delete) như docker rm, systemctl restart, DROP TABLE: Agent chỉ được phép tạo ra câu lệnh. Trước khi lệnh đó thực sự chạm vào server, hệ thống sẽ đẩy một thông báo về Slack/Telegram của bạn: "AI đề xuất chạy lệnh khởi động lại Service A. [Chấp nhận] / [Từ chối]". Bạn bấm nút, lệnh mới được chạy.
All Rights Reserved
