goal：自治循环缺少三类机械护栏 —— 裁决点停不下来、轮粒度过碎、重试失败无熔断

[Augenblick0v0]

让AI给我写的一个关于goal功能的相关建议

一句话

goal 开启后，循环的实际停机条件只有三个：模型自报 complete/blocked、轮数耗尽（默认 256）、用户人工 pause。中间缺少最基本的机械护栏：需要用户拍板的点停不下来（P1）；每轮干一小步就结束、立刻开新一轮，轮次被仪式性开销吃掉（P2）；同一失败反复重试也没有熔断（P3）。

实测现象（2026-09-25 会话 session-3e72569d-e8ea-407f-a2a0-4027c89acca6，目标 = web-v1.5.4 T01–T07 交付计划）

• 17:59 create goal，18:47–22:03 自动续跑 37 个 goal 轮；goal/change 全程只有 create / pause / resume，从未出现 blocked。21:28 的 pause 是用户人工介入。
• P1 证据：从第 ~8 轮起，连续 18 条轮末总结重复挂着「⚠ 需要你确认的两项（不阻塞）」（远端 PaddleOCR-VL 归档质量决策 → 影响 T07/VPS 8091/成本；重试归档是否保留用户手工归档 → 涉用户数据）。两项始终「不阻塞」，模型继续推进；ask_user_question 全程 0 次调用（发了也停不住循环）。
• P2 证据：36 个完整轮中，中位时长 2.95 分钟、中位 8.5 次工具调用；19/36 轮 ≤3 分钟，11/36 轮 ≤6 次工具调用。第 1–4 轮每轮 15–38 个动作，之后退化为「实现一小步 → 写全套状态总结 → 立即开新一轮」。期间 48 条消息反复重申同一「592 passed / 0 failed」基线、18 条重复罗列同两个待决问题——轮首 round prompt 与轮末总结成为主要 token 开销，轮数 cap 被仪式性进度快速烧掉。
• 唯一硬边界：maxGoalRounds 默认 256；本轮 cap 之外没有任何「无进展/重复失败」检测。

根因与建议

P1「等待用户裁决」在现行 blocked 政策下实际不可达

根因（合约层）：

• dsh-tool-goal 执行层："a blocked call is mechanically rejected until the configured number of consecutive rounds has passed"（blockedAfterConsecutiveRounds 默认 3，硬下限，模型自判同一条件是否持续）。
• system-prompt 契约："Mark blocked only after the same blocking condition persists for at least 3 consecutive goal rounds …; difficulty, uncertainty, or useful remaining work is not blocked."
• 待裁决点天然凑不满「同一阻塞条件持续 3 轮」：只要还有下一个任务、还有可复验的基线，就永远存在 "useful remaining work"，条件永远「不阻塞」。把阈值调到 1 也无效——语义排除仍把「等用户拍板」归为 uncertainty。
• 与 dsh-goal 设计意图自相矛盾：服务层 README 明确 block 阶段为 "provider limits, exhausted budgets, execution errors, and requests for human input" 统一设计，但 tool 层把 "requests for human input" 这一类唯一封死了。
• round driver 只看 idle + armed + 余量，未回答的提问不阻止下一轮入队。

建议：

1. 新增一等受阻代码 awaiting-user-decision（或独立 waiting 阶段）：当前轮内立即生效，不受 3 轮硬下限约束（该阈值只应约束「模型自判环境性受阻」）；生效即 disarm 续跑（复用 blocked 的 disarm 语义）；携带结构化 decision payload（问题/选项/影响面/默认行为），Web/CLI 渲染为显式「等待裁决」卡片，用户作答 = resume 并把答案注入下一轮 prompt。
2. 修订 system-prompt 契约：把「需要用户裁决」从 uncertainty 中显式划出——当决策实质性改变计划、成本或部署面且无法从 objective 推导时，立即以 awaiting-user-decision block，不得绕行；difficulty/uncertainty 排除条款仅适用于模型可自行消化的不确定性。
3. driver 守门：轮内发出 ask_user_question 且未获回答时，不得排队下一轮。

P2 轮粒度过碎：没实现几个功能就停轮开新一轮

根因：round prompt 只点名 objective、round number、cap，并要求以 workspace/工具结果/持久状态为权威——没有任何「持续干到里程碑再结束本轮」的指引。模型把每轮当作小步长 + 汇报单元，轮末自然写出全套状态总结，driver 见 idle 立即入队下一轮。每轮固定支付轮首注入 + 轮末总结两份开销，且按次烧 cap。

建议：

1. round prompt 增加 batching 指引：本轮应持续推进到出现有意义的手 stopping point（里程碑完成、遇到裁决点、环境受阻）才结束；禁止仅为汇报而结束本轮。
2. 轮末总结增量模板：与上轮相比只报 delta（新增完成项/新出现的待决问题），不重复基线与未变化项——直接消灭本会话中 48 条重复基线汇报这类开销。
3. 可选：goal 增加软性的「最小轮粒度」提示（如连续 N 轮无新增完成项时在下一轮 prompt 里提示合并轮）。

P3 缺少「重试几次就受阻」的熔断

根因：现行设计里唯一的机械停机是轮数耗尽（"exhaustion records a blocker"）；模型自报 blocked 又受 3 轮门槛约束且完全依赖自判（dsh-goal Known Limitations："No independent evaluator — the caller that records completion or blocking is authoritative"）。同一命令/同一测试/同一构建错误反复失败重试时，没有任何宿主侧计数器介入，模型可以在失败循环里烧掉大量轮次与 token。

建议：

1. dsh-tool-goal（或 driver）新增配置如 blockAfterRepeatedFailures: N：宿主侧统计同一失败特征（相同命令退出码/相同错误签名/相同失败测试集合）连续出现 N 次后，机械转入 blocked（稳定代码如 repeated-failure），与模型自判解耦。
2. 触发时同样 disarm 续跑、渲染受阻卡片（可附带最近一次失败摘要），等用户介入或显式 resume。
3. 该熔断与 P1 的 awaiting-user-decision、既有 blockedAfterConsecutiveRounds 互补，覆盖三类停机：等输入、环境性受阻、失败循环。

环境

• dsh 0.1.7-rc.2（@deepseek-ai/dsh 全局实装，宿主 --profile web）
• 相关包：@deepseek-ai/dsh-goal、@deepseek-ai/dsh-tool-goal（blockedAfterConsecutiveRounds，默认 3）、@deepseek-ai/dsh-goal-round-driver
• 证据会话：session-3e72569d-e8ea-407f-a2a0-4027c89acca6（宿主会话日志，goal id goal-bdc16a7e-fdb4-404d-a2cc-0e96ccd2dbc1）

[PerryLink]

你列的三类护栏里，至少第三类我此前独立核实过：确实没有

1. 先给你一条已核实的事实（对"重试失败无熔断"）

我在另一条帖子里核实过：在 packages/core/agent-loop/src 与 packages/core/tools/src 上检索 stalled / noProgress / circuitBreaker / loopGuard / repeatGuard / duplicateCall，0 命中。

⇒ 也就是说："无进展熔断"这一类机制在当前代码里不存在。所以你的第三类（重试失败无熔断）不是"配置没开"，而是"没实现"——这条可以直接按"缺失能力"提。

2. 建议把三类拆成三条独立的诉求（它们的可行性差别很大）

1. 裁决点停不下来：这是循环控制（需要"在裁决点可中断/可超时"的明确语义）；
2. 轮粒度过碎：这是批次/粒度策略（可以用"最小轮次"或"合并相邻动作"实现，代价是响应变慢）；
3. 重试失败无熔断：已有事实支持"未实现"，最容易落地——契约清晰（连续 N 次同类失败 ⇒ 停止并向用户报告），且我上面已证实没有现成机制会与它冲突。

建议按 3 → 1 → 2 的顺序写（第三类先落地、也最容易达成共识）。

3. 请补三样让每条可判定

1. 触发场景的最小描述（哪个 goal、多少轮、看到什么）；
2. 你期望的阈值/语义（例如"连续 3 次同类失败"、"单轮最多 N 次工具调用"）；
3. dsh --version。

现在这三条是方向性意见，补上第 2 项之后每条都能变成可验收的要求。

4. 一条相关背景（对你有用）

同类问题还有一条独立报告：工具挂载失败会连坐整个会话创建（#7865），以及单个插件不兼容会让整页不可用（#7835）。⇒ 三条合起来是同一个主题：自治运行时缺少"局部失败不扩散"的边界。建议你在报告里把这层主题点出来——它会让你这三条从"体验建议"变成"自治模式缺一类基础护栏"。

5. 版本提醒

⚠️ 当前最新是 0.1.7-rc.2（tag dsh-v0.1.7-rc.2，npm next 也是它）。别装 latest（npm 上它仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next      # 当前 = 0.1.7-rc.2

一条边界

我确认的是第三类机制（无进展熔断）在代码里不存在——这是你三条里我唯一能给出确定结论的一条。第一、二类我没有逐一核对实现，所以按"待判定"处理。