【BUG】harness死循环

[Qian12581]

harness使用flash模型，昨晚测试问了一个简单的问题：DeepSeek-v4-flash和pro对比，今天早上看token直接烧完了，烧了一亿多token，后面看执行日志，发现harness反复执行，最后直到api欠费才停止，希望可以优化
下述为harness循环执行的log：

I have gathered a lot of search results. I have enough information now to synthesize a comprehensive answer. Let me do one or two final searches to get the concrete benchmark numbers from the official sources (the ar5iv paper table comparing Flash and Pro), and then write the answer.

[zoahdev]

先确认一个代码层面的现状（对照 main/master HEAD 99f6f02 rc.7），这直接决定你的止损方式：

agent-loop 没有内置"步数上限 / token 预算 / 成本熔断"。 packages/core/agent-loop/src/index.ts 只有 maxParallelToolCalls（默认 10，控制单轮并行工具数），没有 max-steps、没有累计 token 上限、没有成本熔断器。也就是说：只要模型持续请求工具调用，循环就会一直跑——dsh-budget（#2553）这类成本治理插件是唯一现成的熔断手段。

建议先分三类定位你的日志（决定是不是同一种病）：

1. 工具调用循环（模型自己反复 search / 检索 → 再 search）：日志里会出现连续多个 tool/call（search 类）且每个 turn 都产生新工具请求。这属于 为啥harness会一直在无限循环啊？ #3171 族，argszero 在 #2821 有完整诊断（模型陷入"查一下再查一下"的确认循环）。你贴的这句 "Let me do one or two final searches... and then write the answer" 反复出现，很像这一类。
2. 重试风暴：如果循环里穿插 EMPTY_RESPONSE/TRANSPORT 等可重试失败（retry-policy.ts:19-25 默认可重试码），那是 Bug: vLLM self-hosted deployments stream thinking as delta.reasoning — adapter drops it (fix available) #199 族机制（我们在 Bug: vLLM self-hosted deployments stream thinking as delta.reasoning — adapter drops it (fix available) #199 核验过完整链路）。
3. 单轮超长：搜索结果巨大撑爆 context，单轮就烧掉大量 token（这是另一类，需要 dsh-budget 或超时策略）。

立即可用的止损：

dsh plugin --profile web add dsh-budget   # 成本上限 + 超限策略（#2553 社区插件）

另建议给 profile 配 per-tool timeout（timeout-policy guard）并限制 search 类工具的并行/次数。

为了让官方/社区能定位，请补： ① dsh 版本；② session log 里 tool/call 的 turn 序列（几次、什么工具、有没有 error/finish 重试）；③ 会话开始时间与 token 消耗曲线。有了这三样，就能判定是循环失控还是重试风暴，也才能对症优化。

给官方的建议（本次事故的核心诉求）： 在 agent-loop 增加可选的累计步数/成本熔断（默认关闭或低默认值，与 dsh-budget 语义协作），避免"跑一夜烧光预算"这类无断路器事故。这值得单独开一个 feature 提案帖。

[zoahdev]

应 #3228/#3229 两帖（两位都烧光余额/预算）整理一份 feature 提案草稿，供合并立项：

提案：agent-loop 内置可选的累计步数/成本熔断（circuit breaker）

动机：agent-loop 目前只有 maxParallelToolCalls（默认 10），没有累计步数、累计 token 或成本上限（代码现状已核验：packages/core/agent-loop/src/index.ts）。模型陷入"查一下再查一下"的确认循环时，循环会一直跑，直到余额烧光——#3228（1 亿+ token）、#3229（小问答耗尽余额）都是同一事故类。

设计（最小闭环）：

1. 可选配置（默认关闭，避免行为变化）：

   agent-loop:
     circuitBreaker:
       maxStepsPerTurn: 50          # 单 turn 累计工具步数上限
       maxTokensPerSession: 0       # 0 = 不限制；>0 = 会话累计 token 上限
       maxCostCents: 0              # 0 = 不限制；>0 = 成本上限（配合 token-meter 计费）

2. 触发语义：达到上限 → 循环停止 + 明确的失败码（如 LOOP_CIRCUIT_OPEN）+ 一句人类可读说明（"已到达步数上限，可能是循环；换一种方式重试或检查工具调用模式"）——不是静默停，让用户一眼知道发生了什么。
3. 恢复：新 turn / 新会话 / 用户确认后重置；熔断状态持久化到会话事件（turn/end reason 带 code），可审计。
4. 与 dsh-budget 的关系：dsh-budget 是外部策略层（超限行为可自定义）；内置熔断是内核兜底（即使不装插件，默认防呆也在），两者语义协作不冲突。

落地位置：agent-loop 的 turn 边界计数（steps）+ token-meter 的累计计数器（tokens/cost）→ 熔断检查放在每步 dispatch 前。

回归测试：① 循环场景（模型连续请求同一工具）→ 步数上限触发 LOOP_CIRCUIT_OPEN；② token 上限触发；③ 恢复路径（新 turn 重置）。

如果两位 OP（#3228/#3229）认可，我可以把这个草稿扩成完整的 proposal 帖（含代码位置与测试骨架）。

[denial123789]

这个现象更像 Agent step loop 持续收到“成功的搜索结果”后再次决定调用工具，而不只是单次工具并发过高。当前源码里的 maxParallelToolCalls 只限制一个 step 内的并发，compaction 也只控制上下文压力；它们都不是整轮调用/费用上限。

建议先按这个顺序止损和取证：

1. 运行中按 Esc 或 Ctrl+C，并同时观察 provider usage 是否停止；
2. 保存连续的 assistant → tool call → tool result 事件和每次请求 usage；
3. 不要原样 resume，同一任务换新 Session，缩小到只读工具和明确完成条件；
4. 在 provider 项目侧设置独立的额度/消费上限。

我把这些边界、四种循环类型和最小 incident bundle 整理成了一个独立英文 runbook（基于 99f6f02 源码，不是官方文档）：https://sandbaseai.github.io/deepseek-harness-handbook/runaway-agent-loop.html

如果能补充取消前后最后 5–10 个 Session events，会很容易判断是成功工具调用循环、工具失败循环还是 provider retry。

[PerryLink]

?? token..????????????????????????,????????????:??? dsh-budget ????/?/??? USD ??,overLimit: block ??????????????--????????,????????????????????? alert ? + warnRatio: 0.8,? 80% ? webhook/????????,????????;????????? block?

??:dsh plugin --profile web add dsh-budget???????????????????,?????????????????