提交前确认 · Pre-submission checklist
问题类别 · Category
对话 / Agent 交互 · Agent chat / interaction
涉及的 Agent 框架 · Agent framework
ZCode Agent（自研）
使用场景 · Use case
在 ZCode 桌面端提交一个任务后，agent 进入长时间执行（跑命令、改代码）。此时我发现某个约束需要调整（例如"顺便把 X 也处理一下""先别动 Y 文件"），直接在输入框打字发送——消息被排队挂起，要等整个任务完整跑完才被 agent 看到。结果是：要么干等几十分钟，要么 ESC 打断丢掉已有进度。消息本身没有丢失，但"执行中途改方向"这个能力事实上不存在，体感上输入框形同虚设。
建议方案 · Proposal
任务执行中的用户输入默认（或通过设置项）走 turn steering（guide 投递）：在当前 run 的下一个工具调用 / 回合边界注入对话流，让 agent 中途消化新指令、继续当前任务而不是推倒重来。内核机制已经完整存在（证据见补充材料），缺口只在于用户聊天输入默认按 queue 投递准入。建议：
- 对 active 且
steerable 的 turn，用户输入默认升级为 guide 投递；或提供设置项「执行中输入：转向 / 排队」。
- UI 上给出轻量的「已转向 → 已注入」状态提示（
turn.steerQueued / turn.steerDrained 事件已在发射，桌面壳已在监听）。
预期价值 · Expected value
长任务不再是"说了白说"或"打断重来"：用户在 agent 工作时说的话在秒级（当前工具边界）生效。这是 agent 产品的核心竞争力级交互——Claude Code 的 mid-run steering 已被验证是高频刚需；而 ZCode 的内核管道已就绪，接线成本低于从零实现。
你认为的优先级 · Your perceived priority
高 · High
你使用的 ZCode 版本 / 环境 · ZCode version / environment
ZCode Desktop 3.14.3.7762, Windows 11 (build 26200)
补充材料 · Additional context
以下为「机制已存在、只差接线」的证据（对 shipped 桌面 bundle 的观察，并与本组织开源仓库 zai-org/ZCode 的源码交叉验证）：
- 运行时输入分类已包含
user_steer，与 coordinator_steer / subagent_reply_steer / task_notification_steer 并列。
steerTurn API 支持 delivery: "guide" | "queue" 双投递，事件生命周期完整（TurnSteerQueued / Drained / Discarded / Rejected / Reordered）。
apps/zcode-cli/packages/core/src/runtime/methods/prompt-admission.ts：canSteer 门槛判断与 fallback 到 enqueueDeferredInput 的逻辑。apps/zcode-cli/packages/bootstrap/src/app/input-facade.ts：sendInput → enqueueDeferredInput（inputPresentation: "user_steer"）。
- 桌面壳已监听
turn.steerQueued / turn.steerDrained，并具备 steer 状态机（notRequested → submitting → steering → guided / fellBack，含 queuePosition）。
guide 投递已被 coordinator 路径（coordinator_steer）实际使用，含等待 active turn 的重试轮询——说明该通道经过实战。- 关键门槛：
prompt-admission.ts 中走向 steering 需要同时满足 activeTurn?.steerable === true 且调用方传 queueDelivery: "guide"（或 delivery: "auto" | "steer_active_turn"）；用户聊天输入看起来以默认 queue intent 准入，因此落入 enqueueDeferredInput（delivery: "queue"），等整个 run 结束后才作为新回合送入。
提交前确认 · Pre-submission checklist
问题类别 · Category
对话 / Agent 交互 · Agent chat / interaction
涉及的 Agent 框架 · Agent framework
ZCode Agent（自研）
使用场景 · Use case
在 ZCode 桌面端提交一个任务后，agent 进入长时间执行（跑命令、改代码）。此时我发现某个约束需要调整（例如"顺便把 X 也处理一下""先别动 Y 文件"），直接在输入框打字发送——消息被排队挂起，要等整个任务完整跑完才被 agent 看到。结果是：要么干等几十分钟，要么 ESC 打断丢掉已有进度。消息本身没有丢失，但"执行中途改方向"这个能力事实上不存在，体感上输入框形同虚设。
建议方案 · Proposal
任务执行中的用户输入默认（或通过设置项）走 turn steering（
guide投递）：在当前 run 的下一个工具调用 / 回合边界注入对话流，让 agent 中途消化新指令、继续当前任务而不是推倒重来。内核机制已经完整存在（证据见补充材料），缺口只在于用户聊天输入默认按queue投递准入。建议：steerable的 turn，用户输入默认升级为guide投递；或提供设置项「执行中输入：转向 / 排队」。turn.steerQueued/turn.steerDrained事件已在发射，桌面壳已在监听）。预期价值 · Expected value
长任务不再是"说了白说"或"打断重来"：用户在 agent 工作时说的话在秒级（当前工具边界）生效。这是 agent 产品的核心竞争力级交互——Claude Code 的 mid-run steering 已被验证是高频刚需；而 ZCode 的内核管道已就绪，接线成本低于从零实现。
你认为的优先级 · Your perceived priority
高 · High
你使用的 ZCode 版本 / 环境 · ZCode version / environment
ZCode Desktop 3.14.3.7762, Windows 11 (build 26200)
补充材料 · Additional context
以下为「机制已存在、只差接线」的证据（对 shipped 桌面 bundle 的观察，并与本组织开源仓库
zai-org/ZCode的源码交叉验证）：user_steer，与coordinator_steer/subagent_reply_steer/task_notification_steer并列。steerTurnAPI 支持delivery: "guide" | "queue"双投递，事件生命周期完整（TurnSteerQueued/Drained/Discarded/Rejected/Reordered）。apps/zcode-cli/packages/core/src/runtime/methods/prompt-admission.ts：canSteer门槛判断与 fallback 到enqueueDeferredInput的逻辑。apps/zcode-cli/packages/bootstrap/src/app/input-facade.ts：sendInput→enqueueDeferredInput（inputPresentation: "user_steer"）。turn.steerQueued/turn.steerDrained，并具备 steer 状态机（notRequested → submitting → steering → guided / fellBack，含queuePosition）。guide投递已被 coordinator 路径（coordinator_steer）实际使用，含等待 active turn 的重试轮询——说明该通道经过实战。prompt-admission.ts中走向 steering 需要同时满足activeTurn?.steerable === true且调用方传queueDelivery: "guide"（或delivery: "auto" | "steer_active_turn"）；用户聊天输入看起来以默认 queue intent 准入，因此落入enqueueDeferredInput（delivery: "queue"），等整个 run 结束后才作为新回合送入。