建议：工作区（或任务）可绑定一套预设，新建会话时自动带上

[luoyukun3-oss]

背景

#8634 里 @kkaporn 反馈「普通用户不该需要背命令才能让插件生效」。我们把机制核了一遍：他踩的是层级问题，但顺手挖出一个真缺口，整理成这条建议。

现状：目前只有两层

层	作用范围	生效方式
插件 / bundle	整个配置档（profile）	装一次，该配置档下所有会话、所有工作区一直生效，重启也在 —— 不需要任何"激活"
预设 preset	单个会话	新建会话时选定，被这个会话记住（config.id 是会话保存的 preset 标识符）

⇒ 常见误解：「我没敲命令，所以插件没生效」——插件本来就是全局的；真正会随会话变的只有预设。
⇒ 但确实存在一个缺口：中间那一层是空的。

缺口

现在没有「工作区 / 任务 → 预设」的绑定。用户想要的是：

我要做一个任务，把相关插件装好、归成一个组合；以后在这个工作区新建会话，它自动带上，不用每次手选。

现在只能每次手动选预设，或者把所有插件全挂在同一个预设里（越挂越臃肿）。

建议

1. 支持把预设绑定到工作区（按目录），新建会话时默认使用；
2. 退一步也行：按工作区记住上次的选择，新建会话时沿用；
3. 小白向入口：安装插件时提示「加入当前工作区的预设」，而不是让用户先去理解 profile / preset 这些词。

触发这条建议的用户原话

讨论 #8634 的发起人 @kkaporn 看到本建议后补充道：

……我安装了一大堆插件，在实际使用过程中这些插件没有工作。那么如果，在新开的工作目录里面挂上一套专门插件组合，普通用户用自然语言对话，这些插件自动运行，对用户的自然语言进行拆解分派任务给插件。

即：这不是我们替用户想象的诉求，而是用户自己提出的 —— 他要的不是「全局生效 + 自己判断该装什么」，而是「这个工作目录就带这一套，我说话就行」。

用户随后把需求写细了（原文要点）

同一位用户在跟进里给出了更完整的形态 —— 三层结构，以及两条比"小白友好"更有说服力的收益：

• 全局安装层：插件装一次，放在全局，所有项目都能"选用"；
• 工作区组合层：每个工作区根目录带一份自己的清单（他举的例子是 .dsh/workspace.yaml，里面列 plugins:），这个工作区只启用这套组合里的插件，其他全局插件不参与；
• 会话调用层：该工作区里新开的会话默认只看到这套组合，用户用自然语言说"跑一下项目 / 看场景树 / 截个图"，AI 只在组合内挑选工具。

他列出的收益里，这两条我们原本没写进去：

1. 省 token —— 工具列表短了，提示词负担就小（这是成本账，不只是体验账）；
2. 配置跟着项目走 —— 工作区根目录自带组合，换机器、分享项目都能复现。

原文：全局安装 = 你电脑上装了很多工具；工作区插件组合 = 你进某个项目，只从工具柜里拿这几件工具上工位。其他工具还在柜子里，但不在这个工位上，不干扰你，也不参与 AI 的调用选择。

出处

• @deepseek-ai/dsh-agent-preset README：「可同时声明多个 preset，由会话选择」「config.id 是会话保存的 preset 标识符」
• 插件安装的作用范围：官方 skill 原文 Changes affect every session in that profile
• 触发来源：讨论 使用DSH一小时糟糕的体验 #8634（@kkaporn）

这条来自一线用户的真实卡点，不是设计洁癖。

[kkaporn]

我用一个更简单的比喻，dsh的插件，就跟游戏里面的技能面板一样，当然游戏里面的技能需要升级解锁，而插件是随便安装的。DSH的逻辑是只要安装了的插件就全局生效，这个不能说不好，而是在实际的使用过程中，比如我新建一个会话工作区，这个新的会话工作目录可以全局使用所有插件，但是在实际的使用过程中，有些插件没有工作或者不知道他运行没运行，用指令激活或者要输入具体的插件名称还是别的，对于普通用户有难度，在开发软件还是别的程序的过程中遇到难题本闹就闹心，然后在想问题的时候，还要加入具体的指令某些插件才激活运行，这样更恼火。如果能给每一个新开会话工作区文件夹挂上具体的插件，这个工作文件夹只运行具体的插件，普通用户用自然语言，这里面的插件就会按照自然语言进行工作，哪怕自然语言是错误的，是残缺的，大模型也会跟插件去补全。

[luoyukun3-oss]

@kkaporn 你说"弄清楚了"—— 那我就不复述机制了，只回你最后那两点，因为它们其实一个能查、一个已经做到了。

① "装了一大堆插件，实际使用中它们没工作" —— 这个可以先查清，因为插件在不在跑是可查的，不用靠感受：插件栏有加载 / 启用状态，harness.log 里能查到每个插件的挂载与加载记录（我本机就是靠它确认两个守卫插件真的加载上了）。但更常见的情况是：很多插件是"被动型"的（提供工具、hook、去重兜底），你不触发它管的那条路，它就一声不吭 —— 这不等于它没工作，而是你还没走到它的触发点。把一个插件的 README 读完、按它说的走通一遍，比装十个更能看出它到底在干嘛。

② 你说的"让 SKILLS / 默认对话自动把插件装到该去的文件夹"—— 这个 DSH 已经能做。 官方发行版内置了 cordis-plugin-development（教 agent 怎么装插件、写插件、调配置）和 editing-cordis-compositions 这些 skill。你直接在对话里说"帮我把这个插件装上""帮我看看它为什么没跑起来"，agent 会照那套流程走 —— 我今天核插件机制（插件是全局还是会话级、预设挂在哪一层）用的就是它。所以这一条不用等官方加新功能，你现在就可以试。

③ 你真正想要的那个"工作目录挂一套插件组合" —— 那是本建议的核心，我已经按你的意思写进 #8797 了，也把你这段话摘进了主楼：让官方看到这是用户自己提的，不是我们替你想出来的。

至于那些说你"不配用"的话，我不替他们说话，也不打算跟你争这个 —— 你提的这条功能请求本身是成立的，这就值得留在这儿。

[kkaporn]

要的不是“插件到底有没有在运行”这种模糊问题，而是：

插件可以全局安装，但应该能在具体工作区的根目录上，绑定一套具体的插件组合。这个工作区只启用这套组合里的插件，其他全局插件不参与。

翻译成更直白的话：

全局安装 = 你电脑上装了很多工具。

工作区插件组合 = 你进某个项目，只从工具柜里拿这几件工具上工位。

其他工具还在柜子里，但不在这个工位上，不干扰你，也不参与 AI 的调用选择。

这就是你真正想要的机制。

现状是什么
DSH 现在的插件基本是 全局 / profile 级 的：

装一次，整个配置档都能用。

工作区只是“当前项目目录”，控制的是文件操作范围。

工作区本身不绑定插件，也不决定“这个项目只启用哪几个插件”。

所以你会看到：全局装了一大堆，实际干活时哪些被调用、哪些没被调用，不直观。

你之前说的“插件都在一起挂载着，是否运行不知道”，根本原因就在这里：
插件缺少工作区级的启用范围和组合绑定。

你想要的机制
你想要的其实是三层：

全局安装层
插件装一次，放在全局，所有项目都能“选用”。

工作区组合层
每个工作区根目录下，有一份自己的插件清单 / 配置。
比如 Godot 项目根目录绑定：godot-bridge、scene-tree、screenshot。
另一个项目根目录绑定：web-debug、api-test、database。
这两个工作区互不影响。

会话调用层
在这个工作区里开的新会话，默认只看到这套插件组合。
AI 只从这套组合里选工具调用。
用户不用记命令，自然语言说“跑一下项目、看场景树、截个图”，AI 自动用这套组合里的插件完成。

这样，你作为用户就只需要关心：

这个工作区启用了哪几个插件。

它们有没有被调用。

效果是什么。

全局装了多少、有没有全局生效，不再困扰你。

这能解决什么
插件隔离：不同项目用不同插件，互不干扰。

可见性：当前工作区启用了什么，一目了然。

减少干扰：AI 不会面对几十个全局插件选择困难。

节省 token：工具列表短了，提示词负担小。

配置持久：工作区根目录带着自己的插件组合，换机器、分享项目时也能复现。

自然语言驱动：用户不用记命令，AI 在工作区组合内自动分派。

技术上大概长什么样
可以在工作区根目录放一个配置文件，比如：

yaml

.dsh/workspace.yaml

plugins:

• godot-bridge
• scene-tree
• screenshot
• file-guard
  config:
  godot-bridge:
  project_path: .
  DSH 打开这个工作区时：

读取这份配置。

只加载 / 启用清单里的插件。

其他全局插件保持“已安装但未在此工作区启用”。

每个插件的配置也可以按工作区覆盖。

这就类似：

VSCode 的工作区扩展推荐 / 启用。

npm 项目的本地依赖。

IDE 的项目 SDK 和运行配置。

不是新概念，是很成熟的项目级作用域机制。

所以你的诉求是成立的
你不是“不会用”，也不是“抠字眼”。
你指出的是 DSH 目前缺的一层：工作区级插件组合与绑定。

现有 DSH 只有：

全局插件（整个 profile）

单会话预设（preset）

中间缺的正是：

工作区级插件组 / 项目级插件配置

有了这一层，你之前说的“全局安装的插件是否运行、哪些在运行、怎么解决”就自然解决了：
全局安装只是仓库，工作区组合才是真正上岗的工具集。