显式要求「等结果就结束本轮」后，模型仍会反复轮询子代理并把它停掉

[Engrivnm]

环境：@deepseek-ai/dsh 0.2.2-rc.1，web profile，standard preset，deepseek-flash。

本文记录在用户已给出明确等待规则的情况下，子代理的等待行为，以及对应的实现分析。

背景

会话启动时，用户级指令文件 ~/.dsh/AGENTS.md 会作为一条 user 角色消息注入（createUserMessage + <system-reminder> 包装）。其中与子代理等待行为相关的三条原文：

• When the next step needs results a subagent has not produced yet, end the current turn.
• Don't worry about long run times, don't repeatedly check whether a subagent has finished, and don't readily conclude that a stuck subagent should be stopped. One stop makes all of that subagent's earlier work go to waste.
• Always have a subagent review documentation; never judge your own work from your own perspective.

即：需要子代理结果时结束本轮；不反复检查；不轻易停掉卡住的子代理。以下现象发生在该规则生效的情况下。

现象

本机 19 个会话中，subagent 调用 36 次，list_agents 调用 39 次，轮询次数多于派发次数。

两个样本：

• 某轮：派发后连续 9 次 list_agents，随后调用 interrupt_agent 停掉子代理。此时已过约 15 分钟，评审结果全部作废。
• 另一轮：先查 6 次，随后写下 We should end turn, wait for subagent，结束本轮并回了一句状态。

同一模型、同一份指令，两次结果不同。

机制分析

（1）阻塞原语的可用性不对称。 同一份系统提示词中，后台任务侧为 collect every still-relevant job with job_output (set wait: true only when you are genuinely blocked on it)；子代理侧为 When only waiting for their results remains, end your turn instead of sleeping or polling。subagent 立即返回 id，没有 wait 参数，结果以 user 消息形式的 settlement notice 到达。在结果到达前，list_agents 是唯一可用的观察手段。

（2）轮询结果不携带下一步。 list_agents 在 still running 时只返回状态。dsh-repeat-tool-reminder 在第 3 次相同调用时建议「换个做法或结束任务」，其中不含「结束本轮」。本次会话中，轮询之后实际发生的是重复检查子代理正在检查的内容。

（3）注入层级。 AGENTS.md 以 user 角色注入，层级低于 system。transcript 中模型的推理为 "The AGENTS.md is guidance; the user is waiting."，随后调用 interrupt_agent。

（4）挂起契约不可验证。 「结束本轮后下一轮会自动开始」是模型无法在会话内验证的承诺。实际行为表现为持续轮询。

建议

参考 job_output 的 wait: true 语义，让「正在等待子代理」成为一个有明确定义、有明确下一步的状态：

• list_agents 在 running 时附带「结束本轮，等待 settlement notice」，而不是只返回状态；
• dsh-repeat-tool-reminder 在重复调用 list_agents 时输出 end the turn and wait for the settlement notice，而不是通用的「换个做法或结束任务」。

这样在阻塞时存在一个被明确许可的下一步动作。