前言¶
用 DSH 跑多个任务时，一个常见的失控是消息路由错了：用户本意是给 A 任务补充需求，消息却进了 B 会话，模型照着 B 的上下文继续执行，产出一堆和当前任务无关的操作。等到发现时，有的写入已经发生，很难判断哪些动作属于这次误路由、哪些是早前正常执行的。已有的做法要么靠人盯住对话，要么事后翻日志人工归因，成本高且容易漏。
下面介绍的 myboker/dsh-conversation-guard 就是针对这一处做拦截和留痕的社区插件，属于「工作流」分类。它不替代 DSH 的权限体系，而是在消息进入模型前做一次任务归属判断。
这是什么¶
dsh-conversation-guard 是 DeepSeek Harness 的独立社区插件，维护者为 myboker，许可证 MIT。它的位置是：给会话确立一个任务身份，用分类模型判断新进来的一批消息是否属于该身份；若疑似误路由、显式切换任务或信息不足，就在执行前暂停，由人来确认；如果已经在错误会话里做了工作，插件可以把这段工作的摘要和证据索引导出成一份可复查的交接记录。
它明确不是官方组件，也不承诺兼容其他 DSH 预发布版本。当前社区预览版本是 0.1.0-rc.3。
核心功能¶
1、任务身份绑定。会话里第一条人类消息确立任务身份；也可以显式用 /guard task Fix the web-auth login form 指定。后续的可疑消息无法悄悄改写这个身份。建议每个任务使用单独会话，在既有长会话里启用插件时先显式设置任务。
2、批量消息准入。插件把「当前任务、候选消息、以及最多四个已接受批次的有限上下文」交给分类模型。默认分类模型是 deepseek-v4-pro，接口地址 https://api.deepseek.com。确认是按批进行的，不支持把批次里某一条消息单独拆出来放行。
3、审批不等于授权。放行只说明这批消息属于本会话，不扩大既有权限、工作目录或 Super-agent Mandate。检查失败、附件、超大消息一律需要人工复核。
4、回调与交接。模型确认前，插件先把整批消息落库；之后可用命令复查。当用户发现工作其实做错了会话，Agent 可调 conversation_guard_handoff 记录摘要、已执行动作、产物、验证情况、外部影响或后台任务、剩余工作，并导出带证据引用的本地 Markdown。
5、证据有边界。证据通过原始消息 ID、真实模型调用边界、步骤、工具调用 ID、任务创建关系来定位，排除之后无关请求。模型一个步骤处理多个请求或旧日志缺少调用边界时，记录标记为 mixed。没有记录到关系的活动不会按时间顺序臆断归属。导出会冻结证据清单，后到的日志不会偷偷改掉报告。
安装与启用¶
插件以 tgz 形式发布。先下载 GitHub Release 中的 dsh-conversation-guard-0.1.0-rc.3.tgz，再按下面命令安装并检查配置。安装会基于 DSH 基础模板创建一个 profile（guard-demo），请使用未占用的名字，--from-default-profile 会覆盖同名 profile。
dsh plugin --profile guard-demo add /absolute/path/dsh-conversation-guard-0.1.0-rc.3.tgz
dsh --profile guard-demo --dump-config
若需要交互界面，先从官方 web 或 tui 模板创建 profile，再装插件：
dsh --profile guard-demo --from-default-profile web --dump-config
dsh plugin --profile guard-demo add /absolute/path/dsh-conversation-guard-0.1.0-rc.3.tgz
吊销分类模型的 Key 由环境变量在启动时读取，不写进插件配置。要在启动 DSH 的进程环境里设置 DEEPSEEK_API_KEY，再运行 dsh --profile guard-demo。在 DSH 的 Models 页面保存 Key 并不会设置分类器用的环境变量。
分类器相关配置写在 profile 的 cordis.patch.yml 中，可覆盖的字段如下：
- id: conversation-guard
config:
stateDirectory: /absolute/private/path/conversation-guard
apiKeyEnv: DEEPSEEK_API_KEY
model: deepseek-v4-pro
baseUrl: https://api.deepseek.com
timeoutMs: 30000
questionTimeoutMs: 45000
环境要求：Node.js 24.9 及以上，DSH 0.2.2-alpha.3 或 0.2.2-rc.1（package.json 的 engines 字段与 README 表述一致）。
典型用法¶
启用插件后，第一批让模型执行前发生可疑判断的消息会先被整批保存，支持原生提问的界面会弹出确认提示。若没有提问界面或提示超时，消息仍然保留，可以用命令处理：
| 命令 | 行为 |
|---|---|
/guard status |
显示当前任务、该批消息预览和确认 token |
/guard review |
重新打开该批的原生确认提示 |
/guard allow TOKEN |
明确允许该批在当前会话继续 |
/guard cancel TOKEN |
取消整批，同时保留记录 |
/guard history |
列出本会话已保存的批次 ID |
/guard handoff BATCH_ID |
导出摘要和引用，生成本地 Markdown |
/guard evidence HANDOFF_ID [CURSOR] |
查看证据索引或按游标读取片段 |
/guard task NEW_GOAL |
在无待审批批次时改变普通会话的任务身份 |
只发一句“继续”、一段工具输出、一段引用文本或来自别的会话的确认 token，都不能放行某批消息。批次挂起期间收到的新消息会合并进该批，并替换它的确认 token，从而保留“按我上面说的做”这类依赖关系。要切换任务，先取消挂起批次，再设定新目标并提交新任务。
交接记录的证据浏览支持分页：
/guard evidence HANDOFF_ID
/guard evidence HANDOFF_ID index:20
/guard evidence HANDOFF_ID 3:0
第一条显示索引，index:20 翻到下一页索引。记录的 read_cursor 指向正文，next_cursor 指向下一段。每页正文最多 4000 字符，长输出可以分页读完，不必截尾。索引页最多 20 条。原始完整日志仍留在 DSH，插件存引用而不是复制整段转写。证据只能从来源会话查询，且需要同时具备原始 DSH 日志和插件数据库；被删除或改动的记录会报告为不可用。
适用场景与注意¶
适合在多任务并行、单个会话长期承接不同目标时使用，尤其是误路由后需要界定“哪些动作是哪次请求引起的”场景。它的交接导出给出了可复查的摘要和证据引用，而不是完整转写。README 中记录的 Demo 明确说明：运行时和插件是真实运行的，分类器和 worker 的响应是脚本化的，因此这不是模型准确率演示。
使用前注意几点：插件以当前 DSH 进程的权限运行，放行只确认消息归属，不改变权限边界；它在设计上要求会话中按任务区分清楚，启用插件的既有长会话应先显式设定任务；重启后残留消息不会自动执行，需要回到原会话用 /guard status 判断。测试数据为合成数据，插件只声明兼容上述两个 DSH 预发布版本和 Node.js 24.9+。安装前应检查插件源码与许可证。
结尾¶
dsh-conversation-guard 解决的问题很具体：会话消息属于哪个任务、误路由后如何交接。它把“判断是否放行”和“留一份可复查的证据”这两件事放进同一套命令里，不需要改变 DSH 本身或现有工作流。项目目录页在 https://www.skillhub.cn/plugins/myboker/dsh-conversation-guard ，源码与 Release 在 https://github.com/myboker/dsh-conversation-guard 。
