dsh-glm-mode

「GLM 模式」：为 zhipuai/glm-5.3-flash 调优的 DSH 编码 Agent 预设——装上即得 PTC 程序化工具调用、GLM 专属自动压缩，外加思考死循环守卫与工具空转守卫双层防护。

English · Releases · 更新日志

安装

dsh plugin add hoyyang/dsh-glm-mode

零配置可用（全部开关默认开启）。新会话在预设选择器里选「GLM 模式」，模型选 zhipuai/glm-5.3-flash 即可。

有啥用

• PTC 程序化工具调用：全量工具目录以 Code Mode 呈现，一个 TypeScript 程序组合多步操作，减少往返轮次与 input token（同条件 A/B 实测 input −15%）。
• 思考死循环守卫：GLM-5.3-flash 在高推理档位下有 long-decode 退化缺陷（vLLM #56868 同款报告）——实测曾出现单步纯思考 131,072 token、同一句循环约 2,500 次、29.5 分钟烧满上限。守卫对流做句子级重复检测，提前截断并复用「输出 token 上限」链路，发「继续」即续跑。
• 工具空转守卫：PTC 模式下模型可能幻觉出「顶层 write 工具」并连发占位调用（实测事故连发 37 次、最长连续 23 步空转）。守卫识别空转后经官方通道注入一条纠偏消息，把模型拉回正轨——事后纠偏、不截断正常流。
• GLM 专属自动压缩：1M 上下文按 75% 阈值 / 22% 保留自动压缩，压缩后原地摘要无缝续跑；未选 GLM 预设的 GLM 会话也有溢出级兜底。
• 原生多模态：预设声明 text+image 输入，截图直接看。

30 秒上手

1. dsh plugin add hoyyang/dsh-glm-mode
2. 重启 DSH（或热重载）
3. 新会话 → 预设选「GLM 模式」
4. 模型选 zhipuai/glm-5.3-flash
5. 正常干活——守卫在后台静默工作，无需任何操作

进阶用法

全部配置项（cordis.patch.yml，默认即推荐值）：

| 键 | 默认 | 说明 | |---|---|---| | compactEnabled | true | 自动压缩开关（false 保留手动 /compact） | | glmThresholdRatio | 0.75 | GLM 会话压缩阈值 | | glmRetainRatio | 0.22 | 压缩后保留占比 | | otherThresholdRatio | 0.98 | 非 GLM 模型兜底阈值 | | glmPresetEnabled | true | 随插件安装/卸载 GLM 模式预设 | | loopGuardEnabled | true | 思考死循环守卫开关 | | loopGuardRepeatThreshold | 8 | 同一句子连续重复 N 次即判定死循环 | | loopGuardMinSentenceChars | 48 | 参与比对的句子最小长度（字符） | | loopGuardMinReasoningChars | 2000 | 累计 reasoning 字符达到后才武装判定 | | spinGuardEnabled | true | 工具空转守卫开关 | | spinGuardStreakThreshold | 5 | 连续占位 run_code 达 N 次即注入纠偏 | | spinGuardMaxCodeChars | 200 | 占位判定的 code 长度上限（≥ 视为有实质内容） | | spinGuardWindowMs | 900000 | 距最近占位超过该毫秒数视为断流（不干预） |

守卫触发对账：~/.dsh/dsh-glm-mode/guard-events.jsonl（JSONL 只增流水，kind 字段区分 reasoning-loop / tool-spin）。

工作原理

• 呈现层：agent-presentation mode: ptc 把全量工具目录收进一个 run_code 工具，模型写 TypeScript 程序、运行时桥接调用真实工具。
• 思考守卫：llm/stream 瀑布包装 chunk 流（仅 zhipuai glm-* 路由），reasoning 增量做数字归一化的句子重复比对，触发即合成 finish{max-tokens} 并硬取消上游请求。
• 空转守卫：llm/stream 检测每步工具调用（占位 = run_code 且无 tools.* 实质引用且 code 短）；达阈值后经 agent/pre-step 官方决策通道向消息尾部注入一条纠偏 user 消息——尾部追加不动请求前缀，前缀缓存仅失配增量。
• 压缩：预设内自带隔离压缩 owner（官方 "nearest owner wins" 语义），与 dsh-kiro 等宿主引擎确定性共存。

可靠性与验收

• 合成流自测 52/52（scripts/selftest-loop-guard.mjs：截断语法合规、路由矩阵、武装阈值防误伤、fail-open、注入/清零/零感知矩阵、断流窗口、账本防线）
• 冷启动静态检测 boot-check [A]–[E] 全绿；卸载重装幂等（真卸→重装→预设目录恢复）
• headless 全新进程真模型冒烟通过；守卫对正常流零干扰
• 两守卫均 fail-open：内部错误放行原始流 + 显式日志，绝不弄挂流水线

常见问题

只对 GLM 模型生效吗？ 是。两个守卫与压缩策略都按路由（zhipuai glm-*）判定，其他模型零感知零开销。

会误伤正常回答吗？ 思考守卫有武装阈值（≥2000 reasoning 字符后才开始判定）与最小句长（≥48 字符）双重防误伤；空转守卫误判的代价仅是一条纠偏消息，不会截断任何流。

和直接用 Kiro 模式有什么区别？ Kiro 模式面向 DeepSeek 系模型调优；本插件为 GLM-5.3-flash 提供专属预设（PTC + 1M 压缩阈值 0.75/0.22）与守卫家族，两者可共存，压缩 owner 按官方语义确定性让位。

wire 层配置（thinking 格式 / tool_stream）在哪？ 部署于 settings.yaml 的 provider 路由层（z.ai 官方推荐格式），不在本插件内，装完即用。

本地构建

pnpm install
npm run build      # tsc 编译 + npm pack 产出 tgz
npm run selftest   # 52 项合成流自测

许可证

MIT —— 详见 LICENSE。