运行时性能补丁 ChenXu233/dsh-perf-patch

dsh-perf-patch

DeepSeek Harness（DSH） 的运行时性能补丁。第三方插件把宿主拖慢到 O(N) 时用得上。node_modules 里一个文件都不改：补丁在加载时包装宿主服务，每个补丁都失败安全——只要有一点不确定，就退回原来的代码路径，不改变行为。

在 DSH Desktop 0.2.1-rc.2（Electron 44 / Node 24 / Windows 11）上构建并实测，环境里装了 dsh-ops 和 dsh-mcp-connector。

修复了什么

1. 智能体挂载引发的 tools/change 风暴

挂载一个智能体会注册约 161 个工具。每次注册都触发 tools/change，每个监听器（discovery reconcile、PTC reconcile、MCP governance）都会重放自己那套 O(tools) 的完整工作。所以一次 agents.create 会发出几百条通知，每个监听器都要重跑几百次。

修复： agents.create / agents.resume 运行期间，抑制 tools.layers.onChange；最外层调用返回时，同步发出一次通知。

抑制加同步刷新是刻意为之。用 queueMicrotask 刷新会饿死事件循环（监听器排入的微任务比循环排出的多），实测会冻住 UI；那个版本已移除，不随包发布。

2. tools.schemas() 每次读取都深拷贝

schemas(scope) 克隆每个工具的 JSON Schema；schemaOf(def, true) 克隆单个。两者都只是工具 revision / definition 的纯函数，监听器却在循环里反复调用。

修复： 按工具 revision 缓存 schemas(scope)（WeakMap 以 scope 为键，tools/change 时失效），按 definition + 参数身份缓存 schemaOf(definition, true)。返回的对象在调用方之间共享，请当作只读。

3. dsh-ops 用完整提示词组装回答一个布尔问题

dsh-ops/lib/presentation.js 判断「这个智能体是否走 PTC presentation」时，调用 systemPrompt.assemble({scope, signal})，然后只读一样东西：

assembly.sections.some(s => s.name === 'tools:ptc-only' && s.text.trim() !== '')

assemble() 要渲染约 36 个 section，还要 structuredClone 每个工具 schema（实测约 250–310 ms）。dsh-ops 每个活跃智能体、每次 reconcile 都要做 6 次。

修复： 包装 systemPrompt.assemble。当且仅当这次调用是上述探测之一时，用同样的层拼出最小 assembly 返回：

{ sections: [{ name: 'tools:ptc-only', text }], contexts: [], tools: [] }

探测识别用 dsh-ops 自己的标记（isPresentationProbe，通过模块缓存拿到的 WeakSet）；拿不到这个导入时，退回「调用栈里含 dsh-ops/lib/presentation.js」。其他所有调用方——包括 ptc/index.js 和 discovery/index.js 里真正的提示词组装——都原样放行。

section 文本每次调用都重新计算。缓存试过，已回退：控制输入一旦过期，reconcile 就变成永远不收敛的不动点，把宿主冻住。
在 3 个智能体的实例上实测：每次探测 254–312 ms → 0 ms（每轮 reconcile 扫描约 4.9 s），3 个智能体的 PTC 决策逐字节一致。

安装

cd ~/.dsh/profiles/desktop
npm install ChenXu233/dsh-perf-patch

然后在配置档 package.json 的 dsh.profile.bundles 数组里列出 "dsh-perf-patch"。这个包带有 dsh.bundle.patch → cordis.patch.yml，由它插入 loader 条目。只把名字加进 bundles 还不够 —— 没有补丁层，插件永远不会被加载。

从 checkout 安装：把本仓库克隆到 <profile>/node_modules/dsh-perf-patch，同样把名字加进 bundles。

开关

| 变量 | 作用 |
| DSH_PERF_PATCH=0 | 加载时禁用全部三个补丁。 |
| DSH_PERF_PATCH_VERIFY=1 | 探测短路还会计算完整装配并做比对。一旦发现不一致，就记录错误，并在本会话内永久禁用短路。 |

运行时计数器：

globalThis.__dshPerfPatchProbe // { hits, bypass, mismatches, enabled }

hits = 走短路应答的探测次数，bypass = 转到真实 assemble 的调用次数。如果 hits 一直是 0，说明检测没匹配上，插件等于没生效。

预期行为

* 上游修复落地后，本插件会自动失效：schema 缓存按 revision 做键（无论如何都正确），而 dsh-ops 不再匹配时，探测短路会自动退出。
* 批量门控是唯一的行为变化：监听器在每次 mount 时触发一次，而不是每个工具触发一次。这正是目的所在，但如果有插件依赖 mount 期间每一次中间 tools/change，现在只会看到一次。
* 不要修改 schemas() / schemaOf() 返回的对象。

相关上游 issue

* dsh-ops #333 —— discovery reconcile 为每个智能体重算 presentation
* dsh-ops #369 —— 258 个工具时 tools.schemas() 深拷贝，线性变慢
* dsh-mcp-connector #178 —— governance reconcile 开销

如果这个插件引发了问题：设置 DSH_PERF_PATCH=0，确认问题消失，然后带上数据开 issue。

许可证

MIT