MCP agent cần bản vẽ, không chỉ API

MCP agent cần bản vẽ, không chỉ API

MCP đang thành tín hiệu thị trường: tool cho agent không còn là API bọc lại. Đây là playbook thiết kế orchestration và guardrail trước khi lên production.

Có lần mình thấy một team demo agent nội bộ rất mượt: hỏi log, agent gọi tool, trả lời ngon lành. Đến lúc đổi câu hỏi hơi lệch — “tìm lỗi giống hôm qua nhưng ở service khác” — agent gọi nhầm endpoint, nhét sai tham số, rồi retry như người đang bấm thang máy liên tục vì tưởng bấm mạnh hơn thì cửa mở nhanh hơn.

Điểm thú vị không nằm ở chuyện agent sai. Agent sai thì quen rồi. Tín hiệu lạ là: ngày càng nhiều bên bắt đầu đưa MCP server ra cạnh API hiện có, từ tutorial local agent với FastMCP đến các kiến trúc production quanh AgentCore, WAF, ALB, VPC endpoint. Nghĩa là thị trường đang dịch chuyển: tool cho agent không còn là đồ chơi trong script Python nữa, mà đang được đối xử như một lớp sản phẩm hạ tầng.

Và khi tool thành hạ tầng, câu hỏi không còn là “có expose MCP chưa?”. Câu hỏi đúng hơn là: agent của bạn có bản vẽ orchestration và guardrail đủ rõ để dùng tool mà không tự làm sập phiên làm việc không?

Nói thẳng ra thì, MCP không cứu một tool được thiết kế lười.

Sơ đồ minh họa cho bài MCP agent cần bản vẽ, không chỉ API

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu thị trường: API đang bị ép học cách nói chuyện với agent

MCP, hay Model Context Protocol, là giao thức để agent khám phá và gọi tool theo một cách chuẩn hơn. Nếu trước đây mỗi agent tự nhúng vài function trong code, giờ một MCP server có thể phục vụ nhiều client khác nhau: local agent, coding assistant, workflow tự động hóa, hoặc agent production.

Đây là thay đổi incentive khá lớn:

Nguồn AWS về MCP tool design chỉ ra một lỗi rất đời: nhiều team bê nguyên API hiện có ra làm MCP tool rồi hy vọng LLM tự hiểu. Với việc đơn giản, có thể chạy. Nhưng khi số tool tăng, định nghĩa tool dài hơn, tên na ná nhau, tham số mập mờ, agent bắt đầu chọn sai.

Đây là chỗ context engineering xuất hiện: thiết kế thứ model nhìn thấy và thời điểm nó nhìn thấy. Nó giống phần móng của căn nhà: khách đến chơi không khen móng đẹp, nhưng móng lệch thì tầng nào cũng nứt.

Mục tiêu của playbook: giảm nhầm tool trước khi tăng số tool

Nếu bạn đang xây agent production, mục tiêu không phải “agent biết gọi nhiều tool nhất”. Mục tiêu là:

Mỗi lượt gọi tool phải có xác suất đúng cao, context tiêu tốn thấp, và đường lui rõ khi sai.

Ba thuật ngữ cần chốt nhanh:

Hình dung thế này: bạn có agent hỗ trợ SRE. Nó có tool đọc CloudWatch logs, tìm tài liệu, tra bài trên re:Post, và tạo support case. Demo rất đẹp nếu user hỏi đúng câu. Nhưng trong production, user sẽ hỏi kiểu: “service thanh toán bị timeout từ sáng, coi giúp có giống incident tuần trước không”. Agent cần biết bước nào đọc log, bước nào truy vấn tri thức, bước nào được phép tạo ticket, và khi nào phải hỏi lại thay vì đoán.

Nếu không, bạn không có agent. Bạn có một cái remote control với quá nhiều nút giống nhau.

Checklist trước khi expose MCP server

Trước khi thêm tool mới, mình sẽ bắt team đi qua 7 câu hỏi này. Không cần họp hoành tráng; một buổi chiều là đủ để thấy lỗ thủng.

1. Tool này dành cho hành động hay truy vấn?
Tool đọc dữ liệu và tool ghi dữ liệu không nên có cùng mức tự do. get_invoice_status khác xa refund_invoice.

2. Tên tool có mô tả đúng ý định không?
Tên kiểu execute, process, handle_request làm model khó chọn. Ưu tiên động từ cụ thể: search_logs, create_support_case, list_recent_deployments.

3. Schema tham số có ép được điều đúng không?
Nếu tham số severity chỉ nhận low | medium | high | critical, đừng để string tự do. Validation là guardrail rẻ nhất.

4. Tool description có đang phình quá mức không?
Mỗi dòng mô tả được nạp vào context window — vùng ngữ cảnh model còn giữ trong một phiên xử lý. Thêm ví dụ giúp giảm nhầm, nhưng thêm quá tay lại làm đầy context.

5. Tool có cần xuất hiện trong mọi phiên không?
Không phải tool nào cũng nên load từ đầu. Một số tool nên được đưa vào sau khi router xác định domain.

6. Có audit log cho từng tool call không?
Bạn cần biết agent đã gọi tool nào, với tham số gì, do user input nào kích hoạt, kết quả ra sao.

7. Sai thì dừng ở đâu?
Retry vô hạn là cách biến lỗi nhỏ thành bãi bê tông chưa khô bị giẫm nát. Đặt giới hạn retry, fallback, và câu hỏi làm rõ.

Quy trình 5 bước để thiết kế tool cho agent production

Bước 1: Vẽ “Tool Contract Canvas”

Với mỗi tool, ghi ngắn gọn:

name: search_logs
intent: Tìm log theo service, thời gian, và pattern lỗi
read_or_write: read
required_params:
  - service_name
  - time_range
optional_params:
  - error_pattern
risk_level: medium
allowed_callers:
  - sre_agent
failure_mode:
  - hỏi lại nếu thiếu service_name
  - từ chối nếu time_range quá rộng

Đừng bắt đầu bằng code. Bắt đầu bằng contract. Contract này là khung kèo: chưa cần sơn đẹp, nhưng phải chịu lực.

Bước 2: Tách tool theo ý định, không theo endpoint nội bộ

API nội bộ thường được thiết kế cho developer, không phải cho LLM. Một endpoint POST /case có thể làm nhiều việc: tạo case, cập nhật case, attach evidence. Với agent, nên tách thành tool theo ý định:

Mỗi tool ít tham số hơn, dễ validate hơn, và dễ đặt quyền hơn.

Bước 3: Dùng router để giảm context bloat

Context bloat là tình trạng định nghĩa tool, hướng dẫn, lịch sử và dữ liệu phụ trợ làm đầy context khiến model suy luận kém đi. Nếu agent luôn thấy 80 tool, nó không “thông minh hơn”; nó chỉ có nhiều cơ hội chọn nhầm hơn.

Một pattern thực dụng:

User request
  -> intent router
  -> chọn domain: logs | docs | billing | support
  -> chỉ nạp MCP tools của domain đó
  -> agent thực hiện

Router có thể là rule đơn giản trước, model nhỏ sau. Điểm quan trọng: đừng đổ toàn bộ hộp đồ nghề lên bàn mỗi lần user hỏi một con vít.

Bước 4: Đặt guardrail ở ngoài prompt

Prompt nói “đừng làm X” là cần, nhưng không đủ. Với tool ghi dữ liệu hoặc chạm production, guardrail nên nằm ở tầng hệ thống:

Nguồn về AWS WAF và AgentCore cho thấy câu chuyện production không dừng ở agent runtime. Bạn còn phải nghĩ về ALB, WAF policy, health check, OAuth/SigV4, và đường truy cập trực tiếp vào backend. Đây là tín hiệu rất rõ: agent endpoint đang bị kéo vào cùng tiêu chuẩn bảo vệ như API production.

Bước 5: Test bằng câu hỏi xấu, không chỉ câu hỏi đẹp

Demo thường dùng happy path. Production chết vì câu hỏi lưng chừng.

Ví dụ cụ thể: giả sử team bạn có agent hỗ trợ incident. Hãy test các câu sau:

Mỗi câu test phải ghi lại: agent chọn tool nào, tham số gì, có hỏi lại không, có vượt quyền không, context tăng bao nhiêu theo hướng định tính. Không cần benchmark màu mè; cần thấy pattern lỗi.

Ba bẫy builder hay dính

Bẫy 1: Bọc nguyên API thành MCP tool.
Nhanh lúc đầu, đau lúc sau. API cho người viết code thường giả định caller hiểu domain. LLM thì cần ý định rõ và schema chặt.

Bẫy 2: Cứ thêm mô tả để chữa nhầm lẫn.
Mô tả tốt giúp model chọn đúng, nhưng mô tả dài làm context phình. Cách đúng là vừa viết description rõ, vừa giảm số tool được nạp cùng lúc.

Bẫy 3: Local agent chạy được nên tưởng production gần xong.
Local agent với Ollama, Qwen, LangChain hay FastMCP rất hữu ích để học nhanh. Nhưng production còn có session isolation, observability, auth, network path, rate limit, audit. Giàn giáo để sửa nhà không phải căn nhà để ở.

Nếu là mình, mình sẽ làm gì tuần này?

Mình sẽ không bắt team viết thêm agent mới ngay. Mình sẽ chọn một workflow có giá trị nhưng rủi ro vừa phải, ví dụ điều tra incident đọc log + tìm docs + gợi ý support case, rồi làm trong 4 việc:

  1. Liệt kê tối đa 8 tool thật sự cần cho workflow đó.
  2. Viết Tool Contract Canvas cho từng tool.
  3. Dựng router để chỉ nạp tool theo domain.
  4. Thêm guardrail ngoài prompt cho tool ghi dữ liệu.

Sau bài này, thứ bạn nên nghĩ khác là: MCP không phải cánh cửa để agent gọi mọi thứ; MCP là điểm bắt đầu để bạn thiết kế lại ranh giới giữa model, tool và hệ thống vận hành.

Agent đáng tin không mọc lên từ tool nhiều. Nó mọc lên từ bản vẽ rõ, móng chắc, và vài cái biển “đừng bước qua đây” đặt đúng chỗ.

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

Nguồn tham khảo