同一提示词四次实测：简单配置任务出现 33–50 轮「无界确认」行为（DeepSeek V4.1 + DSH）

[adamqeqj003-dotcom]

现象

一条只需改一个配置字段的提示词，在 DSH 里四次独立会话分别消耗 33–50 轮、32–70 次工具调用；其中真正写入配置的那一步只有 1–3 轮，其余全在动手前反复确认和动手后反复验证。

环境

• 模型：DeepSeek V4.1（2026-09-10 发布的 V4.1-Flash）
• 框架：DSH（本仓库），四次均为全新会话
• 其中三次未加载任何规则文件与技能，一次加载了全局 AGENTS.md；交互模式覆盖 PTC 与标准两种；会话工作目录覆盖两个不同目录
• 测量方式：从会话日志机读 assistant 消息与 tool/call 事件计数，非人工估计

提示词原文（四次完全相同）

给我自定义的这个基元律动的模型，Deepseek Flash模型。的配置文件里加上思考强度的设置 两档，High和Max，默认为High。

起点状态：配置文件里没有该字段。

数据

#	规则文件	模式	轮数	工具调用
1	加载	PTC	39（被用户打断，是下限）	—
2	无	PTC	50	59
3	无	PTC	33	32
4	无	标准	43	70

阶段分解（第 2–4 次测得明细）：

阶段	第 3 次	第 2 次	第 4 次
找到配置文件	4	4	2
搞懂字段语义（答案到手）	第 12 步	第 12 步	第 8 步
动手前的反复确认	15	28	14
建退路 + 真正写入	2	1	3
改完的验证与收尾	4	9	18

唯一有 token 记账的一次（第 1 次）：输入 2,946,619 token——探查 1,602,644、写入回合 90,603、写入之后重新验证 1,253,372。真正的改动占 3%。

已排除的变量

规则文件有无、技能有无、技能目录体量、交互模式、会话工作目录、用户打断。未排除：模型版本（四次都在 V4.1）、框架版本、样本量（四次同一任务）。

观察到的机制

模型在 6–12 轮内就已拿到所需知识，随后 20–40 轮都在证明自己没写错——包括验证那些只有改完才知道结果的事（配置会不会热重载、网关收不收这个值、默认档解析链路对不对）。每一步单独看都合理，合起来没有边界；推理长度看起来正常，膨胀的是动作数量。

框架层可以做的三点

1. 给「交付即可停」一个显式信号：当 agent 把最终验收交给用户时，不必先自建一条端到端证据链。
2. 步数或预算软上限，触及后要求模型说明「还缺什么」，而不是继续。
3. 上下文压缩后主动恢复「本会话已执行过的动作」摘要。

事实与推断的分界

上面所有轮数、工具调用数、token 分解、四种条件下一致的形状都是实测。未声称该行为只出现在 V4.1，也未声称它在所有任务类型上都出现；「模型版本变化导致退化」只是线索，没有做同题跨版本对照。

English summary

Four identical prompts (a one-field config edit) on DeepSeek V4.1 inside DSH produced 33–50 assistant turns and 32–70 tool calls, while the actual write took 1–3 turns; one recorded run spent 2,946,619 input tokens with 3% of them in the write step. The same prompt with no rule file or skill loaded still took 33–50 turns, so instruction text is ruled out. Reasoning length looks normal — what inflates is the number of actions: the model keeps verifying things that can only be known after the change is applied, and it has no internal "enough" criterion. Behavior is consistent with Infinite Agentic Loops (arXiv 2607.01641). Suggested harness-level mitigations: an explicit "deliverable is enough" signal, a soft step/budget cap forcing a "what is missing" report, and post-compaction recovery of the session's own executed actions.

[argszero]

这份报告的数据质量很高，所以我没有停在"看起来合理"上，而是把你指出的机制逐条核到源码，并且把你的建议 2 做成了可直接挂载的插件（下面第 5 节）。结论：你的三条建议都成立，其中两条在源码层比你描述的更"结构性"——失败不是某处写得不对，而是循环本身没有上限这个设计事实。

1. 为什么你观测到的形状是确定的（不是偶发）

packages/core/agent-loop/src/agent.ts：

• turn() 是 while (true)（:286）。它只有三种退出方式，全都要求 turnEnds 已被置位：preStep 返回 reject（:290-293）；本轮进入的消息批为空（:294-300）；某步已结束且 inbox.nextStep 已被抽空（:308-311）。
• 而一步只有在两种情况下才算"结束本轮"——这一步没有发出任何 tool call，或它发出的 tool call 判定为 concludesTurn（:486-492）。
• 与此同时，executeToolCalls 会把每个工具结果 splice 回 inbox.nextStep（:489-491）。

⇒ 只要模型持续调用工具，turnEnds 就永远不被置位，而每一次工具调用都在为下一步制造输入。循环因此不会收敛，也没有任何计数器阻止它。我在 packages/ 全量 grep 了 maxSteps / stepLimit / stepBudget——零命中；框架唯一暴露的循环参数是 AgentLoopSettings.maxParallelToolCalls（src/index.ts:309），那是并发度，不是上限。

这也解释了你"每一步单独看都合理，合起来没有边界"的观察：每一步的正确性检查都在框架内合法，缺的是对步数求和的那一层。

2. 为什么现有的两个 guard 都挡不住（你可能已经排除过，这里给出机制）

• guard/timeout-policy 挂在 tools/execute，是单个工具的截止时间——你的循环里每一步的工具调用都成功返回了。
• guard/repeat-tool-reminder 的判定键是 [工具名, 完整参数的规范化 JSON]，即需要参数完全相同的重复调用。你的第 4 次运行是 70 次工具调用且参数每次都在变，所以它的计数永远不累积。

⇒ 这两个 guard 覆盖的是"同一步卡死"和"同一调用重复"，都不是"步数无界"。你的用例正好落在两者的缝隙上。

3. ★ 你的 token 数据还能再解释一层：成本是双重的

你说"推理长度看起来正常，膨胀的是动作数量"——同意，但动作数量本身还会把每一步的成本抬高：buildRequest 在每一个 step 都调用 session.deriveMessages() 并把完整历史作为 messages 发出（:603、:609）。所以第 N 步的输入 ≈ 历史全长，整个 turn 的输入 token 大致是历史长度 × 步数。

这正好落在你的记账上：探查 160 万、写入 9 万、写入之后重新验证 125 万——不是"验证那几步"本身贵，而是那几步的上下文最贵（此时历史里已经装满了探查结果）。也就是说：减少步数是二次收益，越靠后的步省得越多。

4. 逐条回应你的三点框架层建议

建议 2（步数/预算软上限）——最小、且落在可挂载的缝上。 我做了（见下节）。这是你三点里唯一不需要改 core 的。

建议 1（"交付即可停"的显式信号）——它不能单独存在。 一个没有阈值的"信号"就只是提示词里再多一句，而提示词的量级你的数据已经排除了（加载/不加载规则文件结果一致）。我的实现把 1 和 2 合在一起：信号由步数触发后，以一条具体的、要求回答"已完成/剩余/下一步"的消息送达，而不是一句泛泛的鼓励。

建议 3（压缩后恢复"本会话已执行的动作"）——可挂载，但你说的其实是两件事，值得分开。

• 一半已经被覆盖了：摘要 checklist 里必然包含 ## Files and Code 与 ## Errors and Fixes 两节，而且下次压缩会把上一次的摘要合并进来（"保留仍为真的、丢掉过期的"，不许逐字照抄）。所以"改过哪个文件"通常会在摘要里。
• 真正缺的是你点名的那句——"已执行过的动作"：一张工具调用台账（工具 + 关键参数 + 结果一行），而不是语义概括。这条与摘要是互补的，可以独立做：插件订阅公开的 session/event，筛出 tool/result 累积台账，在观察到 compaction/end 之后把它作为一条新的 user/message 注入。（session/event + step/end 过滤是仓库内既有的插件级用法，见 context/agent-instructions/src/index.ts:307-313。）
• 如实说明：这一条我只核到可行、没有实现——因为第 5 节的插件已经覆盖了你数据里"动手前反复确认 14-28 步"那一大块，先上一条再评估更划算。

5. 交付物：@argszero/cordis-plugin-turn-budget-guard@0.1.0

• npm：@argszero/cordis-plugin-turn-budget-guard
• 仓库：https://github.com/argszero/cordis-plugin-turn-budget-guard
• 挂载：包内含 dsh.bundle 补丁，profile 层 insert 即生效：

- insert:
    - id: turn-budget-guard
      name: '@argszero/cordis-plugin-turn-budget-guard'
      config:
        maxSteps: 20
        gracefulSteps: 8

行为（刻意做成看门狗而不是闸刀）：

1. 未超 maxSteps —— 完全不动，直接放行；
2. 超过 —— 追加一条 logged 的 user/message（source.kind:'plugin'，带插件名，可被审计/过滤），要求它现在就回复"已完成/剩余/下一步"，不再展开新一轮验证；
3. 再过 gracefulSteps 步仍未收束（或 maxFires 用尽）—— agent.cancel('turn-budget', { keepInbox: true }) 结束本轮。keepInbox 是刻意的：默认的 cancel() 会清空队列与 steering 输入，那会把你在这期间打进去的内容一起丢掉。

为什么不会误伤正常任务：预算是按相对基线计的，并且你在中途打字会重设基线——你人已经重新介入了，本轮就该重新获得完整额度。这正是你"每步单独看都合理"的直接推论：合格线应该是"没有进展"，而不是"步数大"。

默认值怎么来的：你自己的分解——第 8–12 步已拿到所需知识，实测 33–50 步。默认 maxSteps: 20 取在这两者之间，gracefulSteps: 8 让它有两次机会收束。按任务类型调大即可。

它是缝上止血，不是 core 修复：真正的修复应当是一个 AgentLoopSettings.maxSteps，外加一个sticky 的 turn-end reason（max-tokens 已有关闭降级的先例可循）。上游一旦有了，把 maxSteps 调到它之上、或直接卸掉这个插件即可——它是纯观察者，上游修好后自动变成 no-op。

6. 边界与一个补充视角

• 全部源码结论基于 c291e7961a；我没有复现你的会话（没有你的任务环境），插件的行为验证用的是脚本化事件驱动 + 打包产物级冒烟，而不是真实模型跑 50 轮。
• 你把"模型版本"和"框架版本"都列为未排除变量——这一点值得保留，但源码给出了一个不需要模型退化的解释：只要模型不断调用工具，循环就不收敛。V4.1 "先把不确定的都验一遍"的倾向恰好落在这个形状里。所以更准确的说法是模型行为 × 无上限的乘积，而不是任一方单独造成；也正因如此，框架侧的上限无论模型怎么变都有价值。
• 你提到的 arXiv 2607.01641 我没有读，所以不对它的结论表态。

English summary: All three of your observations are confirmed at source level on c291e7961a. The loop is while (true) with no step/action/spend ceiling anywhere (grep maxSteps|stepLimit|stepBudget in packages/ is empty), and every tool call both blocks the turn from ending and manufactures the next step's input. Two extra findings: the token cost is quadratic in steps (buildRequest resends the full derived history every step, agent.ts:603/609), which explains why 1.25M of your tokens sat in the post-write re-verification; and neither in-tree guard covers this (timeout-policy is per-tool; repeat-tool-reminder needs identical arguments, which your run never repeats). I implemented your suggestion 2 as a mountable plugin — @argszero/cordis-plugin-turn-budget-guard — which asks the model to wrap up past maxSteps and cancels the turn with keepInbox after a grace window; it rebases the budget whenever the user types mid-turn. Suggestion 1 only lands when bound to a threshold, so it is folded into that message; suggestion 3 is half-covered by the existing summary (which already carries files/errors and merges the prior checkpoint) but the missing half — an executed-actions ledger injected after compaction/end — is feasible via session/event and left as a follow-up.