在让 AI Agent 支配资金之前

AI 系统正在从“给出建议”走向“参与商业执行”。Google 将 UCP 描述为面向 agentic commerce 的开放标准，并将 AP2 描述为与之兼容的授权层，通过结构化 mandate、约束和可审计的意图证明来表达授权。OpenAI 与 Stripe 也共同开发了 Agentic Commerce Protocol，用于连接用户、AI Agent 与商家之间的交易流程。

这意味着一个新的工程边界正在形成：Agent 不再只是告诉用户“可以买什么”，而可能参与选择、协商、授权甚至执行具有经济后果的动作。

Anthropic 的 Project Deal 提供了另一个现实信号。在这个实验市场中，AI 代表用户协商真实物品并达成 186 笔交易，总交易价值超过 4,000 美元。这不是生产级支付网络，但它说明“把经济行为委托给 Agent”已经不是纯理论问题。

先看一个很普通的分布式系统故障。

Agent 被要求向供应商付款。支付请求已经发送，但在收到确定响应之前发生网络超时。

如果第一次付款确实失败，那么重试可能是正确行为；但如果付款已经提交，只是 acknowledgement 丢失，那么盲目 retry 可能造成重复付款。

第二次 API 调用甚至可能返回 200 OK，Agent 也可能报告“付款成功”。最终答案看起来没有问题，但业务不变量已经被破坏。

授权只解决了信任的一部分。

AP2 的价值在于把委托意图和消费约束表达得更加明确。Google 的开发者说明展示了 IntentMandate、绑定具体购物车和金额的 PaymentMandate，以及用于结束授权审计链路的 PaymentReceipt。

但应用系统仍然必须处理自己的状态机、支付提供商行为、并发变化、retry、settlement 与 recovery。一个“授权正确”的请求，仍然可能经过一条错误的执行路径。

Trust contract 应该独立于具体模型。

一个可靠的金融 Agent 合约不应该只是“模型要小心”。它应该定义一组可以被外部验证的条件，无论执行动作的是哪一种模型或 planner。

INTENT
用户授权向供应商付款 ≤ $1,000

STATE
发票仍处于未付款状态

TIME
执行时授权仍然有效

TRANSITION
UNPAID → PAYMENT_PENDING → PAID

RECOVERY
Unknown commit 必须先 reconciliation，而不是 blind retry

VERIFICATION
Provider state 与 authoritative ledger 一致

EVIDENCE
Intent + authority + attempts + reconciliation + decision 被保存

这样，问题就从“我们相信哪一个模型”变成：

一种更安全的不确定状态恢复路径。

这不是适用于所有支付系统的统一算法。有些系统提供 idempotency，有些 reconciliation 机制不同，有些业务还包含延迟结算和多方授权。重点不是“RESONANCE 发明了万能支付方案”，而是：recovery path 本身必须显式、可测试、并且留下证据。

这正是我们需要市场参与的地方。

我们可以无限生成 synthetic failure cases，但真实生产环境中的限制会告诉我们哪些 missing capability 真正值得构建。

对于有价值的案例，我们的第一步不是销售大型平台，而是找出 missing guarantee，绘制执行轨迹，并返回一个具体的 verification hypothesis。如果同一种 missing capability 在多个独立团队中重复出现，它才会成为下一步产品化的证据。

市场回答会去哪里？

有意义的回答会被转化为结构化 Problem Card：workflow → failure → impact → workaround → missing capability → acceptance condition。随后进行 Product Signal Score，并进入 Demand Graph。所有 synthetic 示例都会明确标记，并从真实 market metrics 中排除。

Article #005 在达到证据阈值之前不会被称为“由市场选择”。当前规则要求至少 10 个有意义的外部 workflow，并且获胜 cluster 中至少有 3 个真实案例。

不要先造产品，再问市场喜不喜欢。创造有价值的对话，让市场自己暴露真正需要存在的产品。