旁问 douglarek/dsh-btw

dsh-btw

给 DeepSeek Harness 用的旁问。/btw <question> 让会话自己的模型在主任务继续跑的同时回答一个题外问题：不排队，不打断正在跑的回合，答案也永远不进模型的对话。

命令界面照着 Grok Build 的 /btw 做（crates/codegen/xai-grok-pager/src/slash/commands/btw.rs 和 scrollback/blocks/btw.rs）：命令绕过提示词队列，一行金色点缀的 /btw <question>，答案留在主回合之外。有一处故意不同：Grok 从实时会话里作答，这个插件默认问一个完全不带对话的独立问题；想要 Grok 的行为，设 context: session。

用法

/btw what does WBC stand for?
/btw which file owns the retry loop?

- 这一行立刻出现，带着问题和一个 Answering…，随后显示答案。命令一被接收，输入框就清空，不等模型回复。
- 答案由会话当前的服务商和模型写。默认问题是独立的（context: none）；context: session 会连对话一起发过去。
- 答案按 Markdown 渲染：标题、列表、引用、表格、围栏代码、行内代码、加粗、斜体、链接。
- 模型先推理再作答时，这一行会在答案上方带一个可折叠的 Thinking 块，旁问因此能展示它在继承的思考级别下做的工作。
- 摘要行是像宿主自己的 Turn 行那样的展开控件：问题省略成一行，箭头翻转，点这一行任意位置就把答案折起来或放回来。围栏代码在自己的块里保留换行。
- Esc、草稿和队列都不受影响：第二个问题、后续提示词、正在跑的回合，各自独立继续。

答案不是模型消息，也不属于下一次请求。它以命令生命周期（command/run、command/done）记进会话日志，所以重载、fork、重放之后都还在，并且在会话记录里只出现一次。

安装

在 DeepSeek Harness 配置档里，两种形式都行——已发布的 spec，或者本地检出：

plugin_manager install_bundle target=github:douglarek/dsh-btw
plugin_manager install_bundle target=/absolute/path/to/dsh-btw

bundle 插入一个名为 dsh-btw 的 Host 行，并通过 dsh.client 声明它的浏览器半边。启用这一行，/btw 就出现在输入框的命令菜单里，/btw 渲染器也注册进对话。

配置

每个键都有代码默认值；cordis.patch.yml 里的值就是这些默认值。

| 键 | 默认值 | 含义 |
| enabled | true | 是否挂载命令。 |
| context | none | 旁问请求能看到什么。none 问一个完全不带对话的独立问题；session 在前面加上下面这段有界对话记录，也就是 Grok 的 /btw 的做法。 |
| description | 旁问：不打断当前任务地提问 · Ask a side question without interrupting | 显示在输入框 / 列表下方的说明文字。客户端会原样渲染第三方 Host 命令的目录描述，所以这里是唯一能设定其措辞和语言的地方。 |
| maxContextChars | 12000 | 随问题一起发送的对话记录码点预算。保留开头的任务提示词和最近的消息，其余部分汇总为一条省略计数。 |
| maxToolResultChars | 1200 | 该对话记录中单条工具结果的字符上限。 |
| includeToolResults | true | 工具输出是否计入对话记录。关掉它，长会话里的旁问开销更低。 |
| timeoutMs | 120000 | 单次旁问请求的时限；0 会被拒绝。 |
| temperature | 0.2 | 旁问请求的采样温度。 |
| maxTokens | 未设置 | 旁问请求可选的输出上限。 |
| reasoningEffort | 未设置 | 可选的思考级别覆盖。未设置时继承会话自身运行的级别：先取它当前的模型选择，再取它最近一次请求的路由；两者都没指定级别时，同一服务商与模型下按配置档默认模型的级别处理。 |
| provider、model | 未设置 | 可选的固定路由。未设置时使用会话最近一次请求的路由，再退到配置档的默认模型。两者必须一起提供。 |

与提示词的区别

| | 提示词 | /btw |
| 等待正在运行的回合 | 是 | 否 |
| 进入模型的下一次请求 | 是 | 否 |
| 能看到会话的对话 | 是 | 仅当 context: session |
| 使用工具 | 是 | 否 |
| 出现在会话日志中 | 作为一条消息 | 仅作为命令生命周期 |

工作原理

- Host（index.js、lib/）：用 ctx.commands.register() 注册 btw 命令。旁问请求走会话自己的路由——它的服务商、模型和推理强度——所以旁问的思考级别与主回合一致；会话从未选过级别时，退到配置档默认模型的级别。处理函数在任何回合之外运行，并且立即返回：输入框会一直保留已认领命令的那一行，直到处理函数返回，所以在这里等待模型会把用户的草稿占住整个请求时长。随后 lib/answer-runner.js 从会话当前的模型选择解析路由（退到 session.requestHeader()，再退到 ctx.agentDefaultModel），按固定的旁问策略、不带工具地流式发起一次 ctx.llm.stream() 请求，并为该次运行的 commandId 追加 command/done，从而结束同一行。在 context: session 下，它先把 session.deriveMessages() 摊平成纯文本对话记录；在默认的 none 下，请求就只有问题本身。llm 和 commands 是硬注入，所以缺少它们的配置档里插件保持不激活。
- Client（client.js）：在键 btw 下注册 conversation.chat.commandview，这是 Chat 视图按命令名分发的键控槽位。组件在展开行上渲染问题，答案以 Markdown 渲染，走本 bundle 自带的小型块级/行内解析器（插件的代码无法导入宿主的 Markdown 组件）；主题只用 --dsw-alias-* token，文案取自插件自己的 locale 命名空间。

限制

- /btw 必须位于消息开头。Grok 还会把消息中间的 /btw 提升出来，并把该行剩余内容当作附带问题；Harness 命令平面只在字节零处解析命令，所以 fix the retry loop. /btw why? 会作为普通提示词发送。
- 答案一次性到达。命令平面只结算一次 handler，因此该行无法流式输出 token。
- 投递方式是针对原始 commandId 再发一个 command/done（handler 返回时执行器已经记录过一个）。Chat 命令节点会把它折叠进已有的行；如果读取方期望每次运行恰好一个 command/done，就会看到两个。
- 生命周期只携带一个 text 字符串，所以带推理内容的行会把它内联存放在 <<<btw:reasoning>>> 与 <<<btw:answer>>> 标记行之间（lib/result-text.js）。行解析器会读取这些标记；随附的通用命令卡片不读取，会把标记当作文本显示。
- 工具调用、图片和 plan 模式的附带请求不在范围内：附带请求不声明任何工具，只发送文本。
- 从未发送过请求的会话发起的附带问题，需要在配置里提供 provider 和 model，因为此时还没有可继承的路由。
- / 列表只为 dsh-client-ui-commands 的 HOST_FACES 表中六个第一方定义 id 绘制字形和本地化标题；其他任何 Host 命令都渲染其名称加上本插件的 description。第三方命令无法在那里添加图标，而客户端侧的命令贡献——本可以添加——不接受参数，所以 /btw <question> 会失效。

开发

node --test # unit tests
node scripts/check.js # syntax, manifest, bundle entry points, locale keys