核心用法
lead-storage 是一个写-only 存储执行器，设计用于在 Supervisor 显式确认后将已验证的线索对象持久化。其核心流程为：接收主管下发的 payload → 校验输入格式 → 验证 confirmation_token 存在且非空 → 通过 write-only 接口写入存储 → 按标准输出格式返回结果。
该 skill 采用确认门控机制（confirmation gating），即任何写入操作必须携带有效审批令牌，否则立即拒绝。这种设计将"审批"与"执行"职责分离，形成清晰的安全边界。
显著优点
1. 安全边界清晰：严格区分解析/提取（上游）与存储（本 skill），避免单点权限过大
2. Fail-closed 设计：权限模糊、令牌缺失或校验失败时一律拒绝写入，降低误操作风险
3. 幂等写入支持：以 lead_id 为键实现幂等，防止重复插入导致数据异常
4. 结构化日志：拒绝写入时记录具体校验原因，便于审计与故障排查
5. Schema 驱动：输入输出均有 JSON Schema 约束，减少接口歧义
潜在缺点与局限性
- 功能单一：仅支持写入，无法读取、查询或分析已存数据
- 依赖外部确认：必须等待 Supervisor 提供令牌，无法自主完成闭环
- 无自愈机制：部分失败时仅返回错误状态，不自动重试或补偿
- 无批量优化说明：未明确说明大批量写入的性能或事务保障
适合人群
- 需将线索数据从处理流程安全归档至存储层的系统架构
- 强调职责分离、审批留痕的合规敏感型业务场景
- 已具备上游解析/提取 skill、仅需原子化写入能力的集成方
常规风险
- 令牌泄露风险：若
confirmation_token被截获，可能导致未授权写入（需依赖传输层加密与令牌生命周期管理） - Schema 漂移：上游 payload 与
storage-input.schema.json不匹配时会导致写入被拒，需版本对齐 - 幂等键冲突：
lead_id设计不当可能引发意外覆盖或重复判断错误 - 日志敏感信息：校验原因日志可能包含业务数据，需关注日志脱敏与访问控制