Paegents 支付

当代理（agent）需要通过 Paegents 购买或销售服务，且不绕过公开产品界面时，请使用此技能。

将指导限制在集成层。切勿暴露私钥、卖方侧密钥、未发布的端点、内部架构或内部操作细节。请说明系统预期的行为，以及为何工作流采用当前结构。

产品如此设计的原因

• 客户端签名（Client-side signing）：将支付权限保留在钱包所有者手中，而非平台。
• 协议创建与激活分离：商业接受（commercial acceptance）与链上资金锁定（on-chain funding）是两个不同概念。
• 激活包（activation package）为唯一可信源：费用、支出方（spenders）、随机数（nonces）及链参数必须源自实时状态。
• 结算模式在运行时确定：是否采用直接钱包执行（direct wallet execution）或赞助执行（sponsored execution），取决于当前签名者身份及协议状态。
• 用量记录与结算始终绑定于协议状态：买卖双方均可监控协议当前处于“仅被接受”、“已实际注资”还是“已就绪可结算”等阶段。

适用场景

• 买方代理需购买按用量计费（metered）或固定数量的服务
• 卖方代理需上架服务，并接受基于协议的付款
• 运维人员需了解某协议下一步合法的公开操作
• 任务涉及双向托管（bilateral escrow）、用量计量（metered usage）或结算模式选择

不适用场景

• 任务关注的是内部实现细节，而非产品使用方式
• 用户试图绕过策略、审批、验证或签名等合规要求
• 用户试图共享或记录私钥、原始钱包密钥或卖方凭证
• 将一次性直接支付（one-off direct payment）错误地等同于双向托管协议

预检（Preflight）

执行任何操作前，请确认以下事项：

• 用户已具备所选流程所需的公开凭证
  • 代理身份认证（agent auth）用于代理发起的支付操作
  • 仅所有者身份认证（owner auth）可用于所有者作用域内的初始化或策略类操作
• 买方钱包为自托管（self-custody），且由签名者实际控制
• 钱包中持有足够 USDC 以完成目标支付或托管注资
• 若所选结算模式需直接广播交易，则签名者需预留足够 Gas
• 若预期使用 SDK，则确保 SDK 已安装

切勿要求用户将密钥粘贴至聊天窗口。默认所有密钥均保留在其本地环境中。

操作规则

• 当 SDK 调用与手动构建 HTTP 请求均可选时，优先使用 SDK 调用。
• 优先采用实时响应结果，而非硬编码的假设值。
• 严禁自行构造费用金额、支出方地址、链 ID、随机数（nonce）或协议状态。
• 将 get_activation_package() / getActivationPackage() 视为双向激活流程的权威数据源。
• 若激活包中显示存在待处理的基础设施费用（pending infra fee），则须将基础设施费用许可（infra fee permit）视为买方所需的第二重授权，并单独签署。
• 在决定采用直接结算还是赞助结算前，务必先调用结算选项接口（settlement options）。
• 决策下一步操作前，应基于当前协议及托管状态进行判断。

工作流图谱

卖方流程

1. 注册服务。
2. 配置接受行为（acceptance behavior）与定价策略（pricing policy）。
3. 接受或拒绝协议。
4. 通过用量代理（metered proxy）交付服务，或通过公共 API 记录用量。
5. 持续监控托管与结算状态，直至资金可申领（claimable）。

买方：双向托管（Bilateral Escrow）

1. 搜索或选定服务。
2. 依据商业条款创建用量协议（usage agreement）。
3. 等待卖方接受协议。
4. 获取激活包（activation package）。
5. 在本地签署买方激活意图（buyer activation intent）。
6. 若激活包显示存在待处理的基础设施费用，则需在本地单独签署基础设施费用许可（infra fee permit）。
7. 提交激活请求，并轮询（poll）直至协议状态变为 active 且已被链上确认。
8. 通过用量路径（metered path）或约定的交付路径使用服务。
9. 在执行任何 close、claim 或 withdraw 操作前，务必检查可用的结算选项。

买方：直接稳定币购买（Direct Stablecoin Purchase）

当任务为无需双向托管的一次性购买时，请使用 direct stablecoin helper。该流程存在的意义在于解决更简单的信任问题：单次即时付款，而非长期按用量计费的协议关系。

状态指南

• proposed 或 pending：协议条款已存在，但商业流程尚未生效
• accepted 且激活仍待处理：双方已达成一致，但资金尚未锁定
• active 且激活已确认：托管资金已注入，可开始使用服务
• 激活失败或需刷新签名：检查失败原因，补全缺失的授权，并通过公开路径重试

后续应查阅的参考文档

• 如需最简端到端公开路径，请阅读 references/QUICK_START.md。
• 如需全生命周期指引及决策规则，请阅读 references/PAYMENT_FLOWS.md。
• 如需 Python 与 TypeScript 的 SDK 方法映射，请阅读 references/SDK_USAGE.md。
• 仅当 SDK 功能不足时，才查阅 references/API_REFERENCE.md。
• 如任务因 API 错误或状态错误受阻，请阅读 references/ERROR_CODES.md。
• 如任务涉及重试、轮询或批量操作，请阅读 references/RATE_LIMITS.md。

公开支持边界

请始终限定在客户或运维人员可通过产品直接完成的操作范围内：

• 已发布的 SDK 方法
• 已发布的 API 路由
• 已文档化的激活、用量计量与结算流程
• 已文档化的错误处理与重试行为

当存在明确的公开下一步操作时，切勿提供仅限内部使用的修复步骤。