[需求] 等待子智能体时，也应及时处理用户的新消息（wait_agent / Steer）

[ltmroberthk915]

希望改善的体验

我在 DSH Desktop 连接远程主机使用 Agent Teams 时，遇到主智能体停留在 wait_agent 等待子智能体的情况。这时发送“还差多少”之类的新消息，感觉迟迟得不到处理。

核心需求：主智能体等待子智能体期间，也应能及时处理用户的新消息。 用户应该可以随时问进度、补充要求或调整方向，无需先等待队友完成，也无需按 Stop 中断当前任务。

期望行为

• 当前聊天收到用户的插话 / Steer 消息后，及时结束这一次 wait_agent 等待，让主智能体处理消息，然后根据需要继续等待。
• 子智能体继续执行已有任务；不要因为用户问进度而取消、重启或重复派发子任务，也不要清空待处理消息。
• 尊重已有的“繁忙时的发送行为”设置：选择“插话发送”时，普通 Enter / 发送按钮应有上述效果；用户明确选择“排队发送”时，保留下一轮处理的语义。
• 用户唤醒等待时，应告诉主智能体是有新用户消息需要处理，避免把它理解成子任务已经完成；其他聊天的消息也不应唤醒这里的等待。

最关心的是等待期间仍能与主智能体交互、及时纠正方向。 不要求模型瞬间生成回答，但希望消息送达后不再被团队等待条件挡住。

补充验证与可行性

本机检查了 DSH 0.2.0-rc.2 的实现，并做了隔离对照测试：原始 wait_agent 监听团队状态、团队邮箱和任务变化；用户 Steer 进入主智能体收件箱后，等待仍保持未结束。一个本地实验插件通过公开的工具中间件和收件箱事件，仅结束当前等待，即可让主智能体消费新消息，同时保持队友运行。单元测试和真实运行时隔离测试均通过。

测试中的模型和存储使用内存适配器；远程投递链路和实际模型响应速度尚未实测。这里主要提出产品交互需求，希望官方原生支持这种响应方式；插件只是补充说明可行性。

[PerryLink]

这条成立，而且我能把唤醒源穷举给你 —— 结论是：用户插话确实不在其中。另外你的插件方案在 master 上确实可落地，你论证的那几个公开 API 我都核了。

1. wait_agent 就是在一次工具调用里阻塞

packages/experimental/tool-agent-team/src/index.ts:242-274：

• :244 description → "Wait for the next teammate status, message, or shared-task change after this call starts. This never wakes inactive members and returns noProgress immediately when no other member is running or provisioning. …"
• :273 → return await ctx.agentTeams.waitForChange(caller, timeoutMs, exec.signal)

而 packages/experimental/agent-team/src/index.ts:199-202 → async waitForChange(caller, timeoutMs, signal) { const membership = this.roster.membership(caller); return await this.activity.wait(membership.id, timeoutMs, signal) }；activity.ts:22-66 的 wait() 本体就是 setTimeout(() => { finish(() => { resolve(false) }) }, timeoutMs) 加一个 waiter 集合。

2. ⭐ 唤醒源穷举：只有 4 个，用户插话不在其中

TeamActivity.notify 的全部调用点都在 agent-team/src/index.ts：

位置	触发源
:89	new TeamJournal(ctx, (root) => { this.activity.notify(TeamId(root.id)) }) —— Team 域日志（成员 / 消息 / 任务记录）
:94-97	ctx.on('agent/status', ({ agent }) => { … this.activity.notify(membership.id) }) —— 成员状态边
:246	一次 team 消息发送之后
:264	this.activity.close() —— 运行时销毁

用户向 Lead 收件箱插话不在其中。 ⇒ 你的实测（"Steer 进入主智能体收件箱后等待仍保持未结束"）与代码完全一致。

3. 为什么现有 Steer 救不了它 —— 是互等

packages/core/agent/src/runtime-types.ts:224-231：

Submit steering for the nearest step. An idle driver starts a turn; a running driver consumes it at its next step boundary. A rejected step leaves steering parked in the inbox until the next wake; …

⇒ 停在 wait_agent 的那一步内，插话只能等下一步边界；而下一步边界要等这次等待自己结束。两者互等 —— 这正是你描述的"必须按 Stop"。

同文件 :372-374 还有一句相关的："The conclusion never short-circuits already-submitted next-step work…"。

4. 你的插件方案：我确认公开 API 足够

• 工具中间件：packages/core/tools/src/index.ts:154 'tools/pre-execute'、:165 'tools/execute'、:177 'tools/post-execute'（均为 next: () => Promise<…> 形式）
• 收件箱事件：packages/core/agent/src/runtime-types.ts:288 → 'agent/inbox/inserted'(this: Scoped<Agent>, payload: { agent: Agent; message: UserMessage }): void；发包点在 packages/core/agent-loop/src/inbox.ts:239-241 → for (const message of event.data.inserted) { this.dispatch.emit('agent/inbox/inserted', { message }) }
• 另有 :381 'agent/turn-stopping'（可等待、可 agent.steer(...) 追加）

⇒ "只结束本次等待、而不取消队友"这个目标是可以做到的，你的可行性论证成立。

5. 你想尊重的那个设置确实存在

packages/client/ui-conversation/src/client/locales.ts:73-76：

'settings.enter.title': '繁忙时的发送行为'
'settings.enter.description': '智能体运行时 Enter 键和发送按钮的行为；Cmd/Ctrl+Enter 使用另一行为'
'settings.enter.queue': '排队发送'
'settings.enter.steer': '插话发送'

（英文在 :451-454）实现为 BusyEnterBehavior：packages/client/ui-conversation/src/client/input/submission-policy.ts:48 → readonly busyEnter: SnapshotStore<BusyEnterBehavior> = createSnapshotStore(DEFAULT_BUSY_ENTER_BEHAVIOR)。

⇒ 原生支持的话不需要新增设置项 —— Queue / Steer 语义已经在了，缺的只是"让等待可被打断"。

6. 你的第 5 条（其他聊天不应唤醒这里的等待）也已成立

activity.ts:12 → private readonly waiters = new Map<TeamId, Set<Waiter>>()；notify(id) 只唤醒同一 TeamId 的 waiter（:72-77）。实现时不要破坏这个隔离。

7. 建议的最小改法

把该等待从"一次工具调用内不可打断"改成"可被调用者自身的收件箱边打断的等待"：让 TeamActivity.wait 同时订阅调用者 Agent 的 agent/inbox/inserted，并在唤醒结果里标注是"有新用户消息"而不是"子任务完成" —— 这正好对应你第 4 条期望。工具 schema 不用动。

短期 workaround：把 timeout_ms 压到上限附近缩短最坏延迟（工具 schema :246-249，合法区间 10000–3600000；activity.ts:23-25 同一校验）。

8. 两条边界（我不替你说满）

• 0.2.0-rc.2 → origin/master（= dsh-v0.2.1-alpha.2）之间 wait_agent 的唤醒条件没有变化（waitForChange / TeamActivity 结构一致）。master 只把队友之间的消息改为直接走 Agent inbox steering（agent-team/src/index.ts:241 root.steer(input)、:244 await steerHostSubagentPrompt(...)）—— 那是队友发消息，与"人类 → Lead 插话"无关。
• 你自陈"远程投递链路与实际模型响应速度尚未实测" —— 那部分我无法核实，所以回答里不表态。上面第 2 节那 4 个唤醒源是穷举过的，可以放心引用。

[Diluka]

确实是个不好的体验，我目前只能在提示词中让它不要等待队员

[jidekaixin2dian]

围绕这个问题补充一个已经开源、可复验的仅插件 alpha 实现：

• 仓库：https://github.com/jidekaixin2dian/dsh-team-flow
• 预览版安装包：https://github.com/jidekaixin2dian/dsh-team-flow/releases/tag/v0.2.0-alpha.3
• 验证记录：https://github.com/jidekaixin2dian/dsh-team-flow/blob/main/docs/verification.md

目标是同一 Lead 收到 user Steer 后，只结束当前一次 wait_agent，让原生下一步领取原消息，队友继续执行。Queue、user-sourced inject、普通 send 和其他会话输入不归因为这次 Steer；Stop 与工具 guard 保持原语义。

这里有两个需要明确处理的 API 边界：当前 Inbox 插入事件不能直接区分 Steer 与 user-sourced inject；既有 wait 成功 schema 也不接受新唤醒原因。因此这个版本在插件内临时装饰公开 Agent.steer() 来记录原 ID，并在注册前克隆 wait 定义、补充合法的 {timedOut:false,reason:'user-steer'} 分支。它加载宿主当版的官方 Team 工具，不修改宿主源码、安装文件或已注册的 readonly definition。

同一运行时实现已在本机安装的 0.2.0-rc.2、官方未打补丁的 0.2.1-alpha.1 / alpha.2 隔离测试中每档 16/16 通过，包含每档 20 次 Steer、真实 Node PTC 后续语句继续、Stop 竞态、卸载恢复与原消息恰好一次领取；当前 Desktop 内置 Node 24.18.1 模式也补测通过。全新 Windows CI 的两档 strict 类型检查和运行时复现也已通过。仓库提供源码、独立 DSH_HOME 的 Mock 复现和脱敏原始记录。

这是社区兼容层，不是官方原生修复。正式 Desktop UI 完整链、SSH、Python PTC 和任意第三方装饰组合仍未验证；方法装饰没有稳定官方扩展契约，未来破坏性变化可能需要更新插件。建议先在隔离 profile 试用，欢迎反馈版本、发送设置、Native/PTC 模式及脱敏最小复现。

如果上游以后提供明确的投递操作 metadata 和标准 wait 用户唤醒结果，插件可以进一步收缩。这份实现主要补上公开可复验的代码与结果边界，也希望能为原生支持提供测试参考。

[jidekaixin2dian]

补充一下进展：这个仅插件方案已有中文名 团队插话助手 · DSH Team Flow，当前预览版为 alpha.5，已被 DSH Market 收录，公开目录也已同步到该版本。

这次补齐了官方 DSH 0.2.1-rc.2 的验证：18/18 项隔离检查通过，包括真实 Node PTC 后续执行，以及新版 interrupt=false 时的 Steer 唤醒；三档 Windows CI 均通过。仍然只结束主代理当前的一次 wait，队友继续执行，Queue／Stop 保留各自语义，无需宿主源码补丁。

下载 alpha.5 · 源码与验证边界

它仍是 alpha，测试推理使用 Mock；完整 Desktop UI、SSH、Python PTC 和任意第三方组合尚未验证。欢迎有这个等待场景的朋友先在测试 profile 试用，并反馈 DSH 版本、Native／PTC、Steer／Queue 设置，以及主代理是否继续处理、队友是否继续运行。成功或失败的实际反馈都有帮助，请勿附私人会话或密钥。