我想要的 Agent 工具，不只是一个能聊天、能跑命令的终端。它还得让我知道：现在改的是哪份工作副本，刚才那次请求带了什么，下一步又会交给哪个模型。
这些问题不直接提高模型智力，却决定了我能不能放心让它继续做事。以前写 ai-dev-platform，我关心的是怎样把调度从黑盒里拿出来。到了 DSH，我更关心眼前这场工作能不能看清、能不能接手。
我目前的 Web profile 选进了八个社区插件包。这里不挨个报名字，只讲四个：侧栏、上下文观察、上下文压缩和模型路由。它们都是第三方项目，我做的是选择和组合，不是把别人的实现算成自研。
Note
核对截至 2026-10-23，依据是本机 profile 的 bundle 清单、已安装包和对应源码。列入加载清单，不等于每个子功能都已生效；下面也不把项目文档里的效果数字当作我的实测。 本次核对的本机已装版本：
dsh-better-sidebar 0.28.0、dsh-context 0.74.0、billion-context 0.1.204、@neptune810/dsh-model-router 0.14.2，不代表最新版本。
先分清：插件不是另一份提示词
我理解的 skill，主要回答“这类任务应该怎样做”。DSH 的 skill 工具实现会按名称查找技能，把内容交给模型。技能可以配套脚本，但写进技能的规则，不等于宿主已经强制执行。
插件能改的是另一层：挂载服务、注册工具、参与请求处理，或者在界面上增加入口。
拿 dsh-context 的包声明来说，去掉无关文件后，结构很短：
dsh-context/
├─ cordis.patch.yml # 声明宿主侧插件条目
├─ lib/index.js # 宿主入口
└─ lib/client.js # 浏览器端入口它不是把一段“请关注上下文”的话塞进聊天框。宿主侧和浏览器侧各有入口，包声明再告诉 DSH 怎么加载。这也意味着：装进去的是会运行的代码，不只是供模型参考的文字。
侧栏先解决“我到底在看哪份代码”
dsh-better-sidebar把文件树、编辑器、Git 变更和任务视图放进同一个工作区域。我看重的不是按钮多，而是文件和会话能对得上。
比如 Agent 转进一个 Git worktree 后，聊天还在原来的窗口里。如果侧栏仍然指着主工作副本，看起来就像“它说改了，文件却没变”。
这个插件会结合宿主记录的当前目录和工具调用中的路径，识别真正的 linked worktree，也就是关联的 Git 工作树。最近一次明确切换目录之前的旧线索，不再拿来决定当前根目录。这比一直相信会话创建时的目录可靠，但它仍然是在根据事件判断，不是无所不知。
插件之间的连接也有边界。侧栏可以跳到 dsh-context 的诊断页，但代码没有把“包已经安装”当成“页面可以打开”。它还会检查右侧面板服务、标签类型和页面内容是否真的注册好了。
这种检查比再加一个入口更重要。我不希望界面看起来什么都有，点进去才发现另一半根本没加载。
先看上下文，再决定丢掉什么
dsh-context负责把请求拆开看。它的上下文视图区分系统提示词、工具定义、用户消息、注入内容、回复和工具结果；趋势图按模型请求记录变化，而不只是按聊天气泡计数。
这样才能追问：上下文突然长了一截，是读了大文件，还是加载了技能，又或者工具定义本来就很重？不过，占用分类里的 token 数有估算成分，不能直接当账单；供应商报告的实际用量是另一组数据。
billion-context做的则是处理历史。按它的实现设计，模型用 compress 把已经消耗的消息范围换成摘要，之后可以检索摘要，必要时再恢复原文。
这两个方向我不想混为一谈：一个帮助解释窗口里有什么，另一个会改变后续请求带什么。
压缩也不是免费的。摘要可能漏掉约束，恢复原文会重新占窗口，重写历史还可能影响前缀缓存。我不会因为包名叫 billion-context，就把它理解成模型拥有了无限记忆。它解决的是有限窗口怎样承接更长的工作历史，不是取消窗口限制。
还有一层容易忽略：它的 DSH bundle 不只增加工具，也会调整宿主默认压缩的接管关系。因此，排查“谁压掉了这段内容”，不能只盯着某一个面板。
模型路由最重要的是接管范围
@neptune810/dsh-model-router把模型池和路由控制放到输入区。我最关心的不是“自动挑最强模型”，而是它被允许改什么。
它区分模型与思考等级的控制范围。只管思考等级时，会绑定一个模型，不应该顺手把模型也换掉；默认的手动让位策略，则会在检测到其控制范围内的人为选择后退出自动接管。
这不是单纯的界面状态。宿主侧监听 agent/request，拿到已经解析好的请求，再决定是否改写模型和思考等级。
跨供应商切换还单独设了确认策略。不过我读代码时看到一个重要前提：这个守卫要求模型池里仍有当前供应商的候选。池子只剩另一个供应商时，不能把“先问”理解成无条件的拦截保证。
所以我不会把“装了路由器”写成“每一步都自动选到了最合适的模型”，更不会据此宣称省了多少费用。接管状态、候选池和这一次请求的实际决定，是三件不同的事。
工作台越完整，越要留着退出路径
把这几块放在一起，我想得到的是一条能追查的工作线索：从会话找到文件，从请求找到上下文，再看清模型控制权在哪里。不是让所有决定都自动发生。
代价也很具体。界面插件依赖宿主的服务和槽位，版本不匹配会让入口消失；压缩插件会碰请求历史；路由插件会碰模型选择。它们不是互不相干的皮肤。
侧栏 0.28.0 的文档就明确要求 DSH 0.2.1-rc.1 或更新版本，并提醒宿主与插件的 latest 标签并不保证相互兼容。我会把这种版本边界看得比功能数量更重。
这次核对没有覆盖所有面板的运行行为，也没有做压缩质量或路由收益的对照测试。对我来说，现阶段更有价值的判断是：出了问题，能不能分清是模型没做好、插件改了请求，还是界面没跟上。能分清这些，插件才真的把终端变成了工作台，而不只是把它装饰得更复杂。