[Bug]: Agent 陷入工具死循环并丢失上下文变量，导致 NameError 反复出现且忽略用户追问

[lifein2]

What happened / 发生了什么

在使用 WebChat 适配器进行数据分析任务（生成 OLS/GARCH/AR 回归 Excel）时，观察到 Agent 出现严重的逻辑故障，具体表现为以下三点：

高频 NameError 异常：
Agent 在调用 astrbot_execute_python 工具时，将本应完整执行的 Python 脚本错误地拆分为了 20 余个孤立的代码片段。由于该工具每次调用均运行在独立的无状态进程中，后续片段因缺少 import 语句和前期定义的变量（如 wb, np），连续抛出 NameError: name 'wb' is not defined 和 NameError: name 'np' is not defined。

工具调用死循环且无视系统警告：
尽管系统日志反复发出 [SYSTEM NOTICE] Important: you have executed the same tool ... times consecutively 的警告（最高达 23 次），Agent 仍坚持重试相同的策略，未能修正代码片段的完整性，也未切换为直接向用户说明困难的交互模式。

追问消息被静默消费（Follow-up message lost）：
在任务执行期间，用户发送了追问消息 “为什么你的python代码迟迟没有结果”。系统日志显示 Captured follow-up message，但随后立即标记为 Follow-up ticket already consumed, stopping processing。Agent 完成最后的代码执行后并未针对该追问生成任何文本回复，导致用户长时间等待后仅看到任务结束。

Reproduce / 如何复现？

向 Bot 发送一个复杂的 Python 开发任务请求，例如：

“请使用 Python 生成 OLS 回归、GARCH(1,1) 模型和 AR(2) 自回归模型的模拟数据，计算回归结果，并生成一个包含三个 Sheet 且带格式的 Excel 文件。”

观察 Agent 调用 astrbot_execute_python 工具的日志。

在 Agent 连续调用该工具 3-5 次仍未完成任务时，作为用户发送追问消息：

“为什么你的代码迟迟没有结果？”

等待 Agent 执行完毕。

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

AstrBot 版本：v4.23.2
部署方式：astrbot launcher
llm：kimi-k2.5
消息平台适配器：webchat (WebChat Adapter)

OS

Windows

Logs / 报错日志

pingtairizhi.txt

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

@lifein2 你好！这个 issue 涉及三个相关但独立的问题，以下逐一分析：

1. 高频 NameError — astrbot_execute_python 的无状态设计

astrbot_execute_python 每次调用都通过 subprocess.run([python, "-c", code]) 在完全独立的子进程中运行 [1]，不会保留前一次调用的 import、变量或任何状态。如果 LLM 将一个完整脚本拆分成多个片段分别执行，后续片段必然因缺少 import 和变量定义而抛出 NameError。这是 LLM 的代码生成策略问题，而非 AstrBot 的 bug——LLM 应将所有逻辑放在一次调用中完成，或通过文件系统在调用间传递状态。

2. 工具调用死循环 — 警告机制不强制中断

AstrBot 已有连续工具调用检测机制 [2]，在连续 3/4/5+ 次调用同一工具时会发出递进式警告（advisory → urgent → strong warning），这些警告作为 system notice 注入到 LLM 上下文中 [3]。但这只是"建议"，不会强制终止循环——最终是否停止取决于 LLM 自身的判断。硬性保护是 max_agent_step 上限（默认 30 步），达到后才会强制终止 [4]。

这和之前 #7387 报告的问题类似——某些模型（如 MiMo-v2-flash）会无视这些警告持续返回 tool_calls [5]。你使用的 kimi-k2.5 似乎也存在类似行为。PR #7388 引入了改进的重复调用检测和引导机制 [6]，但本质上仍依赖 LLM 遵守指令。

临时缓解：可以降低 max_agent_step（如 5~10），减少无效循环次数。

3. 追问消息被消费但无回复

Follow-up 消息的工作方式是：在 agent 执行工具期间捕获用户消息，然后在下一次工具返回结果时合并到工具结果内容中，作为 system notice 注入 LLM 上下文 [7]。消息被标记 consumed 意味着它已经被合并到上下文中 [8]。

但如果 agent 在消费 follow-up 后很快触发了 max_step 终止，或者 LLM 在后续步骤中没有生成针对追问的文本回复，用户就看不到任何响应。目前没有机制检测"已消费的 follow-up 是否得到了用户可见的回复"——系统假定 LLM 看到 notice 后会自行回应，但当 LLM 陷入工具循环时，这个假设不成立。

总结：核心问题在于 kimi-k2.5 模型在面对连续 NameError 时未能调整策略（将代码合并为完整脚本），同时忽略了系统的重复调用警告。AstrBot 现有的保护机制（警告 + max_step 硬限）都已生效，但警告层面依赖 LLM 配合。如果这个问题在 kimi-k2.5 上频繁出现，建议尝试更换模型或降低 max_agent_step。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Soulter]

这个应该当时agent还在运行，等待下一个tool call，目前认为这个日志是预期现象。