核心用法
Vincent 是专为 AI Agent 设计的托管式加密钱包基础设施，核心目标是让 Agent 能够自主执行 EVM 链上操作，同时确保私钥绝对隔离。
使用流程：
1. 创建钱包：Agent 调用 secret create 生成钱包，自动存储 API key，返回 claimUrl 供人类用户认领所有权
2. 策略配置：人类通过 claimUrl 在 heyvincent.ai 设置服务端策略（支出限额、白名单、审批阈值等）
3. 日常操作：Agent 使用 scoped API key 执行转账、Token Swap（0x 聚合）、合约调用、余额查询等
4. 审批机制：超出阈值的交易自动进入 "pending_approval" 状态，通过 Telegram 通知人工审批
关键设计： Agent 持有的不是私钥，而是策略约束的 Bearer Token。所有交易在 Vincent 服务端执行，私钥永不离开服务器。
显著优点
| 优势 | 说明 |
|------|------|
| **私钥零暴露** | Agent 仅接触 API key，真正的 EOA/Smart Account 私钥由服务端托管 |
| **服务端策略强制** | 支出限额、地址白名单、Token 白名单、函数选择器白名单均在服务端强制执行，Agent 无法绕过 |
| **无需 Gas 费** | 内置 Paymaster，所有 EVM_WALLET 交易 gas 完全免费 |
| **开源可审计** | 完整服务端代码开源（github.com/HeyVincent-ai/Vincent），支持自托管 |
| **灵活密钥生命周期** | 支持随时撤销、轮换、重新链接（re-link），单点故障可控 |
| **跨生态支持** | 除标准 EVM 交易外，RAW_SIGNER 模式支持 Ethereum ECDSA 和 Solana Ed25519 原始签名 |
| **零配置启动** | 无需预置环境变量，Agent 运行时自举创建钱包，符合 agent-first 设计理念 |
潜在缺点与局限性
1. 托管信任假设：尽管开源可审计，默认使用 heyvincent.ai 托管服务，用户需信任其基础设施可用性和政策执行正确性
2. 网络单点依赖：所有 API 调用仅指向单一域名，若服务中断 Agent 失去钱包操作能力
3. 审批延迟：高价值交易触发人工审批时，链上操作变为异步流程，不适合需要原子性或即时确认的场景
4. Solana 限制：RAW_SIGNER 虽支持 Ed25519 签名，但 EVM_WALLET 的 gas 赞助和智能账户功能仅限 EVM 链
5. 策略生效延迟：未认领钱包前无策略保护，存在短暂的"空窗期"风险
6. API Key 泄露风险：虽为 scoped token，但若泄露且策略宽松，攻击者可在策略允许范围内操作
适合人群
- AI Agent 开发者：需要为 Agent 赋予链上能力，但不愿将私钥交给 LLM/Agent 环境
- 自动化交易策略团队：需要 7×24 小时运行，同时设置严格的支出上限和人工审批兜底
- DAO 财库管理：多签之外的轻量级自动化支出方案，适合小额高频操作
- DeFi 协议集成方：需要后台服务执行链上交互，同时满足合规审计要求
- 个人高级用户：希望 Agent 能自主操作钱包，但保留最终控制权
常规风险
| 风险类型 | 具体表现 | 缓解措施 |
|---------|---------|---------|
| **服务端作恶** | Vincent 服务器错误执行或泄露私钥 | 代码开源可审计，支持自托管；密钥分片/HSM 保护 |
| **策略配置错误** | 人类设置过于宽松的策略导致损失 | 默认保守策略，建议从低限额开始测试 |
| **Telegram 审批劫持** | 审批通知被拦截或仿冒 | 启用 Telegram 2FA，核实官方 bot 身份 |
| **Agent 被诱导** | LLM 被提示注入诱导发起策略内交易 | 结合应用层意图验证，不单一依赖策略 |
| **依赖服务故障** | 0x API、跨链桥等第三方服务失败 | 预览模式（preview）提前验证路径可行性 |
| **re-link token 泄露** | 10分钟有效期的轮换 token 被截获 | 通过安全渠道传输，用后即焚 |
安全架构总结
Vincent 采用"服务端托管 + 策略强制 + API 代理"的三层模型，将传统"持有私钥 → 签名交易"转变为"持有能力令牌 → 请求服务端执行"。这不是传统意义上的自托管钱包，而是一种可编程的托管代理模式——安全性的核心从"密钥保密"转向"策略正确性"和"服务端可信度"。