大多數AI應用的對話都停得太早。它們停在"應用被生成"的那一刻。

這在第一波浪潮裡是合理的。一年前,看著一段提示詞變成一個能跑起來的介面,本身就已經是全場的重頭戲。今天,構建者們已經理解自然語言可以生成軟體。更難的問題是:生成出來的應用之後會發生什麼。

它能為真實用戶運行起來嗎?
它能安全地執行任務嗎?
它能計量成本、按價值收費、並出具憑證嗎?
構建者能從中獲得收入嗎?
用戶能不靠盲目相信一個隨機的應用列表就發現它嗎?

在X-Agent,我們反覆回到的正是這條界線:創建是必要的,但僅靠創建,並不能讓一個Agent應用變成一款真正的產品。缺失的那一層,是"構建完成之後"發生的一切。

摘要

下一個平台級問題,不是生成更多的AI應用,而是把已生成的Agent應用,變成可執行、可分發、可盈利的產品。構建路徑(Build Path)和運行路徑(Runtime Path)應該被當作兩套不同的系統。前者創建應用,後者讓真實用戶去操作它。

Agent應用的支付,應該與執行本身綁定------包括預算、計量、確認、結算、憑證和爭議處理路徑。Agent商店和增長,應該從精選分發和真實使用信號起步,而不是一個空的市場列表。

構建路徑只是產品的一半

構建路徑是目前大多數人已經認識到的那部分。創作者 → Studio → Harness(執行框架) → 沙盒 → 已部署的Agent應用。創作者描述自己想要什麼,系統解讀這個意圖,生成一個應用,在沙盒中預覽,再推進到部署。

這已經很有價值了。它去除了過去阻礙非工程師、也拖慢工程師的搭建工作:倉庫結構、環境配置、預覽循環、部署細節,以及第一輪的應用腳手架搭建。但如果我們止步於此,我們本質上只是擁有了一種"更好地創造供給"的方式。更多的構建者能產出更多應用，更多想法能走到演示階段，更多原型能被分享出去，這並沒有回答"產品"這個問題。一個生成出來的應用,仍然需要用戶、任務、狀態、權限、定價、信任和分發。

這正是我們把構建路徑與運行路徑區分開的原因。

運行時,是應用真正變得有用的地方

運行路徑始於應用部署完成之後。用戶 → Agent應用 → Agent對話 → 工具/狀態/錢包/支付 → 結果。這條路徑服務的是終端用戶,而不是創作者。一個已部署的Agent應用,不應該只是個貼了AI標籤的靜態頁面。用戶應該能打開這個應用、表達意圖、追問細節、觸發工作流、查詢狀態、調用工具,並獲得任務結果。

這話聽起來很顯然,直到你真正動手去構建它。

構建時的Agent和運行時的Agent,是兩份不同的工作。構建時Agent負責協助創建應用;運行時Agent負責協助用戶操作應用。如果把這兩個角色塞進同一段冗長的提示詞裡,系統就會變得難以推理、難以保障安全、也難以實現盈利。

運行時需要與用戶建立自己的一套"契約"。它需要知道這個應用可以讀寫哪些狀態;需要知道有哪些工具可用;需要知道哪些操作廉價且可逆,哪些操作昂貴、涉及外部系統或存在風險;需要知道何時該請求確認;還需要留下審計軌跡。

這就是"模型給出了一個答案"和"應用完成了一項任務"之間的區別。

一個具體的例子:線索分析不只是一句提示詞

以一個簡單的Agent應用為例:活動或行銷campaign結束後的線索(leads)分析。只靠提示詞的版本很常見:用戶粘貼一份線索列表,讓模型給它們排序。模型返回一張表格,或許還帶一個評分和建議的跟進話術。有用,但不完整。

一個真正可執行的Agent應用,必須處理工作流剩下的部分:

從表單、電子表格、CRM或活動系統中導入線索;
標準化字段,同時保留原始來源;
用模型進行分類,並可選調用增強型API做數據補充;
標記出哪些外部調用會產生費用;
在發送消息或寫回CRM之前請求確認;
記錄是誰批准了這次操作;
展示被收取了什麼費用、消耗了什麼資源、產生了什麼結果;
當任務失敗時,支持退款、重試或爭議處理。

這正是許多AI應用悄悄崩潰的地方。模型可以建議下一步該做什麼,但產品層必須承擔授權、執行、成本和責任。這一層產品能力,就是我們所說的"運行時(Runtime)"。

執行需要一份契約

我們不認為"Agent執行"意味著給模型無限的權力。更好的模式應該更收斂:用戶意圖 → 模型提出方案 → 運行時校驗 → 工具執行 → 審計記錄。模型負責理解和規劃,運行時負責驗證和執行。

對於任何有實際意義的操作,運行時應該能構造出一份"執行契約(Execution Contract)"。這不一定是介面上可見的一份文檔,而是告知平台"接下來即將發生什麼"的內部對象。

一份執行契約應該能回答:

付款方(payer):誰來付款；
Agent應用(agentapp):哪個應用正在執行； 構建者(builder):這個應用是誰創建的； 任務(task):正在執行什麼任務； 定價(pricing):這個任務如何計價； 預算上限(budgetcap):允許的最高成本是多少；
確認(confirmation):是否需要用戶確認；
計量(metering):應該測量什麼；
結算(settlement):支付如何結算；
審計(audit):執行過程如何被追蹤。

用戶體驗層面可以保持簡單:

"這項任務最高可能花費0.50美元,是否繼續?"

但後端不能這麼簡單。它需要知道用戶是否批准了這項任務、預留了多少預算、調用了哪些工具、實際執行成本是多少、任務是否完成,以及應該出具什麼樣的憑證。沒有這份契約,支付就只是個結帳介面;有了它,支付就成為了執行過程的一部分。

支付不是一個結帳按鈕

對於Agent應用,支付不應該被生硬地粘在產品外側。當一個Agent開始真正做事的那一刻,成本和價值就成為了運行時層面的问题。有些操作會消耗模型token,有些會調用付費API,有些會用到計算、存儲、搜索、數據服務商、部署基礎設施或第三方服務,還有些操作會直接創造商業價值。

所以支付問題不只是"刷卡還是用錢包?"

而是:

誰發起了這個任務?
誰批准了這筆預算?
消耗了什麼資源?
結果是否完成?
應該收取多少費用?
收入應該如何分成?
如果任務失敗會怎樣?
有什麼記錄能證明發生過什麼?

這就是為什麼我們把Agent應用的支付,視為一個"Agent商業層(Agent Commerce Layer)"。一個實用的"執行-商業"狀態機大致可能是這樣:報價 → 授權 → 預留 → 執行 → 計量 → 結算 → 出具憑證 → 分帳 → 退款/爭議處理。

大多數用戶永遠不需要看到這整套機制。他們應該只看到一個清晰的成本邊界和一個清晰的結果。舉個例子,一個線索分析類Agent應用的示例性定價策略可能是:

免費額度:前10次運行免費；
計價單位:按任務；
任務價格:每批線索3美元；
預算上限:每個任務允許的最高內部成本；
外部成本是否直接轉嫁:是/否；
是否需要確認:在發送外部消息或寫入CRM之前需要。

(這些數字只是產品模型的示例,並非X-Agent目前公開的實際定價。)

構建者不需要去核算原始的token成本,用戶也不需要看到每一項內部計量指標------平台應該把執行過程翻譯成用戶能理解的定價。早期階段,一個實用的起點很簡單:免費額度 + 用量上限 + 任務SKU。按用量計價適用於模型調用、API調用、搜索、存儲和計算;按任務計價適用於動作明確的場景,比如分析線索、生成一個頁面、部署一個應用、生成一份報告、總結一個數據集,或運行一個明確定義的工作流。

按會話或訂閱計價,適合高頻使用的工具。按結果計價很誘人,但應該放到更後面再做------在大多數Agent應用能夠按商業結果收費之前,歸因、風險、信任、責任認定和爭議處理機制都需要先變得足夠強大。

抽象支付通道,保留執行契約

支付通道不應該定義產品體驗。用戶購買的是任務結果,而不是支付協議本身。一個構建者想知道的是:

這個Agent應用該怎麼定價?
誰來付款?
成本如何被控制?
構建者收入什麼時候能變為現實?
任務失敗時會發生什麼?

他們不需要關心底層通道究竟是銀行卡、Apple Pay、平台積分、發票、穩定幣、錢包,還是某種Agent對Agent的支付協議。在產品層面,這些概念應該保持簡單:餘額、積分、發票、錢包。

而在底層,多種支付通道可以並存:

面向主流用戶的銀行卡或Apple Pay;
用於常見付費任務的平台積分;
面向企業客戶的發票或預付積分;
面向Web3原生用戶的錢包或穩定幣通道;
面向Agent對Agent場景的授權預算與自動結算。

新興基礎設施的例子包括agentic wallet(智能體錢包)、類似x402的付費調用協議、穩定幣結算,以及可編程支付系統。它們都指向同一個方向:軟體需要能在運行時層面工作的支付通道。這並不意味著每個Agent應用都必須使用加密貨幣,而是說應用層應該把支付通道抽象出去,同時在其之上保留住那份執行契約。

不同用戶會需要不同的支付通道，但契約本身應該保持一致。

分發同樣是運行時問題的一部分

一旦創建變得容易，分發就會變得更難。AI建構者會增加應用的供給量，但這不意味著用戶能找到合適的應用，也不意味著建構者能從自己創造的東西中獲利。一個Agent應用生態系統，需要的不只是一份公開的應用列表。它需要發現機制、信任機制、排名機制、激勵機制，以及使用反饋，同時還需要理解運行時風險。

一個普通的應用商店大致只會問：

這是個什麼應用?
是誰開發的?
我能安裝嗎?
評分怎麼樣?

而一個Agent商店需要問得更多：

這個Agent應用能執行什麼操作?
它需要什麼權限?
它能調用哪些工具?
使用它要花多少錢?
它已經完成了哪些任務?
有什麼使用信號能證明它確實有用?
存在什麼支付或憑證歷史?
這個建構者的信譽如何?
是誰在幫助分發或做內容篩選?

這是一個產品方向，不是說每個組成部分今天都已經成熟。我們的看法是：一個Agent商店不應該以一個空的開放市場作為起點，而應該從"為優質Agent應用提供精選分發和增長支持的一層"開始起步。這意味著要挑選高質量的應用、給它們初期曝光、運營活動、驗證真實使用情況、獎勵有效的分發行為，同時過濾掉低質量或虛假的活躍數據。

增長機制可以起到幫助作用，但前提是它必須與真實使用綁定。推薦獎勵、任務活動、排行榜、生態激勵------這些機制只有在真正把用戶導向能解決問題的Agent應用時才有意義，否則它們只會製造流量，而不會帶來信任。

建構者經濟的飛輪

商業機會出現在建構、運行時、支付和分發被連接起來的時候。

建構者創建Agent應用
→ 用戶發現並使用它
→ 運行時對執行過程進行計量
→ 用戶為有用的任務付費
→ 建構者收入變得可能
→ 推薦人或內容策展人幫助分發
→ 真實使用數據改善排名和模板
→ 更多建構者加入

支付與產品使用綁定，分發與執行質量綁定，建構者激勵與運行時計量綁定。要讓這套機制真正運轉起來，平台最終需要一套真實的帳本(ledger)。每一次有意義的付費執行，都應該能記錄下：

總收費金額(grosscharge) 模型成本(modelcost)
工具成本(toolcost) 基礎設施成本(infracost)
支付手續費(paymentfee) 平台費用(platformfee)
建構者收入(builderrevenue) 推薦獎勵(referrerreward)
退款金額(refundamount) 結算狀態(settlementstatus)

沒有這個基礎，收入分成、退款、企業計費、反欺詐控制、稅務申報、打款和審計都會變得非常脆弱。有了它，Agent應用就能成為真正的經濟單元：建構者可以發布一個應用，用戶可以為一次有用的任務付費，內容策展人可以幫助分發，平台可以基於執行質量而不只是行銷文案去給應用排名。這就是從"應用生成"到"Agent應用商業化"的轉變。

X-Agent的位置在哪裡

X-Agent正在被建構為一個"Agent應用層"。

它不打算取代基礎模型，不打算取代雲服務商，不打算取代錢包基礎設施，也不只是又一個編程Agent。我們正在建構的技術棧大致是這樣的：

基礎模型
→ Builder / Harness(建構器/執行框架)
→ 安全運行時 / 工具 / 錢包
→ Agent應用
→ 商店 / 分發 / 增長

基礎模型提供智能;
建構器和執行框架把意圖轉化為應用;
安全運行時、工具、錢包和支付系統定義執行邊界;
Agent應用面向真實用戶;
商店、分發和增長系統幫助優質Agent應用獲得規模化的用戶採用。

重點不在於今天每一塊拼圖都已經完成，而在於Agent應用需要經歷這樣一套完整的生命周期：創建 → 部署 → 運行 → 計量 → 收費 → 結算 → 分發 → 迭代改進。如果一個平台只幫助人們創建應用，那它只是在"應用建構器"這一層競爭;如果它只提供錢包，那它只是基礎設施;如果它只運營增長活動，那它只是一個分發工具。

而Agent應用層，把這三者連接了起來。

從生成的應用，到Agent商業體

AI軟體的第一階段，關注的是智能------能回答、能推理、能生成、能提供協助的模型。下一階段，關注的是執行------能使用工具、管理狀態、完成任務的Agent應用。再下一階段，關注的是經濟------能被發現、被定價、被付費、被分發，並通過真實使用不斷改進的Agent應用。

生成出來的應用，只是這條轉化鏈路的起點，而不是產品的終點。AI應用的未來，不會由"能生成多少個演示demo"來定義，而會由"有多少Agent應用能夠執行真實任務、觸達真實用戶、並維持真實的經濟活動"來定義。

這正是X-Agent正在建構的應用層方向。

如果你正在建構Agent應用、智能體錢包基礎設施，或是為AI原生軟體搭建分發渠道，歡迎關注X-Agent，獲取更多關於運行時、商業化與分發方面的建構筆記。