Agent gọi tool — playbook kiểm soát lớp rủi ro nhất

Agent gọi tool — playbook kiểm soát lớp rủi ro nhất

Orchestration ngon rồi nhưng agent vẫn phá production? Vấn đề thường nằm ở lớp tool-calling. Playbook 4 bước siết guardrail cho builder.

Tháng trước mình review một hệ thống agent cho một startup fintech ở TP.HCM. Orchestration sạch sẽ, state management đàng hoàng, observability có đủ. Nhưng ngày thứ ba chạy production, agent tự gọi API xóa draft invoice của khách vì nó "hiểu" rằng draft cũ cần dọn trước khi tạo mới. Không ai cấu hình cho nó quyền xóa — nhưng cũng không ai cấm nó.

Bài 612 mình đã chia sẻ playbook tổng thể cho multi-agent production. Bài này đi sâu vào đúng một lớp: tool-calling — nơi agent chạm vào thế giới thật và gây hậu quả thật.

Playbook này giải quyết gì

Nếu team bạn đã có agent chạy được, orchestrator hoạt động ổn, nhưng vẫn lo "nó sẽ gọi tool gì ngoài dự kiến" — bài này dành cho bạn.

Sau khi đọc xong, bạn sẽ có framework để:

Nghĩ như thế này: orchestration là bố cục tổng thể của bức tranh, nhưng tool-calling là lớp sơn lót. Bỏ qua lớp lót, màu phía trên bong tróc sau vài tuần — dù nhìn lúc mới vẽ thì đẹp.

Bốn bước siết tool-calling

1. Phân tier tool theo hậu quả

Không phải tool nào cũng nguy hiểm như nhau. Chia thành ba tier:

| Tier | Đặc điểm | Ví dụ | Cần gì |
|------|-----------|-------|--------|
| Read-only | Không thay đổi state | Search web, fetch webpage, đọc file | Chỉ cần rate limit |
| Write-internal | Thay đổi state nội bộ | Ghi file workspace, lưu memory | Validate format + scope |
| Write-external | Tác động ra ngoài hệ thống | Gọi API thanh toán, gửi email, xóa record | Human approval hoặc policy engine |

Giả sử team bạn 5 người đang xây research agent tương tự kiến trúc LangGraph — có tool search web, fetch trang, chạy Python, ghi file, và gọi sub-agent. Bước đầu tiên: dán nhãn tier cho từng tool. Search và fetch là tier 1. Ghi file là tier 2. Chạy Python code tùy ý? Tier 2.5 — vì nó có thể ghi file, gọi network, hoặc tốn resource.

2. Sandbox theo nguyên tắc least privilege

Mỗi tool chỉ được phép làm đúng những gì nó cần, không hơn.

Với tool thực thi code (Python execution, shell command), sandbox là bắt buộc — không phải nice-to-have. Cụ thể:

Đây là chỗ nhiều team bỏ qua khi làm demo. Demo thì chạy trên Colab, mọi thứ mở toang. Production thì mỗi tool cần chạy trong container hoặc ít nhất một process riêng với permission scope tường minh.

3. Validate trước khi thực thi

Tool-calling có hai pha: agent quyết định gọi tool gì với tham số gì, rồi hệ thống thực thi lệnh đó. Guardrail nên nằm giữa hai pha này.

Cụ thể, thêm một lớp validation:

def validate_tool_call(tool_name, params, agent_permissions):
    # Check agent có quyền gọi tool này không
    if tool_name not in agent_permissions.allowed_tools:
        return Rejected("Tool not in scope")
    
    # Check params hợp lệ
    if tool_name == "write_file" and not params["path"].startswith(SANDBOX_DIR):
        return Rejected("Path outside sandbox")
    
    # Check tier - nếu tier 3, cần approval
    if get_tier(tool_name) == "write-external":
        return NeedApproval(tool_name, params)
    
    return Approved()

Lớp này đơn giản nhưng chặn được phần lớn sự cố. Anh fintech ở đầu bài nếu có lớp này, agent sẽ bị reject khi cố gọi delete_invoice — vì tool đó thuộc tier write-external mà không có approval flow.

4. Long-term memory cần guardrail riêng

Agentic memory — bộ nhớ dài hạn giúp agent nhớ thông tin qua nhiều phiên — là tính năng mạnh nhưng cũng là vector tấn công. Nếu agent có thể tự ghi vào memory mà không ai kiểm duyệt, nó có thể "tự dạy" bản thân những rule sai.

Guardrail cho memory:

Bẫy mà team hay bước vào

"Tool nhiều thì agent thông minh hơn" — Không. Mỗi tool thêm vào là thêm một chiều quyết định cho model. Giả sử bạn đưa cho agent 15 tool, model phải chọn đúng tool trong 15 lựa chọn mỗi bước. Xác suất chọn sai tăng phi tuyến. Kinh nghiệm thực tế: giữ dưới 7-8 tool cho mỗi agent. Nếu cần nhiều hơn, tách thành sub-agent chuyên biệt — mỗi sub-agent chỉ thấy tool của mình.

"Sandbox làm chậm iteration" — Ban đầu thì đúng, thêm vài giờ setup. Nhưng một incident production do agent ghi đè dữ liệu khách sẽ tốn vài ngày fix + mất trust. Tỷ lệ đầu tư này không cần tính toán phức tạp.

"Model tốt hơn sẽ tự biết không gọi tool sai" — Đây là hiểu lầm nguy hiểm nhất. Bài 608 mình đã nói: nâng model không cứu được agent thiếu guardrail. Model có thể reasoning tốt hơn, nhưng một lần hallucinate (bịa tham số) là đủ gây sự cố.

Bắt đầu chiều nay

Nếu team bạn đang có agent chạy production hoặc sắp lên production:

  1. Liệt kê tất cả tool agent đang có quyền gọi. Dán nhãn tier.
  2. Tìm tool tier 3 (write-external) — thêm approval gate ngay, dù chỉ là log + alert.
  3. Thêm validation layer giữa lúc agent quyết định và lúc tool thực thi. Bắt đầu bằng check permission + check path/domain.
  4. Review memory (nếu có) — xem agent đã tự ghi gì, có entry nào lệch không.

Bốn việc này không cần framework mới, không cần thay model. Chỉ cần thêm một lớp code mỏng giữa agent và thế giới bên ngoài. Giống như họa sĩ quét lớp gesso lên canvas trước khi vẽ — không ai thấy lớp đó trong tranh hoàn chỉnh, nhưng thiếu nó thì màu sẽ thấm ngược và hỏng toàn bộ.

Nói thẳng ra: agent không đáng sợ. Tool không được kiểm soát mới đáng sợ.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo