它是什么
DSH Context 回答的是每个长会话迟早都会提出的问题：此刻窗口里究竟装了什么、这些东西从哪来、又是怎么一步步积起来的。它为每个会话加了一个「Context」标签页，另有一块内容相同的右侧栏面板，以及一条 /context 命令，三者读的是同一份数据。
有一处区别比任何一张卡片都重要：它只观测，不管理。 README 把它称作「full context lifecycle management」，package.json 的描述里也写着「context insight and management」——但两份来源都没有任何一处说明它会修改、裁剪、压缩或清理上下文窗口，也没有说它会改写提示词或改变模型行为。这里的「management」应当按 README 的宽泛措辞来读，而不是当成源码里真有这么一套机制。
三个入口
- Context 标签页 —— 完整的仪表盘，每个会话都能打开：统计、构成、逐请求趋势、事件、文件活动与 agent 网络。
- Context 面板 —— 同一块仪表盘作为右侧栏标签页，需要 harness
0.1.5-rc.1及以上。在侧栏引导页选中 Context，面板就会在对话旁边展开。 /context命令 —— 一个居中弹窗，内含当前构成卡片与上下文浏览器，不必离开对话即可查看。- 设置 → 插件 → 插件配置 保存每用户默认值：趋势粒度（Step / Turn）、趋势模式（Total / Delta）以及文件活动排序。图表内的临时开关只作用于当前视图，不会覆盖已保存的偏好。
各张卡片分别看什么
- Context Stats —— 轮次、步数、人工输入、进行中的工具调用、会话缓存命中率，以及按 models.dev 目录价估算的费用，并区分 DeepSeek 的峰谷价。
- Token Stats —— 计费 token 的去向，按构成拆分（系统、工具、消息等），最后用 provider 给出的精确输出量收口。
- Timing —— 活跃时间如何分摊到模型调用、工具运行与开销上。
- Current Context —— 此刻窗口里的内容，用六色堆叠条对照模型完整窗口展示，斜纹表示剩余余量。
- Context Trend —— 每个模型请求一根堆叠条，配一段大白话的 step 摘要；压缩与清理的发生位置钉在对应的那根条上；悬停或点击可钉住完整拆解。
- Context Browser —— 任一保留请求究竟由什么组装而成：六个可折叠类别可逐层展开到真实的提示词文本、工具 JSON schema、消息内容、推理过程、工具参数与工具输出。
- Context Events —— 每一次注入、压缩、清理、模型切换与 plan 模式开关，标注产出方、净 token 变化、轮次/步数与时间。
- File Activity —— 每个被触及的文件一行，含读/写/搜索/图片计数、估算的行变更量，并可点击跳转到对应的工具结果。
- Agent Network —— 当前 agent、其父级与全部子 agent 画在同一张图上，每个环按该会话的窗口占用缩放。
是估算值，不是测量值
这是诚实理解这个插件的核心，卡片界面本身也是围绕它设计的：
- 类别拆解使用 dsh 自带的固定密度启发式，与内置 token meter 用的是同一套。
- 头部占用率来自官方 token meter 的投影（
contextPressure/contextBreakdown），因此数字与输入框上方那个上下文环始终一致。 - 趋势卡片会把 provider 上报的实测值——Actual Prompt / Output / Cache——摆在估算值旁边，而不是取而代之。
- 文件活动里的行变更量是估算的，工具来源标签也是尽力而为。早于某次压缩的步数是从「被移除消息归档」里重建出来的，卡片自己会标明该步的构成只是近似。
请把每个数字都当成有依据的近似值，只有 provider 上报的字段才是精确的。
运行要求
- Node 需满足
^22.19.0 || >=24.0.0，来自包的engines字段。 - Harness —— README 称可在
@deepseek-ai/dsh0.1.2-rc.1及以后运行，跨越若干代会话日志格式；而清单更严格：它只把三个版本标为兼容，分别是0.1.2-rc.1、0.1.3-alpha.2与0.1.5-rc.1。不要假定它在这个列表之外也兼容。 - README 指向一份
docs/compatibility.md逐版本矩阵，该文件不在本次来源之列，因此无法概述其内容。 - 运行依赖很薄：只有
zod一个。React 与 UI 原语被声明为可选的 peer 依赖。 - 包内有一个
dsh字段，声明了一个bundlepatch（Cordis 组装补丁）以及一个 web 客户端，注入六个客户端包。客户端平台声明为web，没有描述 headless 或纯 CLI 模式。 - README 没有说明权限模型、文件读写行为、网络访问或遥测。请按「未说明」来理解，而不是按「安全」来理解。
已知限制
- 它无法改动窗口，因此也没法拯救一个正在被填满的会话；读卡片就是它的全部能力。
- 费用按目录价估算，不等于账单；来源也没有声称它能降低开销。
- 它不提供精确的 token 或上下文测量，估算值与 provider 实测值可能不一致。
- 压缩之后的重建被明确标注为近似。
- 右侧栏面板以及它打开的图片/文件预览需要 harness
0.1.5-rc.1及以上；在更旧的 harness 上，文件名会在你的系统里打开。 - README 带有星标徽章并请你点星，但本次来源无法核实任何星数，因此这里不引用任何数字。
什么时候用它、什么时候不要用
当会话已经很长、你需要知道空间被谁占走时，或者你在排查某段提示词为什么长成那样时，用它。上下文浏览器是最没有替代品的部分：它能让你读到某个具体请求实际由哪些系统提示词、工具 schema 与工具输出组装而成。文件活动与 agent 网络本身也很有用，可用于审计 agent 做过什么、子 agent 树是什么形状。
不要抱着「它能管理、裁剪或压缩」的预期去装它。如果你想让窗口变小，这个插件只会把问题指给你看，然后到此为止——改动窗口超出两份来源所描述的一切。同样，在需要精确数字的场合，别把它的数字当测量值用：那种场合请看 provider 上报的实测值，其余的都只当作参考。
FAQ
DSH Context 会管理或优化我的上下文窗口吗？
不会，至少来源没有描述任何这类行为。它读取并展示上下文数据。README 与包清单都没有说它会修改、裁剪、压缩或清理窗口，也没有说它会改写提示词或改变模型行为。「management」这个词只出现在 README 的标语和包的描述里，其背后没有任何已记录的机制。
那些 token 数字精确吗？
大多不精确。类别拆解使用 dsh 自带的固定密度启发式，占用率来自官方 token meter 的投影，文件行变更量是估算的，工具来源标签是尽力而为。钉住的趋势详情会把 provider 上报的 Actual Prompt / Output / Cache 摆在估算值旁边；Token Stats 卡片则把估算的构成占比与 provider 精确的计费总量配对展示。早于某次压缩的步数从被移除消息归档重建，并标注为近似。
支持哪些 harness 版本？
README 说 0.1.2-rc.1 及以后。包清单更具体，只列出三个兼容版本：0.1.2-rc.1、0.1.3-alpha.2 与 0.1.5-rc.1。超出这个列表的兼容性，两份来源都没有给出结论；README 链接的兼容性文档在本次来源中也不可得。
它需要 React 和 harness 的 UI 包吗？
要用它的 Web 界面就需要——客户端注入了六个客户端包——五个 @deepseek-ai/dsh-client-* 包，外加 @deepseek-ai/dsh-api-remotes，React 与 UI 原语被声明为 peer 依赖。这两个 peer 都被标为可选，在依赖客户端那一半渲染之前，这一点值得弄清。真正普通的运行依赖只有 zod。
能在 headless 或纯 CLI 环境里用吗？
来源没有描述这样的用法。清单把客户端平台声明为 web，而它记录的每一个入口——Context 标签页、右侧栏面板、/context 弹窗与设置卡片——都是浏览器界面。