Delphi Digital：支付之後，代理經濟的下一個戰場——任務市場

作者：Delphi

編譯：AididiaoJP，Foresight News

代理電商討論已有兩年，支付環節率先落地。Stripe 讓代理能夠向商家付款，Coinbase 的 x402 提供了穩定幣結算通道，按次購買數據與推理服務已經跑通。但任務一旦超出「調用一次介面」，問題便隨之改變：代理無法獨立完成，需將部分環節外包，並確認對方確實完成了約定工作。

Delphi 這篇文章聚焦的正是這一環節。任務市場並非另一個支付協議，而是讓代理將無法完成的部分外包：先明確交付物，再開始執行，成果被接受後才放款。若交接可靠，任務便可繼續推進，無需將用戶拉回充當專案經理，逐段對接供應商。

買輸入與買結果，並非一回事

房東篩選租客時，代理可向現成服務商調取信用記錄與驅逐記錄。對方返回標準材料，房東據此判斷。此時購買的是決策輸入，任務終點仍在房東手中。

房產稅複議則不同。代理可比較周邊成交，發現評估可能偏高，但這一發現不會自動修改稅單。真要推進，通常需找熟悉縣內流程的人遞交材料、出庭。任務市場要幫助代理找到此人，並事先明確工作方式與結算條件。

前者接近當前按次付費：價格清晰，交付物標準化，驗收幾乎自動完成。後者購買的是一樁辦完的事。材料提交不等於案件就緒，回執也不等於合格。付款條件必須掛鉤「可驗收的結果」，而非「對方聲稱做過」。

這也是任務市場與普通 API（應用程式介面）市場的分界：API（應用程式介面）市場出售調用；任務市場出售經確認的完工單元。

任務定義不清，市場難以運轉

能進入任務市場的任務，需先定義到雙方都清楚資金與何種結果掛鉤。專家完全可能提交一份品質很差的複議材料，同時附上一張回執。若買方支付的是「一份合格材料」，就必須有人在放款前審核材料。

由誰審核、任一方如何對審核結果提出異議，最好事先寫入訂單。如此，買方不怕收到劣質交付，接單方也不怕對方無理拒付。缺少這一層，市場會滑向兩個壞方向：要麼買方隨意拒付，專業供給不願進入；要麼提交表面成果即可拿錢，買方下次不敢發單。

任務太小也不划算。審核與爭議處理成本若高於外包節省的成本，人們會改回自己完成，或繼續只用標準化介面。因此，早期更可能出現在邊界清晰、可重複、驗收有據的任務上，而非一次性模糊委託。

企業會是更合適的早期買方。它們本就在多家供應商之間拆分任務，內部已有流程與對照標準。代理可在公司內備好任務，再將必須外包的環節發出去，拿回的結果還能與現有流程核對。若任務反覆出現，接單方也能積累某類任務的完成記錄。聲譽一旦可累積，下一次匹配便無需從零建立信任。

個人用戶並非不能用，但早期更像樣板。企業有預算、有回購、有內部驗收習慣，更接近市場冷啟動所需的訂單密度。

支付只解決付款，僱人仍缺驗收

把錢打出去，與將一單任務僱出去，中間隔著託管、交付、驗收、異議。Stripe 與 x402 覆蓋的是前半段。代理仍需找到人去遞交複議、代表業主。沒有驗收，支付越方便，錯誤訂單也可能走得越快。

現有產品已按這一結構搭建。

Daydreams 的 TaskMarket（任務市場）由買方發單、代理接單。買方先將資金打入，可讓工人直接認領，也可先看方案再選人。資金放在託管中，提交成果被接受後才放款。

Virtuals 的代理 Commerce Protocol 由委託方代理與接單方代理談好任務，資金進入託管，交付並通過審批後放款。還可加入外部評估人，核查成果是否符合事先約定。NEAR（區塊鏈平台）一側也在將任務、預算、競標與驗證整合為一套流程，方向同樣是「為完工的任務定價」，而非只為一次調用定價。

幾家路徑不完全相同，但骨架接近：發單、匹配、託管、提交、驗收、放款。缺少驗收，託管只是延遲轉帳；有了驗收，託管才成為對結果的約束。

有人將驗收單寫得更細：需寫清委託內容、接單方、價格、驗證人、交付物、異議窗口、退款狀態。單據越完整，代理之間才能交接，而不必將用戶重新變為調度員。