DeepSeek Harness Profile 是什么？核心组织单元一篇看懂

在别的工具里，你"装一个 agent"；在 DSH 里，你启动一个 Profile。这是 DSH 最独特的概念，也是后面一切配置的容器。它回答一个问题：一次 dsh 启动，到底是由什么拼出来的？

一句话理解

Profile = 一份"怎么组装这个 dsh 实例"的清单，放在一个目录里。 目录里没有代码，只有声明：挂哪些插件、叠哪些配置、依赖哪些包。

$DSH_HOME/profiles/<name>/
├── package.json      # 依赖清单：树外插件声明在这里
├── dsh.profile       # profile 清单：按顺序排列的 bundles 列表
└── cordis.patch.yml  # 你的定制层：覆盖/追加配置写在这里

三个文件的角色：

文件	干什么	类比
`package.json`	声明额外依赖的插件包	项目依赖清单
`dsh.profile`	声明由哪些组合包（bundle）叠成	菜谱的主料列表
`cordis.patch.yml`	在上面再叠一层你自己的修改	你的"口味调整"

注意 cordis.patch.yml 才是你应该编辑的文件。同目录下的 cordis.yml 是空的根（内容就是一个 []），官方注释写得很直白："Edit cordis.patch.yml, not this file."

两个内置 Profile：web 与 headless

装完就能用的两个入口，本质就是两个预先组装好的 Profile：

Profile	启动命令	用途
`web`	`dsh web`（即 `dsh --profile web`）	浏览器 GUI，交互式工作
`headless`	`dsh --profile headless "任务"`	一次性任务，打印最终答案后退出

两者共享同一套基础能力（模型、工具、持久化），差异只在"表面"：web 挂 Web 服务器与前端，headless 不挂任何界面。首次使用时会从随附模板自动初始化，所以你没建过目录也能直接跑。

为什么要有 Profile：同一个核心，不同形态

DSH 的设计意图是：核心能力做成可复用的组合包（dsh-base 是第一层，dsh-web-app、dsh-headless 是第二层），Profile 只负责声明怎么叠。于是：

想要 GUI？叠 web 组合包
想要纯脚本执行？叠 headless 组合包
想要你自己的形态？自建 Profile，只挂你要的插件

这种"组合而非写死"的方式，就是"一切皆插件"在入口层面的体现。

创建自定义 Profile

内置的两个之外的 Profile，用插件管理器创建：

dsh plugin --profile <name> <pnpm args>

例如给某 Profile 加一个社区插件，实际上是把 pnpm 命令转发到 profile 目录。创建后：

dsh --profile <name>        # 启动

几个常用命令速记

命令	作用
`dsh web`	启动 web Profile
`dsh --profile headless "任务"`	一次性任务
`dsh plugin --profile <name> <pnpm args>`	管理 Profile 插件
`dsh --profile <name> --help`	看该 Profile 应用自己的参数