profile
别名：--profile、档案、配置档、profiles 目录
profile 是一套可切换的插件层栈，落在 $DSH_HOME/profiles/<name>；dsh 启动必须指定 profile，dsh web 只是 --profile web 的别名，插件按 profile 各装一份。
一句话
profile 是 DSH 的「一套装了什么」的边界。 它不是账号、不是主题、不是工作区，而是一份可切换的插件层栈：换 profile 就换了整套插件与配置，而用户数据（会话、技能、存储）默认还是同一份。
落点
profile 住在用户数据根下的 profiles/ 目录里：$DSH_HOME/profiles/<name>/（默认根见 concept/3）。每个 profile 目录里至少有两样东西：
package.json：里面的dsh.profile.bundles是这个 profile 的有序 bundle 列表，也就是层栈的骨架；cordis.patch.yml：这个 profile 自己的用户补丁层。
外加一个 cordis.yml 根配置——它永远是一个空数组，只是给 Loader 一个真实文件当 baseUrl 锚点。树由补丁叠出来，原因见 concept/1。
命令行怎么用
dsh --profile <name> …启动指定 profile；profile 是必填的，不给就报错--profile <name> is required。dsh web是硬编码别名，等价于dsh --profile web。所以「装到哪个 profile」和「用哪个界面起」在官方形态下是同一件事。dsh plugin --profile <name> add <包>把参数原样转发给 pnpm，pnpm 在该 profile 目录里跑——装插件是按 profile 装的，这就是「换了 profile 插件不见」的全部原因。dsh --profile <name> --dump-config打印组合后的树；--dump-default-config不叠加用户层与--patch，用来区分「包带的」与「你改的」。
生态里的三种用法
- 官方形态：
web、headless、desktop、tui这类 profile 名指形态； - 整合包形态：一个整合包基本就是一个 profile，市场里包的
profileName通常与包名一致； - 激活指针：桌面生态里
profiles/desktop被某些工具当作「当前激活 profile」的指针，切换靠改这个目录的指向来实现——这是实现约定，不是规范条款。
未核实
- 本机
$DSH_HOME/profiles下实测能列出web、desktop、dsh-tui等目录，但哪些 profile 名是 DSH 出厂自带、哪些由桌面壳创建，本轮未核实。 - profile 之间的会话 / 存储隔离策略未核实：从机制上看数据根是单一的，但具体哪些状态随 profile 走、哪些全局共享，需要逐项验证。
出处
- CLI 契约：
@deepseek-ai/dsh的lib/bin.js（实测0.1.0-rc.6），其中--profile、web别名、plugin子命令的说明都在帮助文本里。 - profile 目录与层栈解析：
@deepseek-ai/dsh-app-boot的loadProfile/initProfile/PROFILE_PATCH_FILENAME。
相关教程
谁引用了这一条
信息表
- category
- concept.runtime
- layer
- runtime
- spec
- $DSH_HOME/profiles/node_modules/@deepseek-ai/dsh/lib/bin.js（--profile / web 别名 / plugin 子命令）与 @deepseek-ai/dsh-app-boot 的 loadProfile / initProfile
- updatedAt
- 2026-10-02
标签：插件管理、机制、启动