Định tuyến công cụ agent: MCP, nhà cung cấp và chính sách
Hướng dẫn thực tế về Định tuyến công cụ agent: MCP, nhà cung cấp và chính sách, gồm MCP tools, provider choice, gateway policy, đánh đổi production và kiểm tra kết quả.
Agent tool routing là lớp quyết định nhà cung cấp mô hình nào xử lý mỗi lệnh gọi công cụ mà agent thực hiện, và liệu lệnh gọi đó có được phép hay không. Nếu làm tốt, nó mang lại khả năng chuyển đổi dự phòng, kiểm soát chi phí và dấu vết kiểm toán. Nếu làm kém, mỗi máy chủ MCP hoặc lệnh gọi hàm mới đều trở thành một điểm thoát API không được quản lý.
Agent thực sự định tuyến điều gì
Hầu hết các framework agent hiện nay đều hiển thị công cụ dưới dạng các hàm mà mô hình có thể gọi. Khi LLM phát ra một lệnh gọi công cụ, runtime phải giải quyết ba điều: danh tính công cụ, các đối số, và nhà cung cấp hạ nguồn có thể thực thi nó. Bước cuối cùng đó chính là nơi định tuyến tồn tại.
Công cụ được chia thành ba loại chính:
- Công cụ cục bộ chạy bên trong runtime của chính bạn: đọc tệp, tìm kiếm vector, API nội bộ.
- Công cụ MCP chạy trên máy chủ bên ngoài sử dụng Model Context Protocol. Agent khám phá chúng qua MCP client, gửi yêu cầu và chờ kết quả.
- Công cụ dựa trên mô hình thực chất chỉ là các lệnh gọi LLM lồng nhau với thêm một số bước — tóm tắt, phân loại, hoặc tạo mã được gửi trở lại nhà cung cấp.
Gateway nằm giữa agent và hai loại sau. Nó không chỉ là proxy; đó là điểm thực thi chính sách. Vì lý do đó, cách tiếp cận agent tool routing MCP gateway bắt đầu từ chính sách, không phải giao thức.
MCP thay đổi cấu trúc liên kết
Các máy chủ MCP biến một agent đơn lẻ thành client của nhiều khả năng bên ngoài. Một agent lập trình có thể gọi máy chủ MCP để truy cập hệ thống tệp, máy chủ khác để tìm kiếm web, và máy chủ thứ ba để truy cập cơ sở dữ liệu. Mỗi lệnh gọi đều rời khỏi biên giới của bạn và quay trở lại.
Bản thân giao thức khá đơn giản: tin nhắn JSON-RPC qua stdio hoặc HTTP(SSE). Lộ trình Model Context Protocol đang phát triển nhanh chóng, và cơ chế khám phá máy chủ vẫn đang được hoàn thiện, nhưng mô hình bảo mật đã rõ ràng. Bạn không thể để mọi agent tự chọn máy chủ MCP, thông tin xác thực, và nhà cung cấp mô hình của riêng mình.
Ba rủi ro xuất hiện ngay lập tức:
- Chi tiêu ngầm. Agent gọi một công cụ dựa trên mô hình không có giới hạn có thể đốt cháy hạn ngạch mà không có con người can thiệp.
- Rò rỉ dữ liệu. Công cụ gọi nhà cung cấp bên ngoài có thể chuyển tiếp ngữ cảnh mà bạn không định để rời khỏi mạng của mình.
- Thiếu kiểm toán. Nếu lệnh gọi công cụ xảy ra bên trong vòng lặp agent, nhật ký ứng dụng của bạn có thể không ghi lại được yêu cầu, phản hồi, hoặc chi phí.
Gateway mang lại một nơi duy nhất để kiểm tra, giới hạn tốc độ và ghi log mọi lệnh gọi dựa trên mô hình.
Tại sao lựa chọn nhà cung cấp lại quan trọng đối với lệnh gọi công cụ
Không phải lệnh gọi công cụ nào cũng cần cùng một mô hình. Công cụ trích xuất các trường có cấu trúc từ một prompt ngắn không cần mô hình suy luận hàng đầu. Công cụ viết lại nội dung cho khách hàng thì có thể cần. Định tuyến theo khả năng và giá giúp giảm độ trễ và chi tiêu có thể dự đoán được.
Lựa chọn nhà cung cấp được chia thành một số quyết định cụ thể:
| Quyết định | Câu hỏi cần đặt | Quy tắc định tuyến điển hình |
|---|---|---|
| Phù hợp khả năng | Công cụ này có cần suy luận, chế độ JSON, thị giác, hay ngữ cảnh dài không? | Định tuyến công cụ mã đến các mô hình có khả năng tuân thủ chỉ dẫn và đầu ra JSON tốt. |
| Ngân sách độ trễ | Lệnh gọi này có nằm trên đường dẫn quan trọng của yêu cầu người dùng không? | Sử dụng mô hình nhanh hơn, rẻ hơn cho lệnh gọi đồng bộ; trì hoãn công việc nặng. |
| Trần chi phí | Chi tiêu mỗi tác vụ hoặc mỗi người dùng là bao nhiêu? | Giới hạn token mỗi lệnh gọi và chuyển sang nhà cung cấp rẻ hơn khi có thể. |
| Lưu trữ dữ liệu | Prompt này có được phép rời khỏi khu vực hoặc nhà cung cấp không? | Gắn các khối lượng công việc được quản định vào các nhà cung cấp cụ thể hoặc endpoint tự lưu trữ. |
| Chuỗi dự phòng | Điều gì xảy ra khi nhà cung cấp chính gặp sự cố? | Thử lại trong nhà cung cấp, sau đó tràn sang nhà cung cấp thứ hai có đầu ra tương thích. |
Trang /channels trong AveMujica API liệt kê các nhà cung cấp hạ nguồn mà bạn có thể đưa vào các quy tắc này. Trang /model-list hiển thị mô hình nào hỗ trợ các tính năng mỗi công cụ cần, chẳng hạn như function calling, thị giác, hoặc đầu ra có cấu trúc.
Kiểm tra lần cuối: 2026-06-22. Khả năng và giá của nhà cung cấp thay đổi nhanh chóng; hãy xác minh tính năng mô hình với tài liệu tham khảo OpenAI API hiện tại, tài liệu Anthropic API, hoặc tài liệu Google Gemini API trước khi khóa quy tắc định tuyến vào sản xuất.
Các cổng chính sách mọi lệnh gọi agent nên vượt qua
Quyết định định tuyến chỉ tốt khi chính sách thực thi nó. Tối thiểu, mỗi lệnh gọi công cụ agent nên đi qua các cổng sau:
- Xác thực. Agent hoặc người dùng có được phép gọi công cụ này không?
- Giới hạn tốc độ. Giới hạn theo người dùng, theo công cụ, và theo nhà cung cấp ngăn chặn các vòng lặp mất kiểm soát.
- Rào cản chi tiêu. Ngân sách chi phí hoặc token tối đa mỗi lệnh gọi, với khả năng chặn hoặc hạ cấp.
- Xác thực đầu ra. JSON trả về có khớp với schema mà agent mong đợi không? Phản hồi công cụ bị định dạng sai sẽ phá vỡ phần còn lại của vòng lặp agent.
- Ghi log. Ai đã gọi gì, nhà cung cấp nào phục vụ, chi phí bao nhiêu, và có thành công không.
Đường dẫn /usage-logs/common cung cấp cho vận hành viên một cái nhìn thống nhất về dấu vết này. Không có nó, đội ngũ phải tái dựng hành vi agent từ hóa đơn nhà cung cấp.
Nhật ký kiểm toán là yêu cầu của định tuyến, không phải suy nghĩ muộn màng
Khi agent gặp sự cố, bạn cần tái tạo lại chuỗi: prompt, lựa chọn công cụ, nhà cung cấp, phản hồi, chi phí. OWASP Top 10 for LLM Applications 2025 chỉ ra quyền hạn quá mức và tiết lộ thông tin nhạy cảm là những rủi ro cốt lõi. Cả hai đều trở nên tồi tệ hơn khi các lệnh gọi công cụ không để lại bản ghi.
Một nhật ký kiểm toán hữu ích cho agent tool routing cần ghi lại:
- Tên và phiên bản công cụ
- Toàn bộ payload yêu cầu và phản hồi của nhà cung cấp, trong phạm vi chính sách lưu giữ của bạn
- Mô hình và nhà cung cấp được sử dụng
- Số lượng token và chi phí
- Danh tính người dùng hoặc agent
- Dấu thời gian và độ trễ
- Các quyết định chính sách: cho phép, chặn, hạ cấp, hoặc thử lại
Đây không chỉ là tuân thủ hình thức. Đó là cách bạn tìm ra công cụ định dạng đầu ra sai sau một bản cập nhật nhà cung cấp, hoặc vòng lặp agent thử lại một công cụ bị lỗi năm mươi lần.
Kết hợp lại: một mô hình vận hành
Cách thực tế để nghĩ về agent tool routing là phân tách các mối quan tâm theo từng lớp:
| Lớp | Sở hữu | Ví dụ |
|---|---|---|
| Framework agent | Định nghĩa công cụ, schema, quy ước gọi | Function call kiểu OpenAI, thiết lập MCP client |
| Gateway | Lựa chọn nhà cung cấp, thực thi chính sách, ghi log | AveMujica API định tuyến lệnh gọi đến nhà cung cấp có hạn ngạch và ghi lại kết quả |
| Nhà cung cấp | Suy luận mô hình, thời gian hoạt động, định giá | OpenAI, Anthropic, Gemini, Azure, Bedrock |
| Vận hành | Khả năng quan sát, xem xét chi tiêu, điều chỉnh chính sách | Xem /usage-logs/common hàng tuần, điều chỉnh trọng số /channels |
Sự phân tách này giữ cho mã agent gọn gàng trong khi tập trung hóa các quyết định ảnh hưởng đến chi phí và rủi ro. Đồng thời có nghĩa là bạn có thể thay đổi nhà cung cấp mà không cần viết lại agent.
Kết nối với quản trị API rộng hơn
Agent tool routing là một phần của cùng một lĩnh vực với quản trị khóa API cho các team AI. Cả hai đều nhằm mục đích làm cho việc truy cập mô hình có thể quan sát và kiểm soát được. Nếu team bạn đã tập trung hóa khóa và hạn ngạch, thêm chính sách định tuyến công cụ là bước logic tiếp theo.
Điều tương tự cũng đúng với tính minh bạch chi phí. Khả năng hiển thị giá mô hình có ý nghĩa vì các lệnh gọi công cụ làm tăng số lần gọi mô hình. Một tác vụ agent duy nhất có thể gọi mô hình năm hoặc mười lần qua các công cụ khác nhau. Nếu không có phân bổ chi phí theo công cụ, bạn không thể biết khả năng nào đang ngốn ngân sách.
AveMujica API giúp ở đâu
Khi workflow AI đi vào lưu lượng thật, câu hỏi không còn là “gọi được mô hình không” mà là ai được dùng, tốn bao nhiêu và xử lý lỗi thế nào. AveMujica API gom quyền truy cập mô hình, bối cảnh giá, ví và lịch sử sử dụng vào một console.
- Bắt đầu bằng một workflow thật.
- So sánh quyền truy cập mô hình, chi phí và log mà không phải ghép nhiều dashboard nhà cung cấp.
- Mở rộng khi độ trễ, chi phí và chủ sở hữu đã rõ.
Gateway nên giảm việc vận hành lặp lại: key, hóa đơn, giới hạn nhà cung cấp và sự cố không nên nằm rải rác ở nhiều nơi.
Bắt đầu từ một workflow
Chọn một workflow thật và kiểm tra trong AveMujica API rằng quyền truy cập mô hình, bối cảnh giá, log sử dụng và ngân sách khớp với nhau trước khi mở rộng lưu lượng.
Câu hỏi thường gặp
Đội ngũ nên quyết định gì trước với Định tuyến công cụ agent: MCP, nhà cung cấp và chính sách?
Bắt đầu từ quyền sở hữu và ranh giới chính sách: group hoặc key nào sở hữu workflow, mô hình nào được phép dùng và tín hiệu nào chứng minh chính sách đang hoạt động.
Sau khi triển khai nên theo dõi chỉ số nào?
Theo dõi chỉ số gần tác động người dùng nhất: chi phí trên tác vụ thành công, tỷ lệ fallback, p95 latency, request bị chặn hoặc biến động quota. Sau đó nối chỉ số đó với usage logs.
Bao lâu nên xem lại?
Các thông tin về giá và mô hình thay đổi nhanh. Hãy xem lại hàng tháng, và xem lại ngay sau sự cố, lần ra mắt mới hoặc thay đổi giá.
Nên so sánh gì
| Phạm vi | Câu hỏi | Kiểm tra ở đâu |
|---|---|---|
| Ownership | Who owns this workflow? | usage logs and scoped API keys |
| Cost | Which unit can grow fastest? | pricing, model catalog, and wallet |
| Reliability | What failure pattern matters? | dashboard overview and channel history |
| Governance | What should be reviewed next month? | groups, quotas, key scope, and request history |
Bắt đầu từ một workflow
Chọn một workflow thật và kiểm tra trong AveMujica API rằng quyền truy cập mô hình, bối cảnh giá, log sử dụng và ngân sách khớp với nhau trước khi mở rộng lưu lượng.