zheng1/dsh-acp-replay

dsh-acp-replay

一个面向 DeepSeek Harness 的社区 ACP 桥接，它响应 session/load，因此客户端可以在自身重启后重建会话记录。

状态：原型。 它在 dsh 0.1.5-rc.1 上可以端到端运行，但它是 @deepseek-ai/dsh-acp 的 vendored fork，每当该包发生变化时都需要 rebase。

在 npm 上以 dsh-acp-replay 发布。它的版本独立于它所针对的 harness 版本，这一点由 peerDependencies 说明。（0.1.5-rc.1 发布时文件列表不完整，因此加载失败；它已被弃用。请使用 0.1.0 或更新版本。）

为什么需要它

dsh-acp 是一个仅用于自动化的桥接：它的 initialize 声明 sessionCapabilities: { close, list, resume }，没有 loadSession，而 session/resume 会恢复会话，但不会重放其更新。ACP 将 session/load 定义为 agent“通过通知将整个对话历史流式传回客户端”的调用，而将 agent 视为持久记录权威的客户端——例如 Paseo——正是调用该方法来在重启后重建时间线。

没有它，这类客户端会在一个仍然记得一切的 agent 旁边显示空对话，因为 harness 保留了记录，而客户端无法读取它。这个桥接填补了这一空白；跟踪缺失上游功能的讨论是 deepseek-ai/deepseek-harness#6324。

它添加了什么

相对于 @deepseek-ai/dsh-acp@0.1.5-rc.1 有两处更改：

- initialize 声明 loadSession: true。
- 实现了 session/load：它使用只读持久化句柄（ctx.sessionPersistence.open(id, 'read')）打开存储的会话，像 session/resume 一样恢复会话，然后在返回之前通过 src/updates.ts 中现有的更新映射重放快照。

src/replay.ts 将存储的事件映射为协议更新：

| 存储的事件 | ACP 更新 |
| --- | --- |
| user/message，且 source.kind === 'user' | user_message_chunk |
| assistant/message | agent_thought_chunk、agent_message_chunk、usage_update |
| tool/call | tool_call |
| tool/result | tool_call_update |

注入的上下文（运行时快照、技能列表、文件更改通知）共享 user/message 事件类型，但它不是用户说过的话，因此不会出现在传输中。

快速失败保护

该桥接需要 0.1.5-rc.1 引入的持久化句柄 API（ctx.sessionPersistence.open(id, 'read')，然后是 read(0)）；0.1.2-rc.1 则是在服务上使用 load/inspect 读取日志。当挂载的 harness 不提供该桥接所调用的内容时，src/compat.ts 会拒绝挂载，并打印缺失的要求、替代桥接以及此仓库：

dsh-acp-replay cannot serve session/load in this harness (harness 0.1.6):
- 需要 ctx.sessionPersistence.open()，但挂载的 sessionPersistence 服务只暴露 inspect、list、load、stat
此插件内置了 @deepseek-ai/dsh-acp@0.1.5-rc.1，并需要它引入的持久化句柄 API。
请改用随附的桥接（"dsh --profile acp"），或针对已安装的 harness 更新此插件。
https://github.com/zheng1/dsh-acp-replay

在 harness 升级后运行 node test/selfcheck.mjs，无需完整客户端即可得到该答案。

使用它

该桥接会替换某个 profile 中随附的 acp 行。有两种方式：

安装到现有 profile 中。 将该包添加到 profile，并追加到其 cordis.patch.yml：

已在 npm 上发布为 dsh-acp-replay：

dsh plugin --profile acp-replay add dsh-acp-replay   # installs it into that profile

同一个包也可以全局安装（npm install -g dsh-acp-replay）或从检出副本复制（将 lib/ 和 package.json 放入 $DSH_HOME/profiles/node_modules/dsh-acp-replay/）。

- id: acp
disabled: true

- insert:
- id: acp-replay
name: 'dsh-acp-replay'
inject: [acpAppStartup]
config:
provider: deepseek-official
model: deepseek-flash

然后将客户端指向 dsh --profile acp-replay，而不是 dsh --profile acp。在 Paseo 中，这就是 provider 的 command：

{
"agents": {
"providers": {
"dsh": {
"extends": "acp",
"label": "DeepSeek Harness",
"command": ["dsh", "--profile", "acp-replay"]
}
}
}
}

或将其作为 bundle 使用。 该包声明了 dsh.bundle.patch，因此将 dsh-acp-replay 添加到 profile 的 dsh.profile.bundles 会组合出相同的行。

构建

npm install --legacy-peer-deps   # the 0.1.5 peer graph has an rc.1/rc.2 skew
npm run build                    # tsc -> lib/
npm test                         # guard behaviour (node:test)

已验证

针对 dsh 0.1.5-rc.1、一个临时 DSH_HOME 和一个真实 API key：

- initialize 报告 loadSession: true。
- 一个包含两个 prompt 的会话通过桥接正常运行（session/new、session/prompt、session/close）。
- 一个新进程为该 session id 调用 session/load，会收到携带原始 prompt 和答案的 user_message_chunk ×2 和 agent_message_chunk ×2，以及 usage_update ×2。

test/replay-check.mjs 运行两个阶段（先 record，再 load ）；test/selfcheck.mjs 只执行 initialize 并报告是否声明了 loadSession。

通过客户端端到端验证（Paseo 0.7.2 daemon、dsh 0.1.5-rc.1，同一 daemon 上有两个 DSH provider，因此只有桥接不同）。每个 agent 运行一个 prompt，然后重启 daemon——这一事件过去会抹掉可见对话：

| Provider | 重启前 | 重启后 |
| --- | --- | --- |
| dsh-replay（此桥接，声明 loadSession） | 用户 prompt、助手答案、推理行 | 三行全部恢复 |
| dsh（随附的桥接，无 loadSession） | 用户提示，助手回答 | No activity to display. |

Paseo 的 ACP 适配器仅在 agent 声明该能力时才走 loadSession 分支，通过 streamHistory() 初始化其时间线，且无需任何改动即可正常工作。

未验证 / 已知限制

- 工具调用回放已被映射，但上述测试并未实际执行。
- 较旧的主机（dsh 0.1.2-rc.1）暴露的是不同的持久化 API（load/inspect 而非 open/read），因此此分支仅面向 0.1.5-rc.1 及更新版本。
- 回放的历史记录在 session/load 返回之前逐条通知送达；会话非常长时，该调用也会相应变长。
- 该 profile 自身的帮助文本仍显示 --profile acp（它来自随附的 dsh-acp-app 命令提供程序，而非此包）。

许可证

MIT，与其所内置的上游包一致。除 src/replay.ts 外，src/*.ts 均复制自 @deepseek-ai/dsh-acp 的 dsh-v0.1.5-rc.1 标签；新增内容为 loadSession 能力、src/index.ts 中的 loadSession 处理器，以及 src/replay.ts。