← 返回列表
✓ 可直接安装
「GLM 模式」：为 zhipuai/glm-5.3-flash 调优的 DSH 编码 Agent 预设——装上即得…
自动检查通过：npm 包已发布且 engines 声明满足基线；该结论来自程序自动检查，未经人工实机验证。 · 最近上游提交 2026/9/18 · 已提供中文文档
GLM 模式：为 DeepSeek Harness 中的 zhipuai/glm-5.3-flash 全面调优的编码智能体预设——PTC 演示、guard 系列、隔离式压缩
综合分
30.2
GitHub 分
30.2
用户评分
—
★ Stars
1
周下载量
—
安装插件（需先安装 dsh CLI 引擎：npm install -g @deepseek-ai/dsh）
dsh plugin --profile web add dsh-glm-modenpm 包 dsh-glm-mode 已校验归属本仓库，走 npm 安装最省事
信任档位：已验证本站已于 1 天前真实安装成功
- 是什么
- dsh 原生插件 · chat
- 装得上吗
- 本站已真实安装成功（非静态推断）
- 安全吗
- 本站尚未对该插件做风险分级（暂未覆盖，不等同于无风险）
- 还在维护吗
- 活跃：最近一次提交在 7 天前
档位由下列信号合成：本站实装验证（真实安装，当前最高到 L4）· 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。下方各区块是它的证据明细。 验证判据与等级说明 →
🟢实装验证通过· 2026/9/24
由本站实装验证器在真实 dsh 环境安装成功，非静态推断。
数据截至 2026/9/23（元数据每日更新 · 实装验证按队列轮转，单条结论的验证时间见上方）
安装兼容性检查✓ 自动检查通过
以下结论由程序自动检查 npm 包、engines 声明与入口文件得出，未做人工实机验证——能装不等于用着没问题。
✓npm 包dsh-glm-mode @ 0.4.0
✓Node 引擎未声明 engines.node
✓dsh CLI 依赖未声明 dsh 版本约束
✓入口文件main/exports/bin 已声明
验证方式：npm registry 存在性 + package.json 静态校验 · 最后验证 2026/9/23 21:25:51
依赖的 DSH / Cordis 模块
@deepseek-ai/dsh-compaction-basic@deepseek-ai/dsh-compaction-tool-result-pruner@deepseek-ai/schemastery用户评分
还没有人投票，来当第一个
订阅周报，不错过优质插件更新
每周一封 · 高评分插件 + 新用户活动
README
由 DeepSeek 最新模型翻译生成dsh-glm-mode
banner
「GLM 模式」：为 zhipuai/glm-5.3-flash 调优的 DSH 编码 Agent 预设——装上即得 PTC 程序化工具调用、GLM 专属自动压缩，外加思考死循环守卫与工具空转守卫双层防护。
English · Releases · 更新日志
安装
dsh plugin add dsh-glm-mode
（npm 包名独享；也可用 GitHub 源：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 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。