#Kimi K2p5 Tool-Call Regression: Broken in 3.7+, Stuck on 2026.3.2 Legacy

1 messages · Page 1 of 1 (latest)

quasi roverBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

past nightBOT
#

标题（建议）

  • 中文：“Kimi K2p5 在 OpenClaw 2026.3.7+ 工具调用回归（2026.3.2 正常）”
  • English: “Regression: Kimi k2p5 tool calling broken in OpenClaw ≥2026.3.7 (works on 2026.3.2)”

责任在 OpenClaw 还是 Moonshot？
更准确的说法：边界问题，责任是“共同的”，但就你描述的“版本回退可恢复”来看，主要落在 OpenClaw 这边需要修回归/做兼容。

  • 如果 同一个 Kimi 模型/同一把 API key，在 2026.3.2 能正常出结构化 tool call，但 2026.3.7+ 开始变成输出 exec({...}) 这种“文字版假工具调用”，这通常意味着 OpenClaw 的请求整形（prompt/tool schema/兼容层）或响应解析在新版本变了，触发了 Kimi 的不兼容 → 这是 OpenClaw 的集成回归。
  • 同时，Moonshot/Kimi 也确实有责任：模型/API 如果对工具调用的遵循度不稳定（容易“把工具调用当文本说出来”），那任何上层框架都会比较脆弱。Moonshot 需要提升 tool-calling 的一致性/兼容标准。

你这条现象和这个已开的回归 issue 描述几乎一致（2026.3.7 后 Kimi 会直接把 exec(...) 当普通文本吐出来）：
https://github.com/openclaw/openclaw/issues/39907

接下来最能推动修复的动作
如果你愿意帮推进修复，在上述 issue 里补充两类证据最有用：

  1. 同一条请求在 2026.3.2 vs 2026.3.7+ 的对比（尤其是网关日志里模型原始回复片段）
  2. 你用的具体模型标识（kimi-coding/k2p5 等）、运行环境、复现频率（稳定复现 or 间歇性）