Vincent - Credentials

核心用法

Vincent 是专为 AI 代理设计的凭证管理技能，解决「用户需要给代理提供 API 密钥但不想让密钥暴露在对话上下文中」的核心痛点。其工作流程为：

1. 创建密钥：代理通过 npx @vincentai/cli@latest secret create 创建凭证对象，获得 keyId 和 claimUrl
2. 设置值：用户通过 claimUrl 在 Vincent 仪表板中设置真实凭证值（代理不可见），或代理通过 REST API 直接设置
3. 安全写入：代理使用 secret env 命令将凭证直写 .env 文件，值永远不打印到 stdout 或进入代理上下文
4. 应用读取：目标应用正常读取 .env 文件使用凭证

支持四种密钥类型：API_KEY、SSH_KEY、OAUTH_TOKEN、CREDENTIALS（JSON 格式）。

显著优点

• 零暴露架构：凭证值从创建到使用全程不经过代理上下文窗口，从架构上消除泄露风险
• 代理优先设计：无需预配置环境变量，代理运行时自创建、自管理 API 密钥
• 覆盖保护：数据库级原子锁，仅创建该密钥的 API key 可覆盖其值，防篡改
• 生态兼容：支持 OpenClaw、Claude Code 等框架（通常黑名单读取 .env），形成「能写不能读」的安全边界
• 灵活字段提取：CREDENTIALS 类型支持 --field 参数提取特定字段（如仅提取 password）

潜在缺点与局限性

• 中心化依赖：所有 API 调用强制指向 heyvincent.ai，存在供应商锁定和服务可用性依赖
• 16KB 大小限制：单个凭证值上限较低，不适用于大型证书链
• CLI 环境要求：需 Node.js/npm 环境执行 npx 命令，容器化场景需额外配置
• 重新链接流程：API key 丢失后需用户生成 re-link token，人机协作断点
• 无本地回退：网络中断时无法离线创建或写入凭证

适合人群

• AI 应用开发者：构建需要第三方 API 密钥的代理/工具链，希望遵循最小权限原则
• 企业安全团队：需要审计追踪和密钥所有权管理（通过 claim/ownership 机制）
• 多代理协作场景：不同代理拥有独立 keyId，通过覆盖保护隔离权限

常规风险

• 仪表板成为单点：若 heyvincent.ai 服务遭入侵或跑路，所有凭证管理中断
• Re-link token 时效短：10 分钟过期可能导致运维中断
• 文件权限假设：依赖 .env 文件 0600 权限，若运行环境umask宽松可能泄露
• CLI 版本漂移：使用 latest tag 存在非预期更新风险