（7981期）多机器人去重消息 – 多机器人智能去重防打扰

多机器人智能去重防打扰 基于飞书多机器人场景的消息去重技能，通过30秒时间窗口与内容哈希匹配，确保同一用户重复消息仅触发一次AI回复，提升体验并降低算力消耗。 使用说明 核心用法 multi-bot-dedup 是一项针对飞书多机器人接入场景的行为规范型技能，而非可执行代码。当用户在 OpenClaw 平台配置了多个飞书机器人（如兵部、吏部、礼部等不同业务机器人）时，同一条用户消息可能通过多个渠道同时触发 AI 回复，造成重复打扰。该技能通过维护本地状态文件 dedup_state.json，实现智能化的消息去重机制。 具体执行流程为：AI 处理每条飞书消息时，首先读取状态文件获取用户历史记录；随后计算"用户ID + 消息前50字"的哈希值；若距离上次回复时间在30秒内且哈希匹配，则跳过本次回复（NO_REPLY）；否则正常回复并更新状态。整个过程无需人工干预，由 AI 自主遵守执行。 显著优点 体验优化：彻底消除多机器人场景下的重复回复问题，避免用户收到多条相同内容的 AI 消息，显著提升交互质量。 成本节约：通过拦截冗余请求，有效降低大模型 Token 消耗和算力成本，在高并发场景下收益尤为明显。 轻量无侵入：纯本地状态管理，无需调用外部服务或修改飞书机器人配置，部署成本极低。 灵活容错：30秒窗口 + 内容哈希的双因子机制，既能覆盖网络延迟导致的多路触发（通常<5秒），又允许用户在新话题或间隔较久时正常获得回复。 潜在缺点与局限性 状态单机化：dedup_state.json 存储于本地文件系统，若 OpenClaw 采用多实例部署，各实例间状态不互通，可能导致去重失效。 时间窗口固定：30秒阈值无法动态调整，对于网络延迟波动大的场景（如跨国部署）可能过短，导致漏去重；对于用户快速连续提问场景则可能误拦截。 哈希冲突风险：前50字哈希存在极低概率的碰撞可能，不同长消息若前50字相同可能被误判为重复。 无分布式协调：缺乏 Redis 等分布式锁机制，极端并发下可能出现竞态条件。 适合的目标群体 OpenClaw 平台运营者：已配置或计划配置多路飞书机器人接入的组织 企业 IT 管理员：需要统一管理多个业务线机器人，保障用户体验一致性 中大型企业用户：员工规模大、消息并发量高，对成本和体验敏感的组织 使用风险 性能风险：频繁的文件 IO 操作（读取+写入 dedup_state.json）在高 QPS 场景下可能成为瓶颈，建议配合内存缓存优化。 数据持久化风险：状态文件损坏或丢失将导致去重历史清零，短期内可能出现重复回复，需做好文件备份监控。 规则误用风险：AI 需严格区分"行为规范遵守"与"主动技能调用"的边界，避免因理解偏差导致该跳过的未跳过、不该跳过的被拦截。 兼容性风险：该技能深度绑定 OpenClaw 运行时环境与飞书消息协议，迁移至其他平台需重新适配。 原始说明 多飞书机器人去重回复规则。当同一用户通过多个机器人渠道同时发送相同消息时，AI 只回复一次，避免重复打扰。适用于配置了多路飞书机器人接入的 OpenClaw 场景。