goal 续行缺少"无进展"与"等待中"判断：0.1.6-alpha.2 仍复现

[DDDFXYqiming]

背景

本问题在 #1831 与 #4664 已有讨论。本帖补充三项前两帖没有的内容：0.1.6-alpha.2 的复现状态、源码级根因定位，以及另外两个框架在同一问题上的公开做法与原文——其中一家的做法表明，缓解空转并不需要引入独立模型。

环境

• DSH 0.1.6-alpha.2（dsh --version 实测）
• Windows 11，npm 全局安装
• 相关包均为 0.1.6-alpha.2：@deepseek-ai/dsh-goal、@deepseek-ai/dsh-goal-round-driver、@deepseek-ai/dsh-tool-goal
• 使用标准组合，未修改任何 goal 相关配置（profiles/web/cordis.patch.yml 中无 goal 条目，defaultMaxGoalRounds 未被覆盖）

现象

goal 处于 active 且续行已启用时，agent 无法停留在 idle 等待一件事完成：

• 需要等待后台任务或子代理时，回合结束即被注入 <goal_round>，无法被动等待
• 每一轮都被迫产出内容，即使没有任何新信息
• roundsStarted 逐轮递增，上限 256，每轮重发完整会话历史与目标块
• 为什么一个 /goal 命令的目标，在完成时需要校验256轮是否完成？ #1831 记录了更严重的形态：连续 160 轮内容几乎完全相同的验收，直到手动中止

源码定位

1. idle 是无条件的续行触发点

dsh-goal-round-driver/lib/index.js:213-229：

ctx.on("agent/status", ({ agent, status }) => {
  const state = stateFor(agent);
  if (status === "idle") {
    state.competingQueued = false;
    const attempt = state.attempt;
    const goal = currentGoal(state);
    if (attempt !== void 0 && (attempt.phase === "queued" || attempt.phase === "claimed" || attempt.cancelled) && goal !== void 0 && goal.phase === "active" && goal.activation === "armed" && attempt.goalId === goal.id && attempt.revision === goal.revision) {
      state.attempt = void 0;
      // ...pause 已取消的目标...
    }
    requestDrive(state);
  }
});

该分支只处理「目标已被暂停/取消」。requestDrive 之后进入 drive()，其中与 goal 状态相关的唯一停止条件是轮数上限（:125-131）：

if (goal.roundsStarted >= goal.maxGoalRounds) {
  ctx.goals.block(agent, goalRef(goal), {
    code: "round-limit",
    message: `Goal reached its configured limit of ${goal.maxGoalRounds} rounds.`
  });
  return;
}

驱动器内不存在「本回合是否产生了实际推进」或「agent 是否在等某件已经发起的事」的判断。idle 只表示「当前没有回合在跑」，一个刚按工具文档建议结束回合、等待后台通知的 agent，与一个真正做完了的 agent，在这个信号上完全一致。

2. 驱动器没有 jobs 视野

dsh-goal-round-driver/package.json 的 peerDependencies 为 dsh-goal、dsh-llm、dsh-session、cordis、dsh-invariants、dsh-agent，源码中不出现 jobs。而 JobsService 提供同步的 list(caller?: Agent): JobSnapshot[]，按 agent 归属返回作业快照。

3. 全部 block 代码只有三个

round-limit（:127）、queue-failed（:160）、prompt-rejected（:318）。没有对应「无进展」的稳定代码。

4. 空转未被计入异常

driver README 说明它会在轮次因 max tokens 结束、持久化写入失败、agent 被取消、插件卸载时自行停止。这些都是异常路径，「模型连续多轮没有实际推进」不在其中。

与包自述的关系

dsh-goal/README.zh.md 与 dsh-goal-round-driver/README.zh.md 的「已知限制」都写明「没有独立评估器」，开发备注把「评估器支持的完成与阻塞认证」列为开放方向。

本帖想指出的是：防住空转与"独立评估器"是两件可分离的事。

其他框架的公开做法

Claude Code /goal

官方文档：https://code.claude.com/docs/en/goal

• 每个回合结束后由一个独立的小快模型判定条件是否成立，返回 Not yet met / Met / Impossible；原文为 completion is decided by a fresh model rather than the one doing the work
• 停滞检测：If Claude keeps answering the evaluator without making progress (no tool use for several turns in a row), Claude Code stops the loop, prints a warning, and returns control to you with the goal still set.
• 等待感知：If a subagent or a background shell command is still running when a turn ends, Claude Code skips the evaluation for that turn.

Codex Goal

官方 cookbook：https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex

• 同样没有独立评估器，完成由模型对证据自判（the evidence decides whether it is done）
• 但续行带两条调度规则：
  • If a continuation turn makes no tool call, the next automatic continuation is suppressed so Codex does not spin.
  • Codex does not continue while another turn is active, while user input is queued, or while other thread work is pending.

关键对照：Codex 表明，显著缓解空转不需要额外模型——一条「本续行回合无工具调用则抑制下一次」的调度规则即可，成本接近零。

建议

按成本从低到高：

1. 在 drive() 中加入无进展抑制：记录最近一个已准入 round 是否产生过工具调用，连续 N 轮（可配置，默认 1–2）无工具调用则不再排入下一轮，并以稳定代码（如 no-progress）block 或提示用户。此条不引入新依赖，不产生模型调用。
2. 引入 pending-work 感知：以 cordis 可选注入（ctx.inject(['jobs'], …)，官方 llm-pi-ai 即此模式）在 idle 检查点查询 ctx.jobs.list(agent)，仍有未结算作业时推迟续行。组合中没有 jobs 服务时行为与现状一致，不产生硬依赖。同一判断后续可扩展到等待审批、等待子代理。
3. 独立评估器可独立于上述两条推进，二者不冲突。

一个值得单独记录的副作用

被强制发言而无话可说时，模型会编造时间感。#4664 记录到 agent 在没有任何新信息的情况下自称 ~15/20/25 min in。这些句子进入会话历史后会被后续回合当作事实读取。这比 roundsStarted 递增本身更值得注意。

---

本报告由用户在实际使用中遇到问题后，基于本地安装的 0.1.6-alpha.2 源码核查与上述官方文档整理。

[argszero]

Both scheduler rules you're asking for are reachable today from outside drive(), through the public seam — which means their policy can be deployed per-deployment without a core change, in the same way you correctly argue the evaluator can be separated from stall suppression.

What I verified in the 0.1.6-alpha.2 sources, so the mapping is exact rather than inferred:

Your suggestion	Public primitive	Effect
#1 stall suppression	ctx.goals.block(agent, ref, { code, message })	phase blocked, activation disarmed, durable blockedReason; needs an explicit resume
#1 "推迟"/#2 pending work	ctx.goals.pause(agent, ref)	phase paused, activation disarmed; the loop stops, the goal survives
#2 the resume edge	ctx.jobs.list(agent) + jobs.onJobDone(fn)	unsettled = running/stopping; onJobDone returns a disposer

One correction that matters. Suggestion #1 says "block 或提示用户". Those are two different harness operations, and the choice is not cosmetic:

• block is the stop primitive (packages/goal/goal/src/index.ts:409) — terminal until resumed, carries a durable reason, and once roundsStarted >= maxGoalRounds a resume is refused (:364).
• pause is the defer primitive (:352) — same goal, no accusation, resume is the expected next step.

Your #4664 evidence (the invented "~15/20/25 min in") and #1831's 160 near-identical rounds are stalls in a live loop, not a verdict that the goal is unreachable. That is precisely what Claude Code's "stops the loop, prints a warning, and returns control to you with the goal still set" describes — pause plus a durable notice, not block.

Three implementation facts I would want if I were writing this, none of which are in the report:

1. Listener order decides whether the deferral works at all. agent/status is emit-mode; the driver's own listener calls requestDrive(state) (packages/goal/goal-round-driver/src/index.ts:279), and with needsCheckpoint === false its drive() reaches agent.followup(message) (:191) in that same tick — a round admitted before your pause lands is not deferred. A pending checkpoint does interpose a flush await, so "usually early enough" is not early enough. ctx.on('agent/status', fn, { prepend: true }) unshifts the listener (vendor/cordis/src/events.ts:255) and makes the ordering deterministic instead of load-order luck.

2. pause is not inert. When goal/changed reports operation === 'pause' while agent.status === 'running' and the initiator is not the model, the driver cancels the live turn (agent.cancel({ kind: 'user' }, { keepInbox: true }), goal-round-driver/src/index.ts:282-291). So a deferral decision must be taken at the quiescent edge, never from a timer or interval. The same machinery is what makes the other half work: resume fires goal/changed, the driver runs requestDrive, and the loop genuinely restarts rather than leaving a paused goal stranded.

3. The unsettled predicate has to include stopping (JobStatus, packages/jobs/jobs/src/types.ts:17; finishedAt is absent while running/stopping). A job being killed has not settled yet, and treating it as settled would resume into a turn that has nothing to wait for.

On "did this round do anything", you don't need driver internals either. tool/call is a durable session event (packages/core/session/src/types.ts:341), so counting them between two idle edges answers the question from the log — which has the side benefit of making the rule replayable in a test rather than only observable live.

Where that leaves the thread: suggestions 1 and 2 are a policy question, and the policy is mountable today; the remaining core question is whether the driver should own it by default. Both can be true, and the second can be decided on the first one's evidence — which is cheaper than landing it sight-unseen.

Adjacent note, since it is the same loop seen from the other end: I packaged the spend dimension as @argszero/cordis-plugin-goal-budget-guard (npm · source) — it bounds a goal by rounds, unattended rounds, and tokens spent since it began watching, and stops it with one durable ctx.goals.block on that same agent/status edge. This thread is the "it won't stop when there is nothing to do" half; that one is the "it doesn't stop when the spend is absurd" half (#7193). I'll package the two rules above as a sibling plugin and link it here once it is published.

[argszero]

As promised above, the two rules are packaged: @argszero/cordis-plugin-goal-progress-guard — npm: https://www.npmjs.com/package/@argszero/cordis-plugin-goal-progress-guard · source: https://github.com/argszero/cordis-plugin-goal-progress-guard

- insert:
    - id: goal-progress-guard
      name: '@argszero/cordis-plugin-goal-progress-guard'
      config:
        deferWhileJobsPending: true   # default: pause while jobs run, resume when they settle
        maxBarrenRounds: 3            # stop after N consecutive rounds with no tool call
        dryRun: false                 # true logs the deferral or stop it would write

Suggestion #2, as implemented. At every quiescent edge, if the agent still owns an unsettled job (running or stopping), the goal is paused instead of being allowed to take another round; when the last job settles, it is resumed. The rounds in between are exactly the ones the agent would otherwise have spent talking to itself while waiting. I used pause rather than block for the reason in my earlier comment: this is a live loop waiting on work, not a goal that has failed, and the goal stays resumable the whole time.

The jobs service is injected with ctx.inject(['jobs'], …), so the plugin mounts in a composition without it — the deferral dimension is then inert and the rest still works.

Suggestion #1, as implemented. maxBarrenRounds counts consecutive settled rounds in which no tool/call was written to the session, and stops the goal with a durable no-progress reason. No extra model call, which is your Codex comparison taken at face value. The window is the span between two quiescent edges, so a window in which no round was admitted (because a human was driving) does not count toward the streak.

The ordering caveat from my earlier comment is now load-bearing in the code, not just an observation: the plugin registers its agent/status listener with prepend, and there is a test that fails if that is removed. Without it the deferral arrives one round late, every round.

Boundaries, stated up front:

• Nothing interrupts work in flight — both decisions are taken when the agent is quiescent.
• stopping counts as unsettled: a job being killed has not settled.
• If the job count becomes unobservable while a goal is paused by this plugin, the goal is resumed rather than left stranded. A pause that cannot be lifted is worse than one that lifts early.
• A goal someone else moved (a human hit resume, or the round-limit block fired) is forgotten, not fought over.
• The first sight of a goal seeds the window rather than judging it, so rounds that ran before the plugin was mounted are not charged to it.
• Waiting for something that is not a job — an approval, a subagent reporting through another channel — is not covered. Same pause/resume shape, different trigger; it is a natural v2 if there is interest.

Verification. 30 tests: the pure policy functions exhaustively (the streak arithmetic, both gates, the resume decision) plus the guard driven through a real cordis Context against stubs that enforce the real services' rules — the CAS ref must be the revision that was read, pause/block require an active goal, resume refuses an already-armed goal, and the block reason must satisfy the validator copied verbatim from goal/src/index.ts. There is a control arm (without the plugin, an idle agent with a running job is left alone), an ordering test, and 16 mutation checks — all killed.

Where this leaves your report. The suggestion-1/2 policy is deployable today, per-deployment, with no core change; the open core question is whether the driver should own it by default. Both can be true, and the second can now be decided on this one's evidence rather than sight-unseen — which I think is the cheaper order. Your third point (an independent evaluator) stays orthogonal, as you argued.

One note for anyone reading this thread from the spend side: the sibling @argszero/cordis-plugin-goal-budget-guard (npm) bounds a goal by rounds, unattended rounds, and tokens — that is #7193, the "it doesn't stop when the spend is absurd" half of the same loop.

[DDDFXYqiming]

Thanks @argszero — the mapping is clear and I can follow it against the 0.1.6-alpha.2 sources. Two things I take from this:

1. Separating the two primitives matters: pause is the defer path for pending work, block is the terminal path for a goal that is genuinely stuck. My original report conflated them, and your point that the [Bug]？ goal 功能开启后 agent 无法被动等待后台任务：每次进入 idle 即被强制注入 <goal_round>，空转消耗轮次与 token #4664 evidence and 为什么一个 /goal 命令的目标，在完成时需要校验256轮是否完成？ #1831's near-identical rounds are stalls in a live loop rather than verdicts is exactly what I was missing.
2. The listener-ordering requirement (agent/status registered with prepend) is the kind of detail that would make an external implementation look broken for no visible reason. Making it load-bearing with a test rather than leaving it as a comment is the right call.

I confirmed the packaged plugin exists (@argszero/cordis-plugin-goal-progress-guard@0.1.0). I agree with the ordering you propose: deploy the policy per-deployment now, and decide whether the driver should own it by default on this one's evidence rather than sight-unseen.