dsh 系统提示词（system prompt）详解
DeepSeek Harness 在每轮模型调用前往系统提示词里组装了什么——固定身份、人格槽位、工具指引，以及改写它们的插件。
最近更新: 2026-10-04
每一轮对话开始前，模型都会先读到一段系统提示词。在 DeepSeek Harness（dsh）里，这段文字不是手工维护的文件，而是由官方 system-prompt 包（packages/core/system-prompt）在每次请求时实时装配：固定的身份行、你的部署人格（persona）、第一方工具指引，以及所有插件注册的 prompt 段落，按顺序合并成一条系统消息。
本页讲清这次装配里都有什么、谁能改它，以及三类热门提示词插件——persona 编辑器、prompt armor、思考语言注入——分别怎么接入。提示词发出去之后发生的事，请读 agent loop 指南；本页只谈这段文本本身。
TL;DR
- ▸系统提示词是逐轮装配的，不是存好的文件：system-prompt 包把注册的段落按 order 排序，用 renderPrompt 渲染成最终文本。
- ▸固定部分只有一行——「You are an AI agent powered by DeepSeek Harness.」，由 includeHarnessIdentity 配置控制（默认开启）。
- ▸不改代码也能加内容：personaPrefix 与 personaSuffix 两个配置字段，或者一个设置页里的 persona 插件。
- ▸插件通过 ctx.systemPrompt.section(...) 注入；标记为 complete 的段落会整段接管该作用域的系统提示词。
dsh 系统提示词从哪来
官方子系统文档把契约写得非常精确：system-prompt 包拥有「prompt 贡献方与一次装配调用之间交换的数据」。贡献方注册 PromptSection——每段都有唯一的 name、一个数字 order，以及静态或按次解析的 text。段落按 order 升序拼接（同序按名字排），合并结果就是模型收到的系统消息。
三个术语撑起整个设计：
PromptSection
插件贡献的一个段落：name、order、text（静态或按装配解析的函数），可选 undefined} 插值。重名注册直接抛错。
Assembly（装配）
一次 assemble() 调用：合并全局层与请求作用域层，解析工具 schema 与变量，再跑 system-prompt/assemble 瀑布。
Surface node 0
渲染后的文本作为「派生历史的系统消息」提交——首轮作为 surface 节点 0 追加，文本变化时就地替换。它不是请求字段。
模型实际收到什么：按顺序
第一方默认全开时，渲染结果遵循固定顺序——从 −1000 的身份行到 10200 的人格后缀，下面每个槽位都真实存在，与包 README 记载的渲染顺序一致：
- 1
固定身份行
order −1000 · includeHarnessIdentity「You are an AI agent powered by DeepSeek Harness.」——唯一的硬编码句子，排在最前。includeHarnessIdentity: false 可去掉它，官方只建议完全接管提示词的部署这么做。
- 2
部署人格前缀
order 0 · deployment:persona-prefix你的 personaPrefix 配置，或 persona 插件的贡献。README 注明这个槽位承载模型名介绍。默认为空。
- 3
第一方通用指引
first-party guidance生成的工具 SDK 与结构化输出指引：告诉模型怎么调用已挂载的能力。注册的工具 schema 也在同一次装配中随行。
- 4
Harness source 行
order 10000 · harness source带环境信息的后缀从 order 10000 的 harness source 条目开始。
- 5
Web surface
order 10100 · Web surface部署暴露的本地 Web URL，在 order 10100 处随后渲染。
- 6
部署人格后缀
order 10200 · deployment:persona-suffix你的 personaSuffix 配置——order 10200，全提示词的最后一句话。
- ↻
动态运行时上下文
独立通道PromptContext → user-role snapshot有序的 PromptContext 不进入系统文本：它们作为带来源的 user-role 快照进入模型历史——另一条对缓存更友好的通道。includeRuntimeContext: false 或作用域级 suppressor 可整体移除。
部署注册的其它内容落在它声明的 order 上——外部贡献可用任意有限整数。还有一个逃生舱：标记 complete: true 的段落会成为唯一的提示词段落——装配仍然解析工具与变量，然后以这段原文作为全部系统提示词；若有两个生效的 complete 段落，装配会直接报错中止，而不是送出残缺提示词。
谁能改它：三类插件
几乎没人手改 YAML——社区通过插件改提示词。本站目录在此簇收录了 40+ 款插件，按实际用途分三类（星标 2026-10-04 核验）：
Persona 编辑器
xilin3/dsh-prompt-persona（★14）在设置页直接编辑部署人格并实时预览——不写代码填两个人格槽位的方式。同样的槽位用原生 personaPrefix / personaSuffix 配置也能改。
Prompt armor（提示词护甲）
minglink/dsh-infinite-gen-4（★2,294，本簇星标最高）是最知名的 armor 类条目：它加固已部署的提示词、抵抗探测与套取，而不是往里加文字——做防护，不做注入。
注入与提示词上下文
len7183/dsh-think-zh（★32）与 max-null/dsh-chinese-thinking（★10）注入思考语言指令（见下节）；asktheway/dsh-auto-memory（★81）把长期记忆作为动态运行时上下文贡献，而非提示词文本。
中文思考这条差异轴
这个簇最早的需求来自中文用户：即便对话用中文，模型的思考链默认仍是英文。官方讨论 #8798 收集了这条诉求，两个社区插件从提示词层给出答案——不用 fork，也不用换模型。
len7183/dsh-think-zh（★32）在设置里加了思考语言档位（简体中文/默认英文），回复语言跟随提问语言，代码与标识符保持原文；max-null/dsh-chinese-thinking（★10）是更轻量的替代。两者的原理都是往装配好的提示词里注入一条指令——这正是人格槽位与插件段落存在的意义。
成本账：提示词如何到达模型
README 对这笔账算得很坦率：身份行开启后是每请求的固定成本，人格前后缀与插件文本随每次请求重复，开销随渲染长度伸缩。对冲机制是缓存，不是删减：
- ▸渲染结果不变时，提示词保持前缀稳定：历史中的系统节点原地不动，KV 缓存逐轮复用。
- ▸任何变化——改人格、换工具、调顺序——都会从第一个变化的 token 起使缓存失效。
- ▸在同一请求系列的后续调用中声明 systemPromptUpdate: 'in-history' 时，变化后的提示词追加在缓存历史之后，前缀到历史为止仍然可复用。
- ▸上下文压缩压不掉这部分——压缩作用于保留的历史，不作用于逐轮装配的提示词。省的杠杆是少注册，而不是更用力压缩。
常见问题
关于 dsh 系统提示词，大家最常问的几个问题。
dsh 系统提示词能改吗？
能，三种方式，威力递增。配置：在 system-prompt 插件项上设 personaPrefix 与 personaSuffix（includeHarnessIdentity: false 可去掉身份行）。设置页：dsh-prompt-persona 这类 persona 编辑器可视化改同样的槽位，不碰 YAML。代码：用 ctx.systemPrompt.section(undefined) 注册段落——标记 complete: true 的段落会整段接管所在作用域，但两个生效的 complete 段落会让装配直接失败。
系统提示词变长会拖慢会话吗？
它多花 token，而缓存能消化掉大部分。身份行加人格加插件文本随每个请求重复，但只要渲染结果不变，历史中的系统节点就原地不动，服务商侧 KV 缓存在轮与轮之间持续复用。只有从第一个变化的 token 起才重新全额计价——所以每轮都在变的 persona 文本才是贵的模式，稳定的文本在首次请求之后几乎免费。
插件是怎么注入进提示词的？
通过注册表。插件调用 ctx.systemPrompt.section(undefined)，段落就会在每次装配时按 order 升序拼进结果。通过 agent 自己的 ctx 注册的是作用域内条目：只对该 agent 遮蔽同名全局项。合并之后，system-prompt/assemble 瀑布还可以改写结果——除非存在 complete 段落，监听者不能增删它。
不同 profile 看到的系统提示词不一样吗？
可以不一样。装配把全局层与请求作用域层合并，作用域内的段落、变量与工具提供方按 agent 遮蔽同名全局项——同一个安装里，工作 profile 和个人 profile 注册了不同 persona 段落，就会拿到不同的提示词。固定身份行与第一方指引保持一致，除非某个 profile 显式关掉它们或自带 complete 段落。
它是模型内置的系统提示词吗？
不是——这是两层东西。模型厂商的行为调校在权重里，dsh 看不见也改不了。dsh 系统提示词是 harness 在运行时装配、以系统消息发送的文本；其中固定的只有一行身份句。正因为这层分离，同一个模型在 dsh 和别的 harness 下表现可以不同，提示词层插件也能在你挂载的任何模型上生效。
在哪里能看到实际装配出的提示词？
下面两个官方来源就是权威契约：子系统文档列出精确类型，包 README 记载渲染顺序与全部配置字段。运行时，会话的 trajectory 记录了每轮模型实际收到什么——配合 loop 记录的系统节点替换日志，能精确看到提示词在会话中哪一刻发生了变化。
相关指南
系统提示词在整张原理图里的位置。
来源与证据
本页每个机制都能追溯到下列来源；commit 与星标核验于 2026-10-04。