Privy、Turnkey：钱包基础设施在 Agent 支付里做什么？

你想为一款 Agent 产品添加付款功能。有两种常见思路：使用一套面向 Agent 的现成产品，或自己把钱包、签名、权限和支付协议组合起来。Privy 和 Turnkey 适合从后一种思路理解：它们提供构建钱包和安全签名工作流的基础设施，具体体验仍由应用开发者设计。

证据说明：本文依据厂商官方文档整理，查阅日期为 2026 年 10 月 28 日；以下配置是概念示意，本站尚未实测。不同产品、账户类型和版本可能采用不同机制。

钱包、签名和支付并非同一个功能

flowchart TD U[用户或企业设定权限] --> APP[应用与 Agent] APP --> POLICY[策略和审批] POLICY --> SIGN[密钥管理与签名] SIGN --> NET[区块链或其他支付网络] NET --> MERCHANT[服务商确认与交付]

钱包地址用来接收或标识资产；签名用于证明交易由相应密钥授权；策略决定什么请求可被处理；支付交互让购买方和服务方协商付款。基础设施可能覆盖其中几个环节，不意味着自动处理商家履约、退款或业务对账。

Privy 的钱包策略与控制文档介绍了授权密钥、门限批准（多个密钥中需满足指定数量）、多因素认证和策略引擎。它描述的控制模型可从用户控制延伸到服务控制；实际谁能操作，取决于开发者的配置。

文档列出转账限额、收款方及合约名单等策略示例，也指出部分策略在安全环境中执行，限制转账大小依赖交易模拟，当前在该环境外执行。因此，评估保护时，要看具体策略与执行位置，不能只凭“安全环境”四个字判断全部限制。

举例：你允许 Agent 向三个数据商付款，但要求高风险操作由用户额外确认。设计时需要确认，名单限制是否覆盖该应用使用的所有调用类型；如果资金通过合约间接转移，规则是否仍有效。以上是需要验证的设计问题，并非声称 Privy 的特定配置一定覆盖。

Turnkey 的策略文档描述：策略可根据发起人、批准条件和请求内容允许或拒绝活动。文档示例展示了限制特定用户向指定地址发送交易；没有适用的允许规则时，多数操作默认拒绝。

这里有一个影响安全评估的细节：文档说明 Root Quorum（根用户法定人数）可绕过策略。因此，选择时还要研究根用户是谁、凭证如何保管、法定人数如何配置，以及恢复流程是什么，而不只是看普通用户的限制。

问题	Privy 公开文档示例	Turnkey 公开文档示例	应进一步验证
谁能操作？	授权密钥与门限	用户、策略与批准条件	管理员、恢复人及服务账户的实际权限
如何限制？	限额、收款方、合约等策略	基于活动和请求条件的策略	目标资产、网络及调用路径是否覆盖
谁控制资金？	用户或服务控制等配置	依组织与密钥配置而定	密钥导出、恢复、迁移和所有权条款
如何支付商家？	需与应用及支付组件结合	需与应用及支付组件结合	目标商家的协议、资产和交付接口
费用	依实际产品及合同	依实际产品及合同	免费额度、超额、网络费和支持费用

这个表是阅读框架，不是功能全面对比。在两边采用不同配置时，不能凭一行概述给出安全或价格排名。

如果你需要自定义用户体验、不同权限角色、现有身份系统或多种支付方式，基础设施可能提供更多组合空间；代价是你的团队需要负责更多集成、测试、故障处理和运营工作。这是基于产品层级的分析，不代表任何供应商一定适合你的项目。

动手前，先向厂商确认：目标网络和资产、策略覆盖、管理员绕过权限、密钥恢复与迁移、服务中断时能否取回控制权，以及实际报价。然后用相同任务验证批准、拒绝、过期和撤销行为。

继续阅读：《如何选择 Agent Wallet？一份实用判断框架》