第 15 卷

Promise，必须 await

速——A/B 测试要用全新 prompt

7端口占用dsh web 起不来netstat -ano \findstr 3080 找 PID kill

serializeAssistant 里 toolCalls.length

> 0 && reasoning.length

> 0 条件把空的 reasoning 字段省

略 → 下一轮请求报 400（invalid pi-ai

replay state）

6.5 评测视角：官方成绩单 vs 独立实测

（结合 0813 正式版发布）看 Agent 模型成绩单要三问：

1. **谁测的**？官方自测（自家 Harness）vs 独立第三方（AA 等）
2. **什么 harness**？框架不同分数差很大（官方 Terminal-Bench 87.9 vs AA 独立

79）

1. **验证器多严**？宽松验证器（SWE-bench Verified 8.5% 假阳性）vs 严格

（DeepSWE 0.3%）

dsh 的 `agent/request` waterfall 让模型跑分可复现——这是它相比闭源产品的工程优势。

6.6 缓存策略：让每次调用都更便宜

第 5 章讲了高缓存命中率的价值（实测会话缓存命中率 97%；缓存折扣 Flash 档 98% / Pro 档 99%+），这里给出**可操作策略**：

目标做法

提高命中长任务保持会话延续（避免频繁新建会话）

提高命中系统提示/技能目录等前缀保持稳定（不要频繁改配置）

提高命中批量任务放同一会话/同前缀（如同一批文件分析）

降低成本简单轮次用 low 档（思考 token 减少 → 总 token 下降）

监控会话统计行看"缓存命中 %"（Web UI 底部）——低于预期就检查前缀

稳定性

**成本模型速记**：`总成本 ≈ 输出token×输出价 + 输入未命中×未命中价 + 输入命中×命中价`——Agent 工作负载输入占比高，**缓存命中率是成本的第一变量**。

---

动手练习（检验你是否真懂了）

1. **理解题**：不看原文，说出 dsh 任务耗时的三个组成部分及各自占比。为什么"优化

思考时间"是性价比最高的提速手段？

> 自查：参考本章 6.1 节耗时分布表格

1. **理解题**：解释 `low` / `high` / `max` 三个推理档位分别适合什么场景。如果一个

任务"需要读 10 个文件然后做简单汇总"，应该用哪个档位？

> 自查：参考本章 6.2 节三档策略表格

1. **动手题**：打开 `dsh web`，跑一个"创建 3 个文件"的任务，观察 Web UI 底部的

统计行（LLM Xs / 工具调用 Ys），记录数据并分析瓶颈在哪 > 自查：参考本章 6.3 节"耗时可视化"段落

1. **动手题**：把 `~/.dsh/settings.yaml` 的 `reasoningEffort` 从 `high` 改为 `low`，

跑同一个简单任务，对比耗时差异。再改回 `high`，跑一个复杂推理任务，对比差异 > 自查：参考本章 6.2 节"手动"段落

1. **动手题**：模拟"端口占用"坑（先起一个服务占 3080 端口），用 `netstat -ano |

findstr 3080` 找到 PID 并 kill，然后正常启动 `dsh web` > 自查：参考本章 6.4 节坑 #7

1. **思考题**：本章 6.5 节说"评测要三问：谁测的、什么 harness、验证器多严"。请用

一个具体例子解释：同一个模型，在不同 harness 下跑分为什么会差很多？

> 自查：参考本章 6.5 节"官方 Terminal-Bench 87.9 vs AA 独立 79"的例子

常见疑问 FAQ

**Q1：为什么我的 dsh "有时候特别快，有时候特别慢"？**

两个主要原因：① DeepSeek context cache 命中时，首轮上下文注入会快很多（1s vs 110s 的差异可能来自这里）；② 推理档位不同，思考时间差几倍。做 A/B 对比测试时，要

用全新 prompt（避免缓存命中）+ 固定档位。

**Q2：示例提速插件真的能提速多少？有没有实测数据？**

提速收益取决于任务类型。简单任务（1-3 步）dsh 本来就快，插件效果不明显。**长工具链任务（20-50 步）收益最大**，因为每步思考降档的累计效果显著。具体数据参考第 4 章示

例代码的实测日志。

**Q3：我把推理档位设为 `low`，模型质量会下降很多吗？**

取决于任务。简单文件操作、批量处理、确定性任务用 `low` 质量几乎无差别。复杂推理、长链规划、debug 用 `low` 可能漏掉关键步骤。建议：日常用 `high`，批量/简单任务手动切

`low` 或用提速插件自动降档。

**Q4：坑 #6 说的"context cache 命中"是什么？怎么判断是否命中？**

DeepSeek API 会对重复/相似的上下文做缓存，命中时首 token 时间大幅缩短。判断方法：

看 dsh 会话日志里的"首 token 平均"指标，如果某次突然从 10s+ 降到 1s 以下，大概率命中了缓存。做性能对比测试时，用全新 prompt 避免缓存干扰。

**Q5：rc 阶段的破坏性变更会影响性能吗？升级后需要注意什么？**

可能影响。rc 阶段的 agent-loop、waterfall 签名、插件 API 都可能变。升级后：① 跑一遍 `dsh --version` 确认版本；② 看官方 changelog 有没有 breaking changes；③ 跑一个你

熟悉的任务对比耗时和行为；④ 自定义插件检查类型兼容性。

**Q6：我想做性能基准测试（benchmark），有什么建议？**

三个原则：① 固定环境（同模型、同网络、同档位）；② 用全新 prompt 避免缓存；③ 多次运行取中位数（单次波动大）。记录：墙钟时间、LLM 耗时、工具调用耗时、首 token 时

间。参考本章 6.1 节的耗时分布模型设计你的 benchmark。

---

**下一章**：[第 7 章：生态与资源](./07-ecosystem.md) —— 加入 dsh 生态的完整地图。