dsh-glm-mode
GLM Mode：为 DeepSeek Harness 中的 zhipuai/glm-5.3-flash 完全调优的编码代理预设——PTC/Code Mode 工具呈现、GLM 专用自动压缩（75%/22%）、原生多模态，以及防护机制组（推理循环防护 + 工具空转防护）。该预设会随插件一起安装和卸载。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:hoyyang/dsh-glm-mode#81d0cfc857ead5863d1f2ed55f4fe97277db6f01Glm Mode 以 dsh-glm-mode 发布，当前版本为 0.4.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →「GLM 模式」：为 zhipuai/glm-5.3-flash 调优的 DSH 编码 Agent 预设——装上即得 PTC 程序化工具调用、GLM 专属自动压缩，外加思考死循环守卫与工具空转守卫双层防护。
dsh plugin add dsh-glm-mode
（npm 包名独享；也可用 GitHub 源：dsh plugin add hoyyang/dsh-glm-mode）
零配置可用（全部开关默认开启）。新会话在预设选择器里选「GLM 模式」，模型选 zhipuai/glm-5.3-flash 即可。
dsh plugin add dsh-glm-modezhipuai/glm-5.3-flash全部配置项（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 消息——尾部追加不动请求前缀，前缀缓存仅失配增量。scripts/selftest-loop-guard.mjs：截断语法合规、路由矩阵、武装阈值防误伤、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。