[Idea] goal 等待子代理时 idle 轮次过密，容易误判卡住并中断正常子代理

[velnori]

现象(工作区 2026-08-14 会话日志实测)
1、idle 轮短间隔触发：等待子代理期间 8 分钟内跑了 27 轮，间隔 7.4-73.6 秒，其中 8-14 秒的密集段大量存在。
2、模型把"轮次数"当成"已等待时长"：一个判官类子代理 12:08:40 派出，12:10:16 被 interrupt（96 秒），12:10:43（123 秒）模型判定"它已经跑了 9 轮……放弃这个判官"并再次 interrupt。该子代理实际 12:22:12 完成，全程 13.5 分钟——正是该类任务的正常速度（P50=14 分钟）。2 分钟内攒出的 9 个空转轮被当成"等了很久"，对还需要约 12 分钟的健康子代理发出了中断并放弃。

根因：goal idle-round driver 数轮不读秒，模型无墙钟感知，轮次数被误当等待时长——轮越密，误判来得越快。

建议：存在运行中子代理时，抑制或节流 goal 的 idle 轮；仅当按任务类别的墙钟预算（普通 ~10 分钟 / 判官类 ~30 分钟，⚠ 建议值）耗尽且无产出时，才触发 idle/blocked 提示，并附证据（agent createdAt / 最后文件 mtime / 产出文件）。

参考先例：esengine/DeepSeek-Reasonix PR #6960（reset idleTurns to prevent premature idle intercept，已合并）：esengine/DeepSeek-Reasonix#6960

[velnori]

补充证据（本地 Node 脚本只读统计会话日志）：

• 子代理耗时基线（36 会话目录，createdAt → 日志最后写入）：普通调研/精读/审计 P50=3.6 分钟（区间 2.6–4.2）；判官/对抗类 P50=14.0 分钟（13.5 / 14.0）

• interrupt 事件时间戳样本（会话日志 tool/call 事件，判官 2e4ffbbb 于 12:08:40 派出）：

12:10:16.839  turn 31  interrupt_agent  2e4ffbbb   （首次，派出后 96 秒）
12:10:43.894  turn 33  interrupt_agent  2e4ffbbb   （二次，派出后 123 秒）
12:22:12      —— 判官日志最后写入，全程 13.5 分钟

• 复现：会话日志（session.jsonl.zstd）中 turn/start 与 tool/call(interrupt_agent) 事件均带时间戳，可直接对账

[weijiafu14]

这份取证的质量很高——尤其是补充评论里那组基线（36 个会话目录、普通类 P50=3.6 分钟 / 判官类 P50=14.0 分钟），它把"模型误判"从一句抱怨变成了一个可以对账的数字。

补一件：你诊断出的根因有一个今天就能补的解，而且它比"抑制 idle 轮"更接近病灶。

根因是"模型没有墙钟"，那就把墙钟给它

你写的：

模型把"轮次数"当成"已等待时长" …… goal idle-round driver 数轮不读秒，模型无墙钟感知，轮次数被误当等待时长——轮越密，误判来得越快。

这句话我认为是准确的，而且它指向一个和"节流 idle 轮"不同的修法：

• 节流 idle 轮治的是"误判来得多快"——轮稀了，撞线晚一点，但同一个错误认知还在（模型仍然在用轮次数估时间）。跑得慢一点的判官照样会被误杀，只是要多熬一会儿。
• 给模型墙钟治的是错误认知本身——它知道"这个子代理派出到现在是 123 秒、基线 P50 是 14 分钟"之后，9 个空转轮就不再意味着什么了。

而这一半今天就能做，不需要改 DSH 核心：system-prompt/assemble 是一个每步都跑的 async waterfall，awaited，返回值权威。也就是说，一个普通插件可以在每一步把真实的墙钟事实注入进这一轮的系统提示，比如：

运行中的子代理：
- 2e4ffbbb（judge 类）派出于 12:08:40，已运行 2 分 03 秒
  最近产出：<最后文件 mtime>

这两条实测过：waterfall 是 awaited 的、返回值权威；assembly.tools 的已有条目也能改写（不只是追加）。注入一段文本比这个还简单。

边界要说清：我验的是这个 waterfall 的机制本身（在真 DSH 组合上跑探针），没有针对 goal 的 idle 轮场景做过端到端验证，也没有测过注入之后模型的判断会不会真的改变——后者是提示词工程，不是机制问题，得你自己试。但至少"把 createdAt 和已运行秒数送到模型眼前"这条路是通的。

所以我建议把提案拆成两句

1. （今天可做，且治本）"存在运行中子代理时，goal 应把每个子代理的 createdAt、已运行墙钟时长、以及产出证据（最后文件 mtime / 产出文件）投影进模型上下文。"
2. （需要官方做，治标但省钱）"存在运行中子代理时，抑制或节流 idle 轮。"

第 1 条不但可以先做，还能给第 2 条提供数据——注入之后再统计一遍误杀率，就知道节流到底还有多少边际收益。

一个对你"按任务类别的墙钟预算"的保留意见

仅当按任务类别的墙钟预算（普通 ~10 分钟 / 判官类 ~30 分钟，⚠ 建议值）耗尽且无产出时，才触发 idle/blocked 提示

你自己已经加了"⚠ 建议值"，我想把这个保留说得更明确一点：按类别写死的预算是一张会过期的名单。 任务类别会增加（你今天有"普通/判官"，明天可能有"跨仓审计""长时构建"），模型和端点的速度也会变——每次变都得有人回来改这个表，而不改的表现是静默的误杀。

而你在同一句里提的另一半恰恰是不会过期的：

并附证据（agent createdAt / 最后文件 mtime / 产出文件）

"有没有产出"是可观测的事实，"该跑多久"是猜的。 建议把重心放在前者——只要子代理还在产出（日志在写、文件 mtime 在动），就不该被判为卡住，无论它属于哪一类、跑了多久。真正需要墙钟兜底的只有"既无产出、又超过某个非常宽松的上限"这一种，那个上限可以定得很粗（比如 1 小时），粗到不需要按类别区分。

这样提还有个好处：它不需要维护者去认可你那两个数字，而那往往是这类提案卡住的地方。

顺带：你引的那个先例很有说服力

esengine/DeepSeek-Reasonix PR #6960（reset idleTurns to prevent premature idle intercept，已合并）——"另一个 harness 已经踩过并合了修复"是很硬的论据，建议在原帖里把它从"参考先例"提到摘要附近，别让它压在最后一行。

边界与利益相关

我们不修 DSH 自家组件——goal 的 idle-round driver、子代理中断链路都在 DSH 里。上面第一节给的是一个机制（插件可用的公开 waterfall），不是对你场景的端到端验证；其余是提案形状建议。

利益相关：我维护 pi2dsh（Pi 生态兼容层）。这条不推销：system-prompt/assemble 是任何插件都能监听的公开 waterfall，不需要经过我们；而你的核心诉求（goal 别乱中断子代理）在 DSH 自己的 goal 实现里，换任何插件都不改变它。