Bridge：为 Agent 应用连接稳定币与法币资金路径

运营助手准备向供应商付款，但企业持有资金的通道与对方收款方式不同。生成一份看起来合理的付款指令还不够：客户必须具备资格，收款目标必须正确，最终状态也要可核实。Bridge 提供的是这一层资金移动基础设施。

资料边界： 2026 年 11 月 1 日核对官方文档，没有入驻客户、提交身份资料、创建银行指令或转移资金。供应商场景仅为说明。

Bridge 应放在业务批准之后

Bridge 文档覆盖稳定币与法币转移、托管钱包、发行和卡产品。这使它与 Agent 支付相关，但它不是专门定义 Agent 授权的协议。

供应商流程应先批准发票和收款目标，再调用转账工具。能移动资金的 API 密钥，不能代替业务批准。更合适的接口是“为已批准发票准备付款”，而不是让助手任意填写全部转账参数。

客户身份与通道权限分别检查

入驻文档区分个人与企业，并说明 KYC/KYB、条款接受及支付通道 endorsement。建立客户记录，并不代表所有目标路径都已开放。

应用应保存相应客户与通道资格，并在付款前刷新。如果状态改变，Agent 应报告具体阻碍并交给责任人处理，不能编造身份资料、在授权不明确时接受协议，或换用另一个客户身份来强行完成交易。

应用流程概念图，不是 Bridge 完整状态机，也不含真实客户或银行信息。

转账指令不是到账凭证

转账入门区分来源、目标、交易代表的客户和金额，并展示等待入金的状态，以及通过 API 或 Webhook 跟踪进度。

助手最初可能只能说“付款指令已准备”，不能说“供应商已收到钱”。提示应对应已知状态。如果还需要来源入金，就说明谁需要操作，并保留匹配资金所需的引用信息。

不能把文档示例中的账号或路由信息复制为生产付款指令。真实信息应来自经过授权后端核实的实际转账响应。

对账要覆盖最终状态与异常

状态文档区分已提交与已处理，并提醒提交阶段的交易哈希可能不是最终值；另有退回、退款与错误路径。创建请求成功，并没有回答这些后续问题。

我们建议让一份批准发票关联所有提交尝试及最终证据。重复或延迟通知不应触发另一笔付款。发生异常时，应保留原付款义务，直到送达、退回或退款结果得到确认。

记录	对 Agent 流程的作用
已批准发票版本	说明谁批准了金额和收款方
客户与资金通道	确认资金归属和适用资格
转账编号	故障后核对原交易，而非盲目重建
最终结果与回执	支持记账及准确通知供应商

Bridge 不替应用决定什么

支付平台不会替企业判断发票是否真实、变更后的收款人是否获准，或模型建议的付款是否合理。这些属于财务流程。文档支持某个通道，也不代表所有国家、客户和资产都具备资格。

当 Agent 产品需要连接稳定币与法币体系时，可以评估 Bridge。比较应围绕真实任务的托管模式、支持路径、处理条件和异常恢复。资料页保留官方入口；Agent 使用这些通道的权限仍需单独设计并执行。