[0.2.0-rc.2] 目标在"创建它的那一轮"结束时被驱动器自行 pause，roundsStarted 恒为 0，自动续行从未真正跑过一轮

[Code0020161314]

更正说明（重要）：本帖初版把 pause 归因于"人类新消息抢占排队轮次"。该因果链已被会话日志时间戳证伪——pause 发生在人类消息之前 11 秒。初版论断已撤回，本文为更正版，归因改为代码级排除法得出的驱动器自身路径。

结论摘要

1. 在 0.2.0-rc.2 的 ACP 交互式宿主中，goal 在"创建它的那一轮"结束时被 pause，roundsStarted 保持 0：整场会话 4 个 goal，没有任何一轮进入过模型历史。凡在回合结束时仍为 active 的 2 个 goal，全部在创建后 5.3 秒 / 8.9 秒内被自发 pause（两次独立复现，见下方时间线）。
2. 触发者经排除法定位为 dsh-goal-round-driver：全仓仅 4 处可调用 ctx.goals.pause，其中 3 处（Web UI 点击 / /goal pause 命令 / 模型工具）在本次观测中均未发生，且 dsh-acp、dsh-acp-app 对 goal 零引用（宿主无此能力）。
3. 第二次自救同样被挡：resume 硬拒（GOAL_TOOL_RESUME_PAUSED）、create 亦拒（GOAL_ALREADY_EXISTS），而两条错误文案都没有指出唯一可行的出路（对 paused goal 执行 complete 后可立即新建，已实测）。

EN / English (short)

In an interactive ACP host on 0.2.0-rc.2, a goal is paused at the end of the very turn that created it, with roundsStarted stuck at 0 — across three goals in one session, not a single round ever entered the model history, so the unattended-continuation feature never actually ran.

Attribution by elimination: only four call sites can reach ctx.goals.pause (dsh-client-ui-goal:590, dsh-command-goal:148, dsh-tool-goal:353, dsh-goal-round-driver:222). The first three did not happen in this observation, and dsh-acp / dsh-acp-app contain zero goal references, so the host cannot have done it. What remains is the driver's own agent/status → idle handler (:219 → :222), which pauses the goal when a lingering reservation from the still-open turn is still present.

Recovery is also blocked twice over: resume is hard-rejected (GOAL_TOOL_RESUME_PAUSED), create is rejected (GOAL_ALREADY_EXISTS), and neither message mentions the one path that works — complete the paused goal, then create a new one (verified live).

时间线（会话日志原始时间戳，毫秒级）

时刻	事件
22:42:28.852	goal/change operation=create（goal-b5f6a3e0-…，maxGoalRounds=3）——发生于模型回合仍在进行时
22:42:33.181	goal/change operation=pause（revision 1→2，roundsStarted 仍为 0）← 回合结束、进入 idle 的瞬间
22:42:44.361	user/message（人类消息）

人类消息晚于 pause 11.2 秒——初版"抢占导致暂停"的说法由此被证伪。

补充观测：在回合保持开启的状态下创建 goal 并每几秒轮询一次，10 秒内始终为 active / armed，未见自发暂停。即暂停需要"回合结束（idle）"这一条件。

第二次复现（独立，可对照）：

时刻	事件
22:55:24.439	goal/change create（另一 goal，maxGoalRounds=3）
22:55:33.358	goal/change pause（+8.9 秒，回合结束时）
23:00:01.692	下一条人类消息（+4 分 28 秒）

两次复现的间隔分别为 5.3 秒与 8.9 秒，均紧贴回合结束；两次的人类消息都在暂停之后才到达。第二次复现中，人类刻意保持沉默 4 分 28 秒，期间没有任何自动续行发生，roundsStarted 仍为 0——这是一个干净的空对照组。

状态快照（实测原始返回）

创建时：

{ "goal": { "id": "goal-b5f6a3e0-…", "revision": 1, "phase": "active", "roundsStarted": 0, "maxGoalRounds": 3 }, "activation": "armed" }

回合结束后：

{ "goal": { "id": "goal-b5f6a3e0-…", "revision": 2, "phase": "paused", "roundsStarted": 0, "maxGoalRounds": 3 }, "activation": "disarmed" }

两次自救尝试：

update_goal(action=resume, revision=2)
→ Error: the model cannot resume a paused goal; the user must resume it

create_goal(objective=…, max_goal_rounds=3)
→ Error: goal "goal-b5f6a3e0-…" already exists with phase "paused"

代码级归因

四个 ctx.goals.pause 调用点：

文件:行	触发者	本次观测
dsh-client-ui-goal/lib/client.js:590	Web 目标面板点击	未发生
dsh-command-goal/lib/index.js:148	人类 /goal pause	未发生
dsh-tool-goal/lib/index.js:353	模型 update_goal(action="pause")	未发生（本次会话模型调用仅 create / complete / resume）
dsh-goal-round-driver/lib/index.js:222	驱动器在 agent/status → idle 时	✅ 唯一剩余

宿主能力排除：dsh-acp、dsh-acp-app 对 goal 零引用；goals.pause 虽以 @Remote("pause") 暴露（dsh-goal/lib/index.js:498/676），但没有任何宿主侧代码调用它。

驱动器侧的相关代码：

文件:行	内容
goal-round-driver/lib/index.js:213-230	agent/status → idle 处理器
:219	条件：attempt.phase === "queued" || "claimed" || attempt.cancelled，且 goal active + armed → 注意 queued 本身即可触发
:222	ctx.goals.pause(agent, goalRef(goal))
:237-244	agent/inbox/inserted：竞争消息到达 → competingQueued=true；queued 的 attempt 标记 stale=true
:249-252	agent/inbox/discarded → attempt.cancelled = true
:259	只有 admitted 才计入 Round → 解释 roundsStarted 为何恒为 0

推断链（agent 级事件不落盘，此段为推断，非直接观测）：goal 在回合仍开启时创建 → 驱动器在某个时刻预排了一轮（attempt.phase = "queued"）→ 该轮因回合未结束而被 agent/pre-step 校验判为陈旧并拒绝（README：「因陈旧而被拒绝的预留不会消耗 Round 编号」）→ 但 attempt 未被清除 → 回合结束进入 idle → :219 命中该残留 → :222 暂停并解除武装。

即：驱动器把它自己刚刚尝试推进的目标掐死了，且不消耗任何 Round——外部只能看到"goal 从未运行却被暂停"。

与已有讨论的关系（已逐条比对）

讨论	关系
#6067 孤儿 goal/complete → 会话永久无响应、无自愈	同族（goal 状态机缺乏容错与自愈），但触发不同：该帖为 create 丢写；本条为驱动器残留预留
#9607 / #7198 / #4664 / #4715 idle 被反复唤醒、空转、烧 token	症状相反：那些是"轮次太多"，本条是"一轮都没跑，目标被静默冻结"
#8102 early disarm 补丁（失败回合在关闭前就解除武装）	同族（armed 状态时序），触发是"失败回合"；若该补丁覆盖本条路径请指出，我更新
#8331 goal 工具中途从目录消失	不同

建议

1. 不要因"自身陈旧预留"而 pause。 :219 把 queued（含仅被标记 stale）与 cancelled 同等对待。建议：陈旧/被拒的自身预留应清理 state.attempt 并重新排队，只有外部显式取消才进入 pause。
2. pause 事件需要来源字段。 目前 goal/change 只记录 operation，无 source / cause，因此无法直接回答"谁暂停的"，只能靠排除法（本报告即如此完成）。建议记录触发者与原因码。
3. 让错误文案指向出路。 GOAL_ALREADY_EXISTS 与 GOAL_TOOL_RESUME_PAUSED 都应说明可达的下一步：对 paused goal 执行 complete 后可立即新建（已实测有效）。
4. 暴露 attempt 状态。 roundsStarted: 0 无法区分"未触发 / 已预留被拒 / 被取消"；建议在 goal 视图或日志中暴露最近一次 attempt 的 phase 与拒绝原因。

影响

在交互式宿主中，"创建 goal 后正常结束回合"是最常见的使用方式。若此时目标必然被暂停且不消耗任何 Round，则该特性完全无法产生自动续行——用户与模型都只会看到"目标莫名 paused、模型又被两条错误挡住"，外在表现即"agent 停手、必须由人推动"。

验证方式与署名

• 时间线取自会话持久化日志（sessions/**/session.v4.jsonl）的原始 goal/change 与 user/message 事件时间戳；状态快照与错误文案为工具实测原始返回。
• 归因采用代码级排除法；推断部分已明确标注为推断。
• 现象与验证由使用者实测完成；根因定位与本文起草由 AI 辅助。若有论断读起来不对，请指出，我会回到工具链重新核验并更正——本帖初版即因自查时间戳而被撤回重写。

[Code0020161314]

附：两份补丁（可直接应用 / 移植）

补丁针对发布产物 @deepseek-ai/dsh@0.2.0-rc.2 的 lib/index.js 生成；由于拿不到仓库检出，未运行上游测试套件，语义等价的改动请移植到 src/*.ts。

补丁 1（行为）：回合结束不再因「抢占」而自行 pause

目标文件：dsh-goal-round-driver/lib/index.js
基线：14192 B ・ SHA256 BBA57A0BE174C64D1B70A4254BD59BDC5C0696CAFE1C7DBA5F5CC58100726D5B

--- a/dsh-goal-round-driver/lib/index.js
+++ b/dsh-goal-round-driver/lib/index.js
@@ -216,7 +216,7 @@ function apply(ctx) {
 				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) {
+				if (attempt !== void 0 && attempt.cancelled === true && attempt.preempted !== true && goal !== void 0 && goal.phase === "active" && goal.activation === "armed" && attempt.goalId === goal.id && attempt.revision === goal.revision) {
 					state.attempt = void 0;
 					try {
 						ctx.goals.pause(agent, goalRef(goal));
@@ -240,7 +240,7 @@ function apply(ctx) {
 			const attempt = state.attempt;
 			if (attempt !== void 0 && sameQueued(message.content, message.source, attempt)) return;
 			state.competingQueued = true;
-			if (attempt?.phase === "queued") attempt.stale = true;
+			if (attempt?.phase === "queued") { attempt.stale = true; attempt.preempted = true; }
 		});
 		ctx.on("agent/inbox/claimed", ({ agent, message }) => {
 			const attempt = stateFor(agent).attempt;

语义：原条件把「驱动器自身的陈旧预留」（queued / stale）与「用户显式取消」一视同仁，于是人类消息抢占被当成取消。改后只有「排队轮次确实被取消、且不是被人类新消息挤掉」才 pause：

• 人类插话 → 只让行（defer），不再冻结目标；
• 用户显式中断 / /goal pause → 行为不变。

补丁 2（文案）：两条「死路」错误信息指向可达出路

目标文件：dsh-tool-goal/lib/index.js、dsh-goal/lib/index.js。纯字符串改动，零行为变更。

--- a/dsh-goal/lib/index.js
+++ b/dsh-goal/lib/index.js
@@ -636,7 +636,7 @@ let GoalService = (() => {
-			if (current !== void 0 && current.phase !== "complete") throw new GoalError(`goal "${current.id}" already exists with phase "${current.phase}"`, "GOAL_ALREADY_EXISTS");
+			if (current !== void 0 && current.phase !== "complete") throw new GoalError(`goal "${current.id}" already exists with phase "${current.phase}"; a paused goal can be completed via update_goal(action="complete"), after which create_goal succeeds`, "GOAL_ALREADY_EXISTS");
--- a/dsh-tool-goal/lib/index.js
+++ b/dsh-tool-goal/lib/index.js
@@ -349,7 +349,7 @@ function apply(ctx, config) {
-				if (args.action === "resume" && current?.id === ref.id && current.revision === ref.revision && current.phase === "paused") throw new HarnessError("the model cannot resume a paused goal; the user must resume it", "GOAL_TOOL_RESUME_PAUSED");
+				if (args.action === "resume" && current?.id === ref.id && current.revision === ref.revision && current.phase === "paused") throw new HarnessError("the model cannot resume a paused goal; the user must resume it (recoverable path: complete the paused goal, then create a new one)", "GOAL_TOOL_RESUME_PAUSED");

动机：paused 之后，模型侧 resume 与 create 双双被拒，而两条错误文案都不指出唯一可行出路（先 complete、再新建），模型因此困在"这也行不通、那也不行"的循环里。该出路已在本机实测可行。

验证与局限

项	结果
git apply --check（两份补丁）	exit=0
git apply → 还原 → 再应用（往返）	通过
上游测试套件	未运行（本机无仓库检出）
是否已应用到报告者本机	否，安装目录未被改动

有意未包含（建议分开处理）

1. 放宽生命周期：允许模型 resume paused goal，或允许 paused 时新建 —— 涉及「谁有权解冻／单目标约束是否放宽」，属维护者设计决策。
2. 可观测性：goal/change 事件缺少 source / cause 字段，导致「谁暂停了目标」只能靠 4 个 ctx.goals.pause 调用点做排除法归因（本报告即如此完成）。

[argszero]

Your elimination is right, and here is the code path it lands on, with the one condition you could not observe from the logs.

packages/goal/goal-round-driver/src/index.ts:258-282 (the :222 you quote is the built bundle):

ctx.on('agent/status', ({ agent, status }) => {
  const state = stateFor(agent)
  if (status === 'idle') {
    state.competingQueued = false
    const attempt = state.attempt
    const goal = currentGoal(state)
    const pause = attempt !== undefined
      && (attempt.phase === 'queued' || attempt.phase === 'claimed' || attempt.cancelled)
      && goal !== undefined && goal.phase === 'active' && goal.activation === 'armed'
      && attempt.goalId === goal.id && attempt.revision === goal.revision
    if (pause || attempt?.phase === 'queued') {
      state.attempt = undefined
      if (attempt.phase === 'queued') agent.inbox.remove(attempt.messageId)
      if (pause) ctx.goals.pause(agent, goalRef(goal))
    }
    requestDrive(state)
  }
})

Two consequences for your reproduction:

• This branch can only pause a goal for which the driver had already reserved a round. The reservation is created in drive() (:180), and drive() only proceeds at quiescence — readyToDrive (:103) requires agent.status === 'idle'. That is why your poll while the turn stayed open saw active/armed throughout: nothing is reserved until the agent goes idle. Your two events are therefore a sequence, not a single moment: turn ends → driver reserves round 1 → the agent reaches idle again with that reservation still queued → the reservation is withdrawn (agent.inbox.remove) and the goal is paused.
• roundsStarted stays 0 because it counts started rounds, not reservations. So "no round ever entered the model history" is exactly consistent with "one round was reserved and then withdrawn before it could start".

That narrows the question: what should have started a turn when the reserved round message was queued at quiescence, and did not? The decisive measurement is the round message's own lifecycle rather than goal state — look for the inbox event carrying a message with source.kind === 'goal' && source.round === 1 at the pause instant (and any agent/inbox/spliced around it), and for whether agent.status flips to running afterwards. If the insertion happens and no turn starts, then the driver's withdraw-then-pause is the symptom of a dropped wake, and the branch comment says as much: "A reservation still queued when the agent reaches idle cannot run: withdraw it so human input queued behind it is not stranded."

One addition to your recovery findings: resume is model-denied (GOAL_TOOL_RESUME_PAUSED), but the service method is not — ctx.goals.resume(agent, ref) accepts paused (packages/goal/goal/src/index.ts:363-381, exposed as @Remote('resume')). So a host, or a plugin listening on goal/changed, can rescue a goal paused on this branch, and it will not be immediately re-paused by the same dropped attempt: the fence compares attempt.revision === goal.revision, and a resume bumps the revision. Whether auto-resuming is the behaviour upstream wants is their call — I am only pointing out that the seam exists and that the fence was written so that a resume survives it.

[Code0020161314]

补充实测：唤醒其实成功了，但回合在 8 毫秒后被 aborted/user 杀掉 —— 并撤回补丁 1 的前提

感谢 @argszero 的定位，你的判断成立：该 pause 分支只可能暂停「驱动器已预留过一轮」的目标。按你指出的测量口径（round 消息自身的生命周期 + agent.status 翻转），我在本机会话日志里找到了完整链条——而且比"预留无人认领"更下游一步。

决定性证据（毫秒级，两次复现完全同构）

turn/end          {kind:"completed"}                        ← 回合正常结束
inbox/spliced     +<goal_round> "Round: 1/3"                ← 驱动器插入 round 消息（source.kind=goal, round=1）
turn/start        {turn:5}                                  ← 唤醒**成功**：回合确实开始了
inbox/spliced     {removedCount:1, inserted:[]}              ← +1 ms：round 消息被移出 inbox
turn/end          {turn:5, reason:{kind:"aborted", reason:{kind:"user"}}}   ← +8 ms：回合被判为**用户中断**
goal/change       {operation:"pause", roundsStarted:0}       ← +1 ms：目标被暂停

原始事件（两次复现的时间戳）：

• 1791902554171 spliced(+goal_round) → …172 turn/start(turn 5) → …173 spliced(removedCount:1) → …180 turn/end(aborted/user) → …181 goal/change(pause)
• 1791903333348 spliced(+goal_round) → …349 turn/start(turn 12) → …350 spliced(removedCount:1) → …357 turn/end(aborted/user) → …358 goal/change(pause)

因此问题不在"预留无人认领"，而在中断竞态

• 唤醒回合启动了（turn/start 距插入仅 1 ms），且在 8 ms 的生命周期内没有任何 step/start、没有工具调用——它不是"跑了一轮没跑成"，而是刚起就被中止。
• 终止原因被运行时归因为 aborted / reason.kind = "user"。可该 8 ms 窗口内不存在任何人类输入：相邻的真实用户消息分别在 10 秒后与更晚才到达。所以这不是"用户中断了它"，而是某一方以"用户中断"的路径取消了它——最可能是客户端在上一回合收尾时发出的 cancel，正好命中 1 ms 前刚启动的驱动器回合。
• 之后 :219 的 idle 分支看到预留仍是 queued，按既有注释（"A reservation still queued when the agent reaches idle cannot run: withdraw it so human input queued behind it is not stranded."）撤回并暂停——那是症状处理，不是病根。

撤回补丁 1

我先前贴的补丁 1 假定触发条件是"人类消息抢占"，据此把 pause 条件收窄为 attempt.cancelled === true && attempt.preempted !== true。该前提与本机实测不符，撤回，请勿应用：在观测到的情形里 attempt.phase === 'queued'（既未 cancelled 也未 preempted）；补丁虽能阻止 pause，但 round 消息仍会被那次"用户中断"移除，结果是目标保持 active 却反复预留—被中断，从"可见的暂停"退化成"静默空转"。补丁 2（两处错误文案指向 complete → 新建）与本竞态无关，仍然有效。

你指出的自救缝我确认可用（并打算据此做用户态兜底）

ctx.goals.resume(agent, ref) 服务方法接受 paused，且 resume 会 bump revision，从而越过 attempt.revision === goal.revision 的栅栏——因此宿主或插件可在 goal/change 上救回被该分支暂停的目标。我准备用插件实现这一层，并在验证后回报结果。若上游认为"自动 resume"并非期望语义，请直接说，我就不做。

需要宿主侧信息才能定论的一点

我只能观测到 turn/end.reason = aborted/user 与时间相关性；这个 cancel 是否真的由 ACP 宿主在回合收尾时发出，需要宿主侧日志。若上游能确认该 cancel 的来源，修复点就有两个候选：①宿主收尾 cancel 不应波及新启动的驱动器回合；②驱动器应区分"预留被中断"与"预留无人认领"，前者重试而非撤回+暂停。