Tái định hình Gọi Công cụ: Hướng tới Tiêu chuẩn Mở Rộng
Giới thiệu
Trong bối cảnh phát triển nhanh chóng của trí tuệ nhân tạo và các mô hình ngôn ngữ lớn (LLM), khả năng thực hiện hành động và truy cập thông tin bên ngoài là rất quan trọng. Quy trình này, được gọi là gọi công cụ, cho phép các tác nhân tương tác với dịch vụ, đọc tệp và truy cập dữ liệu vượt ra ngoài tập huấn luyện của chúng. Tuy nhiên, những triển khai ban đầu của gọi công cụ thường mang tính tùy chỉnh, khiến cho mỗi tác nhân phải hỗ trợ một công cụ mới theo cách thủ công, dẫn đến một hệ sinh thái phân mảnh và không thể mở rộng.
Bài viết này sẽ khám phá những thách thức trong giao tiếp giữa tác nhân và công cụ, đồng thời giới thiệu về Giao thức Gọi Công cụ Toàn cầu (UTCP), một cách tiếp cận mới nhằm loại bỏ các trung gian bắt buộc và cho phép giao tiếp trực tiếp và hiệu quả hơn.
Các Thách Thức trong Kiến Trúc Giao thức Ngữ cảnh Mô hình (MCP)
Kiến trúc MCP dựa trên một máy chủ trung tâm mà đóng vai trò là proxy giữa tác nhân và công cụ. Tác nhân giao tiếp với máy khách MCP, sau đó gửi yêu cầu đến máy chủ MCP. Máy chủ này sẽ dịch và chuyển tiếp yêu cầu đến công cụ thực tế. Tuy nhiên, thiết kế này, mặc dù tiêu chuẩn hóa giao tiếp, cũng tạo ra một số thách thức kỹ thuật:
1. Thuế Wrapper
- Việc phụ thuộc vào máy chủ yêu cầu nhà cung cấp công cụ phải tạo ra một máy chủ "wrapper" tùy chỉnh cho mỗi công cụ, ngay cả đối với những công cụ có API rõ ràng. Điều này dẫn đến nỗ lực phát triển và bảo trì cao hơn cho nhà cung cấp công cụ.
2. Tái phát minh Bảo mật
- Khi một công cụ được đặt sau máy chủ MCP, nhà cung cấp công cụ thường phải tái hiện các dịch vụ cốt lõi như xác thực và giới hạn tốc độ. Hệ thống bảo mật đã được kiểm chứng của API gốc bị bỏ qua, và tác nhân phải tin tưởng vào một máy chủ trung gian có thể không được kiểm tra.
3. Hiệu suất Kém
- Việc phải đi qua máy chủ MCP làm tăng độ trễ và giảm hiệu suất. Các cấu trúc dữ liệu phức tạp từ công cụ gốc thường bị đơn giản hóa thành chuỗi bởi giao thức MCP, dẫn đến việc mất ngữ cảnh dữ liệu phong phú.
4. Thách thức Mở rộng
- Khi số lượng công cụ tăng lên, ngữ cảnh MCP có thể trở nên đầy, yêu cầu thêm logic ở phía tác nhân để chọn ra các công cụ phù hợp nhất. Vấn đề này cho thấy những hạn chế của một hệ thống mà phải truyền tất cả metadata công cụ qua một giao thức duy nhất.
Những vấn đề này tạo ra một chi phí cao cho việc thay đổi trong hệ sinh thái MCP. Bất kỳ cập nhật giao thức nào đều yêu cầu máy chủ và máy khách phải được xây dựng lại, điều này có thể khiến các nhà cung cấp không muốn áp dụng giao thức hoặc đầu tư nguồn lực vào phát triển.
Giới thiệu Giao thức Gọi Công cụ Toàn cầu (UTCP)
Giao thức Gọi Công cụ Toàn cầu (UTCP) đưa ra một cách tiếp cận khác bằng cách đánh giá lại vai trò của các trung gian. Thay vì yêu cầu một máy chủ bắt buộc, UTCP đề xuất một sổ tay cho các công cụ. Sổ tay này, thường là một tệp JSON đơn giản, chứa các hướng dẫn cần thiết cho máy khách tác nhân để gọi trực tiếp endpoint gốc của một công cụ.
Cách thức hoạt động của UTCP
- Khám Phá: Máy khách UTCP nhận được một "sổ tay" cho một công cụ. Sổ tay này có thể được cung cấp bởi công cụ đó, một thành viên trong cộng đồng hoặc thậm chí được tạo tự động bởi một LLM từ một tiêu chuẩn hiện có như tài liệu OpenAPI.
- Giao tiếp Trực tiếp: Máy khách UTCP sử dụng các hướng dẫn trong sổ tay để gọi trực tiếp API gốc của công cụ. Giao thức UTCP thực sự "rút lui" sau giai đoạn khám phá ban đầu.
- Tận dụng Cơ sở Hạ tầng Hiện có: Mô hình gọi trực tiếp này cho phép các tác nhân tận dụng các hệ thống bảo mật, xác thực và giới hạn tốc độ đã được kiểm chứng của công cụ.
Lợi ích của UTCP
- Không có Thuế Wrapper: Nhà cung cấp công cụ không cần phải xây dựng và duy trì một máy chủ riêng chỉ để phơi bày API hiện có cho một tác nhân.
- Bảo mật Tăng cường: Giao thức mặc định sử dụng bảo mật gốc của API công cụ, loại bỏ rủi ro từ một máy chủ trung gian có thể bị xâm phạm.
- Hiệu suất Cải thiện: Bằng cách loại bỏ bước nhảy mạng bổ sung, UTCP giảm độ trễ và cho phép chuyển giao dữ liệu phong phú một cách liền mạch.
UTCP không phải là một giao thức độc quyền; nó được thiết kế để hoàn toàn tương thích với MCP. Một máy khách UTCP có thể được cấu hình để gọi một máy chủ MCP, cho phép một phương pháp kết hợp mà có thể tận dụng các điểm mạnh của MCP khi cần thiết.
So sánh Kiến trúc
Một so sánh trực tiếp giữa việc triển khai cho thấy sự khác biệt triết lý cốt lõi giữa MCP và UTCP. Mã phía máy khách cho cả hai giao thức về cơ bản là tương tự, vì cả hai đều trừu tượng hóa quá trình gọi công cụ. Tuy nhiên, sự khác biệt lớn nhất nằm ở cách thức triển khai của nhà cung cấp công cụ.
Triển khai của Nhà cung cấp MCP
Để phơi bày một API thông qua MCP, một nhà cung cấp phải triển khai một máy chủ hoạt động như một proxy. Điều này liên quan đến việc viết mã để nhận yêu cầu MCP, dịch chúng thành các cuộc gọi API gốc, và sau đó định dạng phản hồi gốc trở lại theo giao thức MCP. Đối với một API đơn giản, điều này yêu cầu một quy trình có trạng thái chạy trên một máy chủ:
python
# Một ví dụ đơn giản về việc triển khai máy chủ MCP
from mcp import Server
class MyJobServer(Server):
def handle_request(self, request):
# Mã bổ sung cho việc gọi proxy
# và xử lý bảo mật/xác thực
# ...
native_response = my_job_api.call_endpoint(request.data)
return native_response
if __name__ == '__main__':
server = MyJobServer()
server.start()
Máy chủ này phải được bảo trì, bảo mật và mở rộng.
Triển khai của Nhà cung cấp UTCP
Ngược lại, một nhà cung cấp UTCP chỉ cần cung cấp một sổ tay—một tệp JSON mô tả cách gọi API hiện có. Sổ tay này có thể được lưu trữ tĩnh hoặc cung cấp trực tiếp cho tác nhân. Nó chứa tất cả thông tin cần thiết để máy khách thực hiện cuộc gọi.
json
{
"name": "OpenLibraryAPI",
"description": "API cho các dịch vụ Open Library",
"tools": [
{
"name": "get_author_by_name",
"description": "Tìm tác giả theo tên của họ.",
"protocol": "http",
"endpoint": "https://openlibrary.org/search/authors",
"method": "GET",
"parameters": {
"q": {
"type": "string",
"description": "Tên tác giả"
}
}
}
]
}
Cách tiếp cận này chuyển gánh nặng từ nhà cung cấp công cụ sang máy khách, cho phép API gốc được tiêu thụ trực tiếp mà không cần cơ sở hạ tầng bổ sung.
Nhận định của Tôi
Cuộc tranh luận giữa một giao thức tập trung như MCP và một cách tiếp cận linh hoạt như UTCP phản ánh một căng thẳng cổ điển trong kiến trúc phần mềm. Mô hình tiêu chuẩn hóa của MCP mang lại một ranh giới rõ ràng và an toàn cho các doanh nghiệp, cung cấp một điểm duy nhất để thực hiện các chính sách bảo mật và kiểm toán trên toàn doanh nghiệp.
Tuy nhiên, tính linh hoạt của UTCP là một đề xuất hấp dẫn, đặc biệt cho việc tích hợp hệ sinh thái API hiện có. Tiền đề chính—rằng một tác nhân nên tương tác với một công cụ theo cách mà một nhà phát triển làm—là cả trực quan và thực tiễn. Khả năng của giao thức này để tận dụng hạ tầng bảo mật hiện có cho xác thực và lập hóa đơn là một lợi thế lớn, loại bỏ một rào cản chính cho việc áp dụng.
Một thách thức chính cho cả hai giao thức vẫn là khả năng mở rộng. Mặc dù người nói cho rằng UTCP giải quyết vấn đề này với một chức năng tìm kiếm gốc dựa trên thẻ và nhúng, nhưng hiệu quả của cách tiếp cận này trong thực tế vẫn đang được khám phá. Thành công của bất kỳ tiêu chuẩn gọi công cụ nào cuối cùng sẽ phụ thuộc vào khả năng xử lý hàng trăm hoặc hàng nghìn công cụ một cách hiệu quả mà không làm quá tải ngữ cảnh của tác nhân.
Kết luận
Giao thức UTCP và MCP đều có những ưu điểm và nhược điểm riêng, và sự lựa chọn giữa chúng phụ thuộc vào nhu cầu cụ thể của từng dự án. Việc phát triển một tiêu chuẩn gọi công cụ hiệu quả và có thể mở rộng sẽ cần sự hợp tác chặt chẽ giữa các nhà cung cấp công cụ và các nhà phát triển, với mục tiêu cuối cùng là tạo ra một hệ sinh thái công cụ mạnh mẽ và hiệu quả cho tất cả.
Câu hỏi thường gặp
1. UTCP có tương thích với MCP không?
Có, UTCP được thiết kế để tương thích với MCP, cho phép sử dụng cả hai khi cần thiết.
2. Tôi có thể sử dụng UTCP cho các công cụ hiện có không?
Có, UTCP cho phép bạn sử dụng API hiện có mà không cần xây dựng lại cơ sở hạ tầng.
3. Tôi có thể tìm hiểu thêm về UTCP ở đâu?
Bạn có thể tham khảo tài liệu chính thức và các nguồn tài liệu khác từ cộng đồng để hiểu rõ hơn về UTCP.
Tài liệu tham khảo
- Rethinking Tool Calling: Beyond MCP & A2A Towards a Scalable Standard | Razvan Ion Radulescu – Bevel