阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 http://www.iocoder.cn/Fight/dsh-context-insights/ 「芋道源码」欢迎转载，保留摘要，谢谢！

• 它把 Agent 的上下文变成一条能回放的账
• 四个入口，分别在你什么时候想看
• 一条堆叠条，把每一块占了多少摊开
• 能跟上一轮做 diff，也能顺着压缩点往回走
• 装一个插件，但有两道门槛要先过
• 它不是省 token 的工具，是排查工具

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

平时用 DSH 跑长一点的任务，上下文窗口里会不断塞进系统提示、工具 schema、工具返回和各种注入内容。界面通常只告诉我们占用了多少，具体是哪一部分占了，就不太容易看出来。等到压缩发生，再回头找原因，基本只能去翻记录。

dsh-context 主要就是把这些内容展示出来。它是 DeepSeek Harness 的一个第三方开源插件。装上它，一次会话的上下文由什么组成、后来怎么变、什么时候压缩或剪枝，都能直接看。

它把 Agent 的上下文变成一条能回放的账

这句话是全文的骨架。Agent 的上下文为什么天然是黑盒，因为它是拼出来的，系统提示、每个工具的 schema、每轮的用户消息、各种注入内容、助手回复、工具结果，这些东西在每次请求前被重新组装一遍，而界面上只留了一个总量。

黑盒带来的麻烦不是「不知道」，是出事之后没法复现。上下文爆了或者被压缩了，你只能靠回忆去猜哪一步出了问题。

dsh-context 做的事就是把这笔账摊开，而且逐条能往回追。它提供四个查看入口，跨会话的 Context Insights 页面、单个会话里的 Context 标签页、右侧栏的 Context 面板，还有聊天里的 /context 命令。

四个入口，分别在你什么时候想看

跨会话用量看的是 Context Insights 页面。它列出一段时间内所有会话的情况，上面是会话数、计费 token、估算费用、缓存命中率，配最近 7 天的用量柱状图和近几周的活动热力图。

拉到底，每个会话一张卡片，带自己的上下文组成环、token 数、轮次和估算费用，可以按最近时间、token、上下文大小排序，也可以按工作区分组。会话多的时候先看这里，不用一个个点进去找。

费用这块要打个折扣，它是按 models.dev 的目录价估算出来的，虽然把 DeepSeek 的峰谷价也算进去了，但也就是看个大方向。

单个会话的 Context 标签页内容更全。上半部分是轮次、步数、工具调用、缓存命中率、token 去向和时间分配，往下还有当前窗口、趋势、浏览器、事件、文件活动和 Agent 网络六块。

这些数据放在同一页，看的时候不用在几个地方来回切换。token 花在哪、时间耗在模型还是工具上，一页看全。

还有一点值得说，面板头部的占用率和组成，用的是 DSH 官方 token meter 的同一组投影数据，所以和输入框旁边的上下文环对得上。插件和原界面不会各显示一套数字，这件事看着小，但决定了你信哪一组。

一条堆叠条，把每一块占了多少摊开

Current Context 这张卡最直观。它用一条多色堆叠条展示当前上下文窗口，系统提示、工具 schema、用户消息、注入内容、助手回复、工具结果分别占了多少，剩余空间用斜纹表示。

上下文不够用的时候，工具定义和工具结果经常会占掉很大一部分，不一定是你自己输入的内容太多。dsh-context 会把这些分开列出来，还会标出占用最高的工具 schema。插件和工具比较多的会话，可以先看这部分。

这里的分类数字是估算值。 它用的是 DSH 自己的固定密度启发式，不能当成精确测量。钉住某一步之后，面板会把 provider 上报的实际 prompt、output、cache 数字放在估算值旁边。需要准确数字的话，provider 上报的那部分更可靠。

说要精准，这类工具只能官方出手直接调后台，否则一律会有细微差别。作者把这句话写在正文里，而不是藏起来，这点挺难得。

能跟上一轮做 diff，也能顺着压缩点往回走

Context Trend 把每次模型请求画成一根堆叠条，可以切成 Step 或 Turn 粒度，也可以看总量或增量。一轮对话里可能有多次模型调用，每次带进去的上下文都不一样，所以它比只看消息列表更细。

趋势图下面还有一段 step 摘要，写的是用户发了什么、新进入上下文的是什么、模型回复或调用了什么工具。压缩和剪枝会标在对应的柱子上，上下文在哪一步变小、回收了多少，都能看到。切到 Delta 模式后，增长堆在基线上方，压缩往下掉，长会话里发生过几次压缩基本能对上位置。

Context Browser 能打开保留下来的请求，看那次请求实际由哪些内容组成。每个分类都能继续展开，系统提示看原文，工具看 JSON schema，消息看正文，工具结果看参数、状态和返回值，助手回复还能按 Thinking、Tools、Answer 筛选。图片内容以卡片展示，带缩略图、尺寸、存储大小和图像 token 估算。

工具 schema 那一栏会尽量标出工具来源，官方的 tool- 包、dsh- 能力包、某个 MCP server，或者某个插件注册的工具。工具多的时候，这个来源标记能帮你确认每个工具到底来自哪里。

它还能跟上一轮做 diff，哪一类多了几条、多了多少 token，用增减徽标标出来。但压缩前的步骤是从被移除消息的归档里重建的，界面会标「近似」，只能当参考。

往下还有两块。File Activity 按文件列出 Agent 的操作，读过哪些、写过哪些、搜过哪些路径、处理过哪些图片，写操作会估算新增和删除的行数，点开一行能看到完整记录并跳回 Context Browser 里对应的工具结果。比自己翻一整串工具调用方便一些。

Agent Network 展示主 Agent、父级 Agent 和所有子 Agent。每个节点对应一个会话，环的大小按窗口占用缩放，悬停能看 token、请求数、费用和活跃时间，点进去跳到对应会话的 Context 标签页。核验官方 README 时发现还有一条来源没写的，它把这块单独做成了 Fleet 页，主 Agent 与每个子 Agent 各一张实时卡片。

装一个插件，但有两道门槛要先过

安装有两条路。图形界面里打开 Add plugin，搜 dsh-context，点 Install 就行。

命令行是这样。

dsh plugin --profile web add dsh-context

以后更新。

dsh plugin --profile web update dsh-context@latest

装完用 dsh web 启动 Web UI，README 写的是不需要手动构建，也不需要额外重启。

第一道门槛是版本。 作者的兼容矩阵覆盖 @deepseek-ai/dsh 0.1.5-rc.1、0.1.7-rc.2、0.2.0-rc.2 这几条版本线，包本身要求 Node ^22.19.0 或 >=24.0.0。这组版本号是出稿时的口径，而那个仓库发布节奏很快，两天里连发过三个版本，装之前建议自己去仓库对一遍当前的兼容表。还在更旧的 DSH 上的话，先升级。

第二道门槛是安全。 插件是本机跑的第三方代码，装之前最好翻翻源码和依赖，看看仓库还活不活跃。这条提醒不只针对 dsh-context，其他 DSH 插件一样适用。

它不是省 token 的工具，是排查工具

有一点容易读错。README 里用了 management 这个词，但从公开文档看，dsh-context 的主要能力是观测、定位和回看。它不会主动删上下文，也不会替你决定什么时候压缩。

真想省上下文，还是得从工具数量、提示词、注入内容和任务拆分下手。这个插件只负责把账摊开。

所以适用场景也清楚。偶尔用 DSH 聊几句，装不装差别不大；长会话、多工具、多插件、多 Agent 的场景里，它能提供的信息会多一些。作者自己的定位也是把它当排查工具用，它不改模型，也不负责帮你省 token。

这个定位其实挺舒服的。它不承诺帮你优化什么，只承诺真出问题时至少有明细可查。

仓库地址是 https://github.com/bowenliang123/dsh-context 。再交代两句，它是第三方开源插件，不是 DSH 自带功能；另外我没有装过 DSH 环境，上面的功能描述来自官方 README 与来源正文。