大多数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应用(agent_app):哪个应用正在执行；
构建者(builder):这个应用是谁创建的；
任务(task):正在执行什么任务；
定价(pricing):这个任务如何计价；
预算上限(budget_cap):允许的最高成本是多少；
确认(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)。每一次有意义的付费执行,都应该能记录下:

总收费金额(gross_charge)
模型成本(model_cost)
工具成本(tool_cost)
基础设施成本(infra_cost)
支付手续费(payment_fee)
平台费用(platform_fee)
构建者收入(builder_revenue)
推荐奖励(referrer_reward)
退款金额(refund_amount)
结算状态(settlement_status)

没有这个基础,收入分成、退款、企业计费、反欺诈控制、税务申报、打款和审计都会变得非常脆弱。有了它,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,获取更多关于运行时、商业化与分发方面的构建笔记。