DeepSeek Harness 系统提示词怎么来的？DSH plugin 的提示词组装与上下文来源

DeepSeek Harness 的系统提示词不是一份写死的文本，而是由 system-prompt 包在每轮开始时组装成的前缀：里面放工具说明、系统指令与各插件贡献的片段，再交给模型（来源）。 这篇讲这个前缀从哪来、怎么拼、为什么会随插件变长；整条链路见《DeepSeek Harness 一轮对话怎么跑》，工具说明这一块怎么进前缀见《DeepSeek Harness 工具怎么注册》，开销评估见《dsh plugin 的上下文开销》。

为什么值得先搞懂系统提示词

系统提示词是每一轮里模型最先读到的内容，它决定模型「知道有哪些能力、遵守什么规则、能调用什么工具」——换句话说，插件的很多效果，最终都要通过它才落到模型身上（来源）。 把它当成一个可分析的对象之后，三类常见疑问都有了着落：

1. 「我说的话为什么模型没照做」：模型的输入不止你的一段话，还有一整段前缀；前缀里的规则与你的指令会一起影响结果，二者冲突时表现得像「没听你的」。
2. 「装了插件为什么行为变了」：插件要么往前缀里加说明，要么改变工具清单，两者都会被模型读到，于是行为随之改变。
3. 「为什么上下文突然不够用了」：前缀每轮都要发一遍，它占的预算会直接挤压剩余窗口，装的层越多越明显。

反过来说，如果把系统提示词当成黑盒，就会把「插件、提示词、模型行为」三件事混在一起，出问题时无从定位。把它拆成「谁组装、装了什么、什么时候装」三个问题，一切就变得可追。

谁组装：system-prompt 包

DeepSeek Harness 的系统提示词由 system-prompt 包组装：它在一轮开始时把各类片段收拢成一段前缀，然后交给模型（来源）。 三个要点：

1. 前置而非事后：前缀在模型调用之前就拼好，属于这一轮输入的一部分；它不是模型输出之后的补充说明。
2. 统一收拢：插件不各自拼字符串，而是把片段交给 system-prompt 统一拼接。这样「谁往提示词里加了什么」有一个集中入口，便于观察与排查。
3. 每轮都重建：因为它反映当前装载的 DSH plugin 与配置，所以轮与轮之间可能不同——中途改了配置或换了插件，下一轮的前缀就可能跟着变。

这也是它在核心子系统里与 agent-loop、llm、tools、session 并列的原因：它是链路上专门负责「拼输入开头」的一环，而不是某个插件的私有逻辑。

前缀里放了什么：三类内容

DeepSeek Harness 的系统提示词前缀里主要有三类内容：工具与能力说明、系统级指令，以及各 DSH plugin 贡献的片段（来源）。 逐类看：

1. 工具与能力说明：告诉模型当前能用哪些工具、各自的用途与参数范围。这部分与 tools 子系统相关联——注册的工具越多，需要写进前缀的说明通常也越多，细节见《DeepSeek Harness 工具怎么注册》。
2. 系统级指令：框架层面的规则与约束，决定模型的行为边界。它由框架给出而非某个插件的临时提示，因此对所有轮次都成立。
3. 插件贡献的片段：每个装载的 DSH plugin 都可以往前缀里加内容，累积起来构成完整提示词。这一层最灵活，也最容易在装插件后悄悄变长。

三类内容拼在一起，才构成模型每轮实际读到的开头；理解这个构成，就能理解为什么「换一个插件」有时会连带改变模型在别处的表现。

组装发生在什么时候：每轮开始前，且每轮重建

组装发生在每一轮开始、模型被调用之前；并且它不是一次成型，而是每轮重新拼一遍（来源）。 两个性质值得分清：

1. 「前置」决定了它的地位：因为排在模型之前，它是这一轮输入的第一段，模型对它的读取优先级很高。
2. 「每轮重建」决定了它会变：前缀反映的是「此刻」装载了哪些插件、配置长什么样；所以同一次会话里，前后两轮的前缀未必相同。
3. 它与会话日志不是一回事：会话日志是累积的事件记录（见《DeepSeek Harness 会话存在哪怎么查》），而前缀是每轮现拼、拼完即用于本次调用；别把「历史记了什么」与「这轮前缀写了什么」混为一谈。

一个直接的推论是：想让新插件或新规则「被模型看到」，它必须能进入前缀组装这一环；进不了这一环的改动，模型是读不到的。

DSH plugin 怎么影响提示词

DSH plugin 通过向提示词组装环节贡献片段来影响系统提示词——这类内容由 system-prompt 包统一收拢拼接，插件通过 ctx.systemPrompt 这类服务入口参与，而不自行拼字符串。 两点理解：

1. 贡献走服务入口：在「一切皆插件」的架构里，插件不直接改内核文本，而是把片段交给框架的提示词服务；因此贡献的边界清晰，也便于集中排查。
2. 生效范围是「之后的所有轮次」：因为前缀每轮重建，只要插件处于装载状态，它的贡献就会持续出现在后续轮次里——这也解释了为什么装插件的影响往往是「持续性」的，而不是只作用一次。

因此，判断「某个插件会不会影响模型行为」，可以看它有没有参与提示词贡献、以及贡献了多少内容。

为什么装了插件，上下文会变长

装插件后上下文变长，是因为插件贡献的片段会进入 DeepSeek Harness 的系统提示词前缀，而前缀每一轮都要发给模型（来源）。 把开销的来路拆开：

1. 前缀每轮都发：它不像一次性说明那样只出现一次，而是每一轮都占用输入预算。
2. 片段会累积：每多一层插件，就可能多一段说明或声明；单个片段也许不长，叠在一起就明显了。
3. 工具说明跟着涨：能力类插件往往同时增加工具，而工具说明也要写进前缀，于是「加了工具」与「加了文本」是并行的两份开销。
4. 挤压可用窗口：前缀占得越多，留给对话内容与模型输出的空间就越少——这正是需要评估上下文开销的原因。

具体怎么评估、怎么权衡，见《dsh plugin 的上下文开销》。

怎么减少某个插件对提示词的影响

要减少某个 DSH plugin 对系统提示词的影响，通常从两层入手：一是在 profile 层停用或移除该插件条目，二是看它是否有设置项可以关掉相关行为。 按代价从轻到重排：

1. 先查设置开关：有些插件会把「是否贡献提示词片段」做成可配置项，关掉它往往比卸载更省事。
2. 再停用条目：在 profile 的清单里停用该插件，它整层不参与启动，自然也不再贡献任何片段。
3. 最后才考虑卸载：卸载会连带影响它提供的工具与命令，所以放在确认「不需要它」之后再动。
4. 对比验证：改动前后各观察一轮的表现与上下文占用，确认变化确实来自这一处，而不是别的原因。

理解系统提示词的注意事项

把系统提示词当成「每轮重算的前缀」来看，很多现象就解释得通。

1. 它不是固定文本：随插件与配置变化，每轮都可能不同。
2. 它是上下文的开头：与后续会话内容共同构成模型输入，读取优先级很高。
3. 前缀 ≠ 会话日志：一个是每轮现拼的输入开头，一个是累积的事件记录。
4. 加内容有代价：每段片段都占预算，装的插件越多通常越长。
5. 想减负从两层入手：profile 层停用或移除插件条目，或关掉插件自身的设置开关。
6. 排查「谁加的」看贡献来源：先确认是哪一层插件引入的片段，再看它能否关掉。
7. 完整链路见《DeepSeek Harness 一轮对话怎么跑》，工具说明见《DeepSeek Harness 工具怎么注册》。

来源：DeepSeek Harness 官方文档 - 核心子系统、官方文档 - 工具子系统。