[Bug]？ goal 功能开启后 agent 无法被动等待后台任务：每次进入 idle 即被强制注入 <goal_round>，空转消耗轮次与 token

[yaungcn]

在使用DSH进行一个长任务时，中间agent需要等待运行结果，但是目标功能不断启动goal上下文注入，只能通过手动暂停goal功能以停止。请问这是DSH本身问题还是我使用的问题？下面是DS总结的具体内容。

环境
DSH 本地 npm 安装版，涉及包：@deepseek-ai/dsh-goal、@deepseek-ai/dsh-goal-round-driver、@deepseek-ai/dsh-tool-jobs
版本号：v0.1.1 rc.2

问题描述
开启 goal（目标默认 active + armed，续行启用）后，当 agent 需要"等待后台任务完成"并采用工具文档推荐策略——结束回合、不轮询、等完成通知——goal 会在 agent 每次进入 idle 时强制注入 <goal_round> 目标上下文并开启新一轮：

agent 无法停留在 idle 被动等待，每回合结束都被立即注入唤醒；
每一轮被迫产出"还在等待"之类的空转回合；
roundsStarted 逐轮递增（默认上限 256），每轮重发完整会话历史 + 目标块，token 持续消耗；
空转回合中 agent 甚至出现对"已过去多久"的幻觉式估计（无新信息却自称 ~15/20/25 min in）。

预期行为
agent 按工具指引被动等待后台任务期间，goal 不应注入/强制续行；任务完成通知到达后再继续（或由用户显式 resume）。

实际行为
回合记录中每回合均带"上下文注入 goal"标记，Round 连续出现"等待中 / End round"，数分钟内多个空转回合，目标上下文被反复注入。如下图：

复现
创建目标（保持 active + armed，如 maxGoalRounds: 2 即可）；
启动一个较长后台任务（如 pwsh 循环 Start-Sleep，约 2.5 分钟）；
指示 agent"等待完成通知、不轮询"，结束回合；
观察：几秒内注入 <goal_round>（Round 1/2，含完整目标），此时任务仍在运行（才到第 1 个 tick），roundsStarted 由 0 变为 1。
对照：回合内用 job_output(wait: true) 阻塞等待则无注入（roundsStarted 保持 0）——触发条件是 idle 检查点，与是否调用等待工具无关。

[weijiafu14]

这不是你的用法问题，是设计里缺一个判断。我按 0.1.1-rc.2 源码核了一遍，你的定位是对的，而且缺口比你写的更具体。

根因就在那一个 handler 里。 @deepseek-ai/dsh-goal-round-driver 的 agent/status 监听：

ctx.on('agent/status', ({ agent, status }) => {
  if (status === 'idle') {
    // …（只处理"目标已被取消"这一个分支）…
    requestDrive(state)

requestDrive 在 idle 上无条件触发，driver 里没有任何"这个 agent 是不是正在等什么"的概念。所以你的对照实验（job_output(wait: true) 在回合内阻塞就不注入）不是巧合——触发条件就是那个 idle 检查点本身，与你调不调等待工具无关，你这句话写得完全准确。

问题的一般形状：idle 被当成"没事可做"的代理指标，而它不是。它只表示"当前没有回合在跑"。一个刚按工具文档建议结束回合、等后台通知的 agent，和一个真做完了的 agent，在这个信号上完全一样。

但判断所需的数据已经有了，而且就在同一个进程里的公开服务上。 JobsService 有：

abstract list(caller?: Agent): JobSnapshot[]

同步、按 agent 归属、返回当前快照。而 goal-round-driver 的 peerDependencies 只有 dsh-agent / dsh-goal / dsh-invariants / dsh-llm / dsh-session / cordis，源码里一次都没提过 jobs。所以这不是缺 seam，是两个子系统还没有接上——修法不需要新增任何公开面。

干净的接法是 cordis 的可选注入（ctx.inject(['jobs'], …)，官方 llm-pi-ai 就是这个模式），这样：组合里有 jobs 服务时，idle 上若 list(agent) 还有未结束的作业就推迟续行，等作业结算后再进；组合里没有 jobs 服务时行为与今天完全一致，不产生硬依赖。

两点补充：

1. 空转回合不是"只是浪费 token"。 你记录到 agent 在没有任何新信息的情况下自称 "~15/20/25 min in" ——被强制发言而无话可说时，模型会把时间感编出来，而这些幻觉句子会进会话历史、被后续回合当事实读。这比 roundsStarted 递增更值得写进问题描述。
2. jobs 大概率不是唯一要挡的信号。 等审批、等子代理，同样是"idle 但不该续行"。建议提案写成"续行前先问一遍：这个 agent 是不是在等某件已经发起的事"，而不是只特判 jobs——否则下一个能让 agent 合法停下的机制出现时还会再撞一次。

能不能先用第三方插件自救：ctx.goals 的 pause(agent, ref) / resume(agent, ref) / get(agent) 都是公开方法，所以原理上可以写一个插件，监听 agent/status，在 ctx.jobs.list(agent) 还有活作业时 pause、作业结算后 resume——正是把你现在手动做的那件事自动化。必须说明：这条我只读了源码，没有写过、没有跑过，所以只能算"看起来可行"，不算实测结论；真要做还得处理 pause 会改变目标 phase、以及你手动暂停时它是否可见这些细节。在官方修好之前，你现在手动暂停 goal 的做法仍然是最稳的。

利益相关：我维护一个第三方 DSH 插件（Pi 生态兼容层）。goal 与 jobs 都是 DSH 自家组件，我们不碰也修不了，上面全部是对官方源码的核证。