DSH Runtime Tuning

一个关于 agent 运行时的长期实验：从 DeepSeek Harness（DSH）的真实会话记录里找出时间花在了哪里、哪些是白白浪费的，再尽量用插件把它修掉，并且每一项都用数据验证。

这里既是一组可以安装的 DSH 插件，也是这个过程的记录。随着分析推进，插件会不断增加。

起点：一份 9.7 小时的会话

我把自己日常使用 DSH 的一份会话导出来，按事件逐条统计。这份会话有 119 轮对话、2347 次工具调用，跨度 9.7 小时，内容主要是一个项目的反复发行（测试、编译、归档、上传）。

时间大致花在这些地方：

几个值得注意的现象：

• 有工具调用的步骤里，87% 只调用了一个工具。每多一步，就多一次重读上下文和生成。
• 同一个后台任务被反复查询，最多一个查了 13 次。
• 模型会从文件里 grep 出 GitHub 令牌，再用 curl 调 API，令牌因此出现在命令行和日志里。

发现一：机制都在，只是没人强制

读了 DSH 的源码之后发现，DSH 其实已经做得不错：

• 后台任务结束时会通知模型：模型忙时插进下一步，空闲时直接开启新的一轮；
• 前台命令超时后不会被杀掉，而是转到后台；
• 系统提示词里明确写了"不要轮询、不要 sleep"。

问题在于模型并不总是照做：它还是会 wait: true 加上 120 到 600 秒的超时，或者直接前台 sleep 90。等待期间整轮对话被占住，用户插话只能排队。

所以第一个插件 wait-guard 做的事很简单：在工具执行前强制执行这条规则，拦截前台长 sleep 和顶层 agent 的长时间阻塞等待，并告诉模型应该怎么做。

装上第一版之后，同一个发行流程的对比：

要说清楚一点：收益是"不占住对话"，不是"更快"。这次总耗时也变短了，但主要是因为那次编译本身快。以前的阻塞等待在任务结束时也会立刻返回，并没有"白等"。真正的变化是编译期间用户随时可以插话，而不是对着一个卡住的对话。

发现二：通知没来怎么办

让模型结束一轮去等通知，就要回答一个问题：如果任务卡死，通知永远不来呢？

wait-guard 为此加了一个 task_status 工具。模型在一轮的最后声明自己是 done、waiting（在等后台任务，附上预计时间）还是 asking（在等用户回答）。声明 waiting 的一轮正常结束后，插件开始计时；超过两倍预计时间还没有新一轮，就主动唤醒模型去检查。

几个边界是刻意设计的：

• 最多连续唤醒 2 次，用户发消息后重新计数，避免无人值守时无限循环；
• 用户按停止结束的一轮不计时：用户叫停的事，插件不应该再拉起来；
• 实测：一个 sleep 300 的任务，模型预计 1 分钟，插件在第 2 分钟准时唤醒。模型看了一眼输出，重新声明预计 3 分钟；任务结束后模型被正常唤醒并声明完成，兜底计时随之取消。

后来在一次真实发行里发现，模型并不总会声明：它把编译放进后台就直接结束了一轮，没有调 task_status，兜底计时也就没开。于是加了一道硬保底：只要一轮结束时后台还有任务在跑，又没有声明 waiting，就按默认 30 分钟计时，到点唤醒模型去检查。开发服务器这类故意留着的任务，模型可以在 services 里列出来，它们不计时。下一节会讲到，这道硬保底最后成了主角。

发现三：提问会把模型卡住

ask_user_question 默认是阻塞的：问出去之后，在用户回答之前，模型什么也做不了，哪怕手上还有不依赖这个回答的事。

DSH 其实已经实现了非阻塞的 timed 模式（超时返回 pending，用户的回答之后作为插话送进来），但默认关闭，而且这个工具嵌在 agent preset 内部，用户的配置补丁改不到它。具体的复现过程我发在了 DSH 讨论 #8547。

插件 ask-nonblocking 的绕法是：在每个顶层 agent 创建时，用宿主里同一份官方模块在 agent 自己的作用域里注册一个 timed 版本，遮蔽掉 preset 里的阻塞版。实测提问约 1 秒后放行，72 秒后的回答作为新的一轮送了进来。

这个绕法依赖 DSH 的内部接口，所以失败时只写日志、退回阻塞版，不影响任务。

发现四：令牌是模型自己要来的

同一份会话里，同一个 GitHub 令牌出现在 73 条命令（共 83 处）和 74 条模型回复里。往回找它第一次出现的地方，是模型用 ask_user_question 让用户把令牌贴进来，还承诺"会存到权限 0600 的本地文件里"。可令牌一旦作为回答进入对话，就已经在上下文里了：之后每次请求都会把它发给模型服务商，它也会永久留在会话记录里，模型再把它直接写进 curl -H "Authorization: …"。

插件 secret-guard 分三道防线：

• 拒绝向用户索要令牌、密码、API key 的提问，引导改用已经登录好的 gh，或者请用户自己运行 gh auth login。这一道最关键：在非阻塞提问下，用户迟到的回答是以插话送进来的，后面的打码管不到；
• 拒绝参数里带完整令牌的工具调用，以及 gh auth token；
• 工具结果交给模型之前，把其中格式明确的凭据替换成 [REDACTED:…]。

管不到的是用户直接在聊天框里粘贴的令牌：那不是工具结果。

发现五：别靠模型自己报告状态

task_status 的设计前提是模型会照做。数据说明它不会：

长会话里一次都不调，可能是因为它前面一百多轮都没有调用的先例，模型更倾向于沿用自己历史里的做法，而不是系统提示里的一句话。另外，官方提示词要求"给最终答复前收齐所有后台任务"，和"任务还在跑时可以结束这一轮"互相矛盾。

试过的几种办法：

• 让 task_status 和最终答复写在同一条回复里时直接结束这一轮（DSH 的 concludeTurn），省掉重复答复的那一步。机制有效，但模型经常不这么写；
• 做一个专用预设，把两段矛盾的提示合成一段。提示改写生效了，模型的行为没有明显变化，而且预设只对新会话有效，所以没有放进插件包；
• 最后的做法是换个思路：状态由 runtime 按事实判断，不靠模型声明。一轮结束时还有本次请求启动的后台任务在跑，就是在等；有提问没回答，就是在等用户。硬保底和 dsh-task-notify 的完成通知都按这个判断。task_status 降为可选，只在任务会跑超过 30 分钟、或者要标记服务时才需要。

验证：同样启动一个 60 秒的后台任务，模型没有调用 task_status，结束那一轮没有发通知，硬保底照常计时；任务结束、模型回复输出后，才收到一次"本轮已完成"。

顺带：时间到底花在哪

为了判断"一步只调一个工具"值不值得优化，用 4 个小任务（大量独立读取、发行前检查、先找后读、后台任务加并行工作）在 standard 和 ptc 两种预设下各跑一遍，共 8 次：

工具本身很快，时间几乎都在模型请求上。少一步只省一次"等开始出字"，正常时约 2 秒，服务端慢的时候约 8 秒。所以只在提示词里加了一句"互不依赖的读取、检查、修改放进同一条回复并行调用"，不再单独为它写机制。

DSH 自带的 ptc 预设（模型写脚本、在脚本里调工具）在这些任务上总步数从 17 步降到 15 步，但被占住的时间和输入 token 反而略多，因为脚本跑完模型还是要再请求一次去读结果。它适合大量重复查询、需要在中间过滤结果的任务，日常任务里看不出收益。插件的钩子在 ptc 下照样生效：脚本里调用的每个工具都会经过 DSH 的执行前后钩子。

还在看的问题

目前包含的插件

安装、配置项、日志和卸载见 docs/configuration.md。

开发

npm test

测试只用 Node.js 自带的 node:test，不需要安装依赖。

许可证

MIT