dsh 多租户是什么？DeepSeek Harness 多用户隔离与 DSH plugin 适用场景

DeepSeek Harness 官方文档里并没有「多租户」这个词，所谓 dsh 多租户，实践中指的是「一套 dsh 环境给多个用户或多个项目共用，并靠 profile 与工作区把彼此隔开」。 所以这篇不编造官方不存在的多租户能力，只讲清三件事：多租户这个说法对应到 DeepSeek Harness 的哪几个机制、多用户隔离具体靠什么实现、多租户下装 DSH plugin 有哪些边界。（来源）

dsh 多租户是什么：一套 DeepSeek Harness 服务多用户多项目的实践说法

dsh 多租户不是 DeepSeek Harness 官方文档里的功能名，而是用户对「一套环境多人或多项目共用」这类需求的俗称（来源）。 先厘清这点，才不会误以为官方有一个叫「多租户」的开关：

1. 术语澄清：官方文档与 CLI README 都按 profile、workspace、权限边界来描述环境隔离，没有出现「多租户 / multi-tenant」的正式表述；本文按这几个真实机制来讲。
2. 典型场景：一台机器上多个同事轮流用，或一个团队要给多个客户项目各留一套互不干扰的环境，都属于这类需求。
3. 它和单机配置的区别：单机配置只关心「我自己怎么用得顺」，《DeepSeek Harness profile 是什么》讲的是这个；多租户关心的核心是「怎么让几方互不串味」。

这个说法为什么会出现？因为它借用的是服务端「多租户」的直觉——一个服务端实例服务多个互不可见的租户。很多人在 DeepSeek Harness 里也想要那一套：每个用户有自己的空间、看不见别人的东西、彼此不干扰。但 DeepSeek Harness 走的是另一条路：它不是一个「服务端多账号」的模型，而是一个「本机多份组装」的模型，隔离靠的是 profile 目录与会话账本的物理分离，而不是登录与鉴权。把「多租户」这个词翻译过来，落到 DeepSeek Harness 上就是「多份 profile + 多份工作区 + 各自的权限档位」。

因此要先立一条边界：它没有「一个实例里注册多个账号、各自登录」的能力，也没有为租户计费或配额的内建机制。 你说的「租户」，在 DeepSeek Harness 里对应的往往是「一个 profile 加它的工作区」，隔离的效果来自「它们各自是独立的目录与清单」。理解到这层，后面三条隔离线就顺了。

一句话：dsh 多租户是需求描述，profile 与工作区才是 DeepSeek Harness 真正的实现手段。

多用户隔离怎么做：profile、workspace 与权限边界三条线

DeepSeek Harness 的多用户隔离，主要靠三条线实现：profile 切运行栈、workspace 切工作目录与会话、权限边界切能做什么（来源）。 三条线各管一段：

1. profile 隔离运行栈：每个 profile 在 $DSH_HOME/profiles/<名字>/ 下有自己的 package.json（含 dependencies 与 dsh.profile.bundles）、cordis.patch.yml 与 node_modules，装哪些 DSH plugin、叠哪些覆盖配置完全独立。给不同用户或项目各建一个 profile，就相当于各给一套环境。
2. workspace 隔离目录与会话：工作区把「哪个目录」和「哪些会话属于它」绑定成一条持久记录，不同项目的会话天然按目录分好组、互不混淆。归属需要两个条件同时成立——账本里有该会话 id，且会话 header 的规范 cwd 等于工作区路径。《DeepSeek Harness 工作区是什么》讲的就是这条线。
3. 权限边界隔离能做什么：工具调用要过沙箱权限档位与审批，不同档位对应不同的读写范围。把权限收窄，等于给租户划出一条能力边界。

三条线各管一层，用一张表对照它们的隔离对象与落点：

要注意三条线里有一条**「共享面」是会串味的地方**：同一 $DSH_HOME 下，sessions、settings.yaml 与 .credentials.yaml 是所有 profile 共用的。也就是说换 profile 不用重配模型凭据，但会话目录、全局设置与凭据对所有 profile 可见。只属于某一方的技能或密钥，如果放进跨 profile 共享的位置，就会变成大家都能读到的东西。

操作上，一套环境分给多方通常这样落地，每一步都有可验证的结果：

1. 为每个用户或项目建独立 profile：执行 dsh plugin --profile <名字> add <包名>。预期：$DSH_HOME/profiles/<名字>/ 下生成对应的 package.json 与 node_modules，与别的 profile 互不共用。
2. 在该 profile 下把工作区指向各自的项目根目录：让会话按目录归组。预期：不同项目的会话落在各自工作区下，不混在一条时间线里。
3. 按需收窄各 profile 的权限档位：把宽档位权限留给确实需要的一方。预期：一方的高权限操作不会波及别方的文件。
4. 核对隔离是否真的生效：执行 ls "$DSH_HOME/profiles" 看 profile 列表，再 dsh --profile <名字> --dump-config | grep -n "# ==" 逐套核对加载层。预期：每个 profile 的加载层清单互不相同，各自只含它该有的插件。

DSH plugin 适用场景与限制：多租户下装插件的边界

在多租户场景里，DSH plugin 的装与不装，要按「隔离到哪一层」来判断（来源）。 关键边界如下：

1. profile 是 DSH插件（DeepSeek插件）隔离的单位：插件装在哪个 profile，就只影响哪个 profile。想让两个租户用不同插件组合，各装各的即可；各租户也能各自到 DSH Plugin Hub 挑装自己需要的插件。
2. 同名插件可共存：不同 profile 各装一个同名插件，互不覆盖，因为解析的是各自的 node_modules。
3. 全局与用户级目录是共享面：全局 ~/.dsh/skills、用户级配置这类位置是跨 profile 共享的，放进去的内容所有租户都能看到，不适合放只给某一方用的东西。
4. 它没有内建的多租户账号体系：DeepSeek Harness 不是给「一个服务端多账号」设计的，隔离靠的是目录与 profile 的物理分离，而不是登录鉴权。

「隔离到哪一层」这句话，可以拆成一张更细的对照表：越往下走，隔离越弱、串味风险越高。

一句话：多租户在 DeepSeek Harness 里的边界，等于 profile 与用户级目录的边界。

还要说清一个常被忽略的点：为什么隔离单位是 profile 而不是机器。因为 DeepSeek Harness 的能力是按插件装载的，而插件装载的唯一单位就是 profile——一个插件声明它属于哪个 profile，运行时就只在那个 profile 里往接缝上挂。所以两台机器装同一套插件，未必等于同一个隔离效果；真正决定「谁和谁共享能力」的，是它们用的是不是同一份 profile 目录。反过来，让两个租户真正互不可见，最省事的做法就是让他们从不共用 profile 目录，各自有各自的 profiles/<名字> 与 node_modules。

实践示例：给两个项目各建一套 profile 并核对隔离

把概念落到一个具体场景：一台机器上同时维护 A、B 两个客户项目，要求两边的插件组合与工作目录互不干扰。 按下面的步骤做，每步都有可验证的预期：

1. 给 A 建一套环境：执行 dsh plugin --profile proj-a add <A 需要的包名>。预期：$DSH_HOME/profiles/proj-a 出现，包里带上 A 需要的插件。
2. 给 B 建一套环境：执行 dsh plugin --profile proj-b add <B 需要的包名>。预期：profiles/proj-b 独立生成，与 A 的依赖清单不同。
3. 各指向各自的工作目录：在 A 的会话里把工作区指到 A 的代码根目录，B 同理。预期：两边的会话按目录分组，不会互相出现在对方的会话列表里。
4. 核对 A 的加载层：执行 dsh --profile proj-a --dump-config | grep -n "# =="。预期：只列出 A 装的那批层，出现 # == <包名> 的行。
5. 核对 B 的加载层：执行 dsh --profile proj-b --dump-config | grep -n "# =="。预期：列出的层与 A 不同，证明两套环境确实分离。
6. 确认共享面没混入私有内容：检查 ~/.dsh/skills 与全局配置里有没有只该给 A 或只该给 B 的东西。预期：共享层里只有通用内容，私有技能与密钥都留在各自的 profile 或工作区里。

做到第 6 步，「一套环境服务两个项目、彼此不串味」就落到了实处。反过来，只要跳过第 6 步，把某一方的私有内容丢进共享层，前面几步的隔离就白做了。

注意事项与局限

多租户是把双刃剑：用好了互不干扰，用错了会串味。 逐条提醒：

1. 官方没有「多租户」这项官方能力，本文讲的是用现有 profile / 工作区机制组合出来的实践，不要期待一个开关搞定。
2. 隔离靠目录分离：所有租户共用同一台机器与同一个 dsh 安装，物理上并非完全隔离，安全要求高的场景要额外做进程或系统级隔离。
3. 共享目录是最大的串味点：把只属于某一方的技能、密钥放进全局目录，会让其他租户也读到。
4. 权限要按最小够用收窄：多租户下应更谨慎地授予宽档位权限，避免一方操作波及别方文件。
5. 插件权限对租户不设限：装进某个 profile 的插件拥有该 profile 的能力，租户装插件前仍要按来源与权限审一遍。
6. 多一套 profile 就多一份维护成本：同一个插件装三处，将来就得升三次；租户数量上去了，升级与排障的账要提前算。

与其给多个项目手工复制一堆零散配置文件、再靠记忆区分谁用哪套环境，不如用社区官方的 DSH Plugin Hub（dsh-plugin.org/zh）把每个 profile 的插件装得清清楚楚，再用已安装列表逐套核对。

来源：DeepSeek Harness 官方文档 - 架构总览、DeepSeek Harness 官方文档 - 工作区、dsh CLI README。