DSH 的 token 花在哪了？装个 dsh-context，上下文、花费、延迟全摊开

DSH 用多了，总想知道 token 到底花在哪儿了。也想知道每次觉得「怎么这么慢」，到底慢在哪一步。

今天翻到一个插件 dsh-context，太贴合这个需求了。装上之后打开，上下文被什么撑满的、钱花在哪、时间卡在哪个环节，全摊开摆在你面前，还能按每一次请求一步步往前翻。

安装方式

桌面版最省事：侧边栏点开「插件」，在添加插件的搜索框里填 dsh-context，点安装。装完刷新一下页面，不用重启。

习惯敲命令的话：

dsh plugin --profile desktop add dsh-context

备注：如果你用的是 Web 版，把 --profile 后面的 desktop 换成 web 即可。

dsh-context 的四个入口

装完你会发现它不是一个页面，而是四个入口，数据是同一套：

1. 上下文洞察：侧边栏的一级入口，和「插件」「自动化任务」同一层。看的是全部会话的跨会话总览
2. 上下文标签页：进任意会话后，对话区上方的标签页。单个会话的完整仪表盘，日常用得最多的是这个
3. 上下文面板：右侧栏。同样是会话级数据，好处是能一边看对话一边看
4. /context：聊天框里直接敲，弹一个居中窗口，不用切标签页

token 用在什么地方

打开上下文标签页，第一张卡就把这一包拆开了。

七块：系统提示词、工具定义、用户消息、注入内容、技能注入、助手消息、工具结果。每块占多少，一眼看清。

两个容易看错的地方，提醒一下：

1. 条子右侧的斜纹不是剩余空间，是自动压缩预留。DSH 默认在占用到窗口 80% 时触发压缩，这段是缓冲。真正的空闲在更右边，不带斜纹

2. 工具定义常常是隐形大头。你装的每个插件都要把工具说明书塞进上下文，装得越多这一块越厚。我第一次看才发现，我的系统提示词加工具定义就占了将近一半

想看钱的话，Token 统计卡把整个会话的计费 token 按构成拆开，角上标着缓存命中率；费用在上下文统计卡上，按 models.dev 挂牌价估算，悬停价格旁的 ? 能看到每一档的每百万 token 单价。

延迟卡在什么地方

耗时统计卡把整步时长拆成六项：模型等待（TTFT）、模型思考、模型输出、工具参数、工具执行、其他开销。底下还有一条时间轴，各段宽度就是耗时占比。

看两次就能定位瓶颈：

• 工具执行占比高：说明慢在命令本身，不在模型。那种一跑几分钟的测试、扫描，就是这里
• 模型等待占比高：接口响应慢，跟你的提示词怎么写没关系

顺带一提，这张卡量的是整步时长，你等授权、答题磨蹭掉的时间会落进「其他开销」。真正扣掉等待的是趋势图上那条耗时曲线。

怎么省 Token

这块才是重点。下面几条是我自己装上之后实际改的，按见效程度排。

1. 卸掉用不上的插件。 每个插件都往上下文里塞工具定义，而且不是付一次就完——你这一轮里每次请求都要重新带上它，等于反复计费。装插件之前先问一句：这个会话真的用得上吗。我卸掉几个装了两周没打开的，新会话立刻轻一截。

2. 上下文快满了就换新会话。 压缩是丢信息的操作。压缩之后模型容易重复读同一个文件、重复改同一处，这些重复劳动全都要再花一遍 token。任务切换时主动开新会话，比让它硬扛到压缩划算得多。

3. 别让它一次读一大坨。 grep 命中几百行、整份日志丢进去，这些结果会一直留在上下文里，往后每次请求都跟着计费。让它限定行数、把搜索写得更精确，或者先看结构再定点读。

4. 会话中途别折腾前缀。 缓存输入比未缓存便宜得多，而缓存是按前缀命中的。同一个会话里换模型、加减插件，都会改动请求的前半段，让已建立的缓存失效，命中率当场掉下来。要动这些，开新会话再动。

5. 盯住缓存命中率。 就是 Token 统计卡角上那个数。同样的活，命中率高和低能差出好几倍——这一项的杠杆比「少问几句」大得多，值得优先优化。

6. 留意子智能体。 费用是含所有层级子智能体的，挂一支队伍跑长任务，它那一整支的开销都算在你头上。派活之前先掂量一下值不值。

用趋势图和上下文事件配合着看效果最快：压缩事件少了、缓存命中率上去了，说明你改对了。反过来，如果上下文事件里「压缩」三天两头就出现一条，那就是这个会话塞得太多，该拆了。

顺手提一句

插件在 npm 上叫 dsh-context，Apache-2.0 协议，仓库在 https://github.com/bowenliang123/dsh-context

它不碰你的代码和项目配置，只读会话记录；会写东西的只有它自己的界面偏好。

DSH 插件这个系列我会接着写，关注一下，新文直接推到你订阅里。