DeepSeek Harness 五个随附 profile 怎么初始化？目录、manifest 与首次启动

DeepSeek Harness 的五个随附 profile 不是“装完就摆在磁盘上”，而是首次使用时才从内置模板初始化。 web、headless、sdk、sdk-minimal、acp 各自对应一套组合与 patch 应用方式，目录统一落在 $DSH_HOME/profiles/<name>。理解这一点，才能解释“为什么我改了 patch，headless 没热更新”这类问题。

DeepSeek Harness：五个随附 profile 的组成

同样是启动入口，五个 profile 的组合包和 patch 时机并不一样。 对照：（来源）

web 面向浏览器交互；headless 跑一次性任务；sdk 与 sdk-minimal 服务 JSON-RPC 客户端；acp 面向自动化客户端。只有 web 明确“实时应用 patch”，其余四个在启动时把 patch 定下来。

dsh web 只是 dsh --profile web 的硬编码别名。其他四个没有同名快捷方式，要写 dsh --profile headless 或 dsh --profile sdk-minimal。

DeepSeek Harness：目录与 manifest 长什么样

profile 目录不是“一个 YAML 文件”，而是一份 manifest 加若干配置层。 初始化后重点看三处：（来源）

1. package.json — 含 dsh.profile manifest 与有序 dsh.profile.bundles。预期：能看到该 profile 由哪些组合包组成。
2. cordis.patch.yml — profile 自己的持久 patch。预期：你的改动写在这里，重启仍在。
3. node_modules/ — 树外组合包与插件依赖。预期：只有装过第三方包时才出现对应内容。

内置组合包（@deepseek-ai/dsh-base、dsh-web-app、dsh-headless、dsh-sdk-app、dsh-sdk-minimal、dsh-acp-app）始终从当前运行的 dsh 安装目录解析，不从 profile 的 node_modules 找。这意味着升级 dsh 本体后，内置组合包会跟着换版本；树外包则要单独更新。

DeepSeek Harness：首次启动做了什么

启动不是“读一个完整配置文件”，而是从一个空根开始逐层叠加。 顺序：（来源）

1. 创建缺失的 profile — 五个随附名字从模板初始化；其他名字缺失则报错。预期：目录与基础 manifest 出现。
2. 叠加组合包 patch — 按 dsh.profile.bundles 顺序应用每个 bundle 的 patch。预期：基础配置树成形。
3. 叠加 profile patch — 应用 profiles/<name>/cordis.patch.yml。预期：该 profile 的定制生效。
4. 叠加 home patch — 应用 $DSH_HOME/cordis.patch.yml。预期：该 home 下所有 profile 共享的偏好生效。
5. 叠加命令行 --patch — 按 argv 顺序应用。预期：临时覆盖优先级最高。

对同一配置行，后应用的层优先。patch 会替换目标行的整个 config，不是深度合并；这是很多“只改一个字段却把别的字段弄丢”的根源。

DeepSeek Harness：三种进入方式

同名快捷、显式 profile、模板替换，三种方式解决不同问题。 对比如下：（来源）

1. dsh web — --profile web 的别名，适合日常启动 Web UI。预期：直接用，不用记 profile 名。
2. dsh --profile <name> — 启动任意 profile，包括 headless、sdk、acp。预期：参数写在启动器一侧，应用参数放在后面。
3. --from-default-profile — 用模板替换一个自定义 profile。预期：适合重建，不适合保留配置的升级。

如果只是第一次用，直接 dsh web；如果要做 CI 或自动化，先想清楚用 headless 还是 sdk，两者的输出契约不同。

DeepSeek Harness：常见误区

profile 初始化的问题，多数是“以为它和另一个 profile 一样”。 四个误区：（来源）

1. 以为所有 profile 都热更新 — 只有 web 实时应用 patch，其他四个启动时才应用。预期：改完 headless 配置要重启。
2. 以为 profile 名可以随便写 — 非随附名字缺失时不会自动建，必须用 dsh plugin 创建。预期：不会得到一个空 profile 直接启动。
3. 以为内置包会从 node_modules 找 — 内置组合包从 dsh 安装目录解析。预期：升级本体后版本跟着变。
4. 以为 patch 是深合并 — 它替换整个 config。预期：改字段时保留同行的其他字段。

DeepSeek Harness：从模板到可运行的检查表

首次初始化后，按四项确认 profile 真的可用，而不是“目录建出来了”。 检查表：（来源）

1. 目录与 manifest — profiles/<name>/package.json 存在，bundles 非空。预期：不是空目录。
2. 启动无配置错误 — 启动时没有 schema 校验或模块解析失败。预期：进程能进入运行状态。
3. patch 生效 — 用 --dump-config 看到 profile 层的改动。预期：不是只改了文件没叠加。
4. 入口匹配 — web 能开页面，headless 能跑任务，sdk 能响应客户端。预期：不是“能启动但用不了”。

四项里任何一项失败，先看启动日志与 dump，不要急着重装。

第一次启动慢一些是正常的：profile 初始化、依赖解析与前端产物加载都要时间。只要进程最终进入运行状态，就不要因为“等了几秒”而重复启动。

如果启动后立刻退出，先看退出码与日志末尾，不要反复执行 dsh web；重复启动会掩盖第一次的真实报错。

配置层的叠加顺序

profile 不是一份完整配置，而是从空根开始逐层叠加；顺序决定谁覆盖谁。 官方顺序：

后应用的层优先；patch 替换目标行的整个 config，不是深合并。理解这张表，就能解释“为什么我改了 profile patch，却被 home patch 覆盖”。

DeepSeek Harness 常见问题

Q：五个随附 profile 哪个最轻？ sdk-minimal 是独立极简组合，不含 dsh-base，只保留 SDK 协议、适配器、本地执行与持久化；但它不适合当通用 Web UI。

Q：能不能把 web 的配置复制给 headless？ 可以复制 patch，但要注意组合包不同、工具集不同；复制后先用 dump 核对，不要假设字段完全通用。

Q：profile 目录能随便改名吗？ 不建议。名字与启动参数、manifest、凭据引用都相关；要新名字就用 --from-default-profile 新建，而不是直接重命名目录。

一句话收束： 五个随附 profile 的差异不在“名字”，而在“组合包 + patch 时机”；先看 manifest 和启动方式，再改配置。