Claude Code开启ToolSearch遇GLM-5无限循环

背景

在 AI 辅助编程领域，Claude Code 作为一款强大的命令行代码助手，正逐渐被开发者用于处理复杂的项目重构和 UI 修改任务。然而，当结合特定的工作流插件（如 cc-switch）以及特定模型（如 GLM-5）时，开发者可能会遇到工具调用层面的异常行为。

本文分享源自 LINUX DO 社区，记录了一位开发者在使用 Claude Code v2.1.167 版本，配合 cc-switch 插件及 GLM-5 API 进行前端 UI 修改任务时，开启 toolsearch（工具搜索）功能后陷入无限循环的案例。该案例揭示了当前 AI 编程助手在工具加载、Schema 解析以及自我纠错机制方面存在的潜在缺陷，特别是当系统提示（System Prompt）与项目实际技术栈（如 TypeScript/Bun/Electrobun）不匹配时，模型容易陷入无效的搜索死循环。

核心内容

1. 任务场景与初始设定 开发者旨在一个名为 Cotaya-monorepo 的 monorepo 项目中的 worcester workspace 下，修改桌面应用（基于 Electrobun 构建）的 UI。具体需求是在左侧栏底部问号图标（Help Icon）的左侧，增加一个新的图标按钮，点击后允许用户选择两个 SVG 文件（cybersecurity.svg 和 code.svg）。

2. 工具加载与初步探索 Claude Code 在接收到指令后，首先尝试理解需求并检查适用的 Skill（技能模块）。根据 CLAUDE.md 中的指示，模型优先考虑创建团队并行处理，但鉴于任务较小，模型决定直接探索代码库。模型识别出任务涉及前端 UI 修改，理论上适用 frontend-design 或 brainstorming 技能，但认为直接实现更为高效。

为了找到左侧栏代码，模型启动了 toolsearch 机制，试图加载 Grep、Glob、Read、Edit 等基础文件操作工具。初始阶段，模型报告工具已加载（"Tool loaded"），但在后续执行中，Glob 工具似乎未能正确返回结果或无法通过标准方式调用，而 Bash 工具则被确认为可用。

3. 无限循环的成因分析 随着探索深入，模型陷入了一个典型的“工具加载失败-重试-失败”的死循环，具体表现为：

• 工具可用性误判：模型多次尝试通过 ToolSearch 加载 Glob 工具，尽管之前显示 "Tool loaded"，但在实际调用或 Schema 获取时失败。模型反复尝试不同的查询方式（如使用关键词搜索而非 select）来加载 Glob，导致大量 Token 消耗在无效的工具搜索上。
• 环境与技术栈错位：系统提示中包含大量关于 Rust skills 和 meta-cognition 的内容，但当前项目是 TypeScript/Bun/Electrobun 项目。这种上下文不匹配导致模型在判断适用 Skill 时产生困惑，虽然最终试图忽略无关信息，但仍影响了决策效率。
• Schema 解析问题：模型在后期意识到，问题可能出在 deferred tools（延迟加载工具）的 Schema 未正确加载。尽管 Bash 工具在之前的调用中显示已加载，但由于 ToolSearch 返回的结果中未明确显示 Schema，模型无法确定如何正确调用 Bash 的具体参数（如 command）。
• 自我纠错失效：模型虽然多次意识到自己陷入了循环（"I am stuck in a loop"），并试图强制切换到 Bash 工具，但由于对工具调用格式和环境约束的不确定性，它仍然不断回到 ToolSearch 尝试加载其他工具，未能彻底打破循环。

4. 最终状态 直到日志结束，模型仍未成功执行具体的代码搜索命令，而是停留在不断尝试加载 Glob 和确认 Bash 可用性的循环中。这表明在当前的配置下，toolsearch 机制在处理非标准工具或环境配置不一致时，极易导致 AI 助手“卡死”。

关键要点

• ToolSearch 的稳定性风险：开启 toolsearch 功能后，如果底层工具（如 Glob）在环境中存在兼容性问题或加载失败，AI 模型可能会陷入无限的重试循环，浪费 Token 且无法推进任务。
• 系统提示与项目技术栈的匹配至关重要：当 CLAUDE.md 或系统提示中包含与当前项目技术栈（如 Rust vs TypeScript）不符的 Skill 描述时，模型会产生认知冲突，导致决策路径混乱。
• 工具 Schema 加载机制的模糊性：当前版本中，deferred tools 的 Schema 加载可能存在缺陷。即使工具显示 "Tool loaded"，若 Schema 未正确解析，模型将无法生成正确的工具调用参数，导致调用失败。
• 模型自我纠错的局限性：尽管模型能识别出自身陷入循环，但在缺乏明确错误反馈或替代方案指引的情况下，它倾向于重复尝试失败的路径（如反复加载 Glob），而非果断采用备用方案（如直接使用已确认可用的 Bash）。
• cc-switch 与多模型集成的潜在冲突：使用 cc-switch 切换不同模型（如 GLM-5）时，不同模型对工具调用的理解和响应格式可能存在差异，增加了集成环境的复杂性。

意义与影响

这一案例对 AI 编程助手的使用者和开发者具有重要的警示意义：

1. 工作流配置的优化：在使用 Claude Code 等高级 AI 编程工具时，开发者应仔细检查 CLAUDE.md 等配置文件，确保其中的 Skill 描述、工具定义与当前项目的实际技术栈保持一致，避免上下文污染。
2. 工具链的健壮性测试：在部署 AI 辅助开发流程前，应对常用工具（如 Glob, Grep, Bash）的加载和调用进行充分测试，特别是当使用 toolsearch 等动态工具发现机制时，需确认其在各种环境下的稳定性。
3. 监控与干预机制：开发者应建立对 AI 助手行为的监控机制，当检测到模型在工具调用上反复重试或长时间无进展时，应及时介入干预，手动指定工具或重置上下文，避免资源浪费。
4. 模型选择的考量：不同模型在处理工具调用和复杂指令时的表现存在差异。在集成多模型工作流（如结合 GLM-5 和 Claude）时，需评估各模型在特定工具链下的兼容性和稳定性，选择最适合当前场景的模型或配置。

总之，该案例揭示了当前 AI 编程助手在工具集成和复杂任务处理方面的成熟度仍有提升空间，特别是在处理动态工具加载和跨技术栈上下文时，需要更稳健的错误处理和自我纠错机制。