核心用法
lead-storage 是一个确认门控的写入型技能，专用于将已验证的铅对象持久化到外部存储（如 Google Sheets 或数据库）。其执行严格依赖于上游 Supervisor 提供的显式确认令牌，形成「验证 → 确认 → 存储」的可靠链路。
执行流程
1. 接收 payload：从 Supervisor 获取待存储数据
2. Schema 校验：对照 storage-input.schema.json 验证结构完整性
3. 令牌核验：必须存在非空的 confirmation_token，否则拒绝执行
4. 写操作：通过只写接口执行幂等写入（以 lead_id 为键）
5. 结果返回：按 storage-output.schema.json 格式化输出
6. 失败处理：部分失败时返回 status: "failure" 及详细错误信息
显著优点
- 安全优先：强制确认令牌机制，杜绝未授权写入
- 幂等设计：以
lead_id为键，重复执行不造成数据重复 - 失败安全：权限模糊时主动失败（fail closed），不猜测执行
- 职责单一：专注存储，不跨界解析、分析或推荐
潜在局限
- 依赖性强：必须等待 Supervisor 确认，无法自主决策
- 功能受限：不支持读取查询、数据分析或增量更新
- 链式复杂度：完整流程需多技能协作，单点故障影响整体
适合人群
- 销售自动化流程开发者
- 需要审计追踪的 CRM 集成场景
- 对数据写入安全性有严格要求的团队
常规风险
| 风险场景 | 缓解机制 |
|---------|---------|
| 令牌伪造/泄漏 | Supervisor 层统一签发与验证 |
| 重复写入 | `lead_id` 幂等键控 |
| 权限升级 | Fail closed + 明确拒绝日志 |
| Schema 漂移 | 严格 JSON Schema 前置校验 |