Hầu hết các ứng dụng AI dừng lại quá sớm trong cuộc đối thoại. Chúng dừng lại vào khoảnh khắc "ứng dụng được tạo ra".

Điều này là hợp lý trong làn sóng đầu tiên. Một năm trước, việc nhìn một đoạn từ khóa biến thành một giao diện có thể chạy đã là điểm nhấn của toàn bộ sự kiện. Ngày nay, các nhà phát triển đã hiểu rằng ngôn ngữ tự nhiên có thể tạo ra phần mềm. Vấn đề khó khăn hơn là: điều gì sẽ xảy ra với ứng dụng được tạo ra sau đó.

Nó có thể chạy cho người dùng thực sự không?
Nó có thể thực hiện nhiệm vụ một cách an toàn không?
Nó có thể đo lường chi phí, tính phí theo giá trị và phát hành chứng từ không?
Các nhà phát triển có thể kiếm được doanh thu từ đó không?
Người dùng có thể phát hiện ra nó mà không cần mù quáng tin tưởng vào một danh sách ứng dụng ngẫu nhiên không?

Tại X-Agent, chúng tôi thường quay lại ranh giới này: việc tạo ra là cần thiết, nhưng chỉ dựa vào việc tạo ra không thể biến một ứng dụng Agent thành một sản phẩm thực sự. Lớp thiếu hụt đó là mọi thứ xảy ra "sau khi hoàn thành xây dựng".

Tóm tắt

Vấn đề cấp nền tảng tiếp theo không phải là tạo ra nhiều ứng dụng AI hơn, mà là biến các ứng dụng Agent đã được tạo ra thành sản phẩm có thể thực thi, phân phối và có lợi nhuận. Đường xây dựng (Build Path) và đường chạy (Runtime Path) nên được coi là hai hệ thống khác nhau. Đường đầu tiên tạo ra ứng dụng, đường sau cho phép người dùng thực sự thao tác nó.

Việc thanh toán cho ứng dụng Agent nên được liên kết với việc thực hiện chính nó - bao gồm ngân sách, đo lường, xác nhận, thanh toán, chứng từ và quy trình xử lý tranh chấp. Cửa hàng Agent và sự phát triển nên bắt đầu từ việc phân phối được chọn lọc và tín hiệu sử dụng thực tế, chứ không phải một danh sách thị trường trống rỗng.

Đường xây dựng chỉ là một nửa của sản phẩm

Đường xây dựng là phần mà hầu hết mọi người đã nhận ra. Người sáng tạo → Studio → Harness (khung thực hiện) → Sandbox → Ứng dụng Agent đã triển khai. Người sáng tạo mô tả những gì họ muốn, hệ thống giải thích ý định này, tạo ra một ứng dụng, xem trước trong Sandbox, rồi tiến tới triển khai.

Điều này đã rất có giá trị. Nó đã loại bỏ những trở ngại trong quá khứ cản trở những người không phải kỹ sư và làm chậm lại công việc xây dựng của kỹ sư: cấu trúc kho, cấu hình môi trường, vòng lặp xem trước, chi tiết triển khai, và xây dựng giàn giáo ứng dụng trong vòng đầu tiên. Nhưng nếu chúng ta dừng lại ở đây, chúng ta về cơ bản chỉ có một cách "tạo ra nguồn cung tốt hơn". Nhiều nhà phát triển có thể sản xuất nhiều ứng dụng hơn, nhiều ý tưởng có thể đi đến giai đoạn trình diễn hơn, nhiều nguyên mẫu có thể được chia sẻ hơn, điều này không giải quyết được vấn đề "sản phẩm". Một ứng dụng được tạo ra vẫn cần người dùng, nhiệm vụ, trạng thái, quyền, định giá, niềm tin và phân phối.

Đó chính là lý do chúng tôi phân biệt giữa đường xây dựng và đường chạy.

Thời gian chạy là nơi ứng dụng thực sự trở nên hữu ích

Đường chạy bắt đầu sau khi ứng dụng được triển khai hoàn tất. Người dùng → Ứng dụng Agent → Đối thoại Agent → Công cụ/trạng thái/wallet/thanh toán → Kết quả. Đường này phục vụ cho người dùng cuối, chứ không phải người sáng tạo. Một ứng dụng Agent đã triển khai không nên chỉ là một trang tĩnh dán nhãn AI. Người dùng nên có thể mở ứng dụng này, thể hiện ý định, hỏi chi tiết, kích hoạt quy trình làm việc, kiểm tra trạng thái, gọi công cụ và nhận kết quả nhiệm vụ.

Điều này nghe có vẻ hiển nhiên, cho đến khi bạn thực sự bắt tay vào xây dựng nó.

Agent trong quá trình xây dựng và Agent trong thời gian chạy là hai công việc khác nhau. Agent trong quá trình xây dựng chịu trách nhiệm hỗ trợ tạo ra ứng dụng; Agent trong thời gian chạy chịu trách nhiệm hỗ trợ người dùng thao tác ứng dụng. Nếu nhét hai vai trò này vào cùng một đoạn từ khóa dài dòng, hệ thống sẽ trở nên khó suy luận, khó đảm bảo an toàn và cũng khó đạt được lợi nhuận.

Thời gian chạy cần thiết lập một "hợp đồng" riêng với người dùng. Nó cần biết ứng dụng này có thể đọc và ghi những trạng thái nào; cần biết có những công cụ nào có sẵn; cần biết những thao tác nào là rẻ và có thể đảo ngược, những thao tác nào đắt, liên quan đến hệ thống bên ngoài hoặc có rủi ro; cần biết khi nào nên yêu cầu xác nhận; và cần để lại dấu vết kiểm toán.

Đó là sự khác biệt giữa "mô hình đưa ra một câu trả lời" và "ứng dụng hoàn thành một nhiệm vụ".

Một ví dụ cụ thể: phân tích dữ liệu không chỉ là một từ khóa

Lấy một ứng dụng Agent đơn giản làm ví dụ: phân tích dữ liệu (leads) sau khi kết thúc một sự kiện hoặc chiến dịch tiếp thị. Phiên bản chỉ dựa vào từ khóa rất phổ biến: người dùng dán một danh sách dữ liệu, để mô hình sắp xếp chúng. Mô hình trả về một bảng, có thể kèm theo một điểm số và gợi ý cho cuộc gọi tiếp theo. Hữu ích, nhưng không đầy đủ.

Một ứng dụng Agent thực sự có thể thực thi phải xử lý phần còn lại của quy trình làm việc:

Nhập dữ liệu từ biểu mẫu, bảng tính, CRM hoặc hệ thống sự kiện;
Chuẩn hóa các trường, đồng thời giữ nguyên nguồn gốc ban đầu;
Phân loại bằng mô hình và có thể gọi API tăng cường để bổ sung dữ liệu;
Đánh dấu những cuộc gọi bên ngoài nào sẽ phát sinh chi phí;
Yêu cầu xác nhận trước khi gửi tin nhắn hoặc ghi lại vào CRM;
Ghi lại ai đã phê duyệt thao tác này;
Hiển thị những gì đã bị tính phí, tiêu tốn tài nguyên gì, và kết quả đạt được;
Khi nhiệm vụ thất bại, hỗ trợ hoàn tiền, thử lại hoặc xử lý tranh chấp.

Đó chính là nơi nhiều ứng dụng AI âm thầm sụp đổ. Mô hình có thể gợi ý bước tiếp theo nên làm gì, nhưng lớp sản phẩm phải chịu trách nhiệm về ủy quyền, thực hiện, chi phí và trách nhiệm. Lớp khả năng sản phẩm này chính là điều chúng tôi gọi là "thời gian chạy (Runtime)".

Thực hiện cần một hợp đồng

Chúng tôi không cho rằng "thực hiện Agent" có nghĩa là trao cho mô hình quyền lực vô hạn. Mô hình tốt hơn nên hạn chế hơn: ý định người dùng → mô hình đề xuất giải pháp → xác minh thời gian chạy → công cụ thực hiện → ghi chép kiểm toán. Mô hình chịu trách nhiệm hiểu và lập kế hoạch, thời gian chạy chịu trách nhiệm xác minh và thực hiện.

Đối với bất kỳ thao tác nào có ý nghĩa thực tế, thời gian chạy nên có thể xây dựng một "hợp đồng thực hiện (Execution Contract)". Điều này không nhất thiết phải là một tài liệu có thể nhìn thấy trên giao diện, mà là một đối tượng nội bộ thông báo cho nền tảng "những gì sẽ xảy ra tiếp theo".

Một hợp đồng thực hiện nên có thể trả lời:

Người thanh toán (payer): ai sẽ thanh toán;
Ứng dụng Agent (agentapp): ứng dụng nào đang thực hiện; Người xây dựng (builder): ứng dụng này được ai tạo ra; Nhiệm vụ (task): nhiệm vụ nào đang được thực hiện; Định giá (pricing): nhiệm vụ này được định giá như thế nào; Giới hạn ngân sách (budgetcap): chi phí tối đa cho phép là bao nhiêu;
Xác nhận (confirmation): có cần xác nhận từ người dùng không;
Đo lường (metering): nên đo lường điều gì;
Thanh toán (settlement): thanh toán được thực hiện như thế nào;
Kiểm toán (audit): quá trình thực hiện được theo dõi như thế nào.

Mặt trải nghiệm người dùng có thể giữ đơn giản:

"Nhiệm vụ này có thể tốn tối đa 0,50 đô la, có tiếp tục không?"

Nhưng phía sau không thể đơn giản như vậy. Nó cần biết người dùng có phê duyệt nhiệm vụ này không, đã dự trữ bao nhiêu ngân sách, đã gọi công cụ nào, chi phí thực tế là bao nhiêu, nhiệm vụ có hoàn thành không, và nên phát hành chứng từ gì. Không có hợp đồng này, thanh toán chỉ là một giao diện thanh toán; có nó, thanh toán trở thành một phần của quá trình thực hiện.

Thanh toán không phải là một nút thanh toán

Đối với ứng dụng Agent, thanh toán không nên bị dán cứng vào bên ngoài sản phẩm. Khi một Agent bắt đầu thực sự làm việc, chi phí và giá trị trở thành vấn đề của lớp thời gian chạy. Một số thao tác sẽ tiêu tốn token của mô hình, một số sẽ gọi API trả phí, một số sẽ sử dụng tính toán, lưu trữ, tìm kiếm, dịch vụ dữ liệu, cơ sở hạ tầng triển khai hoặc dịch vụ bên thứ ba, và một số thao tác sẽ trực tiếp tạo ra giá trị thương mại.

Vì vậy, vấn đề thanh toán không chỉ là "thẻ hay ví?"

Mà là:

Ai đã khởi xướng nhiệm vụ này?
Ai đã phê duyệt ngân sách này?
Đã tiêu tốn tài nguyên gì?
Kết quả có hoàn thành không?
Nên thu phí bao nhiêu?
Doanh thu nên được chia như thế nào?
Nếu nhiệm vụ thất bại thì sao?
Có ghi chép nào chứng minh điều gì đã xảy ra không?

Đó là lý do tại sao chúng tôi coi thanh toán của ứng dụng Agent là một "Lớp thương mại Agent (Agent Commerce Layer)". Một máy trạng thái "thực hiện-thương mại" thực dụng có thể như sau: báo giá → ủy quyền → dự trữ → thực hiện → đo lường → thanh toán → phát hành chứng từ → chia sẻ → hoàn tiền/xử lý tranh chấp.

Hầu hết người dùng sẽ không bao giờ cần thấy toàn bộ cơ chế này. Họ chỉ nên thấy một ranh giới chi phí rõ ràng và một kết quả rõ ràng. Ví dụ, một chiến lược định giá điển hình cho một ứng dụng Agent phân tích dữ liệu có thể là:

Hạn mức miễn phí: 10 lần chạy đầu tiên miễn phí;
Đơn vị định giá: theo nhiệm vụ;
Giá nhiệm vụ: 3 đô la cho mỗi lô dữ liệu;
Giới hạn ngân sách: chi phí tối đa cho phép cho mỗi nhiệm vụ;
Chi phí bên ngoài có được chuyển giao trực tiếp không: có/không;
Có cần xác nhận không: cần xác nhận trước khi gửi tin nhắn bên ngoài hoặc ghi vào CRM.

(Các con số này chỉ là ví dụ cho mô hình sản phẩm, không phải là mức giá thực tế hiện tại của X-Agent.)

Nhà phát triển không cần phải tính toán chi phí token ban đầu, người dùng cũng không cần thấy từng chỉ số đo lường nội bộ - nền tảng nên dịch quá trình thực hiện thành định giá mà người dùng có thể hiểu. Ở giai đoạn đầu, một điểm khởi đầu thực dụng rất đơn giản: hạn mức miễn phí + giới hạn sử dụng + SKU nhiệm vụ. Định giá theo mức sử dụng áp dụng cho việc gọi mô hình, gọi API, tìm kiếm, lưu trữ và tính toán; định giá theo nhiệm vụ áp dụng cho các tình huống có hành động rõ ràng, chẳng hạn như phân tích dữ liệu, tạo một trang, triển khai một ứng dụng, tạo một báo cáo, tóm tắt một tập dữ liệu, hoặc chạy một quy trình làm việc được định nghĩa rõ ràng.

Định giá theo phiên hoặc đăng ký, phù hợp cho các công cụ sử dụng thường xuyên. Định giá theo kết quả rất hấp dẫn, nhưng nên để sau - trước khi hầu hết các ứng dụng Agent có thể tính phí theo kết quả thương mại, việc quy trách nhiệm, rủi ro, niềm tin, xác định trách nhiệm và cơ chế xử lý tranh chấp cần phải trở nên đủ mạnh.

Kênh thanh toán trừu tượng, giữ lại hợp đồng thực hiện

Kênh thanh toán không nên định nghĩa trải nghiệm sản phẩm. Người dùng mua kết quả nhiệm vụ, chứ không phải chính thỏa thuận thanh toán. Một nhà phát triển muốn biết:

Ứng dụng Agent này nên định giá như thế nào?
Ai sẽ thanh toán?
Chi phí được kiểm soát như thế nào?
Doanh thu của nhà phát triển khi nào có thể trở thành hiện thực?
Điều gì sẽ xảy ra khi nhiệm vụ thất bại?

Họ không cần quan tâm đến việc kênh cơ sở là thẻ ngân hàng, Apple Pay, điểm nền tảng, hóa đơn, stablecoin, ví, hay một thỏa thuận thanh toán Agent với Agent nào. Ở cấp độ sản phẩm, những khái niệm này nên giữ đơn giản: số dư, điểm, hóa đơn, ví.

Và ở cấp độ cơ sở, nhiều kênh thanh toán có thể đồng tồn tại:

Thẻ ngân hàng hoặc Apple Pay cho người dùng chính;
Điểm nền tảng cho các nhiệm vụ trả phí phổ biến;
Hóa đơn hoặc điểm trả trước cho khách hàng doanh nghiệp;
Kênh ví hoặc stablecoin cho người dùng bản địa Web3;
Ngân sách ủy quyền và thanh toán tự động cho các tình huống Agent với Agent.

Ví dụ về cơ sở hạ tầng mới nổi bao gồm ví thông minh (agentic wallet), giao thức gọi trả phí tương tự x402, thanh toán bằng stablecoin, và hệ thống thanh toán có thể lập trình. Tất cả đều hướng về một hướng: phần mềm cần có kênh thanh toán hoạt động ở cấp độ thời gian chạy. Điều này không có nghĩa là mỗi ứng dụng Agent đều phải sử dụng tiền điện tử, mà là lớp ứng dụng nên trừu tượng hóa kênh thanh toán, đồng thời giữ lại hợp đồng thực hiện đó.

Người dùng khác nhau sẽ cần các kênh thanh toán khác nhau, nhưng hợp đồng bản thân nên giữ nguyên.

Phân phối cũng là một phần của vấn đề thời gian chạy.

Khi việc tạo ra trở nên dễ dàng, phân phối sẽ trở nên khó khăn hơn. Các nhà phát triển AI sẽ tăng lượng cung ứng ứng dụng, nhưng điều này không có nghĩa là người dùng có thể tìm thấy ứng dụng phù hợp, cũng không có nghĩa là các nhà phát triển có thể kiếm lợi từ những gì họ tạo ra. Một hệ sinh thái ứng dụng Agent cần nhiều hơn một danh sách ứng dụng công khai. Nó cần cơ chế phát hiện, cơ chế tin cậy, cơ chế xếp hạng, cơ chế khuyến khích, cũng như phản hồi sử dụng, đồng thời cần hiểu rõ rủi ro thời gian chạy.

Một cửa hàng ứng dụng thông thường sẽ chỉ hỏi:

Đây là ứng dụng gì?
Ai đã phát triển nó?
Tôi có thể cài đặt không?
Đánh giá như thế nào?

Trong khi một cửa hàng Agent cần hỏi nhiều hơn:

Ứng dụng Agent này có thể thực hiện những gì?
Nó cần quyền hạn gì?
Nó có thể gọi những công cụ nào?
Sử dụng nó tốn bao nhiêu tiền?
Nó đã hoàn thành những nhiệm vụ nào?
Có tín hiệu sử dụng nào chứng minh nó thực sự hữu ích không?
Có lịch sử thanh toán hoặc chứng từ nào không?
Uy tín của nhà phát triển này như thế nào?
Ai đang giúp phân phối hoặc làm nội dung tuyển chọn?

Đây là một hướng sản phẩm, không phải nói rằng mỗi thành phần đều đã trưởng thành hôm nay. Quan điểm của chúng tôi là: một cửa hàng Agent không nên bắt đầu từ một thị trường mở trống rỗng, mà nên bắt đầu từ "một lớp cung cấp phân phối và hỗ trợ tăng trưởng cho các ứng dụng Agent chất lượng cao". Điều này có nghĩa là chọn lọc các ứng dụng chất lượng cao, cung cấp cho chúng sự phơi bày ban đầu, hoạt động vận hành, xác minh tình trạng sử dụng thực tế, thưởng cho hành vi phân phối hiệu quả, đồng thời lọc bỏ dữ liệu hoạt động kém chất lượng hoặc giả mạo.

Cơ chế tăng trưởng có thể giúp ích, nhưng điều kiện là nó phải gắn liền với việc sử dụng thực tế. Khuyến khích giới thiệu, hoạt động nhiệm vụ, bảng xếp hạng, khuyến khích hệ sinh thái------ những cơ chế này chỉ có ý nghĩa khi thực sự dẫn dắt người dùng đến các ứng dụng Agent có thể giải quyết vấn đề, nếu không chúng chỉ tạo ra lưu lượng mà không mang lại niềm tin.

Bánh đà của nền kinh tế nhà phát triển

Cơ hội kinh doanh xuất hiện khi việc xây dựng, thời gian chạy, thanh toán và phân phối được kết nối với nhau.

Nhà phát triển tạo ra ứng dụng Agent
→ Người dùng phát hiện và sử dụng nó
→ Thời gian chạy đo lường quá trình thực hiện
→ Người dùng trả tiền cho các nhiệm vụ hữu ích
→ Doanh thu của nhà phát triển trở nên khả thi
→ Người giới thiệu hoặc người tuyển chọn nội dung giúp phân phối
→ Dữ liệu sử dụng thực tế cải thiện xếp hạng và mẫu
→ Nhiều nhà phát triển hơn tham gia

Thanh toán gắn liền với việc sử dụng sản phẩm, phân phối gắn liền với chất lượng thực hiện, khuyến khích nhà phát triển gắn liền với đo lường thời gian chạy. Để cơ chế này thực sự hoạt động, nền tảng cuối cùng cần một sổ cái thực tế. Mỗi lần thực hiện thanh toán có ý nghĩa, đều nên được ghi lại:

Tổng số tiền thu phí (grosscharge) Chi phí mô hình (modelcost)
Chi phí công cụ (toolcost) Chi phí cơ sở hạ tầng (infracost)
Phí thanh toán (paymentfee) Phí nền tảng (platformfee)
Doanh thu nhà phát triển (builderrevenue) Phần thưởng giới thiệu (referrerreward)
Số tiền hoàn lại (refundamount) Trạng thái thanh toán (settlementstatus)

Nếu không có nền tảng này, việc chia sẻ doanh thu, hoàn tiền, lập hóa đơn doanh nghiệp, kiểm soát gian lận, khai báo thuế, chuyển khoản và kiểm toán sẽ trở nên rất yếu ớt. Với nó, ứng dụng Agent có thể trở thành đơn vị kinh tế thực sự: nhà phát triển có thể phát hành một ứng dụng, người dùng có thể trả tiền cho một nhiệm vụ hữu ích, người tuyển chọn nội dung có thể giúp phân phối, nền tảng có thể xếp hạng ứng dụng dựa trên chất lượng thực hiện chứ không chỉ dựa trên nội dung tiếp thị. Đây là sự chuyển đổi từ "tạo ra ứng dụng" sang "thương mại hóa ứng dụng Agent".

Vị trí của X-Agent ở đâu

X-Agent đang được xây dựng như một "lớp ứng dụng Agent".

Nó không có ý định thay thế mô hình cơ bản, không có ý định thay thế nhà cung cấp dịch vụ đám mây, không có ý định thay thế cơ sở hạ tầng ví điện tử, cũng không chỉ là một Agent lập trình khác. Công nghệ mà chúng tôi đang xây dựng đại khái như sau:

Mô hình cơ bản
→ Builder / Harness (Công cụ xây dựng / Khung thực hiện)
→ Thời gian chạy an toàn / Công cụ / Ví điện tử
→ Ứng dụng Agent
→ Cửa hàng / Phân phối / Tăng trưởng

Mô hình cơ bản cung cấp trí thông minh;
Công cụ xây dựng và khung thực hiện chuyển đổi ý định thành ứng dụng;
Thời gian chạy an toàn, công cụ, ví điện tử và hệ thống thanh toán định nghĩa ranh giới thực hiện;
Ứng dụng Agent hướng đến người dùng thực tế;
Cửa hàng, phân phối và hệ thống tăng trưởng giúp các ứng dụng Agent chất lượng cao đạt được quy mô người dùng.

Điều quan trọng không phải là hôm nay mỗi mảnh ghép đều đã hoàn thành, mà là ứng dụng Agent cần trải qua một chu trình đầy đủ như vậy: tạo ra → triển khai → thực hiện → đo lường → thu phí → thanh toán → phân phối → cải tiến lặp lại. Nếu một nền tảng chỉ giúp mọi người tạo ra ứng dụng, thì nó chỉ đang cạnh tranh ở cấp độ "công cụ xây dựng ứng dụng"; nếu nó chỉ cung cấp ví điện tử, thì nó chỉ là cơ sở hạ tầng; nếu nó chỉ vận hành các hoạt động tăng trưởng, thì nó chỉ là một công cụ phân phối.

Trong khi đó, lớp ứng dụng Agent kết nối cả ba yếu tố này lại với nhau.

Từ ứng dụng được tạo ra, đến thể chế thương mại Agent

Giai đoạn đầu tiên của phần mềm AI tập trung vào trí thông minh------có thể trả lời, có thể suy luận, có thể tạo ra, có thể cung cấp hỗ trợ. Giai đoạn tiếp theo, tập trung vào thực hiện------có thể sử dụng công cụ, quản lý trạng thái, hoàn thành nhiệm vụ của ứng dụng Agent. Giai đoạn tiếp theo nữa, tập trung vào kinh tế------có thể được phát hiện, được định giá, được thanh toán, được phân phối, và cải tiến liên tục thông qua việc sử dụng thực tế của ứng dụng Agent.

Các ứng dụng được tạo ra chỉ là điểm khởi đầu của chuỗi chuyển đổi này, chứ không phải là điểm kết thúc của sản phẩm. Tương lai của ứng dụng AI sẽ không được định nghĩa bởi "có thể tạo ra bao nhiêu bản demo", mà sẽ được định nghĩa bởi "có bao nhiêu ứng dụng Agent có thể thực hiện nhiệm vụ thực tế, tiếp cận người dùng thực tế, và duy trì hoạt động kinh tế thực tế".

Đây chính là hướng lớp ứng dụng mà X-Agent đang xây dựng.

Nếu bạn đang xây dựng ứng dụng Agent, cơ sở hạ tầng ví điện tử thông minh, hoặc đang xây dựng kênh phân phối cho phần mềm gốc AI, hãy theo dõi X-Agent để nhận thêm thông tin về thời gian chạy, thương mại hóa và các ghi chú xây dựng liên quan đến phân phối.