Skip to content

btw: ask a working Bot a side question without interrupting it or polluting its context #407

Closed

Description

@klarkxy

问题 / Problem

Bot 干活动辄几分钟到几十分钟。用户想「顺便问一句」时,普通输入框的消息按 busy-Enter 偏好排队或插队:排队要等当前回合结束才被读到;插队会改变 Bot 当前的路线;两种都永久进入对话历史,之后每一轮重复计费。缺少一条「立刻答、不打断、不留痕」的旁路。

Claude Code 2026-03 的 /btw 验证了这个需求:用当前会话的完整上下文做一次无工具、单轮的独立调用来回答,不打断主任务、不写入主对话历史。

设计 / Design

在 Bot 的私聊里,输入以 /btw 开头即旁路提问:

  • 回答用该 Bot 当前会话上下文的快照(截断到「工具调用都已有结果」的边界),以与会话自己的请求同构的方式(同路由、同思考强度、同工具声明)做一次独立调用,只在末尾追加问题——保留提示缓存前缀。
  • 不执行任何工具:模型返回的工具调用块不派发,重试一次,再犯即失败。
  • 不写进该 Bot 的模型可见历史,主对话与正在跑的回合不受影响。
  • 问答显示为一张 btw 卡(用户可见、模型看不到):回合在跑时在输入框上方的泊位、可取消,回合结束后归位到该回合的回合尾;旧分段的卡片并入旧分段渲染。每个 Bot 保留最近 20 条,问与答各限 2000 字。
  • 入口走 DSH 的输入触发机制;群聊、带附件、空问题三种情况认领后拒绝,绝不落入正常发送。
  • 同一个 Bot 最多 2 个在飞;调用计入用量页(kind: btw)。

完整设计说明见随 PR 合入的 docs/plans/2026-10-21-btw.md(经两轮评审修订)。

不做 / Out of scope

  • 群聊里的 btw、对群会话做快照。
  • Bot 对 Bot 的旁路问答(ask_bot):改动派活设计里「只提问不动手留给独立 app」的决定,另行提案。

Activity

  1. Notoonex commented on Oct 21, 2026

    @Notoonex

    👍 +1 confirming this issue with a critical multi-context user scenario:

    Real-world failure scenario: Single-chat long task disrupted by Group chat mention

    In addition to the user wanting to ask a quick side question in single chat, we encountered a severe workflow breakage in multi-session / group chat setups:

    1. The setup: A Bot is running an autonomous multi-step execution (e.g. running 5+ bash commands/code refactoring) in its private 1-on-1 chat.
    2. The trigger: While waiting, the user switches to a multi-bot Group Chat and mentions @Bot with a quick coordination task.
    3. The disruption: Because of the steer delivery path, the Bot interprets the incoming group task as a mid-turn course correction for the private chat, abandoning the uncompleted steps of the long task and jumping into the group topic.
    4. The consequence: The original long-running engineering task is permanently left half-done and cannot be resumed, causing significant user frustration.

    The proposed /btw side-channel mechanism in #407 is urgently needed. Furthermore, we strongly suggest:

    • Group chat deliveries should NEVER default to steering an in-flight private turn; cross-session events should either queue independently or isolate cleanly without hijacking a separate running session.
  2. klarkxy commented on Oct 21, 2026

    @klarkxy
    CollaboratorAuthor

    Thanks @Notoonex — both the +1 and the scenario are appreciated. The cross-session case is deliberately out of scope for this issue: /btw here covers only the private chat, and group-chat behavior is explicitly excluded.

    What you describe — a group-chat @mention steering an in-flight private turn — would be a delivery-routing bug of its own: deliveries are session-scoped by design (deliver() targets an explicit Session, and steer only cuts into that same Session's running turn), so a group message should never reach the private turn. I've split it into #411 so it gets tracked on its own — could you add your DS Bot/DSH versions and what the private chat looked like afterwards over there?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Ordinary bug or featureenhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions