核心用法
MagicPay 是一款面向敏感操作场景的安全自动化工具，采用「会话-子资源」架构设计。用户需先通过 magicpay start-session 启动受保护的产品工作流会话，再绑定浏览器子资源（launch 或 attach），随后执行 Memory 填充计划（plan-fill → apply-fill）完成表单填写。关键操作如支付授权需显式获取用户键入确认（authorize-payment），且原始凭证值全程对 LLM 隐藏，仅通过句柄引用传递。
显著优点
- 隐私隔离架构：存储的登录信息、身份数据、支付卡等敏感值完全隔离于 LLM 上下文，采用「值无关描述符 + 不透明引用」机制，从设计上消除提示注入导致的数据泄露风险。
- 显式授权机制：所有 consequential actions（支付提交、登录、身份验证等）强制要求用户键入匹配确认，结合
--return-pending支持多渠道（Web/OTP）审批，避免自动执行的滥用风险。 - 模块化工作流：清晰区分产品会话（MagicPay 拥有）与浏览器资源（外部工具拥有），支持 OpenClaw 原生浏览器优先策略，便于集成到现有自动化流程。
- 合规性设计：对 OTP 等敏感输入实施「不记录、不摘要、不重复」原则，API 密钥和 CDP 端点禁止日志输出。
潜在缺点与局限性
- 信任边界有限：MagicPay 仅保护存储值对 LLM 的隔离，不保证浏览器、操作系统或 Shell 被入侵时的安全；用户已输入聊天窗口的明文密码同样不受保护。
- 运行时依赖：需 Node.js 环境及
magicpayCLI 全局安装，provider-backed 支付卡需先完成authorize-payment才暴露卡句柄，流程中断点较多。 - CAPTCHA 处理受限：仅作为恢复手段使用，需人工确认真实 CAPTCHA 存在，不能作为通用等待或挑战检测机制。
- 生态锁定：Memory 系统与 Mercuryo 后端深度绑定，跨平台迁移或自定义存储后端支持有限。
适合人群
- 需要自动化处理敏感支付、登录、订阅流程的企业用户与开发者
- 对 LLM 数据隐私有强合规要求的金融、医疗、身份验证场景
- 已在 OpenClaw/MagicBrowse 生态内构建工作流的自动化工程师
常规风险
- 会话管理风险：
MAGICPAY_API_KEY与本地配置文件（~/.magicpay/config.json）泄露可导致未授权访问；共享工作环境下需定期轮换密钥。 - 人机边界模糊：若 LLM 误判「页面事实未变」而跳过二次确认，可能导致非预期交易提交；需严格遵循「事实变更即重新授权」规则。
- CAPTCHA 误判：错误调用
solve-captcha可能触发反爬机制或账户限制。 - Browser 与 Workflow 生命周期错配：
end-session不自动清理浏览器，需确保浏览器所有者正确回收资源，避免会话残留。