Trước đây, nối N công cụ với M mô hình đòi hỏi N×M lớp thích ứng. MCP tách phía công cụ khỏi phía mô hình để mỗi bên chỉ cần triển khai giao thức một lần. Bài viết trình bày lựa chọn thiết kế này, cách trừu tượng hóa môi trường và thao tác trình duyệt, cùng những vấn đề hiện vẫn chưa được giải quyết.
Khi một Agent thực sự bắt tay vào làm việc, cuối cùng thường phải thao tác trong trình duyệt: đăng nhập, đăng nội dung, thu thập dữ liệu hoặc điền biểu mẫu. Điểm khó về kỹ thuật không phải là có bấm được hay không, mà là chi phí tích hợp khi giao trình duyệt cho Agent.
Vũng lầy tích hợp N×M
Giả sử trên thị trường có N công cụ và M mô hình. Nhà cung cấp công cụ phải viết một bộ mã tích hợp cho từng mô hình, còn phía mô hình cũng cần một lớp thích ứng cho từng công cụ. Hai bên tự bảo trì phần của mình, tổng cộng thành N×M triển khai.
Rắc rối nằm ở phép nhân. Thêm một công cụ không chỉ là thêm một phần việc, mà phải nối công cụ đó với từng mô hình. Ngược lại, khi mô hình đổi phiên bản, các công cụ đã tích hợp cũng có thể phải xác minh lại. Một khả năng dù tốt đến đâu, nếu chưa có thích ứng cho một mô hình cụ thể thì vẫn không dùng được ở đó — công cụ bị kẹt ở khâu phân phối.
Ở giai đoạn đầu, mỗi bên chỉ có thể tự viết. Cùng một việc như liệt kê môi trường, khởi động trình duyệt, đọc trang, nhưng đổi bên gọi là phải viết lại, và logic thường không thống nhất: có bên đặt phần chờ ở client, có bên đặt ở server.
Giao thức tách hai phía khỏi nhau
MCP (Model Context Protocol) được công khai vào cuối năm 2024. Cách làm là chuẩn hóa việc khám phá và gọi công cụ: công cụ phơi bày gì, mô tả tham số ra sao và trả về cấu trúc nào đều được quy định trong giao thức.
Kiến trúc vì thế trở thành Agent nối với một MCP Client; Client dùng giao thức để nối đến nhiều MCP Server, còn năng lực cụ thể nằm phía sau các Server đó. Khối lượng triển khai giảm từ N×M xuống N+M: phía mô hình triển khai client một lần, phía công cụ triển khai server một lần.
Chỉ có ba vai trò. Host là ứng dụng chạy mô hình và chịu trách nhiệm khởi động client. Client là phần triển khai phía khách của giao thức, thường một Client tương ứng với một Server. Server do nhà cung cấp công cụ viết, đóng gói năng lực thành các công cụ chuẩn hóa để cung cấp ra ngoài.
Hiện có hai kiểu giao tiếp. Chế độ cục bộ dùng đầu vào/đầu ra chuẩn, client và server ở cùng một máy; đường truyền ngắn, ít cấu hình nên được dùng nhiều trong tự động hóa. Chế độ từ xa dùng HTTP hoặc WebSocket, phù hợp với triển khai phân tán nhưng phải cân nhắc kỹ hơn về xác thực và ranh giới mạng.
Trong trình duyệt, có ba lớp năng lực được phơi bày
Khi nối môi trường trình duyệt vào giao thức, các năng lực được phơi bày nhìn chung nằm ở ba lớp.
Lớp trên cùng là môi trường: liệt kê các môi trường trong tài khoản, tạo mới theo cấu hình, khởi động môi trường chỉ định, gắn lối ra mạng và đóng sau khi dùng. Trước đây các thao tác này nằm rải rác trong API của từng nhà cung cấp; nay chúng trở thành các công cụ mà mô hình có thể khám phá và gọi. Sau khi khởi động, hệ thống thường trả về một endpoint gỡ lỗi, chẳng hạn cổng hoặc địa chỉ WebSocket, có thể chuyển cho driver như Selenium hoặc Puppeteer.
Lớp giữa là trang: mở địa chỉ, đọc DOM hoặc cây trợ năng, chuyển tab và chụp ảnh màn hình.
Lớp dưới cùng là thao tác: nhấp, nhập, cuộn, chờ một điều kiện được thỏa mãn và xử lý cửa sổ bật lên.
Thay đổi quan trọng không nằm ở số lượng thao tác, mà ở việc môi trường chuyển từ một đoạn mã bạn buộc phải tự viết thành tài nguyên mà Agent có thể tự chọn và sử dụng. Bạn chỉ cần nêu rõ mục tiêu; Agent có thể quyết định tạo môi trường mới hay dùng lại môi trường hiện có và gọi công cụ theo thứ tự nào. Điều này đặc biệt rõ khi chạy nhiều môi trường song song: việc điều phối nằm trong prompt thay vì bị mã hóa cứng trong script.
Những phần hiện vẫn chưa được giải quyết
Giao thức giải quyết kết nối, không giải quyết tính đúng đắn. Vẫn còn một số điểm dễ bị bỏ qua.
Chất lượng mô tả công cụ quyết định kết quả gọi. Nếu tham số sai hoặc chọn nhầm công cụ, giao thức không thể cứu được. Khi số lượng công cụ tăng, chính phần mô tả cũng chiếm dung lượng ngữ cảnh, vì vậy phải cân bằng giữa số lượng và độ chi tiết. Nếu quá thô, mô hình không biết một công cụ làm được bao nhiêu việc; nếu quá nhỏ, ngữ cảnh sẽ đầy trước.
Quyền hạn và kiểm toán vẫn ở giai đoạn đầu. Nhiều Server chạy cục bộ trên một máy, vừa khởi động đã có quyền khá lớn nhưng thiếu phân quyền chi tiết và nhật ký cuộc gọi. Với chế độ từ xa, trước hết phải trả lời ai được kết nối và được thấy những gì.
Tính ổn định của trang cũng chưa biến mất. Không tìm thấy phần tử, thứ tự tải không ổn định, trạng thái đăng nhập hết hạn hay CAPTCHA vẫn đòi hỏi chờ, thử lại và cơ chế dự phòng. Giao thức chỉ thống nhất điểm vào.
Mức độ trưởng thành của hệ sinh thái cũng không đồng đều. Các Server khác nhau không hoàn toàn thống nhất về loại tài nguyên hỗ trợ, cấu trúc trả về và mã lỗi. Khi ghép nhiều Server để làm một nhiệm vụ, logic điều phối thường vẫn phải tự viết. Bản thân giao thức cũng đang tiếp tục phát triển nên cần chú ý khác biệt hành vi giữa các phiên bản.
Còn một ranh giới cần phân biệt rõ: giao thức quản lý cách mô hình gọi công cụ, chứ không quyết định nhiệm vụ có hợp lệ hay tuân thủ quy định hay không. Việc thu thập dữ liệu có được cho phép không, mục đích sử dụng tài khoản có chính đáng không, có vi phạm quy tắc nền tảng không đều là các đánh giá độc lập, không liên quan đến việc đường kết nối có trơn tru hay không.
Trong tình huống nhiều môi trường, mức độ cách ly giữa các môi trường và việc lối ra mạng, múi giờ, ngôn ngữ có được cấu hình đồng bộ hay không thường ảnh hưởng kết quả nhiều hơn cách tích hợp. Ở lớp cách ly môi trường, PurpleMark cung cấp các giao diện tạo, khởi động và cấu hình mạng cho môi trường mà công cụ AI có thể gọi, để một client duy nhất có thể điều phối.
Nội dung này chỉ nhằm giải thích nguyên lý kỹ thuật. Hãy sử dụng các giao thức và công cụ liên quan trong khuôn khổ pháp luật và quy định hiện hành.
