核心用法
OpenClaw + 1ly Payments 是为 OpenClaw 框架设计的支付能力扩展，通过 MCP（Model Context Protocol）服务器将 1ly 的支付网络接入 AI Agent。核心流程分为三步：安装 mcporter 工具 → 添加 1ly MCP 服务器 → 在 OpenClaw 配置中启用并设定预算与钱包。
配置要点：
- 钱包设置：Solana 钱包用于代币发行与交易（
ONELY_WALLET_SOLANA_KEY），Base 链建议用 Coinbase Agentic Wallet（ONELY_WALLET_PROVIDER=coinbase）而非裸私钥。 - 预算管控：通过
ONELY_BUDGET_PER_CALL和ONELY_BUDGET_DAILY设定自动支出上限，超预算则阻断交易。 - Seller 身份：
ONELY_API_KEY仅用于创建商店与收款链接，自动保存在本地配置目录。
四大工具流：
1. Buyer 流：搜索 API（1ly_search）→ 获取详情 → 调用付费（1ly_call）→ 可选评价
2. Seller 流：创建商店（1ly_create_store）→ 生成收款链接（1ly_create_link）→ 分享链接自动完成交付
3. Token 流（Bags.fm）：发币（1ly_launch_token）→ 询价 → 交易 → 提取手续费，需自备 Solana RPC 节点
4. 免费工具：1ly_search、1ly_get_details 无需钱包即可使用
安全设计：
- 钱包文件仅限用户主目录或
/tmp，外部路径被拒绝；建议权限chmod 600 - 沙箱环境可用内联密钥数组替代文件路径
- 自动支出为 opt-in，必须显式配置预算才启用
显著优点
- 协议级集成：通过 MCP 标准与 OpenClaw 深度耦合，工具调用原生自然
- 多链支持：Solana（发币/交易）+ Base EVM（USDC 支付）双轨并行
- 预算熔断机制：双层预算硬限制，防止 Agent 无限额消费
- 零托管：私钥本地存储，1ly 不接触用户资金
- x402 兼容：支持未来互联网支付协议演进
潜在局限
- 依赖复杂度：需同时维护 Node.js 工具链（
mcporter、npx）、Solana RPC 节点、OpenClaw 配置三层基础设施 - 私钥管理负担：虽然本地存储，但 JSON 文件或内联数组仍存在被日志、备份泄露风险
- Solana 单点依赖：Token 工具仅支持 Solana，以太坊生态用户无法使用发币功能
- 预算非实时链上检查：预算限制在 Agent 层实现，非智能合约级熔断，极端网络延迟可能绕过
- Seller API Key 本地存储：macOS/Linux/Windows 路径差异大，容器化环境需额外挂载卷
适合人群
- AI Agent 开发者：希望为 Agent 添加原生支付能力的 OpenClaw 用户
- Solana 项目方：需要快速发币、设置交易手续费的创作者（Bags.fm 集成）
- API 服务商：想通过 1ly 网络出售 API 调用次数的开发者
- 自动化交易用户：寻求 Agent-to-Agent 自动结算的加密原生用户
常规风险
| 风险类别 | 具体描述 | 缓解建议 |
|---------|---------|---------|
| **私钥泄露** | 钱包 JSON 文件权限不当或被意外提交至代码仓库 | 使用 `chmod 600`，排除于 `.gitignore`，优先用 Coinbase Agentic Wallet |
| **预算绕过** | Agent 配置错误或恶意修改预算参数导致超额支出 | 定期审计 `openclaw.json`，设置极低初始预算测试 |
| **MCP 服务器供应链** | npm 包 `@1ly/mcp-server` 被篡改或依赖库存在漏洞 | 验证 `dist.integrity`，固定版本号 `@0.1.6`，监控 CVE |
| **RPC 节点不可靠** | 默认 Solana 公共 RPC 延迟高或故障影响交易 | 自建或付费 RPC，配置 `ONELY_SOLANA_RPC_URL` |
| **Token 工具参数误设** | `slippageBps` 或 `share_fee` 配置错误导致资金损失 | 先用小额测试交易，理解 `bps`（基点）单位 |
| **环境变量注入** | 内联密钥通过环境变量传递时被 shell 历史记录 | 使用专用密钥管理工具，避免命令行直接暴露 |
生态定位：该 skill 属于 OpenClaw 生态的支付基础设施层，与 1ly 网络的其他技能（如 1ly-payments）形成互补，专注于 Agent 框架集成而非独立支付工具。