Kiến trúc là Quyết định Sản phẩm & Giao thức Tương tác
Vì sao kiến trúc kỹ thuật là quyết định sản phẩm, tách biệt Inference API khỏi Interoperability Protocols, và bức tranh tổng thể các chuẩn giao tiếp.
Kiến trúc là một quyết định sản phẩm
Ngày 1 đã khẳng định rằng AI agent không chỉ đơn thuần là một mô hình (model). Nó là một model nằm bên trong harness-hệ thống phụ trợ cung cấp context, tool, state và feedback. Sang Ngày 2, câu hỏi đặt ra là: điều gì sẽ xảy ra khi harness cần vươn ra ngoài phạm vi của chính nó?
Câu trả lời đầy cám dỗ thường là kết nối tất cả mọi thứ: cấp cho agent mọi API, thêm hàng loạt specialist agent, rồi để nó tự sinh ra bất kỳ giao diện nào nó cần. Cách này tạo ra một bản demo vô cùng ấn tượng, nhưng đồng thời cũng tạo ra một sản phẩm thiếu rõ ràng về trách nhiệm (unclear ownership), có các ranh giới phân quyền không thể nhìn thấy, và tiềm ẩn quá nhiều điểm rủi ro có thể phát sinh lỗi.
Các giao thức (protocol) tỏ ra hữu ích vì chúng giúp tách biệt các mối bận tâm (concerns) này. Bản thân protocol không tự tạo ra giá trị cho người dùng. Chúng chỉ định nghĩa cách một capability được khám phá (discovered), khởi chạy (invoked), quản trị (governed) và quan sát (observed). Đối với một Product Manager, quyết định về mặt kiến trúc bắt đầu từ chính mối quan hệ mà sản phẩm cần thiết lập:
Hãy cùng sử dụng một ví dụ thực tế xuyên suốt Ngày 2: vendor-onboarding agent-một agent hỗ trợ PM so sánh các nhà cung cấp dịch vụ phân tích (analytics provider) và khởi chạy một chương trình dùng thử (pilot) đã qua phê duyệt. Agent này phải truy xuất các yêu cầu nội bộ cùng thông tin thực tế về vendor, nhờ một compliance specialist kiểm tra quy trình xử lý dữ liệu, trình bày bảng so sánh cho PM chỉnh sửa và-chỉ khi người dùng quyết định lựa chọn vendor-mới chuẩn bị một giao dịch thương mại có giới hạn. Người dùng chỉ nhìn thấy một quy trình duy nhất, nhưng mỗi bước chuyển giao lại mang một loại trách nhiệm hoàn toàn khác nhau.
Việc tương tác với model có thể chạy qua OpenResponses hoặc Interactions API. MCP cho phép agent sử dụng một capability truy xuất dữ liệu có giới hạn (bounded retrieval). A2A cho phép giao việc kiểm tra tuân thủ (compliance review) mở cho một participant-bên có thể đặt câu hỏi làm rõ. A2UI mô tả bảng so sánh dưới dạng khai báo mà không cần gửi bất kỳ code UI có thể thực thi nào. UCP trao đổi dữ liệu danh mục và đơn hàng với phía merchant, trong khi AP2 xác minh quyền thanh toán của người dùng. Bảng dưới đây tóm tắt sơ đồ các mối quan hệ đó.
| Nhu cầu sản phẩm | Interface | Nội dung được chuẩn hóa |
|---|---|---|
| Sử dụng một capability bên ngoài | MCP | Tool, resource, prompt và thông tin kết nối |
| Giao việc cho một specialist | A2A | Identity của agent, task state và cách thức cộng tác |
| Trình bày kết quả có thể tương tác | A2UI | Intent giao diện (UI intent) dạng khai báo do host render |
| Thực hiện giao dịch thương mại | UCP và AP2 | Tương tác với merchant, phân quyền (authorization) và payment intent |
Sơ đồ protocol bên dưới sẽ dễ hiểu nhất nếu đọc từ tâm ra ngoài. Agent vẫn đóng vai trò chịu trách nhiệm hiểu mục tiêu của người dùng. Mỗi protocol lại xử lý một ranh giới (boundary) khác nhau xoay quanh mục tiêu đó. MCP vươn tới các tool, A2A vươn tới các agent khác, A2UI tiếp cận người dùng thông qua một trusted renderer, còn các protocol thương mại sẽ quản trị giao dịch.
Bản đồ Protocol quanh một Agent
Hãy đọc từ tâm ra ngoài. Agent chịu trách nhiệm hiểu mục tiêu người dùng; mỗi protocol quản trị một ranh giới quanh mục tiêu đó.
Chọn một protocol để xem ranh giới mà nó quản trị
MCP
• Dùng một capability bên ngoàiTool, resource, prompt và chi tiết kết nối cho một lệnh gọi có ranh giới rõ ràng.
Ai sở hữu server này, dữ liệu nào rời khỏi ranh giới, và một scope bị từ chối trông ra sao?
Sự phân biệt này giúp ngăn chặn một sai lầm phổ biến trên roadmap: coi mọi integration đều là cùng một loại công việc. Tra cứu database, nhờ một compliance agent từ xa kiểm tra tuân thủ, sinh bảng so sánh và thực hiện thanh toán là bốn cam kết sản phẩm hoàn toàn khác nhau. Mỗi cam kết đòi hỏi những quyết định riêng biệt về lifecycle, phân quyền (permission), phương án dự phòng (fallback) và cách thức đánh giá (evaluation).