[BUG] Python SDK当 session ID 存在时无法 resume 对话

[785Coder]

Python SDK 当session ID 存在时无法resume对话：

import json

from pathlib import Path
from deepseek_harness import DeepSeekHarness, DeepSeekHarnessConfig

cwd = Path(".").resolve()
config = Path("./cordis.yml").resolve()
session = Path(".sessions").resolve()

while True:
    with DeepSeekHarness(
        config=DeepSeekHarnessConfig(
            provider="openai",
            model="Qwen3.8",
            max_tokens=15200,
            cordis=str(config),
            cwd=str(cwd),
            session_root=str(session),
            base_url="http://***",
            api_key="sk-***",
        )
    ) as harness:
        query = input("user->")
        result = harness.run(query, session_id="id-123")

        print(result.session_root, result.session_id)
        print(result.final_response)

结论：不是 Python SDK 不持久化，而是 SDK server 从不“恢复”已存在的会话

1. 架构上：Python SDK 本身不做任何持久化

DeepSeekHarness 是一个很薄的客户端——它只是用 subprocess 拉起一个 Node 运行时进程（deepseek_harness_runtime → @deepseek-ai/dsh-sdk-jsonrpc-server），通过 stdio JSON-RPC 发 session/prompt。真正写 JSONL 的是那个子进程里的 @deepseek-ai/dsh-session-persistence-jsonl 插件，根目录由 DSH_SESSION_ROOT 决定（python/sdk/src/deepseek_harness/api.py:64-65）。

2. 你脚本里的关键问题：with DeepSeekHarness(...) 在 while True 里

你的循环每转一圈就新建一个运行时子进程。于是第二次起，session_id="id-123" 面对的是一个全新的进程。
而 SDK server 的 createSession（packages/sdk/server/src/server.ts:218-231）对每个 sessionId 无条件走“新建会话”路径：

const handle = await this.ctx.agents.create({ sessionId, meta: { cwd }, ... })

agents.create（packages/core/agent-loop/src/index.ts:589）调的是 ctx.sessions.prepare(id, { meta })——内存里从零新建一个空会话，不会去读磁盘。agent-loop 里其实有 resume()（index.ts:653，会通过 sessionPersistence.prepare(id) 把历史加载进来），但 SDK server 从来没调用它。

3. 于是发生“id 冲突”，后续全部不落盘

新进程里这个空会话被 announce 后，持久化协调器 onCreated（packages/session/session-persistence/src/coordinator.ts:1237）发现磁盘上已有 id-123 的日志，走 adoptLivePrefix：因为新会话的 seed 是空的，无法覆盖已持久化的前缀，直接抛：

session "id-123" already has a persisted log on disk that does not match this live session (id collision)

这个错误被吸收进 write-behind 的初始化 promise（coordinator.ts:1181 的 .catch），所以对话还能正常跑、还能返回回答；但之后每个写入都会 await 这个已 reject 的 init 而失败 → JSONL 一个字都不更新，模型也看不到之前的上下文。进程退出时 flush 再抛一次，又被 disposeAndExit 里的 Promise.allSettled 和 Python 客户端 close() 的 except 吞掉，所以你根本看不到报错。

相关讨论：

#167
#712

[Jstn-1g]

我按这个复现完成了一份可运行、可复核的 reference implementation：

• 分支：https://github.com/Jstn-1g/deepseek-harness/tree/reference/discussion-4591-sdk-resume
• 精确提交：Jstn-1g@f86c59f

确认并处理了两个相互独立的问题：

1. SDK server 在启用持久化时，现在会先按客户端给定的 sessionId 调用 agents.resume()；只有精确读取以类型化 SessionNotFoundError 证明该 ID 不存在时才创建。损坏日志、后端错误和其他 ID 的缺失不会被误当成“新会话”。关闭期间的待完成 open 也会被中止。
2. 仅修 server 还不够。两进程 Python 回归最初恢复了第一条 user 消息，却丢了第一条 assistant 回复。原因是 Python close() 收到 shutdown 响应后立即 terminate，而运行时的最终持久化批次仍在异步 quiesce。客户端现在先关闭 stdin，并给 EOF 驱动的持久化/退出留出有界宽限期，再升级到 terminate/kill。

最终回归把模型在第二个全新运行时进程中看到的历史精确固定为：user(first) -> assistant(first) -> user(second)，同时检查 Zstandard 持久化产物。TypeScript 也有真实双进程 e2e 和可重放 snapshot 覆盖。

本地验证：

• 155 个 AgentLoop / SDK server / persistence 聚焦测试通过
• 真实双进程 TypeScript e2e 与 restart snapshot 通过
• bundled-default Python 双进程 source-runtime 证明通过，完整历史与持久化均匹配
• 全量 TypeScript build/typecheck、lint 通过
• 28/28 文档 gate 与 1003 个中英文配对通过

限制说明：Windows 本地环境无法构建项目的 release-shaped 单文件运行时；新的 sdk-restart packaged-executable 场景已接入 Linux CI 的 --scenario all，该载体级运行仍应由 CI 确认。

这是一份 reference implementation，尚未合入 upstream。如果维护者希望把 typed absence、server resume 和 Python dispose ladder 拆成更小的提交，我可以按首选边界调整。

[PerryLink]

你的根因分析成立, master (c291e79) 上仍未修。逐点核实:

• SDK server 对每个 sessionId 无条件走新建路径, 从不 resume:
  packages/sdk/server/src/server.ts:259-292 (getOrCreateSession → createSession → this.ctx.agents.create(...))
  没有对已持久化 id 的 resume 调用。
• Python 侧只是薄客户端, 逐轮 session/prompt (python/sdk/src/deepseek_harness/api.py:120-131,
  python/sdk/src/deepseek_harness/client.py:174-182); 每次新建 harness 进程就会撞上磁盘日志,
  持久化协调器抛 id collision 后被写路径吞掉——所以"能对话、但不落盘、看不到历史"。

当前可用的绕过(今天就能用, 不需要等上游):

1. 一个进程内复用同一个 DeepSeekHarness 实例跑多轮(把 while True 移到 with 外面, 循环里只 harness.run(...))
   —— 同进程内 resume 正常工作, 历史连续;
2. 需要跨进程时, 每轮用新的 session_id, 并在 prompt 里自己重放历史(有损: 丢工具结果/摘要);
3. 社区已有可复核的参考实现(Jstn-1g/deepseek-harness@f86c59f, 帖内链接): server 先按 id 调 agents.resume(), 只有类型化
   SessionNotFoundError 才 create; 另修 Python close() 过早 terminate 丢尾批持久化的问题。尚未合入上游。

给上游的修复方向正是你帖子里那条: session/prompt 检测到已持久化日志时走 resume, 并保留 lease/损坏检测。