#0152 OpenClaw 踩坑记：Kimi 模型工具调用标记泄漏到用户对话

type

Post

status

Published

date

Apr 5, 2026

slug

openclaw-kimi-tool-call-leakage

summary

使用 Kimi 模型的 OpenClaw agent 在 Discord/Telegram 对话中泄漏内部工具调用标记的问题分析与解决方案

问题现象

在使用 OpenClaw 多 agent 系统时，某些接入 Kimi 模型的 agent 在 Discord 或 Telegram 中与用户对话时，会将内部工具调用的原始标记直接暴露给用户。用户看到的消息类似这样：

让我检查当前频道状态：

<|tool_call_argument_begin|>

<|tool_call_end|>

<|tool_calls_section_end|>

这些标记本应在 gateway 层被拦截和解析执行，绝不应该出现在用户可见的对话中。

问题根因

这个问题的本质是 Kimi 模型的工具调用格式与 OpenClaw gateway 的输出处理之间存在断层。

1. Kimi 的工具调用机制

Kimi 模型使用自定义的文本标记（<|tool_calls_section_begin|> 等）来表示工具调用意图。这与 Claude API 原生的结构化 tool_use content block 不同——Claude 的工具调用是通过 JSON 结构返回的，永远不会混入文本流。

而 Kimi 的工具调用标记是嵌入在文本响应中的，这意味着如果 gateway 没有做专门的解析，这些标记就会被当作普通文本原样发送。

2. Gateway 缺少输出过滤

OpenClaw 的 gateway 在将模型响应推送到 Discord/Telegram 之前，没有对 Kimi 特有的工具调用标记做拦截和过滤。响应流程是：

正确的流程应该是：

3. 模型的 "说出来" 行为

有时模型在不确定是否应该调用工具时，会先用自然语言描述意图（如 "让我检查当前频道状态："），然后附上工具调用标记。这种 "先说再做" 的行为进一步加剧了泄漏问题。

解决方案

需要两层防御，prompt 约束 + 代码过滤，缺一不可。

第一层：System Prompt 约束

在 agent 的 system prompt 中加入明确的输出规范：

但 prompt 约束不是 100% 可靠，模型仍可能偶尔违反规则。所以必须配合代码层面的硬过滤。

第二层：Gateway 输出过滤（关键）

在 OpenClaw gateway 发送消息到 Discord/Telegram 之前，加一层正则过滤：

在 gateway 的消息发送路径中插入这个过滤函数：

流式输出场景的特殊处理

如果 gateway 使用流式（streaming）推送，需要做 buffer 检测：

在流式推送到频道前，检测当前 buffer 是否包含 <|tool_ 前缀

如果检测到，暂停推送，继续缓冲直到 <|tool_calls_section_end|> 出现或超时

超时后丢弃未闭合的标记内容

对比：为什么 Claude 不会有这个问题

Claude API 的工具调用是通过 response 中的结构化 tool_use content block 返回的，而不是嵌入在文本中。模型响应的 content 数组中，text 类型的 block 永远不会包含工具调用指令，工具调用是独立的 tool_use 类型 block。这种设计从架构层面杜绝了标记泄漏的可能。

而 Kimi 使用文本内嵌标记的方式，将工具调用和自然语言混在同一个文本流中，需要调用方自行解析和分离，增加了泄漏风险。

总结

维度	说明
问题	Kimi 模型的工具调用标记泄漏到用户对话
根因	Kimi 使用文本内嵌标记 + Gateway 未做过滤
修复	System Prompt 约束 + Gateway 正则过滤（双保险）
预防	对接新模型时，始终在 gateway 层加模型特定的输出过滤

每次接入新的 LLM 模型到 OpenClaw 时，都应该先了解该模型的工具调用格式，并在 gateway 层加入对应的过滤逻辑。这是多模型架构下的必修课。

🔧#0152 OpenClaw 踩坑记：Kimi 模型工具调用标记泄漏到用户对话