第 13 章 · Profile、Bundle 与「第五种模式」

本篇目标：不改源码，造出一个属于你的运行时。 这是 DSH 相对其他 Harness 最独特的一层，也是「大师级」的分界。

13.1 插件树：一个运行中的 dsh 到底是什么

官方 docs/architecture.md：

A running dsh is a plugin tree composed at boot from ordered layers.

三个概念：

每个包在自己 package.json 的 dsh 字段里声明：dsh.profile 列出 bundles，dsh.bundle 指向 patch 文件。

层叠顺序（后者覆盖前者）：

空 entry list
 → profile 的 ordered bundles
 → profile 自带的 cordis.patch.yml
 → Harness home 的 patch
 → --patch overlays

官方 随附 bundles：

dsh --profile web --dump-config      # 打印本机真实启动的整棵树

原文："Any row it prints can be replaced by a patch of your own." —— 这就是「配置层自由组合」的全部含义。

13.2 一个最小 patch 的心智模型

官方 patch 以 row id 定位、整行替换或插入。下面是示意结构（字段名以 reference/config-catalog.md 生成目录为准，动手前 dump 核对）：

# cordis.patch.yml —— 示意，非可直接运行的完整配置
- id: dsh-tool-web-search
  config:
    enabled: false            # 关掉联网搜索，缩小攻击面与提示词体积
- id: custom-sidebar-plugin
  config:
    package: "@you/dsh-usage-panel"
    inject: ["sessions", "tokenMeter"]

三类常见改法：

判据 17：能看懂 --dump-config 输出、并能用 patch 精确替换其中任意一行，才算真正「拥有」这个 Harness。只会点设置页的人，仍在 inner harness 里。

13.3 第五种模式：把试验固化为预设

原文 创造模式的进阶路径：

检查运行时 → 加载与测试插件 → 观察服务与依赖 → 调整组合 → 固化为新的预设模式

产出例子：写作模式、数据分析模式。原文 那句「从此你就不只是在用 DSH，你是在用『你的 DSH』」，工程含义是：预设 = 一份可版本化、可分发的 Harness 配置。

一个「写作模式」该长什么样（推断 设计建议，需自行验证）：

一个「数据分析模式」则相反：保留 PTC、只读并行、沙箱内 Python，关掉 UI 相关插件。

模式的本质不是「换个提示词」，是换掉整个能力集合与约束集合。 这正是第 05 章「四种模式不是等级」的推广。

13.4 预设的工程纪律

官方 还有一条容易踩的：plugin 是管理命令名，若有同名 profile，必须写 --profile plugin。

13.5 从 DSH 迁移到任意 Harness

把这一章抽象成通用清单，任何框架都适用：

七问全答得上来，你就能在 Claude Code / Codex / LangGraph / 自研运行时里复刻同一套工程方法——具体文件名不同，结构完全同构。这也是本系列不止讲 DSH 的原因。

13.6 本章产出与验收

核心产出：一个自定义预设（如 writing），含 patch 文件、dump-config 前后 diff、一个端到端用例、一份 README 说明每个取舍的理由。

验收点：

• 能画出 profile → bundle → patch → overlay 的层叠顺序并指出覆盖方向
• 能解释 dsh-sdk-minimal 为何不套 dsh-base
• 能用 patch 精确关掉一个工具，并在 dump 输出中验证
• 能说出预设与「换个提示词」的三点以上区别
• 能用 13.5 的七问评估另一个 Harness 框架

延伸阅读