Cline 接入 DeepAI API 中转站：You did not use a tool 工具调用错误怎么排查

Cline、Roo Code 这类代码 Agent 和普通聊天客户端最大的差别是：模型不能只“回答得像个人”，还要按客户端约定输出工具调用格式。例如读取文件、编辑代码、提交最终结果，都要被解析成明确的 tool call。通过 DeepAI API 中转站接入 OpenAI-compatible Provider 时，如果遇到 You did not use a tool in your previous response，不要只盯着 Base URL 和 API Key，重点要看模型是否真的产出了可解析的工具调用。

Cline 接入 DeepAI API 中转站时报 You did not use a tool 的 XML 工具调用排查流程 — 代码 Agent 的工具调用失败，常常发生在模型输出格式、上下文窗口和项目文件列表三者交界处。

GitHub Issue 背景：模型回答了，但没有用工具

这个问题来自 Cline Issue #735。用户使用 OpenAI Compatible Provider 和 Claude 3.5 Sonnet 类模型时，任务中突然出现自动错误提示：

[ERROR] You did not use a tool in your previous response!
Please retry with a tool use.

报错后，Cline 还会提醒模型必须使用 XML 风格的工具调用格式，例如 <attempt_completion>、<ask_followup_question> 或其他工具标签。也就是说，客户端并不是没有收到模型回复，而是没有从回复中解析到它需要的工具调用结构。

为什么 OpenAI-compatible 接入更容易暴露这个问题

OpenAI-compatible 只是传输协议兼容，不等于所有模型都具备同等的 Agent 工具遵循能力。代码 Agent 需要模型稳定做到三件事：

理解当前任务和工程上下文。
按客户端要求输出严格的工具调用格式。
在多轮工具执行后继续保持格式，不把工具调用写成普通自然语言。

当你把 Cline 接到本地模型、Ollama、Open-WebUI、第三方网关或 DeepAI API 中转站时，请求路径可能都正确，但模型能力、上下文长度、系统提示保真度、流式输出和 XML 解析都会影响结果。DeepAI API 中转站可以统一鉴权、路由和日志，但不能替一个工具遵循能力不足的模型稳定生成 Cline 需要的 XML 标签。

Issue 里的三个关键线索

Issue 讨论里出现了几个很有价值的排查线索：

项目文件列表过大：有用户提到项目目录包含大量文件，Cline 自动注入的文件列表被截断，导致上下文被无关信息挤占。
本地模型 context 太小：有人指出 Ollama 即便模型标称支持大上下文，实际加载时默认 context 可能只有 2048，关键工具指令容易被截断或稀释。
模型工具能力差异：也有人反馈切到云端模型后问题消失，说明同样的 OpenAI-compatible 协议下，模型对工具格式的遵循能力差异很大。

这三点对 DeepAI API 中转站用户尤其重要：如果同一套 Cline 配置里，普通聊天没问题，但读取文件、编辑代码、完成任务时反复提示没有使用工具，优先看上下文和模型能力，而不是只换 Key。

DeepAI API 中转站场景下的排查步骤

确认 Cline / Roo Code 的 Base URL 写到 https://api.deepai.wang/v1，不要写到具体接口路径。
在 DeepAI API 中转站后台确认请求确实到达，状态码是 200，且使用的是你预期的模型。
让 Cline 执行最小任务，例如只读取一个短文件并总结，确认工具调用解析是否稳定。
如果最小任务能跑，大项目失败，检查文件列表、忽略规则和上下文长度。
如果最小任务也失败，优先换成工具遵循能力更强的模型，或降低温度、增加上下文窗口后重试。

如何减少上下文噪声

代码 Agent 最怕把大量无关文件塞进上下文。建议在项目里明确排除这些目录：

node_modules/
.git/
dist/
build/
coverage/
.next/
logs/
*.lock
*.min.js

如果客户端支持 ignore 文件或上下文排除配置，尽量让 Cline 只看到当前任务相关的源码、配置和文档。文件列表越干净，模型越容易保留工具调用说明，输出 <read_file>、<replace_in_file>、<attempt_completion> 这类标签的稳定性也越高。

模型选择建议：不要只看价格和上下文长度

对 DeepAI API 中转站来说，给代码 Agent 选模型时建议看四个指标：

工具格式遵循能力：能否长期稳定输出客户端要求的 XML 或 tool call。
有效上下文：不是宣传窗口，而是实际请求里能否保住系统提示、工程上下文和任务指令。
代码理解能力：能否在读文件、改文件、运行测试之间保持状态。
延迟与成本：工具链路会多轮调用，便宜但频繁失败的模型反而更贵。

如果你在中转站后台同时配置多个模型，可以给 Cline 单独分配一个“代码 Agent 专用”模型路由，而不是和普通聊天共用同一个便宜模型。这样既方便成本统计，也能减少工具调用格式错误。

常见误区

看到 200 就以为成功：HTTP 200 只能说明模型返回了内容，不代表 Cline 解析到了工具调用。
只调大 max_tokens：输出长度不等于上下文长度。工具说明可能在输入侧已经被挤掉。
把所有仓库文件都给模型：项目越大，越应该用 ignore 和按需读取。
把协议兼容当成 Agent 兼容：OpenAI-compatible 能通，不等于模型适合 Cline 工具工作流。
忽略模型温度：工具调用场景建议使用更低温度，减少格式漂移。

上线前的最小验证清单

问一句普通问题，确认 DeepAI API 中转站连接、Key 和模型路由正常。
让 Cline 读取一个小文件，确认 read_file 类工具调用能被解析。
让 Cline 修改一个临时文件，确认编辑工具调用能完成。
让 Cline 输出最终结果，确认 attempt_completion 或对应完成工具能出现。
查看 DeepAI API 中转站日志，记录模型、耗时、token 用量和失败轮次。

参考资料

总结

Cline 接入 DeepAI API 中转站后，如果提示 You did not use a tool in your previous response，说明模型回复没有被客户端解析成合法工具调用。排查时先确认请求到达中转站，再用最小任务验证工具解析；如果大项目才失败，优先减少文件列表和上下文噪声；如果最小任务也失败，选择工具遵循能力更强、上下文更稳定的模型。对代码 Agent 来说，协议能通只是第一步，工具格式稳定才是真正可用。