DSHarness 系统拆解 固定基线 47f943859b · 36 已复核 / 0 撰写中 / 36 章
English
核心运行时·第 07 章

提示词组装与上下文注入

Section registry、顺序、作用域、工具 schema 与动态上下文

已复核上游 47f943859b范围: 分析 system prompt registry、section 顺序、per-step 重建、agent.inject 与上下文插件。

结论:Prompt 是一份每 step 求值、可由日志重建的程序

DeepSeek Harness 不会在 session 创建时一次性生成 system string。每个拟执行的模型 step 都重新求值 scoped prompt provider、规范化可见 tool schema、投影易变 runtime fact、接纳带 source 的 context message,并在模型 I/O 前记录最终有效的 request state。

这一架构同时服务三个目标:per-Agent composition、确定性 replay 与 provider prefix-cache 稳定性。它刻意把稳定指令和易变事实分开,而不是把所有 model-visible input 都叫作“system prompt”。

1. 四条语义不同的模型输入通道

通道表示耐久形式典型内容变化行为
稳定指令PromptSection[]request/header.systemHarness identity、persona、plan policy、工具使用指引每 step 重渲染;只有值变化才写新的完整 header
工具接口ToolSchema[]request/header.tools当前 Agent scope 可见的名称、描述和 JSON 参数每 step canonicalize,并按顺序比较
易变 runtime factPromptContext[]带 source 的 user/message snapshotSandbox mode、approval policy、delegation status完整渲染 snapshot 变化时才追加
Context pluginagent/pre-step messages带 source 的 user/message工作区指令、当前时间、tmux 位置、显式 session reference每个插件自己拥有刷新、顺序、边界和 provenance
架构不变量

四条通道都会在 provider dispatch 前获得可重建锚点:稳定 system/tool 状态写入 request-header event,message-shaped context 进入 session surface;Loop invariant 再从日志独立重建两侧。ROOT-MODEL-LOGGEDLOOP-REQUEST-INVARIANT

2. Registry 有五种可逆贡献

生产 API

SystemPrompt 以 effect 注册 section、context、runtime-context suppressor、tool-schema provider 与 variable。注册/释放都会发 system-prompt/change;同一 layer 内重复的具名项被拒绝。order -100 的 identity 与 order 0 的 deployment persona 也是普通 section,并非隐藏的字符串拼接。PROMPT-REGISTRY-CONTRACT

注册Identity求值Teardown
section({name, order, text, complete?})Name 在单 layer 唯一Text provider 每 assembly 一次;稍后插值随 owner effect 删除精确 entry
context({name, order, text})Name 在单 layer 唯一runtime context 被 suppress 时完全不求值删除精确 entry
suppressRuntimeContext()匿名独立 tokenscope chain 任一 active suppressor 即获胜只移除该 suppressor
tools(provider)匿名 provider membership返回 visible schema 与可选的 restriction 前 known names移除 provider
variable(name, provider)严格小写 identifier每 assembly 解析一次;允许返回 undefined删除精确 name

默认 Agent Loop 贡献三个变量:providermodelcwd,值分别来自 Agent 和 Session。这是 ownership 选择:template 只引用值,runtime object 仍是事实 owner。

3. Scope shadowing 发生在 provider 求值之前

Scope 语义

Assembly context 会把 agentscope 同时设为同一 Agent。全局贡献先被最远祖先、再被最近 scope 叠加;同名 section、context 或 variable 由最近 scope 获胜。DESIGN-SCOPED-LAYERSPROMPT-STEP-BOUNDARY

测试定义的行为

Scoped deployment:persona 只替换对应 scope 的 global persona。更重要的是,被覆盖的 global text provider 完全不会执行——effective map 在 text 求值之前就已形成。PROMPT-SCOPE-SHADOW

机制推导

Shadowing 不是渲染后的字符串替换,而是 provider selection。Child Agent 可以继承 parent composition,只覆盖一个 named slot,无需执行被替代 provider 或复制整份 prompt。

4. 一次 assembly 有严格求值顺序

1

解析 scope 与 suppression

收集已有 scope chain,判断 global 或 inherited suppressor 是否 active。

2

求值 variables

先 global,再从祖先到最近 scope;近层 provider 覆盖同名值。

3

物化 named entries

在 text provider 执行前构建 effective section/context map。

4

快照 tool providers

固定本 generation 的 membership,逐个调用 provider,并 clone schema parameters。

5

排序与求值

按 numeric order stable-sort section/context,强制最多一个 complete,求值 text,并 canonicalize tools。

6

运行 expert waterfall

system-prompt/assemble 可以合作式改写 mutable assembly,或直接短路。

7

重新施加硬约束

把原始已求值 complete section 恢复为唯一 section;suppression active 时清空 contexts。

生产控制流

assemble() 直接实现上述顺序。Waterfall 前的 registry output 具有确定性;返回值具有权威性,但 complete 与 suppression 约束会在最后再次施加。PROMPT-ASSEMBLY-PIPELINE

Mutation 测试

Tool-provider membership 先快照,因此 provider 求值期间新注册的 provider 只进入下一次 assembly;variable 使用 live map iteration,因此早期 variable provider 注册的新 variable 可进入同一 generation。每次 assembly 都获得新的 section/context/tool 容器,tool parameters 也会 structural clone。PROMPT-ASSEMBLY-MUTATION-TESTPROMPT-VARIABLE-TEST

5. complete 约束 section,不锁死整个 assembly

精确语义

一个 effective complete: true section 不会跳过 variable、context、tool 或 waterfall。Waterfall 仍完整运行;随后 registry 把原始已求值 complete section 恢复为唯一 section。两个 effective complete section 会让 assembly 失败。PROMPT-ASSEMBLY-PIPELINEPROMPT-ASSEMBLY-MUTATION-TEST

  • Listener 不能替换 complete section 的 name 或已求值 text。
  • Listener 仍可以改变 variables、contexts 与 tools。
  • 因为 interpolation 更晚发生,修改被引用 variable 仍能改变 complete template 的最终文本。
  • Runtime-context suppression 会清掉 waterfall 重新加入的 context。
设计评价

complete 是 section authority,而不是不可修改的 whole-request mode。它保留 tool/context composition;但若调用方要求 byte-fixed complete prompt,也必须控制该 template 引用的 variables。

6. 渲染严格,而且刻意延后

Renderer 合同

Section/context provider 返回未插值文本。渲染只接受 name 匹配 [a-z][a-z0-9_]*{{name}};unknown、undefined 和 malformed reference 都快速失败。Own-property lookup 阻止未注册的 prototype name;替换值不二次扫描;空项被丢弃;section 以双换行连接。PROMPT-STRICT-RENDERPROMPT-VARIABLE-TEST

失败位置此前已记录什么绝不会发生什么
Assembly/provider/tool-order failureturn/startstep/start、request header 或 adapter call
Runtime-context interpolation failureturn/start不会打开 step
agent/pre-step rejectturn/start;claimed inbox splice 已耐久无 step/model request;Turn 以 blocked 结束
首个 accepted message list 为空Turn boundary 与 claim effect无 step;Turn 以 completed 结束
System-section interpolation failureturn/startstep/start、已进入的 user messages无 request dispatch;step/end 仍在 finally 中闭合
取消测试

Assembly 阻塞时 cancel 或 owner disposal,会产生没有 step、chunk、assistant message 或 adapter request 的 aborted Turn。PROMPT-CANCEL-TEST

7. Tool schema 也是 prompt 确定性的一部分

排序算法

未显式配置时,schema 按与 locale 无关的 code-unit 字典序排序。显式 toolOrder 必须且只能包含一个 <unlisted-tools> marker,不能重复;未知配置名失败;restriction 前已知的名字可以在当前 scope 缺席;未列出的 visible tool 在 marker 位置内排序。PROMPT-TOOL-ORDER

Schema visibility 与 usage guidance 是两项独立注册。隐藏 tool schema 不会自动删除另一个插件贡献的工具说明;要求二者同步的 package 必须让自己的 guidance provider 检查当前 scope visibility。

设计评价

Canonical order 同时影响正确性、replay 与 cache。Registry 只保证 expert waterfall 之前的顺序;之后新增或重排 tool 的 listener 自己承担确定性。该层也不会静默去重同名 schema。

8. 组装频率:每个拟执行 step 一次,而非每次 retry

Step 边界

preStep() 依次 claim inbox、组装 scoped prompt、渲染 dynamic context、提出 snapshot,再进入 agent/pre-step。只有被接纳且非空的 decision 才打开 step/start,并把该 assembly 交给 step()PROMPT-STEP-BOUNDARY

Retry 边界

step() 在 provider-retry loop 之外只渲染一次 system string。Retry 会在同一编号的 Turn/Step 内重新构建 request config、folded header 和 durable messages,但复用该 Step 的 system 与 tool assembly。PROMPT-RETRY-BOUNDARYLOOP-REQUEST-ERROR-TEST

事件重新 assemble?原因
Tool result 需要下一次模型请求这是新拟执行 Step;scope provider 与 runtime fact 可能已变
下一次 user Turn每个拟执行 Step 都求值当前 composition
Provider error 获得 retry actionRetry 是同一 Step 内的另一次 request attempt
Assembly 后 prompt registration 改变下一 Step当前 Step 已拥有 detached assembly snapshot
Rejected/empty proposed Step已经 assembleAdmission 在 assembly 和 dynamic-context projection 之后决定

9. Dynamic runtime context 是 append-only 完整快照

Projection 状态机

Runtime context 把 named sections 渲染在固定的“supersedes earlier snapshots”声明之后。RuntimeContextProjection 恢复 Session surface 中最新仍 retained 的 owned snapshot;只有完整值变化才提出 sourced user message;context 消失时发明确 clear marker;replacement 从 surface 移除 snapshot 时忘记 retained state。LOOP-RUNTIME-CONTEXT

1

无历史值 + 当前为空

不发消息;没有旧语义需要清除。

2

与 retained text 相同

不发消息;历史已携带有效快照。

3

变成新的非空值

提出一个完整 user-role snapshot,保留 plugin 与 named-section provenance。

4

值变为空

提出 clear tombstone,避免旧 snapshot 继续保持语义有效。

5

Compaction 替换 retained snapshot

重置 retained state;下一 Step 即使文本未变也重新声明当前 context。

Candidate 不会自行 commit。只有最终 agent/pre-step decision 让它 enter,Loop 才 append;listener 可以删除、改写、重排或 reject。若被删,projection 不会错误推进,下个 Step 可再次提出。

10. 其他 context plugin 刻意使用 pre-step 通道

Plugin刷新/准入规则位置与 provenance
Agent instructions组合 workspace files 并追踪工具触及路径;初始 Step 不运行时保留 pending context插在 claimed batch 后、driver runtime context 前 PROMPT-CONTEXT-AGENT-INSTRUCTIONS
Time context默认每 Step;若 refresh interval 仍覆盖上次 injection 则跳过;解析 browser 或 fallback timezone在 downstream pre-step decision 后追加 sourced snapshot PROMPT-CONTEXT-TIME
Tmux context只在 step 1,且 shell 可用、refresh 到期、location 查询成功、状态变化把 sourced snapshot 放在 decision 前面 PROMPT-CONTEXT-TMUX
Session reference显式 host preparation;按 mention 顺序 snapshot 有界 referenced Session surface返回单个 aggregated recall message,由 caller enqueue
设计评价

这些输入没有被误叫作 system section,因为它们的刷新、消息位置、source attribution 与 retention 规则各不相同。Pre-step waterfall 很强,但语义是分布式的:最终 message order 取决于 listener nesting,以及每个插件在 next() 前后如何操作。

11. Request header 让稳定部分可 replay

Canonical header

Header 保存 resolved call config、哪些字段来自 adapter default、渲染后的 system text 和有序 tool schemas。空 system/tool collection 归一为字段缺席;equality 比较 config、adapter-default marker、system bytes 与有序 schema;offline replay fold 最后一份完整 snapshot。PROMPT-HEADER-CANONICAL

写入策略

第一次 request 写 initialresume;之后只有 canonical equality 失败才写完整 change snapshot。测试证明每 Step 重组装但值不变时不会增加 header,真实 section 变化才会写第二份。LOOP-REQUEST-BUILDPROMPT-HEADER-CHANGE-TEST

Frozen provider request 最终由当前 header 与 Session.deriveMessages() 组成。这避免了第二份隐藏 conversation store:稳定指令与 message history 都有耐久锚点。

12. KV-cache 命中是涌现结果,不是 Harness 自有缓存

Wire 布局

直接 DeepSeek adapter 把 system text 序列化为首条 wire message,再追加 derived history;始终请求 streaming usage;该路径没有设置显式 cache-control directive。PROMPT-DEEPSEEK-WIRE

机制推导

Cache reuse 来自 byte-stable prefix:稳定的 system/config/tools、append-only message history,以及把易变事实作为 user-role snapshot 追加,而不是重写开头。该路径中的 DeepSeek Harness 不维护独立 KV cache。

未执行的真实 API 测试

上游 key-gated E2E 要求 tool round trip 与后续 Turn 中,首请求后的每次请求都报告正数 provider cache-read token。本研究未安装依赖或凭据,因此这是已审阅的测试合同,不是本地观察结果。PROMPT-CACHE-E2E

13. 优势、代价与未解决边缘

选择收益代价或边缘
每个 proposed Step 重 assemble没有 stale change-driven cache;始终求值当前 scope每 Step 都支付 provider 与组装开销
完整 header snapshot重建与 equality 简单、局部大工具目录变化时比 delta 占更多日志
Append volatile context稳定 provider-cache prefix 并保留 provenanceSnapshot 在 surface replacement/compaction 前持续累积
严格 variable/tool orderTypo 在畸形 request 到达模型前失败某些配置错误要到首次 assembly 才出现
Expert waterfall不改 Loop 即获得最大组合能力Waterfall 后的顺序、唯一性与一致性由 listener 负责
稳定 numeric section order不同 order 值之间具有简单确定性相同 order 回退到 registration order,受 composition 影响
Per-Step assembly、per-attempt request buildRetry 可读新耐久 history/config,同时保持 Step 语义Retry 中途的 prompt 变化要等下一 Step
本章评价

最有价值的设计不是 template engine,而是语义位置:稳定 policy 进入可重建 header;易变 policy 进入 sourced snapshot;情境 context 进入独立治理的 message。Replay 与 cache 因而成为同一数据模型的结果,而不是两套分离优化。

本章复核清单

  • 已追踪五种 registry contribution API 与 scoped effect ownership。
  • 已重建精确 assembly 顺序,包括 membership snapshot 与 live variable iteration。
  • 已确认 scope shadow 在 displaced provider 求值前发生。
  • 已分开 section、tool schema、runtime snapshot 与 pre-step message 四条通道。
  • 已确认 proposed-Step boundary 与 same-Step provider-retry boundary。
  • 已把严格 render failure 映射到准确的 durable Turn/Step outcome。
  • 已确认 header canonicalization、change suppression、request freeze 与 log reconstruction。
  • 已审阅但未声称运行 key-gated DeepSeek cache E2E。

我的学习体会

内容仅自动保存到当前浏览器,不上传、不进入仓库。你可以导出 Markdown 自行归档。