dsh-prompt-studio

Prompt Studio 的 DeepSeek Harness 插件分发形态。插件在对话页注册 Prompt Studio 标签页，以同一组件列表展示运行时原生提示词和用户补充，并提供编辑、原生覆盖与完整请求预览。

组件模型

每个编排项使用同一结构：

interface PromptComponent {
  id: string
  kind: 'native' | 'supplement'
  role: 'system' | 'user' | 'assistant'
  position?: 'after_system' | 'anchored' | 'tail'
  order: number
  enabled: boolean
  template: string
  origin?: string
}

这些字段分别描述不同维度，不以 kind 代替角色或用途：

• kind 只区分来源：native 是 Host 在运行时发现的只读组件；supplement 是用户可编排并持久化的补充组件。
• role 决定内容归宿：
  • system 一律注册为有序 system section，最终与原生 sections 合并到全局唯一的 system 字段；此时不得设置 position；
  • user、assistant 进入消息序列，必须设置 position。
• position 只描述 user/assistant 消息所处的间隙：
  • after_system：全局 system 字段之后、第一条原生会话消息之前；
  • anchored：最后一条真实用户消息之后，找不到锚点时跳过；
  • tail：原生消息序列末尾。

anchored 与 tail 的区别：简单对话中最后一条消息往往就是用户输入，两者重叠；但存在工具调用流（user → tool_call → tool_result → assistant）时完全不同——anchored 插在用户输入之后、工具调用流之前，tail 插在整个序列最末尾（工具结果与助手回复之后）。需要紧贴用户问题补充指令用 anchored，需要模型读完完整上下文再看到的内容用 tail。

• order 有两种与归宿对应的含义：
  • system 组件的 order 是 system section 的全局混排层级，和原生 sections 一起升序排列；约定 -100 是身份区、0 是 persona、100–199 是工具区，其他负值也在 persona 之前；
  • user/assistant 组件的 order 只在同一个 position 间隙内排序，不参与跨间隙比较。
• origin 只用于覆盖。补充组件未设置 origin 时是普通注入；设置为某个原生组件 id 时，同一个补充组件即覆盖该原生组件，不存在单独的覆盖 kind。

同一消息间隙的补充组件按 (order, 声明顺序) 排列。system sections 由 Host 依 order 与原生 sections 全局混排。

内容合并

所有 system sections 最终渲染为同一个 system 字符串，补充内容以纯文本直接并入，不加任何包装标记。

user/assistant 补充先进入选定间隙。若补充组与间隙左侧或右侧的相邻原生消息 role 相同，补充内容会按先后关系合并进该原生消息的 content；若角色不同，则在该间隙创建新消息。相邻且同角色的补充也合并为一条消息。

原生覆盖

覆盖仍使用有序 marker section 和 system-prompt/assemble waterfall，不依赖静态原生目录：