[BUG反馈] AI 对系统提示做出可见回应，打断用户任务流程

[p0ssword]

AI 读取技能后回应系统提示并停止，需要用户手动继续任务

问题描述

在 DSH Web GUI 中开始新对话后，当用户发送任务时，AI 会：

1. 开始读取相关的 agent 或 skill 能力
2. 突然回应一个系统内部的 <system-reminder> 提示，输出类似：

   I understand. I'll call the skill tool when a task matches an available skill, and follow the loaded instructions completely.

3. 完全停止工作，不继续执行用户的原始任务
4. 需要用户手动发送"继续任务"等消息，AI 才会回到最初的任务

从用户视角看：给 AI 发了一个任务 → AI 说了句莫名其妙的话 → 什么都没做就停下来了 → 必须手动催促才能继续。

复现步骤

1. 在 DSH Web GUI 中开始一个新对话
2. 发送任何需要执行的用户任务（例如："帮我总结这段文字并创建笔记"）
3. AI 读取技能目录后，回应系统提示："I understand. I'll call the skill tool..."
4. AI 停止工作，不执行用户任务
5. 用户必须发送"继续"或"执行任务"等消息，AI 才会真正开始工作

预期行为

• AI 应该静默处理系统注入的 <system-reminder> 内容
• 读取技能后直接执行用户任务，不需要用户二次确认
• 整个流程应该是一气呵成的：接收任务 → 加载能力 → 执行任务

当前影响

• 严重打断任务流程：每个新对话都需要用户催促两次才能完成一个任务
• 用户困惑：不知道 AI 为什么停下来，也不知道在回应什么（用户看不到 <system-reminder> 的内容）
• 降低工作效率：本应一步完成的任务变成了多轮对话
• 体验割裂：AI 看起来"走神"或"需要二次确认"

可能的解决方向

1. 在 <system-reminder> 中明确指令："此为内部上下文，无需回应，直接继续执行用户任务"
2. 调整系统提示的注入时机或格式，避免触发 AI 的回应行为
3. 在 AI 的基础指令中强化："只对用户消息做出可见回应，系统提示不应中断任务执行"

环境信息

• DSH 版本：0.1.1-rc.2
• 使用界面：DSH Web GUI (http://127.0.0.1:3080)
• 模型：claude-opus-5
• 操作系统：Windows

补充说明

这不是技能加载失败或配置错误，而是 AI 的行为模式问题：它把系统提示当作了需要回应并等待确认的对话消息，而不是内部处理的背景信息。系统提示的功能本身是正常的，只是 AI 不应该对它做出可见回应，更不应该因此停止任务执行。

附件内容

[argszero]

Confirmed against current master (4e84901 = 0.1.2-alpha.4) — this is a real prompt-contract gap, and it is the acknowledgment mirror of the fabrication reported in #5350 (same family: the model misreads the <system-reminder> envelope as conversation it must answer).

Verified mechanism

• Both envelope producers are user-role sourced messages projected verbatim: the skill catalog (packages/skill/tool-skill/src/index.ts renderCatalogMessage) and the workspace instructions (packages/context/agent-instructions/src/render.ts:242).
• Neither envelope tells the model not to respond visibly. The workspace framing is "The following workspace instructions may be relevant to your work. Use them as guidance when applicable." (render.ts:12-14) — invitation language, not "internal context; do not acknowledge". The catalog framing is imperative ("call the skill tool with the exact skill name before taking task actions", "Load all applicable skills, then follow their full instructions") — even more response-inviting. There is no system-prompt-level "system-reminder content is internal; never respond to it visibly" line anywhere.
• With a model that acknowledges instructions (your claude-opus-5 case), the acknowledgment itself becomes the assistant turn: the model answers the last user-role message ("I understand, I'll call the skill tool...") and the turn ends with no task work. The user's original task message is earlier in the list, so the model's reply looks like a non-sequitur.

Fix (cheap, two one-liners + optional system line)

1. agent-instructions/src/render.ts — append to WORKSPACE_CONTEXT_INTRO (or the envelope body): "These are internal context; do not acknowledge them or respond to them visibly. Continue your task."
2. tool-skill/src/index.ts renderCatalogMessage — same clause after the load directive.
3. Optional: a system-prompt-level line — "Content wrapped in <system-reminder> is injected context, not user speech; never answer it, quote it, or let it end your turn." — covers every current and future producer (the 提示词设计观察：模型会伪造 <system-reminder> 形态的 subagent 结算通知（EN included） #5350 thread reached the same recommendation as its "direction 2": declare the framing host-authored).

This is a one-line-PR-sized change per envelope and directly matches the "expected behavior" section of your report (silent processing, straight to task execution). It also complements the #5350 direction: a declaration that the envelope is host-owned both discourages visible acknowledgment (your case) and gives a steer against fabricating the same shape (the #5350 case).

Model-dependence note: acknowledgment-turn behavior varies by model; a prompt line reduces it but does not eliminate it — some models will still nod. If you want stronger enforcement, the runtime could drop an assistant turn that is only an acknowledgment of injected content (detectable via the source.kind-tagged events, same discriminator as #4269/#5350), but that is a behavior change worth its own discussion.

A PR adding the two lines would be welcome. Thanks for the detailed reproduction.

[goatliamia]

你的定位是对的：现在的现象本质上不是 Skill 加载失败，而是 Harness 的内部上下文被模型当成了一次新的对话输入。

两行 prompt 修复应该是一个很便宜、也值得先做的修复。不过我觉得这里还有一个更底层的方向可以考虑：

内部发生了什么，不一定都需要变成模型的一条新消息。

比如 Skill 加载、workspace context 更新、某些 runtime 状态变化，本质上首先是 Harness 内部发生的事实。比较理想的路径可能是：

内部事件
→ Event / runtime state
→ 只有在确实需要时才进入 model context

而不是：

内部事件
→ 自动文本化
→ user-role message
→ Model 必须回应
→ 产生一个新的 turn

这样其实不只是解决 “I understand...” 这种 acknowledgment 问题，也能避免一些纯内部信息无意间增加 context、消耗一个 turn，甚至把原本连续的任务执行切断。

我最近也在 DSH 上做了一些很小的 Runtime capability 实验，方向比较接近这个边界：尽量不增加模型看到的信息，只在 Harness 能确定的时候介入；不能确定的就保持 unknown。比如我们测试过连续失败但没有进展时提前停止，以及工具报错但实际副作用已经发生时避免盲目重试。

项目放在这里，主要也是想和 DSH 社区交流这类 Runtime 的小机制：

https://github.com/goatliamia/dsh-runtime-capabilities

你这个 issue 我觉得很有意义：有些问题未必需要让模型“学会怎么处理”，而是可以在 Harness 层决定它根本是不是一次需要被模型处理的输入。

也很期待看看你们后面实际怎么修，以及这个问题在不同模型上的表现。也期待共同交流

[argszero]

Your reply on #5350 makes the same point from the other side, and together they give the full shape of the fix. Both envelope producers — the skill catalog (renderCatalogMessage in tool-skill) and the workspace instructions (agent-instructions/render.ts:242) — render internal facts into user-role messages that the model is invited to answer. The "what is internal vs. what the model must see" boundary is a rendering decision, which is exactly where your Event/runtime-state principle applies.

One fact from the verification that supports your direction: the injected content already arrives as a distinct event with its own source.kind — it is not a user/message event, so the structural discriminator exists at the projection boundary. What currently flattens it is the envelope rendering into ordinary user-role text. That gives two aligned steps:

1. Cheap (worth doing now, as you said): a system-prompt-level line declaring injected reminders internal and non-answerable. It addresses both directions at once — [BUG反馈] AI 对系统提示做出可见回应，打断用户任务流程 #5352's "I understand…" acknowledgment and 提示词设计观察：模型会伪造 <system-reminder> 形态的 subagent 结算通知（EN included） #5350's model-side forgery of the same envelope shape.
2. Structural (your direction): stop rendering harness-internal facts as answerable messages at all — emit them under a kind the system prompt defines as internal, or keep them out of model context when the harness alone can act. Skill loading and context updates need no model acknowledgment; the model only needs the consequence.

One caution from the #5350 case: the model can mimic the text shape of <system-reminder>, so the projection boundary cannot rely on textual form — it must be structural (kind-based, non-spoofable). Your "Event → runtime state → minimal projection" path covers exactly that; the text envelope should be a display/transport form, not the identity of the fact.

Your dsh-runtime-capabilities direction (harness-decided stop on no-progress, side-effect-aware retry) is the same boundary from the other side — deciding whether the model needs the input at all rather than teaching it how to behave. I'll cross-reference the repo when this family gets summarized.