ARTICLE · 1194695

DeepSeek 这个插件有点狠!

发布时间：2026-10-16 19:48:18 最近访问：2026-10-16 19:48:20

DeepSeek 这个插件有点狠!

点击上方程序员成长指北，关注公众号

回复1，加入AI Coding 群

用 DeepSeek Harness 跑任务时，有一个数字很容易让人困惑：明明只输入了一小段需求，上下文怎么已经占了这么多？

任务执行久了，这种困惑会更具体。是读进来的文件太大，还是命令输出太长？装的工具和技能有没有占空间？要精简配置，又该从哪里下手？输入框旁边的占用百分比能提醒你窗口用了多少，但要回答这些问题，还得把里面的内容展开。

dsh-context https://github.com/bowenliang123/dsh-context 就是为这件事做的第三方开源插件。它给 DeepSeek Harness 增加了上下文组成、逐请求趋势、注入事件和工具调用的查看入口，让我们能沿着一次任务的执行过程，找到内容从哪里进入、在哪一步开始变多。

Tianyi Cui 在 X 上推荐它 https://x.com/tianyi/status/2105256532657267119时，用的是“功能很丰富的 DSH 上下文管理插件”这个描述。对日常写代码的人来说，最值得上手的部分，是把“上下文好像太大了”变成一个可以逐项核查的问题。

先装好，打开一条已有任务

在 DeepSeek Harness 桌面版或网页版中，进入 Plugins / 插件 → Add plugin / 添加插件，输入包名 dsh-context，点击安装，并按界面提示启用。

在 Add plugin 窗口中输入 dsh-context 并安装

*图 1：项目仓库提供的安装窗口示例，输入的是 npm 包名 dsh-context。*

使用 CLI 管理 Web 配置的读者，可以按项目 README 给出的方式安装：

dsh plugin --profile web add dsh-context

更新对应配置中的插件：

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

这里的 --profile web 指向 Web 配置。桌面端直接使用插件界面即可。项目兼容性矩阵明确列出的 DSH 版本是 0.1.7-rc.2 和 0.2.0-rc.2；其他版本应查看仓库最新说明，不宜仅凭版本号更大就认定已验证兼容。

启用后，先打开一条有执行记录的会话，找到 Context / 上下文 标签页。只想快速看一眼，也可以在对话框输入 /context，通过命令菜单打开包含当前组成和上下文浏览器的弹窗。

第一次用，建议先看当前上下文，再看趋势图，最后展开某一步的具体内容。按这个顺序，面板上的数字比较容易串起来。

两种 Token 数字，先分清再看

dsh-context 里最容易看混的是 Token Stats 和 Current Context。前者关注会话累计用量，后者关注当前窗口占用。

你想知道什么	应该看哪里
整条会话累计产生了多少 Token 用量	Token Stats
当前上下文窗口装了多少内容	Current Context
哪个请求开始明显增长	Context Trend
某次请求里具体带了哪些文本和工具定义	Context Browser

为什么累计用量可能远大于当前窗口占用？因为一条用户消息，往往会触发多次模型请求。

例如，一个简化任务连续请求模型三次，输入分别是 20k、24k、30k Token，那么累计输入就是 74k，再加上各次输出，才构成相应的累计用量。第三次请求的输入仍是 30k，不能把 74k 当成它当时的窗口占用。这里的数字只是解释统计口径的假设例子。

前面的消息和工具结果可能在后续请求中继续作为输入，其中一部分会命中缓存。缓存命中率高，说明输入的复用情况；它不等于这些内容从上下文窗口里消失了。

Current Context 卡片显示当前窗口占用与分类组成

*图 2：仓库示例显示 90.9k / 1.0M 的当前占用。下方按类别列出估算值，用于观察组成。*

还有一个细节要一起看：分类数字前面的 ≈。

项目文档说明，分类 Token 使用与 DSH 内置计量器相同的固定密度启发式估算；趋势明细会另列供应商上报的实际输入、输出和缓存数据。当前占用卡片则读取与 Harness 输入框占用环相同的官方计量投影。

因此，分类数字适合帮助我们判断哪部分值得检查；核对实际用量时，应看供应商上报值。分类估算不能当成精确账单。 面板中的成本也属于价格表估算，实际扣费还要以所用服务商账单为准。

第一条回复之前，上下文就已经有内容了

理解了统计口径，接下来可以做一个很有用的动作：在 Context Browser / 上下文浏览器 中，切到某条任务的第一个保留步骤。

你可能会发现，Agent 还没写出第一条回复，上下文里就已经有系统提示词、工具定义、技能目录和项目指令了。用户输入的任务要求，只是其中的一部分。

浏览器把内容分成系统提示词、工具定义、用户消息、注入上下文、技能注入、助手消息和工具结果等类别。每一类都能展开到具体条目，再继续查看实际内容。

上下文浏览器展开工具定义，显示来源、估算大小和参数说明

*图 3：仓库示例中有 27 项工具定义，估算约 6.8k Token；展开 edit 后可以查看说明与参数。这些数值属于图中的示例步骤。*

这张图很适合解释一个容易忽略的成本：工具尚未被调用，它的定义也可能已经进入请求。 模型要决定用哪个工具，需要先知道工具名称、用途、参数结构等信息。

检查工具开销时，可以按大小排序，先读较长的定义，再看旁边的来源标签。插件会尽力标识一方工具包、功能包、MCP 服务或插件来源，方便追溯。这里也要注意，“安装了多少个插件”和“当前请求收到多少工具说明”并不是同一个数字，应以所选请求里实际展示的内容为准。

技能也有类似区别。可用技能的名称和简介进入上下文，不代表 Agent 已经加载了某个技能的完整说明。dsh-context 把技能目录、技能调用和加载内容放进独立的 Skill Injections 类别，展开后才能判断看到的是哪一种。

如果想确认 AGENTS.md、运行时信息或插件内容从哪里进入，可以接着看 Context Events / 上下文事件。这里会记录注入、压缩、剪枝等变化及其来源、时间和对应步骤。组成告诉我们“有什么”，事件帮助我们追溯“怎么进来的”。

上下文突然变大，去找那一步

只看最终组成，有时仍然不够。工具结果占比很大，但究竟是哪次读取、搜索或执行命令带回了大量文本？这就需要 Context Trend / 上下文趋势。

在 Step 模式下，趋势图按模型请求展开。一轮用户对话里，Agent 可能先读文件，再搜索，再修改代码，随后运行检查，每个环节都可能产生新的模型请求。因此，一轮对话出现多根柱子很正常。

上下文趋势按步骤展示组成变化，并显示选中步骤的输入和响应摘要

*图 4：仓库中的趋势示例。下方 User、In、Response 分别帮助回看用户要求、新进入的内容，以及回复或工具调用。*

排查时，可以沿着这条路径走：

找到趋势图中明显升高的那根柱子。
查看增加最多的颜色对应哪一类内容。
选中该步骤，在上下文浏览器里展开对应类别。
核对具体文本、工具参数和返回结果。

例如，如果 Tool Results 突然增加，就去看是不是某次搜索范围过大、读入了整个文件，或者命令返回了长日志。这些只是排查方向，最终应以展开后的记录为准。

图中的 Total / Delta 也很实用：Total 看每次请求的整体组成，Delta 看相邻请求的增减。这里的 Total 属于上下文趋势视图，不能与前面 Token Stats 的累计用量混为一谈。

压缩和剪枝发生时，图上会有相应标记，可以与事件列表对照。历史步骤如果需要从已移除消息的存档重建，插件会在只能近似还原时提示；看到这种提示，就应保留对还原精度的判断。

从文件直接追到工具调用

开发任务还有另一种查法：你已经知道想看哪个文件，只是不想在长对话中逐条翻找。

File Activity / 文件活动 会把读、写、搜索等操作按文件汇总。展开某个文件，可以查看操作记录，并跳转到上下文浏览器中的对应工具结果。

文件活动按路径列出读取、写入等操作及估算的增删行数

*图 5：文件活动示例。先定位文件，再展开操作，可以缩短查找工具调用的路径。*

比如想知道某次 edit 到底改了什么，就可以沿着文件记录找到调用，检查 file_path、old_string、new_string 和返回状态。此时，文件改动和上下文里的工具调用就对上了。

不过，面板中的增删行数是按工具参数估算的，工具返回成功也不等于最终代码正确。验收改动时，仍然需要检查实际文件、Git Diff，以及与改动规模相称的运行验证。这个面板解决的是记录查找和过程追溯。

任务多了，再用跨会话总览

前面的操作都围绕一条会话。如果你每天跑很多任务，可以从左侧 Context Insights / 上下文洞察 开始，先找到值得回看的那一条。

上下文洞察页面展示跨会话统计、活动热力图和可筛选的会话卡片

*图 6：跨会话总览示例。图中的会话数量、Token 和成本属于项目作者的示例数据。*

这个页面提供时间范围筛选、活动热力图和会话卡片，可以搜索标题，也可以按 Token 用量或上下文大小等条件排序。它适合回答“哪些任务值得复盘”，具体原因还要点进会话查看。

如果任务使用了子 Agent，Fleet / 编队 标签页还可以展示当前 Agent、父 Agent 和子 Agent 的关系，以及各自的窗口占用、步骤等信息。每个 Agent 有自己的会话上下文，读数时应区分单个 Agent 的状态与整个编队的汇总。

当前版本的偏好设置还提供系统提示词前缀和后缀，会拼接到各会话的系统提示词中，包含子 Agent，并从下一轮生效。这属于实际影响后续请求的配置项。初次使用时，先熟悉查看和定位功能，就已经能解决不少问题。

真要精简上下文，先找到具体内容

看完这些面板，下一步不必马上大改配置。选一条执行过程较长的任务，找到占用较多的类别，再展开读一遍，通常比凭感觉删工具更有帮助。

看到的现象	接下来检查什么
第一步的工具定义就很大	较长的工具说明、来源包，以及当前任务是否需要这些工具
注入内容或技能内容较多	项目规则、技能目录、已加载说明中是否有重复或无关内容
某一步工具结果突然增加	读取范围、搜索结果数量、命令输出是否超出任务需要
助手消息持续增长	展开具体消息，区分回复、工具参数和可见的推理记录