智能体商业(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。