dsh-glm-mode

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

license

安装

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 输入，截图直接看。

全部配置项（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。