Qwen3.7-Plus 为什么反复报告 Tool execution aborted？

Qwen3.7-Plus 在 Kilo Code 中反复报告 Tool execution aborted，如果现象集中出现在 VS Code 扩展 7.4.9，并且连读取文件这样的基础操作也会被中止，优先判断为扩展侧的已知回归，而不是模型突然失去工具调用能力。原问题的维护者已经确认修复进入主分支，因此最有效的处理是升级到包含修复的稳定版本；在升级前后保留日志并做最小复现，才能避免把版本故障与权限、沙箱或服务负载混为一谈。

这条提示真正表示什么

Tool execution aborted 表示一次工具执行没有正常完成，但它不是一个足以直接定位根因的底层错误。一次读文件操作通常要经过模型生成工具调用、Kilo Code 校验调用、扩展执行本地工具、结果回传模型几个环节。任一环节主动取消、状态丢失或被新请求替换，界面都可能只显示“执行已中止”。

原始案例的关键证据有三个：问题是在 VS Code 扩展 7.4.9 中突然出现的；同一工作流两天前还能正常完成；错误在读取文件时反复发生，同时代理长时间停留在“Considering next steps”。维护者随后说明问题已在主分支修复并将进入下一版本。这个时间关系比单独看到 Qwen3.7-Plus 型号更有诊断价值。

先升级扩展并建立干净会话

先在 VS Code 的扩展管理页查看 Kilo Code 当前版本，升级到可用的最新稳定版，然后执行一次窗口重载。已有会话可能保留旧的运行状态、工具调用记录或取消标记，因此升级后不要只在原会话中继续点击重试，应该新建会话，用同一个项目和同一个模型执行最小读文件任务。

1. 记录当前 Kilo Code 版本、模型名称、运行模式和 provider。
2. 升级扩展，完成后重载 VS Code 窗口。
3. 新建会话，只要求代理读取一个已知存在的小型文本文件并概述第一行。
4. 确认工具结果能够返回，再逐步恢复原来的测试修复任务。

成功标志不是界面不再出现某个词，而是读取工具产生了有效结果，结果被模型接收，并且代理能够继续下一步。如果最小任务正常、旧长会话仍失败，应保留新会话并重新提供必要上下文，不要继续复用可能已损坏的执行链。

不要先把回归误诊为模型问题

错误恰好发生在 Qwen3.7-Plus 上，并不能证明模型是根因。模型负责提出工具调用，扩展负责接收、授权、执行和回传；维护者确认扩展代码已有修复，说明至少该案例存在客户端实现因素。直接换模型可能暂时绕过触发条件，却无法证明原模型不支持读文件，也无法修复扩展状态。

可以用控制变量法验证：保持项目、提示词、Kilo Code 版本和 provider 不变，只更换模型；再保持模型不变，只更换扩展版本。若多个模型都在旧版本失败，而升级后同一模型恢复，证据指向扩展回归。若只有一个模型持续产生无法解析的调用，则再检查模型与 provider 的工具调用兼容性。

升级后仍失败时按执行链排查

检查是否由用户或会话取消

先确认没有连续提交新消息、停止当前任务或在工具尚未完成时切换模式。新的用户动作可能取消正在运行的工具。测试时一次只发送一个请求，等待工具返回后再继续，避免人为制造与回归相同的表面现象。

检查工具权限

Kilo Code 的工具需要经过权限策略。权限为 ask 时，扩展会等待确认；权限为 deny 时，调用会被阻止。打开设置中的自动批准配置，确认读取工具没有被拒绝，同时查看界面是否存在被忽略的授权提示。权限问题通常会稳定地影响某一类工具，而不是升级前突然大面积随机中止。

区分沙箱拒绝与普通中止

沙箱位于工具权限之外，用于限制写入位置和网络访问。官方说明中，沙箱无法建立或目标不被允许时应返回具体错误并拒绝执行，不会静默降级为无限制运行。单纯读取项目内文件通常也不受沙箱写入限制。只有日志明确出现沙箱、代理或路径限制时，才调整对应配置；不要为消除一条笼统提示而关闭全部安全边界。

查看扩展日志中的第一条错误

打开 VS Code 的输出面板，选择 Kilo Code 相关输出通道，并同时查看开发者工具控制台。重点保存第一次中止前后的工具名称、调用标识、异常消息和时间，不要只截取最后一条汇总提示。连续失败往往会产生多条派生错误，第一条错误最接近真正原因。

提交问题时应包含可复现步骤、扩展版本、VS Code 版本、操作系统、provider、模型名称和经过脱敏的日志。API Key、令牌、用户名、私人路径以及项目源码不应出现在公开日志中。

如何判断问题已经解决

用三个层级验证比一次成功更可靠。第一层连续执行三次只读任务，确认没有中止；第二层让代理读取两个相关文件并给出差异，确认多步结果能正常回传；第三层再恢复原来的测试修改任务，确认读取、编辑和测试工具能够依次完成。每一层都使用新会话，并记录失败发生在哪个工具阶段。

如果升级后基础读取恢复，而大型任务仍长时间停留在“Considering next steps”，再缩短上下文、拆分任务并检查 provider 延迟。推理等待和工具执行中止属于不同阶段，不能仅凭它们同时出现就认定是同一个故障。

临时绕过方案及其边界

无法立即升级时，可以新建短会话、把任务拆成单个文件操作，或暂时选择已验证能稳定返回工具调用的模型。这些措施只能降低触发概率，不会修复扩展回归。不要反复自动重试写文件、执行脚本或部署命令，因为一次调用可能已经产生副作用，只是结果没有成功回传。

因此，处理这类重复中止的顺序应当是：先确认扩展版本并升级，再用干净会话复现，随后检查权限、沙箱和第一条日志错误，最后才比较模型与 provider。对原始 7.4.9 案例来说，维护者给出的版本修复信息是最强证据，换模型只能作为诊断对照或短期绕行。