独立解读
Cobo Agentic Wallet：用 Pact 给 Agent 一份可执行的权限
类型：产品分析｜资料查阅：2026-10-28｜依据 Cobo 官方资料，未实际创建钱包或进行交易。
用户让一个链上 Agent 每天检查资金情况，并在指定条件下进行小额兑换。用户希望它自动工作，却不希望它获得整个钱包的无限控制权。
Cobo Agentic Wallet 的核心设计是：让人先批准一份限定用途和权限的 Pact，Agent 再在范围内发起交易。它把链上钱包、签名、授权和移动端治理组合成一个产品。Cobo Agentic Wallet
Cobo 的背景
Cobo 是数字资产钱包与托管基础设施公司，官方称成立于 2017 年。其 Agentic Wallet 延伸了已有 MPC 签名和钱包管理能力，面向需要 Agent 执行链上操作的人或团队。Cobo 产品发布
MPC（多方计算）可以让不同参与方协作完成签名，而不要求 Agent 获得完整私钥。它的安全边界取决于具体参与方、密钥份额、策略和恢复设计，不能只凭“MPC”一词断定绝对安全。
Pact：把任务变成边界
假设用户说：“在 Base 上，每天最多花 10 美元购买指定数据服务，有效期一周。”一个 Pact 可能需要表达允许的任务、资产、预算、有效期、目标和结束条件。
这是概念示意，具体能设置哪些条件应以实际产品版本为准。官网描述用户可以在移动端审批、调整和监控 Agent，并通过 Pact 约束交易。产品页面
| 能力 | 官网描述 | 要继续验证 |
|---|---|---|
| 授权范围 | Pact 绑定任务、规则和期限 | 哪些规则强制执行，哪些只是说明 |
| 签名 | MPC 签名，权限不同参与方分担 | 任一方离线、密钥泄露、备份失效时怎么恢复 |
| 使用场景 | 支付、转账、swap 与其他链上动作 | 每一条链和动作是否都支持相同规则 |
| 例外处理 | 用户审批、监控及冻结 | 正在执行或已签署交易能否停止 |
| 接入 | Agent skill 与移动端配合 | 版本、地区、账户资格及审计记录 |
谁能签，谁能恢复？
Cobo 当前产品页描述了两组签名参与关系：Agent 与 Cobo可处理 Pact 授权内的自动操作；用户与 Cobo用于治理及高价值审批等。官网同时称默认非托管，并提供可选托管模式；密钥恢复需要按官方实际配置与备份流程理解。Cobo FAQ
这里有两个容易忽略的问题：
- 用户能设置规则，不等于每笔交易都必须用户实时签名；需看所用模式和 Pact。
- 钱包服务支持多个网络，不等于每个网络都支持同样的策略、资产、支付协议和恢复方式。
官方早期发布材料与当前产品页面对模式和开放状态的措辞有所不同。准确情况应以当前文档、可见界面和合同核实，不能把早期“即将推出”或现有宣传描述一概当成已对所有人开放。
不只是钱包：Recipe 让 Agent 有可执行路径
Cobo 用 Recipe 描述预先组织的链上任务，例如转账、swap、x402 请求等。它试图减少 Agent 自己拼接合约和参数的工作。Cobo 产品介绍
Recipe 并不消除数据错误、模型误解、协议风险或用户批准错误。对同一 Recipe，仍需验证目标合约、报价、授权、费用和交易结果。
商业模式：早期免费，后续按用量的计划
官网 FAQ 称 Agentic Wallet 在 early access 免费，正式推出后的定价计划按使用量计费。当前实际价格、准入和各链费用需要与 Cobo 确认。官方 FAQ
Cobo 原有业务有钱包与数字资产基础设施；Agent 钱包可能让其已有签名、安全和服务能力面向新客户，但这是商业分析，不是 Cobo 已披露的 Agent 钱包收入。
| 比较维度 | Cobo Agentic Wallet | MetaMask Agent Wallet |
|---|---|---|
| 主要切入 | MPC、Pact 与授权治理 | 用户链上交易及钱包安全流程 |
| Agent 控制 | 官网描述 Pact 及策略检查 | 官网描述 Guard Mode、allowlist、风险检查 |
| 用户交互 | 产品页强调手机审批和监控 | 支持的方式及交易模式依产品配置而定 |
| 可用性与定价 | early access 免费、正式用量价格待确认 | Agent 钱包独立收费需核实 |
比较只基于各自公开资料，尚未在同一场景测试；MetaMask 上手指南与 Cobo 配置差异应逐项核验。
选型前的关键问题
- Pact 覆盖哪些链、资产、合约和 Agent 操作？
- 用户不在线时谁参与签名？例外审批如何到达用户？
- 设备丢失、Cobo 服务不可用、策略需要撤销时具体怎么恢复？
- 对已签名、待确认或跨链中的交易，冻结能影响到哪一步？
- early access 的资格、费用和正式版合同如何变化？
规则在哪里生效，会影响哪些风险？
Pact 是用户授权和执行计划的组织方式。真正需要核查的是签名前策略检查覆盖了哪些请求、签名参与方如何协作、以及不同模式下谁可以修改或撤销规则。
| 场景 | 如果只靠提示词 | 应向供应商核实的控制 |
|---|---|---|
| Agent 想向非允许对象转账 | 模型可能误解任务 | 收款地址及合约能否被拒绝 |
| Agent 在短时间发起多笔交易 | 每笔看似未超额 | 累计预算如何处理并发与待确认交易 |
| 用户手机暂时离线 | 例外操作无法直接确认 | 授权内操作与例外审批分别如何处理 |
| 交易已签名但未确认 | 界面可能仍显示待处理 | 撤销、冻结和广播的实际边界 |
这些问题是评估清单，并非认定 Cobo 已发生上述失败。早期测试可以先在支持的测试环境完成授权、拒绝、撤销与恢复路径，再决定是否使用真实资金。
对不同客户，价值也不同
个人交易者可能更重视手机审批、账户恢复和安全反馈；搭建多个 Agent 的团队可能更关心每个 Pact 的预算、策略变更、日志导出与批量管理。API 数据采购方还需检查 x402 请求在具体链和资产上是否支持，不能把链上 swap 支持直接等同于任意 API 支付支持。
比较价格时，除早期访问费外，还要查网络费用、兑换费用、服务商收费和实际可用地区。Cobo 的公开价格计划不等同于目标客户的最终合同。
判断。 Cobo 的产品重点是把 Agent 的授权与钱包签名、用户治理连接起来。真正的比较不是谁的宣传更安全，而是对应任务中规则在哪里被执行、用户能否撤销，以及失败时是否可恢复。