Cloudflare thu phí công cụ MCP qua Monetization Gateway và giao thức x402, nhưng quyền kiểm soát chi tiêu vẫn thuộc về hệ thống vận hành tác tử. Hệ thống đó cần đặt hạn mức ngoài mô hình và giữ ngân sách cho từng tác vụ. Nó cũng phải xử lý giá biến động, ngăn thanh toán trùng khi thử lại và nối mỗi khoản phí với đúng lệnh gọi.
Cloudflare đã mở bản thử nghiệm kín của Monetization Gateway vào hôm thứ Tư. Bản thử nghiệm cho phép chủ tên miền thu tiền khi tác tử AI truy cập giao diện lập trình ứng dụng, công cụ MCP, trang web và tập dữ liệu. Theo bài viết gốc của The New Stack, cổng đưa thông tin ủy quyền thanh toán vào yêu cầu HTTP bằng giao thức x402. Tài nguyên chỉ được cung cấp sau khi khoản tiền được quyết toán bằng USDC trên chuỗi khối Base.
Bản thử nghiệm hiện chỉ dành cho người bán và người mua đủ điều kiện tại Mỹ. AI Gateway của Cloudflare cũng dùng cơ chế này để tính phí suy luận theo từng yêu cầu. Mỗi lệnh gọi có phí tạo thêm một quyết định trong vòng thực thi. Trước khi tiếp tục, hệ thống phải xác định tác tử có được phép tiêu tiền hay không.
Quyền chi tiền phải nằm ngoài mô hình
Mô hình có thể chọn công cụ, nhưng hạn mức và quyền thanh toán phải do một lớp kiểm soát độc lập thực thi. Cách tách biệt này ngăn tác tử vượt quá ngân sách ngay cả khi mô hình chọn một công cụ có phí hoặc thực hiện một quy trình dài.
Cloudflare dự kiến cung cấp Ví ảo, cho phép chủ Ví tài khoản thiết lập hạn mức, danh sách cho phép và giá trị giao dịch tối đa. Các giới hạn này vẫn có hiệu lực bất kể tác tử chọn công cụ nào.
Ở phía máy khách, trình bao withX402Client trong bộ công cụ phát triển Agents nhận một hàm xác nhận. Hàm này có thể xem yêu cầu thanh toán trước khi tiền được chuyển. Nếu nhà phát triển truyền giá trị rỗng, tác tử được phép thanh toán tự động. Đây cũng là điểm nhóm vận hành có thể yêu cầu người dùng phê duyệt một lệnh gọi có phí.
Việc tách quyền chi tiền khỏi mô hình đặc biệt quan trọng khi tác tử được giao quy trình dài. Bài toán này gần với câu hỏi AI nên được trao bao nhiêu quyền: khả năng hành động phải đi cùng giới hạn do hệ thống thực thi, thay vì chỉ dựa vào lời nhắc.
Giới hạn từng giao dịch chưa đủ để giữ ngân sách
Giới hạn cho mỗi lệnh gọi không kiểm soát được tổng chi phí của một tác vụ gồm nhiều bước. Hệ thống cần đồng thời kiểm tra mức tối đa của từng giao dịch và ngân sách còn lại của tác vụ trước khi cho phép thanh toán.
Theo The New Stack, một tác tử bị giới hạn ở mức 0,10 USD cho mỗi lệnh gọi vẫn có thể tiêu 10 USD trong một tác vụ dài. Khoản chi đó không vi phạm giới hạn cho từng lệnh gọi. Hạn mức ví có thể chặn tổng chi tiêu, nhưng không cho biết một tác vụ riêng lẻ đã dùng bao nhiêu nếu nhà phát triển không tạo Ví ảo riêng cho từng lần chạy.
Một số nền tảng đã đưa kiểm soát này vào cổng trung gian. TrueForge của TrueFoundry chuyển các lệnh gọi mô hình và tương tác MCP qua AI Gateway, nơi nhóm vận hành có thể áp ngân sách và giới hạn tần suất trên nhiều tác tử.
Hệ thống vì thế cần ít nhất hai lớp giới hạn:
- Mức tối đa được phép thanh toán cho từng giao dịch.
- Ngân sách còn lại của tác vụ đang thực thi.
Việc theo dõi chi phí theo từng tác vụ càng quan trọng khi lượng sử dụng tập trung vào một nhóm nhỏ, như trường hợp 1% kỹ sư dùng 40% token.
Giá biến động làm phép tính ngân sách phức tạp hơn
Với cơ chế giá biến động, tác tử có thể biết mức trần phải trả nhưng chưa biết chi phí cuối cùng. Cách kiểm soát thận trọng là tạm trừ toàn bộ mức trần khỏi ngân sách, sau đó hoàn lại phần chênh lệch khi giao dịch được quyết toán.
Cloudflare hỗ trợ hai cơ chế của x402. Cơ chế exact áp dụng giá cố định. Cơ chế upto cho phép máy khách ủy quyền một mức trần trước khi máy chủ của người bán báo khoản phí thực tế. Theo The New Stack, khách hàng ra mắt API2PDF dùng upto vì mỗi tác vụ tạo tệp PDF tiêu thụ lượng tính toán và băng thông khác nhau.
Theo tài liệu cấu hình Monetization Gateway của Cloudflare, cổng hiện hỗ trợ mức giá từ 0,001 USD đến 100 USD. Trong lúc chờ quyết toán, hệ thống có thể coi mỗi lệnh gọi đã tiêu toàn bộ mức trần được ủy quyền. Khi khoản phí thực tế được trả về, phần chênh lệch mới được cộng lại vào ngân sách còn lại của tác vụ.
Khi thử lại có thể trở thành mua lại
Một lần thử lại không an toàn có thể khiến tác tử trả tiền hai lần cho cùng một tài nguyên. Khung tác tử cần kiểm tra trạng thái thanh toán và lưu hồ sơ giao dịch trước khi gửi lại yêu cầu có phí.
Một yêu cầu có phí có thể thất bại ở ba thời điểm:
- Trước khi giao dịch được ủy quyền.
- Trong lúc giao dịch được quyết toán.
- Sau khi tiền đã chuyển nhưng phản hồi chưa tới máy khách.
Trường hợp cuối có rủi ro cao nhất vì máy khách có thể hiểu nhầm rằng giao dịch chưa xảy ra. Cloudflare xử lý quy trình thanh toán trong cổng, kể cả những giao dịch thất bại cần thử lại. Máy khách x402 kiểm tra trạng thái HTTP và phản hồi trước khi gửi tiếp, nhưng khung tác tử vẫn phải lưu hồ sơ riêng cho từng khoản thanh toán.
Hồ sơ cần phân biệt giao dịch thất bại, giao dịch đã chuyển tiền nhưng mất phản hồi và lệnh gọi tiếp theo thực sự là một giao dịch mới. Đây là một phần của hạ tầng vận hành tác tử, tương tự các lớp điều phối và thực thi trong hạ tầng AI tác tử trên Kubernetes.
Giá trở thành tiêu chí chọn công cụ
Khi nhiều công cụ có thể hoàn thành cùng một nhiệm vụ, máy khách phải cân nhắc giá cùng độ trễ, độ tin cậy và chất lượng đầu ra. Bộ công cụ của Cloudflare hỗ trợ thanh toán, nhưng không quyết định dịch vụ nào đáng mua.
Bộ công cụ phát triển Agents của Cloudflare cho phép máy chủ MCP kết hợp công cụ miễn phí và có phí thông qua paidTool. Nhà phát triển đặt giá bằng USD cho mỗi lệnh gọi. Nếu máy khách chọn công cụ có phí nhưng chưa thanh toán, máy chủ trả mã trạng thái 402. Máy khách sau đó có thể thử lại qua x402 kèm bằng chứng thanh toán.
Với giá biến động, hệ thống có thể chỉ biết mức trần thay vì khoản phí cuối cùng. Tác tử có thể chọn dịch vụ rẻ hơn khi dịch vụ đó đáp ứng nhiệm vụ, hoặc trả nhiều hơn nếu yêu cầu công việc cho phép và ngân sách vẫn còn.
Cloudflare còn dự kiến giúp tác tử tìm thấy dịch vụ của người bán trong lúc quy trình đang chạy. Khi đó, hệ thống thực thi phải xác định người bán nào được chấp thuận và tác tử được phép chi bao nhiêu.
Nội dung chi tiêu phải được truy vết theo từng lệnh gọi
Mỗi khoản thanh toán cần được nối với mô hình, công cụ, tác vụ và lần thử đã tạo ra chi phí. Nếu chỉ theo dõi số dư ví hoặc phản hồi cuối cùng, bên mua không thể phân biệt hai lần thử với hai lần mua.
Một lệnh gọi công cụ thành công không cho biết tác tử đã tốn bao nhiêu trên đường đi, nhất là khi có nhiều lần thử lại. Phản hồi cuối cùng cũng có thể che khuất chuỗi lệnh gọi qua nhiều tác tử. Khi thanh toán được thêm vào, mỗi lệnh gọi cần mang theo lịch sử giao dịch.
Nhật ký phía người mua
Cloudflare cho biết họ dự kiến cung cấp nhật ký giao dịch Monetization Gateway, nhưng các nhật ký này hướng đến người bán. Bên mua vẫn cần hệ thống đo lường riêng để nối từng khoản thanh toán với mô hình, công cụ và tác vụ đã tạo ra chi phí đó.
Theo ví dụ của The New Stack, số dư ví có thể cho biết tác tử đã tiêu 50 USD. Tuy nhiên, số dư không cho biết một tác vụ đã dùng 3,80 USD qua 27 lệnh gọi. Nó cũng không chỉ ra một lần thử lại đã thanh toán hai lần cho cùng tài nguyên. AI Gateway của Cloudflare hiện nhận thanh toán x402 cho suy luận. Vì vậy, lệnh gọi mô hình và công cụ có phí có thể cùng rút tiền từ một ví.
Điểm kiểm soát nằm ở khả năng gắn từng khoản tiền với đúng tác vụ, áp ngân sách trước khi gọi và xác định trạng thái giao dịch trước khi thử lại. Việc cho phép tác tử thanh toán chỉ là bước đầu; giới hạn và dữ liệu truy vết mới quyết định hệ thống có kiểm soát được chi tiêu hay không.
Hãy tiếp tục theo dõi Sine để cập nhật cách các nền tảng AI tác tử kiểm soát quyền hạn, chi phí và rủi ro vận hành.
