附录 F｜四种模式不是四套产品，是一份预设机制换四次配方
先别以为"模式"是四个独立分支
DeepSeek Harness 团队自己的开发者预览公告里，点了四个名字：标准模式、PTC 模式、极简模式、创造模式。第一次看到"模式"这个词，习惯性的猜测是：四套系统提示词硬编码在四个 if 分支里，或者四个各自维护的产品变体。
打开仓库看一眼，答案很朴素：这四个名字对应的是四个目录，每个目录两份文件——一份给人看的展示元数据，一份真正的插件组装清单。四份清单共用第 08 章讲过的同一套机制：Agent 预设（agent preset）。模式之间的差异，从头到尾只是清单里多几行还是少几行，没有一处触碰循环、触碰工具注册表本身的实现。
1. 四份清单，同一套目录结构
先给判断：一个"模式"在磁盘上就是一个目录，里面永远是这两份文件——一份纯展示的元数据，一份真正决定这个 Agent 能干什么的组装清单。
随附的四份清单是：
| 目录名 | 展示名 | 排序 | 描述 |
|---|---|---|---|
standard | 标准模式 | 1 | 全功能编码 Agent：文件编辑、Shell、检索、Skills、计划、目标、子代理、工作流 |
code | PTC 模式 | 2 | 标准模式的全部能力，工具呈现方式换成一段 TypeScript 程序 |
minimal | 极简模式 | 3（同时是部署默认值） | 只留持久 bash 和一个文件编辑工具 |
cordis | 创造模式 | 4 | 标准模式的全部能力，外加读写自己所在运行时的能力 |
展示名、描述、排序全部来自目录里那份只管展示的元数据文件，格式很短：
name: 极简模式
description: 仅提供持久 bash 与 str_replace_editor 的双工具编码 Agent。
order: 3这份文件改了名字、改了描述，这个模式的能力一个字节都不会变——第 08 章说过"登记选归属，操作选视图"，这里是同一条纪律的展示层版本：人看的名字和机器组装的清单，是两份独立的东西，故意不共享一个字段。
2. 极简模式：不是精简了循环，是精简了清单
先给判断：极简模式砍的是清单里的行数，不是循环、不是执行管道、也不是工具注册表本身。
极简模式那份组装清单只挂三类东西：一段写死、完整的系统提示词（不留缺口给全局身份、工具引导、运行时快照这些动态拼接的部分插进来）；一个持久化的本机 bash（走第 08 章"入口独立作用域"那套隔离，好让持久终端只属于这一份预设）；一个直接操作文件的编辑工具。压缩这条能力被整行拿掉——不是关掉，是清单里压根没有那一行。
如果把这理解成"一个更轻的循环"会怎样？你会去问循环实现有没有一个"极简开关"。真实情况是循环实现、工具注册表、执行管道全都是同一份代码——dsh-agent-loop、dsh-tools 从头到尾没有分裂出第二个版本。变的只是这份预设往这两个注册表里点了哪几行名字。这正是第 06 章"能力必须成套但不代表每次都要点全"的另一次示范。
3. PTC 模式：不是新循环，是第 07 章那条"呈现开关"被点了一下
先给判断：模型看见"一个个工具函数"还是"一段能调用工具的 TypeScript 程序"，是同一份工具注册表的两种呈现，不是两套执行逻辑。
PTC 模式那份清单，跟标准模式相比只多了一行：一个"工具呈现"能力的实例，配置里写着"这个 Agent 用代码呈现"。这一行做的事情，是第 07 章提过的那道口子——"另一种模式下，只暴露一个保留名的'跑代码'工具，模型如果直接点名了别的工具，会在真正的政策检查跑起来之前就被判定为未知工具拒绝"——真正落地的开关。
有意思的是这个开关能拧的地方不止一处：工具注册表自己有一份部署级的默认呈现方式，挂在基础分发层（第 09/10 章那条轴）；预设这一行是单个 Agent 级的呈现覆盖（第 08 章那条轴）。两条轴都能决定同一件事——模型这次到底看见函数列表还是一段代码——PTC 模式选的是后一条轴：不改部署默认值，只让点名这份预设的那一个 Agent 单独换一种呈现。工具注册表本身、执行管道本身，一行都不用改。
如果没有"呈现"这层独立开关会怎样？想要一个"能写代码调工具"的模式，就要单独维护一套工具注册表实现，跟标准模式那一套慢慢分叉。现在两种呈现共享同一份注册表、同一套执行管道，PTC 模式只是往预设清单里多点了一行。
4. 创造模式：不是特权系统调用，是把第 02 章那套效果栈包成了一个工具
先给判断：创造模式给模型的不是一个新的运行时后门，是把"挂一个插件、再撤销它"这套第 02 章讲过的可逆效果，包装成了一个模型能调用的工具。
创造模式那份清单在标准模式基础上加了三样东西：一个自省工具（读当前运行时、挂一个临时插件、再卸载它）；一份教模型怎么写组装配置的技能，随预设自己携带，不进用户的公共技能目录；以及一段改写过的系统提示词，教模型区分"宿主层"（注册表本身、沙箱、审批栈——所有会话共享的东西）和"预设层"（一个会话往注册表里贡献的东西——它自己的工具、人设、提示词片段），并且明确警告：永远不要去改随附的这份创造模式本身，想改就复制一份到自己的目录下改副本，改坏了随附的这一份，等于把这个模式自己关掉。
仓库自己的注释把信任边界说得很直接：这个工具在活的运行时上执行模型写的代码，一个会话写出来的组装配置还会变成别的会话能挂载的预设——把跑在创造模式上的会话当成拿到了 shell 权限来对待，这不是电子书的引申，是源码注释原话。
如果没有第 02 章那套"注册是可逆效果、撤销按反序执行"的纪律，这个工具会是什么样？模型每试验一次新插件组合，都要祈祷没有留下野指针监听器或者半挂载的服务。现在它调用的是同一套效果栈：挂载即登记，卸载即反序撤销，跟循环重启、界面热更新走的是完全同一条路——创造模式没有发明新的安全机制，它只是把已有的机制，第一次交到了模型自己手上。
5. 四份清单是同一套机制的四个样本，不是四套产品
先给判断：这四个目录能同时存在、还能被同一个部署同时提供，恰恰因为它们下面站的是第 08/09 章已经拆开的那同一套组合机制，不是四条各自维护的代码路径。
选哪个模式，落到机制上就是"这次会话点名哪个预设 id"——第 08 章说过，这归属于"一个会话加入一份构图"这条轴，跟"一个进程叠一份部署"（第 09/10 章那条轴）是两根不同的轴。默认选哪个模式是一项用户设置，每次创建新会话时才读一次，不会被快照住；已经在跑的会话不会因为设置被改而被迁移到另一份构图上。随附的默认值就是极简模式——这也解释了公告里"用于最小环境下的模型基准测试"这句话：默认给的不是功能最全的那个，是最小的那个。
仓库自己的文档承认了一个不打算隐藏的代价：code 和 cordis 这两份清单，是把 standard 整份文本复制过来再加几行，不是靠继承或者补丁表达"标准模式加一点东西"——那种"只写差异"的补丁语义，仓库把它留在了第 09 章讲的分发层（cordis.patch.yml），换来的是每一份预设自己可以被完整读完，不用翻两个文件才拼出一份 Agent 到底能干什么。三份文件因此有大段重复的注释和配置——这不是疏忽，是作者自己写在已知限制里的一笔明确的可读性税。
如果四种模式真是四套产品会怎样？每加一个新模式，都要单独接一遍工具注册、审批策略、沙箱配置。现在加一个新模式，只是在 .agent-presets/ 下新开一个目录，写一份清单，需要的每一项能力全部找现成的包按名字点一下——这正是创造模式那个自省工具存在的理由：连"造一个新模式"这件事本身，都不需要碰宿主层一行配置。
6. 结语：带走一句话
标准、PTC、极简、创造，从头到尾只是同一个 Agent 预设目录里塞的四份不同清单——工具呈现在哪个开关上翻、循环和注册表要不要动、复制一份清单要付多少可读性税，答案全部能在第 06-09 章已经讲过的机制里直接查到，不用为"模式"这个词单独发明一套新概念。