问题现象与适用场景
有些人在把 OpenClaw 本地部署到飞书后，会遇到“机器人一直重复输出同一句话”或“同一条消息被连续回复多次”的情况。原始描述里提到使用的是 Kimi2.5 模型，问题发生在飞书接入场景中。由于帖子信息较少，不能直接断定是模型本身的问题，更常见的是接入层、消息回调、上下文处理或流式输出逻辑出了偏差。
这类问题通常表现为以下几种情况：
- 机器人对一条消息连续回复多次，内容几乎相同。
- 回复内容后半段不断重复前半段。
- 在飞书里看起来像“刷屏”，但接口日志里只有一次请求。
- 每次触发后都会进入循环，直到手动停止服务。
如果你也遇到类似现象，建议先不要急着改模型参数，而是按“消息是否被重复触发”“输出是否被重复拼接”“会话状态是否被错误保留”这三个方向排查。
常见原因
OpenClaw 重复输出，通常不是单一原因造成的，优先怀疑下面几类问题：
- 飞书事件回调被重复触发：消息事件、重试机制或签名校验异常，可能导致同一条消息被处理多次。
- 程序把流式输出重复拼接：如果使用了 streaming 模式，前端或中间层没有正确去重，容易把增量内容累加成重复文本。
- 上下文历史被重复加入：每轮对话都把上一轮内容再次拼接进 prompt，模型就可能“照着重复”。
- 消息去重逻辑缺失：没有按 message_id、event_id 或会话 ID 做幂等处理，导致同一事件被执行多次。
- 提示词中存在循环指令：例如要求模型“重复确认”“完整复述”“持续补充”，在某些模板下会放大重复倾向。
- 代理层或网关重试：本地服务超时、返回慢、连接不稳定时，上游可能自动重试，造成重复响应。
分步解决方案
1. 先确认是不是“请求被重复发送”
第一步不要看输出内容，而是看日志里同一条飞书消息是否被处理了多次。重点检查：
- 同一个消息事件是否出现多次进入处理函数。
- 请求体里的 event_id、message_id、chat_id 是否重复。
- 服务端是否因为超时而被飞书或网关重试。
如果日志显示同一事件被执行多次，优先处理幂等问题。可以在业务层增加去重缓存，例如按消息 ID 记录已处理状态，在短时间内遇到相同 ID 直接丢弃。
判断标准：如果日志里有多次“收到消息”但模型只调用了一次，问题大概率在回调或重试；如果日志里只有一次“收到消息”，但最终回复重复，问题更可能在输出拼接或上下文处理。
2. 检查飞书回调和事件订阅配置
飞书接入场景里，重复输出经常和事件订阅配置有关。建议检查：
- 回调地址是否配置了多个入口，导致同一事件被多个实例消费。
- 是否存在测试环境和生产环境同时监听同一消息。
- 签名校验、时间戳校验是否正确，避免异常请求被当成有效消息处理。
- 服务是否在响应飞书时过慢，触发平台重试。
如果你是多实例部署，先临时只保留一个实例验证，排除“多个进程同时处理同一事件”的情况。
3. 排查流式输出是否被重复拼接
如果 OpenClaw 使用了流式返回，重复输出很可能不是模型“说了两遍”，而是你的接收端把增量片段重复追加了。可以重点检查：
- 每次收到 chunk 时，是否直接 append 到同一个字符串。
- 是否在刷新 UI 或发送飞书消息时，把历史内容和当前增量一起再次发送。
- 是否对同一条流式响应做了多次监听。
建议先切换为非流式模式做一次对照测试。如果非流式正常、流式重复，问题基本就落在流式处理逻辑上。此时要检查“增量更新”和“最终提交”是否分离，避免把同一段内容既实时展示又最终再发一次。
4. 检查上下文拼接和记忆缓存
如果每轮对话都会越来越重复，通常说明历史消息被错误地重复加入 prompt。你可以检查：
- 是否在构造上下文时，把当前用户消息加入了两次。
- 是否把 assistant 的回复又当成 user 输入再次传给模型。
- 是否存在会话缓存未清理，导致旧消息不断叠加。
处理方式通常是先把上下文缩到最小可用配置，只保留最近一轮或最近几轮消息，确认不重复后再逐步恢复记忆能力。这样更容易定位是哪一层把内容加重了。
5. 简化提示词，排除模板循环
如果你的系统提示词、角色提示词或工作流里包含“重复确认”“完整复述”“持续补充”“直到满足条件”等表达，模型可能会在某些场景下不断延展同一内容。建议临时改成最小提示词测试：
你是一个简洁的助手，只回答用户当前问题，不要重复上一轮内容，不要复述系统提示词。如果简化后重复现象明显减轻，说明问题与提示词模板有关。接下来再逐步加回业务规则，找到触发重复的那一段。
6. 检查超时、重试和并发处理
本地部署时，如果模型响应慢、接口超时或网关配置了自动重试，也可能让同一请求被执行多次。建议检查：
- 服务端超时设置是否过短。
- 飞书侧或中间代理是否开启重试。
- 同一会话是否被并发请求同时处理。
如果怀疑是重试导致，先把超时和重试策略调保守一些，再观察日志里是否还会出现重复请求。
如何验证是否修复成功
修复后不要只看一次结果，最好按下面顺序验证：
- 发送一条短消息，确认只触发一次处理日志。
- 连续发送两到三条不同消息，确认每条都只回复一次。
- 观察回复内容是否还会出现“同句重复”或“尾部循环”。
- 如果使用流式输出，再对比流式和非流式两种模式是否一致。
- 查看服务日志中同一 message_id 是否只出现一次。
如果日志、飞书侧展示和模型输出三者都一致，基本可以判断重复输出问题已经被修复。
解决不了时的补充建议
如果按上面的顺序排查后仍然无法定位，建议继续做以下几件事：
- 先停用多实例，只保留单进程运行，排除并发消费问题。
- 关闭流式输出，确认是否是增量拼接导致。
- 把上下文缩到最小，确认是否是历史消息污染。
- 在关键节点打印日志：收到事件、进入模型、收到模型返回、发送飞书消息。
- 对照官方当前推荐的稳定配置逐项恢复，不要一次性叠加太多功能。
如果你愿意进一步定位，最有价值的信息通常是：飞书事件日志、OpenClaw 处理日志、模型请求与返回片段、以及是否启用了流式输出。把这些信息对齐后，通常能很快判断是“重复触发”还是“重复拼接”。
总体来说，OpenClaw 在飞书里重复输出，优先不是怀疑模型能力，而是先查消息幂等、回调重试、流式拼接和上下文重复这四个点。只要把处理链路拆开验证，问题一般都能定位到具体一层。