DeepSeek / Kimi / GLM‑5.1 状态机与工具链稳定性分析

1. DeepSeek V4 Pro 状态机缺陷（核心问题）

1.1 缺陷表现

DeepSeek V4 Pro 在私有部署中会出现：

工具调用后返回空响应
工具历史 + 当前无工具 → 卡死
工具结果大 → 注意力崩溃
多轮工具链路 → 直接停止生成

这些问题在 Hermes / Cursor / Claude Code 中尤为明显。

1.2 内部机制（状态机分支概率塌陷）

工具调用后的内部状态机分支如下：

工具调用完成 → 模型需要决定下一步生成什么：
- A：自然语言总结
- B：继续工具调用
- C：结束/空输出

DeepSeek 的问题：

P(总结) 弱（被工具结果淹没）
P(继续工具) 被 tools=[] 禁止
P(结束/空) 异常偏高

→ 最终走到空输出分支

1.3 为什么上下文调到 256K 也没用？

因为问题不是“上下文不够”，而是：

上下文越大，注意力越容易被工具结果淹没 → 状态机更容易崩。

2. DeepSeek 官方 API 为什么稳定？

DeepSeek 官方 API 的稳定性来自 7 层工程补丁：

补丁	作用
自动 Retry	空响应自动重试 3～8 次
自动 JSON 修复	修补半截 JSON、缺字段
工具后自动 fallback	工具历史 + 无工具 → 强制总结
自动截断上下文	避免注意力被工具结果淹没
自动摘要工具结果	工具结果太大时自动压缩
自动禁用工具（retry 时）	避免再次触发工具状态机
自动修补状态机	强制引导“工具 → 总结”链路

私有部署没有这些补丁 → 暴露模型真实缺陷。

3. Kimi / GLM‑5.1 是否有类似缺陷？

3.1 Kimi（Moonshot）

不会出现 DeepSeek 那种空响应问题
工具调用后强制进入“总结模式”
工具结果大 → 自动摘要
工具历史 + 无工具 → 自动 fallback

→ 国产模型中最稳定的 Agent 状态机

3.2 GLM‑5.1

不会空响应
不会卡死
工具调用倾向偏高（over‑tooling）
偶发 JSON 格式问题

→ 稳定但偏积极工具调用

4. 三者状态机差异对比表（最终版）

模型	工具调用稳定性	工具后空响应	状态机内部机制	官方 API 稳定原因	私有模型表现	Hermes 表现	Claude Code	Cursor
DeepSeek V4 Pro	⚠ 不稳定	❌ 高概率	分支概率塌陷	7 层补丁兜底	❌ 最不稳定	❌ 最容易崩	⚠ 不稳定	⚠ 不稳定
Kimi	⭐ 稳定	⭐ 不会	强制总结	内置强制总结 + 摘要	⭐ 非常稳定	⭐ 最稳	⭐ 稳定	⭐ 稳定
GLM‑5.1	⭐ 稳定	⭐ 不会	过度工具化	轻量 JSON 修复	⭐ 稳定	⚠ 稳但过度工具	⭐ 稳定	⭐ 稳定

5. 为什么 Claude Code / Cursor 看起来“能修复空响应”？

它们修复的是：

IDE 任务链路的空结果（自动 continue / retry / diff 修复）

它们不能修复：

模型内部状态机的空响应

所以：

GPT / Claude / Kimi → 偶发空 → IDE 能兜住
DeepSeek → 结构性空 → IDE 兜不住

6. Hermes 为什么最容易暴露 DeepSeek 的缺陷？

因为 Hermes 会触发 DeepSeek 的死亡区间：

工具调用
工具结果
工具历史 + 当前无工具
多轮链路

→ DeepSeek 状态机最容易崩的地方

7. 最终模型选型建议

场景	推荐模型
最稳定（国产）	Kimi
稳定但工具调用偏多	GLM‑5.1
不建议（除非大量补丁）	DeepSeek V4 Pro

DeepSeek V4 Pro状态机问题