DSH plugin 系统提示词怎么加？DeepSeek Harness 的段落、上下文与装配 waterfall

DSH plugin 往系统提示词里加内容，不是拼接一个字符串字段，而是通过 ctx.systemPrompt 注册贡献者，再由一次组装调用把它们解析、排序、渲染成 surface 节点（来源）。 本文面向 DSH插件 / DeepSeek插件 作者，讲清四类贡献的注册与排序、提示词为什么是「surface 节点 0」而非请求字段，以及装配 waterfall 的权威性与上限；提示词从哪来、为什么会变长的原理见 系统提示词解析，这里只讲开发者要实现的契约。

DSH plugin 系统提示词的四类贡献与排序

系统提示词组装包管理提示词贡献者与一次组装调用之间交换的数据，共有 section、context、tools、variable 四类贡献（来源）。

1. section — 提示词段落本身。PromptSection 含唯一的 name（重复注册抛错）、order（升序拼接，相同 order 用名称的代码单元顺序）、text（静态字符串或每次组装求值的 provider，可引用 {{variable}}，由 renderPrompt 稍后插值），以及可选的 complete。
2. context — 与 section 对应的缓存安全结构，物化为持久的 user-role 快照；PromptContext 同样以 name 唯一、order 升序 join，text 为空则不贡献任何内容。
3. tools — 工具 schema 提供方，返回 ToolProviderResult：schemas 是本次组装对模型可见的 schema 集合，knownNames 是限制前的名称全集，用来区分「配置名拼写错误」与「已知工具在此作用域中被有意隐藏」。
4. variable — 提示词变量，name 形如 [a-z][a-z0-9_]*；provider 可以返回 undefined，但渲染引用该值的段落会失败。

排序是两段式的：各段先按 order 升序，再按名称的代码单元顺序排列。仓库贡献方通过 getSectionOrder() 解析服务持有的具名分配（如 DEPLOYMENT_PERSONA_PREFIX / DEPLOYMENT_PERSONA_SUFFIX），runtime-context 贡献方通过 getContextOrder() 解析独立分配。作用域上，scoped 段落与变量阴影同名 global，同一层内的重复与非有限 order 都会抛错。

DSH plugin 系统提示词是 surface 节点 0，不是请求字段

协作式组装完成后，一个有效的 complete 段会成为唯一的提示词段落；agent loop 用 renderPrompt 渲染这些段落，并把文本作为 system/message surface 节点提交（来源）。 提交方式有三种：

1. 首个步骤 — 作为 surface 第 0 号节点追加。
2. 渲染文本变化时 — 原地替换该节点。
3. 序列延续且已准备调用声明了 systemPromptUpdate: 'in-history' — 把非空更新追加到已缓存历史之后。

关键结论：系统提示词作为派生历史中的消息而不是请求字段到达模型。所以修改提示词要走「替换或追加 surface 节点」，而不是去改请求头；这也解释了为什么提示词变更能被日志与回放统一处理。

context 这一路则更克制：组装会解析并排序这些贡献，但 agent loop 仅在完整当前快照发生变化或被 compaction 移除时，才把它记录在保留的模型历史之后。

DSH plugin 装配 waterfall 的权威性与上限

system-prompt/assemble 是对组装后 sections、contexts、tools、variables 的专家级 waterfall，作用域过滤分发，scoped 监听器只收到该 scope 的组装，返回值具有权威性（来源）。 但有三个不可越界的约束：

1. complete 段会在 waterfall 之后恢复 — 如果注册了生效的 complete 段，组装在 waterfall 后把该段恢复为唯一提示词段落，因此监听器无法添加或替换该 scope 的系统提示词。多于一个生效的 complete 段会让组装失败。
2. signal 只属于本次组装 — waterfall 收到的 signal 仅控制本次显式组装请求，不得保留用以控制后续轮次。
3. 保留名与抑制 — tools() 提供方返回保留的 TOOL_ORDER_REST 名称会让组装失败；suppressRuntimeContext() 可以在调用 context 的作用域内抑制全部动态 runtime-context 贡献，而不改动拥有或强制这些事实的服务，多个抑制器各自独立可处置。

另外，system-prompt/change 是未过滤的注册表通知（全局变更影响每个 scope）；ctx.systemPrompt.assemble(context) 会组装 global 与 scoped provider、分离工具参数、应用规范排序，再跑 waterfall，最后强制任何 complete 段。

写完自检三项：name 是否唯一、order 是否有限；想整体替换提示词时是否用了 complete 而不是在 waterfall 里去改结果；是否误把 signal 缓存起来控制后续轮次。想找提示词类插件的社区实现，你可以在 DSH Plugin Hub 检索；扩展点归属判据见 功能→机制映射。