核心用法
lead-storage 是一个写操作专用的存储技能，仅在 Supervisor 明确确认后执行。它接收已验证的线索 payload，完成最终持久化，适用于用户要求"保存已批准的线索到 Google Sheets"或"提交确认后的记录"等场景。
标准调用链：前置环节 → Supervisor 人工确认 → lead-storage 写入
执行流程：
1. 接收 Supervisor 传递的 payload
2. 用 storage-input.schema.json 严格校验结构
3. 强制检查 confirmation_token 存在且非空
4. 通过写-only 接口写入存储
5. 保留完整的提取/归一化/评分元数据（交易类型、资产类别、价格、面积、位置层级、优先级等）
6. 以 lead_id 为键实现幂等写入，防止同一 broker 多次转发导致重复
7. 按 storage-output.schema.json 返回结果
8. 部分失败时返回 status: "failure" 及详细错误信息
显著优点
- 确认门禁设计：强制人工确认 token，杜绝自动写入风险
- 幂等性保障：
lead_id去重机制应对重复提交场景 - 元数据完整性：完整保留上游提取、归一化、评分信息，支持追溯
- 故障安全：权限模糊时 fail-closed，token 缺失/无效时拒绝写入
- Schema 契约：输入输出均有 JSON Schema 约束，降低集成错误
潜在缺点与局限性
- 无自主判断能力：完全依赖上游确认，无法处理"边存边审"场景
- 无读取能力：不支持查询、分析、汇总等读操作
- 无解析能力：不能从原始消息中提取新线索实体
- 单点阻塞：Supervisor 确认成为必经瓶颈，高频批量场景效率受限
- 无冲突解决：仅记录失败原因，不提供自动重试或合并策略
适合人群
- 销售运营团队需将已审核线索归档至 Sheets/DB
- 需严格审批链的 B2B 销售流程（如商业地产、大额交易）
- 多 broker 环境下需防重复录入的数据管理员
- 合规要求高的场景（金融、医疗等需人工留痕行业）
常规风险
| 风险类型 | 描述 | 缓解措施 |
|---------|------|---------|
| 确认绕过 | token 被伪造或泄露导致未授权写入 | token 生命周期管理、最小权限存储 |
| 幂等失效 | `lead_id` 生成规则冲突导致重复 | 统一 id 生成策略、存储层唯一约束 |
| 数据丢失 | 部分失败时仅返回错误无自动补偿 | 上游实现重试队列、监控告警 |
| 权限扩散 | 写接口暴露面过大 | 网络隔离、仅允许特定服务账户调用 |