agent 在长任务中回复陷入循环、大量重复，且无轮次预算/重复检测兜底

[Colinchiu007]

一句话说明问题：DSH 的 agent 在长任务（尤其涉及后台 job 轮询、等待外部进程）中会陷入回复内容循环、大量重复，且没有任何机制兜底。

复现步骤

1. 发起一个需要长时间等待外部进程的任务（如 electron-builder 打包、后台下载 144MB electron 二进制、轮询 job 状态）。
2. 让 agent 在后台 job 未完成时持续检查状态。
3. 观察 agent 反复执行「检查 win-unpacked 是否填充 → 读取 job 输出 → 等待 → 再检查」的循环，每步文本内容高度重复。
4. 实测会话 session-87f7ba51 中 turn 4 单轮跑了 72 步，其中约 30+ 步是重复轮询打包状态；turn 5~14 每轮开头模型自己承认「我陷入循环了 / 我又重复了」，随后仍继续重复。

实际结果

• 单个 turn 无步骤上限，可无限延续（实测单轮 72 步）。
• 回复文本大量重复，模型反复自我纠正但无法跳出循环。
• 至少两个会话（session-87f7ba51、session-389ea38a）出现该问题。

预期结果

• 存在轮次/步骤预算，超限强制结束轮次。
• 存在「回复内容重复」检测，连续高相似度回复时注入提醒或终止。
• 存在「无进展」检测，连续 N 步无实质进展时提醒模型换方案或收尾。

环境

• DSH 版本：@deepseek-ai/dsh 0.1.1-rc.2（web profile，standard preset）
• 模型：deepseek-v4-flash-0731-oc（provider tianyi-dp4f，reasoningEffort: max）
• 平台：Windows，Node v22.22.3

根因分析（已排查）

1. 无「回复内容重复」检测：唯一的循环防护是 repeat-tool-reminder 插件（已启用，阈值 [3,5,8]），但其检测键是「(tool name, 完全相同的规范化参数)」，只拦截完全相同的工具调用。实际循环是「文本回复重复 + 参数略有不同的工具调用」（轮询时检查不同目录/进程/文件），该插件完全检测不到，一次提醒都没触发。
2. 无「轮次/步骤预算」：dsh-agent-loop README 明确「没有内置轮次预算：工具调用或 steering 会让当前轮次继续；限制失控轮次的策略必须从扩展点（如 agent/turn-stopping）执行取消」。因此单轮可无限跑下去，没有硬性兜底。
3. 采样参数缺少重复惩罚：DSH 的 GenerateOptions 采样只有 temperature/maxTokens/stop，没有 repetition_penalty/frequency_penalty/presence_penalty（README 记录为「已删除的惰性旋钮」）。模型在长任务中容易退化到重复输出，且无惩罚项抑制。

建议修复方向

• P0：给 dsh-agent-loop 增加轮次/步骤预算（单轮最大步骤数，超限强制结束轮次）。
• P1：增强 repeat-tool-reminder：检测语义相似的工具调用（如轮询类命令），或对「连续 N 步无进展」注入提醒。
• P1：增加回复文本重复检测（连续多条 assistant 文本高相似度时注入提醒）。
• P2：在 GenerateOptions 恢复 repetition_penalty 支持。

[liyangbing]

这个复现把“模型重复输出”和“Agent turn 没有硬边界”区分得很清楚。建议修复按四层落地，并分别记账：

1. 硬预算：为每个 turn 设置 steps、wall-clock、provider token/cost 和 tool-output 上限；达到上限时写入可恢复的终止原因，不能只依赖模型自我收尾。
2. 无进展信号：对轮询类工具按资源/状态摘要建立进展指纹，区分“同一状态重复”“状态改变但没有任务进展”和“外部 job 已完成”；文本相似度只能作为提醒信号，不能单独决定删除历史。
3. 外部 job 状态：让 Agent 等待时保留 job ID、上次观察时间、状态变化和下一次允许检查时间；没有状态变化时采用退避或要求换方案，不要每一步都重新读取相同目录。
4. 取消与恢复：预算耗尽、用户停止、provider 失败和进程退出都要分别写入 Session/工具生命周期；清理孤儿进程或临时目录后，再提供“新 turn/新 Session 继续”的明确入口。

验收建议覆盖：有限状态轮询、相似但不同参数的工具调用、状态最终变化、永久 pending、外部进程崩溃、取消期间结果到达、断线重连和跨冷启动恢复。报告 turn/step 数、重复指纹命中、等待时间、provider usage、终止原因和清理结果；不要把“模型说我陷入循环”当作检测证据。

如果采用扩展点实现，必须证明取消在达到预算时真的阻止下一次 tool call，并且不会留下半写 Session 或悬空 approval。独立社区手册的 runaway-loop 与有界失败接续参考：https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/runaway-agent-loop.md 和 https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/agent-patterns/ralph-bounded-failure-successor.md 。手册不是 DeepSeek AI 官方项目。

[Colinchiu007]

补充分析：这是「模型退化」还是「框架兜底缺失」？

进一步排查后，结论是两者叠加，但根子在框架。用会话日志的硬数据说明：

一、模型确实在退化（第三方 LLM 行为）

以 session-87f7ba51 turn 4 的 step 40-72 为例，模型对同一个后台 job 反复轮询：

step=41 job_output(pwsh-9) → step=43 job_output(pwsh-9) → step=45 job_output(pwsh-9)
→ step=47 job_output(pwsh-9) → step=50 job_output(pwsh-9) → step=52 job_kill(pwsh-9)
→ step=59 job_output(pwsh-10) → step=61 job_output(pwsh-10) → step=63 job_output(pwsh-10)
→ step=65 job_output(pwsh-10) → step=67 job_output(pwsh-10) → step=69 job_output(pwsh-10)
→ step=71 job_output(pwsh-10)

job_output(pwsh-9) 连续调用了 5 次，job_output(pwsh-10) 连续调用了 6 次。模型在「等待外部进程完成」的场景下退化到重复轮询，且模型自己在 turn 5~14 反复承认「我陷入循环了 / 我又重复了」。这是所有 LLM 在无进展等待场景的常见弱点，并非某个模型独有的 bug。

二、为什么 repeat-tool-reminder 没拦住？（框架检测盲区）

这是关键。看工具参数：

• job_output(pwsh-9) 每次参数都不同：timeout_ms 从 240000 → 120000 → 180000 → 120000 变化
• pwsh 命令每次检查不同的路径 / 进程

repeat-tool-reminder 的检测键是「(tool name, 完全相同的 canonical arguments)」。参数一变就不算重复，计数器永远到不了阈值 [3,5,8]，所以一次提醒都没触发。轮询循环恰好绕过了这个检测——这是框架的盲区，不是模型问题。

三、框架层面的三个缺失（根子）

缺失	说明
无轮次/步骤预算	单轮可无限跑（实测 72 步），无硬性上限
重复检测只看「完全相同」参数	参数微变即漏检，轮询循环完全绕过
采样无 repetition penalty	GenerateOptions 只有 temperature / maxTokens / stop，无惩罚项抑制退化

四、客观判断

• 模型层面：deepseek-v4-flash-0731-oc 在长任务（尤其等待外部进程）中确实会退化到重复轮询，这是诱因。
• 框架层面（根子）：DSH 明知模型可能循环，却只做了「完全相同调用」检测，且明确不做轮次预算（README 原文「没有内置轮次预算：限制失控轮次的策略必须从扩展点执行取消」）。这是设计取舍，但代价是这种循环无人兜底。

结论： 不能简单归咎于「第三方 LLM 的问题」。模型退化是诱因，但框架没有兜底机制才是让循环无限延续、让用户看到大量重复的根本原因。这也正是建议增加「轮次预算 + 语义相似重复检测 + 无进展检测」的原因——这些是框架该做的防御，不能指望模型永远不退化。

[Colinchiu007]

感谢 @liyangbing 的四层落地建议，非常专业且与实测吻合。补充几点我们排查中与四层方案直接对应的观察：

1. 硬预算 —— 实测确认无任何上限

ReactLoopAgent.turn() 循环确实没有 maxSteps/maxTurns/spend 上限。实测单轮跑了 72 步（turn 4），且 maxParallelToolCalls（默认 10）只约束单步并发，不约束步数。maxTokens 只约束单次请求输出，不约束累计。这与手册 runaway-agent-loop 的结论一致。

2. 无进展信号 —— 指纹比文本相似度更可靠

实测中 job_output(pwsh-9) 连续 5 次、pwsh-10 连续 6 次，但每次 timeout_ms 都不同，所以 repeat-tool-reminder（键 = 完全相同 canonical args）完全漏检。您提出的「按资源/状态摘要建立进展指纹」正是解法：对轮询类工具，指纹应该基于「job ID + 状态字段」，而非完整参数。文本相似度确实只该做提醒，不该单独决定删除历史。

3. 外部 job 状态 —— 退避是刚需

实测模型每一步都 job_output 重新读取，没有退避。若框架能保留「上次观察时间 + 状态变化 + 下次允许检查时间」，并在无变化时退避或要求换方案，能直接消除这类循环。

4. 取消与恢复 —— 需要可恢复的终止原因

您强调「达到上限时写入可恢复的终止原因，不能只依赖模型自我收尾」，这点很关键——实测模型自己反复说「我陷入循环了」但无法跳出，说明模型自我收尾不可靠，必须由框架写入终止原因。

关于验收

您列的「不要把『模型说我陷入循环』当作检测证据」非常正确。实测中模型 turn 5~14 每轮都承认循环，但依然继续——模型的自我声明不是可靠信号，必须用指纹命中/预算耗尽等客观信号。

手册链接

两个链接我都验证过（HTTP 200，内容真实）：

• runaway-agent-loop.md 明确确认 ReactLoopAgent.turn() 无 maxSteps/maxTurns/spend 上限，并给出 30 秒紧急停止流程。
• ralph-bounded-failure-successor.md 讨论 Ralph 的有界失败接续，强调区分 budget-limited 与 round-failed——这与您第 4 层「可恢复终止原因」的语义一致。

感谢提供参考，这些手册对落地实现很有价值。

[Colinchiu007]

实现提案：为 Agent turn 增加硬边界与无进展检测（四层落地）

基于 @liyangbing 的四层建议，结合对 dsh-agent-loop、dsh-repeat-tool-reminder、dsh-tools 源码的核对，整理为可落地的实现提案。所有扩展点名称与签名均来自当前 0.1.1-rc.2 实际代码。

第 1 层：硬预算（Hard Budget）

目标

为每个 turn 设置 steps / wall-clock / provider token/cost / tool-output 上限，达到上限时写入可恢复的终止原因，不依赖模型自我收尾。

现状（已核对）

ReactLoopAgent.turn()（dsh-agent-loop/lib/index.js L516-604）的 while(true) 循环只检查 signal.aborted，没有 maxSteps / maxTurns / spend 上限。phase.step 递增但无上限检查。agent/turn-stopping 是 serial 事件（L565），仅在 turnEnds && inbox.nextStep.length === 0 时触发——即只有模型自己结束 turn 才会触发，无法作为预算耗尽时的兜底。

扩展点

• 新增 agent/turn-budget waterfall（或复用 agent/pre-step 的决策返回）：在每个 step 开始前（preStep L492 处）检查预算。
• 预算状态存于 ReactLoopAgent 实例（phase 对象扩展字段：budget: { steps, wallClockMs, tokens, toolOutputBytes }）。

实现要点

1. 在 preStep()（L492-514）内、agent/pre-step waterfall 之后，检查预算。若超限，返回 {kind: "reject"} 并写入终止原因。
2. 终止原因写入 turn/end 事件的 reason 字段（当前支持 completed / blocked / aborted / error / max-tokens，需新增 budget-exhausted）。
3. 预算字段通过 agent/request waterfall 的 proposedConfig 或独立配置注入，避免硬编码。
4. 关键：预算检查必须在 step() 的 while(true) 内、buildRequest（L693）之前执行，确保达到预算时真的阻止下一次 tool call，而不是等模型自己停。

验收用例

• 单轮 steps 上限 = 5，模型连续调用工具 6 次 → 第 6 次被阻止，turn/end.reason = budget-exhausted，无第 6 次 tool call 发出。
• wall-clock 上限 = 10s，模型在 10s 后仍在调用 → 被阻止。
• token/cost 上限 = 100K，模型累计超限 → 被阻止。
• 达到预算后，agent/turn-stopping 仍被触发，且 inbox.nextStep 清空，无半写 Session。

第 2 层：无进展信号（Progress Fingerprint）

目标

对轮询类工具按「资源/状态摘要」建立进展指纹，区分三种状态：

1. 同一状态重复（无进展）
2. 状态改变但没有任务进展
3. 外部 job 已完成（有进展）

文本相似度只能作为提醒信号，不能单独决定删除历史。

现状（已核对）

dsh-repeat-tool-reminder（lib/index.js L163-314）用 canonicalize()（L218）对参数深度排序后 JSON.stringify，检测键是 [exec.name, canonical]（L283）。参数微变即漏检——实测 job_output(pwsh-9) 的 timeout_ms 每次不同，计数器永远到不了阈值 [3,5,8]。

扩展点

• 复用 tools/post-execute waterfall（签名 (exec, result, next)，返回 {kind: 'accept'|'block', additionalContexts}）。
• 新增 progress-fingerprint 插件，或扩展 repeat-tool-reminder。

实现要点

1. 为轮询类工具（job_output / job_status / pipeline:status 等）定义指纹提取器：从 exec.arguments + result 提取「资源 ID + 状态字段」，而非完整参数。
   • 例：job_output 的指纹 = job_id + result.status。
2. 用 WeakMap<Agent, Map<fingerprint, {count, lastSeen}>> 维护每 agent 的进展指纹链（与现有 chains WeakMap 同模式）。
3. 区分三种状态：
   • 指纹相同 → count++（同一状态重复）
   • 指纹不同但任务未完成 → 重置计数但标记「状态改变无进展」
   • 指纹显示完成 → 重置计数（有进展）
4. 达到阈值时，通过 additionalContexts 注入提醒（复用现有 prependContext 机制），绝不替换 content。
5. 文本相似度检测作为独立提醒信号，但不得单独触发删除历史（删除历史需人工或更高阈值确认）。

验收用例

• job_output(pwsh-9) 连续 5 次但 timeout_ms 不同 → 指纹相同（job_id + status 相同），第 3 次触发提醒。
• job_output 状态从 running → completed → 指纹变化，计数重置，不误报。
• 相似但不同参数的 pwsh 命令（检查不同目录）→ 指纹不同，但文本相似度检测可作提醒。
• 文本相似度提醒不删除历史，只注入 additionalContexts。

第 3 层：外部 Job 状态跟踪（Job State Awareness）

目标

让 Agent 等待时保留 job ID、上次观察时间、状态变化、下一次允许检查时间；无状态变化时采用退避或要求换方案，不每一步都重新读取相同目录。

现状（已核对）

实测模型每步都 job_output 重新读取，无退避。dsh-tool-jobs 的 job_output 每次调用都重新读取 job 状态，没有「上次观察时间 / 退避」概念。

扩展点

• 在 dsh-tool-jobs 的 job_output 工具实现中增加退避逻辑。
• 或新增 agent/pre-step 监听器，检测连续轮询同一 job。

实现要点

1. job_output 维护 Map<jobId, {lastObservedAt, lastStatus, nextAllowedCheckAt}>。
2. 若 now < nextAllowedCheckAt 且状态未变化 → 返回「退避中，请等待」或注入提醒要求换方案。
3. 退避策略：指数退避（如 1s → 2s → 4s → 8s，上限 60s），或基于 job 类型配置。
4. 状态变化时重置退避计时器。
5. 提供「等待完成」的语义化工具（如 job_wait(jobId, timeoutMs)）替代「反复 job_output 轮询」，让模型一次调用即可等待到完成或超时。

验收用例

• 同一 job 连续 job_output 3 次无状态变化 → 第 3 次返回退避提示。
• job 状态变化 → 退避重置，允许立即检查。
• job_wait 在 job 完成时立即返回，超时返回 timeout 状态。
• 永久 pending 的 job → 退避到上限后要求换方案或结束。

第 4 层：取消与恢复（Cancellation & Recovery）

目标

预算耗尽、用户停止、provider 失败、进程退出分别写入 Session/工具生命周期；清理孤儿进程或临时目录后，提供「新 turn / 新 Session 继续」的明确入口。

现状（已核对）

turn() 的 catch 块（L574-589）区分 signal.aborted（aborted）与普通错误（error），turn/end 写入 reason。但没有「预算耗尽」的独立 reason，也没有「清理孤儿进程」的钩子。

扩展点

• turn/end 的 reason 扩展 budget-exhausted。
• 新增 agent/turn-end serial 事件（或复用 agent/turn-stopping）作为清理钩子。
• dsh-tool-jobs 提供 job_cleanup 工具清理孤儿进程/临时目录。

实现要点

1. turn/end.reason 增加 budget-exhausted、user-stopped、provider-failed、process-exit 等枚举，分别记录。
2. 新增 agent/turn-end 事件，在 turn/end 写入后触发，供插件清理孤儿进程/临时目录。
3. 提供「继续」入口：resumeSessionId 已存在（dsh-agent-loop 支持），预算耗尽后可通过 ctx.agents.resume() 恢复，但需确保不重放已耗尽的步骤。
4. 清理孤儿进程：job_cleanup 工具 + agent/turn-end 钩子，避免预算耗尽后残留后台进程。
5. 取消语义：达到预算时的取消必须真正阻止下一次 tool call（见第 1 层），且不留下半写 Session 或悬空 approval。

验收用例

• 预算耗尽 → turn/end.reason = budget-exhausted，孤儿进程被 agent/turn-end 钩子清理。
• 用户停止 → reason = user-stopped，inbox 清空。
• provider 失败 → reason = provider-failed，retryPolicy 生效。
• 进程退出 → reason = process-exit，重启后可通过 resumeSessionId 恢复，不重放已耗尽的步骤。
• 取消期间结果到达 → 正确写入，不丢失。

验收总纲

覆盖场景：

• 有限状态轮询（job 从 pending → running → completed）
• 相似但不同参数的工具调用（timeout_ms 变化）
• 状态最终变化（job 完成）
• 永久 pending（job 永不完成）
• 外部进程崩溃
• 取消期间结果到达
• 断线重连
• 跨冷启动恢复（resumeSessionId）

报告指标：

• turn/step 数
• 重复指纹命中次数
• 等待时间
• provider usage（token/cost）
• 终止原因（turn/end.reason）
• 清理结果（孤儿进程/临时目录）

关键原则：不要把「模型说我陷入循环」当作检测证据——必须用指纹命中、预算耗尽等客观信号。

[argszero]

源码核对（0.1.2-alpha.1，cd5ef81481；帖内引用的是 rc.2 编译产物 lib/index.js 行号，以下为当前源码行号）：@Colinchiu007 的三项缺口判断全部成立，另有两处线程中没有的补充。

确认项：

• turn() 的 while(true)（packages/core/agent-loop/src/agent.ts:270）只查 signal.throwIfAborted()，无 maxSteps/maxTurns/spend 上限——单轮无限步，实测 72 步是真实行为。
• agent/turn-stopping（:302-304）确实只在 turnEnds && inbox.nextStep.length === 0 时触发——即只有模型自己结束 turn 才会走这个兜底钩子。
• TurnEndReasonMap（packages/core/session/src/types.ts:155-174）= completed/aborted/blocked/error/max-tokens/interrupted 六态，无预算态；:176 注释明确接口 merge-extensible（插件可合并新变体）。
• repeat-tool-reminder 检测键 = JSON.stringify([exec.name, canonical])（guard/repeat-tool-reminder/src/index.ts:195），canonical = 全参数深排序字符串（:103-105）——参数微变（timeout_ms 240000→120000）即新键、计数重置，轮询循环完全绕过。确认。

补充 1：强制停止的机制已经存在，缺的是核算与独立原因
agent/pre-step waterfall 返回 {kind:'reject'} 时，turn() 直接 turnEnds = { kind: 'blocked' }; return false（agent.ts:280-284）——"第 6 次调用被阻止"的 veto 路径现成可用，不需要改循环。真正缺的是：① 预算核算（steps/wall-clock/tokens/tool-output 的累计状态，现无任何记账）；② 独立终止原因（blocked 语义 ≠ budget-exhausted，下游无法区分"被插件拦下"与"预算耗尽"）。

补充 2：max-tokens sticky 就是新终止原因的实现先例
turn() 内注释（:297-301）："max-tokens is sticky: once any step hits the ceiling, later steps that complete normally must not downgrade the turn outcome"——框架已有"粘性终止原因"机制：命中后后续正常 step 不得降级结果。新增 budget-exhausted 变体按同一模式实现即可（sticky 判定 turnEnds.kind !== 'max-tokens' 处并列判断）。且因 TurnEndReasonMap merge-extensible，插件今天就能在类型层合并 budget-exhausted 变体并让 turn/end.reason 携带它（核心循环不消费但事件可传播）——这是本需求最小可落地的形态，等核心侧加预算核算再全量接上。

对第 2 层的锐化：exact-args 检测键是刻意设计——gentle 提醒文案（index.ts:63-67）明写 "repeating the exact same tool call with identical arguments"，检测器保证的是"完全相同调用"的精确捕获。修复方向不应是放宽键（破坏精确保证），而是为轮询类工具提供等价类提取器：指纹 = 资源 ID + 状态字段，显式丢弃易变参数（timeout_ms、时间戳、轮询序号）——与你的第 2 层一致，但以"检测器保持精确 + 另设指纹通道"的方式落，两者不冲突。

家族映射：这是 #2821（ReactLoopAgent 无 maxSteps 致无界循环）家族的第 2 机制——mech 1 = 无硬预算（本轮 again 确认）；mech 2 = 重复检测键过严，带变化参数的轮询循环完全绕过。两者互补：预算兜住"不收敛"，指纹兜住"重复提醒失灵"。

[goatliamia]

这个 case 和我们最近在 DSH 上做的一组实验很接近。前面关于 hard budget、progress fingerprint、job backoff 的讨论我基本认同，我想补一个稍微不同的角度：

这里可能不只是「怎么检测模型 polling 太多」，还可以继续问：polling 这件事本身是否应该一直留在 Model loop。

比如：

job_output(pwsh-9, timeout_ms=1000)
job_output(pwsh-9, timeout_ms=3000)
job_output(pwsh-9, timeout_ms=5000)

对目前按完整 args 比较的 repeat detection 来说，这是三个不同调用。

但从 execution / progress 的角度，它们可能其实是：

same resource: pwsh-9
same state: running
same progress revision

timeout_ms 只是 control parameter，不一定应该成为 progress identity 的一部分。

我们最近做过一个受控的 no-progress Circuit 实验：

same execution class
+ same deterministic failure/progress fingerprint
+ no meaningful world-state change

观察到：

failed attempts:      3.33 → 2.00
post-open attempts:   1.33 → 0
steps:                9.00 → 3.67
cacheReadTokens:      ↓ roughly 55–62%

后来在开放式任务里又自然遇到了：

denied tool
→ retry
→ denied tool
→ retry

所以我们后来不再把它理解成某一种特定 error 的 retry breaker，而更倾向于叫它 no-progress circuit。

不过你的 background-job case 让我觉得还能再往前走一步。

如果 job plugin / Harness 已经能够确定：

job = running

那 Model 也许根本不需要不断决定：

“现在要不要再 poll 一次？”

更自然的 execution semantics 可能是：

Model requests an unavailable result
        ↓
Harness: still running; I will surface the transition
        ↓
Model stops polling this branch
        ↓
running → completed
        ↓
Delta / event becomes visible

我们之前在 temporary-invalid lifecycle 场景里也测试过类似的 Commitment + Delta，拒绝后的重复验证从 3.0 降到了 1.67，方向上说明「状态变化由 Harness 通知」确实有机会减少 Model 自己 polling。

所以我现在会把这里拆成三个不同 primitive：

Hard Budget
→ absolute last-resort ceiling

No-progress Circuit
→ stop an execution path whose observable state is not progressing

Commitment + Delta
→ if the Harness owns the transition, remove repeated polling from the Model loop

Progress fingerprint 我也比较倾向于结构化，而不是完整 args 或文本相似度。对 job 类工具，可能更接近：

resourceId
+ normalized state
+ progress/output cursor
+ terminal state

真正发生：

pending → running
running → completed
output cursor advances

才算 progress，并 reset circuit。

这里还有一个边界我觉得很重要：Generic Runtime 不一定知道每种 Tool 什么叫 progress。可能更合理的是由 Tool / Plugin 提供自己的 progress semantics，而 Circuit 只消费统一的 progress signal。

我们目前把这组机制做成了一个可插拔的实验项目：

https://github.com/goatliamia/dsh-runtime-capabilities

如果你有兴趣，我其实更希望你直接拿自己的 72-step polling case 去试，而不是我们再自己构造一个类似场景。

命中、没命中、或者产生 false positive 都很有价值。可以直接在仓库开一个 external-case Issue；如果你后来做了适配、留下了脱敏 trajectory / 实验结果，也很欢迎 evidence-only PR，不一定非要改 Runtime 代码。

我们自己不一定拥有每一种 provider / MCP / job environment，所以我反而希望这些 capability 能逐渐被真实遇到问题的人自己拿来验证。

对这个 case，我最想知道的是两件事：

1. 不同 timeout_ms、但同一个 job state，现有 no-progress fingerprint 能不能正确识别成同一条 execution path；
2. 如果 job plugin 能提供明确的 state transition，是否真的可以进一步把 repeated polling 从 Model loop 中拿掉。

任何一条在真实场景里不成立，对这个项目来说也同样是有价值的结果。

[EvansSune]

运行稍微复杂的任务思考时间巨长，思考链也是长篇大论，非常需要给个边界限制了

[aoaoms]

我遇到过，思考过程处理请求超时还一直等待，都无法终止。重启服务才行。