智能体商业（Agentic Commerce）

约 1880 字大约 6 分钟

2026-05-12

Agentic Commerce 讨论的是：当 Agent 能代表用户发现商品、调用 API、比较报价、发起付款和验收结果时，商业流程应该如何被重新设计。

为什么要探索这个

传统电商和 SaaS 订阅都是人来点按钮、填表单、确认付款。Agentic Commerce 的变化在于，很多购买行为会变成机器之间的协作：一个 Agent 发现某个 API 可以完成任务，向服务方询价，确认预算，付款，拿到结果，再把结果交回给用户。

这件事看起来只是“AI 自动买东西”，但真正的难点在交易边界：

Agent 是否能判断这个服务值得买？
用户预算如何表达成机器可执行的限制？
服务方如何证明任务完成？
结果不满意时如何退款或仲裁？
小额、高频、跨平台的机器支付怎么做？

第一性原理

Agent 可以替用户发起商业动作，但不能替用户承担无限责任。

商业自动化的核心不是让 Agent 随便花钱，而是把购买意图、预算、验收标准和争议规则变成结构化协议。

购买前要有 intent：买什么、为什么买、最多花多少、接受什么结果。
购买中要有约束：报价、有效期、服务条款、数据使用范围和退款条件。
购买后要有证据：任务结果、收据、日志、验收记录和争议路径。

知识节点

Agents Purchasing APIs

Agents Purchasing APIs 指 Agent 直接购买 API、数据、推理、存储、检索、执行服务的能力。它不是人类开发者提前注册账号、复制 key、充值套餐，而是 Agent 在任务过程中动态发现服务并完成调用。

一个最小流程通常是：

Agent 识别当前任务需要外部服务。
查询可用服务、价格、能力和限制。
生成购买请求和预算约束。
服务方返回报价和调用方式。
Agent 在用户授权范围内付款并调用。
系统记录结果、费用和失败原因。

这里最重要的不是“自动付款”，而是服务发现、价格透明、权限限制和调用日志。

Payment Intent

Payment Intent 是用户授权 Agent 花钱之前的结构化表达。它应该比一句“帮我买最合适的服务”更具体。

一个 Payment Intent 可以包含：

任务目标：要完成什么。
预算：单次、每日或总额度。
支付资产：稳定币、平台余额或其他 token。
可接受服务方：白名单、黑名单或最低声誉。
质量要求：输出格式、响应时间、准确性或验收标准。
退款条件：超时、失败、格式错误、结果不可用。
有效期：这次授权持续多久。

Payment Intent 的作用是把用户意愿变成机器能检查的边界。Agent 可以在边界内决策，但不能把边界解释得越来越宽。

Budget Control

预算控制是 Agentic Commerce 的安全阀。没有预算控制，Agent 的一次循环错误就可能不断购买服务、重复调用 API 或发起无意义交易。

预算应该分层：

任务预算：完成某个任务最多花多少。
服务预算：单个 API 或 provider 的上限。
时间预算：每小时、每天、每周的总额度。
风险预算：高风险服务必须人工确认。
失败预算：连续失败几次后停止。

对用户来说，预算界面要可理解：不是一堆抽象参数，而是“这个 Agent 最多能花多少钱、花在哪些服务上、什么时候自动停止”。

Proof of Task Completion

服务方拿到钱之前，系统需要判断任务是否完成。Proof of Task Completion 不是一种单一证明，而是一组证据。

不同服务的证据不同：

API 服务：请求 ID、响应状态、结构化输出、时间戳。
数据服务：数据哈希、版本、字段说明、授权记录。
推理服务：模型版本、输入摘要、输出哈希、评测结果。
执行服务：交易哈希、事件日志、状态变化。
人工服务：交付物、验收记录、争议窗口。

在低价值场景里，日志和回调可能就够了；在高价值场景里，可能需要签名回执、链上事件、第三方评测或托管仲裁。

On-chain Receipt

On-chain Receipt 是把关键交易结果记录到链上。它不一定保存完整内容，而是保存足够让双方事后核对的证据。

一个 receipt 可以包含：

payer、provider、agent 或 task id。
支付金额、资产、链和交易哈希。
服务类型和报价 id。
输出哈希或交付物引用。
完成时间、验收状态和争议状态。

链上 receipt 的价值是让跨平台结算更容易对账，也让 Agent 的商业行为更可追踪。但不要把所有敏感输入和输出都直接上链，隐私数据应该只保存哈希或加密引用。

Escrow Flow

Escrow Flow 用托管状态机降低交易双方的不信任。用户不想先付款后拿不到服务，服务方也不想先交付后收不到钱。

一个基础 escrow 流程：

用户或 Agent 创建任务和预算。
资金进入托管合约或受控账户。
服务方接受任务并交付结果。
系统按验收标准检查结果。
验收通过则放款。
验收失败则退款或进入争议。

Agentic Commerce 里的 escrow 要特别注意自动验收边界。模型可以帮助判断结果是否合格，但高价值或主观结果不应该只靠模型自动放款。

在 AI x Web3 中的位置

Agentic Commerce 把 Agent、钱包、权限、支付、托管、声誉和验证连在一起。它不是单个功能，而是一条商业闭环。

如果做项目，可以从三个方向切入：

帮 Agent 购买 API、数据或推理服务。
帮服务方接受 Agent 支付并自动交付。
帮用户管理预算、权限和消费审计。

最小实践

设计一个“Agent 购买链上数据分析 API”的流程。

写清楚：

用户目标和预算。
Agent 如何发现 API 服务。
服务方报价包含哪些字段。
Payment Intent 如何限制金额、次数和服务范围。
API 如何证明已经完成分析。
收据和日志如何保存。
失败、超时和结果不满意时如何退款。

扩展阅读

x402 Protocol：学习基于 HTTP 402 的机器支付流程。
Coinbase x402 Docs：看实际开发者如何接入 x402。
Machine Payment Protocol：理解 Agent 支付、服务发现和结算的协议化尝试。
Agent Payments Protocol：了解 Agent 支付授权、意图和商业交互的协议设计。
ERC-8183：阅读 Agent 任务支付和托管相关的 EIP。