持久调查上下文NickUserVorname/dsh-durable-context

DSH 持久上下文

一个由失败驱动的实验性控制层，用于在长时间的 DeepSeek Harness 会话中保留调查状态，并且仅在其相关语义已有存续表示之后，才回收旧上下文。

该项目将三种容易被混为一谈的操作区分开来：

1. 构建持久的调查状态；
2. 将该状态投射回普通模型上下文；
3. 授权对旧的活动上下文进行不可逆的回收。

核心规则是：

保存状态与证明其对话来源可以安全移除，是不同的转换。

一次成功的检查点可以推进持久项目状态，而无需授予修剪产生该状态的更早对话的权限。

从这里开始

该仓库保存了实时录像、机器可读的资格证据、回顾性工程报告、技术规范，以及一份冻结的实现摘录。

实时资格验证

干净的 Git 根目录资格验证

选择性捕获、延迟转移与全新聊天恢复

这是最干净的端到端资格验证运行。

一个新初始化的 Git 工作区启动时没有先前项目的持久注入。该运行随后展示了：

- 普通对话材料不会自动进入调查性持久状态；
- 对 18 张截图的分析产生了结构化的调查状态；
- 先前的管理事实 M7RK-5316 在初始调查检查点中仍然缺失；
- /compress 随后审计了更早的来源跨度，并显式转移了 M7RK-5316；
- 随后的宿主注入包含了被转移的事实；
- 一个全新聊天在用户未重复的情况下回忆起了 M7RK-5316。

来自同一次运行的机器可读证据被保留为一个资格验证案例：

2026-08-28 选择性捕获与延迟转移

pre-compress checkpoint
|
| M7RK-5316 absent
v
/compress coverage audit
|
| M7RK-5316 explicitly transferred
v
post-compress host injection
|
| M7RK-5316 present
v
fresh-chat recall

真实世界多图像分析

长时间运行的真实世界资格验证

这段较长的录像展示了系统在混乱的迭代工作中运行，而不是一个构造的金丝雀测试。

该运行包括：

- 跨多张图像的分析；
- 一条未能提供实际图像像素的工具路径；
- 一次错误的证据解读；
- 在图像被实际读取后的后续纠正；
- 将纠正及相关约束保留在持久调查状态中；
- 错误之后继续工作；
- 宿主注入的项目状态；
- 在全新聊天中继续。

重要的部分不仅仅是持久性。

它展示了：

failure
-> correction
-> 持久约束 / 证据更新
-> 后续复用

非 Git 项目边界观察

状态在聊天/UI 重置和文件夹重命名后仍然存在

在以下情况之后，先前的持久上下文仍会被注入：

- 先前的 DSH 对话被删除；
- 工作区从 DSH UI 中移除；
- 同一个非 Git 文件夹被重命名；
- 从重命名后的文件夹打开一个新对话。

先前状态被注入到另一个新的非 Git 项目

另一个新的非 Git 文件夹作为全新的 DSH 项目打开，但先前项目的持久调查状态仍被注入其中。

这些录屏共同表明，在观察到的非 Git 设置中，仅凭不同或重命名的文件夹不应被假定为能够建立持久的项目隔离。

干净的 Git 根目录资格验证提供了对比观察：在执行 git init 之后，先前项目状态不再被注入。

这些录屏记录的是观察到的当前运行时行为，而非 DSH 内部项目身份算法的完整规范。

早期基线

同一工作区跨聊天注入

最早保存的录屏展示了基本的跨聊天路径：来自现有 DSH 工作区的持久项目状态被注入到在该同一工作区中打开的新聊天中。

后续的资格验证录屏逐步测试更困难的情况。

机器可读的资格验证

干净的 M7RK-5316 资格验证被保存为单一证据链：

资格验证证据

它包含：

01-pre-compress-state-checkpoint.raw.txt
02-compress-coverage-audit.raw.txt
03-post-compress-context-injection.raw.txt
README.md

第一个产物包含已开发的截图分析状态，包括 known、constraints、decisions、evidence、do_not_repeat、未决事项和下一步行动，而此时 M7RK-5316 尚未出现。

/compress 产物审计候选表面 14..327 并明确报告：

Transferred: the M7RK-5316 label fact and the user-changed approval policy.

随后由宿主注入的状态包含 M7RK-5316，并暴露有界投影元数据，包括：

field_aware: true
soft_max_chars: 12000
full_state_path: .dsh/project/WORKING_STATE.json

同一注入明确说明，原始隐藏推理不是持久记忆。

工程来源

主要工程线索保存在：

- DSH/Qwen harness 演进报告，v0.2-v0.8
- 跨系统故障分析
- 版本谱系
- 故障模型
- 不变量
- 压缩协议
- 记忆架构
- 复现与资格验证
- 相关工作

这些报告是回顾性的工程分析。运行时声明由实现和原始证据单独支持。

架构

1. 持久化调查状态

持久化单元是项目级规范工作状态，而不是一系列独立记忆消息的流。

实质性状态可以从以下工作中保留：

- 故障排查与调试；
- 测试与资格验证；
- 研究；
- 实验；
- 分析性调查；
- 多图像分析；
- 迭代构建。

普通对话不会自动被视为调查性持久状态。

典型的工作状态字段包括：

- known
- constraints
- decisions
- evidence
- failed_hypotheses
- do_not_repeat
- open_acceptance
- next_action

这是延续状态，而不是原始隐藏推理的转储。

2. 宿主投影到普通模型上下文

持久状态不通过单独的模型侧记忆查询 API 暴露。

宿主渲染项目工作状态的一个有界、字段感知的投影，并将该投影注入模型的普通上下文。

完整的项目状态单独保存在：

.dsh/project/WORKING_STATE.json

干净资格验证捕获了一个投影，包含：

field_aware: true
soft_max_chars: 12000

并明确保留关键字段，包括：

constraints
failed_hypotheses
do_not_repeat
open_acceptance
next_action

较旧的注入快照可能仍保留在保留的对话历史中可见，直到该历史被回收。

因此，最新的注入是持久项目状态的当前宿主投影，而不是原始隐藏推理的重放。

3. 覆盖率门控的上下文回收

创建持久状态不足以证明其原始对话来源可以安全消失。

回收路径为：

旧的活动候选区间
|
v
语义疏散
|
v
识别缺失的活跃语义
|
v
在需要时转移缺失材料
|
v
覆盖率审计
|
v
宿主侧修订 / 指纹检查
|
+---- 不足 / 不确定 ----> 保留旧上下文
|
---- 覆盖率充足
|
v
推进可安全修剪的授权
|
v
回收已审计的活动表面

语义覆盖率仍然由模型辅助。

不可逆的回收授权仍然由宿主控制。

4. 授权边界

实现区分：

protocol_committed_through_seq

与：

prune_safe_through_seq

这些代表不同的声明。

protocol_committed_through_seq 记录持久的协议进展。

prune_safe_through_seq 记录不可逆的活动上下文回收已被授权的边界。

因此，一次正常的调查性检查点可能成功，而 prune_safe_through_seq 仍未被设置。

系统有意防止：

a checkpoint happened

被解释为：

everything before that checkpoint is safe to forget

为什么存在这一点

该架构源于真实智能体辅助工程工作中反复出现的长期失败。

反复出现的类别包括：

- 有用的发现仅保留在短暂的对话中；
- 重要约束仅作为提示历史存续；
- 被拒绝的假设被重试；
- 失败的操作被重复；
- 测试通过而用户验收仍然失败；
- 模型自我报告被视为权威；
- 上下文压缩丢失了独特的约束或证据；
- 反复压缩累积信息损失；
- 过时的源或项目状态存续到后续操作中；
- 运行时、宿主、解析器、工具和模型故障被相互混淆；
- 部分状态转换导致持久权威与可见上下文不同步。

这些失败推动设计走向更清晰的职责划分。

模型仍然负责语义工作，例如：

- 解释；
- 假设；
- 实现判断；
- 审查；
- 语义覆盖评估。

宿主仍然负责承载权威的操作，例如：

- 规范修订；
- 持久状态；
- 任务和源权威；
- 预算；
- 变更门控；
- 状态转换；
- 不可逆回收权威。

失败模型区分归因类别，包括：

- 模型；
- 测试框架；
- 运行时；
- 提供方；
- 解析器；
- 工具协议；
- 上下文处理；
- 项目状态治理；
- 未知或混合。

参见 FAILURE_MODEL.md。

该架构是如何推导出来的

该项目并非一次性地从一份干净的固定规范实现而来。

它通过反复的工程循环演化：

observed failure
|
v
retrospective analysis
|
v
cross-layer attribution
|
v
requirement / authority boundary
|
v
implementation revision
|
v
live qualification
|
v
newly observed failure
|
v
next iteration

重要的一步是归因。

在智能体会话中观察到的失败并不自动是模型失败。

它可能反而属于：

- 模型行为；
- 测试框架行为；
- 运行时集成；
- 提供方行为；
- 解析器行为；
- 工具协议；
- 上下文处理；
- 项目状态治理；
- 或同时属于多个层。
这些报告保留了那些失败及其回顾性分析。

实现与资格验证证据保留了在分析被转化为架构需求之后所发生的情况。

资格验证状态

| 行为 | 状态 | 主要证据 |
| --- | --- | --- |
| 同一工作区跨聊天注入 | 已演示 | 基线视频 |
| 长时间运行的多图像分析工作流 | 已演示 | 真实世界视频 |
| 错误证据解读被纠正并延续 | 已演示 | 真实世界视频 |
| 选择性调查状态捕获 | 已演示 | 干净资格验证 |
| 正向晚期语义迁移 | 已演示 | 视频、机器可读案例 |
| 晚期迁移后的新聊天恢复 | 已演示 | 干净资格验证 |
| 有界字段感知宿主投影 | 直接观察 | 机器可读案例 |
| 覆盖审计的成功回收 | 已演示 | 运行时证据 |
| 活动表面缩减 | 已演示 | 保留约 25,582 -> 18,312 的跟踪记录 |
| 同一非 Git 工作区在聊天/UI 重置和重命名后持久化 | 已观察 | 视频 |
| 先前状态出现在另一个新的非 Git 项目中 | 已观察 | 视频 |
| Git 根项目隔离 | 在当前测试设置中已演示 | 干净资格验证 |

工程演进与报告

上方的资格验证表描述了当前的公开证据。

下方的版本历史解释了架构如何演进到该状态。

v0.2.x

控制层将更多权限从瞬态模型行为转移到宿主治理中。

变更包括：

- 宿主拥有的来源权威；
- 任务生命周期控制；
- 变更边界；
- 有界目标与预算；
- 工作树隔离；
- 审查与验收分离；
- 防失控控制。

底层教训是，语义能力与操作权限不应被视为同一回事。

v0.7.x

系统围绕更长时间运行的状态和上下文压力增加了机制：

- 持久提交实验；
- 结构化状态累积；
- 上下文压力处理；
- 结构化压缩；
- 来源加固；
- 事务加固。

实际使用随后暴露出一类新问题。

让记忆协议过于通用，导致了其自身的状态污染和响应终结问题。

试图保留更多状态本身可能会干扰普通工作。

v0.8.x
架构的反应是将此前耦合的机制分离开来。

变更包括：

- 普通回答与强制性记忆协议分离；
- 调查性检查点改为事件驱动；
- 持久状态进展与回收权限分离；
- 在回收之前引入语义疏散；
- 引入覆盖审计；
- 成功的检查点不再被视为等同于修剪许可。

这是以下两者之间区分变得至关重要的阶段：

protocol_committed_through_seq

与：

prune_safe_through_seq

主要回顾来源

关于完整推理和失败历史：

- DSH/Qwen harness 演进报告，v0.2-v0.8
- 跨系统失败分析
- 版本谱系

这些文档解释了架构的演进。

不应将它们视为比保留的实现和实时资格验证产物更有力的当前运行时行为证据。

这与典型长期记忆有何不同

持久记忆、上下文注入、分层状态、会话恢复和上下文压缩都有先例。

本项目并不声称这些概念各自是新的。

更窄的架构焦点在于此处使用的组合方式，尤其是以下三者之间的分离：

1. 增量式持久调查状态提交；
2. 将该状态有界地投影回活动模型上下文；
3. 在语义覆盖和宿主侧一致性检查之后，单独授权对对话来源进行回收。

因此，本项目关注的与其说是：

智能体如何能在之后记住某些东西？

不如说是：

留存状态何时变得足以授权移除最初包含它的活动上下文？

这也是为什么持久进展和修剪安全权限具有不同的边界。

参见 RELATED_WORK.md 了解当前的先例比较。

详细的回收资格验证

现有的成功回收轨迹

保留的实时语料库包含一次成功的、经过覆盖审计的 /compress 轨迹，其中候选片段已经具有足够的留存表示。

审计结论为：

无需转移；可安全修剪。

该次运行将活动表面从大约：

25,582 tokens

减少到：

18,312 tokens

这仍然是本项目明确测量的活动表面缩减示例。

正向延迟转移资格验证

后来的 M7RK-5316 运行检验了互补路径，即在回收之前，相关材料在留存状态中缺失。

资格验证序列为：

1. M7RK-5316 存在于较早的活动对话中。
2. 调查检查点已包含实质性截图分析状态，但不包含 M7RK-5316。
3. /compress 审计候选表面 14..327。
4. 运行时明确报告 M7RK-5316 已转移。
5. 以下由宿主注入的持久状态包含 M7RK-5316。
6. 新对话无需用户重复即可回忆出它。

完整证据链：

2026-08-28 选择性捕获与延迟转移

视频：

选择性捕获、延迟转移与新对话恢复

本次运行的 /compress 输出打印：

Before estimated active surface: ~40232 tokens
After active surface estimate: ~40385 tokens

这些本地估算不作为压缩比声明使用。

本次运行是语义疏散、显式延迟转移及后续恢复的证据。

较早的 25,582 -> 18,312 轨迹仍是该项目明确的活跃表面缩减示例。

故障关闭式资格考量

已演示的 M7RK-5316 案例已经检验了一个真实的语义缺口：压缩前持久状态中缺失的材料在语义疏散期间被发现，并转移到了存活状态中。

如果缺失材料可用且可恢复，转移才是预期行为，而非拒绝。

一个有意义的故障关闭式资格认定需要这样一个现实案例：语义覆盖在疏散后仍未解决，而不是通过破坏存活状态来人为制造失败。

当前公开语料并未单独声称存在一个自然发生的未解决覆盖拒绝案例。

已知的事务排序弱点

实际资格验证还暴露了一个较早的部分提交路径：审计/状态提交通过，但活跃表面替换失败。

源表面仍然存在，因此观察到的失败并未删除原始上下文。

然而，在活跃表面替换完成之前，修剪权限已经推进。

这被保留为事务排序/原子性弱点的证据，而不是作为完全原子行为来呈现。

观察到的项目身份行为

资格验证暴露了受测的非 Git 工作区与 Git 根工作区之间的实际差异。

非 Git 行为

两段录像显示了有问题的隔离行为。

聊天删除、UI 移除和重命名后的同一非 Git 工作区

在先前的对话被删除、工作区从 DSH UI 中移除、同一文件夹被重命名并打开新对话之后，持久注入仍然存在。

不同新非 Git 项目中的先前持久状态

一个不同的新非 Git 项目仍然收到了先前项目的持久状态。
这些观察结果意味着，不应仅凭在受测的非 Git 设置中打开一个新文件夹或重命名文件夹就推断出项目隔离。

Git 根目录行为

在干净资格验证中：

git init

足以建立一个单独的已观察项目边界。

在该工作区中新建的 DSH 会话不再收到先前项目的持久调查性注入。

尝试的初始 Git 提交失败，因为未配置 Git 作者身份，因此观察到的隔离并不依赖于成功的提交或现有的 Git 历史。

关于隔离的资格验证运行，请参见：

REPRODUCTION.md

本节记录当前观察到的运行时行为，而非 DSH 使用的完整内部身份算法。

开发谱系

v0.1
|
| early project/control pack
v
v0.2.x
|
| host governance
| task/source authority
| mutation boundaries
| review vs acceptance
| anti-runaway controls
v
v0.7.x
|
| durable commit experiments
| context-pressure handling
| structured compaction
| universal checkpoint experiments
v
v0.8.x
|
| ordinary answers separated from memory protocol
| event-driven investigative checkpointing
| durable state separated from reclamation authority
| semantic evacuation and coverage audit
v
live / pre-canonical-v0.9
|
| live qualification
| runtime integration fixes
| preserved memory/context subsystem extract
v
v1.0
|
- active development

这些标签描述的是开发阶段，而非 Git 分支。

该仓库使用 main。

详细关系保留在：

VERSION_LINEAGE.md

冻结的历史包应位于：

Historical packages

证据模型

该仓库区分了几种证据类别。

DESIGN

架构、需求和预期行为。

设计材料本身并不能确立运行时成功。

IMPLEMENTATION

保留的代码，表明某一机制在特定实现状态下存在。

实现并不证明每条路径都已被成功执行。

LIVE EVIDENCE

运行时跟踪、捕获的注入、状态快照、录制内容和可观察的运行时输出。

这些是关于已证明行为的主张的主要来源。

REPORT / ANALYSIS

对实现和证据的回顾性解释。

报告保留因果推理、失败分析和设计理由，但其效力不高于主要运行时证据。

HISTORICAL

较旧的冻结开发材料。

历史工件对于谱系和失败分析很有用，但不应自动将其解释为当前运行时行为。

EXTERNAL / THIRD-PARTY

DeepSeek Harness、依赖项、捐赠材料和外部编写的软件。
它们的收录并不意味着本仓库拥有作者身份或重新许可。

原生 DSH 与自定义控制层

DeepSeek Harness 已经提供了运行时/会话基础设施以及宿主级上下文注入原语。

本项目不主张这些传输机制为原创工作。

自定义层涉及在这些原语之上的持久调查状态管理与回收语义，包括：

- 规范持久调查状态；
- 增量调查检查点；
- 有界状态投影与重新注入；
- 跨聊天恢复；
- 语义疏散；
- 覆盖审计；
- 宿主侧一致性检查；
- 显式剪枝安全授权；
- 协议进度与回收授权的分离。

范围与非主张

本项目不主张发明了：

- 持久化智能体记忆；
- 分层记忆；
- 上下文压缩；
- 宿主管理状态；
- 跨会话延续；
- 运行时上下文注入；
- 检查点。

这些概念已有先例。

更狭义的架构关注点在于此处使用的组合，尤其是持久调查状态提交与对其对话来源的单独授权、覆盖门控回收之间的分离。

参见：

RELATED_WORK.md

本项目为实验性项目。

保留的历史故障并不自动是当前运行时的缺陷。

保留的实现产物并不自动与当前安装的运行时相同。

回顾性报告不是主要运行时证据。

成功的语义覆盖审计并不被呈现为信息零损失的数学证明。

仓库地图

memory-stack/
主要保留的记忆/上下文子系统。

docs/
架构、不变量、压缩协议、
故障模型、相关工作与复现。

evidence/
主要运行时、资格与来源证据。

qualification/
按资格案例分组的完整证据链。

live-logs/
独立运行时追踪与故障排查输出。

memory-injections/
独立捕获的持久状态投影与重新注入。

videos/
录制索引与录制来源。

provenance/
版本谱系、哈希与产物关系。

reports/
回顾性工程报告与案例研究分析。

historical/
冻结的历史开发材料。

implementation/
精选的更广泛控制层发布的占位符。

full-environment/
外部保留环境的来源占位符。

主要保留的实现

主要保留的记忆/上下文产物是：

保留的实现归档
可在以下位置获取可浏览的提取表示：

可浏览的实现提取

该产物表示的是从实时环境派生的子系统提取，而非完整已安装控制包的逐字节副本。

其保留的模块主体来自实时安装的冻结版本，而精简的独立提取入口点则是由后续的实时集成钩子组装而成。

参见：

保留的实现细节

当前保留的实现状态：

live / pre-canonical-v0.9 development state

架构经历了 v0.1、v0.2.x、v0.7.x、v0.8.x 以及后续实时资格认证工作的演进。

v1.0 正在积极开发中。

来源

重要的保留产物在可行的情况下使用 SHA-256 进行标识。

主要证据在可行的情况下应保持逐字节不变。

如果发布需要脱敏处理：

1. 私下保留未经改动的原始版本；
2. 发布清晰标注的衍生版本；
3. 在来源元数据中保留原始版本与衍生版本之间的关系。

文件系统时间戳是辅助来源信息。

哈希值和有记录的产物关系是本仓库使用的主要身份识别机制。

参见：

来源记录

许可证

除非另有明确说明，原始项目代码和文档均依据 Apache License 2.0 许可。

DeepSeek Harness、第三方软件、依赖项、捐赠材料、外部编写的代码、捆绑的运行时材料以及历史产物均保留其原始许可证和条款。

仓库级别的 Apache-2.0 许可证不会自动对第三方材料重新许可。

参见：

LICENSING.md