Sau thanh toán, chiến trường tiếp theo của nền kinh tế tác nhân: Thị trường nhiệm vụ

Tác giả: Delphi

Biên dịch: AididiaoJP, Foresight News

Thảo luận về thương mại điện tử tác nhân đã diễn ra hai năm, khâu thanh toán là nơi đầu tiên được triển khai. Stripe cho phép tác nhân thanh toán cho người bán, x402 của Coinbase cung cấp kênh thanh toán bằng stablecoin, việc mua dữ liệu và dịch vụ suy luận theo lượt đã hoạt động trơn tru. Nhưng khi nhiệm vụ vượt ra ngoài phạm vi "gọi một lần API", vấn đề sẽ thay đổi: tác nhân không thể hoàn thành độc lập, cần thuê ngoài một phần công đoạn và xác nhận đối phương thực sự đã hoàn thành công việc đã thỏa thuận.

Bài viết này của Delphi tập trung chính vào khâu đó. Thị trường nhiệm vụ không phải là một giao thức thanh toán khác, mà là nơi để tác nhân thuê ngoài những phần việc không thể tự hoàn thành: trước tiên xác định rõ sản phẩm bàn giao, sau đó mới bắt đầu thực hiện, chỉ giải ngân khi kết quả được chấp nhận. Nếu việc bàn giao đáng tin cậy, nhiệm vụ có thể tiếp tục tiến triển mà không cần kéo người dùng quay lại làm quản lý dự án, đối chiếu từng khâu với nhà cung cấp.

Mua đầu vào và mua kết quả không phải là một

Khi chủ nhà sàng lọc người thuê, tác nhân có thể lấy báo cáo tín dụng và hồ sơ trục xuất từ các nhà cung cấp dịch vụ có sẵn. Đối phương trả về tài liệu chuẩn, chủ nhà dựa vào đó để phán đoán. Lúc này mua là đầu vào cho quyết định, điểm kết thúc của nhiệm vụ vẫn nằm trong tay chủ nhà.

Khiếu nại thuế bất động sản thì khác. Tác nhân có thể so sánh các giao dịch xung quanh, phát hiện mức định giá có thể quá cao, nhưng phát hiện này không tự động sửa đổi hóa đơn thuế. Để thực sự tiến hành, thường cần tìm người quen thuộc quy trình trong quận để nộp tài liệu và ra tòa. Thị trường nhiệm vụ cần giúp tác nhân tìm được người này, đồng thời xác định trước cách thức làm việc và điều kiện thanh toán.

Trường hợp trước gần với mô hình trả phí theo lượt hiện tại: giá rõ ràng, sản phẩm bàn giao được chuẩn hóa, việc nghiệm thu gần như tự động. Trường hợp sau mua là một việc đã được hoàn thành. Nộp tài liệu không đồng nghĩa với hồ sơ đã sẵn sàng, biên nhận cũng không đồng nghĩa với đạt yêu cầu. Điều kiện thanh toán phải gắn với "kết quả có thể nghiệm thu", chứ không phải "đối phương tuyên bố đã làm".

Đây cũng là ranh giới giữa thị trường nhiệm vụ và thị trường API (giao diện lập trình ứng dụng) thông thường: thị trường API bán lượt gọi; thị trường nhiệm vụ bán đơn vị công việc đã được xác nhận hoàn thành.

Nhiệm vụ không được định nghĩa rõ ràng, thị trường khó vận hành

Nhiệm vụ có thể vào thị trường nhiệm vụ cần được định nghĩa trước đến mức cả hai bên đều rõ tiền gắn với kết quả nào. Chuyên gia hoàn toàn có thể nộp một bộ tài liệu khiếu nại chất lượng rất kém, kèm theo một biên nhận. Nếu bên mua trả tiền cho "một bộ tài liệu đạt yêu cầu", thì phải có người xem xét tài liệu trước khi giải ngân.

Ai sẽ xem xét, mỗi bên có thể phản đối kết quả xem xét như thế nào, tốt nhất nên ghi trước vào đơn hàng. Như vậy, bên mua không sợ nhận phải sản phẩm kém chất lượng, bên nhận việc cũng không sợ bị từ chối thanh toán vô lý. Thiếu lớp này, thị trường sẽ trượt theo hai hướng xấu: hoặc bên mua tùy tiện từ chối thanh toán, nguồn cung chuyên nghiệp không muốn tham gia; hoặc chỉ cần nộp kết quả bề ngoài là có tiền, lần sau bên mua không dám đăng việc.

Nhiệm vụ quá nhỏ cũng không đáng. Nếu chi phí xem xét và xử lý tranh chấp cao hơn chi phí tiết kiệm được từ thuê ngoài, người ta sẽ quay lại tự làm hoặc tiếp tục chỉ dùng giao diện chuẩn hóa. Do đó, giai đoạn đầu có khả năng xuất hiện ở những nhiệm vụ có ranh giới rõ ràng, có thể lặp lại, có căn cứ nghiệm thu, chứ không phải những ủy thác mơ hồ một lần.

Doanh nghiệp sẽ là bên mua ban đầu phù hợp hơn. Họ vốn đã chia nhỏ nhiệm vụ giữa nhiều nhà cung cấp, nội bộ đã có quy trình và tiêu chuẩn đối chiếu. Tác nhân có thể chuẩn bị nhiệm vụ trong công ty, sau đó đưa ra những khâu bắt buộc phải thuê ngoài, kết quả nhận về còn có thể đối chiếu với quy trình hiện có. Nếu nhiệm vụ lặp lại nhiều lần, bên nhận việc cũng có thể tích lũy hồ sơ hoàn thành cho một loại nhiệm vụ nào đó. Một khi danh tiếng có thể tích lũy, lần ghép nối tiếp theo không cần xây dựng lòng tin từ đầu.

Người dùng cá nhân không phải không dùng được, nhưng giai đoạn đầu giống như bản mẫu hơn. Doanh nghiệp có ngân sách, có mua lại, có thói quen nghiệm thu nội bộ, gần hơn với mật độ đơn hàng cần thiết để khởi động nguội thị trường.

Thanh toán chỉ giải quyết việc trả tiền, thuê người vẫn thiếu nghiệm thu

Giữa việc chuyển tiền đi và việc thuê một nhiệm vụ, còn có ký quỹ, bàn giao, nghiệm thu, phản đối. Stripe và x402 bao phủ nửa đầu. Tác nhân vẫn cần tìm người nộp đơn khiếu nại, đại diện chủ sở hữu. Không có nghiệm thu, thanh toán càng thuận tiện, đơn hàng sai càng có thể đi nhanh hơn.

Sản phẩm hiện có đã được xây dựng theo cấu trúc này.

TaskMarket (thị trường nhiệm vụ) của Daydreams do bên mua đăng việc, tác nhân nhận việc. Bên mua trước tiên nạp tiền vào, có thể để người lao động trực tiếp nhận, cũng có thể xem phương án trước rồi mới chọn người. Tiền được giữ trong ký quỹ, chỉ giải ngân sau khi sản phẩm nộp lên được chấp nhận.

Agent Commerce Protocol của Virtuals do tác nhân ủy thác và tác nhân nhận việc thỏa thuận nhiệm vụ, tiền vào ký quỹ, giải ngân sau khi bàn giao và được phê duyệt. Còn có thể thêm người đánh giá bên ngoài để kiểm tra kết quả có phù hợp với thỏa thuận trước hay không. Phía NEAR (nền tảng blockchain) cũng đang tích hợp nhiệm vụ, ngân sách, đấu thầu và xác minh thành một quy trình, hướng đi cũng là "định giá cho nhiệm vụ đã hoàn thành", chứ không chỉ định giá cho một lần gọi.

Một số bên có lộ trình không hoàn toàn giống nhau, nhưng khung xương gần giống: đăng việc, ghép nối, ký quỹ, nộp bài, nghiệm thu, giải ngân. Thiếu nghiệm thu, ký quỹ chỉ là chuyển khoản trì hoãn; có nghiệm thu, ký quỹ mới trở thành ràng buộc đối với kết quả.

Có người viết phiếu nghiệm thu chi tiết hơn: cần ghi rõ nội dung ủy thác, bên nhận việc, giá, người xác minh, sản phẩm bàn giao, cửa sổ phản đối, trạng thái hoàn tiền. Chứng từ càng đầy đủ, tác nhân mới có thể bàn giao cho nhau, mà không cần biến người dùng trở lại thành người điều phối.

Thêm một bước, sai sót sẽ phóng đại

Thị trường nhiệm vụ được đề xuất không chỉ vì thuê ngoài nghe có vẻ cao cấp, mà còn vì quy trình nhiều bước sẽ phóng đại sai số. Nhiệm vụ mười bước, mỗi bước đúng 95%, xác suất đi hết không sai sót chỉ còn khoảng sáu phần mười. Mỗi lần bàn giao không có nghiệm thu, sai sót phía trước sẽ bị đưa vào khâu tiếp theo.

Do đó, thị trường cần đặt điểm kiểm tra ở chỗ bàn giao: khâu này thông qua, mới mua khâu tiếp theo. Sai sót dừng ở bước đó, chứ không lăn đến cuối mới phát hiện cả đơn hàng bị hủy. Đặc biệt là với tác nhân. Nó không giống nhân viên công ty, có vấn đề có thể họp để truy trách nhiệm; nó cần điều kiện nghiệm thu và quy tắc giải ngân được viết trước.

Điều này cũng giải thích vì sao giao dịch tác nhân hiện tại phần lớn vẫn dừng ở các dịch vụ crypto-native và đơn giản: nhiệm vụ ngắn, kết quả dễ xác minh, ít tranh chấp. Điều thực sự tạo khác biệt là xâu chuỗi nhiều nhà cung cấp vào quy trình làm việc dài hơn, và kiểm soát ở từng bước.

Hiện tại thấy là khung xương, chưa phải quy mô

Việc thị trường nhiệm vụ cần làm rất cụ thể: để tác nhân thuê ngoài một phần nhiệm vụ, chỉ trả tiền sau khi kết quả được công nhận, từ đó thực sự hoàn thành nhiều nhiệm vụ hơn. Lớp thanh toán đã có. Thứ còn thiếu là đơn vị công việc hoàn thành có thể xác minh, nghiệm thu với chi phí chấp nhận được, và mật độ đơn hàng lặp lại đủ dày.

Quy trình nội bộ công ty mở rộng ra ngoài sẽ là nhu cầu tử tế đầu tiên. Ủy thác phức tạp phía cá nhân cần chờ chi phí nghiệm thu và xử lý tranh chấp giảm xuống trước. Trước đó, điều đáng quan tâm không phải là một giao thức thanh toán khác, mà là ba việc có thể xuất hiện đồng thời hay không: nhiệm vụ có thể được viết thành chứng từ có thể nghiệm thu, ký quỹ có thể giữ tiền trước khi được phê duyệt, bên nhận việc có hồ sơ hoàn thành có thể tích lũy.

Ba điều này đầy đủ, tác nhân mới có cơ hội làm xong nhiệm vụ, thay vì làm được một nửa rồi gọi người dùng quay lại tiếp tục làm quản lý dự án.