核心用法
lead-storage 是一个后置型持久化技能，仅用于将已验证的线索对象写入 Google Sheets 或数据库。它不接受原始用户输入，也不执行解析、提取或分析操作，而是依赖上游 supervisor 节点提供的显式确认令牌（confirmation_token）作为安全闸门。
典型调用链为：用户请求 → Supervisor 解析/验证 → 显式确认 → lead-storage 执行写入。
显著优点
1. 强确认机制：通过强制校验 confirmation_token 杜绝未授权写入，符合最小权限原则。
2. 幂等写入设计：以 lead_id 为键实现重复执行安全，避免数据重复或覆盖冲突。
3. 明确边界隔离：严格区分解析层与存储层，降低单点故障导致的数据污染风险。
4. 失败闭合（Fail-Closed）：令牌缺失、权限模糊或验证失败时主动拒绝写入，防止静默错误。
潜在缺点与局限性
- 无自主决策能力：必须依赖外部确认，无法独立判断写入时机，可能增加交互轮次。
- 无回读验证：设计为 write-only，不执行写入后的读取校验，需依赖上游保证数据正确性。
- 令牌生命周期未明确：若令牌过期或重复使用策略缺失，可能导致可用性问题。
适合人群
- 需要高置信度数据入库场景的企业级用户
- 已部署 Supervisor 审批节点的多智能体系统
- 对数据一致性有严格要求、接受延迟换取安全的业务场景
常规风险
| 风险类型 | 说明 | 缓解建议 |
|---------|------|---------|
| 令牌泄露 | 确认令牌若被截获，可能导致未授权批量写入 | 实施短期令牌 + 签名机制 |
| 上游污染 | Supervisor 若提供错误数据，将原样持久化 | 增加 Schema 严格校验与业务规则校验层 |
| 部分失败处理 | 批量写入时单条失败可能影响整体状态一致性 | 完善 `error_message` 与重试补偿机制 |
| 审计盲区 | 当前规范未要求写入日志结构化输出 | 补充可查询的写入审计追踪 |