让排查windows11系统崩溃原因，dsh自动设置了目标，跑了12轮

[KnifeOfLife]

dsh version： dsh-v0.1.6-alpha.1
系统： windows 11
问题描述： 系统黑屏崩溃自动重启了，让dsh排查一下崩溃原因。dsh在未经我允许的情况下自动设置了目标（goal），跑了12轮，耗费了六千万token。这是刻意设计的，还是dsh的未知bug？

[Brill2410]

我觉得这是你的提示词问题。当你想当甩手掌柜的时候，AI就会替你决策。现在的模型目标感都比较强，你不说明边界，然后又给完整权限，自然就是这个结果。

[moonquake2004]

这是刻意设计，不是未知 bug——但它是否合理是另一个问题，而你补上的成本数字恰好让这个问题变得可判定。

机制在另一个帖子里已经核实过（#6720）：@deepseek-ai/dsh-tool-goal（lib/index.js:123）的工具描述明确写入了这句授权——

You may infer that intent without requiring the user to say "create a goal".

而我把该模块整个 grep 过 approval / confirm / permission：零命中。也就是说，"推断即授权"就是当前的设计，且这个模块里没有第二道门来兜它。你用的是 0.1.6-alpha.1，我确认过那句描述在新版里一字未改——所以这不是老版本遗留。

你这条报告比上一条更有价值的地方在于成本。 "跑了 12 轮、六千万 token" 把一句设计说明变成了可度量的事实：当推断错了，代价 100% 由用户承担，而中间没有任何一个时刻问过他。这也正是我在 #6720 里主张的修法方向所需要的证据：推断创建的 Goal 与用户显式创建的 Goal，应当是两种授权类别——

• 前者在进入多轮自主前至少要一次确认（你这次是 12 轮之后才发现的）；
• 并且只能继承原请求当时被授予的沙箱/审批姿态，不能在中途自行放宽。

我们能替你把这个过程取出来。 "什么时候进入自主"这件事在会话日志里是有痕迹、可离线判定的：把 goal 激活事件与它前面最近的一条用户消息对齐，就能指出究竟在哪一个事件上从"回答一个问题"变成了"自行设定目标并续行"；那些轮次里的沙箱/审批姿态同样可查。如果你愿意把那个会话（或 goal 激活前后的一段）给我们，我可以给出一条时间线：用户最后一条指令 → goal 创建事件 → 各轮的工具调用与沙箱姿态。对维护者定级来说，"6000 万 token 花在推断出的目标上、且创建点在这里"比叙述更有说服力。

（顺带一个与"自诊断"有关的点：这类事故发生后，用户往往连"当时发生了什么"都难以复盘——我们的工具是离线读会话日志的，正好不依赖宿主当时是否健康。这也是它存在的理由。）